9.1.0b1

178 files changed, 29709 insertions, 6946 deletions

diff --git a/doc/Makefile.in b/doc/Makefile.in
new file mode 100644
index 00000000..b0168bd9
--- /dev/null
+++ b/doc/Makefile.in
@@ -0,0 +1,29 @@
+# Copyright (C) 1998-2000  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 INTERNET SOFTWARE CONSORTIUM
+# DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+# INTERNET SOFTWARE CONSORTIUM 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.1 2000/12/01 02:12:28 gson 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 =
+TARGETS =
+
+@BIND9_MAKE_RULES@
diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml
index 56ba7e88..aaac47e5 100644
--- a/doc/arm/Bv9ARM-book.xml
+++ b/doc/arm/Bv9ARM-book.xml
@@ -1,8 +1,8 @@
-<?xml version='1.0'?>
+
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
                "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd">
 
-<!-- File: $Id: Bv9ARM-book.xml,v 1.17 2000/10/18 18:27:46 gson Exp $ -->
+<!-- File: $Id: Bv9ARM-book.xml,v 1.65 2000/12/02 00:34:39 gson Exp $ -->
 
 <book>
 
@@ -140,7 +140,7 @@ called <command>named</command> and a <command>resolver</command> library.
 The <acronym>BIND</acronym> server runs in the background, servicing queries on a well
 known network port. The standard port for the User Datagram Protocol
 (UDP) and Transmission Control Protocol (TCP), usually port 53,
-is specified in<command> </command><filename>/etc/services</filename>.
+is specified in <filename>/etc/services</filename>.
 The <emphasis>resolver</emphasis> is a set of routines residing
 in a system library that provides the interface that programs can
 use to access the domain name services.</para>
@@ -163,18 +163,22 @@ start. Zones usually represent administrative boundaries. For example,
 a domain name for a host at the company <emphasis>Example, Inc.</emphasis> would
 be:</para>
 <para><systemitem class="systemname">ourhost.example.com</systemitem></para>
-<para>where <systemitem class="systemname">com</systemitem> is the top level domain to which <systemitem class="systemname">ourhost.example.com</systemitem> belongs, <systemitem class="systemname">example</systemitem> is
-a subdomain of <systemitem class="systemname">com</systemitem>, and <systemitem class="systemname">ourhost</systemitem> is the
+<para>where <systemitem class="systemname">com</systemitem> is the top level domain to which
+<systemitem class="systemname">ourhost.example.com</systemitem> belongs, 
+<systemitem class="systemname">example</systemitem> is
+a subdomain of <systemitem class="systemname">com</systemitem>, and
+<systemitem class="systemname">ourhost</systemitem> is the
 name of the host.</para>
 <para>The specifications for the domain nameserver are defined in
 the RFC 1034, RFC 1035 and RFC 974. These documents can be found
 in
 <filename>/usr/src/etc/named/doc</filename> in 4.4BSD or are available
 via File Transfer Protocol (FTP) from
-<ulink
-       url="ftp://www.isi.edu/in-notes/">ftp://www.isi.edu/in-notes/</ulink> or via the Web at <ulink url="http://www.ietf.org/rfc/">http://www.ietf.org/rfc/</ulink>.
+<ulink url="ftp://www.isi.edu/in-notes/">ftp://www.isi.edu/in-notes/</ulink>
+or via the Web at <ulink url="http://www.ietf.org/rfc/">http://www.ietf.org/rfc/</ulink>.
 (See Appendix C for complete information on finding and retrieving
-RFCs.) It is also recommended that you read the related man pages: <command>named</command> and <command>resolver</command>.</para></sect2>
+RFCs.) It is also recommended that you read the related man pages:
+<command>named</command> and <command>resolver</command>.</para></sect2>
 <sect2><title>Types of Zones</title>
 <para>As we 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
@@ -187,9 +191,12 @@ the root of the delegated zone.</para>
 <para>To properly operate a nameserver, it is important to understand
 the difference between a <emphasis>zone</emphasis> and a <emphasis>domain</emphasis>.</para>
 <para>For instance, consider the <systemitem class="systemname">example.com</systemitem> domain
-which includes names such as <systemitem class="systemname">host.aaa.example.com </systemitem>and <systemitem class="systemname">host.bbb.example.com</systemitem> even
-though the <systemitem class="systemname">example.com</systemitem> zone includes only delegations
-for the <systemitem class="systemname">aaa.example.com</systemitem> and <systemitem class="systemname">bbb.example.com</systemitem> zones.
+which includes names such as <systemitem class="systemname">host.aaa.example.com</systemitem>
+and <systemitem class="systemname">host.bbb.example.com</systemitem> even
+though the <systemitem class="systemname">example.com</systemitem>
+zone includes only delegations for the
+<systemitem class="systemname">aaa.example.com</systemitem>
+and <systemitem class="systemname">bbb.example.com</systemitem> 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
 nameservers. Every name in the <acronym>DNS</acronym> tree is a <emphasis>domain</emphasis>,
@@ -500,8 +507,9 @@ of the time:</para>
     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"/>. This substatement is not supported in
+    <command>options</command> statement, see
+    <xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
+    This substatement is not supported in
     <acronym>BIND</acronym> 9, and only the ordering scheme described above is
     available.</para>
 
@@ -635,67 +643,61 @@ of a server.</para>
                 <arg choice="plain"><replaceable>command</replaceable></arg>
                 <arg rep="repeat"><replaceable>command</replaceable></arg>
               </cmdsynopsis>
-              <para><command>command</command> is one of the following
-              for <command>named</command>:</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.500in"/>
-                  <colspec colname = "2" colnum = "2" colsep = "0"
-                           colwidth = "3.000in"/>
-                  <tbody>
-                    <row rowsep = "0">
-                      <entry colname = "1">
-<para><userinput>status</userinput><footnote id="nyi1">
-                            <para>not yet implemented</para>
-                          </footnote></para></entry>
-<entry colname = "2"><para>Display ps(1) status of named.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><userinput>dumpdb</userinput><footnoteref linkend="nyi1"/></para></entry>
-<entry colname = "2"><para>Dump database and cache to /var/tmp/named_dump.db.</para></entry>
-</row>
+              <para><command>command</command> is one of the following:</para>
+
+<informaltable colsep = "0" rowsep = "0">
+	<tgroup cols = "2" colsep = "0" rowsep = "0" tgroupstyle = "4Level-table">
+	<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "3.000in"/>
+        <colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.000in"/>
+        <tbody>
+
 <row rowsep = "0">
 <entry colname = "1"><para><userinput>reload</userinput></para></entry>
 <entry colname = "2"><para>Reload configuration file and zones.</para></entry>
 </row>
+
 <row rowsep = "0">
-<entry colname = "1"><para><userinput>stats</userinput><footnoteref linkend="nyi1"/></para></entry>
-<entry colname = "2"><para>Dump statistics to /var/tmp/named.stats.</para></entry>
+<entry colname = "1"><para><userinput>reload <replaceable>zone</replaceable> <optional><replaceable>class</replaceable> <optional><replaceable>view</replaceable></optional></optional></userinput></para></entry>
+<entry colname = "2"><para>Reload the given zone.</para></entry>
 </row>
+
 <row rowsep = "0">
-<entry colname = "1"><para><userinput>trace</userinput><footnoteref linkend="nyi1"/></para></entry>
-<entry colname = "2"><para>Increment debugging level by one.</para></entry>
+<entry colname = "1"><para><userinput>refresh <replaceable>zone</replaceable> <optional><replaceable>class</replaceable> <optional><replaceable>view</replaceable></optional></optional></userinput></para></entry>
+<entry colname = "2"><para>Schedule zone maintenance for the given zone.</para></entry>
 </row>
+
 <row rowsep = "0">
-                      <entry colname = "1">
-<para><userinput>notrace</userinput><footnoteref linkend="nyi1"/>
-</para></entry>
-<entry colname = "2"><para>Set debugging level to 0.</para></entry>
+<entry colname = "1"><para><userinput>stats</userinput></para></entry>
+<entry colname = "2"><para>Write server statistics to the statistics file.</para></entry>
 </row>
+
 <row rowsep = "0">
-                      <entry colname =
-                             "1"><para><userinput>querylog</userinput><footnoteref linkend="nyi1"/></para></entry>
+<entry colname = "1"><para><userinput>querylog</userinput></para></entry>
 <entry colname = "2"><para>Toggle query logging.</para></entry>
 </row>
+
 <row rowsep = "0">
-                      <entry colname =
-                             "1"><para><userinput>stop</userinput><footnoteref linkend="nyi1"/></para></entry>
-<entry colname = "2"><para>Stop the server.</para></entry>
+<entry colname = "1"><para><userinput>stop</userinput></para></entry>
+<entry colname = "2"><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.</para></entry>
 </row>
+
 <row rowsep = "0">
-                      <entry colname =
-                             "1"><para><userinput>restart</userinput><footnoteref linkend="nyi1"/></para></entry>
-<entry colname = "2"><para>Restart the server.</para></entry>
-                    </row>
-                  </tbody>
-                </tgroup>
-              </informaltable>
-              <para>As noted above, <command>reload</command> is the
-              only command available for <acronym>BIND</acronym> 9.0.0. The other
-              commands, and more, are planned to be implemented for
-              future releases.</para>
+<entry colname = "1"><para><userinput>halt</userinput></para></entry>
+<entry colname = "2"><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.</para></entry>
+</row>
+
+</tbody>
+</tgroup>
+</informaltable>
+
+<para>In <acronym>BIND</acronym> 9.1, <command>rndc</command> does not
+yet support all the commands of the BIND 8 <command>ndc</command>
+utility.  Additonal commands will be added in future releases.</para>
 
               <para>A configuration file is required, since all
               communication with the server is authenticated with
@@ -709,35 +711,35 @@ of a server.</para>
 
               <para>The format of the configuration file is similar to
               that of <filename>named.conf</filename>, but limited to
-              only three statements, the <command>options{}</command>,
-              <command>key{}</command> and <command>server{}</command>
+              only three statements, the <command>options</command>,
+              <command>key</command> and <command>server</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 two clauses: <command>default-server</command> and <command>default-key</command>. <command>default-server</command> takes a
+<para>The <command>options</command> statement has two clauses: <command>default-server</command> and <command>default-key</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 key as its argument, as defined by a <command>key{}</command> statement.
+the name of key as its argument, as defined by a <command>key</command> statement.
  In the future a <command>default-port</command> clause will be
 added to specify the port to which <command>rndc</command> should
 connect.</para>
-<para>The <command>key{}</command> statement names a key with its
+<para>The <command>key</command> statement names a key with its
 string argument. The string is required by the server to 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>.
+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, typically
 generated with either <command>dnssec-keygen</command> or <command>mmencode</command>.</para>
-<para>The <command>server{}</command> statement uses the key clause
-to associate a <command>key{}</command>-defined key with a server.
- The argument to the <command>server{}</command> statement is a
+<para>The <command>server</command> statement uses the key clause
+to associate a <command>key</command>-defined key with a server.
+ The argument to the <command>server</command> statement is a
 host name or address (addresses must be double quoted).  The argument
-to the key clause is the name of the key as defined by the <command>key{}</command> statement.
+to the key clause is the name of the key as defined by the <command>key</command> statement.
  A <command>port</command> clause will be added to a future release
 to specify the port to which <command>rndc</command> should connect
 on the given server.</para>
@@ -892,7 +894,7 @@ 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> </emphasis><filename>site1.internal</filename>,
 and <filename>site2.internal</filename>.</para>
-<para>To protect the<filename> site1.interna</filename><emphasis>l</emphasis> and<emphasis> </emphasis><filename>site2.internal</filename> domains,
+<para>To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
 the internal nameservers must be configured to disallow all queries
 to these domains from any external hosts, including the bastion
 hosts.</para>
@@ -937,7 +939,7 @@ internal clients will now be able to:</para>
 <para>Hosts on the Internet will be able to:</para>
 <itemizedlist><listitem>
         <simpara>Look up any hostnames in the <systemitem class="systemname">site1</systemitem> and 
-<systemitem class="systemname">site2.example.com </systemitem>zones.</simpara></listitem>
+<systemitem class="systemname">site2.example.com</systemitem> zones.</simpara></listitem>
 <listitem>
         <simpara>Exchange mail with anyone in the <systemitem class="systemname">site1</systemitem> and 
 <systemitem class="systemname">site2.example.com</systemitem> zones.</simpara></listitem></itemizedlist>
@@ -1121,17 +1123,17 @@ server 10.1.2.3 {
 <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 response
+<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 non-response messages to <emphasis>host1</emphasis>.</para></sect2>
+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.
+<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>
@@ -1224,11 +1226,14 @@ allow-update { key host1-host2. ;};
     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
+    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 and signedkey files to be in the working directory.</para>
+    keyset and signedkey files to be in the working directory, and
+    that the tools shipped with BIND 9.0.x are not fully 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 and signatures.  A
@@ -1275,7 +1280,7 @@ allow-update { key host1-host2. ;};
 
       <para>The public keys should be inserted into the zone file with
       <command>$INCLUDE</command> statements, including the
-      <filename>.key </filename>files.</para>
+      <filename>.key</filename> files.</para>
 
     </sect2>
     <sect2>
@@ -1302,10 +1307,10 @@ allow-update { key host1-host2. ;};
       3600 and a signature validity period of 10 days starting from
       now.</para>
 
-<para><userinput>dnssec-makekeyset -t 3600 -e +86400 Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para>
+<para><userinput>dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para>
 
       <para>One output file is produced:
-      <filename>child.example.keyset</filename>.  This file should be
+      <filename>keyset-child.example.</filename>.  This file should be
       transmitted to the parent to be signed.  It includes the keys,
       as well as signatures over the key set generated by the zone
       keys themselves, which are used to prove ownership of the
@@ -1328,10 +1333,10 @@ allow-update { key host1-host2. ;};
       <para>The following command signs the child's key set with the
       zone keys:</para>
 
-<para><userinput>dnssec-signkey grand.child.example.keyset Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para>
+<para><userinput>dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para>
 
       <para>One output file is produced:
-      <filename>grand.child.example.signedkey</filename>.  This file
+      <filename>signedkey-grand.child.example.</filename>.  This file
       should be both transmitted back to the child and retained.  It
       includes all keys (the child's keys) from the keyset file and
       signatures generated by this zone's zone keys.</para>
@@ -1600,24 +1605,35 @@ 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><title>Running a Resolver Daemon</title>
+<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>.</para>
-<para>Applications using the lightweight resolver library will make
-UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.
- The daemon will try to find the answer to the questions "what are the
-addresses for host <systemitem class="systemname">foo.example.com</systemitem>?" and "what are
-the names for IPv4 address 204.152.184.79?"</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 overriden by <command>lwserver</command> lines in
+<filename>/etc/resolv.conf</filename>.
+The daemon will try to find the answer to the questions "what are the
+addresses for host
+<systemitem class="systemname">foo.example.com</systemitem>?" and "what are
+the names for IPv4 address 10.1.2.3?"</para>
 <para>The daemon currently only looks in the DNS, but in the future
-it may use other sources such as <literal>/etc/hosts</literal>,
+it may use other sources such as <filename>/etc/hosts</filename>,
 NIS, etc.</para>
-<para>The <command>lwresd</command> daemon is essentially a stripped-down,
+<para>The <command>lwresd</command> daemon is essentially a
 caching-only name server that answers 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.
- 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></sect1></chapter>
+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="ch06"><title><acronym>BIND</acronym> 9 Configuration Reference</title>
 <para><acronym>BIND</acronym> 9 configuration is broadly similar to <acronym>BIND</acronym> 8.x; however,
@@ -1644,7 +1660,7 @@ 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><command>, </command><varname>ip_prefix</varname><command>, </command><varname>key_id</varname><command>, </command>or <varname>acl_name</varname> elements, see
+<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">
@@ -1668,7 +1684,7 @@ in <varname>dotted_decimal</varname> notation.</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<command> </command><varname>ip6_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>
@@ -1717,7 +1733,7 @@ value of <varname>size_spec</varname> is that of unsigned long integers
 on the machine. 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><command> </command>for
+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>Integer
@@ -1732,6 +1748,16 @@ to safely set a really large number.</para></entry>
 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>
@@ -2007,15 +2033,11 @@ Usage</title>
       the <command>key_list</command> is allowed to be used to
       authenticate commands and responses given over the control
       channel by digitally signing each message between the server and
-      a command client (See <xref linkend="rndc"/> in <xref
-                                                            linkend="admin_tools"/>). All commands to the
-      control channel must be signed by one of its specified keys to
+      a command client (See <xref linkend="rndc"/> in
+      <xref linkend="admin_tools"/>). All commands to the control channel
+      must be signed by one of its specified keys to
       be honored.</para>
 
-      <para> For the initial release of <acronym>BIND</acronym> 9.0.0, only one command
-      is possible over the command channel, the command to reload the
-      server.  We will expand command set in future releases.</para>
-
       <para>The UNIX control channel type of <acronym>BIND</acronym> 8 is not supported
       in <acronym>BIND</acronym> 9.0.0, and is not expected to be added in future
       releases.  If it is present in the controls statement from a
@@ -2077,8 +2099,9 @@ Usage</title>
      ( <command>file</command> <replaceable>path name</replaceable>
          [ <command>versions</command> ( <replaceable>number</replaceable> | <literal>unlimited</literal> ) ]
          [ <command>size</command> <replaceable>size spec</replaceable> ]
-       | <command>syslog</command> ( <replaceable>syslog_facility</replaceable> )
-       | <literal>null</literal> );
+       | <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>; ]
@@ -2102,11 +2125,12 @@ 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><command>logging</command> {
+<programlisting><command>logging</command> {
      category "default" { "default_syslog"; "default_debug"; };
-	};
+};
 </programlisting>
-      <para>In <acronym>BIND</acronym> 9, the logging configuration is only established when
+
+<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
@@ -2116,19 +2140,25 @@ 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 clause that says whether
-messages selected for the channel go to a file, to a particular
-syslog facility, 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
+
+<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 word <command>null</command> as the destination option
-for the channel will cause all messages sent to it to be discarded;
+
+<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> clause can include limitations
+
+<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>The <command>size</command> option for files is simply a hard
 ceiling on log growth. If the file ever exceeds the size, then <command>named</command> will
 not write anything more to it until the file is reopened; exceeding
@@ -2150,8 +2180,10 @@ is synonymous with <command>99</command> in current <acronym>BIND</acronym> rele
     print-time yes;
     print-category yes;
 };
-        </programlisting>
-<para>The argument for the <command>syslog</command> clause is a
+</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. How <command>syslog</command> will handle messages sent to
 this facility is described in the <command>syslog.conf</command> man
@@ -2172,6 +2204,12 @@ cause messages of severity <command>info</command> and <command>notice</command>
 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
@@ -2225,11 +2263,7 @@ channel "default_debug" {
 					// current debug level
 };
 channel "default_stderr" {		// writes to stderr
-    file "&lt;stderr&gt;";			// this is illustrative only;
-					// there's currently no way of
-					// specifying an internal file
-					// descriptor in the 
-					// configuration language.
+    stderr;
     severity info;			// only send priority info
 					// and higher
 };
@@ -2337,11 +2371,59 @@ lookups performed on behalf of clients by a caching name server.</para></entry>
 <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>queries</command></para></entry>
+<entry colname = "2"><para>Queries.</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>address_match_list</replaceable> }; </optional>
+    <optional> view <replaceable>view_name</replaceable>; </optional>
+    <optional> search { <replaceable>domain_name</replaceable> ; <optional> <replaceable>ip_addr</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 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 this statement is omitted, requests
+      will be accepted on 127.0.0.1, port 53.</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>options</command> Statement Grammar</title>
 
       <para>This is the grammar of the <command>options</command>
@@ -2356,15 +2438,16 @@ lookups performed on behalf of clients by a caching name server.</para></entry>
     <optional> memstatistics-file <replaceable>path_name</replaceable>; </optional>
     <optional> pid-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>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> has-old-clients <replaceable>yes_or_no</replaceable>; </optional>
     <optional> host-statistics <replaceable>yes_or_no</replaceable>; </optional>
     <optional> multiple-cnames <replaceable>yes_or_no</replaceable>; </optional>
-    <optional> notify <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</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>
@@ -2390,8 +2473,10 @@ lookups performed on behalf of clients by a caching name server.</para></entry>
     <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>; </optional>
-    <optional> transfer-source-v6 <replaceable>ip6_addr</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> 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> coresize <replaceable>size_spec</replaceable> ; </optional>
@@ -2416,6 +2501,9 @@ lookups performed on behalf of clients by a caching name server.</para></entry>
     <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>
 };
 </programlisting>
 </sect2>
@@ -2480,17 +2568,16 @@ most cases, the keyname should be the server's host name.</para></entry>
 <row rowsep = "0">
 <entry colname = "1"><para><command>dump-file</command></para></entry>
 <entry colname = "2"><para>The pathname of the file the server dumps
-the database to when it receives <command>SIGINT</command> signal
-(<command>ndc dumpdb</command>). If not specified, the default is <filename>named_dump.db</filename>.</para><note>
-                      <simpara>Not
-yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+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>
+<note><simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>memstatistics-file</command></para></entry>
 <entry colname = "2"><para>The pathname of the file the server writes memory
-usage statistics to on exit. If not specified, the default is <filename>named.memstats</filename>.</para><note>
-                      <simpara>Not
-yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+usage statistics to on exit. If not specified, the default is <filename>named.memstats</filename>.</para>
+<note><simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>pid-file</command></para></entry>
@@ -2504,10 +2591,26 @@ nameserver.</para></entry>
 <row rowsep = "0">
 <entry colname = "1"><para><command>statistics-file</command></para></entry>
 <entry colname = "2"><para>The pathname of the file the server appends statistics
-to. If not specified, the default is <filename>named.stats</filename>.</para><note>
-                      <simpara>Not
-yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+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></entry>
+</row>
+<row rowsep = "0">
+<entry colname = "1"><para><command>port</command></para></entry>
+<entry colname = "2"><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.
+The <command>port</command> option should be placed at
+the beginning of the options block, before
+any other options that take port numbers or IP addresses,
+to ensure that the port value takes effect for all addresses
+used by the server.</para>
+</entry>
 </row>
+
 </tbody>
 </tgroup></informaltable> </para>
 <sect3 id="boolean_options"><title>Boolean Options</title>
@@ -2540,18 +2643,28 @@ 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>zone</command> statement,
-in which case it overrides the <command>options dialup </command>statement.</para><para>If
-the zone is a master then the server will send out a NOTIFY request
+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. This will 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.</para><para>If the
-zone is a slave or stub then the server will suppress the regular
-"zone up to date" queries and only perform them when the
-<command>heartbeat-interval</command> expires.</para><note>
-                    <simpara>Not yet implemented
-in <acronym>BIND</acronym> 9.</simpara></note></entry>
+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 send refresh queries 
+when the <command>heartbeat-interval</command> expires and
+<userinput>passive</userinput> which just disables normal refresh
+processing.</para>
+</entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>fake-iquery</command></para></entry>
@@ -2560,33 +2673,28 @@ the obsolete DNS query type IQUERY. <acronym>BIND</acronym> 9 never does IQUERY
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>fetch-glue</command></para></entry>
-<entry colname = "2"><para>(Information present outside of the authoritative
-nodes in the zone is called <emphasis>glue</emphasis> information).
-If <userinput>yes</userinput> (the default), the server will fetch
-glue resource records it doesn't have when constructing the additional
-data section of a response. <command>fetch-glue </command><userinput>no</userinput><command> </command>can
-be used in conjunction with <command>recursion </command><userinput>no</userinput><command> </command>to
-prevent the server's cache from growing or becoming corrupted (at
-the cost of requiring more work from the client).</para><note>
-                    <simpara>Not yet
-implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+<entry colname = "2"><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>
+</entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>has-old-clients</command></para></entry>
 <entry colname = "2"><para>This option was incorrectly implemented
-in <acronym>BIND</acronym> 8, and is ignored by <acronym>BIND</acronym> 9.  To achieve the intended effect
+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></entry>
+<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></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>host-statistics</command></para></entry>
-<entry colname = "2"><para>If <userinput>yes</userinput>, then statistics
-are kept for every host that the nameserver interacts with. The
-default is <userinput>no</userinput>.</para><note>
-                    <simpara>turning on <command>host-statistics</command> can consume
-huge amounts of memory.</simpara></note><note>
-                    <simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+<entry colname = "2"><para>In BIND 8, this enables keeping of
+statistics for every host that the nameserver interacts with.
+Not implemented in BIND 9.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>maintain-ixfr-base</command></para></entry>
@@ -2594,22 +2702,28 @@ huge amounts of memory.</simpara></note><note>
  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></entry>
+transfers, use <command>provide-ixfr</command> <userinput>no</userinput>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>multiple-cnames</command></para></entry>
 <entry colname = "2"><para>This option was used in <acronym>BIND</acronym> 8 to allow
 a domain name to allow multiple CNAME records in violation of the
-DNS standards.  <acronym>BIND</acronym> 9 currently does not check for multiple CNAMEs
-in zone data loaded from master files, but such checks may be introduced
-in a later release.  <acronym>BIND</acronym> 9 always strictly enforces the CNAME rules
-in dynamic updates.</para></entry>
+DNS standards.  <acronym>BIND</acronym> 9.1 always strictly
+enforces the CNAME rules both in master files and dynamic updates.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>notify</command></para></entry>
 <entry colname = "2"><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"/>.
+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>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
@@ -2643,10 +2757,25 @@ answers. The default is <userinput>no</userinput>.</para>
  <acronym>BIND</acronym> 9 always allocates query IDs from a pool.</para></entry>
 </row>
 <row rowsep = "0">
+<entry colname = "1"><para><command>zone-statistics</command></para></entry>
+<entry colname = "2"><para>If <userinput>yes</userinput>, the server will, by default, collect
+statistical data on all zones in the server.  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></entry>
+</row>
+<row rowsep = "0">
+<entry colname = "1"><para><command>use-ixfr</command></para></entry>
+<entry colname = "2"><para></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"/>.</entry>
+</row>
+<row rowsep = "0">
 <entry colname = "1"><para><command>treat-cr-as-space</command></para></entry>
 <entry colname = "2"><para>This option was used in <acronym>BIND</acronym> 8 to make
-the server treat "<command>\r</command>" characters the same way
-as <command>&#60;space> </command>" " or "<command>\t</command>",
+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,
@@ -2668,10 +2797,40 @@ 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 per-server.
-These options are valid for slave and stub zones, and clamp the SOA
+These options are valid for master, slave and stub zones, and clamp the SOA
 refresh and retry times to the specified values.
 </para>
-<note><para>These options are not yet implemented in <acronym>BIND</acronym> 9.0.</para></note>
+</entry>
+</row>
+
+<row rowsep = "0">
+<entry colname = "1">
+<para><command>additional-from-auth</command></para>
+<para><command>additional-from-cache</command></para>
+</entry>
+<entry colname = "2"><para>
+These options control the server's behavior when answering queries
+which have additional data, or when following CNAME and DNAME
+chains to provide additional data.
+</para><para>
+When both of these options are set to <userinput>yes</userinput> 
+(the default) and a
+query is being answered from authoratitive data (a zone
+configured into the server), the additional data section of the
+reply will be filled in using data from other authoratitive 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
+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, A6, and AAAA) for <literal>mail.example.net</literal> will be provided as well,
+if known.  These options disable this behavior.
+</para>
 </entry>
 </row>
 
@@ -2711,50 +2870,6 @@ 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 id="name_checking"><title>Name Checking</title>
-<para>The server can check domain names based upon their expected
-client contexts. For example, a domain name used as a hostname can
-be checked for compliance with the RFCs defining valid hostnames.</para>
-<para>Three checking methods are available:</para>
-<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.797in"/>
-<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "3.703in"/>
-<tbody>
-<row rowsep = "0">
-<entry colname = "1"><para><command>ignore</command></para></entry>
-<entry colname = "2"><para>No checking is done.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>warn</command></para></entry>
-<entry colname = "2"><para>Names are checked against their expected
-client contexts. Invalid names are logged, but processing continues normally.</para></entry>
-</row>
-<row rowsep = "0">
-<entry colname = "1"><para><command>fail</command></para></entry>
-<entry colname = "2"><para>Names are checked against their expected
-client contexts. Invalid names are logged, and the offending data
-is rejected.</para></entry>
-</row>
-</tbody>
-</tgroup></informaltable></para>
-<para>The server can check names in three areas: master zone files,
-slave zone files, and in responses to queries the server has initiated.
-If <command>check-names response fail</command> has been specified,
-and answering the client's question would require sending an invalid
-name to the client, the server will send a REFUSED response code
-to the client.</para>
-<para>The defaults are:</para>
-<programlisting>    check-names master fail;
-    check-names slave warn;
-    check-names response ignore;
-</programlisting>
-<para><command>check-names</command> may also be specified in the <command>zone</command> statement,
-in which case it overrides the <command>options check-names</command> statement.
-When used in a <command>zone</command> statement, the area is not
-specified because it can be deduced from the zone type.</para>
-        <note>
-<para>Name checking is not yet implemented in <acronym>BIND</acronym> 9.</para></note></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
@@ -2793,9 +2908,7 @@ If not specified, the default is to allow transfers from all hosts.</para></entr
 <entry colname = "1"><para><command>blackhole</command></para></entry>
 <entry colname = "2"><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>
-<note>
-                      <simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+from these addresses will not be responded to. The default is <userinput>none</userinput>.</para></entry>
 </row>
 </tbody>
 </tgroup></informaltable></para></sect3>
@@ -2839,7 +2952,7 @@ listen-on-v6 port 1234 { any; };
 <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>statement is specified,
+<para>If no <command>listen-on-v6</command> statement 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
@@ -2869,9 +2982,10 @@ system. The following options apply to zone transfers.</para>
 <tbody>
 <row rowsep = "0">
 <entry colname = "1"><para><command>also-notify</command></para></entry>
-<entry colname = "2"><para>Defines a global list of IP addresses
+<entry colname = "2"><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. This helps to ensure that copies of the zones will
+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
@@ -2910,25 +3024,14 @@ servers to find out if zone serial numbers have changed. Each such
 query uses a minute amount of the slave server's network bandwidth,
 but more importantly each query uses a small amount of memory in
 the slave server while waiting for the master server to respond.
-The <command>serial-queries </command>option sets the maximum number
+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. The default is 4.</para><note>
-
-                    <simpara>If a server loads a large (tens or
-                    hundreds of thousands) number of slave zones, then
-                    this limit should be raised to the high hundreds
-                    or low thousands, otherwise the slave server may
-                    never actually become aware of zone changes in the
-                    master servers. Beware, though, that setting this
-                    limit arbitrarily high can spend a considerable
-                    amount of your slave server's network, CPU, and
-                    memory resources. As with all tunable limits, this
-                    one should be changed gently and monitored for its
-                    effects.</simpara>
-
-</note>
-<note>
-<simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note>
+any given time.  BIND 9 does not limit the number of outstanding
+serial queries and ignores the The <command>serial-queries</command> option;
+instead, it limits the rate at which the queries are sent.
+The maximum rate is currently fixed at 20 queries
+per second but may become configurable in a future release.  
+</para>
 </entry>
 </row>
 <row rowsep = "0">
@@ -2967,14 +3070,17 @@ of the <command>server</command> statement.</para></entry>
 <entry colname = "1"><para><command>transfer-source</command></para></entry>
 <entry colname = "2"><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. If not set, it defaults
+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-zone basis by including a
-<command>transfer-source</command> statement within the <command>zone</command> block
+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></entry>
 </row>
 <row rowsep = "0">
@@ -2982,6 +3088,23 @@ in the configuration file.</para></entry>
 <entry colname = "2"><para>The same as <command>transfer-source</command>,
 except zone transfers are performed using IPv6.</para></entry>
               </row>
+<row rowsep = "0">
+<entry colname = "1"><para><command>notify-source</command></para></entry>
+<entry colname = "2"><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.
+This statement sets the <command>notify-source</command> for all zones,
+but can be overridden on a per-zone / 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></entry>
+</row>
+<row rowsep = "0">
+<entry colname = "1"><para><command>notify-source-v6</command></para></entry>
+<entry colname = "2"><para>Like <command>notify-source</command>,
+but applies to notify messages sent to IPv6 addresses.</para></entry>
+              </row>
             </tbody>
           </tgroup>
         </informaltable>
@@ -3011,39 +3134,23 @@ except zone transfers are performed using IPv6.</para></entry>
 <row rowsep = "0">
 <entry colname = "1"><para><command>coresize</command></para></entry>
 <entry colname = "2"><para>The maximum size of a core dump. The default
-is <literal>default</literal>.</para><note>
-                    <simpara>Not yet implemented in <acronym>BIND</acronym>
-9.</simpara></note></entry>
+is <literal>default</literal>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>datasize</command></para></entry>
 <entry colname = "2"><para>The maximum amount of data memory the server
-may use. The default is <literal>default</literal>.</para><note>
-<simpara>Not
-yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+may use. The default is <literal>default</literal>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>files</command></para></entry>
 <entry colname = "2"><para>The maximum number of files the server
 may have open concurrently. The default is <literal>unlimited</literal>.
-</para><note>
-                    <simpara>on some operating systems the server cannot set an unlimited
-value and cannot determine the maximum number of open files the
-kernel can support. On such systems, choosing 
-<literal>unlimited</literal> will
-cause the server to use the larger of the <command>rlim_max</command> for <command>RLIMIT_NOFILE</command> and
-the value returned by <command>sysconf(_SC_OPEN_MAX)</command>.
-If the actual kernel limit is larger than this value, use <command>limit
-files </command>to specify the limit explicitly.</simpara></note><note><simpara>Not yet
-implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>max-ixfr-log-size</command></para></entry>
-<entry colname = "2"><para>The <command>max-ixfr-log-size</command> will
-be used in a future release of the server to limit the size of the
-transaction log kept for Incremental Zone Transfer.</para><note>
-<simpara>Not
-yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+<entry colname = "2"><para>This option is obsolete; it is accepted
+and ignored for BIND 8 compatibility.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>recursive-clients</command></para></entry>
@@ -3054,9 +3161,7 @@ is <literal>1000</literal>.</para></entry>
 <row rowsep = "0">
 <entry colname = "1"><para><command>stacksize</command></para></entry>
 <entry colname = "2"><para>The maximum amount of stack memory the server
-may use. The default is <literal>default</literal>.</para><note>
-<simpara>Not
-yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+may use. The default is <literal>default</literal>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>tcp-clients</command></para></entry>
@@ -3083,11 +3188,9 @@ If set to 0, no  periodic cleaning will occur.</para></entry>
 <row rowsep = "0">
 <entry colname = "1"><para><command>heartbeat-interval</command></para></entry>
 <entry colname = "2"><para>The server will perform zone maintenance tasks
-for all zones marked  <command>dialup yes</command> whenever this
+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). If set to 0, no zone maintenance for these zones will occur.</para><note>
-                    <simpara>Not yet
-implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+to 1 day (1440 minutes). If set to 0, no zone maintenance for these zones will occur.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>interface-interval</command></para></entry>
@@ -3104,7 +3207,7 @@ that have gone away will be cleaned up.</para></entry>
 <entry colname = "2"><para>Nameserver statistics will be logged
 every <command>statistics-interval</command> minutes. The default is 
 60. If set to 0, no statistics will be logged.</para><note>
-                    <simpara>Not yet implemented in <acronym>BIND</acronym>9.</simpara></note></entry>
+<simpara>Not yet implemented in <acronym>BIND</acronym>9.</simpara></note></entry>
 </row>
 </tbody>
 </tgroup></informaltable></sect3>
@@ -3147,7 +3250,7 @@ records, or <varname>RRset</varname>, you must use the <command>sortlist</comman
                                                     linkend="types_of_resource_records_and_when_to_use_them"/>. Specifications for RRs
 are documented in RFC 1035.</para>
 <para>When returning multiple RRs the nameserver will normally return
-them in <varname>Round Robin</varname><varname> </varname>order,
+them in <varname>Round Robin</varname> order,
 that is, after each request the first RR is put at the end of the
 list. The client resolver code should rearrange the RRs as appropriate,
 that is, using any addresses on the local net in preference to other addresses.
@@ -3156,7 +3259,7 @@ 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 nameservers, not all the clients.</para>
 <para>The <command>sortlist</command> statement (see below) takes
-an <command>address_match_list </command>and interprets it even
+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
@@ -3189,7 +3292,7 @@ their directly connected networks.</para>
     { 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.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; }; }; };
@@ -3204,7 +3307,7 @@ their directly connected networks.</para>
 };</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> 8.x. Responses sent
+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
@@ -3288,8 +3391,6 @@ lame server indication. 0 disables caching. (This is
 <emphasis role="bold">NOT</emphasis> recommended.)
 Default is <literal>600</literal> (10 minutes). Maximum value is 
 <literal>1800</literal> (30 minutes).</para>
-<note>
-                    <simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note>
 </entry>
 </row>
 <row rowsep = "0">
@@ -3329,17 +3430,68 @@ to allow for a limited amount of clock skew.</para></entry>
 </row>
 </tbody>
 </tgroup></informaltable></sect3>
-      <sect3>
-        <title>Deprecated Features</title>
 
-        <para><command>use-ixfr</command> is deprecated in <acronym>BIND</acronym> 9. 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>
+<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 the line <command>+++ Statistics Dump
++++ (973798949)</command>, where 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).  The statistics dump ends
+with the line <command>--- Statistics Dump --- (973798949)</command>, where the
+number is identical to the number in the beginning line.</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 other than
+a referral response.</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>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>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>
+</tbody>
+</tgroup></informaltable>
+</sect3>
 
-</sect3></sect2>
+</sect2>
     <sect2 id="server_statement_grammar">
       <title><command>server</command>
 Statement Grammar</title>
@@ -3360,16 +3512,13 @@ to be associated with a remote nameserver.</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>
-      <note>
-        <simpara>The <command>bogus</command> clause
-is not yet implemented in <acronym>BIND</acronym> 9.</simpara></note>
 <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 nonincremental. If not set, the value
-of the <command>provide-ixfr </command>option in the global options block
+of the <command>provide-ixfr</command> option in the 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
@@ -3388,14 +3537,14 @@ uses one DNS message per resource record transferred. <command>many-answers</com
 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
+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 is used to identify a <command>key_id </command>defined
+<para>The <command>keys</command> clause is used to identify a <command>key_id</command> defined
 by the <command>key</command> statement, to be used for transaction
 security when talking to the remote server. The <command>key</command> statement
 must come before the <command>server</command> statement that references
@@ -3430,6 +3579,7 @@ key data.</para></sect2>
 <programlisting>view <replaceable>view_name</replaceable> <optional><replaceable>class</replaceable></optional> {
       match-clients { <replaceable>address_match_list</replaceable> } ;
       <optional> <replaceable>view_option</replaceable>; ...</optional>
+      <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
       <optional> <replaceable>zone_statement</replaceable>; ...</optional>
 };
 </programlisting></sect2>
@@ -3442,7 +3592,7 @@ split DNS setups without having to run multiple servers.</para>
 DNS namespace that will be seen by those clients whose IP addresses
 match the <varname>address_match_list</varname> of the view's <command>match-clients</command> clause.
  The order of the <command>view</command> statements is significant-a
-client query will be resolved in the context of the first <command>view</command> whose <command>match-clients </command>list
+client query will be resolved in the context of the first <command>view</command> whose <command>match-clients</command> list
 matches the client's IP address.</para>
 <para>Zones defined within a <command>view</command> statement will
 be only be accessible to clients that match the <command>view</command>.
@@ -3503,24 +3653,28 @@ Statement Grammar</title>
     <optional> allow-update-forwarding { <replaceable>address_match_list</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>true_or_false</replaceable> ; </optional>
+    <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
     <optional> file <replaceable>string</replaceable> ; </optional>
     <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
     <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> ; <optional> <replaceable>ip_addr</replaceable> ; <optional>...</optional></optional></optional> } ; </optional>
     <optional> ixfr-base <replaceable>string</replaceable> ; </optional>
     <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
-    <optional> maintain-ixfr-base <replaceable>true_or_false</replaceable> ; </optional>
+    <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
     <optional> masters <optional>port <replaceable>ip_port</replaceable></optional> { <replaceable>ip_addr</replaceable> ; <optional><replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <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>true_or_false</replaceable> ; </optional>
+    <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</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>
-    <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) ; </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> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
     <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional>
+    <optional> database <replaceable>string</replaceable> ; </optional>
 }</optional>;
 </programlisting>
 </sect2>
@@ -3555,7 +3709,7 @@ tens or hundreds of thousands) of zones per server, it is best to
 use a two level naming scheme for zone file names. For example,
 a slave server for the zone <systemitem class="systemname">example.com</systemitem> might place
 the zone contents into a file called
-<filename>ex/example.com</filename> where <filename>ex/ </filename>is
+<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 100K files into a single directory.)</para></entry>
 </row>
@@ -3591,9 +3745,7 @@ 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 respecify the global forwarders.</para>
-<note>
-                <simpara>Domain-specific
-forwarding is not yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+</entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><varname>hint</varname></para></entry>
@@ -3648,11 +3800,22 @@ updates from all hosts.</para></entry>
               </row>
               <row rowsep = "0">
                 <entry colname = "1"><para><command>allow-update-forwarding</command></para></entry>
-                <entry colname = "2"><para>Specifies which hosts are allowed to
+
+<entry colname = "2"><para>Specifies which hosts are allowed to
 submit Dynamic DNS updates to slave zones to be forwarded to the
-master. The default is to deny update forwarding from all hosts.</para><note>
-                    <simpara>Update
-forwarding is not yet implemented.</simpara></note></entry>
+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>
+</entry>
               </row>
               <row rowsep = "0">
                 <entry colname = "1"><para><command>also-notify</command></para></entry>
@@ -3669,16 +3832,33 @@ The default is the empty list.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>check-names</command></para></entry>
-                <entry colname = "2"><para>See <xref
-                                                     linkend="name_checking"/>.</para>
-<note>
-                    <simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+<entry colname = "2"><para>
+This option was used in BIND 8 to restrict the character set of
+domain names in master files and/or DNS responses received from the
+netowrk.  BIND 9 does not restrict the character set of domain names
+and does not implement the <command>check-names</command> option.
+</para>
+</entry>
+</row>
+<row rowsep = "0">
+<entry colname = "1"><para><command>database</command></para></entry>
+<entry colname = "2"><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>
+</entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>dialup</command></para></entry>
-                <entry colname = "2"><para>See the description of
-<command>dialup</command> under <xref linkend="boolean_options"/>.
-<note><simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note></para></entry>
+               <entry colname = "2"><para>See the description of
+<command>dialup</command> in <xref linkend="boolean_options"/>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>forward</command></para></entry>
@@ -3686,16 +3866,14 @@ The default is the empty list.</para></entry>
 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>
-<note>
-                    <simpara>Not yet implemented in <acronym>BIND</acronym> 9.</simpara></note></entry>
+</entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>forwarders</command></para></entry>
 <entry colname = "2"><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; the global options are not used.</para><note>
-<para>Not
-yet implemented in <acronym>BIND</acronym> 9.</para></note></entry>
+no forwarding is done for the zone; the global options are not used.</para>
+</entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>ixfr-base</command></para></entry>
@@ -3708,27 +3886,27 @@ zone file.</para></entry>
 <row rowsep = "0">
 <entry colname = "1"><para><command>max-transfer-time-in</command></para></entry>
 <entry colname = "2"><para>See the description of
-<command>max-transfer-time-in</command> under <xref linkend="zone_transfers"/>.</para></entry>
+<command>max-transfer-time-in</command> in <xref linkend="zone_transfers"/>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>max-transfer-idle-in</command></para></entry>
 <entry colname = "2"><para>See the description of
-<command>max-transfer-idle-in</command> under <xref linkend="zone_transfers"/>.</para></entry>
+<command>max-transfer-idle-in</command> in <xref linkend="zone_transfers"/>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>max-transfer-time-out</command></para></entry>
 <entry colname = "2"><para>See the description of
-<command>max-transfer-time-out</command> under <xref linkend="zone_transfers"/>.</para></entry>
+<command>max-transfer-time-out</command> in <xref linkend="zone_transfers"/>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>max-transfer-idle-out</command></para></entry>
 <entry colname = "2"><para>See the description of
-<command>max-transfer-idle-out</command> under <xref linkend="zone_transfers"/>.</para></entry>
+<command>max-transfer-idle-out</command> in <xref linkend="zone_transfers"/>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>notify</command></para></entry>
                 <entry colname = "2"><para>See the description of
-<command>notify</command> under <xref linkend="boolean_options"/>.</para></entry>
+<command>notify</command> in <xref linkend="boolean_options"/>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>pubkey</command></para></entry>
@@ -3738,24 +3916,39 @@ zones when they are loaded from disk. <acronym>BIND</acronym> 9 does not verify
 on loading and ignores the option.</para></entry>
 </row>
 <row rowsep = "0">
+<entry colname = "1"><para><command>zone-statistics</command></para></entry>
+<entry colname = "2"><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></entry>
+</row>
+<row rowsep = "0">
 <entry colname = "1"><para><command>sig-validity-interval</command></para></entry>
                 <entry colname = "2"><para>See the description of
-<command>sig-validity-interval</command> under <xref linkend="tuning"/>.</para></entry>
+<command>sig-validity-interval</command> in <xref linkend="tuning"/>.</para></entry>
 </row>
 <row rowsep = "0">
 <entry colname = "1"><para><command>transfer-source</command></para></entry>
-<entry colname = "2"><para>Determines which local address will be bound
-to the IPv4 TCP connection used to fetch this zone. If not set,
-it defaults to a system controlled value which will usually be the
-address of the interface "closest to" the remote end. If the remote
-end user is an <command>allow-transfer</command> option for this
-zone, the address, supplied by the <command>transfer-source</command> option,
-needs to be specified in that <command>allow-transfer</command> option.</para></entry>
+<entry colname = "2"><para>See the description of
+<command>transfer-source</command> in <xref linkend="zone_transfers"/>
+</para></entry>
 </row>
 <row rowsep = "0">
-<entry colname = "1"><para>transfer-source-v6</para></entry>
-<entry colname = "2"><para>Similar to transfer-source, but for zone transfers
-performed using IPv6.</para></entry>
+<entry colname = "1"><para><command>transfer-source-v6</command></para></entry>
+<entry colname = "2"><para>See the description of
+<command>transfer-source-v6</command> in <xref linkend="zone_transfers"/>
+</para></entry>
+</row>
+<row rowsep = "0">
+<entry colname = "1"><para><command>notify-source</command></para></entry>
+<entry colname = "2"><para>See the description of
+<command>notify-source</command> in <xref linkend="zone_transfers"/>
+</para></entry>
+</row>
+<row rowsep = "0">
+<entry colname = "1"><para><command>notify-source-v6</command></para></entry>
+<entry colname = "2"><para>See the description of
+<command>notify-source-v6</command> in <xref linkend="zone_transfers"/>.
+</para></entry>
 </row>
 </tbody>
 </tgroup></informaltable></sect3>
@@ -4312,9 +4505,9 @@ 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
+<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>&#60;<varname>zone-name</varname>><command>.</command> The
+in there is an implicit <command>$ORIGIN</command> &#60;<varname>zone-name</varname>><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><literal>$ORIGIN example.com
@@ -4345,7 +4538,7 @@ with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.</para>
 <sect2><title><acronym>BIND</acronym> Master File Extension: the  <command>$GENERATE</command> Directive</title>
         <para>Syntax: <command>$GENERATE</command> <replaceable>range</replaceable> <replaceable>hs</replaceable> <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
+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>
@@ -4376,10 +4569,23 @@ or start-stop/step. If the first form is used then step is set to
           <entry colname = "2"><para><command>lhs</command> describes the
 owner name of the resource records to be created.      Any single <command>$</command> symbols
 within the <command>lhs</command> side are replaced by the iterator
-value. To get a $ in the output use a double <command>$</command>,
-e.g. <command>$$</command>. If the <command>lhs</command> is not
-absolute, the current <command>$ORIGIN </command>is appended to
-the name.</para></entry>
+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 interator, field width and base. 
+Modifiers are introduced by a <command>{</command> immediately following the
+<command>$</command> as <command>${offset[,width[,base]]}</command>.
+e.g. <command>${-20,3,d}</command> which subtracts 20 from the current value,
+prints the result as a decimal in a zero padded field of with 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 compatability with earlier versions <command>$$</command> is still
+recognised a indicating a literal $ in the output.</para></entry>
         </row>
         <row rowsep = "0">
           <entry colname = "1"><para><command>type</command></para></entry>
@@ -4394,11 +4600,7 @@ similarly to lhs.</para></entry>
       </tbody>
       </tgroup></informaltable>
       <para>The <command>$GENERATE</command> directive is a <acronym>BIND</acronym> extension
-and not part of the standard zone file format.
-<note>
-          <simpara>It is not yet implemented in <acronym>BIND</acronym> 9.</simpara>
-        </note>
-</para>
+and not part of the standard zone file format.</para>
     </sect2>
   </sect1>
 </chapter>
@@ -4473,17 +4675,34 @@ 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></sect2></sect1>
-<sect1><title>Dynamic Updates</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. <acronym>BIND9</acronym> also
-supports authenticating updates cryptographically by means of transaction
-signatures (TSIG). The use of TSIG is strongly recommended.</para>
+<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>
+all.</para>
+
+</sect1></chapter>
 
 <chapter id="ch08">
   <title>Troubleshooting</title>
@@ -4539,7 +4758,7 @@ all.</para></sect1></chapter>
     <acronym>BIND</acronym> and <acronym>DHCP</acronym>.</para>
 
     <para>To discuss arrangements for support, contact
-    <ulink url="email:info@isc.org">info@isc.org</ulink> or visit the
+    <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>
@@ -5370,9 +5589,7 @@ after which they are deleted unless updated by their authors.
       </bibliography>
     </sect2>
   </sect1>
+
 </appendix>
 
 </book>
-
-
-
diff --git a/doc/arm/Bv9ARM.ch01.html b/doc/arm/Bv9ARM.ch01.html
index 5a139148..d772ca30 100644
--- a/doc/arm/Bv9ARM.ch01.html
+++ b/doc/arm/Bv9ARM.ch01.html
@@ -232,6 +232,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -352,6 +353,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -546,10 +548,7 @@ CLASS="acronym"
 > server runs in the background, servicing queries on a well
 known network port. The standard port for the User Datagram Protocol
 (UDP) and Transmission Control Protocol (TCP), usually port 53,
-is specified in<B
-CLASS="command"
-> </B
-><TT
+is specified in <TT
 CLASS="filename"
 >/etc/services</TT
 >.
@@ -564,7 +563,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN136"
+NAME="AEN135"
 >1.4.1. Nameservers</A
 ></H2
 ><P
@@ -604,17 +603,20 @@ CLASS="systemitem"
 >where <SPAN
 CLASS="systemitem"
 >com</SPAN
-> is the top level domain to which <SPAN
+> is the top level domain to which
+<SPAN
 CLASS="systemitem"
 >ourhost.example.com</SPAN
-> belongs, <SPAN
+> belongs, 
+<SPAN
 CLASS="systemitem"
 >example</SPAN
 > is
 a subdomain of <SPAN
 CLASS="systemitem"
 >com</SPAN
->, and <SPAN
+>, and
+<SPAN
 CLASS="systemitem"
 >ourhost</SPAN
 > is the
@@ -632,13 +634,15 @@ via File Transfer Protocol (FTP) from
 HREF="ftp://www.isi.edu/in-notes/"
 TARGET="_top"
 >ftp://www.isi.edu/in-notes/</A
-> or via the Web at <A
+>
+or via the Web at <A
 HREF="http://www.ietf.org/rfc/"
 TARGET="_top"
 >http://www.ietf.org/rfc/</A
 >.
 (See Appendix C for complete information on finding and retrieving
-RFCs.) It is also recommended that you read the related man pages: <B
+RFCs.) It is also recommended that you read the related man pages:
+<B
 CLASS="command"
 >named</B
 > and <B
@@ -651,7 +655,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN157"
+NAME="AEN156"
 >1.4.2. Types of Zones</A
 ></H2
 ><P
@@ -682,19 +686,22 @@ CLASS="systemitem"
 > domain
 which includes names such as <SPAN
 CLASS="systemitem"
->host.aaa.example.com </SPAN
->and <SPAN
+>host.aaa.example.com</SPAN
+>
+and <SPAN
 CLASS="systemitem"
 >host.bbb.example.com</SPAN
 > even
 though the <SPAN
 CLASS="systemitem"
 >example.com</SPAN
-> zone includes only delegations
-for the <SPAN
+>
+zone includes only delegations for the
+<SPAN
 CLASS="systemitem"
 >aaa.example.com</SPAN
-> and <SPAN
+>
+and <SPAN
 CLASS="systemitem"
 >bbb.example.com</SPAN
 > zones.
@@ -810,7 +817,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN194"
+NAME="AEN193"
 >1.4.3. Servers</A
 ></H2
 ><P
@@ -842,7 +849,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN202"
+NAME="AEN201"
 >1.4.3.1. Master Server</A
 ></H3
 ><P
@@ -860,7 +867,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN206"
+NAME="AEN205"
 >1.4.3.2. Slave Server</A
 ></H3
 ><P
@@ -882,7 +889,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN211"
+NAME="AEN210"
 >1.4.3.3. Caching Only Server</A
 ></H3
 ><P
@@ -901,7 +908,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN215"
+NAME="AEN214"
 >1.4.3.4. Forwarding Server</A
 ></H3
 ><P
@@ -946,7 +953,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN223"
+NAME="AEN222"
 >1.4.3.5. Stealth Server</A
 ></H3
 ><P
diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html
index 6ff4fc3f..c216bbde 100644
--- a/doc/arm/Bv9ARM.ch02.html
+++ b/doc/arm/Bv9ARM.ch02.html
@@ -78,27 +78,27 @@ CLASS="TOC"
 ></DT
 ><DT
 >2.1. <A
-HREF="Bv9ARM.ch02.html#AEN230"
+HREF="Bv9ARM.ch02.html#AEN229"
 >Hardware requirements</A
 ></DT
 ><DT
 >2.2. <A
-HREF="Bv9ARM.ch02.html#AEN238"
+HREF="Bv9ARM.ch02.html#AEN237"
 >CPU Requirements</A
 ></DT
 ><DT
 >2.3. <A
-HREF="Bv9ARM.ch02.html#AEN242"
+HREF="Bv9ARM.ch02.html#AEN241"
 >Memory Requirements</A
 ></DT
 ><DT
 >2.4. <A
-HREF="Bv9ARM.ch02.html#AEN247"
+HREF="Bv9ARM.ch02.html#AEN246"
 >Nameserver Intensive Environment Issues</A
 ></DT
 ><DT
 >2.5. <A
-HREF="Bv9ARM.ch02.html#AEN250"
+HREF="Bv9ARM.ch02.html#AEN249"
 >Supported Operating Systems</A
 ></DT
 ></DL
@@ -108,7 +108,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN230"
+NAME="AEN229"
 >2.1. Hardware requirements</A
 ></H1
 ><P
@@ -139,7 +139,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN238"
+NAME="AEN237"
 >2.2. CPU Requirements</A
 ></H1
 ><P
@@ -156,7 +156,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN242"
+NAME="AEN241"
 >2.3. Memory Requirements</A
 ></H1
 ><P
@@ -183,7 +183,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN247"
+NAME="AEN246"
 >2.4. Nameserver Intensive Environment Issues</A
 ></H1
 ><P
@@ -203,7 +203,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN250"
+NAME="AEN249"
 >2.5. Supported Operating Systems</A
 ></H1
 ><P
diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html
index 4f327893..e78e837d 100644
--- a/doc/arm/Bv9ARM.ch03.html
+++ b/doc/arm/Bv9ARM.ch03.html
@@ -80,7 +80,7 @@ HREF="Bv9ARM.ch03.html#sample_configuration"
 ></DT
 ><DT
 >3.2. <A
-HREF="Bv9ARM.ch03.html#AEN286"
+HREF="Bv9ARM.ch03.html#AEN285"
 >Load Balancing</A
 ></DT
 ><DT
@@ -90,7 +90,7 @@ HREF="Bv9ARM.ch03.html#notify"
 ></DT
 ><DT
 >3.4. <A
-HREF="Bv9ARM.ch03.html#AEN374"
+HREF="Bv9ARM.ch03.html#AEN373"
 >Nameserver Operations</A
 ></DT
 ></DL
@@ -112,7 +112,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN276"
+NAME="AEN275"
 >3.1.1. A Caching-only Nameserver</A
 ></H2
 ><P
@@ -143,7 +143,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN280"
+NAME="AEN279"
 >3.1.2. An Authoritative-only Nameserver</A
 ></H2
 ><P
@@ -198,7 +198,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN286"
+NAME="AEN285"
 >3.2. Load Balancing</A
 ></H1
 ><P
@@ -217,6 +217,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -428,12 +429,14 @@ CLASS="command"
     <B
 CLASS="command"
 >options</B
-> statement, see <A
+> statement, see
+    <A
 HREF="Bv9ARM.ch06.html#rrset_ordering"
 ><I
 >RRset Ordering</I
 ></A
->. This substatement is not supported in
+>.
+    This substatement is not supported in
     <SPAN
 CLASS="acronym"
 >BIND</SPAN
@@ -471,14 +474,14 @@ CLASS="command"
 >also-notify</B
 >, see <A
 HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.12.7</A
+>Section 6.2.14.6</A
 >. For more information about
     <B
 CLASS="command"
 >notify</B
 >, see <A
 HREF="Bv9ARM.ch06.html#boolean_options"
->Section 6.2.12.1</A
+>Section 6.2.14.1</A
 >.</P
 ></DIV
 ><DIV
@@ -486,7 +489,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN374"
+NAME="AEN373"
 >3.4. Nameserver Operations</A
 ></H1
 ><DIV
@@ -494,7 +497,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN376"
+NAME="AEN375"
 >3.4.1. Tools for Use With the Nameserver Daemon</A
 ></H2
 ><P
@@ -507,7 +510,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN379"
+NAME="AEN378"
 >3.4.1.1. Diagnostic Tools</A
 ></H3
 ><P
@@ -773,55 +776,26 @@ CLASS="replaceable"
 ><B
 CLASS="command"
 >command</B
-> is one of the following
-              for <B
-CLASS="command"
->named</B
->:</P
+> is one of the following:</P
 ><DIV
 CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
 ><TD
-WIDTH="144"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
->&#13;<P
-><TT
-CLASS="userinput"
-><B
->status</B
-></TT
-><SUP
->a</SUP
-></P
-></TD
-><TD
 WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Display ps(1) status of named.</P
-></TD
-></TR
-><TR
-><TD
-WIDTH="144"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
-><P
 ><TT
 CLASS="userinput"
 ><B
->dumpdb</B
+>reload</B
 ></TT
-><A
-HREF="#FTN.nyi1"
->[a]</A
 ></P
 ></TD
 ><TD
@@ -829,19 +803,40 @@ WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Dump database and cache to /var/tmp/named_dump.db.</P
+>Reload configuration file and zones.</P
 ></TD
 ></TR
 ><TR
 ><TD
-WIDTH="144"
+WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
 ><TT
 CLASS="userinput"
 ><B
->reload</B
+>reload <TT
+CLASS="replaceable"
+><I
+>zone</I
+></TT
+> [<SPAN
+CLASS="optional"
+><TT
+CLASS="replaceable"
+><I
+>class</I
+></TT
+> [<SPAN
+CLASS="optional"
+><TT
+CLASS="replaceable"
+><I
+>view</I
+></TT
+></SPAN
+>]</SPAN
+>]</B
 ></TT
 ></P
 ></TD
@@ -850,23 +845,41 @@ WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Reload configuration file and zones.</P
+>Reload the given zone.</P
 ></TD
 ></TR
 ><TR
 ><TD
-WIDTH="144"
+WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
 ><TT
 CLASS="userinput"
 ><B
->stats</B
+>refresh <TT
+CLASS="replaceable"
+><I
+>zone</I
+></TT
+> [<SPAN
+CLASS="optional"
+><TT
+CLASS="replaceable"
+><I
+>class</I
+></TT
+> [<SPAN
+CLASS="optional"
+><TT
+CLASS="replaceable"
+><I
+>view</I
+></TT
+></SPAN
+>]</SPAN
+>]</B
 ></TT
-><A
-HREF="#FTN.nyi1"
->[a]</A
 ></P
 ></TD
 ><TD
@@ -874,23 +887,20 @@ WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Dump statistics to /var/tmp/named.stats.</P
+>Schedule zone maintenance for the given zone.</P
 ></TD
 ></TR
 ><TR
 ><TD
-WIDTH="144"
+WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
 ><TT
 CLASS="userinput"
 ><B
->trace</B
+>stats</B
 ></TT
-><A
-HREF="#FTN.nyi1"
->[a]</A
 ></P
 ></TD
 ><TD
@@ -898,48 +908,20 @@ WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Increment debugging level by one.</P
+>Write server statistics to the statistics file.</P
 ></TD
 ></TR
 ><TR
 ><TD
-WIDTH="144"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
->&#13;<P
-><TT
-CLASS="userinput"
-><B
->notrace</B
-></TT
-><A
-HREF="#FTN.nyi1"
->[a]</A
->
-</P
-></TD
-><TD
 WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Set debugging level to 0.</P
-></TD
-></TR
-><TR
-><TD
-WIDTH="144"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
-><P
 ><TT
 CLASS="userinput"
 ><B
 >querylog</B
 ></TT
-><A
-HREF="#FTN.nyi1"
->[a]</A
 ></P
 ></TD
 ><TD
@@ -952,7 +934,7 @@ VALIGN="MIDDLE"
 ></TR
 ><TR
 ><TD
-WIDTH="144"
+WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
@@ -961,9 +943,6 @@ CLASS="userinput"
 ><B
 >stop</B
 ></TT
-><A
-HREF="#FTN.nyi1"
->[a]</A
 ></P
 ></TD
 ><TD
@@ -971,23 +950,22 @@ WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Stop the server.</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.</P
 ></TD
 ></TR
 ><TR
 ><TD
-WIDTH="144"
+WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
 ><TT
 CLASS="userinput"
 ><B
->restart</B
+>halt</B
 ></TT
-><A
-HREF="#FTN.nyi1"
->[a]</A
 ></P
 ></TD
 ><TD
@@ -995,32 +973,29 @@ WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Restart the server.</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.</P
 ></TD
 ></TR
-><TR
-><TD
-COLSPAN="2"
->Notes:<BR><A
-NAME="FTN.nyi1"
->a</A
->not yet implemented<BR></TD
-></TR
 ></TABLE
 ><P
 ></P
 ></DIV
 ><P
->As noted above, <B
-CLASS="command"
->reload</B
-> is the
-              only command available for <SPAN
+>In <SPAN
 CLASS="acronym"
 >BIND</SPAN
-> 9.0.0. The other
-              commands, and more, are planned to be implemented for
-              future releases.</P
+> 9.1, <B
+CLASS="command"
+>rndc</B
+> does not
+yet support all the commands of the BIND 8 <B
+CLASS="command"
+>ndc</B
+>
+utility.  Additonal commands will be added in future releases.</P
 ><P
 >A configuration file is required, since all
               communication with the server is authenticated with
@@ -1048,14 +1023,14 @@ CLASS="filename"
 >, but limited to
               only three statements, the <B
 CLASS="command"
->options{}</B
+>options</B
 >,
               <B
 CLASS="command"
->key{}</B
+>key</B
 > and <B
 CLASS="command"
->server{}</B
+>server</B
 >
               statements.  These statements are what associate the
               secret keys to the servers with which they are meant to
@@ -1064,7 +1039,7 @@ CLASS="command"
 ><P
 >The <B
 CLASS="command"
->options{}</B
+>options</B
 > statement has two clauses: <B
 CLASS="command"
 >default-server</B
@@ -1086,7 +1061,7 @@ CLASS="command"
 > takes
 the name of key as its argument, as defined by a <B
 CLASS="command"
->key{}</B
+>key</B
 > statement.
  In the future a <B
 CLASS="command"
@@ -1100,7 +1075,7 @@ connect.</P
 ><P
 >The <B
 CLASS="command"
->key{}</B
+>key</B
 > statement names a key with its
 string argument. The string is required by the server to be a valid
 domain name, though it need not actually be hierarchical; thus,
@@ -1112,7 +1087,7 @@ CLASS="userinput"
 >" is a valid name.
 The <B
 CLASS="command"
->key{}</B
+>key</B
 > statement has two clauses: <B
 CLASS="command"
 >algorithm</B
@@ -1138,20 +1113,20 @@ CLASS="command"
 ><P
 >The <B
 CLASS="command"
->server{}</B
+>server</B
 > statement uses the key clause
 to associate a <B
 CLASS="command"
->key{}</B
+>key</B
 >-defined key with a server.
  The argument to the <B
 CLASS="command"
->server{}</B
+>server</B
 > statement is a
 host name or address (addresses must be double quoted).  The argument
 to the key clause is the name of the key as defined by the <B
 CLASS="command"
->key{}</B
+>key</B
 > statement.
  A <B
 CLASS="command"
@@ -1216,7 +1191,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN600"
+NAME="AEN588"
 >3.4.2. Signals</A
 ></H2
 ><P
@@ -1231,6 +1206,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html
index c41336d0..e413a204 100644
--- a/doc/arm/Bv9ARM.ch04.html
+++ b/doc/arm/Bv9ARM.ch04.html
@@ -85,7 +85,7 @@ HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
 ></DT
 ><DT
 >4.3. <A
-HREF="Bv9ARM.ch04.html#AEN654"
+HREF="Bv9ARM.ch04.html#AEN642"
 >Split DNS</A
 ></DT
 ><DT
@@ -95,12 +95,12 @@ HREF="Bv9ARM.ch04.html#tsig"
 ></DT
 ><DT
 >4.5. <A
-HREF="Bv9ARM.ch04.html#AEN816"
+HREF="Bv9ARM.ch04.html#AEN802"
 >TKEY</A
 ></DT
 ><DT
 >4.6. <A
-HREF="Bv9ARM.ch04.html#AEN831"
+HREF="Bv9ARM.ch04.html#AEN817"
 >SIG(0)</A
 ></DT
 ><DT
@@ -110,7 +110,7 @@ HREF="Bv9ARM.ch04.html#DNSSEC"
 ></DT
 ><DT
 >4.8. <A
-HREF="Bv9ARM.ch04.html#AEN915"
+HREF="Bv9ARM.ch04.html#AEN901"
 >IPv6 Support in <SPAN
 CLASS="acronym"
 >BIND</SPAN
@@ -229,7 +229,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN654"
+NAME="AEN642"
 >4.3. Split DNS</A
 ></H1
 ><P
@@ -312,16 +312,10 @@ CLASS="filename"
 >site2.internal</TT
 >.</P
 ><P
->To protect the<TT
+>To protect the <TT
 CLASS="filename"
-> site1.interna</TT
-><I
-CLASS="emphasis"
->l</I
-> and<I
-CLASS="emphasis"
-> </I
-><TT
+>site1.internal</TT
+> and <TT
 CLASS="filename"
 >site2.internal</TT
 > domains,
@@ -445,8 +439,8 @@ CLASS="systemitem"
 > and 
 <SPAN
 CLASS="systemitem"
->site2.example.com </SPAN
->zones.</P
+>site2.example.com</SPAN
+> zones.</P
 ></LI
 ><LI
 ><P
@@ -635,7 +629,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN747"
+NAME="AEN733"
 >4.4.1. Generate Shared Keys for Each Pair of Hosts</A
 ></H2
 ><P
@@ -653,7 +647,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN752"
+NAME="AEN738"
 >4.4.1.1. Automatic Generation</A
 ></H3
 ><P
@@ -695,7 +689,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN763"
+NAME="AEN749"
 >4.4.1.2. Manual Generation</A
 ></H3
 ><P
@@ -716,7 +710,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN768"
+NAME="AEN754"
 >4.4.2. Copying the Shared Secret to Both Machines</A
 ></H2
 ><P
@@ -728,7 +722,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN771"
+NAME="AEN757"
 >4.4.3. Informing the Servers of the Key's Existence</A
 ></H2
 ><P
@@ -776,7 +770,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN783"
+NAME="AEN769"
 >4.4.4. Instructing the Server to Use the Key</A
 ></H2
 ><P
@@ -807,7 +801,7 @@ file.</P
 >If <I
 CLASS="emphasis"
 >host1</I
-> sends a message that is a response
+> sends a message that is a request
 to that address, the message will be signed with the specified key. <I
 CLASS="emphasis"
 >host1</I
@@ -826,7 +820,7 @@ CLASS="emphasis"
 CLASS="emphasis"
 >host2</I
 > to
-sign non-response messages to <I
+sign request messages to <I
 CLASS="emphasis"
 >host1</I
 >.</P
@@ -836,7 +830,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN799"
+NAME="AEN785"
 >4.4.5. TSIG Key Based Access Control</A
 ></H2
 ><P
@@ -847,8 +841,8 @@ CLASS="acronym"
 definitions and
 <B
 CLASS="command"
->allow-{ query | transfer | update } </B
->directives.
+>allow-{ query | transfer | update }</B
+> directives.
 This has been extended to allow TSIG keys also. The above key would
 be denoted <B
 CLASS="command"
@@ -874,7 +868,7 @@ CLASS="command"
 >update-policy</B
 > statement in <A
 HREF="Bv9ARM.ch06.html#dynamic_update_policies"
->Section 6.2.20.4</A
+>Section 6.2.22.4</A
 >.</P
 ></DIV
 ><DIV
@@ -882,7 +876,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN812"
+NAME="AEN798"
 >4.4.6. Errors</A
 ></H2
 ><P
@@ -911,7 +905,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN816"
+NAME="AEN802"
 >4.5. TKEY</A
 ></H1
 ><P
@@ -977,7 +971,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN831"
+NAME="AEN817"
 >4.6. SIG(0)</A
 ></H1
 ><P
@@ -1021,14 +1015,17 @@ CLASS="emphasis"
     of steps which must be followed.  <SPAN
 CLASS="acronym"
 >BIND</SPAN
-> 9 ships with several tools
+> 9 ships
+    with several tools
     that are used in this process, which are explained in more detail
     below.  In all cases, the "<TT
 CLASS="option"
 >-h</TT
 >" option prints a
     full list of parameters.  Note that the DNSSEC tools require the
-    keyset and signedkey files to be in the working directory.</P
+    keyset and signedkey files to be in the working directory, and
+    that the tools shipped with BIND 9.0.x are not fully 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 and signatures.  A
@@ -1043,7 +1040,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN847"
+NAME="AEN833"
 >4.7.1. Generating Keys</A
 ></H2
 ><P
@@ -1114,15 +1111,15 @@ CLASS="command"
 > statements, including the
       <TT
 CLASS="filename"
->.key </TT
->files.</P
+>.key</TT
+> files.</P
 ></DIV
 ><DIV
 CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN867"
+NAME="AEN853"
 >4.7.2. Creating a Keyset</A
 ></H2
 ><P
@@ -1156,14 +1153,14 @@ CLASS="command"
 ><TT
 CLASS="userinput"
 ><B
->dnssec-makekeyset -t 3600 -e +86400 Kchild.example.+003+12345 Kchild.example.+003+23456</B
+>dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</B
 ></TT
 ></P
 ><P
 >One output file is produced:
       <TT
 CLASS="filename"
->child.example.keyset</TT
+>keyset-child.example.</TT
 >.  This file should be
       transmitted to the parent to be signed.  It includes the keys,
       as well as signatures over the key set generated by the zone
@@ -1175,7 +1172,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN879"
+NAME="AEN865"
 >4.7.3. Signing the Child's Keyset</A
 ></H2
 ><P
@@ -1207,14 +1204,14 @@ CLASS="filename"
 ><TT
 CLASS="userinput"
 ><B
->dnssec-signkey grand.child.example.keyset Kchild.example.+003+12345 Kchild.example.+003+23456</B
+>dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</B
 ></TT
 ></P
 ><P
 >One output file is produced:
       <TT
 CLASS="filename"
->grand.child.example.signedkey</TT
+>signedkey-grand.child.example.</TT
 >.  This file
       should be both transmitted back to the child and retained.  It
       includes all keys (the child's keys) from the keyset file and
@@ -1225,7 +1222,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN892"
+NAME="AEN878"
 >4.7.4. Signing the Zone</A
 ></H2
 ><P
@@ -1287,7 +1284,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN908"
+NAME="AEN894"
 >4.7.5. Configuring Servers</A
 ></H2
 ><P
@@ -1314,7 +1311,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN915"
+NAME="AEN901"
 >4.8. IPv6 Support in <SPAN
 CLASS="acronym"
 >BIND</SPAN
@@ -1368,7 +1365,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN929"
+NAME="AEN915"
 >4.8.1. Address Lookups Using AAAA Records</A
 ></H2
 ><P
@@ -1390,7 +1387,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN934"
+NAME="AEN920"
 >4.8.2. Address Lookups Using A6 Records</A
 ></H2
 ><P
@@ -1410,7 +1407,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN938"
+NAME="AEN924"
 >4.8.2.1. A6 Chains</A
 ></H3
 ><P
@@ -1456,7 +1453,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN949"
+NAME="AEN935"
 >4.8.2.2. A6 Records for DNS Servers</A
 ></H3
 ><P
@@ -1486,7 +1483,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN955"
+NAME="AEN941"
 >4.8.3. Address to Name Lookups Using Nibble Format</A
 ></H2
 ><P
@@ -1517,7 +1514,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN962"
+NAME="AEN948"
 >4.8.4. Address to Name Lookups Using Bitstring Format</A
 ></H2
 ><P
@@ -1544,7 +1541,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN969"
+NAME="AEN955"
 >4.8.5. Using DNAME for Delegation of IPv6 Reverse Addresses</A
 ></H2
 ><P
diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html
index bb6f5272..cf6563a5 100644
--- a/doc/arm/Bv9ARM.ch05.html
+++ b/doc/arm/Bv9ARM.ch05.html
@@ -78,12 +78,12 @@ CLASS="TOC"
 ></DT
 ><DT
 >5.1. <A
-HREF="Bv9ARM.ch05.html#AEN989"
+HREF="Bv9ARM.ch05.html#AEN975"
 >The Lightweight Resolver Library</A
 ></DT
 ><DT
 >5.2. <A
-HREF="Bv9ARM.ch05.html#AEN995"
+HREF="Bv9ARM.ch05.html#lwresd"
 >Running a Resolver Daemon</A
 ></DT
 ></DL
@@ -93,7 +93,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN989"
+NAME="AEN975"
 >5.1. The Lightweight Resolver Library</A
 ></H1
 ><P
@@ -120,7 +120,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN995"
+NAME="lwresd"
 >5.2. Running a Resolver Daemon</A
 ></H1
 ><P
@@ -130,18 +130,27 @@ CLASS="command"
 >lwresd</B
 >.</P
 ><P
->Applications using the lightweight resolver library will make
-UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.
- The daemon will try to find the answer to the questions "what are the
-addresses for host <SPAN
+>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 overriden by <B
+CLASS="command"
+>lwserver</B
+> lines in
+<TT
+CLASS="filename"
+>/etc/resolv.conf</TT
+>.
+The daemon will try to find the answer to the questions "what are the
+addresses for host
+<SPAN
 CLASS="systemitem"
 >foo.example.com</SPAN
 >?" and "what are
-the names for IPv4 address 204.152.184.79?"</P
+the names for IPv4 address 10.1.2.3?"</P
 ><P
 >The daemon currently only looks in the DNS, but in the future
 it may use other sources such as <TT
-CLASS="literal"
+CLASS="filename"
 >/etc/hosts</TT
 >,
 NIS, etc.</P
@@ -149,19 +158,41 @@ NIS, etc.</P
 >The <B
 CLASS="command"
 >lwresd</B
-> daemon is essentially a stripped-down,
+> daemon is essentially a
 caching-only name server that answers 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.
- It uses the name servers listed on <B
+Unless configured otherwise, it uses the name servers listed on
+<B
 CLASS="command"
 >nameserver</B
-> lines
-in <TT
+> lines in <TT
 CLASS="filename"
 >/etc/resolv.conf</TT
-> as forwarders, but is also
-capable of doing the resolution autonomously if none are specified.</P
+>
+as forwarders, but is also capable of doing the resolution autonomously if
+none are specified.</P
+><P
+>The <B
+CLASS="command"
+>lwresd</B
+> daemon may also be configured with a
+<TT
+CLASS="filename"
+>named.conf</TT
+> style configuration file, in
+<TT
+CLASS="filename"
+>/etc/lwresd.conf</TT
+> by default.  A name server may also
+be configured to act as a lightweight resolver daemon using the
+<B
+CLASS="command"
+>lwres</B
+> statement in <TT
+CLASS="filename"
+>named.conf</TT
+>.</P
 ></DIV
 ></DIV
 ><DIV
diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html
index 43c82d6b..266cb0bd 100644
--- a/doc/arm/Bv9ARM.ch06.html
+++ b/doc/arm/Bv9ARM.ch06.html
@@ -88,7 +88,7 @@ HREF="Bv9ARM.ch06.html#Configuration_File_Grammar"
 ></DT
 ><DT
 >6.3. <A
-HREF="Bv9ARM.ch06.html#AEN3213"
+HREF="Bv9ARM.ch06.html#AEN3338"
 >Zone File</A
 ></DT
 ></DL
@@ -144,6 +144,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -191,22 +192,13 @@ VALIGN="MIDDLE"
 >A list of one or more <TT
 CLASS="varname"
 >ip_addr</TT
-><B
-CLASS="command"
->, </B
-><TT
+>, <TT
 CLASS="varname"
 >ip_prefix</TT
-><B
-CLASS="command"
->, </B
-><TT
+>, <TT
 CLASS="varname"
 >key_id</TT
-><B
-CLASS="command"
->, </B
->or <TT
+>, or <TT
 CLASS="varname"
 >acl_name</TT
 > elements, see
@@ -332,10 +324,7 @@ VALIGN="MIDDLE"
 >An <TT
 CLASS="varname"
 >ip4_addr</TT
-> or<B
-CLASS="command"
-> </B
-><TT
+> or <TT
 CLASS="varname"
 >ip6_addr</TT
 >.</P
@@ -570,10 +559,7 @@ CLASS="userinput"
 ><B
 >k</B
 ></TT
-><B
-CLASS="command"
-> </B
->for
+> for
 kilobytes, <TT
 CLASS="userinput"
 ><B
@@ -659,6 +645,76 @@ CLASS="userinput"
 >.</P
 ></TD
 ></TR
+><TR
+><TD
+WIDTH="178"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><TT
+CLASS="varname"
+>dialup_option</TT
+></P
+></TD
+><TD
+WIDTH="362"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>One of <TT
+CLASS="userinput"
+><B
+>yes</B
+></TT
+>,
+<TT
+CLASS="userinput"
+><B
+>no</B
+></TT
+>, <TT
+CLASS="userinput"
+><B
+>notify</B
+></TT
+>,
+<TT
+CLASS="userinput"
+><B
+>notify-passive</B
+></TT
+>, <TT
+CLASS="userinput"
+><B
+>refresh</B
+></TT
+> or
+<TT
+CLASS="userinput"
+><B
+>passive</B
+></TT
+>.
+When used in a zone, <TT
+CLASS="userinput"
+><B
+>notify-passive</B
+></TT
+>,
+<TT
+CLASS="userinput"
+><B
+>refresh</B
+></TT
+>, and <TT
+CLASS="userinput"
+><B
+>passive</B
+></TT
+>
+are restricted to slave and stub zones.</P
+></TD
+></TR
 ></TABLE
 ><P
 ></P
@@ -676,7 +732,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN1176"
+NAME="AEN1180"
 >6.1.1.1. Syntax</A
 ></H3
 ><PRE
@@ -707,7 +763,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN1184"
+NAME="AEN1188"
 >6.1.1.2. Definition and Usage</A
 ></H3
 ><P
@@ -813,7 +869,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1212"
+NAME="AEN1216"
 >6.1.2. Comment Syntax</A
 ></H2
 ><P
@@ -832,7 +888,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN1217"
+NAME="AEN1221"
 >6.1.2.1. Syntax</A
 ></H3
 ><P
@@ -864,7 +920,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN1226"
+NAME="AEN1230"
 >6.1.2.2. Definition and Usage</A
 ></H3
 ><P
@@ -976,6 +1032,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -1196,7 +1253,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1319"
+NAME="AEN1323"
 >6.2.1. <B
 CLASS="command"
 >acl</B
@@ -1245,6 +1302,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -1335,7 +1393,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1361"
+NAME="AEN1365"
 >6.2.3. <B
 CLASS="command"
 >controls</B
@@ -1374,7 +1432,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1370"
+NAME="AEN1374"
 >6.2.4. <B
 CLASS="command"
 >controls</B
@@ -1453,20 +1511,14 @@ HREF="Bv9ARM.ch03.html#rndc"
 ><I
 >Remote Name Daemon Control application</I
 ></A
-> in <A
+> in
+      <A
 HREF="Bv9ARM.ch03.html#admin_tools"
 >Section 3.4.1.2</A
->). All commands to the
-      control channel must be signed by one of its specified keys to
+>). All commands to the control channel
+      must be signed by one of its specified keys to
       be honored.</P
 ><P
-> For the initial release of <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.0.0, only one command
-      is possible over the command channel, the command to reload the
-      server.  We will expand command set in future releases.</P
-><P
 >The UNIX control channel type of <SPAN
 CLASS="acronym"
 >BIND</SPAN
@@ -1487,7 +1539,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1398"
+NAME="AEN1400"
 >6.2.5. <B
 CLASS="command"
 >include</B
@@ -1507,7 +1559,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1403"
+NAME="AEN1405"
 >6.2.6. <B
 CLASS="command"
 >include</B
@@ -1537,7 +1589,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1410"
+NAME="AEN1412"
 >6.2.7. <B
 CLASS="command"
 >key</B
@@ -1571,7 +1623,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1417"
+NAME="AEN1419"
 >6.2.8. <B
 CLASS="command"
 >key</B
@@ -1625,7 +1677,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1429"
+NAME="AEN1431"
 >6.2.9. <B
 CLASS="command"
 >logging</B
@@ -1679,15 +1731,19 @@ CLASS="replaceable"
        | <B
 CLASS="command"
 >syslog</B
-> ( <TT
+> <TT
 CLASS="replaceable"
 ><I
 >syslog_facility</I
 ></TT
-> )
-       | <TT
-CLASS="literal"
->null</TT
+>
+       | <B
+CLASS="command"
+>stderr</B
+>
+       | <B
+CLASS="command"
+>null</B
 > );
      [ <B
 CLASS="command"
@@ -1781,7 +1837,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1468"
+NAME="AEN1471"
 >6.2.10. <B
 CLASS="command"
 >logging</B
@@ -1820,7 +1876,7 @@ CLASS="command"
 >logging</B
 > {
      category "default" { "default_syslog"; "default_debug"; };
-	};
+};
 </PRE
 ><P
 >In <SPAN
@@ -1847,7 +1903,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN1485"
+NAME="AEN1488"
 >6.2.10.1. The <B
 CLASS="command"
 >channel</B
@@ -1860,31 +1916,33 @@ CLASS="emphasis"
 >;
 you can make as many of them as you want.</P
 ><P
->Every channel definition must include a clause that says whether
-messages selected for the channel go to a file, to a particular
-syslog facility, or are discarded. It can optionally also limit
-the message severity level that will be accepted by the channel
-(the default is <B
+>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
+<B
 CLASS="command"
 >info</B
->), and whether to include
-a <B
+>), and whether to include a
+<B
 CLASS="command"
 >named</B
 >-generated time stamp, the category name
 and/or severity level (the default is not to include any).</P
 ><P
->The word <B
+>The <B
 CLASS="command"
 >null</B
-> as the destination option
-for the channel will cause all messages sent to it to be discarded;
+> 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 <B
 CLASS="command"
 >file</B
-> clause can include limitations
+> 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
@@ -1955,12 +2013,13 @@ CLASS="programlisting"
     print-time yes;
     print-category yes;
 };
-        </PRE
+</PRE
 ><P
->The argument for the <B
+>The <B
 CLASS="command"
 >syslog</B
-> clause is a
+> destination clause directs the
+channel to the system log.  Its argument is a
 syslog facility as described in the <B
 CLASS="command"
 >syslog</B
@@ -2041,6 +2100,14 @@ CLASS="command"
 > would
 print all messages it received from the channel.</P
 ><P
+>The <B
+CLASS="command"
+>stderr</B
+> 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
@@ -2159,11 +2226,7 @@ channel "default_debug" {
 					// current debug level
 };
 channel "default_stderr" {		// writes to stderr
-    file "&#60;stderr&#62;";			// this is illustrative only;
-					// there's currently no way of
-					// specifying an internal file
-					// descriptor in the 
-					// configuration language.
+    stderr;
     severity info;			// only send priority info
 					// and higher
 };
@@ -2270,6 +2333,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -2505,6 +2569,25 @@ VALIGN="MIDDLE"
 >Dynamic updates.</P
 ></TD
 ></TR
+><TR
+><TD
+WIDTH="110"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>queries</B
+></P
+></TD
+><TD
+WIDTH="322"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>Queries.</P
+></TD
+></TR
 ></TABLE
 ><P
 ></P
@@ -2516,9 +2599,155 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1662"
+NAME="AEN1673"
 >6.2.11. <B
 CLASS="command"
+>lwres</B
+> Statement Grammar</A
+></H2
+><P
+> This is the grammar of the <B
+CLASS="command"
+>lwres</B
+>
+      statement in the <TT
+CLASS="filename"
+>named.conf</TT
+> file:</P
+><PRE
+CLASS="programlisting"
+><B
+CLASS="command"
+>lwres</B
+> {
+    [<SPAN
+CLASS="optional"
+> listen-on { <TT
+CLASS="replaceable"
+><I
+>address_match_list</I
+></TT
+> }; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> view <TT
+CLASS="replaceable"
+><I
+>view_name</I
+></TT
+>; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> search { <TT
+CLASS="replaceable"
+><I
+>domain_name</I
+></TT
+> ; [<SPAN
+CLASS="optional"
+> <TT
+CLASS="replaceable"
+><I
+>ip_addr</I
+></TT
+> ; ... </SPAN
+>] }; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> ndots <TT
+CLASS="replaceable"
+><I
+>number</I
+></TT
+>; </SPAN
+>]
+};
+</PRE
+></DIV
+><DIV
+CLASS="sect2"
+><H2
+CLASS="sect2"
+><A
+NAME="AEN1691"
+>6.2.12. <B
+CLASS="command"
+>lwres</B
+> Statement Definition and Usage</A
+></H2
+><P
+>The <B
+CLASS="command"
+>lwres</B
+> statement configures the name
+      server to also act as a lightweight resolver server, see
+      <A
+HREF="Bv9ARM.ch05.html#lwresd"
+>Section 5.2</A
+>.  There may be be multiple
+      <B
+CLASS="command"
+>lwres</B
+> statements configuring
+      lightweight resolver servers with different properties.</P
+><P
+>The <B
+CLASS="command"
+>listen-on</B
+> statement specifies a list of
+      addresses (and ports) that this instance of a lightweight resolver daemon
+      should accept requests on.  If this statement is omitted, requests
+      will be accepted on 127.0.0.1, port 53.</P
+><P
+>The <B
+CLASS="command"
+>view</B
+> 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 <B
+CLASS="command"
+>search</B
+> statement is equivalent to the
+      <B
+CLASS="command"
+>search</B
+> statement in
+      <TT
+CLASS="filename"
+>/etc/resolv.conf</TT
+>.  It provides a list of domains
+      which are appended to relative names in queries.</P
+><P
+>The <B
+CLASS="command"
+>ndots</B
+> statement is equivalent to the
+      <B
+CLASS="command"
+>ndots</B
+> statement in
+      <TT
+CLASS="filename"
+>/etc/resolv.conf</TT
+>.  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"
+><H2
+CLASS="sect2"
+><A
+NAME="AEN1710"
+>6.2.13. <B
+CLASS="command"
 >options</B
 > Statement Grammar</A
 ></H2
@@ -2625,6 +2854,15 @@ CLASS="replaceable"
 >]
     [<SPAN
 CLASS="optional"
+> zone-statistics <TT
+CLASS="replaceable"
+><I
+>yes_or_no</I
+></TT
+>; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
 > auth-nxdomain <TT
 CLASS="replaceable"
 ><I
@@ -2646,7 +2884,7 @@ CLASS="optional"
 > dialup <TT
 CLASS="replaceable"
 ><I
->yes_or_no</I
+>dialup_option</I
 ></TT
 >; </SPAN
 >]
@@ -2702,6 +2940,11 @@ CLASS="replaceable"
 ><I
 >yes_or_no</I
 ></TT
+> | <TT
+CLASS="replaceable"
+><I
+>explicit</I
+></TT
 >; </SPAN
 >]
     [<SPAN
@@ -3009,21 +3252,83 @@ CLASS="replaceable"
 >]
     [<SPAN
 CLASS="optional"
-> transfer-source <TT
+> transfer-source (<TT
 CLASS="replaceable"
 ><I
 >ip4_addr</I
 ></TT
->; </SPAN
+> | <TT
+CLASS="constant"
+>*</TT
+>) [<SPAN
+CLASS="optional"
+>port <TT
+CLASS="replaceable"
+><I
+>ip_port</I
+></TT
+></SPAN
+>] ; </SPAN
 >]
     [<SPAN
 CLASS="optional"
-> transfer-source-v6 <TT
+> transfer-source-v6 (<TT
 CLASS="replaceable"
 ><I
 >ip6_addr</I
 ></TT
->; </SPAN
+> | <TT
+CLASS="constant"
+>*</TT
+>) [<SPAN
+CLASS="optional"
+>port <TT
+CLASS="replaceable"
+><I
+>ip_port</I
+></TT
+></SPAN
+>] ; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> notify-source (<TT
+CLASS="replaceable"
+><I
+>ip4_addr</I
+></TT
+> | <TT
+CLASS="constant"
+>*</TT
+>) [<SPAN
+CLASS="optional"
+>port <TT
+CLASS="replaceable"
+><I
+>ip_port</I
+></TT
+></SPAN
+>] ; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> notify-source-v6 (<TT
+CLASS="replaceable"
+><I
+>ip6_addr</I
+></TT
+> | <TT
+CLASS="constant"
+>*</TT
+>) [<SPAN
+CLASS="optional"
+>port <TT
+CLASS="replaceable"
+><I
+>ip_port</I
+></TT
+></SPAN
+>] ; </SPAN
 >]
     [<SPAN
 CLASS="optional"
@@ -3282,6 +3587,33 @@ CLASS="replaceable"
 ></TT
 > ; </SPAN
 >]
+    [<SPAN
+CLASS="optional"
+> port <TT
+CLASS="replaceable"
+><I
+>ip_port</I
+></TT
+>; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> additional-from-auth <TT
+CLASS="replaceable"
+><I
+>yes_or_no</I
+></TT
+> ; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> additional-from-cache <TT
+CLASS="replaceable"
+><I
+>yes_or_no</I
+></TT
+> ; </SPAN
+>]
 };
 </PRE
 ></DIV
@@ -3290,8 +3622,8 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN1838"
->6.2.12. <B
+NAME="AEN1911"
+>6.2.14. <B
 CLASS="command"
 >options</B
 > Statement Definition and
@@ -3317,6 +3649,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -3506,26 +3839,24 @@ ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
 >The pathname of the file the server dumps
-the database to when it receives <B
-CLASS="command"
->SIGINT</B
-> signal
-(<B
+the database to when instructed to do so with
+<B
 CLASS="command"
->ndc dumpdb</B
->). If not specified, the default is <TT
+>rndc dumpdb</B
+>.
+If not specified, the default is <TT
 CLASS="filename"
 >named_dump.db</TT
 >.</P
-><DIV
+>
+<DIV
 CLASS="note"
 ><BLOCKQUOTE
 CLASS="note"
 ><P
 ><B
 >Note: </B
->Not
-yet implemented in <SPAN
+>Not yet implemented in <SPAN
 CLASS="acronym"
 >BIND</SPAN
 > 9.</P
@@ -3554,15 +3885,15 @@ usage statistics to on exit. If not specified, the default is <TT
 CLASS="filename"
 >named.memstats</TT
 >.</P
-><DIV
+>
+<DIV
 CLASS="note"
 ><BLOCKQUOTE
 CLASS="note"
 ><P
 ><B
 >Note: </B
->Not
-yet implemented in <SPAN
+>Not yet implemented in <SPAN
 CLASS="acronym"
 >BIND</SPAN
 > 9.</P
@@ -3617,25 +3948,51 @@ ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
 >The pathname of the file the server appends statistics
-to. If not specified, the default is <TT
+to when instructed to do so using <B
+CLASS="command"
+>rndc stats</B
+>.
+If not specified, the default is <TT
 CLASS="filename"
 >named.stats</TT
->.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
+> in the
+server's current directory.  The format of the file is described
+in <A
+HREF="Bv9ARM.ch06.html#statsfile"
+>Section 6.2.14.13</A
+></P
+></TD
+></TR
+><TR
+><TD
+WIDTH="153"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
 ><P
 ><B
->Note: </B
->Not
-yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
+CLASS="command"
+>port</B
+></P
 ></TD
+><TD
+WIDTH="303"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>&#13;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.
+The <B
+CLASS="command"
+>port</B
+> option should be placed at
+the beginning of the options block, before
+any other options that take port numbers or IP addresses,
+to ensure that the port value takes effect for all addresses
+used by the server.</P
+>
+</TD
 ></TR
 ></TABLE
 ><P
@@ -3648,13 +4005,14 @@ CLASS="sect3"
 CLASS="sect3"
 ><A
 NAME="boolean_options"
->6.2.12.1. Boolean Options</A
+>6.2.14.1. Boolean Options</A
 ></H3
 ><DIV
 CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -3765,48 +4123,74 @@ CLASS="userinput"
 >no</B
 ></TT
 >.</P
-><P
+>
+<P
 >The <B
 CLASS="command"
 >dialup</B
 > option
 may also be specified in the <B
 CLASS="command"
+>view</B
+> and 
+<B
+CLASS="command"
 >zone</B
-> statement,
-in which case it overrides the <B
+> statements,
+in which case it overrides the global <B
 CLASS="command"
->options dialup </B
->statement.</P
+>dialup</B
+>
+option.</P
 ><P
 >If
-the zone is a master then the server will send out a NOTIFY request
+the zone is a master zone then the server will send out a NOTIFY request
 to all the slaves. This will 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.</P
 ><P
 >If the
-zone is a slave or stub then the server will suppress the regular
-"zone up to date" queries and only perform them when 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
 <B
 CLASS="command"
 >heartbeat-interval</B
-> expires.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
+> expires in addition to sending
+NOTIFY requests.</P
 ><P
+>Finer control can be achieved by using
+<TT
+CLASS="userinput"
 ><B
->Note: </B
->Not yet implemented
-in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
-></TD
+>notify</B
+></TT
+> which only sends NOTIFY messages,
+<TT
+CLASS="userinput"
+><B
+>notify-passive</B
+></TT
+> which sends NOTIFY messages and
+suppresses the normal refresh queries, <TT
+CLASS="userinput"
+><B
+>refresh</B
+></TT
+>
+which suppresses normal refresh processing and send refresh queries 
+when the <B
+CLASS="command"
+>heartbeat-interval</B
+> expires and
+<TT
+CLASS="userinput"
+><B
+>passive</B
+></TT
+> which just disables normal refresh
+processing.</P
+>
+</TD
 ></TR
 ><TR
 ><TD
@@ -3850,59 +4234,19 @@ WIDTH="287"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->(Information present outside of the authoritative
-nodes in the zone is called <I
-CLASS="emphasis"
->glue</I
-> information).
-If <TT
+>This option is obsolete.
+In BIND 8, <TT
 CLASS="userinput"
 ><B
->yes</B
+>fetch-glue yes</B
 ></TT
-> (the default), the server will fetch
-glue resource records it doesn't have when constructing the additional
-data section of a response. <B
-CLASS="command"
->fetch-glue </B
-><TT
-CLASS="userinput"
-><B
->no</B
-></TT
-><B
-CLASS="command"
-> </B
->can
-be used in conjunction with <B
-CLASS="command"
->recursion </B
-><TT
-CLASS="userinput"
-><B
->no</B
-></TT
-><B
-CLASS="command"
-> </B
->to
-prevent the server's cache from growing or becoming corrupted (at
-the cost of requiring more work from the client).</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet
-implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
-></TD
+>
+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
+>
+</TD
 ></TR
 ><TR
 ><TD
@@ -3927,12 +4271,13 @@ CLASS="acronym"
 > 8, and is ignored by <SPAN
 CLASS="acronym"
 >BIND</SPAN
-> 9.  To achieve the intended effect
+> 9.
+To achieve the intended effect
 of
 <B
 CLASS="command"
->has-old-clients </B
-><TT
+>has-old-clients</B
+> <TT
 CLASS="userinput"
 ><B
 >yes</B
@@ -3940,16 +4285,16 @@ CLASS="userinput"
 >, specify
 the two separate options <B
 CLASS="command"
->auth-nxdomain </B
-><TT
+>auth-nxdomain</B
+> <TT
 CLASS="userinput"
 ><B
 >yes</B
 ></TT
 > and <B
 CLASS="command"
->rfc2308-type1 </B
-><TT
+>rfc2308-type1</B
+> <TT
 CLASS="userinput"
 ><B
 >no</B
@@ -3973,46 +4318,9 @@ WIDTH="287"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->If <TT
-CLASS="userinput"
-><B
->yes</B
-></TT
->, then statistics
-are kept for every host that the nameserver interacts with. The
-default is <TT
-CLASS="userinput"
-><B
->no</B
-></TT
->.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->turning on <B
-CLASS="command"
->host-statistics</B
-> can consume
-huge amounts of memory.</P
-></BLOCKQUOTE
-></DIV
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
+>In BIND 8, this enables keeping of
+statistics for every host that the nameserver interacts with.
+Not implemented in BIND 9.</P
 ></TD
 ></TR
 ><TR
@@ -4046,8 +4354,8 @@ CLASS="acronym"
 log whenever possible.  If you need to disable outgoing incremental zone
 transfers, use <B
 CLASS="command"
->provide-ixfr </B
-><TT
+>provide-ixfr</B
+> <TT
 CLASS="userinput"
 ><B
 >no</B
@@ -4079,13 +4387,8 @@ a domain name to allow multiple CNAME records in violation of the
 DNS standards.  <SPAN
 CLASS="acronym"
 >BIND</SPAN
-> 9 currently does not check for multiple CNAMEs
-in zone data loaded from master files, but such checks may be introduced
-in a later release.  <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9 always strictly enforces the CNAME rules
-in dynamic updates.</P
+> 9.1 always strictly
+enforces the CNAME rules both in master files and dynamic updates.</P
 ></TD
 ></TR
 ><TR
@@ -4114,8 +4417,34 @@ DNS NOTIFY messages are sent when a zone the server is authoritative for
 changes, see <A
 HREF="Bv9ARM.ch03.html#notify"
 >Section 3.3</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
+<B
+CLASS="command"
+>also-notify</B
+> option.
+</P
+><P
+>&#13;If <TT
+CLASS="userinput"
+><B
+>explicit</B
+></TT
+>, notifies are sent only to
+servers explicitly listed using <B
+CLASS="command"
+>also-notify</B
 >.
-The <B
+If <TT
+CLASS="userinput"
+><B
+>no</B
+></TT
+>, no notifies are sent.
+</P
+><P
+>&#13;The <B
 CLASS="command"
 >notify</B
 > option may also be specified in the <B
@@ -4257,6 +4586,77 @@ VALIGN="MIDDLE"
 ><P
 ><B
 CLASS="command"
+>zone-statistics</B
+></P
+></TD
+><TD
+WIDTH="287"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>If <TT
+CLASS="userinput"
+><B
+>yes</B
+></TT
+>, the server will, by default, collect
+statistical data on all zones in the server.  These statistics may be accessed
+using <B
+CLASS="command"
+>rndc stats</B
+>, which will dump them to the file listed
+in the <B
+CLASS="command"
+>statistics-file</B
+>.  See also <A
+HREF="Bv9ARM.ch06.html#statsfile"
+>Section 6.2.14.13</A
+>.</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="145"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>use-ixfr</B
+></P
+></TD
+><TD
+WIDTH="287"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+></P
+><I
+CLASS="emphasis"
+>This option is obsolete</I
+>.
+If you need to disable IXFR to a particular server or servers see
+the information on the <B
+CLASS="command"
+>provide-ixfr</B
+> option
+in <A
+HREF="Bv9ARM.ch06.html#server_statement_definition_and_usage"
+>Section 6.2.16</A
+>. See also
+<A
+HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
+>Section 4.2</A
+>.</TD
+></TR
+><TR
+><TD
+WIDTH="145"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
 >treat-cr-as-space</B
 ></P
 ></TD
@@ -4269,17 +4669,11 @@ VALIGN="MIDDLE"
 CLASS="acronym"
 >BIND</SPAN
 > 8 to make
-the server treat "<B
+the server treat carriage return ("<B
 CLASS="command"
 >\r</B
->" characters the same way
-as <B
-CLASS="command"
->&#60;space&#62; </B
->" " or "<B
-CLASS="command"
->\t</B
->",
+>") 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 <SPAN
 CLASS="acronym"
@@ -4339,23 +4733,73 @@ control over their contents.
 ><P
 >&#13;These options allow the administrator to set a minimum and maximum
 refresh and retry time either per-zone, per-view, or per-server.
-These options are valid for slave and stub zones, and clamp the SOA
+These options are valid for master, slave and stub zones, and clamp the SOA
 refresh and retry times to the specified values.
 </P
 >
-<DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
+</TD
+></TR
+><TR
+><TD
+WIDTH="145"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+>&#13;<P
+><B
+CLASS="command"
+>additional-from-auth</B
+></P
+>
+<P
+><B
+CLASS="command"
+>additional-from-cache</B
+></P
+>
+</TD
+><TD
+WIDTH="287"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>&#13;These options control the server's behavior when answering queries
+which have additional data, or when following CNAME and DNAME
+chains to provide additional data.
+</P
 ><P
+>&#13;When both of these options are set to <TT
+CLASS="userinput"
 ><B
->Note: </B
->These options are not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.0.</P
-></BLOCKQUOTE
-></DIV
+>yes</B
+></TT
+> 
+(the default) and a
+query is being answered from authoratitive data (a zone
+configured into the server), the additional data section of the
+reply will be filled in using data from other authoratitive 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
+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
+>&#13;For example, if a query asks for an MX record for host <TT
+CLASS="literal"
+>foo.example.com</TT
+>,
+and the record found is "<TT
+CLASS="literal"
+>MX 10 mail.example.net</TT
+>", normally the address
+records (A, A6, and AAAA) for <TT
+CLASS="literal"
+>mail.example.net</TT
+> will be provided as well,
+if known.  These options disable this behavior.
+</P
 >
 </TD
 ></TR
@@ -4369,8 +4813,8 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN2125"
->6.2.12.2. Forwarding</A
+NAME="AEN2223"
+>6.2.14.2. Forwarding</A
 ></H3
 ><P
 >The forwarding facility can be used to create a large site-wide
@@ -4386,6 +4830,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -4453,7 +4898,7 @@ CLASS="command"
 > behavior,
 or not forward at all, see <A
 HREF="Bv9ARM.ch06.html#zone_statement_grammar"
->Section 6.2.19</A
+>Section 6.2.21</A
 >.</P
 ></DIV
 ><DIV
@@ -4461,144 +4906,8 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="name_checking"
->6.2.12.3. Name Checking</A
-></H3
-><P
->The server can check domain names based upon their expected
-client contexts. For example, a domain name used as a hostname can
-be checked for compliance with the RFCs defining valid hostnames.</P
-><P
->Three checking methods are available:</P
-><P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><TABLE
-BORDER="1"
-CLASS="CALSTABLE"
-><TR
-><TD
-WIDTH="77"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
-><P
-><B
-CLASS="command"
->ignore</B
-></P
-></TD
-><TD
-WIDTH="355"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
-><P
->No checking is done.</P
-></TD
-></TR
-><TR
-><TD
-WIDTH="77"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
-><P
-><B
-CLASS="command"
->warn</B
-></P
-></TD
-><TD
-WIDTH="355"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
-><P
->Names are checked against their expected
-client contexts. Invalid names are logged, but processing continues normally.</P
-></TD
-></TR
-><TR
-><TD
-WIDTH="77"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
-><P
-><B
-CLASS="command"
->fail</B
-></P
-></TD
-><TD
-WIDTH="355"
-ALIGN="LEFT"
-VALIGN="MIDDLE"
-><P
->Names are checked against their expected
-client contexts. Invalid names are logged, and the offending data
-is rejected.</P
-></TD
-></TR
-></TABLE
-><P
-></P
-></DIV
-></P
-><P
->The server can check names in three areas: master zone files,
-slave zone files, and in responses to queries the server has initiated.
-If <B
-CLASS="command"
->check-names response fail</B
-> has been specified,
-and answering the client's question would require sending an invalid
-name to the client, the server will send a REFUSED response code
-to the client.</P
-><P
->The defaults are:</P
-><PRE
-CLASS="programlisting"
->    check-names master fail;
-    check-names slave warn;
-    check-names response ignore;
-</PRE
-><P
-><B
-CLASS="command"
->check-names</B
-> may also be specified in the <B
-CLASS="command"
->zone</B
-> statement,
-in which case it overrides the <B
-CLASS="command"
->options check-names</B
-> statement.
-When used in a <B
-CLASS="command"
->zone</B
-> statement, the area is not
-specified because it can be deduced from the zone type.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Name checking is not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
 NAME="access_control"
->6.2.12.4. Access Control</A
+>6.2.14.3. Access Control</A
 ></H3
 ><P
 >Access to the server can be restricted based on the IP address
@@ -4613,6 +4922,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -4727,20 +5037,6 @@ CLASS="userinput"
 >none</B
 ></TT
 >.</P
->
-<DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
 ></TD
 ></TR
 ></TABLE
@@ -4754,8 +5050,8 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN2235"
->6.2.12.5. Interfaces</A
+NAME="AEN2290"
+>6.2.14.4. Interfaces</A
 ></H3
 ><P
 >The interfaces and ports that the server will answer queries
@@ -4840,8 +5136,8 @@ CLASS="programlisting"
 ><P
 >If no <B
 CLASS="command"
->listen-on-v6 </B
->statement is specified,
+>listen-on-v6</B
+> statement is specified,
 the server will not listen on any IPv6 address.</P
 ></DIV
 ><DIV
@@ -4849,8 +5145,8 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN2261"
->6.2.12.6. Query Address</A
+NAME="AEN2316"
+>6.2.14.5. Query Address</A
 ></H3
 ><P
 >If the server doesn't know the answer to a question, it will
@@ -4909,7 +5205,7 @@ CLASS="sect3"
 CLASS="sect3"
 ><A
 NAME="zone_transfers"
->6.2.12.7. Zone Transfers</A
+>6.2.14.6. Zone Transfers</A
 ></H3
 ><P
 ><SPAN
@@ -4923,6 +5219,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -4941,9 +5238,10 @@ WIDTH="264"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Defines a global list of IP addresses
+>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. This helps to ensure that copies of the zones will
+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 <B
 CLASS="command"
 >also-notify</B
@@ -5075,46 +5373,20 @@ servers to find out if zone serial numbers have changed. Each such
 query uses a minute amount of the slave server's network bandwidth,
 but more importantly each query uses a small amount of memory in
 the slave server while waiting for the master server to respond.
-The <B
+In BIND 8, the <B
 CLASS="command"
->serial-queries </B
->option sets the maximum number
+>serial-queries</B
+> option set the maximum number
 of concurrent serial-number queries allowed to be outstanding at
-any given time. The default is 4.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->If a server loads a large (tens or
-                    hundreds of thousands) number of slave zones, then
-                    this limit should be raised to the high hundreds
-                    or low thousands, otherwise the slave server may
-                    never actually become aware of zone changes in the
-                    master servers. Beware, though, that setting this
-                    limit arbitrarily high can spend a considerable
-                    amount of your slave server's network, CPU, and
-                    memory resources. As with all tunable limits, this
-                    one should be changed gently and monitored for its
-                    effects.</P
-></BLOCKQUOTE
-></DIV
->
-<DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
+any given time.  BIND 9 does not limit the number of outstanding
+serial queries and ignores the The <B
+CLASS="command"
+>serial-queries</B
+> option;
+instead, it limits the rate at which the queries are sent.
+The maximum rate is currently fixed at 20 queries
+per second but may become configurable in a future release.  
+</P
 >
 </TD
 ></TR
@@ -5282,7 +5554,9 @@ CLASS="command"
 >transfer-source</B
 > determines
 which local address will be bound to IPv4 TCP connections used to
-fetch zones transferred inbound by the server. If not set, it defaults
+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 <B
@@ -5294,11 +5568,15 @@ sets the <B
 CLASS="command"
 >transfer-source</B
 > for all zones, but can
-be overridden on a per-zone basis by including a
+be overridden on a per-view or per-zone basis by including a
 <B
 CLASS="command"
 >transfer-source</B
-> statement within the <B
+> statement within the
+<B
+CLASS="command"
+>view</B
+> or <B
 CLASS="command"
 >zone</B
 > block
@@ -5328,6 +5606,74 @@ CLASS="command"
 except zone transfers are performed using IPv6.</P
 ></TD
 ></TR
+><TR
+><TD
+WIDTH="168"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>notify-source</B
+></P
+></TD
+><TD
+WIDTH="264"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>notify-source</B
+> 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 <B
+CLASS="command"
+>masters</B
+>
+zone clause.
+This statement sets the <B
+CLASS="command"
+>notify-source</B
+> for all zones,
+but can be overridden on a per-zone / per-view basis by including a
+<B
+CLASS="command"
+>notify-source</B
+> statement within the <B
+CLASS="command"
+>zone</B
+>
+or <B
+CLASS="command"
+>view</B
+> block in the configuration file.</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="168"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>notify-source-v6</B
+></P
+></TD
+><TD
+WIDTH="264"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>Like <B
+CLASS="command"
+>notify-source</B
+>,
+but applies to notify messages sent to IPv6 addresses.</P
+></TD
+></TR
 ></TABLE
 ><P
 ></P
@@ -5338,8 +5684,8 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN2391"
->6.2.12.8. Resource Limits</A
+NAME="AEN2462"
+>6.2.14.7. Resource Limits</A
 ></H3
 ><P
 >The server's usage of many system resources can be
@@ -5380,6 +5726,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -5403,20 +5750,6 @@ is <TT
 CLASS="literal"
 >default</TT
 >.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
->
-9.</P
-></BLOCKQUOTE
-></DIV
 ></TD
 ></TR
 ><TR
@@ -5440,20 +5773,6 @@ may use. The default is <TT
 CLASS="literal"
 >default</TT
 >.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not
-yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
 ></TD
 ></TR
 ><TR
@@ -5478,52 +5797,6 @@ CLASS="literal"
 >unlimited</TT
 >.
 </P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->on some operating systems the server cannot set an unlimited
-value and cannot determine the maximum number of open files the
-kernel can support. On such systems, choosing 
-<TT
-CLASS="literal"
->unlimited</TT
-> will
-cause the server to use the larger of the <B
-CLASS="command"
->rlim_max</B
-> for <B
-CLASS="command"
->RLIMIT_NOFILE</B
-> and
-the value returned by <B
-CLASS="command"
->sysconf(_SC_OPEN_MAX)</B
->.
-If the actual kernel limit is larger than this value, use <B
-CLASS="command"
->limit
-files </B
->to specify the limit explicitly.</P
-></BLOCKQUOTE
-></DIV
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet
-implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
 ></TD
 ></TR
 ><TR
@@ -5542,26 +5815,8 @@ WIDTH="288"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->The <B
-CLASS="command"
->max-ixfr-log-size</B
-> will
-be used in a future release of the server to limit the size of the
-transaction log kept for Incremental Zone Transfer.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not
-yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
+>This option is obsolete; it is accepted
+and ignored for BIND 8 compatibility.</P
 ></TD
 ></TR
 ><TR
@@ -5609,20 +5864,6 @@ may use. The default is <TT
 CLASS="literal"
 >default</TT
 >.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not
-yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
 ></TD
 ></TR
 ><TR
@@ -5671,14 +5912,15 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN2480"
->6.2.12.9. Periodic Task Intervals</A
+NAME="AEN2528"
+>6.2.14.8. Periodic Task Intervals</A
 ></H3
 ><DIV
 CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -5723,26 +5965,12 @@ ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
 >The server will perform zone maintenance tasks
-for all zones marked  <B
+for all zones marked as <B
 CLASS="command"
->dialup yes</B
+>dialup</B
 > whenever this
 interval expires. The default is 60 minutes. Reasonable values are up
 to 1 day (1440 minutes). If set to 0, no zone maintenance for these zones will occur.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet
-implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
 ></TD
 ></TR
 ><TR
@@ -5824,7 +6052,7 @@ CLASS="sect3"
 CLASS="sect3"
 ><A
 NAME="topology"
->6.2.12.10. Topology</A
+>6.2.14.9. Topology</A
 ></H3
 ><P
 >All other things being equal, when the server chooses a nameserver
@@ -5887,7 +6115,7 @@ CLASS="sect3"
 CLASS="sect3"
 ><A
 NAME="the_sortlist_statement"
->6.2.12.11. The <B
+>6.2.14.10. The <B
 CLASS="command"
 >sortlist</B
 > Statement</A
@@ -5915,10 +6143,7 @@ are documented in RFC 1035.</P
 them in <TT
 CLASS="varname"
 >Round Robin</TT
-><TT
-CLASS="varname"
-> </TT
->order,
+> order,
 that is, after each request the first RR is put at the end of the
 list. The client resolver code should rearrange the RRs as appropriate,
 that is, using any addresses on the local net in preference to other addresses.
@@ -5933,15 +6158,15 @@ CLASS="command"
 > statement (see below) takes
 an <B
 CLASS="command"
->address_match_list </B
->and interprets it even
+>address_match_list</B
+> and interprets it even
 more specifically than the <B
 CLASS="command"
 >topology</B
 > statement
 does (<A
 HREF="Bv9ARM.ch06.html#topology"
->Section 6.2.12.10</A
+>Section 6.2.14.9</A
 >). Each top level statement in the <B
 CLASS="command"
 >sortlist</B
@@ -5992,7 +6217,7 @@ CLASS="programlisting"
     { 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.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; }; }; };
@@ -6011,7 +6236,7 @@ local host and hosts on directly connected networks. It is similar
 to the behavior of the address sort in <SPAN
 CLASS="acronym"
 >BIND</SPAN
-> 8.x. Responses sent
+> 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
@@ -6047,7 +6272,7 @@ CLASS="sect3"
 CLASS="sect3"
 ><A
 NAME="rrset_ordering"
->6.2.12.12. RRset Ordering</A
+>6.2.14.11. RRset Ordering</A
 ></H3
 ><P
 >When multiple records are returned in an answer it may be
@@ -6124,6 +6349,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -6247,13 +6473,14 @@ CLASS="sect3"
 CLASS="sect3"
 ><A
 NAME="tuning"
->6.2.12.13. Tuning</A
+>6.2.14.12. Tuning</A
 ></H3
 ><DIV
 CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -6287,20 +6514,6 @@ CLASS="literal"
 >1800</TT
 > (30 minutes).</P
 >
-<DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
->
 </TD
 ></TR
 ><TR
@@ -6446,30 +6659,173 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN2676"
->6.2.12.14. Deprecated Features</A
+NAME="statsfile"
+>6.2.14.13. The Statistics File</A
 ></H3
 ><P
-><B
-CLASS="command"
->use-ixfr</B
-> is deprecated in <SPAN
+>The statistics file generated by <SPAN
+CLASS="acronym"
+>BIND</SPAN
+> 9
+is similar, but not identical, to that
+generated by <SPAN
 CLASS="acronym"
 >BIND</SPAN
-> 9. If
-        you need to disable IXFR to a particular server or servers see
-        the information on the <B
+> 8.
+</P
+><P
+>The statistics dump begins with the line <B
 CLASS="command"
->provide-ixfr</B
-> option
-        in <A
-HREF="Bv9ARM.ch06.html#server_statement_definition_and_usage"
->Section 6.2.14</A
->. See also
-        <A
-HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
->Section 4.2</A
->.</P
+>+++ Statistics Dump
++++ (973798949)</B
+>, where 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).  The statistics dump ends
+with the line <B
+CLASS="command"
+>--- Statistics Dump --- (973798949)</B
+>, where the
+number is identical to the number in the beginning line.</P
+><P
+>The following statistics counters are maintained:</P
+><DIV
+CLASS="informaltable"
+><P
+></P
+><TABLE
+CELLPADDING="3"
+BORDER="1"
+CLASS="CALSTABLE"
+><TR
+><TD
+WIDTH="110"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>success</B
+></P
+></TD
+><TD
+WIDTH="322"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>The number of
+successful queries made to the server or zone.  A successful query
+is defined as query which returns a NOERROR response other than
+a referral response.</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="110"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>referral</B
+></P
+></TD
+><TD
+WIDTH="322"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>The number of queries which resulted
+in referral responses.</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="110"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>nxrrset</B
+></P
+></TD
+><TD
+WIDTH="322"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>The number of queries which resulted in
+NOERROR responses with no data.</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="110"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>nxdomain</B
+></P
+></TD
+><TD
+WIDTH="322"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>The number
+of queries which resulted in NXDOMAIN responses.</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="110"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>recursion</B
+></P
+></TD
+><TD
+WIDTH="322"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>The number of queries which caused the server
+to perform recursion in order to find the final answer.</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="110"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>failure</B
+></P
+></TD
+><TD
+WIDTH="322"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>The number of queries which resulted in a
+failure response other than those above.</P
+></TD
+></TR
+></TABLE
+><P
+></P
+></DIV
 ></DIV
 ></DIV
 ><DIV
@@ -6478,7 +6834,7 @@ CLASS="sect2"
 CLASS="sect2"
 ><A
 NAME="server_statement_grammar"
->6.2.13. <B
+>6.2.15. <B
 CLASS="command"
 >server</B
 >
@@ -6561,7 +6917,7 @@ CLASS="sect2"
 CLASS="sect2"
 ><A
 NAME="server_statement_definition_and_usage"
->6.2.14. <B
+>6.2.16. <B
 CLASS="command"
 >server</B
 > Statement Definition
@@ -6583,23 +6939,6 @@ CLASS="command"
 CLASS="command"
 >no</B
 >.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->The <B
-CLASS="command"
->bogus</B
-> clause
-is not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
 ><P
 >The <B
 CLASS="command"
@@ -6618,8 +6957,8 @@ CLASS="command"
 to the remote server will be nonincremental. If not set, the value
 of the <B
 CLASS="command"
->provide-ixfr </B
->option in the global options block
+>provide-ixfr</B
+> option in the global options block
 is used as a default.</P
 ><P
 >The <B
@@ -6676,12 +7015,12 @@ CLASS="acronym"
 > 4.9.5. You can specify which method
 to use for a server with the <B
 CLASS="command"
->transfer-format </B
->option.
+>transfer-format</B
+> option.
 If <B
 CLASS="command"
->transfer-format </B
->is not specified, the <B
+>transfer-format</B
+> is not specified, the <B
 CLASS="command"
 >transfer-format</B
 > specified
@@ -6709,8 +7048,8 @@ CLASS="command"
 >keys</B
 > clause is used to identify a <B
 CLASS="command"
->key_id </B
->defined
+>key_id</B
+> defined
 by the <B
 CLASS="command"
 >key</B
@@ -6740,8 +7079,8 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN2750"
->6.2.15. <B
+NAME="AEN2829"
+>6.2.17. <B
 CLASS="command"
 >trusted-keys</B
 > Statement Grammar</A
@@ -6815,8 +7154,8 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN2766"
->6.2.16. <B
+NAME="AEN2845"
+>6.2.18. <B
 CLASS="command"
 >trusted-keys</B
 > Statement Definition
@@ -6850,8 +7189,8 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN2774"
->6.2.17. <B
+NAME="AEN2853"
+>6.2.19. <B
 CLASS="command"
 >view</B
 > Statement Grammar</A
@@ -6889,6 +7228,15 @@ CLASS="replaceable"
 >]
       [<SPAN
 CLASS="optional"
+> zone-statistics <TT
+CLASS="replaceable"
+><I
+>yes_or_no</I
+></TT
+> ; </SPAN
+>]
+      [<SPAN
+CLASS="optional"
 > <TT
 CLASS="replaceable"
 ><I
@@ -6904,8 +7252,8 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN2786"
->6.2.18. <B
+NAME="AEN2867"
+>6.2.20. <B
 CLASS="command"
 >view</B
 > Statement Definition and Usage</A
@@ -6943,8 +7291,8 @@ CLASS="command"
 >view</B
 > whose <B
 CLASS="command"
->match-clients </B
->list
+>match-clients</B
+> list
 matches the client's IP address.</P
 ><P
 >Zones defined within a <B
@@ -7046,7 +7394,7 @@ CLASS="sect2"
 CLASS="sect2"
 ><A
 NAME="zone_statement_grammar"
->6.2.19. <B
+>6.2.21. <B
 CLASS="command"
 >zone</B
 >
@@ -7170,7 +7518,7 @@ CLASS="optional"
 > dialup <TT
 CLASS="replaceable"
 ><I
->true_or_false</I
+>dialup_option</I
 ></TT
 > ; </SPAN
 >]
@@ -7239,7 +7587,7 @@ CLASS="optional"
 > maintain-ixfr-base <TT
 CLASS="replaceable"
 ><I
->true_or_false</I
+>yes_or_no</I
 ></TT
 > ; </SPAN
 >]
@@ -7329,7 +7677,12 @@ CLASS="optional"
 > notify <TT
 CLASS="replaceable"
 ><I
->true_or_false</I
+>yes_or_no</I
+></TT
+> | <TT
+CLASS="replaceable"
+><I
+>explicit</I
 ></TT
 > ; </SPAN
 >]
@@ -7367,7 +7720,15 @@ CLASS="replaceable"
 > | <TT
 CLASS="constant"
 >*</TT
->) ; </SPAN
+>) [<SPAN
+CLASS="optional"
+>port <TT
+CLASS="replaceable"
+><I
+>ip_port</I
+></TT
+></SPAN
+>] ; </SPAN
 >]
     [<SPAN
 CLASS="optional"
@@ -7379,7 +7740,64 @@ CLASS="replaceable"
 > | <TT
 CLASS="constant"
 >*</TT
->) ; </SPAN
+>) [<SPAN
+CLASS="optional"
+>port <TT
+CLASS="replaceable"
+><I
+>ip_port</I
+></TT
+></SPAN
+>] ; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> notify-source (<TT
+CLASS="replaceable"
+><I
+>ip4_addr</I
+></TT
+> | <TT
+CLASS="constant"
+>*</TT
+>) [<SPAN
+CLASS="optional"
+>port <TT
+CLASS="replaceable"
+><I
+>ip_port</I
+></TT
+></SPAN
+>] ; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> notify-source-v6 (<TT
+CLASS="replaceable"
+><I
+>ip6_addr</I
+></TT
+> | <TT
+CLASS="constant"
+>*</TT
+>) [<SPAN
+CLASS="optional"
+>port <TT
+CLASS="replaceable"
+><I
+>ip_port</I
+></TT
+></SPAN
+>] ; </SPAN
+>]
+    [<SPAN
+CLASS="optional"
+> zone-statistics <TT
+CLASS="replaceable"
+><I
+>yes_or_no</I
+></TT
+> ; </SPAN
 >]
     [<SPAN
 CLASS="optional"
@@ -7390,6 +7808,15 @@ CLASS="replaceable"
 ></TT
 > ; </SPAN
 >]
+    [<SPAN
+CLASS="optional"
+> database <TT
+CLASS="replaceable"
+><I
+>string</I
+></TT
+> ; </SPAN
+>]
 }</SPAN
 >];
 </PRE
@@ -7399,8 +7826,8 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN2902"
->6.2.20. <B
+NAME="AEN3002"
+>6.2.22. <B
 CLASS="command"
 >zone</B
 > Statement Definition and Usage</A
@@ -7410,14 +7837,15 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN2905"
->6.2.20.1. Zone Types</A
+NAME="AEN3005"
+>6.2.22.1. Zone Types</A
 ></H3
 ><DIV
 CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -7483,8 +7911,8 @@ CLASS="filename"
 >ex/example.com</TT
 > where <TT
 CLASS="filename"
->ex/ </TT
->is
+>ex/</TT
+> is
 just the first two letters of the zone name. (Most operating systems
 behave very slowly if you put 100K files into a single directory.)</P
 ></TD
@@ -7598,21 +8026,7 @@ CLASS="command"
 to", then "forward only", or vice versa, but want to use the same
 servers as set globally) you need to respecify the global forwarders.</P
 >
-<DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Domain-specific
-forwarding is not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
-></TD
+</TD
 ></TR
 ><TR
 ><TD
@@ -7648,8 +8062,8 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN2965"
->6.2.20.2. Class</A
+NAME="AEN3062"
+>6.2.22.2. Class</A
 ></H3
 ><P
 >The zone's name may optionally be followed by a class. If
@@ -7686,14 +8100,15 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN2975"
->6.2.20.3. Zone Options</A
+NAME="AEN3072"
+>6.2.22.3. Zone Options</A
 ></H3
 ><DIV
 CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -7718,7 +8133,7 @@ CLASS="command"
 >allow-query</B
 > in <A
 HREF="Bv9ARM.ch06.html#access_control"
->Section 6.2.12.4</A
+>Section 6.2.14.3</A
 ></P
 ></TD
 ></TR
@@ -7743,7 +8158,7 @@ CLASS="command"
 >allow-transfer</B
 > in <A
 HREF="Bv9ARM.ch06.html#access_control"
->Section 6.2.12.4</A
+>Section 6.2.14.3</A
 >.</P
 ></TD
 ></TR
@@ -7787,7 +8202,7 @@ VALIGN="MIDDLE"
 >Specifies a "Simple Secure Update" policy. See
 <A
 HREF="Bv9ARM.ch06.html#dynamic_update_policies"
->Section 6.2.20.4</A
+>Section 6.2.22.4</A
 >.</P
 ></TD
 ></TR
@@ -7809,19 +8224,45 @@ VALIGN="MIDDLE"
 ><P
 >Specifies which hosts are allowed to
 submit Dynamic DNS updates to slave zones to be forwarded to the
-master. The default is to deny update forwarding from all hosts.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
+master.  The default is <TT
+CLASS="userinput"
 ><B
->Note: </B
->Update
-forwarding is not yet implemented.</P
-></BLOCKQUOTE
-></DIV
-></TD
+>{ none; }</B
+></TT
+>, which 
+means that no update forwarding will be performed.  To enable
+update forwarding, specify  <TT
+CLASS="userinput"
+><B
+>allow-update-forwarding { any; };</B
+></TT
+>.
+Specifying values other than <TT
+CLASS="userinput"
+><B
+>{ none; }</B
+></TT
+> or
+<TT
+CLASS="userinput"
+><B
+>{ any; }</B
+></TT
+> 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"
+>Section 7.3</A
+>
+for more details.</P
+>
+</TD
 ></TR
 ><TR
 ><TD
@@ -7882,25 +8323,58 @@ WIDTH="273"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->See <A
-HREF="Bv9ARM.ch06.html#name_checking"
->Section 6.2.12.3</A
->.</P
+>&#13;This option was used in BIND 8 to restrict the character set of
+domain names in master files and/or DNS responses received from the
+netowrk.  BIND 9 does not restrict the character set of domain names
+and does not implement the <B
+CLASS="command"
+>check-names</B
+> option.
+</P
 >
-<DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
+</TD
+></TR
+><TR
+><TD
+WIDTH="159"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
 ><P
 ><B
->Note: </B
->Not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
+CLASS="command"
+>database</B
+></P
 ></TD
+><TD
+WIDTH="273"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>Specify the type of database to be used for storing the
+zone data.  The string following the <B
+CLASS="command"
+>database</B
+> 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 <TT
+CLASS="userinput"
+><B
+>"rbt"</B
+></TT
+>, 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
+>
+</TD
 ></TR
 ><TR
 ><TD
@@ -7922,24 +8396,10 @@ VALIGN="MIDDLE"
 <B
 CLASS="command"
 >dialup</B
-> under <A
+> in <A
 HREF="Bv9ARM.ch06.html#boolean_options"
->Section 6.2.12.1</A
->.
-<DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
-></P
+>Section 6.2.14.1</A
+>.</P
 ></TD
 ></TR
 ><TR
@@ -7969,20 +8429,7 @@ CLASS="command"
 > would
 allow a normal lookup to be tried.</P
 >
-<DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
-></TD
+</TD
 ></TR
 ><TR
 ><TD
@@ -8006,21 +8453,8 @@ CLASS="command"
 >forward</B
 >,
 no forwarding is done for the zone; the global options are not used.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not
-yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
-></TD
+>
+</TD
 ></TR
 ><TR
 ><TD
@@ -8074,9 +8508,9 @@ VALIGN="MIDDLE"
 <B
 CLASS="command"
 >max-transfer-time-in</B
-> under <A
+> in <A
 HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.12.7</A
+>Section 6.2.14.6</A
 >.</P
 ></TD
 ></TR
@@ -8100,9 +8534,9 @@ VALIGN="MIDDLE"
 <B
 CLASS="command"
 >max-transfer-idle-in</B
-> under <A
+> in <A
 HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.12.7</A
+>Section 6.2.14.6</A
 >.</P
 ></TD
 ></TR
@@ -8126,9 +8560,9 @@ VALIGN="MIDDLE"
 <B
 CLASS="command"
 >max-transfer-time-out</B
-> under <A
+> in <A
 HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.12.7</A
+>Section 6.2.14.6</A
 >.</P
 ></TD
 ></TR
@@ -8152,9 +8586,9 @@ VALIGN="MIDDLE"
 <B
 CLASS="command"
 >max-transfer-idle-out</B
-> under <A
+> in <A
 HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.12.7</A
+>Section 6.2.14.6</A
 >.</P
 ></TD
 ></TR
@@ -8178,9 +8612,9 @@ VALIGN="MIDDLE"
 <B
 CLASS="command"
 >notify</B
-> under <A
+> in <A
 HREF="Bv9ARM.ch06.html#boolean_options"
->Section 6.2.12.1</A
+>Section 6.2.14.1</A
 >.</P
 ></TD
 ></TR
@@ -8220,6 +8654,35 @@ VALIGN="MIDDLE"
 ><P
 ><B
 CLASS="command"
+>zone-statistics</B
+></P
+></TD
+><TD
+WIDTH="273"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>If <TT
+CLASS="userinput"
+><B
+>yes</B
+></TT
+>, the server will keep statistical
+information for this zone, which can be dumped to the
+<B
+CLASS="command"
+>statistics-file</B
+> defined in the server options.</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="159"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
 >sig-validity-interval</B
 ></P
 ></TD
@@ -8232,9 +8695,9 @@ VALIGN="MIDDLE"
 <B
 CLASS="command"
 >sig-validity-interval</B
-> under <A
+> in <A
 HREF="Bv9ARM.ch06.html#tuning"
->Section 6.2.12.13</A
+>Section 6.2.14.12</A
 >.</P
 ></TD
 ></TR
@@ -8254,22 +8717,42 @@ WIDTH="273"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Determines which local address will be bound
-to the IPv4 TCP connection used to fetch this zone. If not set,
-it defaults to a system controlled value which will usually be the
-address of the interface "closest to" the remote end. If the remote
-end user is an <B
-CLASS="command"
->allow-transfer</B
-> option for this
-zone, the address, supplied by the <B
+>See the description of
+<B
 CLASS="command"
 >transfer-source</B
-> option,
-needs to be specified in that <B
+> in <A
+HREF="Bv9ARM.ch06.html#zone_transfers"
+>Section 6.2.14.6</A
+>
+</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="159"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
 CLASS="command"
->allow-transfer</B
-> option.</P
+>transfer-source-v6</B
+></P
+></TD
+><TD
+WIDTH="273"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>See the description of
+<B
+CLASS="command"
+>transfer-source-v6</B
+> in <A
+HREF="Bv9ARM.ch06.html#zone_transfers"
+>Section 6.2.14.6</A
+>
+</P
 ></TD
 ></TR
 ><TR
@@ -8278,15 +8761,52 @@ WIDTH="159"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->transfer-source-v6</P
+><B
+CLASS="command"
+>notify-source</B
+></P
 ></TD
 ><TD
 WIDTH="273"
 ALIGN="LEFT"
 VALIGN="MIDDLE"
 ><P
->Similar to transfer-source, but for zone transfers
-performed using IPv6.</P
+>See the description of
+<B
+CLASS="command"
+>notify-source</B
+> in <A
+HREF="Bv9ARM.ch06.html#zone_transfers"
+>Section 6.2.14.6</A
+>
+</P
+></TD
+></TR
+><TR
+><TD
+WIDTH="159"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+><B
+CLASS="command"
+>notify-source-v6</B
+></P
+></TD
+><TD
+WIDTH="273"
+ALIGN="LEFT"
+VALIGN="MIDDLE"
+><P
+>See the description of
+<B
+CLASS="command"
+>notify-source-v6</B
+> in <A
+HREF="Bv9ARM.ch06.html#zone_transfers"
+>Section 6.2.14.6</A
+>.
+</P
 ></TD
 ></TR
 ></TABLE
@@ -8300,7 +8820,7 @@ CLASS="sect3"
 CLASS="sect3"
 ><A
 NAME="dynamic_update_policies"
->6.2.20.4. Dynamic Update Policies</A
+>6.2.22.4. Dynamic Update Policies</A
 ></H3
 ><P
 ><SPAN
@@ -8420,6 +8940,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -8519,7 +9040,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN3213"
+NAME="AEN3338"
 >6.3. Zone File</A
 ></H1
 ><DIV
@@ -8540,7 +9061,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN3218"
+NAME="AEN3343"
 >6.3.1.1. Resource Records</A
 ></H3
 ><P
@@ -8553,10 +9074,10 @@ NAME="AEN3218"
         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"
->Section 6.2.12.11</A
+>Section 6.2.14.10</A
 > and <A
 HREF="Bv9ARM.ch06.html#rrset_ordering"
->Section 6.2.12.12</A
+>Section 6.2.14.11</A
 >.</P
 ><P
 >The components of a Resource Record are:</P
@@ -8565,6 +9086,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -8670,6 +9192,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -9041,6 +9564,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -9087,6 +9611,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -9256,7 +9781,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN3432"
+NAME="AEN3557"
 >6.3.1.2. Textual expression of RRs</A
 ></H3
 ><P
@@ -9288,6 +9813,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -9491,6 +10017,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -9574,7 +10101,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN3533"
+NAME="AEN3658"
 >6.3.2. Discussion of MX Records</A
 ></H2
 ><P
@@ -9609,6 +10136,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -9898,6 +10426,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -9973,7 +10502,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN3654"
+NAME="AEN3779"
 >6.3.4. Inverse Mapping in IPv4</A
 ></H2
 ><P
@@ -9999,6 +10528,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -10071,7 +10601,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN3681"
+NAME="AEN3806"
 >6.3.5. Other Zone File Directives</A
 ></H2
 ><P
@@ -10096,7 +10626,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN3688"
+NAME="AEN3813"
 >6.3.5.1. The <B
 CLASS="command"
 >$ORIGIN</B
@@ -10124,13 +10654,13 @@ CLASS="replaceable"
 ><P
 ><B
 CLASS="command"
->$ORIGIN </B
->sets the domain name that will
+>$ORIGIN</B
+> sets the domain name that will
 be appended to any unqualified records. When a zone is first read
 in there is an implicit <B
 CLASS="command"
->$ORIGIN </B
->&#60;<TT
+>$ORIGIN</B
+> &#60;<TT
 CLASS="varname"
 >zone-name</TT
 >&#62;<B
@@ -10166,7 +10696,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN3708"
+NAME="AEN3833"
 >6.3.5.2. The <B
 CLASS="command"
 >$INCLUDE</B
@@ -10242,7 +10772,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN3727"
+NAME="AEN3852"
 >6.3.5.3. The <B
 CLASS="command"
 >$TTL</B
@@ -10282,7 +10812,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN3738"
+NAME="AEN3863"
 >6.3.6. <SPAN
 CLASS="acronym"
 >BIND</SPAN
@@ -10331,8 +10861,8 @@ CLASS="command"
 > is used to create a series of
 resource records that only differ from each other by an iterator. <B
 CLASS="command"
->$GENERATE </B
->can
+>$GENERATE</B
+> 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
@@ -10363,6 +10893,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -10414,22 +10945,73 @@ within the <B
 CLASS="command"
 >lhs</B
 > side are replaced by the iterator
-value. To get a $ in the output use a double <B
+value.
+To get a $ in the output you need to escape the <B
 CLASS="command"
 >$</B
+>
+using a backslash <B
+CLASS="command"
+>\</B
 >,
 e.g. <B
 CLASS="command"
->$$</B
->. If the <B
+>\$</B
+>. The <B
+CLASS="command"
+>$</B
+> may optionally be followed
+by modifiers which change the offset from the interator, field width and base. 
+Modifiers are introduced by a <B
+CLASS="command"
+>{</B
+> immediately following the
+<B
+CLASS="command"
+>$</B
+> as <B
+CLASS="command"
+>${offset[,width[,base]]}</B
+>.
+e.g. <B
+CLASS="command"
+>${-20,3,d}</B
+> which subtracts 20 from the current value,
+prints the result as a decimal in a zero padded field of with 3.  Available
+output forms are decimal (<B
+CLASS="command"
+>d</B
+>), octal (<B
+CLASS="command"
+>o</B
+>)
+and hexadecimal (<B
+CLASS="command"
+>x</B
+> or <B
+CLASS="command"
+>X</B
+> for uppercase).
+The default modifier is <B
+CLASS="command"
+>${0,0,d}</B
+>.
+If the <B
 CLASS="command"
 >lhs</B
 > is not
 absolute, the current <B
 CLASS="command"
->$ORIGIN </B
->is appended to
+>$ORIGIN</B
+> is appended to
 the name.</P
+>
+<P
+>For compatability with earlier versions <B
+CLASS="command"
+>$$</B
+> is still
+recognised a indicating a literal $ in the output.</P
 ></TD
 ></TR
 ><TR
@@ -10484,22 +11066,7 @@ CLASS="command"
 CLASS="acronym"
 >BIND</SPAN
 > extension
-and not part of the standard zone file format.
-<DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->It is not yet implemented in <SPAN
-CLASS="acronym"
->BIND</SPAN
-> 9.</P
-></BLOCKQUOTE
-></DIV
->
-</P
+and not part of the standard zone file format.</P
 ></DIV
 ></DIV
 ></DIV
diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html
index 411e5725..958d1d57 100644
--- a/doc/arm/Bv9ARM.ch07.html
+++ b/doc/arm/Bv9ARM.ch07.html
@@ -83,7 +83,7 @@ HREF="Bv9ARM.ch07.html#Access_Control_Lists"
 ></DT
 ><DT
 >7.2. <A
-HREF="Bv9ARM.ch07.html#AEN3819"
+HREF="Bv9ARM.ch07.html#AEN3954"
 ><B
 CLASS="command"
 >chroot</B
@@ -95,8 +95,8 @@ UNIX servers)</A
 ></DT
 ><DT
 >7.3. <A
-HREF="Bv9ARM.ch07.html#AEN3865"
->Dynamic Updates</A
+HREF="Bv9ARM.ch07.html#dynamic_update_security"
+>Dynamic Update Security</A
 ></DT
 ></DL
 ></DIV
@@ -180,7 +180,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN3819"
+NAME="AEN3954"
 >7.2. <B
 CLASS="command"
 >chroot</B
@@ -259,7 +259,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN3842"
+NAME="AEN3977"
 >7.2.1. The <B
 CLASS="command"
 >chroot</B
@@ -315,7 +315,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN3857"
+NAME="AEN3992"
 >7.2.2. Using the <B
 CLASS="command"
 >setuid</B
@@ -346,21 +346,44 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN3865"
->7.3. Dynamic Updates</A
+NAME="dynamic_update_security"
+>7.3. Dynamic Update Security</A
 ></H1
 ><P
->Access to the dynamic update facility should be strictly limited.
-In earlier versions of <SPAN
+>Access to the dynamic
+update facility should be strictly limited.  In earlier versions of
+<SPAN
 CLASS="acronym"
 >BIND</SPAN
-> the only way to do this was based on
-the IP address of the host requesting the update. <SPAN
-CLASS="acronym"
->BIND9</SPAN
-> also
-supports authenticating updates cryptographically by means of transaction
-signatures (TSIG). The use of TSIG is strongly recommended.</P
+> 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 <B
+CLASS="command"
+>allow-update</B
+> 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
+<B
+CLASS="command"
+>allow-update</B
+> 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 <B
+CLASS="command"
+>allow-update</B
+> option should
+list only TSIG key names, not IP addresses or network
+prefixes. Alternatively, the new <B
+CLASS="command"
+>update-policy</B
+>
+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
diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html
index ead1ba33..9641043b 100644
--- a/doc/arm/Bv9ARM.ch08.html
+++ b/doc/arm/Bv9ARM.ch08.html
@@ -75,17 +75,17 @@ CLASS="TOC"
 ></DT
 ><DT
 >8.1. <A
-HREF="Bv9ARM.ch08.html#AEN3873"
+HREF="Bv9ARM.ch08.html#AEN4012"
 >Common Problems</A
 ></DT
 ><DT
 >8.2. <A
-HREF="Bv9ARM.ch08.html#AEN3879"
+HREF="Bv9ARM.ch08.html#AEN4018"
 >Incrementing and Changing the Serial Number</A
 ></DT
 ><DT
 >8.3. <A
-HREF="Bv9ARM.ch08.html#AEN3884"
+HREF="Bv9ARM.ch08.html#AEN4023"
 >Where Can I Get Help?</A
 ></DT
 ></DL
@@ -95,7 +95,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN3873"
+NAME="AEN4012"
 >8.1. Common Problems</A
 ></H1
 ><DIV
@@ -103,7 +103,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN3875"
+NAME="AEN4014"
 >8.1.1. It's not working; how can I figure out what's wrong?</A
 ></H2
 ><P
@@ -123,7 +123,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN3879"
+NAME="AEN4018"
 >8.2. Incrementing and Changing the Serial Number</A
 ></H1
 ><P
@@ -152,7 +152,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN3884"
+NAME="AEN4023"
 >8.3. Where Can I Get Help?</A
 ></H1
 ><P
@@ -189,7 +189,7 @@ CLASS="acronym"
 ><P
 >To discuss arrangements for support, contact
     <A
-HREF="email:info@isc.org"
+HREF="mailto:info@isc.org"
 TARGET="_top"
 >info@isc.org</A
 > or visit the
diff --git a/doc/arm/Bv9ARM.ch09.html b/doc/arm/Bv9ARM.ch09.html
index 48f6d4ae..a3521b54 100644
--- a/doc/arm/Bv9ARM.ch09.html
+++ b/doc/arm/Bv9ARM.ch09.html
@@ -69,7 +69,7 @@ CLASS="TOC"
 ></DT
 ><DT
 >A.1. <A
-HREF="Bv9ARM.ch09.html#AEN3900"
+HREF="Bv9ARM.ch09.html#AEN4039"
 >Acknowledgements</A
 ></DT
 ><DT
@@ -82,7 +82,7 @@ CLASS="acronym"
 ></DT
 ><DT
 >A.3. <A
-HREF="Bv9ARM.ch09.html#AEN3941"
+HREF="Bv9ARM.ch09.html#AEN4080"
 >General <SPAN
 CLASS="acronym"
 >DNS</SPAN
@@ -100,7 +100,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN3900"
+NAME="AEN4039"
 >A.1. Acknowledgements</A
 ></H1
 ><DIV
@@ -108,7 +108,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN3902"
+NAME="AEN4041"
 >A.1.1. A Brief History of the <SPAN
 CLASS="acronym"
 >DNS</SPAN
@@ -243,7 +243,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN3932"
+NAME="AEN4071"
 >A.2.1.1. HS = hesiod</A
 ></H3
 ><P
@@ -264,7 +264,7 @@ CLASS="sect3"
 ><H3
 CLASS="sect3"
 ><A
-NAME="AEN3937"
+NAME="AEN4076"
 >A.2.1.2. CH = chaos</A
 ></H3
 ><P
@@ -282,7 +282,7 @@ CLASS="sect1"
 ><H1
 CLASS="sect1"
 ><A
-NAME="AEN3941"
+NAME="AEN4080"
 >A.3. General <SPAN
 CLASS="acronym"
 >DNS</SPAN
@@ -293,7 +293,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN3944"
+NAME="AEN4083"
 >A.3.1. IPv6 addresses (A6)</A
 ></H2
 ><P
@@ -323,6 +323,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -536,6 +537,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -713,6 +715,7 @@ CLASS="informaltable"
 ><P
 ></P
 ><TABLE
+CELLPADDING="3"
 BORDER="1"
 CLASS="CALSTABLE"
 ><TR
@@ -863,19 +866,19 @@ TARGET="_top"
 >.</P
 ><H3
 ><A
-NAME="AEN4120"
+NAME="AEN4259"
 >Bibliography</A
 ></H3
 ><H1
 CLASS="bibliodiv"
 ><A
-NAME="AEN4121"
+NAME="AEN4260"
 >Standards</A
 ></H1
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4123"
+NAME="AEN4262"
 ></A
 ><P
 >[RFC974]&nbsp;C. Partridge, <I
@@ -889,7 +892,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4130"
+NAME="AEN4269"
 ></A
 ><P
 >[RFC1034]&nbsp;P.V. Mockapetris, <I
@@ -903,7 +906,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4137"
+NAME="AEN4276"
 ></A
 ><P
 >[RFC1035]&nbsp;P. V. Mockapetris, <I
@@ -924,7 +927,7 @@ NAME="proposed_standards"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4146"
+NAME="AEN4285"
 ></A
 ><P
 >[RFC2181]&nbsp;R., R. Bush Elz, <I
@@ -941,7 +944,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4154"
+NAME="AEN4293"
 ></A
 ><P
 >[RFC2308]&nbsp;M. Andrews, <I
@@ -958,7 +961,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4162"
+NAME="AEN4301"
 ></A
 ><P
 >[RFC1995]&nbsp;M. Ohta, <I
@@ -975,7 +978,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4170"
+NAME="AEN4309"
 ></A
 ><P
 >[RFC1996]&nbsp;P. Vixie, <I
@@ -989,7 +992,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4177"
+NAME="AEN4316"
 ></A
 ><P
 >[RFC2136]&nbsp;P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, <I
@@ -1003,7 +1006,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4194"
+NAME="AEN4333"
 ></A
 ><P
 >[RFC2845]&nbsp;P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington, <I
@@ -1020,13 +1023,13 @@ STYLE="margin-left=0.5in"
 ><H1
 CLASS="bibliodiv"
 ><A
-NAME="AEN4213"
+NAME="AEN4352"
 >Proposed Standards Still Under Development</A
 ></H1
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4218"
+NAME="AEN4357"
 ></A
 ><P
 >[RFC1886]&nbsp;S. Thomson and C. Huitema, <I
@@ -1043,7 +1046,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4230"
+NAME="AEN4369"
 ></A
 ><P
 >[RFC2065]&nbsp;D. Eastlake, 3rd and C. Kaufman, <I
@@ -1057,7 +1060,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4242"
+NAME="AEN4381"
 ></A
 ><P
 >[RFC2137]&nbsp;D. Eastlake, 3rd, <I
@@ -1071,7 +1074,7 @@ STYLE="margin-left=0.5in"
 ><H1
 CLASS="bibliodiv"
 ><A
-NAME="AEN4250"
+NAME="AEN4389"
 >Other Important RFCs About <SPAN
 CLASS="acronym"
 >DNS</SPAN
@@ -1080,7 +1083,7 @@ CLASS="acronym"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4253"
+NAME="AEN4392"
 ></A
 ><P
 >[RFC1535]&nbsp;E. Gavron, <I
@@ -1097,7 +1100,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4261"
+NAME="AEN4400"
 ></A
 ><P
 >[RFC1536]&nbsp;A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller, <I
@@ -1114,7 +1117,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4282"
+NAME="AEN4421"
 ></A
 ><P
 >[RFC1982]&nbsp;R. Elz and R. Bush, <I
@@ -1128,13 +1131,13 @@ STYLE="margin-left=0.5in"
 ><H1
 CLASS="bibliodiv"
 ><A
-NAME="AEN4293"
+NAME="AEN4432"
 >Resource Record Types</A
 ></H1
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4295"
+NAME="AEN4434"
 ></A
 ><P
 >[RFC1183]&nbsp;C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris, <I
@@ -1151,7 +1154,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4313"
+NAME="AEN4452"
 ></A
 ><P
 >[RFC1706]&nbsp;B. Manning and R. Colella, <I
@@ -1168,7 +1171,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4325"
+NAME="AEN4464"
 ></A
 ><P
 >[RFC2168]&nbsp;R. Daniel and M. Mealling, <I
@@ -1183,7 +1186,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4336"
+NAME="AEN4475"
 ></A
 ><P
 >[RFC1876]&nbsp;C. Davis, P. Vixie, T., and I. Dickinson, <I
@@ -1198,7 +1201,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4353"
+NAME="AEN4492"
 ></A
 ><P
 >[RFC2052]&nbsp;A. Gulbrandsen and P. Vixie, <I
@@ -1216,7 +1219,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4365"
+NAME="AEN4504"
 ></A
 ><P
 >[RFC2163]&nbsp;A. Allocchio, <I
@@ -1234,7 +1237,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4373"
+NAME="AEN4512"
 ></A
 ><P
 >[RFC2230]&nbsp;R. Atkinson, <I
@@ -1251,7 +1254,7 @@ STYLE="margin-left=0.5in"
 ><H1
 CLASS="bibliodiv"
 ><A
-NAME="AEN4381"
+NAME="AEN4520"
 ><SPAN
 CLASS="acronym"
 >DNS</SPAN
@@ -1260,7 +1263,7 @@ CLASS="acronym"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4384"
+NAME="AEN4523"
 ></A
 ><P
 >[RFC1101]&nbsp;P. V. Mockapetris, <I
@@ -1277,7 +1280,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4392"
+NAME="AEN4531"
 ></A
 ><P
 >[RFC1123]&nbsp;Braden, <I
@@ -1291,7 +1294,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4399"
+NAME="AEN4538"
 ></A
 ><P
 >[RFC1591]&nbsp;J. Postel, <I
@@ -1305,7 +1308,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4406"
+NAME="AEN4545"
 ></A
 ><P
 >[RFC2317]&nbsp;H. Eidnes, G. de Groot, and P. Vixie, <I
@@ -1319,7 +1322,7 @@ STYLE="margin-left=0.5in"
 ><H1
 CLASS="bibliodiv"
 ><A
-NAME="AEN4420"
+NAME="AEN4559"
 ><SPAN
 CLASS="acronym"
 >DNS</SPAN
@@ -1328,7 +1331,7 @@ CLASS="acronym"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4423"
+NAME="AEN4562"
 ></A
 ><P
 >[RFC1537]&nbsp;P. Beertema, <I
@@ -1345,7 +1348,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4431"
+NAME="AEN4570"
 ></A
 ><P
 >[RFC1912]&nbsp;D. Barr, <I
@@ -1362,7 +1365,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4439"
+NAME="AEN4578"
 ></A
 ><P
 >[RFC1912]&nbsp;D. Barr, <I
@@ -1379,7 +1382,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4447"
+NAME="AEN4586"
 ></A
 ><P
 >[RFC2010]&nbsp;B. Manning and P. Vixie, <I
@@ -1393,7 +1396,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4458"
+NAME="AEN4597"
 ></A
 ><P
 >[RFC2219]&nbsp;M. Hamilton and R. Wright, <I
@@ -1410,7 +1413,7 @@ STYLE="margin-left=0.5in"
 ><H1
 CLASS="bibliodiv"
 ><A
-NAME="AEN4470"
+NAME="AEN4609"
 >Other <SPAN
 CLASS="acronym"
 >DNS</SPAN
@@ -1419,7 +1422,7 @@ CLASS="acronym"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4476"
+NAME="AEN4615"
 ></A
 ><P
 >[RFC1464]&nbsp;R. Rosenbaum, <I
@@ -1433,7 +1436,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4483"
+NAME="AEN4622"
 ></A
 ><P
 >[RFC1713]&nbsp;A. Romao, <I
@@ -1450,7 +1453,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4491"
+NAME="AEN4630"
 ></A
 ><P
 >[RFC1794]&nbsp;T. Brisco, <I
@@ -1467,7 +1470,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4499"
+NAME="AEN4638"
 ></A
 ><P
 >[RFC2240]&nbsp;O. Vaughan, <I
@@ -1481,7 +1484,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4506"
+NAME="AEN4645"
 ></A
 ><P
 >[RFC2345]&nbsp;J. Klensin, T. Wolf, and G. Oglesby, <I
@@ -1495,7 +1498,7 @@ STYLE="margin-left=0.5in"
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4520"
+NAME="AEN4659"
 ></A
 ><P
 >[RFC2352]&nbsp;O. Vaughan, <I
@@ -1509,13 +1512,13 @@ STYLE="margin-left=0.5in"
 ><H1
 CLASS="bibliodiv"
 ><A
-NAME="AEN4527"
+NAME="AEN4666"
 >Obsolete and Unimplemented Experimental RRs</A
 ></H1
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4529"
+NAME="AEN4668"
 ></A
 ><P
 >[RFC1712]&nbsp;C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni, <I
@@ -1554,7 +1557,7 @@ CLASS="sect2"
 ><H2
 CLASS="sect2"
 ><A
-NAME="AEN4550"
+NAME="AEN4689"
 >A.4.3. Other Documents About <SPAN
 CLASS="acronym"
 >BIND</SPAN
@@ -1564,13 +1567,13 @@ CLASS="acronym"
 ></P
 ><H3
 ><A
-NAME="AEN4554"
+NAME="AEN4693"
 >Bibliography</A
 ></H3
 ><DIV
 CLASS="biblioentry"
 ><A
-NAME="AEN4555"
+NAME="AEN4694"
 ></A
 ><P
 >Paul Albitz and Cricket Liu, <I
diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html
index 26576dc1..5e703cd7 100644
--- a/doc/arm/Bv9ARM.html
+++ b/doc/arm/Bv9ARM.html
@@ -64,17 +64,17 @@ CLASS="acronym"
 ><DL
 ><DT
 >1.4.1. <A
-HREF="Bv9ARM.ch01.html#AEN136"
+HREF="Bv9ARM.ch01.html#AEN135"
 >Nameservers</A
 ></DT
 ><DT
 >1.4.2. <A
-HREF="Bv9ARM.ch01.html#AEN157"
+HREF="Bv9ARM.ch01.html#AEN156"
 >Types of Zones</A
 ></DT
 ><DT
 >1.4.3. <A
-HREF="Bv9ARM.ch01.html#AEN194"
+HREF="Bv9ARM.ch01.html#AEN193"
 >Servers</A
 ></DT
 ></DL
@@ -93,27 +93,27 @@ CLASS="acronym"
 ><DL
 ><DT
 >2.1. <A
-HREF="Bv9ARM.ch02.html#AEN230"
+HREF="Bv9ARM.ch02.html#AEN229"
 >Hardware requirements</A
 ></DT
 ><DT
 >2.2. <A
-HREF="Bv9ARM.ch02.html#AEN238"
+HREF="Bv9ARM.ch02.html#AEN237"
 >CPU Requirements</A
 ></DT
 ><DT
 >2.3. <A
-HREF="Bv9ARM.ch02.html#AEN242"
+HREF="Bv9ARM.ch02.html#AEN241"
 >Memory Requirements</A
 ></DT
 ><DT
 >2.4. <A
-HREF="Bv9ARM.ch02.html#AEN247"
+HREF="Bv9ARM.ch02.html#AEN246"
 >Nameserver Intensive Environment Issues</A
 ></DT
 ><DT
 >2.5. <A
-HREF="Bv9ARM.ch02.html#AEN250"
+HREF="Bv9ARM.ch02.html#AEN249"
 >Supported Operating Systems</A
 ></DT
 ></DL
@@ -134,19 +134,19 @@ HREF="Bv9ARM.ch03.html#sample_configuration"
 ><DL
 ><DT
 >3.1.1. <A
-HREF="Bv9ARM.ch03.html#AEN276"
+HREF="Bv9ARM.ch03.html#AEN275"
 >A Caching-only Nameserver</A
 ></DT
 ><DT
 >3.1.2. <A
-HREF="Bv9ARM.ch03.html#AEN280"
+HREF="Bv9ARM.ch03.html#AEN279"
 >An Authoritative-only Nameserver</A
 ></DT
 ></DL
 ></DD
 ><DT
 >3.2. <A
-HREF="Bv9ARM.ch03.html#AEN286"
+HREF="Bv9ARM.ch03.html#AEN285"
 >Load Balancing</A
 ></DT
 ><DT
@@ -156,19 +156,19 @@ HREF="Bv9ARM.ch03.html#notify"
 ></DT
 ><DT
 >3.4. <A
-HREF="Bv9ARM.ch03.html#AEN374"
+HREF="Bv9ARM.ch03.html#AEN373"
 >Nameserver Operations</A
 ></DT
 ><DD
 ><DL
 ><DT
 >3.4.1. <A
-HREF="Bv9ARM.ch03.html#AEN376"
+HREF="Bv9ARM.ch03.html#AEN375"
 >Tools for Use With the Nameserver Daemon</A
 ></DT
 ><DT
 >3.4.2. <A
-HREF="Bv9ARM.ch03.html#AEN600"
+HREF="Bv9ARM.ch03.html#AEN588"
 >Signals</A
 ></DT
 ></DL
@@ -194,7 +194,7 @@ HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
 ></DT
 ><DT
 >4.3. <A
-HREF="Bv9ARM.ch04.html#AEN654"
+HREF="Bv9ARM.ch04.html#AEN642"
 >Split DNS</A
 ></DT
 ><DT
@@ -206,44 +206,44 @@ HREF="Bv9ARM.ch04.html#tsig"
 ><DL
 ><DT
 >4.4.1. <A
-HREF="Bv9ARM.ch04.html#AEN747"
+HREF="Bv9ARM.ch04.html#AEN733"
 >Generate Shared Keys for Each Pair of Hosts</A
 ></DT
 ><DT
 >4.4.2. <A
-HREF="Bv9ARM.ch04.html#AEN768"
+HREF="Bv9ARM.ch04.html#AEN754"
 >Copying the Shared Secret to Both Machines</A
 ></DT
 ><DT
 >4.4.3. <A
-HREF="Bv9ARM.ch04.html#AEN771"
+HREF="Bv9ARM.ch04.html#AEN757"
 >Informing the Servers of the Key's Existence</A
 ></DT
 ><DT
 >4.4.4. <A
-HREF="Bv9ARM.ch04.html#AEN783"
+HREF="Bv9ARM.ch04.html#AEN769"
 >Instructing the Server to Use the Key</A
 ></DT
 ><DT
 >4.4.5. <A
-HREF="Bv9ARM.ch04.html#AEN799"
+HREF="Bv9ARM.ch04.html#AEN785"
 >TSIG Key Based Access Control</A
 ></DT
 ><DT
 >4.4.6. <A
-HREF="Bv9ARM.ch04.html#AEN812"
+HREF="Bv9ARM.ch04.html#AEN798"
 >Errors</A
 ></DT
 ></DL
 ></DD
 ><DT
 >4.5. <A
-HREF="Bv9ARM.ch04.html#AEN816"
+HREF="Bv9ARM.ch04.html#AEN802"
 >TKEY</A
 ></DT
 ><DT
 >4.6. <A
-HREF="Bv9ARM.ch04.html#AEN831"
+HREF="Bv9ARM.ch04.html#AEN817"
 >SIG(0)</A
 ></DT
 ><DT
@@ -255,34 +255,34 @@ HREF="Bv9ARM.ch04.html#DNSSEC"
 ><DL
 ><DT
 >4.7.1. <A
-HREF="Bv9ARM.ch04.html#AEN847"
+HREF="Bv9ARM.ch04.html#AEN833"
 >Generating Keys</A
 ></DT
 ><DT
 >4.7.2. <A
-HREF="Bv9ARM.ch04.html#AEN867"
+HREF="Bv9ARM.ch04.html#AEN853"
 >Creating a Keyset</A
 ></DT
 ><DT
 >4.7.3. <A
-HREF="Bv9ARM.ch04.html#AEN879"
+HREF="Bv9ARM.ch04.html#AEN865"
 >Signing the Child's Keyset</A
 ></DT
 ><DT
 >4.7.4. <A
-HREF="Bv9ARM.ch04.html#AEN892"
+HREF="Bv9ARM.ch04.html#AEN878"
 >Signing the Zone</A
 ></DT
 ><DT
 >4.7.5. <A
-HREF="Bv9ARM.ch04.html#AEN908"
+HREF="Bv9ARM.ch04.html#AEN894"
 >Configuring Servers</A
 ></DT
 ></DL
 ></DD
 ><DT
 >4.8. <A
-HREF="Bv9ARM.ch04.html#AEN915"
+HREF="Bv9ARM.ch04.html#AEN901"
 >IPv6 Support in <SPAN
 CLASS="acronym"
 >BIND</SPAN
@@ -292,27 +292,27 @@ CLASS="acronym"
 ><DL
 ><DT
 >4.8.1. <A
-HREF="Bv9ARM.ch04.html#AEN929"
+HREF="Bv9ARM.ch04.html#AEN915"
 >Address Lookups Using AAAA Records</A
 ></DT
 ><DT
 >4.8.2. <A
-HREF="Bv9ARM.ch04.html#AEN934"
+HREF="Bv9ARM.ch04.html#AEN920"
 >Address Lookups Using A6 Records</A
 ></DT
 ><DT
 >4.8.3. <A
-HREF="Bv9ARM.ch04.html#AEN955"
+HREF="Bv9ARM.ch04.html#AEN941"
 >Address to Name Lookups Using Nibble Format</A
 ></DT
 ><DT
 >4.8.4. <A
-HREF="Bv9ARM.ch04.html#AEN962"
+HREF="Bv9ARM.ch04.html#AEN948"
 >Address to Name Lookups Using Bitstring Format</A
 ></DT
 ><DT
 >4.8.5. <A
-HREF="Bv9ARM.ch04.html#AEN969"
+HREF="Bv9ARM.ch04.html#AEN955"
 >Using DNAME for Delegation of IPv6 Reverse Addresses</A
 ></DT
 ></DL
@@ -331,12 +331,12 @@ CLASS="acronym"
 ><DL
 ><DT
 >5.1. <A
-HREF="Bv9ARM.ch05.html#AEN989"
+HREF="Bv9ARM.ch05.html#AEN975"
 >The Lightweight Resolver Library</A
 ></DT
 ><DT
 >5.2. <A
-HREF="Bv9ARM.ch05.html#AEN995"
+HREF="Bv9ARM.ch05.html#lwresd"
 >Running a Resolver Daemon</A
 ></DT
 ></DL
@@ -365,7 +365,7 @@ HREF="Bv9ARM.ch06.html#address_match_lists"
 ></DT
 ><DT
 >6.1.2. <A
-HREF="Bv9ARM.ch06.html#AEN1212"
+HREF="Bv9ARM.ch06.html#AEN1216"
 >Comment Syntax</A
 ></DT
 ></DL
@@ -379,7 +379,7 @@ HREF="Bv9ARM.ch06.html#Configuration_File_Grammar"
 ><DL
 ><DT
 >6.2.1. <A
-HREF="Bv9ARM.ch06.html#AEN1319"
+HREF="Bv9ARM.ch06.html#AEN1323"
 ><B
 CLASS="command"
 >acl</B
@@ -396,7 +396,7 @@ Usage</A
 ></DT
 ><DT
 >6.2.3. <A
-HREF="Bv9ARM.ch06.html#AEN1361"
+HREF="Bv9ARM.ch06.html#AEN1365"
 ><B
 CLASS="command"
 >controls</B
@@ -404,7 +404,7 @@ CLASS="command"
 ></DT
 ><DT
 >6.2.4. <A
-HREF="Bv9ARM.ch06.html#AEN1370"
+HREF="Bv9ARM.ch06.html#AEN1374"
 ><B
 CLASS="command"
 >controls</B
@@ -413,7 +413,7 @@ Usage</A
 ></DT
 ><DT
 >6.2.5. <A
-HREF="Bv9ARM.ch06.html#AEN1398"
+HREF="Bv9ARM.ch06.html#AEN1400"
 ><B
 CLASS="command"
 >include</B
@@ -421,7 +421,7 @@ CLASS="command"
 ></DT
 ><DT
 >6.2.6. <A
-HREF="Bv9ARM.ch06.html#AEN1403"
+HREF="Bv9ARM.ch06.html#AEN1405"
 ><B
 CLASS="command"
 >include</B
@@ -430,7 +430,7 @@ Usage</A
 ></DT
 ><DT
 >6.2.7. <A
-HREF="Bv9ARM.ch06.html#AEN1410"
+HREF="Bv9ARM.ch06.html#AEN1412"
 ><B
 CLASS="command"
 >key</B
@@ -438,7 +438,7 @@ CLASS="command"
 ></DT
 ><DT
 >6.2.8. <A
-HREF="Bv9ARM.ch06.html#AEN1417"
+HREF="Bv9ARM.ch06.html#AEN1419"
 ><B
 CLASS="command"
 >key</B
@@ -446,7 +446,7 @@ CLASS="command"
 ></DT
 ><DT
 >6.2.9. <A
-HREF="Bv9ARM.ch06.html#AEN1429"
+HREF="Bv9ARM.ch06.html#AEN1431"
 ><B
 CLASS="command"
 >logging</B
@@ -454,7 +454,7 @@ CLASS="command"
 ></DT
 ><DT
 >6.2.10. <A
-HREF="Bv9ARM.ch06.html#AEN1468"
+HREF="Bv9ARM.ch06.html#AEN1471"
 ><B
 CLASS="command"
 >logging</B
@@ -463,15 +463,31 @@ Usage</A
 ></DT
 ><DT
 >6.2.11. <A
-HREF="Bv9ARM.ch06.html#AEN1662"
+HREF="Bv9ARM.ch06.html#AEN1673"
 ><B
 CLASS="command"
->options</B
+>lwres</B
 > Statement Grammar</A
 ></DT
 ><DT
 >6.2.12. <A
-HREF="Bv9ARM.ch06.html#AEN1838"
+HREF="Bv9ARM.ch06.html#AEN1691"
+><B
+CLASS="command"
+>lwres</B
+> Statement Definition and Usage</A
+></DT
+><DT
+>6.2.13. <A
+HREF="Bv9ARM.ch06.html#AEN1710"
+><B
+CLASS="command"
+>options</B
+> Statement Grammar</A
+></DT
+><DT
+>6.2.14. <A
+HREF="Bv9ARM.ch06.html#AEN1911"
 ><B
 CLASS="command"
 >options</B
@@ -479,7 +495,7 @@ CLASS="command"
 Usage</A
 ></DT
 ><DT
->6.2.13. <A
+>6.2.15. <A
 HREF="Bv9ARM.ch06.html#server_statement_grammar"
 ><B
 CLASS="command"
@@ -488,7 +504,7 @@ CLASS="command"
 Statement Grammar</A
 ></DT
 ><DT
->6.2.14. <A
+>6.2.16. <A
 HREF="Bv9ARM.ch06.html#server_statement_definition_and_usage"
 ><B
 CLASS="command"
@@ -497,16 +513,16 @@ CLASS="command"
 and Usage</A
 ></DT
 ><DT
->6.2.15. <A
-HREF="Bv9ARM.ch06.html#AEN2750"
+>6.2.17. <A
+HREF="Bv9ARM.ch06.html#AEN2829"
 ><B
 CLASS="command"
 >trusted-keys</B
 > Statement Grammar</A
 ></DT
 ><DT
->6.2.16. <A
-HREF="Bv9ARM.ch06.html#AEN2766"
+>6.2.18. <A
+HREF="Bv9ARM.ch06.html#AEN2845"
 ><B
 CLASS="command"
 >trusted-keys</B
@@ -514,23 +530,23 @@ CLASS="command"
 and Usage</A
 ></DT
 ><DT
->6.2.17. <A
-HREF="Bv9ARM.ch06.html#AEN2774"
+>6.2.19. <A
+HREF="Bv9ARM.ch06.html#AEN2853"
 ><B
 CLASS="command"
 >view</B
 > Statement Grammar</A
 ></DT
 ><DT
->6.2.18. <A
-HREF="Bv9ARM.ch06.html#AEN2786"
+>6.2.20. <A
+HREF="Bv9ARM.ch06.html#AEN2867"
 ><B
 CLASS="command"
 >view</B
 > Statement Definition and Usage</A
 ></DT
 ><DT
->6.2.19. <A
+>6.2.21. <A
 HREF="Bv9ARM.ch06.html#zone_statement_grammar"
 ><B
 CLASS="command"
@@ -539,8 +555,8 @@ CLASS="command"
 Statement Grammar</A
 ></DT
 ><DT
->6.2.20. <A
-HREF="Bv9ARM.ch06.html#AEN2902"
+>6.2.22. <A
+HREF="Bv9ARM.ch06.html#AEN3002"
 ><B
 CLASS="command"
 >zone</B
@@ -550,7 +566,7 @@ CLASS="command"
 ></DD
 ><DT
 >6.3. <A
-HREF="Bv9ARM.ch06.html#AEN3213"
+HREF="Bv9ARM.ch06.html#AEN3338"
 >Zone File</A
 ></DT
 ><DD
@@ -562,7 +578,7 @@ HREF="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them"
 ></DT
 ><DT
 >6.3.2. <A
-HREF="Bv9ARM.ch06.html#AEN3533"
+HREF="Bv9ARM.ch06.html#AEN3658"
 >Discussion of MX Records</A
 ></DT
 ><DT
@@ -572,17 +588,17 @@ HREF="Bv9ARM.ch06.html#Setting_TTLs"
 ></DT
 ><DT
 >6.3.4. <A
-HREF="Bv9ARM.ch06.html#AEN3654"
+HREF="Bv9ARM.ch06.html#AEN3779"
 >Inverse Mapping in IPv4</A
 ></DT
 ><DT
 >6.3.5. <A
-HREF="Bv9ARM.ch06.html#AEN3681"
+HREF="Bv9ARM.ch06.html#AEN3806"
 >Other Zone File Directives</A
 ></DT
 ><DT
 >6.3.6. <A
-HREF="Bv9ARM.ch06.html#AEN3738"
+HREF="Bv9ARM.ch06.html#AEN3863"
 ><SPAN
 CLASS="acronym"
 >BIND</SPAN
@@ -612,7 +628,7 @@ HREF="Bv9ARM.ch07.html#Access_Control_Lists"
 ></DT
 ><DT
 >7.2. <A
-HREF="Bv9ARM.ch07.html#AEN3819"
+HREF="Bv9ARM.ch07.html#AEN3954"
 ><B
 CLASS="command"
 >chroot</B
@@ -626,7 +642,7 @@ UNIX servers)</A
 ><DL
 ><DT
 >7.2.1. <A
-HREF="Bv9ARM.ch07.html#AEN3842"
+HREF="Bv9ARM.ch07.html#AEN3977"
 >The <B
 CLASS="command"
 >chroot</B
@@ -634,7 +650,7 @@ CLASS="command"
 ></DT
 ><DT
 >7.2.2. <A
-HREF="Bv9ARM.ch07.html#AEN3857"
+HREF="Bv9ARM.ch07.html#AEN3992"
 >Using the <B
 CLASS="command"
 >setuid</B
@@ -644,8 +660,8 @@ CLASS="command"
 ></DD
 ><DT
 >7.3. <A
-HREF="Bv9ARM.ch07.html#AEN3865"
->Dynamic Updates</A
+HREF="Bv9ARM.ch07.html#dynamic_update_security"
+>Dynamic Update Security</A
 ></DT
 ></DL
 ></DD
@@ -658,26 +674,26 @@ HREF="Bv9ARM.ch08.html"
 ><DL
 ><DT
 >8.1. <A
-HREF="Bv9ARM.ch08.html#AEN3873"
+HREF="Bv9ARM.ch08.html#AEN4012"
 >Common Problems</A
 ></DT
 ><DD
 ><DL
 ><DT
 >8.1.1. <A
-HREF="Bv9ARM.ch08.html#AEN3875"
+HREF="Bv9ARM.ch08.html#AEN4014"
 >It's not working; how can I figure out what's wrong?</A
 ></DT
 ></DL
 ></DD
 ><DT
 >8.2. <A
-HREF="Bv9ARM.ch08.html#AEN3879"
+HREF="Bv9ARM.ch08.html#AEN4018"
 >Incrementing and Changing the Serial Number</A
 ></DT
 ><DT
 >8.3. <A
-HREF="Bv9ARM.ch08.html#AEN3884"
+HREF="Bv9ARM.ch08.html#AEN4023"
 >Where Can I Get Help?</A
 ></DT
 ></DL
@@ -691,14 +707,14 @@ HREF="Bv9ARM.ch09.html"
 ><DL
 ><DT
 >A.1. <A
-HREF="Bv9ARM.ch09.html#AEN3900"
+HREF="Bv9ARM.ch09.html#AEN4039"
 >Acknowledgements</A
 ></DT
 ><DD
 ><DL
 ><DT
 >A.1.1. <A
-HREF="Bv9ARM.ch09.html#AEN3902"
+HREF="Bv9ARM.ch09.html#AEN4041"
 >A Brief History of the <SPAN
 CLASS="acronym"
 >DNS</SPAN
@@ -728,7 +744,7 @@ HREF="Bv9ARM.ch09.html#classes_of_resource_records"
 ></DD
 ><DT
 >A.3. <A
-HREF="Bv9ARM.ch09.html#AEN3941"
+HREF="Bv9ARM.ch09.html#AEN4080"
 >General <SPAN
 CLASS="acronym"
 >DNS</SPAN
@@ -738,7 +754,7 @@ CLASS="acronym"
 ><DL
 ><DT
 >A.3.1. <A
-HREF="Bv9ARM.ch09.html#AEN3944"
+HREF="Bv9ARM.ch09.html#AEN4083"
 >IPv6 addresses (A6)</A
 ></DT
 ></DL
@@ -762,7 +778,7 @@ HREF="Bv9ARM.ch09.html#internet_drafts"
 ></DT
 ><DT
 >A.4.3. <A
-HREF="Bv9ARM.ch09.html#AEN4550"
+HREF="Bv9ARM.ch09.html#AEN4689"
 >Other Documents About <SPAN
 CLASS="acronym"
 >BIND</SPAN
diff --git a/doc/arm/README-SGML b/doc/arm/README-SGML
index ba778922..cfd8c816 100644
--- a/doc/arm/README-SGML
+++ b/doc/arm/README-SGML
@@ -1,6 +1,9 @@
+Copyright (C) 2000  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.7 2000/10/18 01:17:45 scanner Exp $
+Version: $Id: README-SGML,v 1.12 2000/11/18 02:57:24 bwelling Exp $
 
 The entire ARM is in the single file:
 
@@ -24,24 +27,24 @@ 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.
+    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/
+    http://docbook.org/
 
 and buried in:
 
-  http://www.nwalsh.com/docbook/defguide/index.html
+    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/
+    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
@@ -50,8 +53,8 @@ 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">
+    <!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:
@@ -128,7 +131,7 @@ 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
+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.)
@@ -139,26 +142,32 @@ 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
+    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/
+    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
+    /usr/ports/textproc/sgmltools
 
 HOW TO RENDER A DOCUMENT AS HTML or TeX:
 
 o Generate html doc with:
 
-openjade -d ./nominum-docbook-html.dsl \
-     -t sgml \
-     -v /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
-     Bv9ARM-book.xml
+    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
@@ -187,17 +196,15 @@ jade -v -c /usr/pkg/share/sgml/catalog -t sgml \
      ./Bv9ARM-book.xml
 
 Furthermore, since the style sheet subset we define has in it a hard
-coded path to the style sheet is based on you need to modify the
-second line of this file (this needs to be done via configure so we
-are not tripping over each other.)
-
-Where on FreeBSD the second line reads:
-
-<!ENTITY dbstyle SYSTEM "/usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
+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/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
+    <!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
@@ -298,6 +305,7 @@ o add "hugelatex," Enlarge pool sizes, install the jadetex TeX driver
 
   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.
diff --git a/doc/arm/catalog.in b/doc/arm/catalog.in
new file mode 100644
index 00000000..e39b0ca1
--- /dev/null
+++ b/doc/arm/catalog.in
@@ -0,0 +1,6 @@
+CATALOG "@SGMLDIR@/iso8879/catalog"
+CATALOG "@SGMLDIR@/docbook/2.4.1/catalog"
+CATALOG "@SGMLDIR@/docbook/3.0/catalog"
+CATALOG "@SGMLDIR@/docbook/3.1/catalog"
+CATALOG "@SGMLDIR@/jade/catalog"
+CATALOG "@XMLDIR@/catalog"
diff --git a/doc/arm/genhtml.sh.in b/doc/arm/genhtml.sh.in
new file mode 100644
index 00000000..ad739833
--- /dev/null
+++ b/doc/arm/genhtml.sh.in
@@ -0,0 +1,25 @@
+#!/bin/sh
+#
+# Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+# DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+# INTERNET SOFTWARE CONSORTIUM 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: genhtml.sh.in,v 1.4 2000/11/16 00:11:16 gson Exp $
+
+@JADE@ -v \
+    -c @SGMLDIR@/catalog \
+    -t sgml \
+    -d ./nominum-docbook-html.dsl \
+    @SGMLDIR@/docbook/dsssl/modular/dtds/decls/xml.dcl \
+    ./Bv9ARM-book.xml
diff --git a/doc/arm/nominum-docbook-html.dsl b/doc/arm/nominum-docbook-html.dsl.in
index 68e86d4f..3a807465 100644
--- a/doc/arm/nominum-docbook-html.dsl
+++ b/doc/arm/nominum-docbook-html.dsl.in
@@ -1,5 +1,5 @@
 <!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
-<!ENTITY dbstyle SYSTEM "/usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
+<!ENTITY dbstyle SYSTEM "@SGMLDIR@/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
 ]>
 
 <style-sheet>
@@ -107,6 +107,41 @@
 	(normalize "set")  ;; sets are definitely chunks...
 	))
 
+;
+; Add some cell padding to tables so that they don't look so cramped
+; in Netscape.
+;
+; The following definition was cut-and-pasted from dbtable.dsl and the 
+; single line containing the word CELLPADDING was added.
+;
+(element tgroup
+  (let* ((wrapper   (parent (current-node)))
+	 (frameattr (attribute-string (normalize "frame") wrapper))
+	 (pgwide    (attribute-string (normalize "pgwide") wrapper))
+	 (footnotes (select-elements (descendants (current-node)) 
+				     (normalize "footnote")))
+	 (border (if (equal? frameattr (normalize "none"))
+		     '(("BORDER" "0"))
+		     '(("BORDER" "1"))))
+	 (width (if (equal? pgwide "1")
+		    (list (list "WIDTH" ($table-width$)))
+		    '()))
+	 (head (select-elements (children (current-node)) (normalize "thead")))
+	 (body (select-elements (children (current-node)) (normalize "tbody")))
+	 (feet (select-elements (children (current-node)) (normalize "tfoot"))))
+    (make element gi: "TABLE"
+	  attributes: (append
+		       '(("CELLPADDING" "3"))
+		       border
+		       width
+		       (if %cals-table-class%
+			   (list (list "CLASS" %cals-table-class%))
+			   '()))
+	  (process-node-list head)
+	  (process-node-list body)
+	  (process-node-list feet)
+	  (make-table-endnotes))))
+
 </style-specification-body>
 </style-specification>
 <external-specification id="docbook" document="dbstyle">
diff --git a/doc/arm/validate.sh.in b/doc/arm/validate.sh.in
new file mode 100644
index 00000000..86fca685
--- /dev/null
+++ b/doc/arm/validate.sh.in
@@ -0,0 +1,21 @@
+#!/bin/sh
+#
+# Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+# DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+# INTERNET SOFTWARE CONSORTIUM 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: validate.sh.in,v 1.1 2000/11/15 23:42:02 gson Exp $
+
+nsgmls -sv @SGMLDIR@/docbook/dsssl/modular/dtds/decls/xml.dcl \
+       Bv9ARM-book.xml
diff --git a/doc/draft/draft-costanzo-dns-gl-03.txt b/doc/draft/draft-costanzo-dns-gl-03.txt
index c7a526a8..b080a889 100644
--- a/doc/draft/draft-costanzo-dns-gl-03.txt
+++ b/doc/draft/draft-costanzo-dns-gl-03.txt
@@ -69,10 +69,10 @@ EXPIRES IN SIX MONTHS                                             June 2000
    to local domain administrators.
 
    This document resolves the problem of relating host information within
-   the DNS to geographical locations. This definition has been designed to 
-   be easy for the person who administrates DNS for a domain. The author 
-   hopes that the lack of requiring longitude, latitude and elevation 
-   information and merely being able to enter address information, as you 
+   the DNS to geographical locations. This definition has been designed to
+   be easy for the person who administrates DNS for a domain. The author
+   hopes that the lack of requiring longitude, latitude and elevation
+   information and merely being able to enter address information, as you
    would address a postal letter, will mean broad acceptance and use of the
    GL resource record.
 
@@ -86,7 +86,7 @@ EXPIRES IN SIX MONTHS                                             June 2000
 
    Although several other attempts by various authors have attempted to
    created resource records that would allow location information on host to
-   be stored and distributed, none, to the authors knowledge, have either 
+   be stored and distributed, none, to the authors knowledge, have either
    gained acceptance on a wide scale or made allowance for location information
    that is not within the confines of the planet Earth.
 
@@ -104,7 +104,7 @@ EXPIRES IN SIX MONTHS                                             June 2000
    <string> <string>
 
    The format of the RDATA field is two varying length strings separated by
-   a space character. The first, the hierarchical locator, then an address 
+   a space character. The first, the hierarchical locator, then an address
    string. Each is quoted (like all strings) only when it has spaces in it,
    which will never be true for the first string, and almost always for the
    second.
@@ -128,7 +128,7 @@ by a period "."):
 
   Astronomical Location -                          (Required)
            A coded field defining the heavenly body within
-           the known Universe, where the machine resides.  The most common 
+           the known Universe, where the machine resides.  The most common
            entry, "S3" is the planet Earth and is the only currently
            defined location.
 
@@ -141,10 +141,10 @@ by a period "."):
   Country Code -                                    (Required)
 
           The country code specifies the country the host computer resides
-          in. The code is a two character fixed length string and may only 
+          in. The code is a two character fixed length string and may only
           be included within the Astronimical Location 'S3'.  These codes
           are defined in document ISO 3166-1 and are listed in Appendix A
-          for easy reference. 
+          for easy reference.
 
    Postal Zone -                                    (Optional)
 
@@ -156,8 +156,8 @@ by a period "."):
           This field may be omitted only if the country in which the host
           machine resides does not use a postal coding system.
 
-          When all three Hierarchical Locator components exist for an DNS 
-          entry, the position being defined is considered to be a "precise 
+          When all three Hierarchical Locator components exist for an DNS
+          entry, the position being defined is considered to be a "precise
           position".
 
 
@@ -263,9 +263,9 @@ Parimaribo"
 
    New Astronomical Locations (ALs)  MUST be registered with the Internet
    Assigned Numbers Authority (IANA).  IANA acts as a central registry for
-   these values. IANA may reject or modify the Astronomical Location 
-   registration request if it does not meet the criteria as specified in 
-   section 4.1.1.  
+   these values. IANA may reject or modify the Astronomical Location
+   registration request if it does not meet the criteria as specified in
+   section 4.1.1.
 
    Registration requests should be sent via electronic mail to IANA as
    follows:
@@ -273,7 +273,7 @@ Parimaribo"
              To:  IANA@iana.org
              Subject:  Registration of a new Astronomical Location
 
-   The mail message must specify the proposed AL. Documentation defining 
+   The mail message must specify the proposed AL. Documentation defining
    the AL and its proposed purpose must be included.  The documentation must
    either reference an external non-Internet standards document or an existing
    or soon to be RFC.  If applicable, the documentation should contain a
@@ -281,8 +281,8 @@ Parimaribo"
    RFC according to the normal procedure within a reasonable amount of
    time after the AL registration has been approved.
 
-   IANA will not register a new Astronmical Location until an actual 
-   computer requiring GL data in the DNS resides or will soon reside on a 
+   IANA will not register a new Astronmical Location until an actual
+   computer requiring GL data in the DNS resides or will soon reside on a
    heavenly body other than Earth.
 
 
@@ -305,8 +305,8 @@ EXPIRES IN SIX MONTHS                                              May 2000
 7.1 Defining New Astronimical Locations
 
   The astronomical location 'S3' is intended to be Sol-Three (i.e. the Earth).
-  The Earth is the 3rd large planet in the solar system. The Sun would be S0 
-  (not that we'd have a computer there), but a solar observatory in orbit might 
+  The Earth is the 3rd large planet in the solar system. The Sun would be S0
+  (not that we'd have a computer there), but a solar observatory in orbit might
   be S0-001. Our moon would be S3-1. Other letters and such for catalogued
   objects. Additionally, the ISS and Mir space stations could use S3-001 (Mir),
   S3-002 (ISS) now,   if they get connected on IP.
@@ -318,12 +318,12 @@ EXPIRES IN SIX MONTHS                                              May 2000
 7.2 Other possible uses for GL
 
   The use of postal codes also is exactly what is needed for credit card address
-  authentication. Sites could (quietly) compare GL info provided on entries from 
+  authentication. Sites could (quietly) compare GL info provided on entries from
   ISPs to what someone enters for additional verification purposes.
 
 
 
-  
+
 
 
 
diff --git a/doc/draft/draft-ietf-dhc-dhcp-dns-12.txt b/doc/draft/draft-ietf-dhc-dhcp-dns-12.txt
index c97ba625..d2424d07 100644
--- a/doc/draft/draft-ietf-dhc-dhcp-dns-12.txt
+++ b/doc/draft/draft-ietf-dhc-dhcp-dns-12.txt
@@ -128,7 +128,7 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
    and PTR. The A RR contains mapping from a FQDN to an IP address; the
    PTR RR contains mapping from an IP address to a FQDN.  The Dynamic
    DNS Updates specification (RFC2136[5]) describes a mechanism that
-   enables DNS information to be updated over a network. 
+   enables DNS information to be updated over a network.
 
    DHCP RFC2131[3] provides a mechanism by which a host (a DHCP client)
    can acquire certain configuration information, along with its IP
@@ -180,7 +180,7 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
    The only difference between these two cases is whether the FQDN to
    IP address mapping is updated by a DHCP client or by a DHCP server.
    The IP address to FQDN mapping is updated by a DHCP server in both
-   cases. 
+   cases.
 
    The reason these two are important, while others are unlikely, has
    to do with authority over the respective DNS domain names. A DHCP
@@ -202,13 +202,13 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
    to modify its own domain name. Compliant implementations MAY support
    some or all of these possibilities. Furthermore, this specification
    applies only to DHCP client and server processes: it does not apply
-   to other processes which initiate dynamic DNS updates. 
+   to other processes which initiate dynamic DNS updates.
 
    This document describes a new DHCP option which a client can use to
    convey all or part of its domain name to a DHCP server.
    Site-specific policy determines whether DHCP servers use the names
    that clients offer or not, and what DHCP servers may do in cases
-   where clients do not supply domain names. 
+   where clients do not supply domain names.
 
 4. Issues with DDNS in DHCP Environments
 
@@ -245,7 +245,7 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
    would have its original A RR replaced by the new record. Either of
    these effects may be considered undesirable by some sites. Different
    authority and credential models have different levels of exposure to
-   name collisions. 
+   name collisions.
 
    1.  Client updates A RR, uses Secure DNS Update with credentials
        that are associated with the client's FQDN, and exclusive to the
@@ -356,7 +356,7 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
    is used when the client's link-layer address is being used to
    identify it, and one that is used when some DHCP option that the
    DHCP client has sent is being used to identify it.
-      
+
 
       DISCUSSION:
       Implementors should note that the actual identifying data is
@@ -444,7 +444,7 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
    allow the client to convey its FQDN to the server this document
    defines a new DHCP option, called "Client FQDN". The FQDN Option
    also contains Flags and RCode fields which DHCP servers can use to
-   convey information about DNS updates to clients. 
+   convey information about DNS updates to clients.
 
    Clients MAY send the FQDN option, setting appropriate Flags values,
    in both their DISCOVER and REQUEST messages. If a client sends the
@@ -456,7 +456,7 @@ Stapp & Rekhter          Expires September 2000                 [Page 8]
 Internet-Draft      Interaction between DHCP and DNS          March 2000
 
 
-   subsequent REQUEST messages. 
+   subsequent REQUEST messages.
 
    The code for this option is 81. Its minimum length is 4.
 
@@ -481,12 +481,12 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
    indicate that it will not perform any Dynamic DNS updates, and that
    it expects the DHCP server to perform any FQDN-to-IP (the A RR) DNS
    update on its behalf. If this bit is clear, the client indicates
-   that it intends to maintain its own FQDN-to-IP mapping update. 
+   that it intends to maintain its own FQDN-to-IP mapping update.
 
    If a DHCP server intends to take responsibility for the A RR update
    whether or not the client sending the FQDN option has set the "S"
    bit, it sets both the "O" bit and the "S" bit, and sends the FQDN
-   option in its DHCPOFFER and/or DHCPACK messages. 
+   option in its DHCPOFFER and/or DHCPACK messages.
 
    The data in the Domain Name field may appear in one of two formats:
    ASCII, or DNS-style binary encoding (without compression, of
@@ -497,12 +497,12 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
    reply, it MUST use the same encoding that the client used. The DNS
    encoding is recommended. The use of ASCII-encoded domain-names is
    fragile, and the use of ASCII encoding in this option should be
-   considered deprecated. 
+   considered deprecated.
 
    The remaining bits in the Flags field are reserved for future
    assignment. DHCP clients and servers which send the FQDN option MUST
    set the MBZ bits to 0, and they MUST ignore values in the part of
-   the field labelled "MBZ". 
+   the field labelled "MBZ".
 
 
 
@@ -670,7 +670,7 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
    described in Section 8. The server MAY originate the update before
    the server sends the DHCPACK message to the client. In this case the
    RCODE from the update [RFC2136] MUST be carried to the client in the
-   RCODE2 field of the Client FQDN option in the DHCPACK message. 
+   RCODE2 field of the Client FQDN option in the DHCPACK message.
    Alternatively the server MAY send the DHCPACK message to the client
    without waiting for the update to be completed. In this case the
 
@@ -794,7 +794,7 @@ Internet-Draft      Interaction between DHCP and DNS          March 2000
 
    existing A RR and the existing DHCID RR, adding A and DHCID RRs that
    represent the IP address and client-identity of the new client.
-      
+
 
       DISCUSSION:
       The updating entity may be configured to allow the existing DNS
diff --git a/doc/draft/draft-ietf-dnsext-ad-is-secure-00.txt b/doc/draft/draft-ietf-dnsext-ad-is-secure-00.txt
new file mode 100644
index 00000000..7829b82e
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-ad-is-secure-00.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+
+DNSEXT Working Group                       Brian Wellington    (Nominum)
+INTERNET-DRAFT                             Olafur Gudmundsson (NAI Labs)
+<draft-ietf-dnsext-ad-is-secure-00.txt>                    November 2000
+
+Updates: RFC 2535
+
+                       Redefinition of DNS AD bit
+
+
+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
+
+   Comments should be sent to the authors or the DNSEXT WG mailing list
+   namedroppers@ops.ietf.org
+
+   This draft expires on May 17, 2001.
+
+   Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All rights reserved.
+
+
+
+Abstract
+
+   Based on implementation experience, the current definition of the AD
+   bit in the DNS header is not useful. This draft changes the
+   specification so that the AD bit is only set on answers where
+   signatures have been cryptographically verified.
+
+
+
+
+Expires May 2001                                                [Page 1]
+
+INTERNET-DRAFT        AD bit set on secure answers         November 2000
+
+
+1 - Introduction
+
+   Familiarity with the DNS system [RFC1034, RFC1035] and DNS security
+   extensions [RFC2535] is helpful but not necessary.
+
+   As specified in RFC 2535 (section 6.1), the AD 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. This is not especially
+   useful in practice, since a conformant server should never reply with
+   data that failed its security policy.
+
+   This draft proposes to redefine the AD bit such that it is only set
+   if all data in the response has been cryptographically verified.
+   Thus, a response containing properly delegated insecure data will not
+   have AD set, as will a response from a server configured without
+   DNSSEC keys.  As before, data which failed to verify will not be
+   returned.  An application can then use the value of the AD bit to
+   determine if the data is secure or not.
+
+1.1 - Requirements
+
+   The key words "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
+   document are to be interpreted as described in RFC2119.
+
+
+1.2 - Updated documents and sections
+
+   The definition of the AD bit in RFC2535, Section 6.1, is changed.
+
+2 - Setting of AD bit
+
+   Section 6.1 of RFC2535 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 changes are to delete the words "either" and "or Insecure" from
+   the sentence.
+
+   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."
+
+
+
+
+
+
+Expires May 2001                                                [Page 2]
+
+INTERNET-DRAFT        AD bit set on secure answers         November 2000
+
+
+   If the answer section contains any data, the server MUST NOT include
+   data in the authority section that would cause the AD bit to be
+   unset.
+
+   The AD bit MUST NOT be set on a response unless all of the RRsets in
+   the answer and authority sections are Authenticated.
+   A resolver MUST NOT blindly trust the AD bit unless it communicates
+   with the server over secure transport mechanism or using message
+   authentication such as TSIG[RFC2845] or SIG(0)[RFC2931], and the
+   resolver policy is that it can trust the server.
+
+   A DNS server following this modified specification will only set the
+   AD bit when it has verified the data in the answer.  In the case of a
+   primary server for a secure zone, the data MAY be considered
+   Authenticated, depending on local policy.  Secondary servers SHOULD
+   NOT consider data Authenticated unless the zone was transfered
+   securely or the data was verified.
+
+3 - Interpretation of the AD bit
+
+   A response containing data marked Insecure in the answer or authority
+   section will never have the AD bit set.  In this case, the resolver
+   SHOULD treat the data as Insecure whether or not SIG records are
+   present.
+
+4 - 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 server is
+   using the updated definition.
+
+5 - IANA Considerations:
+
+   None
+
+6 - Acknowledgments:
+
+   The following people have provided input on this document: Andreas
+   Gustafsson, Bob Halley, Steven Jacob,
+
+References:
+
+[RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
+           Specification'', STD 13, RFC 1035, November 1987.
+
+
+[RFC2535]  D. Eastlake, ``Domain Name System Security Extensions'', RFC
+           2535, March 1999.
+
+
+
+Expires May 2001                                                [Page 3]
+
+INTERNET-DRAFT        AD bit set on secure answers         November 2000
+
+
+[RFC2845]  P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
+           ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC
+           2845, May 2000.
+
+[RFC2931]  D. Eastlake, ``DNS Request and Transaction Signatures
+           (SIG(0))'', RFC 2931, September 2000.
+
+
+Authors Addresses
+
+      Brian Wellington                        Olafur Gudmundsson
+      Nominum Inc.                            NAI Labs
+      950 Charter Street                      3060 Washington Road (Rt. 97)
+      Redwood City, CA, 94063                 Glenwood, MD, 21738
+      USA                                     USA
+      +1 650 381 6022                         +1 443 259 2389
+      <Brian.Wellington@nominum.com>          <ogud@tislabs.com>
+
+
+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."
+
+
+
+
+
+Expires May 2001                                                [Page 4]
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-00.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt
index b9988762..7c1d45e5 100644
--- a/doc/draft/draft-ietf-dnsext-axfr-clarify-00.txt
+++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt
@@ -1,7 +1,6 @@
-
 INTERNET-DRAFT                                      Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-00.txt                     Nominum Inc.
-                                                            March 2000
+draft-ietf-dnsext-axfr-clarify-01.txt                     Nominum Inc.
+                                                         November 2000
 
 
                DNS Zone Transfer Protocol Clarifications
@@ -19,7 +18,7 @@ Status of this Memo
 
    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
+   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
@@ -50,9 +49,9 @@ Abstract
 
 
 
-Expires September 2000                                          [Page 1]
+Expires May 2001                                                [Page 1]
 
-draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
+draft-ietf-dnsext-axfr-clarify-01.txt                      November 2000
 
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -66,6 +65,10 @@ draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
    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
@@ -99,17 +102,17 @@ draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
    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
 
 
+Expires May 2001                                                [Page 2]
+
+draft-ietf-dnsext-axfr-clarify-01.txt                      November 2000
 
 
-Expires September 2000                                          [Page 2]
-
-draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
+   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
@@ -121,8 +124,9 @@ draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
        AA      1 (but MAY be 0 when RCODE is nonzero)
        TC      0
        RD      Copy from request
-       RA      Set according to availability of recursion
-       Z       000
+       RA      Set according to availability of recursion S    Z       0
+       AD      0
+       CD      0
        RCODE   0 or error code
 
    The slave MUST check the RCODE and abort the transfer if it is
@@ -154,29 +158,47 @@ draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
    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.
 
 
 
-Expires September 2000                                          [Page 3]
+Expires May 2001                                                [Page 3]
 
-draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
+draft-ietf-dnsext-axfr-clarify-01.txt                      November 2000
 
 
-4. Glue
+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.
 
-   Zone transfers MAY contain glue RRs pertaining to NS records in the
-   zone.  An RR is considered a glue RR when it is not within the zone
-   being transferred.  A slave MUST recognize glue RRs as such; it MUST
-   NOT treat them as authoritative data.
+4. Glue
 
-   Note that classifying an RR as glue or non-glue may not be possible
-   until the entire zone has been received so that the zone cuts defined
-   by the zone's NS records can be determined.
+   A master transmitting a zone transfer MUST include the full set of
+   zone data it loaded from the zone's master file, from an incoming
+   zone transfer, or other similar means of configuring zone data.  This
+   includes any nonauthoritative data ("glue") associated with the zone
+   by being present in the zone's master file or the incoming transfer
+   along with the authoritative data.  This glue data includes any
+   configured zone data obscured by zone cuts or otherwise outside the
+   zone in case; it is not limited to RRs pointed to by NS records.
+
+   The glue RRs are transmitted in the answer section along with the
+   authoritative data.  This is unlike ordinary DNS responses where glue
+   is transmitted in the authority or additional section.
+
+   Zone transfers MUST NOT contain RRs from the authoritative data of
+   zones other than the one being transferred or from the cache, even
+   when such RRs are pointed to by NS records in the zone being
+   transferred.
+
+   A slave receiving a zone transfer MUST accept glue data and recognize
+   it as such; glue MUST NOT be treated as authoritative data nor
+   entered into the cache.  Note that classifying an RR as glue or non-
+   glue may not be possible until the entire zone has been received so
+   that the zone cuts defined by the zone's NS records can be
+   determined.  Glue data that is not below the zone origin ("cross-zone
+   glue") MAY be discarded by the slave.
 
 5. Transmission order
 
@@ -192,11 +214,36 @@ draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
 
    The initial and final SOA record MUST be identical, with the possible
    exception of case and compression.  In particular, they MUST have the
+
+
+
+Expires May 2001                                                [Page 4]
+
+draft-ietf-dnsext-axfr-clarify-01.txt                      November 2000
+
+
    same serial number.
 
    The transmission order of all other RRs in the zone, including glue
    records, is undefined.
 
+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 TSIG [RFC2845] for this
+   purpose 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.
+
 References
 
    [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
@@ -205,8 +252,11 @@ References
    [RFC1035] - Domain Names - Implementation and Specifications, P.
    Mockapetris, November 1987.
 
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", BCP 14, RFC 2119, March 1997.
+   [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
 
@@ -216,16 +266,16 @@ Author's Address
    Redwood City, CA 94063
    USA
 
+   Phone: +1 650 779 6004
 
+   Email: gson@nominum.com
 
-Expires September 2000                                          [Page 4]
-
-draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
 
 
-   Phone: +1 650 779 6004
 
-   Email: gson@nominum.com
+Expires May 2001                                                [Page 5]
+
+draft-ietf-dnsext-axfr-clarify-01.txt                      November 2000
 
 
 Full Copyright Statement
@@ -274,5 +324,10 @@ Full Copyright Statement
 
 
 
-Expires September 2000                                          [Page 5]
+
+
+
+
+
+Expires May 2001                                                [Page 6]
 
diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-00.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-00.txt
new file mode 100644
index 00000000..b6386e27
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-00.txt
@@ -0,0 +1,336 @@
+Network Working Group                                      A. Gustafsson
+Internet-Draft                                                  T. Lemon
+Expires: January 12, 2001                                  Nominum, Inc.
+                                                                 M. Stapp
+                                                      Cisco Systems, Inc.
+                                                            July 14, 2000
+
+
+                  A DNS RR for encoding DHCP information
+                   <draft-ietf-dnsext-dhcid-rr-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."
+
+    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 12, 2001.
+
+Copyright Notice
+
+    Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+    A situation can arise where multiple DHCP clients request the same
+    DNS name from their (possibly distinct) DHCP servers.  To resolve
+    such conflicts, 'Resolution of DNS Name Conflicts'[7] proposes
+    storing client identifiers in the DNS to unambiguously associate
+    domain names with the DHCP clients "owning" them. This memo defines
+    a distinct RR type for use by DHCP servers, the "DHCID" RR.
+
+
+
+
+
+
+Gustafsson, et. al.     Expires January 12, 2001                [Page 1]
+
+Internet-Draft    A DNS RR for encoding DHCP information       July 2000
+
+
+Table of Contents
+
+    1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+    2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+    3.  The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . .  3
+    4.  DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . .  3
+    4.1 Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
+    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
+        References . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
+        Full Copyright Statement . . . . . . . . . . . . . . . . . . .  6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gustafsson, et. al.     Expires January 12, 2001                [Page 2]
+
+Internet-Draft    A DNS RR for encoding DHCP information       July 2000
+
+
+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[1].
+
+2. Introduction
+
+    A set of procedures to allow DHCP [RFC2131] clients and servers to
+    automatically update the DNS (RFC1034[2], RFC1035[3]) is proposed in
+    Resolution of DNS Name Conflicts[7].
+
+    A situation can arise where multiple DHCP clients wish to use the
+    same DNS name. To resolve such conflicts, Resolution of DNS Name
+    Conflicts[7] proposes storing client identifiers in the DNS to
+    unambiguously associate domain names with the DHCP clients using
+    them. In the interest of clarity, it would be preferable for this
+    DHCP information to use a distinct RR type.
+
+    This memo defines a distinct RR type for this purpose for use by
+    DHCP clients or servers, the "DHCID" RR.
+
+3. The DHCID RR
+
+    The DHCP RR is defined with mnemonic DHCID and type code [TBD].
+
+4. DHCID RDATA format
+
+    The RDATA section of a DHCID RR in transmission contains RDLENGTH
+    bytes 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.  In DNS
+    master files, the RDATA is represented as a hexadecimal string with
+    an optional "0x" or "0X" prefix.  Periods (".") may be inserted
+    anywhere after the "0x" for readability.  This format is identical
+    to that of the NSAP RR (RFC1706[4]). The number of hexadecimal
+    digits MUST be even.
+
+    DHCP clients or servers use the DHCID RR to associate a DHCP
+    client's identity with a DNS name, so that multiple DHCP clients and
+    servers may safely perform dynamic DNS updates to the same zone.
+    From the updater's perspective, the DHCID resource record consists
+    of a 16-bit identifier type, followed by one or more bytes
+    representing the actual identifier.  There are two possible forms
+    for a DHCID RR - one that is used when the DHCP server is using the
+    client's link-layer address to identify it, and one that is used
+    when the DHCP server is using some DHCP option that the DHCP client
+    sent to identify it. When the link-layer address is used as the
+
+
+Gustafsson, et. al.     Expires January 12, 2001                [Page 3]
+
+Internet-Draft    A DNS RR for encoding DHCP information       July 2000
+
+
+    identifier, the first two bytes of the RRDATA are set to 0. When a
+    DHCP option is used as the identifier, the first two bytes of the
+    RRDATA contain the option number, in network byte order. The two
+    bytes 0xffff are reserved. In both cases, the remainder of the
+    RRDATA is the result of performing a one-way hash across the
+    identifier.
+
+    The details of the method used to generate the data in the RR and
+    the use to which a DHCP client or server may put this association
+    are beyond the scope of this draft, and are discussed in the draft
+    that specifies the DNS update behavior, 'Resolution of DNS Name
+    Conflicts'[7]. This RR MUST NOT be used for any purpose other than
+    that detailed in the DHC document. Althought this RR contains data
+    that is opaque to DNS servers, the data is meaningful to DHCP
+    updaters. Therefore, new data formats may only be defined through
+    actions of the DHC Working Group.
+
+4.1 Example
+
+    A DHCP server allocating the IPv4 address 10.0.0.1 to a client
+    "client.org.nil" might use the client's link-layer address to
+    identify the client:
+
+      client.org.nil. A    10.0.0.1
+      client.org.nil. DHCID 
+00.00.18.29.11.17.22.0a.ad.c1.88.10.a3.dd.ff.c8.d9.49
+
+    A DHCP server allocating the IPv4 address 10.0.12.99 to a client
+    "chi.org.nil" might use the DHCP client identifier option to
+    identify the client:
+
+      chi.org.nil. A    10.0.12.99
+      chi.org.nil. DHCID 00.61.92.71.22.da.01.88.dd.3a.11.8c.1c.a0.ff.94.9d.81
+
+5. Security Considerations
+
+    The DHCID record as such does not introduce any new security
+    problems into the DNS.  In order to avoid exposing private
+    information about DHCP clients to public scrutiny, a one-way-hash is
+    used to obscure all client information.
+
+6. IANA Considerations
+
+    The IANA is requested to allocate an RR type number for the DHCP
+    record type.
+
+References
+
+    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", RFC 2119, March 1997.
+
+
+Gustafsson, et. al.     Expires January 12, 2001                [Page 4]
+
+Internet-Draft    A DNS RR for encoding DHCP information       July 2000
+
+
+    [2]  Mockapetris, P., "Domain names - Concepts and Facilities", RFC
+         1034, Nov 1987.
+
+    [3]  Mockapetris, P., "Domain names - Implementation and
+         Specification", RFC 1035, Nov 1987.
+
+    [4]  Manning, B. and R. Colella, "DNS NSAP Resource Records", RFC
+         1706, Oct 1994.
+
+    [5]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar
+         1997.
+
+    [6]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+         Extensions", RFC 2132, Mar 1997.
+
+    [7]  Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
+         (draft-ietf-dhc-dns-resolution-*)", July 2000.
+
+
+Authors' Addresses
+
+    Andreas Gustafsson
+    Nominum, Inc.
+    950 Charter St.
+    Redwood City, CA  94063
+    USA
+
+    EMail: gson@nominum.com
+
+
+    Ted Lemon
+    Nominum, Inc.
+    950 Charter St.
+    Redwood City, CA  94063
+    USA
+
+    EMail: mellon@nominum.com
+
+
+    Mark Stapp
+    Cisco Systems, Inc.
+    250 Apollo Dr.
+    Chelmsford, MA  01824
+    USA
+
+    Phone: 978.244.8498
+    EMail: mjs@cisco.com
+
+
+
+
+Gustafsson, et. al.     Expires January 12, 2001                [Page 5]
+
+Internet-Draft    A DNS RR for encoding DHCP information       July 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gustafsson, et. al.     Expires January 12, 2001                [Page 6]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dnsmib-historical-00.txt b/doc/draft/draft-ietf-dnsext-dnsmib-historical-00.txt
new file mode 100644
index 00000000..f8dbb52e
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnsmib-historical-00.txt
@@ -0,0 +1,226 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+draft-ietf-dnsext-dnsmib-historical-00.txt       InterNetShare.com, Inc.
+                                                            October 2000
+
+
+             Applicability Statement for DNS MIB Extensions
+
+
+Status of this document
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC 2026.
+
+   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>
+
+   Distribution of this document is unlimited.  Please send comments to
+   the Namedroppers mailing list <namedroppers@ops.ietf.org>.
+
+Abstract
+
+   More than six years after the DNS Server and Resolver MIB extensions
+   became proposed standards, there still has not been any significant
+   deployment of these MIB extensions.  This note examines the reasons
+   why these MIB extensions were never deployed, and recommends retiring
+   these MIB extensions by moving them to Historical status.
+
+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
+
+
+
+Austein                    Expires 2 May 2001                   [Page 1]
+
+draft-ietf-dnsext-dnsmib-historical-00.txt                  October 2000
+
+
+   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 accrete 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
+   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 sigh, 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.
+
+
+
+
+Austein                    Expires 2 May 2001                   [Page 2]
+
+draft-ietf-dnsext-dnsmib-historical-00.txt                  October 2000
+
+
+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.
+
+   - If the entire project is taking too long, perhaps that's a hint
+     too.
+
+
+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.
+
+Security Considerations
+
+   Getting rid of the DNS MIB extensions undoubtedly closes a few
+   security holes, or would if anybody had ever implemented them.
+
+IANA Considerations
+
+   Getting rid of the DNS MIB extensions should not impose any new work
+   on IANA.
+
+Acknowledgments
+
+   The author would like to thank all the people who were involved in
+   this silly project over the years for their optimism and patience,
+   misguided though it may have been.
+
+References
+
+   [DNS-SERVER-MIB]  Austein, R., and Saperia, J., "DNS Server MIB
+        Extensions", RFC 1611, May 1994.
+
+
+
+
+
+Austein                    Expires 2 May 2001                   [Page 3]
+
+draft-ietf-dnsext-dnsmib-historical-00.txt                  October 2000
+
+
+   [DNS-RESOLVER-MIB]  Austein, R., and Saperia, J., "DNS Resolver MIB
+        Extensions", RFC 1612, May 1994.
+
+   [DNS-DYNAMIC-UPDATE] Vixie,  P., Ed., Thomson, S., Rekhter, Y., and
+        Bound, J., "Dynamic Updates in the Domain Name System (DNS
+        UPDATE)", RFC 2136, April 1997.
+
+   [AGENTX] Daniele, M., Wijnen, B., Ellison, M., and Francisco, D.,
+        "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741,
+        January 2000.
+
+Author's addresses:
+
+      Rob Austein
+      InterNetShare.com, Inc.
+      505 West Olive Ave., Suite 321
+      Sunnyvale, CA 94086
+      USA
+      sra@hactrn.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                    Expires 2 May 2001                   [Page 4]
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-okbit-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-okbit-01.txt
new file mode 100644
index 00000000..f84a21ce
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-okbit-01.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                            David Conrad
+draft-ietf-dnsext-dnssec-okbit-01.txt                     Nominum Inc.
+                                                        November, 2000
+
+                 Indicating Resolver Support of DNSSEC
+
+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 order to deploy DNSSEC 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 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.
+
+
+
+Expires May, 2001                                               [Page 1]
+
+draft-ietf-dnsext-dnssec-okbit-01.txt                     November, 2000
+
+
+   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.
+
+   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
+
+   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
+
+
+
+Expires May, 2001                                               [Page 2]
+
+draft-ietf-dnsext-dnssec-okbit-01.txt                     November, 2000
+
+
+   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 existance 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.
+
+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 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).
+
+   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
+
+
+
+Expires May, 2001                                               [Page 3]
+
+draft-ietf-dnsext-dnssec-okbit-01.txt                     November, 2000
+
+
+   DNSSEC security RRs and SHOULD retry the query without the EDNS0 in
+   accordance with section 5.3 of [RFC2671].
+
+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
+
+   Allocation of the most significant bit of the Z field in the EDNS0
+   OPT meta-RR is required.
+
+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, and Steve Bellovin.
+
+References
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+   RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+   Specifications", 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
+
+Author's Address
+
+   David Conrad
+   Nominum Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+   USA
+
+   Phone: +1 650 779 6003
+
+
+
+
+Expires May, 2001                                               [Page 4]
+
+draft-ietf-dnsext-dnssec-okbit-01.txt                     November, 2000
+
+
+   Email: david.conrad@nominum.com
+
+
+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 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
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May, 2001                                               [Page 5]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt
new file mode 100644
index 00000000..22ec053a
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt
@@ -0,0 +1,661 @@
+
+
+
+
+
+
+DNEXT Working Group                                             S. Rose
+Internet Draft                                                     NIST
+Expires: February 2001                                      August 2000
+Category: Informational
+
+
+
+
+               DNS Security Document Roadmap
+               ------------------------------
+         <draft-ietf-dnsext-dnssec-roadmap-00.txt>
+
+
+Status of this Document
+
+   This document is an Internet-Draft and is in full
+   conformance with all provisions of Section 10 of RFC2026.
+   Distribution of this document is unlimited.  Comments
+   regarding this document should be sent to the author.
+
+   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
+
+   DNS Security (DNSSEC)technology is composed of extensions
+   to the Domain Name System (DNS) protocol that provide
+   data integrity and authentication to security aware
+   resolvers and applications through the use of
+   cryptographic digital signatures.  Several documents
+   exist to describe these extensions and the implementation
+   specific details regarding specific digital signing
+   schemes.  The interrelationship between these different
+   documents is discussed here.  A brief overview of what to
+
+
+
+Rose                                                            [Page 1]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+   find in which document and author guidelines for what to
+   include in new DNS Security documents, or revisions to
+   existing documents, is described.
+
+
+
+
+
+                          
+
+
+
+   1.  Introduction ...............................................    3
+   2.  Interrelationship of DNS Security Documents ................    3
+   3.  Relationship of DNS Security Documents to other DNS Docu-
+   ments ..........................................................    6
+   4.  Recommended Content for new DNS Security Documents .........    6
+   4.1  Security Related Resource Records .........................    6
+   4.2  Digital Signature Algorithm Implementation ................    7
+   4.3  Refinement of Security Procedures .........................    7
+   4.4  The Use of DNS Security Extensions with Other Protocols
+   ................................................................    8
+   5.  Security Considerations ....................................    8
+   6.  Acknowledgements ...........................................    8
+   7.  References .................................................    9
+   8.  Author's Address ...........................................   10
+   Expiration and File Name .......................................   10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                                                            [Page 2]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+1. Introduction
+
+   This document is intended to provide guidelines for the development
+   of supplemental documents describing security extensions to the
+   Domain Name System (DNS).
+
+   The main goal of the DNS Security (DNSSEC) protocol extensions is to
+   add data authentication and integrity services to the DNS protocol.
+   These protocol extensions should be differentiated from DNS opera-
+   tional security issues, which are beyond the scope of this effort.
+   DNS Security documents fall into one or possibly more of the follow-
+   ing sub-categories: new DNS security resource records, implementation
+   details of specific digital signing algorithms for use in DNS Secu-
+   rity and Secure DNS transactions.  Since the goal of DNS Security
+   extensions is to become part of the DNS protocol standard, additional
+   documents that seek to refine a portion of the security extensions
+   will be introduced as the specifications progress along the IETF
+   standards track.
+
+   There is a set of basic guidelines for each sub-category of documents
+   that explains what should be included, what should be considered a
+   protocol extension, and what should be considered an operational
+   issue.  Currently, there are at least two documents that fall under
+   operational security considerations that deal specifically with the
+   DNS security extensions:  The first is RFC 2541 which deals with the
+   operational side of implementing the security extensions.  The other
+   is the CAIRN DNSSEC testbed Internet draft [CAIRN].  These documents
+   should be considered part of the operational side of DNS, but will be
+   addressed as a supplemental part of the DNS Security roadmap.  That
+   is not to say that these two documents are not important to securing
+   a DNS zone, but it does not directly address the proposed DNS secu-
+   rity extensions.  Authors of documents that seek to address the
+   operational concerns of DNS security should be aware of the structure
+   of DNS Security documentation if they wish to include their documents
+   in the DNSEXT Working Group in addition to the DNS Operations WG.
+
+   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].  It is
+   also assumed the reader has some knowledge of the Domain Name System
+   [RFC1035] and the Domain Name System Security Extensions [RFC2535].
+
+
+2. Interrelationship of DNS Security Documents
+
+   The DNSSEC set of documents can be partitioned into five main groups
+   as depicted in Figure 1.  All of these documents in turn are under
+   the larger umbrella group of DNS base protocol documents.  It is
+
+
+
+Rose                                                            [Page 3]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+   possible that some documents fall into more than one of these
+   categories, such as RFC 2535, and should follow the guidelines for
+   the all of the document groups it falls into.  However, it is wise to
+   limit the number of "uberdocuments" that try to be everything to
+   everyone.  The documents listed in each category are current as to
+   the time of writing.
+
+
+                    +--------------------------------+
+                    |                                |
+                    |    Base DNS Protocol Docs.     |
+                    |   [RFC1035, RFC2181, etc.]     |
+                    |                                |
+                    +--------------------------------+
+                                    |
+                                    |
+                                    |
+      +------------+          +-----------+          +-------------+
+      |  New       |          |  DNSSEC   |          |  New        |
+      |  Security  | <------->|  protocol |<-------->|  Security   |
+      |  RRs       |          |           |          |  Uses       |
+      | [RFC2538,  |          | [RFC2535, |          |             |
+      |  SIG0 NO]  |          |  CLARIFY, |          +-------------+
+      +------------+          |  AUTH,    |
+                              |  SIZE ]   |
+                              +-----------+
+                                    |
+                                    |
+             +----------------------+***********************
+             |                      |                      *
+             |                      |                      *
+       +------------+       +---------------+      +-*-*-*-*-*-*-*-*-+
+       |  DS        |       |               |      | Implementation  |
+       |  Algorithm |       |  Transactions |      * Notes           *
+       |  Impl.     |       |               |      |                 |
+       | [RFC2536,  |       |  [RFC2845,    |      *  [CAIRN]        *
+       |  RFC2537   |       |   TKEY]       |      |                 |
+       |  RFC2539   |       |               |      *                 *
+       |  GSS-TSIG] |       |               |      +-*-*-*-*-*-*-*-*-+
+       +------------+       +---------------+
+                     Figure 1  DNSSEC Document Roadmap
+
+
+   The "DNSSEC protocol" document set refers to the document that makes
+   up the groundwork for adding security to the DNS protocol [RFC2535]
+   and updates to this document.  RFC 2535 laid out the goals and expec-
+   tations of DNS Security and the new security related Resource Records
+   KEY, SIG, and NXT.  Expanding from this document, related document
+
+
+
+Rose                                                            [Page 4]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+   groups include the implementation documents of various digital signa-
+   ture algorithms with DNSSEC, and documents further refining the tran-
+   saction of messages.  It is expected that RFC 2535 will be obseleted
+   by one or more documents that refine the set of security extensions
+   and DNS security transactions.  Documents that seek to modify or
+   clarify the base protocol documents should state so clearly in the
+   introduction of the document (as well as proscribe to the IETF guide-
+   lines of RFC/Internet Draft author guidelines).  Also, the portions
+   of the specification to be modified SHOULD be synopsized in the new
+   document for the benefit of the reader.  The "DNSSEC protocol" set
+   includes the documents [RFC2535], [CLARIFY], [AUTH], [SIZE] and their
+   derivative documents.
+
+   The "New Security RRs" set refers to the group of documents that seek
+   to add additional Resource Record to the set of base DNS Record
+   types.  These new records can be related to securing the DNS protocol
+   [RFC2535] [SIG0] [NO] or using DNS security for other purposes such
+   as storing certificates [RFC2538].
+
+   The "DS Algorithm Impl" document set refers to the group of documents
+   that describe how a specific digital signature algorithm is imple-
+   mented to fit the DNSSEC Resource Record format.  Each one of these
+   documents deals with one specific digital signature algorithm. Exam-
+   ples of this set include [RFC2536] [RFC2537] [RFC2539] and [GSS-
+   TSIG].
+
+   The "Transactions" document set refers to the group of documents that
+   deal with the message transaction sequence of security related DNS
+   operations.  The contents and sequence for operations such as dynamic
+   update [RFC2137] [UPDATE] and transaction signatures [RFC2845] are
+   described in this document category.  Additional message transaction
+   schemes to support DNSSEC operation would also fall under this group,
+   including secret key establishment [TKEY], and verification.
+
+   The final document set, "New Security Uses", refers to documents that
+   seek to use proposed DNS Security extensions for other security
+   related purposes.  Documents that fall in this category include the
+   use of DNS in the distribution of certificates and individual user
+   public keys (PGP, email, etc.).
+
+   Lastly, there is a set of documents that should be classified as
+   "Implementation Notes".  Because the DNS security extensions are
+   still in the developmental stage, there is an audience for documents
+   that detail the transition and implementation of the security exten-
+   sions.  These have more to do with the practical side of DNS opera-
+   tions, but can also point to places in the protocol specifications
+   that need improvement.  Documents in this set may be offspring of
+   both the DNSEXT and/or DNSOP working groups.  Currently, there is
+
+
+
+Rose                                                            [Page 5]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+   only one Internet Draft that falls under this category:  The report
+   on the CAIRN DNSSEC testbed [CAIRN].  This document was submitted
+   through the DNSOP working group, however the main concern of this
+   document in the implementation and limitations of the DNS security
+   extensions, hence its interest to the DNS security community.
+   Authors of documents that deal with the implementation and opera-
+   tional side of the DNSSEC specifications would be advised/encouraged
+   to submit their documents to the DNSEXT working group as well.
+
+
+3. Relationship of DNS Security Documents to other DNS Documents
+
+   The DNS security related extensions should be considered a subset of
+   the DNS protocol.  The DNS Security working group of the IETF
+   (DNSSEC) has been absorbed into the larger DNS Extensions working
+   group (DNSEXT).  Therefore, all DNS security related documents should
+   be seen as a subset of the main DNS architecture documents.  It is a
+   good idea for authors of future DNS security documents to be familiar
+   with the contents of these base protocol documents.
+
+
+4. Recommended Content for new DNS Security Documents
+
+   Documents that seek to make additions or revisions to the DNS proto-
+   col to add security should follow common guidelines as to minimum
+   required content and structure.  It is the purpose of this document
+   roadmap to establish criteria for content that any new DNS security
+   protocol specifications document SHOULD contain.  This criteria
+   SHOULD be interpreted as a minimum set of information required/needed
+   in a document, any additional information regarding the specific
+   extension should also be included in the document.  These criteria
+   are not officially part of the IETF guidelines regarding RFC/Internet
+   Drafts, but should be considered as guidance to promote uniformity to
+   working group documents.
+
+   Since the addition of security to the DNS protocol is now considered
+   A general extension to the DNS protocol, any guideline for the con-
+   tents of a DNS Security document could be taken as a suggestion for
+   the contents of any DNS extension document.
+
+
+4.1 Security Related Resource Records
+
+   Documents describing a new type of DNS Security Resource Record (RR)
+   should contain information describing the structure and use of the
+   new RR type.  It is a good idea to only discuss one new type in a
+   document, unless the set of new resource records are closely related
+   or a protocol extensions requires the use of more than one new record
+
+
+
+Rose                                                            [Page 6]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+   type.  Specifically: each document detailing a new Security related
+   RR type should include the following information:
+
+   *  The format of the new RR type, both "on the wire" (bit format) and
+   ASCII representation (for text zone files), if appropriate.
+
+   *  When and in what section of a DNS query/response this new RR type
+   is to be included.
+
+   *   At which level of the DNS hierarchy this new RR type is to be
+   considered authoritative (i.e. in a zone, in a zone's superzone) and
+   who is authoritative to sign the new RR.
+
+
+4.2 Digital Signature Algorithm Implementations
+
+   Documents describing the implementation details of a specific digital
+   signature algorithm such as [RFC 2536, RFC 2537] for use with DNS
+   Security should include the following information:
+
+   *   The format/encoding of the algorithm's public key for use in a
+   KEY Resource Record.
+
+   *   The acceptable key size for use with the algorithm.
+
+   *    The current known status of the algorithm (as one of REQUIRED,
+   RECOMMENDED, or OPTIONAL).
+
+   In addition, authors are encouraged to include any necessary descrip-
+   tion of the algorithm itself, as well as any know/suspected
+   weaknesses as an appendix to the document.  This is for reference
+   only, as the goals of the DNSEXT working group is to propose exten-
+   sions to the DNS protocol, not cryptographic research.
+
+
+4.3 Refinement of Security Procedures
+
+   This set of documents includes DNS protocol operations that relate to
+   DNS Security specifically such as DNS secret key establishment [TKEY]
+   and security extensions to pre-existing or proposed DNS operations
+   such as dynamic update [RFC2137].  Documents that describe a new set
+   of DNS message transactions, or seek to refine a current series of
+   transaction that make up a DNS operation SHOULD include the following
+   information:
+
+   *  The order in which the DNS messages are sent by the operation ini-
+   tiator and target.
+
+
+
+
+Rose                                                            [Page 7]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+   *  The format of these DNS messages.
+
+   *  Any required authentication mechanisms for each stage of the
+   operation and the required authority for that mechanism (i.e. zone,
+   host, or some other trusted authority such as a DNS administrator or
+   certificate authority).
+
+
+4.4 The Use of DNS Security Extensions with Other Protocols
+
+   Because of the flexibility and ubiquity of the DNS, there may exist
+   other Internet protocols and applications that could make use of, or
+   extend, the DNS security protocols.  Examples of this type of docu-
+   ment include the use of DNS to support the Public Key Infrastructure
+   (PKI).  It is beyond the scope of this roadmap to describe the con-
+   tents of this class of documents. However, if uses or extensions
+   require the addition or modification of a DNS Resource Record type or
+   DNS query/response transactions, then the guidelines laid out in the
+   previous sections of this document SHOULD be adhered too.
+
+
+5. Security Considerations
+
+   This document provides a roadmap and guidelines for writing DNS Secu-
+   rity related documents. The reader should follow all the security
+   procedures and guidelines described in the DNS Security Extensions
+   document [RFC2535].
+
+
+6. Acknowledgements
+
+   In addition to the RFCs mentioned in this document, there are also
+   numerous Internet drafts that fall in one or more of the categories
+   of DNS Security documents mentioned above.  Depending on where (and
+   if) these documents are on the IETF standards track, the reader may
+   not be able to access these documents through the RFC repositories.
+   For that reason, the version of the Internet drafts that were refer-
+   enced in this document are given below:
+
+   *   SIG0: D. Eastlake.  "DNS Request and Transaction Signatures
+   (SIG(0))" <draft-ietf-dnsext-sig-zero-02.txt>.
+   *   TKEY: D. Eastlake.  "Secret Key Establishment for DNS" <draft-
+   ietf-dnsext-tkey-03.txt>.
+   *   SIGALG:  R. Austein, P. Vixie.  "DNS SIGALGOPT".  <draft-ietf-
+   dnsind-sigalgopt-00.txt>
+   *   CLARIFY: E. Lewis.  "DNS Security Extension Clarification on Zone
+   Status" <draft-ietf-dnsext-zone-status-01.txt>
+   *   AUTH:  B. Wellington.  "Domain Name System Security (DNSSEC)
+
+
+
+Rose                                                            [Page 8]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+   Signing Authority"  <draft-ietf-dnsext-signing-auth-01.txt>
+   *   CAIRN:  D. Massey, T. Lehman, and E. Lewis.  "DNSSEC Implementa-
+   tion in the CAIRN Testbed".  <draft-ietf-dnsop-dnsseccairn-00.txt>
+   *   UPDATE:  X. Wang, Y. Huang, and D. Rine.  "Secure Online Domain
+   Name System (DNS) Dynamic Update".  <draft-whr-dnsext-secure-online-
+   update-00.txt>
+   *   SIZE:  O. Gudmundsson.  "DNSSEC and IPv6 A6 aware server/resolver
+   message size requirements". <draft-ietf-dnsext-message-size-00.txt>
+   *   GSS-TSIG:  S. Kwan, P. Garg, J. Gilroy, and L. Esibov.  "GSS
+   Algorithm for TSIG (GSS-TSIG)".  <draft-ietf-dnsext-gss-tsig-00.txt>
+   *   NO:  S. A. Josefsson.  "Authenticating Denial of Existence in DNS
+   with Minimum Disclosure".  <draft-jas-dnsext-no-00.txt>
+
+
+7. References
+
+   [RFC2535] D. Eastlake, "Domain Name System Security Extensions", RFC
+   2535, March 1999.
+
+   [RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name Sys-
+   tem (DNS)", RFC 2537, March 1999.
+
+   [RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System
+   (DNS)", RFC 2536, March 1999.
+
+   [RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update",
+   RFC 2137, April 1997.
+
+   [RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
+   Name System (DNS)", RFC 2539, March 1999.
+
+   [RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the
+   Domain Name System (DNS)", RFC 2538, March 1999.
+
+   [RFC1591] J. Postal, "Domain Name System Structure and Delegation",
+   RFC 1591, March 1994.
+
+   [RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specification",
+   RFC 2181, July 1997.
+
+   [RFC2541] D. Eastlake, "DNS Security Operational Considerations", RFC
+   541, March 1999.
+
+   [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, and B. Wellington.
+   "Secret Key Transaction Authentication for DNS (TSIG)".  RFC 2845,
+   May 2000.
+
+   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
+
+
+
+Rose                                                            [Page 9]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+   Requirement Levels", RFC-2119, March 1997.
+
+
+
+
+8. Authors' Addresses
+
+   Scott Rose
+   National Institute for Standards and Technology
+   Gaithersburg, MD
+   Email: scott.rose@nist.gov
+
+
+
+Expiration and File Name:
+
+   This draft, titled <draft-ietf-dnsext-dnssec-roadmap-00.txt> expires
+February 2001
+
+
+
+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 develop-
+   ing 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 MER-
+   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+Rose                                                           [Page 10]
+
+
+
+
+
+INTERNET-DRAFT       DNS Security Document Roadmap           August 2000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                                                           [Page 11]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-edns0dot5-00.txt b/doc/draft/draft-ietf-dnsext-edns0dot5-02.txt
index 4e5307a1..098da810 100644
--- a/doc/draft/draft-ietf-dnsext-edns0dot5-00.txt
+++ b/doc/draft/draft-ietf-dnsext-edns0dot5-02.txt
@@ -5,10 +5,10 @@
 
 
 Network Working Group                                         R. Austein
-draft-ietf-dnsext-edns0dot5-00.txt               InterNetShare.com, Inc.
+draft-ietf-dnsext-edns0dot5-02.txt               InterNetShare.com, Inc.
                                                            H. Alvestrand
-                                                          EDB MaXware AS
-                                                           February 2000
+                                                           Cisco Systems
+                                                           November 2000
 
 
          A Proposed Enhancement to the EDNS0 Version Mechanism
@@ -55,12 +55,12 @@ Motivation and Scope
 
 
 
-Austein & Alvestrand     Expires 28 August 2000                 [Page 1]
+Austein & Alvestrand       Expires 22 May 2001                  [Page 1]
 
-draft-ietf-dnsext-edns0dot5-00.txt                         February 2000
+draft-ietf-dnsext-edns0dot5-02.txt                         November 2000
 
 
-   This note proposes to replace the monolithic version numbering
+   This note proposes to augument the monolithic version numbering
    mechanism with a mechanism for listing an explicit set of protocol
    features that a particular implementation supports.  We retain
    version numbering as a way of abbreviating the feature sets that we
@@ -68,8 +68,8 @@ draft-ietf-dnsext-edns0dot5-00.txt                         February 2000
 
 Model
 
-   Our revised extension model for EDNS0 is designed with three goals in
-   mind:
+   Our revised extension model for the DNS is designed with three goals
+   in mind:
 
    - We want the protocol to be as simple as possible for the common
      case of a client or server that implements "mainstream standard
@@ -85,9 +85,10 @@ Model
    of the TTL field of the OPT RR, and a variable-length list of
    FEATURES, stored in the variable part of the OPT RR.
 
-   All FEATUREs are extensions of the DNS.  We reserve FEATURE numbers 1
-   to 100 for describing features of the original RFC 1034/1035 DNS
-   specification that we might eventually chose to deprecate.
+   All FEATUREs are extensions of the DNS.  We reserve the range of
+   FEATURE numbers from 1 to 100 for describing features of the original
+   RFC 1034/1035 DNS specification that we might eventually choose to
+   deprecate.
 
    Any query/response pair can be described as using a set of DNS
    FEATUREs.  Such features might for instance be:
@@ -105,18 +106,18 @@ Model
    - SIG record parsing and checking;
 
    FEATURE numbers are handed out by IANA on a first-come-first-served
-   basis.  Any revised specification of a format or function should have
-   its own FEATURE number; in the IETF process, any significantly
-   changed Internet-Draft should have a new FEATURE number assigned for
+   basis within their appropriate ranges.  Any revised specification of
+   a format or function should have its own FEATURE number; in the IETF
 
 
 
-Austein & Alvestrand     Expires 28 August 2000                 [Page 2]
+Austein & Alvestrand       Expires 22 May 2001                  [Page 2]
 
-draft-ietf-dnsext-edns0dot5-00.txt                         February 2000
+draft-ietf-dnsext-edns0dot5-02.txt                         November 2000
 
 
-   experimentation.
+   process, any significantly changed Internet-Draft should have a new
+   FEATURE number assigned for experimentation.
 
    An assigned VERSION number names a set of FEATUREs.  VERSION numbers
    are assigned by the IETF through a standards action.
@@ -134,8 +135,8 @@ draft-ietf-dnsext-edns0dot5-00.txt                         February 2000
 
 Mechanism
 
-   We propose to transport explicit feature sets as lists of integers
-   carried in the variable RDATA portion of the EDNS0 OPT pseudo-RR.
+   We transport explicit feature sets as lists of integers carried in
+   the variable RDATA portion of the EDNS0 OPT pseudo-RR.
 
    The OPTION-CODE for FEATURES is [TBD].
 
@@ -148,35 +149,46 @@ Mechanism
 
 Usage
 
-   When composing a query message, the client includes an OPT record
-   indicating the set of FEATUREs that:
+   In most respects, the FEATURE mechanism is used symmetrically by
+   clients and servers; exceptions to this rule are stated after the
+   general explanation.
 
-   - Allows the client to express this query;
+   When composing a DNS message, a client or server includes an OPT
+   record indicating a set of FEATUREs that:
 
-   - Allows the server to express all responses that the client is
-     prepared to accept for this query.
+   - MUST include all FEATUREs that the client or server believes are
+     relevant to this message;
+
+   - MAY include all FEATURES that the client or server is prepared to
+     receive.
 
    This set is expressed as a VERSION and any additional FEATURES
    required.
 
-   The server will include an OPT pseudo-RR that indicates:
-
-   - The highest VERSION numbers supported by the responder (for
-     information only -- the client takes no action based on this);
 
 
+Austein & Alvestrand       Expires 22 May 2001                  [Page 3]
+
+draft-ietf-dnsext-edns0dot5-02.txt                         November 2000
 
 
-Austein & Alvestrand     Expires 28 August 2000                 [Page 3]
-
-draft-ietf-dnsext-edns0dot5-00.txt                         February 2000
+   In general, we expect that a client or server will include an OPT
+   pseudo-RR that indicates:
 
+   - The highest VERSION number that the entity generating the message
+     supports; and
 
-   - The set of FEATUREs not encompassed by the VERSION that are
-     necessary to express the response.
+   - A small (possibly empty) set of additional FEATUREs not encompassed
+     by the VERSION that the entity deems necessary or desirable.
 
-   No FEATURE may be included or used that is not within the set of
-   FEATUREs that the query originator indicated.
+   The above symmetry notwithstanding, we impose one important
+   constraint on the server: while a server is allowed to indicate
+   whatever FEATUREs it believes are relevant or useful, a server MUST
+   NOT make use of any FEATURE in a response that is not within the set
+   of FEATUREs indicated by the client that generated the corresponding
+   request.  That is, a response may say "I support FEATURE FOO"
+   regardless of what the client supports, but the rest of the response
+   must not use FEATURE FOO unless the client also supports it.
 
    As a special case, if a client explicitly queries for the OPT RR of
    the root zone, the server returns an OPT record including all
@@ -190,8 +202,8 @@ Life Cycle
    - VERSION X is defined and deployed.
 
    - A new FEATURE is defined and experimentally implemented.  All
-     clients and servers part of the experiment use FEATURE to indicate
-     support.
+     clients and servers taking part in the experiment use FEATURE to
+     indicate support.
 
    - Community consensus is reached that this FEATURE is genuinely
      useful.
@@ -209,24 +221,29 @@ Risks
    all, since by any realistic estimate it takes years (decades?)  to
    upgrade all the DNS implementations already in the field.
 
+
+
+Austein & Alvestrand       Expires 22 May 2001                  [Page 4]
+
+draft-ietf-dnsext-edns0dot5-02.txt                         November 2000
+
+
    A flexible extension mechanism of this type increases the risk that
    some implementors might chose to deploy features designed to hinder
    interoperability (so-called "labeled noninteroperability").
 
 Security Considerations
 
-   We do not believe that this protocol enhancement adds any new
+   We do not believe that this protocol enhancement adds any major new
    security risks, but we do believe that it would be helpful in getting
    complicated DNS extensions such as [DNSSEC] deployed more quickly.
 
-
-
-
-
-Austein & Alvestrand     Expires 28 August 2000                 [Page 4]
-
-draft-ietf-dnsext-edns0dot5-00.txt                         February 2000
-
+   As with any enhancement to or complication of the DNS protocol, this
+   enhancement offers attackers yet another way to increase the load on
+   a name server.  Root, TLD and other "major" name servers should view
+   excessively complicated FEATURE sets with suspicion, and should not
+   allow themselves to be tricked into performing more work than is
+   really necessary.
 
 IANA Considerations
 
@@ -234,6 +251,12 @@ IANA Considerations
 
    IANA will need to create a new registry of feature numbers.
 
+Acknowledgments
+
+   The authors would like to thank the following people for their help
+   in improving this document: Randy Bush, Patrik Faltstrom, Olafur
+   Gudmundsson, Bob Halley, and XXX.
+
 References
 
    [DNSSEC]  Eastlake, D., "Domain Name System Security Extensions", RFC
@@ -251,6 +274,16 @@ References
    [BINARY-LABELS]  Crawford, M., "Binary Labels in the Domain Name
         System", RFC 2673 August 1999.
 
+
+
+
+
+
+Austein & Alvestrand       Expires 22 May 2001                  [Page 5]
+
+draft-ietf-dnsext-edns0dot5-02.txt                         November 2000
+
+
 Author's addresses:
 
       Rob Austein
@@ -262,12 +295,12 @@ Author's addresses:
       sra@hactrn.net
 
       Harald Tveit Alvestrand
-      EDB MaXware AS
-      Pirsenteret
-      N-7486 Trondheim
+      Cisco Systems
+      Weidemanns vei 27
+      N-7043 Trondheim
       NORWAY
 
-      +47 73 54 57 97
+      +47 73 50 33 52
       Harald@Alvestrand.no
 
 
@@ -279,4 +312,27 @@ Author's addresses:
 
 
 
-Austein & Alvestrand     Expires 28 August 2000                 [Page 5]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Alvestrand       Expires 22 May 2001                  [Page 6]
diff --git a/doc/draft/draft-ietf-dnsext-gss-tsig-01.txt b/doc/draft/draft-ietf-dnsext-gss-tsig-01.txt
new file mode 100644
index 00000000..a7fc59ba
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-gss-tsig-01.txt
@@ -0,0 +1,1158 @@
+
+INTERNET-DRAFT                                               Stuart Kwan
+<draft-ietf-dnsext-gss-tsig-01.txt>                         Praerit Garg
+                                                            James Gilroy
+                                                            Levon Esibov
+                                                         Microsoft Corp.
+                                                       November 22, 2000
+                                                    Expires May 22, 2001
+
+
+                 GSS Algorithm for TSIG (GSS-TSIG)
+
+
+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
+
+The 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 2001                                              [Page 1]
+
+INTERNET-DRAFT                   GSS-TSIG            November 22, 2000
+
+
+Table of Contents
+
+1: Introduction......................................................2
+2: Algorithm Overview................................................3
+  2.1: GSS Details...................................................4
+3: Client Protocol Details...........................................4
+  3.1: Negotiating Context...........................................4
+    3.1.1: Call GSS_Init_sec_context.................................5
+    3.1.2: Send TKEY Query to Server.................................6
+    3.1.3: Receive TKEY Query-Response from Server...................7
+  3.2: Context Established...........................................9
+4: Server Protocol Details...........................................9
+  4.1: Negotiating Context...........................................9
+    4.1.1: Receive TKEY Query from Client...........................10
+    4.1.2: Call GSS_Accept_sec_context..............................10
+    4.1.3: Send TKEY Query-Response to Client.......................11
+  4.2: Context Established..........................................12
+    4.2.1: Terminating a Context....................................12
+5: Sending and Verifying Signed Messages............................12
+  5.1: Sending a Signed Message - Call GSS_GetMIC...................12
+  5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............13
+6: Example usage of GSS-TSIG algorithm..............................14
+7: Security Considerations..........................................18
+8: IANA Considerations..............................................18
+9: Conformance......................................................18
+10:Acknowledgements.................................................18
+11:References.......................................................19
+
+
+1. Introduction
+
+The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol
+was developed to provide a lightweight end to end 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 off the answers.
+
+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.
+
+Expires May 22, 2001                                            [Page 2]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+* 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", "REQUIRED", "SHOULD", "RECOMMENDED",  and
+"MAY" in this document are to be interpreted as described in 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:
+
+                           +----------+
+                           |          |
+                           V          |
+                   +---------------+  |
+                   | Uninitialized |  |
+                   |               |  |
+                   +---------------+  |
+                           |          |
+                           V          |
+                   +---------------+  |
+                   | Negotiating   |  |
+                   | Context       |  |
+                   +---------------+  |
+                           |          |
+                           V          |
+                   +---------------+  |
+                   | Context       |  |
+                   | Established   |  |
+                   +---------------+  |
+                           |          |
+                           +----------+
+
+Expires May 22, 2001                                            [Page 3]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+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].
+
+
+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.
+
+
+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.
+
+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].
+
+Expires May 22, 2001                                            [Page 4]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+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        conf_req_flag         = TRUE
+     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 [RFC2734]
+
+   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
+     BOOLEAN        sequence_state
+     BOOLEAN        anon_state
+     BOOLEAN        trans_state
+     BOOLEAN        prot_ready_state
+     BOOLEAN        conf_avail
+     BOOLEAN        integ_avail
+     INTEGER        lifetime_rec
+
+
+
+Expires May 22, 2001                                            [Page 5]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+The client MUST abandon the algorithm 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
+
+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 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.
+
+
+
+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].
+
+
+
+
+
+
+
+Expires May 22, 2001                                            [Page 6]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+   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.
+
+
+3.1.3 Receive TKEY Query-Response from Server
+
+Upon the reception of the TKEY query 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.
+
+
+
+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. 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 signature is
+invalid, then an attacker has tampered with the message in transit or
+has attempted to send the client a false response. The client MUST
+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.
+
+
+
+
+Expires May 22, 2001                                            [Page 7]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+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
+
+If the last call to GSS_Init_sec_context yielded a major_status value
+of GSS_S_CONTINUE, 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. Since the message is not signed, the client MUST
+disregard the error code of the DNS message and the TKEY record. The
+client MUST pass a token specified in the Key Data field in the TKEY
+resource record to 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
+
+then client MUST abandon this negotiation sequence.  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.
+
+If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then
+client MUST act as described below.
+
+
+Expires May 22, 2001                                            [Page 8]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+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.
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+Expires May 22, 2001                                            [Page 9]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+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, the corresponding context_handle is used in
+subsequent GSS operations. If the name is not found, then the server
+interprets this as a start of new security context negotiation.
+
+
+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.
+
+   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
+
+Expires May 22, 2001                                           [Page 10]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+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.
+
+     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.
+
+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. 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, 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.
+
+
+
+
+
+Expires May 22, 2001                                           [Page 11]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+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).
+
+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:
+
+   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].
+
+
+Expires May 22, 2001                                           [Page 12]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+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].
+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]).
+
+
+
+
+
+
+Expires May 22, 2001                                           [Page 13]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+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.
+
+If major_status is set to one of the following values, the negotiated
+context is no longer valid.
+     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 this failure occurs 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 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].
+
+
+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.
+
+
+
+
+
+
+
+Expires May 22, 2001                                           [Page 14]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+  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
+
+  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.
+
+
+
+
+
+
+Expires May 22, 2001                                           [Page 15]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+  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)
+     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.
+
+Expires May 22, 2001                                           [Page 16]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+  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, repectively. It
+  finds that the key_name 789.client.example.com.server.example.com. is
+  listed in its (key_name, context_handle) mapping table.
+
+
+  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.
+
+
+
+
+
+
+
+
+
+Expires May 22, 2001                                           [Page 17]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+  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 to 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.
+
+
+  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 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.
+
+
+Expires May 22, 2001                                           [Page 18]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+8. IANA Considerations
+
+The authors request that the IANA reserve 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 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. 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 and Donald E. Eastlake 3rd.
+
+
+11. References
+
+[RFC2743] J. Linn, "Generic Security Service Application Program
+          Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories,
+          January 2000.
+
+[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
+          "Secret Key Transaction Signatures for DNS (TSIG)", RFC 2845,
+          ISC, NAI Labs, Motorola, Nominum, May, 2000,
+
+[RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)",
+          RFC 2930, Motorola, September 2000.
+
+[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
+          RFC 2535, IBM, March 1999.
+
+
+
+Expires May 22, 2001                                           [Page 19]
+
+INTERNET-DRAFT                   GSS-TSIG              November 22, 2000
+
+
+
+[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
+          RFC 2137, CyberCash, April 1997.
+
+[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+          Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+[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, OpenVision Technologies, June 1996.
+
+[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
+          RFC 2025, Bell-Northern Research, October 1996.
+
+[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
+          Negotiation Mechanism", RFC 2478, Bull, December 1998.
+
+
+
+12. Author's Addresses
+
+Stuart Kwan                         Praerit Garg
+Microsoft Corporation               Microsoft Corporation
+One Microsoft Way                   One Microsoft Way
+Redmond, WA  98052                  Redmond, WA  98052
+USA                                 USA
+skwan@microsoft.com
+
+James Gilroy                        Levon Esibov
+Microsoft Corporation               Microsoft Corporation
+One Microsoft Way                   One Microsoft Way
+Redmond, WA  98052                  Redmond, WA  98052
+USA                                 USA
+                                    levone@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 22, 2001                                           [Page 20]
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-iana-dns-01.txt b/doc/draft/draft-ietf-dnsext-iana-dns-01.txt
deleted file mode 100644
index 95dc70dd..00000000
--- a/doc/draft/draft-ietf-dnsext-iana-dns-01.txt
+++ /dev/null
@@ -1,753 +0,0 @@
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-                                                            Eric Brunner
-                                                            Bill Manning
-Expires: December 2000                                         June 2000
-
-
-
-              Domain Name System (DNS) IANA Considerations
-              ------ ---- ------ ----- ---- --------------
-                  <draft-ietf-dnsext-iana-dns-01.txt>
-
-
-
-Status of This Document
-
-   Distribution of this draft, which is intended to become a Best
-   Current Practice, is unlimited. Comments should be sent to the DNS
-   Working Group mailing list <namedroppers@internic.net> or to the
-   authors.
-
-   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
-
-   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, etc.
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 1]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 2000
-
-
-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 Special Note on the OPT RR...........................8
-      3.2 RR CLASS IANA Considerations...........................8
-      3.3 RR NAME Considerations.................................9
-      4. Security Considerations................................10
-
-      References................................................11
-
-      Authors Addresses.........................................13
-      Expiration and File Name..................................13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 2]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 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.
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 3]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 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
-
-
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 4]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 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 [draft-ietf-
-   dnsext-tkey-*.txt].  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                [draft-ietf-dnsext-tkey-*.txt]
-        20    BADNAME   Duplicate key name           [draft-ietf-dnsext-tkey-*.txt]
-        21    BADALG    Algorithm not supported      [draft-ietf-dnsext-tkey-*.txt]
-        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.
-
-
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 5]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 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.
-
-   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.
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 6]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 2000
-
-
-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 [draft-ietf-dnsext-tkey-*.txt].
-
-   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.
-
-     32768 - 65279
-   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
-     65280 - 65535
-   0xFF00 - 0xFFFF - Private Use.
-
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 7]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 2000
-
-
-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, 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.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].
-
-     5 - 127
-   0x0005 - 0x007F - available for assignment by IETF Consensus as data
-          CLASSes only.
-
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 8]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 2000
-
-
-     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].
-
-   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
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 9]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 2000
-
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                        [Page 10]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 2000
-
-
-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] - P. Mockapetris, "Domain Names - Concepts and
-   Facilities", STD 13, November 1987.
-
-   [RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
-   Specifications", STD 13, November 1987.
-
-   [RFC 1591] - J. Postel, "Domain Name System Structure and
-   Delegation", March 1994.
-
-   [RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
-   Changes (DNS NOTIFY)", August 1996.
-
-   [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
-   Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
-
-   [RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
-   Specification", July 1997.
-
-   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
-   in RFCs", T.  Narten, H. Alvestrand, October 1998.
-
-   [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
-   March 1999.
-
-   [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
-   June 1999.
-
-   [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
-   1999.
-
-   [RFC 2672] - M. Crawford, "Non-Terminal DNS Name Redirection", August
-   1999.
-
-   [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
-   August 1999.
-
-   [RFC 2845] - P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
-   "Secret Key Transaction Authentication for DNS (TSIG)", May 2000.
-
-   [draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key
-   Establishment for DNS (TKEY RR)", xxx 2000.
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                        [Page 11]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 2000
-
-
-   [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
-   X3.4, American National Standards Institute: New York, 1968.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                        [Page 12]
-
-
-INTERNET-DRAFT          DNS IANA Considerations                June 2000
-
-
-Authors Addresses
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Telephone:   +1-978-562-2827 (h)
-                +1-508-261-5434 (w)
-   fax:         +1-508-261-4447 (w)
-   email:       Donald.Eastlake@motorola.com
-
-
-   Eric Brunner
-   Engage Technologies
-   100 Brickstone Square, 2nd Floor
-   Andover, MA 01810
-
-   Telephone:   +1-978-684-7796 (voice)
-                +1-978-684-3636 (fax)
-   email:       brunner@engage.com
-
-
-   Bill Manning
-   USC/ISI
-   4676 Admiralty Way, #1001
-   Marina del Rey, CA 90292 USA
-
-   Telephone:   +1 310 822 1511
-   email:       bmanning@isi.edu
-
-
-
-Expiration and File Name
-
-   This draft expires December 2000.
-
-   Its file name is draft-ietf-dnsext-iana-dns-02.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd, E. Brunner, B. Manning                        [Page 13]
-
diff --git a/doc/draft/draft-ietf-dnsext-message-size-01.txt b/doc/draft/draft-ietf-dnsext-message-size-01.txt
new file mode 100644
index 00000000..d0948dcf
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-message-size-01.txt
@@ -0,0 +1,338 @@
+
+
+
+
+
+
+DNSEXT Working Group                       Olafur Gudmundsson (NAI Labs)
+INTERNET-DRAFT                                              October 2000
+
+<draft-ietf-dnsext-message-size-01.txt>
+
+Updates: RFC 2535, RFC 2874
+
+
+
+   DNSSEC and IPv6 A6 aware server/resolver message size requirements
+
+
+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
+
+   Comments should be sent to the authors or the DNSEXT WG mailing list
+   namedroppers@ops.ietf.org
+
+   This draft expires on March 29, 2001.
+
+   Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All rights reserved.
+
+
+
+
+
+
+
+
+
+
+Expires March 2001                                              [Page 1]
+
+INTERNET-DRAFT  DNSSEC and IPng message size requirement    October 2000
+
+
+Abstract
+
+   This document mandates support for EDNS0 in DNS entities claiming to
+   support DNS Security Extensions and 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.
+
+
+
+
+1 - Introduction
+
+   Familiarity with the DNS[RFC1034, RFC1035], DNS Security
+   Extensions[RFC2535], EDNS0[RFC2671] and A6[RFC2874] is helpful.
+
+   RFC 1035[RFC1035] 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 size UDP datagrams. Thus, any answer that
+   requires more than 512 octets will result in a partial and probably
+   useless reply with the Truncation Bit set; in most cases the
+   requester will then retry using TCP. Some DNS servers send back an
+   answer truncating the message at the last RR boundary before
+   truncation, other servers truncate at the previous set, some send
+   back empty answer with TC bit set.
+
+   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
+   server also needs to keep a state of the connection during this
+   transaction. As many DNS servers answer thousands of queries per
+   second, requiring them to use TCP will cause significant overhead and
+   delays.
+
+
+1.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..200 octets.  The
+   addition of these signatures on each or most RR sets in an answer
+   will significantly increase the size of DNS answers from secure
+   zones.
+
+   It is important that security aware servers and resolvers get all the
+   data in Answer and Authority section in one query without truncation.
+   In some cases it is important that some Additional Data be sent
+
+
+
+Expires March 2001                                              [Page 2]
+
+INTERNET-DRAFT  DNSSEC and IPng message size requirement    October 2000
+
+
+   along, mainly in delegation cases.
+
+   TSIG[RFC2845] allows for the light weight authentication of DNS
+   messages, but increases the size of the messages by at least 70
+   octets.  DNSSEC allows for computationally expensive message
+   authentication with 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.
+
+
+1.2 - IPv6 Motivations
+
+   IPv6 addresses[RFC2874] are 128 bits and are 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
+   queried name has multiple A6 addresses may overflow a 512-octet UDP
+   packet size.
+
+
+1.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 DNS message. If root servers start advertising A6 or
+   KEY records then the root zone answer for NS records will not fit in
+   an single 512-octet DNS message. Resulting in a large number of TCP
+   connections to the root servers.
+
+   It is important that a high level domains have a high number of
+   domain name servers for redundancy, latency and load balancing
+   reasons.
+
+
+1.4 UDP vs TCP for DNS messages
+
+   Given all these factors, it is essential that any implementations
+   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 avoid fragmentation
+   of DNS responses. A fragmented UDP message that suffers a loss off
+   one of the fragments renders the answer useless and DNS must
+   retransmit the query. TCP connection requires number of round trips
+   for establishment, data transfer and tear down, but only the lost
+   data segments are retransmitted.
+
+
+
+
+Expires March 2001                                              [Page 3]
+
+INTERNET-DRAFT  DNSSEC and IPng message size requirement    October 2000
+
+
+   In the early days 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 few thousand octets.
+
+
+1.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.
+
+1.7 - Requirements
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and "MAY"
+   in this document are to be interpreted as described in RFC 2119.
+
+
+2 - Protocol changes:
+
+   This document updates [RFC2535] and [RFC2874], by adding new
+   requirements.
+
+   All RFC2535-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 RFC2874-compliant servers and resolver MUST support EDNS0 and
+   advertise message size of at least 1024 octets, but SHOULD advertise
+   message size of 2048.
+
+   All RFC2535 and RFC2874 compliant entities MUST be able to handle
+   fragmented IP and IPv6 UDP packets.
+
+   All hosts supporting both RFC2535 and RFC2874 MUST use the larger
+   required value in EDNS0 advertisements.
+
+
+
+
+
+
+
+
+Expires March 2001                                              [Page 4]
+
+INTERNET-DRAFT  DNSSEC and IPng message size requirement    October 2000
+
+
+3 Acknowledgments
+
+   Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
+   Gustafsson, Bob Halley, Edward Lewis and Kazu Yamamoto where
+   instrumental in motivating and shaping this document.
+
+4 - Security Considerations:
+
+   There are no additional security considerations other than those in
+   RFC2671.
+
+
+5 - IANA Considerations:
+
+   None
+
+References:
+
+
+[RFC1034]  P. Mockapetris, ``Domain Names - Concepts and Facilities''
+           STD 13, RFC 1034, November 1987.
+
+[RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
+           Specification'', STD 13, RFC 1035, November 1987.
+
+
+[RFC2535]  D. Eastlake, ``Domain Name System Security Extensions'', RFC
+           2535, March 1999.
+
+
+[RFC2671]  P. Vixie, ``Extension Mechanisms for DNS (EDNS0)'',  RFC
+           2671, August 1999.
+
+
+[RFC2845]  P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
+           ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC
+           2845, May 2000.
+
+
+[RFC2874]  M. Crawford, C. Huitema, S. Thompson, ``DNS Extensions to
+           Support IPv6 Address Aggregation and Renumbering'', RFC2874,
+           Sometime 2000.
+
+
+
+
+
+
+
+
+
+Expires March 2001                                              [Page 5]
+
+INTERNET-DRAFT  DNSSEC and IPng message size requirement    October 2000
+
+
+Author Address
+
+
+   Olafur Gudmundsson
+      NAI Labs
+      Network Associates
+      3060 Washington Road (Rt. 97)
+      Glenwood, MD 21738
+      USA
+      +1 443 259 2389
+      <ogud@tislabs.com>
+
+
+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."
+
+
+
+
+
+
+
+
+
+
+
+Expires March 2001                                              [Page 6]
diff --git a/doc/draft/draft-ietf-dnsext-rfc2782bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc2782bis-00.txt
new file mode 100644
index 00000000..a58f052d
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2782bis-00.txt
@@ -0,0 +1,682 @@
+
+
+
+
+
+Network Working Group                                     A. Gulbrandsen
+Category: INTERNET-DRAFT                                    Trolltech AS
+Obsoletes: 2052                                                 P. Vixie
+draft-ietf-dnsext-rfc2782bis-00.txt         Internet Software Consortium
+November 16, 2000                                              L. Esibov
+Expires: May 16, 2001                                    Microsoft Corp.
+                                                           
+
+
+       A DNS RR for specifying the location of services (DNS SRV)
+
+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 (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.
+
+
+
+
+
+Expires May 2001                                                [Page 1]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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.Domain 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.
+
+
+
+
+
+Expires May 2001                                                [Page 2]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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.
+
+   Domain
+        The domain this RR refers to.  The SRV RR is unique in that the
+        name one searches for is not this Domain 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,
+
+
+
+
+Expires May 2001                                                [Page 3]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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 real 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
+
+
+
+Expires May 2001                                                [Page 4]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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.
+
+
+
+
+Expires May 2001                                                [Page 5]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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.domain, 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.
+
+
+
+
+
+Expires May 2001                                                [Page 6]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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=domain, 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.)
+
+
+
+Expires May 2001                                                [Page 7]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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 .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 2001                                                [Page 8]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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.
+
+
+
+Expires May 2001                                                [Page 9]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 2001                                               [Page 10]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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
+   Trolltech AS
+   Waldemar Thranes gate 98
+   N-0175 Oslo, Norway
+
+   Fax:   +47 21604800
+   Phone: +47 21604801
+   EMail: arnt@trolltech.com
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 2001                                               [Page 11]
+
+INTERNET-DRAFT                 DNS SRV RR                 Novemeber 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 16, 2001                                           [Page 12]
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-signing-auth-01.txt b/doc/draft/draft-ietf-dnsext-signing-auth-01.txt
deleted file mode 100644
index 9fbe1497..00000000
--- a/doc/draft/draft-ietf-dnsext-signing-auth-01.txt
+++ /dev/null
@@ -1,390 +0,0 @@
-
-DNSIND Working Group                          Brian Wellington (Nominum)
-INTERNET-DRAFT                                                  May 2000
-
-<draft-ietf-dnsext-signing-auth-01.txt>
-
-Updates: RFC 2535
-
-
-
-         Domain Name System Security (DNSSEC) Signing Authority
-
-
-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
-
-   Comments should be sent to the authors or the DNSIND WG mailing list
-   namedroppers@internic.net.
-
-   This draft expires on November 12, 2000.
-
-   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
-
-
-
-Expires November 2000                                           [Page 1]
-
-INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
-
-
-   secure resolution process.  Specifically, this affects the
-   authorization of keys to sign sets of records.
-
-
-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.
-
-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].
-
-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.
-
-
-
-
-
-
-
-Expires November 2000                                           [Page 2]
-
-INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
-
-
-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.
-
-
-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 contraints.
-
-
-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.  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.
-
-
-
-Expires November 2000                                           [Page 3]
-
-INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
-
-
-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.
-
-
-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 [SSU].  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
-
-
-
-Expires November 2000                                           [Page 4]
-
-INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
-
-
-signatures.  in the DNS.
-
-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 can sign data.  amount of work to determine if all such keys have
-the proper authority.
-
-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.
-
-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.
-
-
-
-Expires November 2000                                           [Page 5]
-
-INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
-
-
-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
-
-
-6 - References
-
-[RFC1034]  P. Mockapetris, ``Domain Names - Concepts and Facilities,''
-           RFC 1034, ISI, November 1987.
-
-[RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
-           Specification,'' RFC 1035, ISI, November 1987.
-
-[RFC2136]  P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
-           Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
-           & Cisco & DEC, April 1997.
-
-[RFC2535]  D. Eastlake, ``Domain Name System Security Extensions,'' RFC
-           2065, IBM, March 1999.
-
-[SSU]      B. Wellington, ``Simple Secure Domain Name System (DNS)
-           Dynamic Update,'' draft-ietf-dnsext-simple-secure-
-           update-01.txt, Nominum, May 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Expires November 2000                                           [Page 6]
-
-INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
-
-
-7 - Author's Address
-
-
-   Brian Wellington
-       Nominum, Inc.
-       950 Charter Street
-       Redwood City, CA 94063
-       +1 650 779 6022
-       <Brian.Wellington@nominum.com>
-
-
-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 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 MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires November 2000                                           [Page 7]
-
diff --git a/doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt b/doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt
deleted file mode 100644
index 1034426a..00000000
--- a/doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt
+++ /dev/null
@@ -1,445 +0,0 @@
-DNSIND Working Group                          Brian Wellington (NAILabs)
-INTERNET-DRAFT                                                  May 2000
-
-<draft-ietf-dnsext-simple-secure-update-01.txt>
-
-Updates: RFC 2535, RFC 2136,
-Replaces: RFC 2137, [update2]
-
-
-
-             Secure Domain Name System (DNS) Dynamic Update
-
-
-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
-
-   Comments should be sent to the authors or the DNSIND WG mailing list
-   namedroppers@internic.net.
-
-   This draft expires on November 12, 2000.
-
-   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
-
-
-
-Expires November 2000                                           [Page 1]
-
-INTERNET-DRAFT            Secure Dynamic Update                 May 2000
-
-
-   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.
-
-
-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], and TSIG transaction security [TSIG] is recommended.
-
-This document updates portions of RFC 2535, in particular section 3.1.2.
-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 [TSIG] or SIG(0) [RFC2535]
-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.
-
-
-
-
-Expires November 2000                                           [Page 2]
-
-INTERNET-DRAFT            Secure Dynamic Update                 May 2000
-
-
-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 negotation, 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 verifcations.
-
-SIG records do not cover the message header, which includes record
-counts.  Therefore, it is possibly 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 [signing-auth], 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 [TKEY] 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.
-
-
-
-
-Expires November 2000                                           [Page 3]
-
-INTERNET-DRAFT            Secure Dynamic Update                 May 2000
-
-
-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 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.
-
-
-
-
-
-Expires November 2000                                           [Page 4]
-
-INTERNET-DRAFT            Secure Dynamic Update                 May 2000
-
-
-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.
-
-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 restrict 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 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.
-
-
-
-
-
-Expires November 2000                                           [Page 5]
-
-INTERNET-DRAFT            Secure Dynamic Update                 May 2000
-
-
-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
-
-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 the
-updated zone is secured, the data affected by an update operation MUST
-be secured by one or more SIG records.  For each RRset, if the update
-includes a valid signature by a zone key, this signature SHOULD be
-reused.  Otherwise, the server MUST generate SIG records with one or
-more zone keys (of which the private components MUST be online).  If
-multiple zone keys are online and an RRset requires a signature, a SIG
-MUST be generated by at least one of the zone keys.
-
-If a principal is authorized to add SIG records and there are SIG
-records in the request, the following rules are applied.  If the SIG was
-generated by a zone key for the relevant zone, verification is attempted
-(the public key must be available if the determination that it is a zone
-key was made).  If successful, the SIG is retained; otherwise, the SIG
-is dropped.  Otherwise, the SIG is retained without verification, since
-it is considered immaterial to the DNSSEC validation process.  The
-server MAY examine SIG records and drop SIGs with a temporal validity
-period in the past.  At the completion of the update process, each
-updated RRset must be signed in accordance with the zone's signing
-policy; the SIGs must either be included in the update or generated by
-the server.
-
-The server MUST also, if necessary, generate a new SOA record and new
-NXT records, and sign these with the appropriate zone keys.  NXT records
-are explicitly forbidden.  SOA updates are allowed, since the
-maintenance of SOA parameters is outside of the scope of the DNS
-protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires November 2000                                           [Page 6]
-
-INTERNET-DRAFT            Secure Dynamic Update                 May 2000
-
-
-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.
-
-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):
-
-   Donald Eastlake
-   Olafur Gudmundsson
-   Andreas Gustafsson
-   Bob Halley
-   Stuart Kwan
-   Ed Lewis
-
-
-7 - References
-
-[RFC1034]  P. Mockapetris, ``Domain Names - Concepts and Facilities,''
-           RFC 1034, ISI, November 1987.
-
-[RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
-           Specification,'' RFC 1035, ISI, November 1987.
-
-[RFC2136]  P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
-           Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
-           & Cisco & DEC, April 1997.
-
-[RFC2137]  D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
-           2137, CyberCash, April 1997.
-
-[RFC2535]  D. Eastlake, ``Domain Name System Security Extensions,'' RFC
-           2065, IBM, March 1999.
-
-[TSIG]     P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington
-           ``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
-           ietf-dnsext-tsig-00.txt, ISC & NAILabs & IBM & NAILabs, March
-           2000.
-
-
-
-Expires November 2000                                           [Page 7]
-
-INTERNET-DRAFT            Secure Dynamic Update                 May 2000
-
-
-[TKEY]     D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
-           draft-ietf-dnsext-tkey-02.txt, IBM, April 2000.
-
-[signing-auth]
-           B. Wellington ``Domain Name System Security (DNSSEC) Signing
-           Authority,'' draft-ietf-dnsext-signing-auth-01.txt, Nominum,
-           May 2000.
-
-8 - Author's Address
-
-
-   Brian Wellington
-       Nominum, Inc.
-       950 Charter Street
-       Redwood City, CA 94063
-       +1 650 779 6022
-       <Brian.Wellington@nominum.com>
-
-
-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 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 MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-Expires November 2000                                           [Page 8]
-
diff --git a/doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt b/doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt
new file mode 100644
index 00000000..6c5cc994
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt
@@ -0,0 +1,333 @@
+INTERNET-DRAFT                                       Andreas Gustafsson
+draft-ietf-dnsext-unknown-rrs-00.txt                       Nominum Inc.
+                                                          November 2000
+
+
+                    Handling of Unknown DNS RR Types
+
+
+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
+
+   Extending the Domain Name System with new Resource Record 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
+
+
+
+Expires May 2001                                                [Page 1]
+
+draft-ietf-dnsext-unknown-rrs-00.txt                       November 2000
+
+
+   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].
+
+2. Definitions
+
+   In this document, a "well known" RR type means one defined in
+   RFC1035.
+
+   An "RR of unknown type" is an RR type whose RDATA format is not known
+   to the DNS implementation at hand, and which therefore cannot be
+   converted to a type-specific text format, compressed, or otherwise
+   handled in any type-specific way.  This includes the case where the
+   RR's type is recognized but its RDATA format is class specific and
+   the RR is of a class for which the format 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.
+
+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 not well known.
+
+   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 SRV RR is clearly defined to not
+   allow compression of the target field, some existing name servers
+   compress it anyway).
+
+   Future specifications for new RR types that contain domain names
+   within their RDATA MUST NOT allow the use of name compression for
+
+
+
+Expires May 2001                                                [Page 2]
+
+draft-ietf-dnsext-unknown-rrs-00.txt                       November 2000
+
+
+   those names, and SHOULD explicitly state that the embedded domain
+   names MUST NOT be compressed.
+
+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.
+
+   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.
+
+   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
+
+
+
+Expires May 2001                                                [Page 3]
+
+draft-ietf-dnsext-unknown-rrs-00.txt                       November 2000
+
+
+   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.
+
+7. DNSSEC Canonical Form and Ordering
+
+   DNSSEC [RFC2535] defines a canonical form and ordering for RRs.  In
+   the canonical form, domain names embedded in the RDATA are converted
+   to lower case.
+
+   To ensure backwards compatilbility, this canonical form remains
+   unchanged for any RR types defined in RFC2931 or earlier.  That is,
+   the domain names embedded in RRs of type 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 are converted to lower case.  For all
+   other RR types, the canonical form is hereby changed such that no
+   downcasing of embedded domain names takes place.  The owner name is
+   still set to lower case.
+
+   The canonical 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
+
+
+
+Expires May 2001                                                [Page 4]
+
+draft-ietf-dnsext-unknown-rrs-00.txt                       November 2000
+
+
+   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.
+
+   9. IANA Considerations
+
+   The IANA is hereby requested to verify that specifications for new RR
+   types requesting an RR type number comply with this specification.
+   In particular, the IANA MUST NOT assign numbers to RR types whose
+   specification allows embedded domain names to be compressed.
+
+   10. Security Considerations
+
+   This specification is not believed to cause any new security
+   problems, nor to solve any existing ones.
+
+References
+
+   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
+   November 1987.
+
+   [RFC1035] - Domain Names - Implementation and Specifications, P.
+   Mockapetris, November 1987.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE).  P.
+   Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
+
+   [RFC2535] Domain Name System Security Extensions. D. Eastlake.  March
+   1999.
+
+Author's Address
+
+   Andreas Gustafsson
+   Nominum Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+   USA
+
+   Phone: +1 650 779 6004
+
+   Email: Andreas.Gustafsson@nominum.com
+
+
+Full Copyright Statement
+
+
+
+
+Expires May 2001                                                [Page 5]
+
+draft-ietf-dnsext-unknown-rrs-00.txt                       November 2000
+
+
+   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 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
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 2001                                                [Page 6]
+
diff --git a/doc/draft/draft-ietf-dnsext-zone-status-01.txt b/doc/draft/draft-ietf-dnsext-zone-status-01.txt
deleted file mode 100644
index af7c85bb..00000000
--- a/doc/draft/draft-ietf-dnsext-zone-status-01.txt
+++ /dev/null
@@ -1,640 +0,0 @@
-DNSEXT WG                                               Edward Lewis
-INTERNET DRAFT                                          NAI Labs
-Category:I-D                                            April 13, 2000
-
-       DNS Security Extension Clarification on Zone Status
-             <draft-ietf-dnsext-zone-status-01.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.
-
-Comments should be sent to the authors or the DNSIND WG mailing list
-namedroppers@internic.net.
-
-This draft expires on October 13, 2000.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (1999, 2000).  All rights reserved.
-
-Abstract
-
-The definition of a secured zone is presented, updating RFC 2535.  The
-new definition has consequences that alter the interpretation of the
-NXT record, obsolete NULL keys, and the designation of "experimentally
-secure."
-
-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.
-
-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
-
-Expires October 13, 2000                                     [Page  1]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-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 (absent interaction with other zones).
-
-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, what does a parent
-consider a secure child to be, 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.
-
-This document updates several sections of RFC 2535.  The definition of
-a secured zone is an update to section 3.4 of the RFC.  The document
-updates section 2.3.4, by specifying a replacement for the NULL zone
-keys.  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.
-
-2 Status of a Zone
-
-In this section, rules governing a zone's DNSSEC status are presented.
-There are three levels of security defined: full, private, and
-unsecured.  A zone is fully secure when it complies with the strictest
-set of DNSSEC processing rules.  A zone is privately 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.  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.
-
-
-Expires October 13, 2000                                     [Page  2]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-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.
-
-2.b On-tree Validation - The authorization model in which only the
-parent zone can is recognized to supply a DNSSEC-meaningful signature
-that is used by a resolver to build a chain of trust from the child's
-keys to a recognized root of security.  The term "on-tree" refers to
-following up the DNS domain hierarchy 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' 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 Fully Secured
-
-A fully 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).  Fully 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 fully 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. (Updates 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
-
-Expires October 13, 2000                                     [Page  3]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-(2.a) of a mandatory to implement algorithm.  (Updates 2535, section
-2.3.1.)
-
-Mentioned earlier, the root zone is a special case.  Defining what
-constitutes a secure root zone is difficult, as the discussion on
-securing the root zone has not come to a consensus in an open forum. 
-However, the security of the root zone will be determined by the
-preconfiguration of a trusted key in resolvers.  Who generates and
-distributes the trusted key is an open issue.
-
-2.2 Privately Secured
-
-Note that the term "privately" is open to debate...
-
-A privately secured zone is a zone that complies with rules like those
-for a fully 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 preconfigured in
-all the resolvers of interest.
-
-2.2.b.2 The private key's public component 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. (Updates RFC
-2535, section 2.3.2.) 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.
-
-
-
-
-Expires October 13, 2000                                     [Page  4]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-2.4 Wrap up
-
-The designation of fully secured, privately 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 fully secured zones as secured, and all others as
-unsecured, including zones which are privately secured.  Resolvers
-that are not as restrictive, such as those that implement algorithms
-in addition to the mandatory to implement algorithms, will see some
-privately secured zones as secured.
-
-The intent of the labels "fully" and "privately" 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 Parental Notification
-
-For a resolver to come to a definitive answer concerning a zone's
-security status there is a requirement that the parent of a zone
-signify whether the child zone is signed or not.  The justification of
-this requirement requires a discussion of the resolver's activity,
-which is described in RFC 2535.
-
-In RFC 2535, a parent is required to hold a NULL key for an unsigned
-child (a bone of contention here is how this works in light of
-multiple algorithms).  The parent has the option to hold the keys of
-the child if the child is signed.  The parent may also hold nothing
-cryptographic if the child is signed.  This, of course, assumes the
-parent is a signed zone.
-
-RFC 2535 does permit the following case, a child zone that uses DNSSEC
-capable software yet chooses to remain unsecured could hold a signed
-NULL key delivered from the parent.  This is considered to be a rare
-condition, a zone administrator that goes to the trouble to get the
-keys from the parent and have it signed will likely just sign the
-whole zone, or leave the NULL key to the parent.
-
-There is a strong case for discouraging a parent from holding keys of
-a signed child, or an unsigned child for that matter.  These include
-concrete concerns about performance and more abstract concerns about
-the liability of the parent.
-
-DNS [RFC 1034 and 1035] requires a parent to hold NS records for a
-child zone, this signifies the delegation.  RFC 2535 requires a
-secured parent to also have signed NXT records for the child, and
-possibly a signed KEY RR set (required for some NULL key situations).
-
-By redefining the security status of a zone to be per zone and not per
-
-Expires October 13, 2000                                     [Page  5]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-algorithm, there is an opportunity to completely remove the need for a
-KEY RR set in the parent.  Because the question of whether the zone is
-secure or not is a yes-or-no question, the notification needs just one
-bit to be expressed.
-
-Keep in mind that the following sections speak to the contents of a
-zone, not a name server.  In the case of a name server speaking
-authoritatively for both the parent and child, or if a server caches
-the information for the other half of the delegation, then a server
-will have more types of data at a delegation point than a parent is
-supposed to hold.  (E.g., if a parent zone's name server caches the
-SOA for the child, the SOA is not in the parent zone, but is in the
-server's cache.)
-
-3.1 Child Has Keys Bit
-
-This section is written assuming the current definition of NXT holds.
-There is some controversy surrounding the NXT record, which may result
-in a complete replacement of it for proof of non-existence.  The
-current NXT definition provides an extension bit in the types present
-bit map, whose use is remains incompletely defined.  The following
-text largely ignores these uncertainties, and should be rewritten to
-accommodate these uncertainties in revisions.
-
-In the parent's half of the delegation point, there will be an NXT
-record, called an "upper" NXT.  According to the rules for a
-delegation point, only the NS, NXT, and SIG bits will be turned on in
-the types present field, assuming we drop the KEY set altogether.
-
-The KEY bit in the parent's NXT types present bit map is hereby
-redefined to have the following meaning.  (Note that this applies to
-just delegation points.)
-
-If the bit corresponding to the KEY RR set in an upper NXT is set, the
-parent has generated and issued a currently valid SIG (KEY) RR
-validating the child's apex KEY RR set.  Note that this does not
-require the child to include either a zone signing KEY RR (2.a) or a
-NULL zone KEY RR.  This does assume that only on-tree validation (2.b)
-is in use.
-
-The temporal validity of the bit's setting may be enforced in the SIG
-(NXT) RR validity period, timely editing of the master file, dynamic
-updates, or whatever another mechanism.
-
-If a child submits a key set to the parent for validation that does
-not include a zone signing KEY RR (2.a), then the child will remain
-unsecured although the upper NXT KEY RR bit will be set to 1 by the
-parent.  A resolver seeing this will know to look for a child key set,
-and see that there is no zone signing KEY RR (2.a) and know to treat
-the child as unsecured.
-
-If a NULL zone KEY RR is seen, the resolver ignores it.  If a NULL key
-is the only zone key, then the resolver will deduce the child is
-unsecured as in the previous paragraph.  If there is both a NULL and
-
-Expires October 13, 2000                                     [Page  6]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-one or more zone signing KEY RR (2.a), then the zone is considered
-signed in the algorithm(s) identified in the signing capable key(s).
-
-If the bit is 0 then the child has not submitted a KEY RR set for
-validation, hence is to be considered unsigned.
-
-Note that for a fully secured zone (section 2.1), the bit is on (1). 
-For all unsecured zones (section 2.3) the bit is either off (0) or on
-(1) with a NULL KEY and no zone signing KEY RR at the apex.  For
-privately secured zones (section 2.2), the setting of the bit is
-determined by whether the parent signs the child's keys or not. 
-Hence, for privately secured zones, the parent may have no
-responsibility.  A child wishing to have the parent set the bit must
-contact the parent.
-
-3.2 Rules Governing the Bit
-
-In this section, the words of the previous are turned into definitive
-MUST and SHOULDs.  Note that this section does not refer to the bit in
-the NXT.  This is in anticipation of a change in the way NXT indicates
-types present (e.g., if bit 0 of the field is defined) or a successor
-to the NXT is defined.
-
-3.2.a. At a delegation point, a secured parent zone MUST have a
-mechanism in place to indicate which RR sets are present.  The
-mechanism MUST indicate that the NS, SIG, and the type(s)
-corresponding to the mechanism itself are present (of course, with
-these types actually being present).  With the exception of the KEY RR
-type, all other types MUST be indicated as not present, and, in
-accordance with delegation rules, actually be absent from the zone. 
-If, in the future, other data is permitted to be present at a
-delegation point, this requirement MUST be amended.
-
-Assuming the NXT record, the above requirement reads as follows.  At a
-delegation point, a parent zone must have a secured NXT record.  This
-NXT record must indicate that the NS, SIG, and NXT types are present.
-With the exception of KEY, all other types must be indicated as not
-present.  The lower casing of the word "must" is intentional,
-conveying that this is an explanation of the rule above.
-
-3.2.b. The KEY set MUST be indicated as present during the time when
-the parent has issued a signature for the child's KEY set. Conversely,
-during periods of time in which the parent knows it has not generated
-a signature for the KEY RR set, the KEY set MUST be indicated to be
-absent.
-
-If the parent has issued signatures with discontinuous validity spans,
-then the presence of the KEY set will flip from present to not present
-and back as time progresses.
-
-3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully
-consider the algorithm of the key used to generate the signature.  The
-parent SHOULD make clear to child zones what steps are to be taken to
-
-
-Expires October 13, 2000                                     [Page  7]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-get the parent to indicate that the child is signed.  This document
-will go no further in specifying operational considerations.
-
-(Let's say the parent signs the child's key set with an algorithm the
-child can't process.  The child could elect not to advertise this
-signature, as it cannot verify that the signature covers the real key
-set.  If this happens, is the parent justified in claiming that the
-child is secured?)
-
-3.2.d. The parent MUST have the capability to allow the child, through
-some trusted, probably non-DNS mechanism, to request that the
-indication of the KEY set to be turned off.  This allows a child to
-revert to an unsigned state.
-
-3.2.e. The parent SHOULD NOT allow the child to request that the KEY
-set be indicated as present in the absence of a key signing request.
-
-3.3 Operational Considerations
-
-Retrieving the NXT for a delegated name from the parent zone (the
-upper NXT) is not a trivial operation.  The complication arises due to
-having an NXT in the delegatee (the lower NXT) that matches the owner
-name of the upper NXT.  (The case in which both the parent and child
-zones are secured is the only case mentioned here.  If both are not
-secured, then there will be at most one NXT, which is easily
-retrieved.)
-
-There are two complications to describe.  One involves the multiple
-NXT sets matching the same owner.  The other is the pragmatic issue of
-knowing where to get the answer.
-
-With multiple NXT sets at the same owner, caches may become a problem.
-If a (for example) recursive server has cached the lower NXT, any
-query for the upper NXT may be confused for a lower NXT query.  This
-is akin to the issue of the ANY query, where a server with some cached
-data will answer with just that and not seek the rest of the data.
-
-Note that distinguishing between an upper and lower NXT is a trivial
-operation, especially so if the SIG RR is available.
-
-A resolver may know the child's server's addresses and the parent zone
-may not be sharing servers with the child.  In this case the resolver
-will need to be able to locate the parent zones (possibly having to go
-to the root servers and descend) in order to obtain the upper NXT
-record.
-
-A potential solution to this is to define an NXT meta-query that will
-force a recursive server to find all available NXT RR sets for a given
-name.  Details of this have not been examined.
-
-3.4 Interaction with Dynamic Update
-
-Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update-
-xy.txt] defines a means by which a zone can change without undergoing
-
-Expires October 13, 2000                                     [Page  8]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-a full reload.  This combination of dynamic update and the proposed
-use of the NXT record to signify a child's status raises some
-concerns.
-
-First a few elements need to be labeled.  There is an off-line signer,
-which is the process that signs zone data files away from the name
-server.  There is an on-line signer, part of a name server, that the
-dynamic update mechanism uses to sign the updated data.  Finally,
-there is an on-line key validator, perhaps a misnomer, which accepts
-requests for parent signatures over each child zone's keys.
-
-The proposal depicted in this draft relies upon the on-line key
-validator informing the on-line and off-line signers of the status of
-a child, recall that the status of a child has a temporal element.
-E.g., a signature may be generated for just the month of July, so the
-child is secured for the month of July, but not the month of August.
-
-The first issues pertain to the way in which an off-line signer comes
-to encode a validation in an NXT record.  There is a need for the
-status information to flow from the on-line validator to the off-line
-signer and then be used as input to the signing process.  The way that
-this information makes the transition is an issue.  The second issue
-is through what mechanism is this information ingested into the NXT
-generating process.  Recall that all other information can be derived
-by the zone data, the status of the child isn't stored anywhere else
-in the parent zone.
-
-The next issue is the means in which a validation action is reported
-to the active zone.  On the surface, dynamically updating the NXT
-would seem to make sense, but updating the NXT in this manner can lead
-to a race condition in the server, this is unstable.  The issue here
-is deriving a mechanism by which a name server knows to signify that
-the child status has changed.  Note that this applies to newly
-validated keys as well as the granting of a child's request to cancel
-a validation.
-
-The final issue is the operation of the off-line signer.  When an NXT
-is being regenerated, the old NXT is needed to see what the previous
-setting of the child's status had been.  The old NXT signature is also
-needed to know that, had the child been known to be secured, for what
-interval was is it thought to be secured so that the new NXT signature
-is appropriately set.  Of course, if the reason for updating the NXT
-is a change as described in the previous paragraph, the old NXT is of
-lesser value.
-
-The issue raised in the last paragraph leads to a questioning of the
-sanity of using signature validity periods to signify the temporal
-status of data in a server.  What does a server return if the NXT
-needed is not currently covered by a valid signature?
-
-4 NULL keys
-
-Through the use of the types present to indicate the existence of a
-signature validating the KEY set of a child, the need for NULL keys
-
-Expires October 13, 2000                                     [Page  9]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-effectively disappears.  NULL keys are left as a defined entity, but
-are rendered meaningless in DNSSEC.
-
-5 Experimental Status
-
-Without NULL keys, an experimentally secured zone cannot be defined as
-it is in RFC 2535.  The purpose of an experimentally secured zone was
-to facilitate the migration from an unsecured zone to a secured zone.
-
-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 privately 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 preconfiguration 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.
-
-6 IANA/ICANN Considerations
-
-This document does not request any action from an assigned number
-authority nor recommends any actions.
-
-7 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.
-
-8 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) and CAIRN (a
-DARPA-funded research network).  Further discussions leading to the
-document include Olafur Gudmundsson, Russ Mundy, Robert Watson, and
-Brian Wellington.
-
-9 References
-
-[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities,"
-RFC 1034, November 1987.
-
-[RFC1035] P. Mockapetris, "Domain Names - Implementation and
-Specification," RFC 1034, November 1987.
-
-
-Expires October 13, 2000                                     [Page 10]
-DNS Security Extension Clarification on Zone Status     April 13, 2000
-
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels," RFC 2119, March 1997
-
-[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
-Updates in the Domain Name System," RFC 2136, April 1997.
-
-[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
-2535, March 1999.
-
-[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
-Secure Domain Name System (DNS) Dynamic Update," version 00, February
-2000.
-
-10 Author Information
-
-Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443
-259 2352 <lewis@tislabs.com>
-
-11 Full Copyright Statement
-
-Copyright (C) The Internet Society (1999, 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."
-
-
-
-
-
-
-
-
-
-
-
-Expires October 13, 2000                                     [Page 11]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-zone-status-03.txt b/doc/draft/draft-ietf-dnsext-zone-status-03.txt
new file mode 100644
index 00000000..b3599b14
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-zone-status-03.txt
@@ -0,0 +1,524 @@
+DNSEXT WG                                                 Edward Lewis
+INTERNET DRAFT                                                NAI Labs
+Category:I-D                                        September 19, 2000
+
+           DNS Security Extension Clarification on Zone Status
+                 <draft-ietf-dnsext-zone-status-03.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.
+
+Comments should be sent to the authors or the DNSEXT WG mailing list
+namedroppers@ops.ietf.org.
+
+This draft expires on March, 19, 2001.
+
+Copyright Notice
+
+Copyright (C) The Internet Society (1999, 2000).  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.
+
+
+Expires March 19, 2001                                      [Page  1]
+Internet Draft                                     September 19, 2000
+
+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.
+
+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
+
+Expires March 19, 2001                                      [Page  2]
+Internet Draft                                     September 19, 2000
+
+security.  Other resolvers (not so configured) will recognize this
+island as unsecured.
+
+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 draft, [SIGAUTH], that restricts this activity.  Regardless
+of the other draft, 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 Determing 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 becuase 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.
+
+Overlapping islands of security introduce no conceptually interesting
+
+Expires March 19, 2001                                      [Page  3]
+Internet Draft                                     September 19, 2000
+
+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.
+
+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.
+
+Expires March 19, 2001                                      [Page  4]
+Internet Draft                                     September 19, 2000
+
+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 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' 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
+
+Expires March 19, 2001                                      [Page  5]
+Internet Draft                                     September 19, 2000
+
+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).
+
+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.
+
+
+
+Expires March 19, 2001                                      [Page  6]
+Internet Draft                                     September 19, 2000
+
+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 component 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.
+
+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
+
+Expires March 19, 2001                                      [Page  7]
+Internet Draft                                     September 19, 2000
+
+secured is a special case of globally 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/ICANN Considerations
+
+This document does not request any action from an assigned number
+authority nor recommends any actions.
+
+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] P. Mockapetris, "Domain Names - Concepts and Facilities,"
+RFC 1034, November 1987.
+
+[RFC1035] P. Mockapetris, "Domain Names - Implementation and
+Specification," RFC 1034, November 1987.
+
+[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels," RFC 2119, March 1997
+
+[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
+Updates in the Domain Name System," RFC 2136, April 1997.
+
+[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
+2535, March 1999.
+
+
+Expires March 19, 2001                                      [Page  8]
+Internet Draft                                     September 19, 2000
+
+[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
+Secure Domain Name System (DNS) Dynamic Update," version 00, February
+2000.
+
+[SIGAUTH] B. Wellington, draft-ietf-dnsext-signing-auth-01.txt
+
+10 Author Information
+
+Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443
+259 2352 <lewis@tislabs.com>
+
+11 Full Copyright Statement
+
+Copyright (C) The Internet Society (1999, 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."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires March 19, 2001                                      [Page  9]
+
+
diff --git a/doc/draft/draft-ietf-enum-rqmts-01.txt b/doc/draft/draft-ietf-enum-rqmts-01.txt
index ce6f2358..ad453c4f 100644
--- a/doc/draft/draft-ietf-enum-rqmts-01.txt
+++ b/doc/draft/draft-ietf-enum-rqmts-01.txt
@@ -2,341 +2,341 @@
 Telephone Number Mapping                                       A. Brown
 Internet Draft                                          Nortel Networks
 Document: <draft-ietf-enum-rqmts-01.txt>                      June 2000
-Category: Informational 
- 
- 
-                           ENUM Requirements 
- 
- 
-Status of this Memo 
-    
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1].  
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
+Category: Informational
+
+
+                           ENUM Requirements
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [1].
+
+   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. 
-    
-1.      Abstract 
-    
-   This paper defines the requirements for a DNS-based architecture and 
-   protocols for mapping a telephone number to a set of attributes 
-   (e.g., URLs) that can be used to contact a resource associated with 
-   that number.  There are many possible protocols that can be 
-   considered for a telephone number mapping service.  The purpose of 
-   this document is to focus discussion on a DNS-based solution.  The 
-   intention is to enumerate the expectations of such a solution and to 
-   clarify the scope. 
-    
-2.      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 RFC-2119 [2]. 
-    
-3.      Requirements 
-    
-3.1     Endpoint Address Lookup 
-    
-   The system SHALL provide a service for the retrieval of service 
-   specific endpoint addresses (e.g., email address, IP address, SIP 
-   address, URL, etc.) or the retrieval of the addresses of servers, if 
-   available, which may contain this endpoint information. 
-    
-  
-                          ENUM Requirements                  June 2000 
- 
- 
-3.2     Capabilities Retrieval/Negotiation 
-    
-   The retrieval or negotiation of capabilities is beyond the scope of 
-   the system.   
-    
-3.3     Retrieval of Additional Information and Capabilities 
-    
-   The retrieval of additional, application-specific information (e.g., 
-   spoken name for verification purposes) is beyond the scope of the 
-   system.  The system MUST provide a service for the retrieval of 
-   protocol and service information if available. 
-    
-   The system SHOULD provide access to capabilities relevant to the 
-   telephone number in question.  The retrieval or negotiation of 
-   capabilities will depend on the outcome of the rescap work or work 
-   done in other groups. 
-    
-3.4     Qualification of the Request 
-    
-   The system is not required to enable the qualification of a request 
-   by a user, for the purposes of filtering for reducing returned 
-   information or for traffic reduction.  
-    
-3.5     Provisioning 
-    
-   The architecture and protocol MAY support at least the existing 
-   administrative model as the current E.164 telephone number 
-   delegation system.  The protocol SHOULD also provide the ability to 
-   support corporate numbering plan or competitive directory service 
-   providers under separate root domains.  It SHOULD NOT require an 
-   additional centralized administrator beyond that required for the 
-   existing telephone number system. 
-    
-   The distribution of telephone numbers is a national affair by ITU 
-   treaty and different telephone number distribution schemes may 
-   require different delegation models.  How nations choose to 
-   administer the ENUM space within their borders is a national issue.  
-   In any case, the subscriber or enterprise is the ultimate authority 
-   for service provisioning. 
-    
-   Further, it must be possible for the authority to which a telephone 
-   number has been delegated to redirect the query to a different 
-   entity that provides service-specific information for that number. 
-    
-3.6     Propagation of Changes 
-    
-   Propagation of Changes If multiple copies of the data are 
-   distributed in different areas, their update should be incorporated 
-   almost simultaneously depending on the application of DNS to 
-   services. 
-    
-
-
-  
-                          ENUM Requirements                  June 2000 
- 
- 
-   When a numbering plan change is made in a country or network, the 
-   update of relevant E.164 number data in DNS needs to be coordinated 
-   with the change. 
-    
-3.7     Response Timeout 
-    
-   The system SHALL have a defined timeout mechanism. 
-    
-3.8     Global Number Portability 
-    
-   The system MUST support existing local number portability 
-   mechanisms, where applicable.  It is RECOMMENDED that the system not 
-   be designed in such as way as to impede future global number 
-   portability.  
-    
-3.9     Scalability 
-    
-   The system MUST scale to handle quantities of telephone numbers and 
-   queries comparable to current and expected future PSTN usage.   
-    
-   It must be possible to operate the system based on telephone number 
+   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.
+
+1.      Abstract
+
+   This paper defines the requirements for a DNS-based architecture and
+   protocols for mapping a telephone number to a set of attributes
+   (e.g., URLs) that can be used to contact a resource associated with
+   that number.  There are many possible protocols that can be
+   considered for a telephone number mapping service.  The purpose of
+   this document is to focus discussion on a DNS-based solution.  The
+   intention is to enumerate the expectations of such a solution and to
+   clarify the scope.
+
+2.      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 RFC-2119 [2].
+
+3.      Requirements
+
+3.1     Endpoint Address Lookup
+
+   The system SHALL provide a service for the retrieval of service
+   specific endpoint addresses (e.g., email address, IP address, SIP
+   address, URL, etc.) or the retrieval of the addresses of servers, if
+   available, which may contain this endpoint information.
+
+
+                          ENUM Requirements                  June 2000
+
+
+3.2     Capabilities Retrieval/Negotiation
+
+   The retrieval or negotiation of capabilities is beyond the scope of
+   the system.
+
+3.3     Retrieval of Additional Information and Capabilities
+
+   The retrieval of additional, application-specific information (e.g.,
+   spoken name for verification purposes) is beyond the scope of the
+   system.  The system MUST provide a service for the retrieval of
+   protocol and service information if available.
+
+   The system SHOULD provide access to capabilities relevant to the
+   telephone number in question.  The retrieval or negotiation of
+   capabilities will depend on the outcome of the rescap work or work
+   done in other groups.
+
+3.4     Qualification of the Request
+
+   The system is not required to enable the qualification of a request
+   by a user, for the purposes of filtering for reducing returned
+   information or for traffic reduction.
+
+3.5     Provisioning
+
+   The architecture and protocol MAY support at least the existing
+   administrative model as the current E.164 telephone number
+   delegation system.  The protocol SHOULD also provide the ability to
+   support corporate numbering plan or competitive directory service
+   providers under separate root domains.  It SHOULD NOT require an
+   additional centralized administrator beyond that required for the
+   existing telephone number system.
+
+   The distribution of telephone numbers is a national affair by ITU
+   treaty and different telephone number distribution schemes may
+   require different delegation models.  How nations choose to
+   administer the ENUM space within their borders is a national issue.
+   In any case, the subscriber or enterprise is the ultimate authority
+   for service provisioning.
+
+   Further, it must be possible for the authority to which a telephone
+   number has been delegated to redirect the query to a different
+   entity that provides service-specific information for that number.
+
+3.6     Propagation of Changes
+
+   Propagation of Changes If multiple copies of the data are
+   distributed in different areas, their update should be incorporated
+   almost simultaneously depending on the application of DNS to
+   services.
+
+
+
+
+                          ENUM Requirements                  June 2000
+
+
+   When a numbering plan change is made in a country or network, the
+   update of relevant E.164 number data in DNS needs to be coordinated
+   with the change.
+
+3.7     Response Timeout
+
+   The system SHALL have a defined timeout mechanism.
+
+3.8     Global Number Portability
+
+   The system MUST support existing local number portability
+   mechanisms, where applicable.  It is RECOMMENDED that the system not
+   be designed in such as way as to impede future global number
+   portability.
+
+3.9     Scalability
+
+   The system MUST scale to handle quantities of telephone numbers and
+   queries comparable to current and expected future PSTN usage.
+
+   It must be possible to operate the system based on telephone number
    blocks defined at the digit boundaries as well as explicit per-
-   number configuration. 
-    
-3.10    Query Performance 
-    
-   It SHOULD be possible to administer the ENUM service using the 
-   selected protocols and structures such that the current user 
-   expectations for latency in telecommunications services can be met.  
-   In particular, it SHOULD be possible to operate the system in such a 
-   manner that an ENUM query for a service-specific record can be 
-   satisfied within one second 95% of the time and that within two 
-   seconds, the query can be satisfied 99% of the time. 
-    
-3.11    Other PSTN Numbering Services 
-    
-   E.164 numbers, short codes, service codes and prefixes are 
-   categorized in dialing plans.  A prefix is an indicator consisting 
-   of one or more digits that allows the selection of different types 
-   of number formats, networks and/or services.  Prefixes are not part 
-   of the number and are part of a dialing plan.  The uses and the 
-   formats of prefixes are a national matter.  Short codes, e.g. 
-   emergency, or service codes may be used based on the national 
-   numbering plan.  Those codes are not universal and typically valid 
-   only within a numbering domain identified with the same country code 
-   or country code + network identification code. 
-    
-   PSTN type numbering services such as Emergency 911, directory 
-   assistance 411, and other carrier codes for services accessible via 
-   non-E164 (or subset) telephone number service access codes are 
-   outside the scope of ENUM. 
-    
-3.12    Privacy 
-  
-                          ENUM Requirements                  June 2000 
- 
- 
-    
-   The system MUST allow the owner of the telephone number to control 
-   the information which prospective callers may receive. 
-    
-3.13    Competition 
-    
-   The solution MUST permit competing service providers to offer 
-   telecommunications service for a given number.  Competing 
-   telecommunications services MUST be enabled where the ENUM entry is 
-   administered by the single entity to which the number is delegated.  
-   Who that single entity is, is beyond the scope of ENUM. 
-    
-3.14    Authorization of Requests and Responses 
-    
-   The system SHALL enable the authorization of requests and responses. 
-    
-3.15    Privacy and Integrity of Requests and Responses 
-    
-   The system SHALL enable the privacy and integrity of requests and 
-   responses. 
-    
-3.16    Call Routing 
-    
-   The system is not required to provide a service for routing calls or 
-   locating gateways to a specific service. 
-    
-3.17    Service Logic 
-    
-   The system is not responsible for employing service logic for the 
-   intelligent retrieval of information. 
-    
-3.18    E.164 Numbers 
-    
-   The system is not responsible for returning information on private 
-   numbering plans and non-E.164 numbers.  The system is responsible 
-   for returning information on 1-800 and other legitimate E.164 
-   numbers.   
-    
-3.19    Application Specific Use of ENUM 
-    
-   The ENUM service MUST be application agnostic.  It is expected that 
-   various other IETF work groups will develop ENUM specific usage 
-   profiles for their specific application.  ENUM will not mandate the 
-   use of any specific DNS Resource Record for any particular 
-   application.  
- 
-4.      Security Considerations 
- 
-   This document specifies several security requirements including 
-   privacy of information, and authorization, privacy and integrity or 
-   requests and responses.  
-    
-
-  
-                          ENUM Requirements                  June 2000 
- 
- 
-   The system will be designed to retrieve information required to 
-   initiate an Internet telephony session.  Each of these session types 
-   will have their own security threats, which should be addressed in 
-   the groups responsible for those services. 
- 
-5.      References 
-    
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-6.      Acknowledgements         
-    
-   This document is based on discussions from the ENUM working group. 
-    
-7.      Author's Addresses 
-    
-   Anne Brown 
-   Nortel Networks 
-   P.O. Box 3511, Station C 
-   K1Y 4H7 
-   Phone: +1 613 765 5274 
-   Email: arbrown@nortelnetworks.com 
-    
-8.      Changes From draft-enum-rqmts-00.txt 
-    
-   Based on WG discussions and input documents from the SG2 workshop, 
-   the following changes have been made since the previous version of 
-   this draft: 
-    
-        3.1 Endpoint Address Lookup 
-                Major - URLs are not the only response 
-        3.3 Retrieval of Additional Information and Capabilities 
-                Renamed from "Retrieval of Additional Information" 
-                Minor - Added paragraph on capabilities 
-        3.5 Provisioning 
-                Major - New text involving change of ENUM scope 
-        3.6 Propagation of Changes 
-                New section 
-                Major - New section based on nnar-e164-dns-iw-info.txt 
-        3.9 Scalability 
-                Renumbered from 3.8 
-                Major - New paragraph on handling of both blocks and 
-                individual telephone numbers. 
-        3.10 Query Performance 
-                Renumbered from 3.9 
-                Major - Upgraded to support PSTN performance  
-                expectations 
-        3.11 Other PSTN Numbering Services 
-                Renumbered from 3.10 
-  
-                          ENUM Requirements                  June 2000 
- 
- 
-                Renamed from "Other PSTN Services" 
-                Minor - Changes for clarification based on WG  
-                discussions and nnar-e164-dns-iw-info.txt 
-    
-        3.13 Competition 
-                Renumbered from 3.12 
-                Major - Telephone number MUST be able to be  
-                administered by a single entity 
-                 
-        3.19 Application Specific Use of ENUM 
-                New Section 
-                Major - For clarification  
-    
-Full Copyright Statement 
-    
-   "Copyright (C) The Internet Society (date). 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 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
+   number configuration.
+
+3.10    Query Performance
+
+   It SHOULD be possible to administer the ENUM service using the
+   selected protocols and structures such that the current user
+   expectations for latency in telecommunications services can be met.
+   In particular, it SHOULD be possible to operate the system in such a
+   manner that an ENUM query for a service-specific record can be
+   satisfied within one second 95% of the time and that within two
+   seconds, the query can be satisfied 99% of the time.
+
+3.11    Other PSTN Numbering Services
+
+   E.164 numbers, short codes, service codes and prefixes are
+   categorized in dialing plans.  A prefix is an indicator consisting
+   of one or more digits that allows the selection of different types
+   of number formats, networks and/or services.  Prefixes are not part
+   of the number and are part of a dialing plan.  The uses and the
+   formats of prefixes are a national matter.  Short codes, e.g.
+   emergency, or service codes may be used based on the national
+   numbering plan.  Those codes are not universal and typically valid
+   only within a numbering domain identified with the same country code
+   or country code + network identification code.
+
+   PSTN type numbering services such as Emergency 911, directory
+   assistance 411, and other carrier codes for services accessible via
+   non-E164 (or subset) telephone number service access codes are
+   outside the scope of ENUM.
+
+3.12    Privacy
+
+                          ENUM Requirements                  June 2000
+
+
+
+   The system MUST allow the owner of the telephone number to control
+   the information which prospective callers may receive.
+
+3.13    Competition
+
+   The solution MUST permit competing service providers to offer
+   telecommunications service for a given number.  Competing
+   telecommunications services MUST be enabled where the ENUM entry is
+   administered by the single entity to which the number is delegated.
+   Who that single entity is, is beyond the scope of ENUM.
+
+3.14    Authorization of Requests and Responses
+
+   The system SHALL enable the authorization of requests and responses.
+
+3.15    Privacy and Integrity of Requests and Responses
+
+   The system SHALL enable the privacy and integrity of requests and
+   responses.
+
+3.16    Call Routing
+
+   The system is not required to provide a service for routing calls or
+   locating gateways to a specific service.
+
+3.17    Service Logic
+
+   The system is not responsible for employing service logic for the
+   intelligent retrieval of information.
+
+3.18    E.164 Numbers
+
+   The system is not responsible for returning information on private
+   numbering plans and non-E.164 numbers.  The system is responsible
+   for returning information on 1-800 and other legitimate E.164
+   numbers.
+
+3.19    Application Specific Use of ENUM
+
+   The ENUM service MUST be application agnostic.  It is expected that
+   various other IETF work groups will develop ENUM specific usage
+   profiles for their specific application.  ENUM will not mandate the
+   use of any specific DNS Resource Record for any particular
+   application.
+
+4.      Security Considerations
+
+   This document specifies several security requirements including
+   privacy of information, and authorization, privacy and integrity or
+   requests and responses.
+
+
+
+                          ENUM Requirements                  June 2000
+
+
+   The system will be designed to retrieve information required to
+   initiate an Internet telephony session.  Each of these session types
+   will have their own security threats, which should be addressed in
+   the groups responsible for those services.
+
+5.      References
+
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+      9, RFC 2026, October 1996.
+
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+      Levels", BCP 14, RFC 2119, March 1997
+
+6.      Acknowledgements
+
+   This document is based on discussions from the ENUM working group.
+
+7.      Author's Addresses
+
+   Anne Brown
+   Nortel Networks
+   P.O. Box 3511, Station C
+   K1Y 4H7
+   Phone: +1 613 765 5274
+   Email: arbrown@nortelnetworks.com
+
+8.      Changes From draft-enum-rqmts-00.txt
+
+   Based on WG discussions and input documents from the SG2 workshop,
+   the following changes have been made since the previous version of
+   this draft:
+
+        3.1 Endpoint Address Lookup
+                Major - URLs are not the only response
+        3.3 Retrieval of Additional Information and Capabilities
+                Renamed from "Retrieval of Additional Information"
+                Minor - Added paragraph on capabilities
+        3.5 Provisioning
+                Major - New text involving change of ENUM scope
+        3.6 Propagation of Changes
+                New section
+                Major - New section based on nnar-e164-dns-iw-info.txt
+        3.9 Scalability
+                Renumbered from 3.8
+                Major - New paragraph on handling of both blocks and
+                individual telephone numbers.
+        3.10 Query Performance
+                Renumbered from 3.9
+                Major - Upgraded to support PSTN performance
+                expectations
+        3.11 Other PSTN Numbering Services
+                Renumbered from 3.10
+
+                          ENUM Requirements                  June 2000
+
+
+                Renamed from "Other PSTN Services"
+                Minor - Changes for clarification based on WG
+                discussions and nnar-e164-dns-iw-info.txt
+
+        3.13 Competition
+                Renumbered from 3.12
+                Major - Telephone number MUST be able to be
+                administered by a single entity
+
+        3.19 Application Specific Use of ENUM
+                New Section
+                Major - For clarification
+
+Full Copyright Statement
+
+   "Copyright (C) The Internet Society (date). 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
diff --git a/doc/draft/draft-ietf-idn-aceid-00.txt b/doc/draft/draft-ietf-idn-aceid-00.txt
new file mode 100644
index 00000000..5aa36647
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-aceid-00.txt
@@ -0,0 +1,201 @@
+Internet Draft                                      Naomasa Maruyama 
+draft-ietf-idn-aceid-00.txt                           Yoshiro Yoneya 
+November 17, 2000                                              JPNIC 
+Expires May 17, 2001
+
+           Proposal for a determining process of ACE identifier
+
+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 IETF IDN WG, various kinds of ASCII Compatible Encodings,
+hereafter abbreviated as "ACE", are discussed as methods for realizing
+multilingual domain names (hereafter referred to as "MDN").  Each ACE
+uses a prefix or a suffix as an identifier in order for MDNs to fit
+within the existing ASCII domain name space.  In other words,
+acceptance of an ACE proposal as an Internet standard means that the
+existing ASCII domain name space will be partitioned, in order to
+accommodate MDN space.
+
+    This document describes possible trouble in the standardization
+process of ACE, and proposes a solution for it.
+
+
+1. Present situation and concern
+
+    At present, some specifications relating to MDN specify their own
+ACE identifiers.  In these drafts, multilingual domain names encoded
+into ASCII character strings, with the ACE identifiers in their heads
+or tails, are merely ASCII character strings.  It is possible
+accidently or intentionally to register a domain name that is not an
+MDN but has the designated ACE identifier string.
+
+    If this kind of registration takes place, there is no warranty
+that the domain name will be consistent with MDN semantics.
+Furthermore, there is no warranty that the name, interpreted as an
+MDN, will comply with the registration policies of the registry, when
+the ACE identifier proposal is finally accepted as an Internet
+standard.  This might cause problems with name disputes and/or
+revocations.
+
+    Therefore, the current situation letting independent ACE proposal
+authors arbitrarily select an ACE identifier, hence permitting domain
+name registrants registrer such names, may hinder deployment of MDN
+technology.
+
+
+2. Selecting ACE identifiers
+
+    In order to maintain a smooth standardization process for ACE,
+this document proposes a strategy for selecting and reserving of ACE
+identifiers and a method for assigning them.
+
+
+2.1 The ACE identifier candidates and tentative suspension of
+     registering relevant domain names
+
+    All strings starting with a combination of two alpha-numericals,
+followed by two hyphens, are defined to be ACE prefix identifier
+candidates.  All strings starting with one hyphen followed by three
+alpha-numericals, and strings starting with two hyphens followed by
+two alpha-numericals are defined as ACE suffix identifier candidates.
+ACE prefix identifier candidates and ACE suffix identifier candidates
+are collectively called ACE identifier candidates.
+
+    All the domain name registries recognized by ICANN SHOULD
+tentatively suspend registration of domain names which have an ACE
+prefix identifier candidate at the heads of one of the labels of the
+domain name and those which have an ACE suffix identifier candidate at
+the tail of one of the labels of the name.  These domain names are
+collectively called "relevant domain names".
+
+    This suspension should be continued until March 1, 2001 00:00:00 UTC.
+
+
+2.2 Survey of relevant domain name registration
+
+    All registries recognized by ICANN SHOULD conduct a survey about
+relevant domain names registered in their zone, and report, no later
+than February 10, 2001 00:00:00 UTC, all of the ACE identifier
+candidates which are used by relevant domain names.
+
+
+2.3 Selection of ACE identifiers and permanent blocking of
+     relevant domain names
+
+    The IDN WG MUST summarize the reports and list ACE identifier
+candidates that are not reported to be used in registered domain names
+by February 17, 2001 00:00:00 UTC, and select ten to twenty ACE prefix
+identifier candidates and ten to twenty ACE suffix identifier
+candidates for ACE identifiers.  Among these twenty to forty ACE
+identifiers, one prefix identifier and one suffix identifier will be
+used for experiments.  Others will be used, one by one as ACE standard
+evolves.
+
+    The list of ACE identifiers will be sent to IANA, and will be
+maintained by IANA from February 24, 2001 00:00:00 UTC.  Domain names
+relevant to these identifiers SHOULD NOT be registered in any DNS
+zone, except for registration of multilingual domain names compliant
+to one of future IDN standards.  This new restriction about the domain
+name space will be notified to all ICANN recognized registries by IANA
+immediately after it receives the list.
+
+
+2.4 Blocking of registration for relevant domain names
+
+    Domain names relevant to ACE identifiers selected by the procedure
+described in section 2.3 SHOULD NOT be registered in any zone of ICANN
+recognized registries except for registration of multilingual domain
+names compliant to one of future IDN standards.  All ICANN recognized
+registries SHOULD implement this restriction no later than March 1,
+2001 00:00:00 UTC.
+
+    Registration for domain names relevant to ACE identifier
+candidates, tentatively suspended by 2.1, but not relevant to ACE
+identifiers selected by section 2.3 MAY be reopened from March 1, 2001
+00:00:00 UTC.
+
+
+3. Use of an ACE identifier in writing an ACE proposal
+
+    When writing an ACE proposal using an ACE identifier, the author
+SHOULD either describe the ACE identifier as "to be decided" and left
+to discretion of the IDN WG or other organ of IETF or ICANN, or use
+either of the ACE identifiers for experiment defined in section 2.3,
+with a unique version number added after or before the prefix or
+suffix.
+
+    If a proposal is validated and published as an Internet Draft, the
+IDN WG or other organ of IETF or ICANN MUST replace the "to be
+decided" part with an experimental identifier with a unique version
+number added after or before the prefix or the suffix.
+
+
+4. Determination of ACE identifier
+
+    When an Internet Draft relating to ACE is accepted as an Internet
+standard and becomes an RFC, IDN WG or other organ of IETF or ICANN
+MUST replace the experimental ACE identifier, augmented by the version
+number, with one of the ACE identifiers.
+
+
+5. Security considerations
+
+None in particular.
+
+
+6. References
+
+[IDNREQ]        Z Wenzel, J Seng, "Requirements of Internationalized Domain
+                Names", draft-ietf-idn-requirements-03.txt, Jun 2000.
+
+[RACE]          P Hoffman, "RACE: Row-based ASCII Compatible Encoding for
+                IDN", draft-ietf-idn-race-02.txt, Oct 2000.
+
+[BRACE]         A Costello, "BRACE: Bi-mode Row-based ASCII-Compatible
+                Encoding for IDN", draft-ietf-idn-brace-00.txt, Sep 2000.
+
+[LACE]          P Hoffman, "LACE: Length-based ASCII Compatible Encoding for
+                IDN", draft-ietf-idn-lace-00.txt, Nov 2000.
+
+[VERSION]       M Blanchet, "Handling versions of internationalized domain
+                names protocols", draft-ietf-idn-version-00.txt, Nov 2000.
+
+
+7. Acknowledgements
+
+JPNIC IDN-TF members,
+Dave Crocker.
+
+8. Author's Address
+
+Naomasa Maruyama
+Japan Network Information Center
+Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
+Chiyoda-ku Tokyo 101-0052, Japan
+maruyama@nic.ad.jp
+
+Yoshiro Yoneya
+Japan Network Information Center
+Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
+Chiyoda-ku Tokyo 101-0052, Japan
+yone@nic.ad.jp
diff --git a/doc/draft/draft-ietf-idn-brace-00.txt b/doc/draft/draft-ietf-idn-brace-00.txt
new file mode 100644
index 00000000..be93f6a9
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-brace-00.txt
@@ -0,0 +1,1053 @@
+INTERNET-DRAFT                                          Adam M. Costello
+draft-ietf-idn-brace-00.txt                                  2000-Sep-14
+Expires 2001-Mar-14
+
+       BRACE: Bi-mode Row-based ASCII-Compatible Encoding for IDN
+                              version 0.1.2
+
+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
+
+    Distribution of this document is unlimited.  Please send comments
+    to the author at amc@cs.berkeley.edu, or to the idn working group
+    at idn@ops.ietf.org.  A newer version of this specification may be
+    available at http://www.cs.berkeley.edu/~amc/charset/brace
+
+Abstract
+
+    BRACE is a reversible function from Unicode (UTF-16) [UNICODE]
+    text strings to host name labels.  Host name labels are defined by
+    [RFC952] and [RFC1123] as case-insensitive strings of ASCII letters,
+    digits, and hyphens, neither beginning nor ending with a hyphen.
+    [RFC1034] restricts the length of labels to 63 characters.
+
+Contents
+
+    Primary goals
+    Secondary goals
+    Overview
+    Encoding procedure
+    Base-32 characters
+    Encoding styles
+    Decoding procedure
+    Comparison with RACE
+    Example strings
+    Security considerations
+    References
+    Author
+    Example implementation
+
+Primary goals
+
+    Efficient encoding:  Small ratio of encoded size to original size,
+    for all UTF-16 strings.
+
+    Uniqueness:  Every UTF-16 string maps to at most one label.
+
+    Completeness:  Every UTF-16 string maps to a label, provided it is
+    not too long.  Restrictions on which UTF-16 strings are allowed is
+    purely a matter of policy.
+
+    Degeneration:  All valid host name labels that do not end with the
+    BRACE signature "-8Q9" (or "-8q9") are the BRACE encodings of their
+    own UTF-16 representations.
+
+Secondary goals
+
+    Conceptual simplicity:  This has been somewhat compromised for the
+    sake of efficient encoding.
+
+    Readability:  ASCII letters and digits in the original string are
+    represented literally in the encoded string.  This comes for free
+    because it is the most efficient encoding anyway.
+
+Overview
+
+    The encoded string alternates between two modes.  ASCII letters,
+    digits, and hyphens in the Unicode string (which will henceforth be
+    called LDH characters) are encoded literally, except that hyphens
+    are doubled.  Non-LDH codes in the Unicode string are encoded
+    using base-32 mode, in which each character of the encoded string
+    represents five bits.  Single hyphens in the encoded string indicate
+    mode changes.
+
+    The base-32 mode uses exactly one of four styles.  Half-row style is
+    used for Unicode strings in which all the non-LDH codes belong to
+    a single half-row (have the same upper 9 bits).  Full-row style is
+    used for Unicode strings in which all the non-LDH codes belong to a
+    single row (have the same upper 8 bits) but not all the same half.
+    Mixed style is used when when many of the non-LDH characters (but
+    not all of them) belong to the same row.  No-row style is used for
+    all other strings.
+
+Encoding procedure
+
+    If the UTF-16 string contains more than 63 16-bit codes, it's too
+    long, so abort.
+
+    If the upper bytes are all zero, and the string formed by the lower
+    bytes is a valid host name label and does not end with "-8Q9" or
+    "-8q9", output the low bytes and stop.
+
+    The encoder needs a bit queue capable of holding up to 22 bits, a
+    buffer of LDH characters capable of holding up to 124 characters,
+    and a 4-value encoding style indicator.  The LDH buffer is initially
+    empty.  The initial contents of the bit queue, and the value of the
+    style indicator, depend on which encoding style is chosen (which
+    is explained below).  Bit strings are enqueued and dequeued in
+    big-endian order (most significant bit first).
+
+    After choosing the style and initializing the bit queue, perform the
+    following actions:
+
+        while the bit queue contains at least 5 bits
+            dequeue 5 bits
+            output the corresponding base-32 character
+        endwhile
+
+        for each 16-bit code of the UTF-16 string (in order) do
+            if the code is 0x002D ("-", ASCII hyphen) then
+                append two hyphens to the ASCII buffer
+            else if the code is an LDH character then
+                if the LDH buffer contains no non-hyphens then
+                    append one hyphen to the LDH buffer
+                endif
+
+                append the code to the LDH buffer
+            else (the code is not an LDH character)
+                if the LDH buffer contains any non-hyphens then
+                    append one hyphen to the LDH buffer
+                endif
+
+                if the bit queue is empty then
+                    output the LDH buffer and reset it to empty
+                endif
+
+                enqueue the bit string corresponding to the code
+                (the bit string depends on the encoding style)
+                dequeue 5 bits
+                output the corresponding base-32 character
+                output the LDH buffer and reset it to empty
+
+                while the bit queue contains at least 5 bits
+                    dequeue 5 bits
+                    output the corresponding base-32 character
+                endwhile
+            endif
+        endfor
+
+        if the bit queue is not empty
+            enqueue zero bits until it contains 5 bits
+            dequeue 5 bits
+            output the corresponding base-32 character
+        endif
+
+        output the LDH buffer
+        output the LDH characters "-8Q9"
+
+    If the total number of characters output was greater than 63, the
+    string is too long for a host name label.
+
+    Notice that a group of LDH characters appears in the output as soon
+    as all the bits of the preceeding non-LDH codes have appeared.  The
+    base-32 character that appears just before the switch to literal
+    mode may contain at most four bits of information from the first
+    non-LDH character that comes after the LDH group.
+
+Base-32 characters
+
+    "2" =  0 = 00000
+    "3" =  1 = 00001
+    "4" =  2 = 00010
+    "5" =  3 = 00011
+    "6" =  4 = 00100
+    "7" =  5 = 00101
+    "8" =  6 = 00110
+    "9" =  7 = 00111
+    "A" =  8 = 01000
+    "B" =  9 = 01001
+    "C" = 10 = 01010
+    "D" = 11 = 01011
+    "E" = 12 = 01100
+    "F" = 13 = 01101
+    "G" = 14 = 01110
+    "H" = 15 = 01111
+    "I" = 16 = 10000
+    "J" = 17 = 10001
+    "K" = 18 = 10010
+    "M" = 19 = 10011
+    "N" = 20 = 10100
+    "P" = 21 = 10101
+    "Q" = 22 = 10110
+    "R" = 23 = 10111
+    "S" = 24 = 11000
+    "T" = 25 = 11001
+    "U" = 26 = 11010
+    "V" = 27 = 11011
+    "W" = 28 = 11100
+    "X" = 29 = 11101
+    "Y" = 30 = 11110
+    "Z" = 31 = 11111
+
+    The digits "0" and "1" and the letters "O" and "L" ("l") are not
+    used, to avoid transcription errors.
+
+    The base-32 characters, like all characters in host name labels, are
+    case-insensitive, so they must be recognized in both upper and lower
+    case.  However, since existing LDH labels are usually stored in
+    lower case, it is recommended that the base-32 portions of encoded
+    names be stored in upper case, to help humans easily pick out the
+    literal portions.
+
+Encoding styles
+
+    The choice of encoding style depends only on the codes in the UTF-16
+    string that are not LDH characters.  It in no way depends on any LDH
+    codes that may be present.
+
+    Each code belongs to a particular half-row, which is given by its
+    upper 9 bits.  If all of the non-LDH codes belong to the same
+    half-row, use half-row style:  Initialize the bit queue by enqueuing
+    two 0 bits followed by the designated half-row number (the 9-bit
+    half-row number shared by all the codes).  During the encoding
+    procedure the bit string corresponding to each code is its lower 7
+    bits.
+
+    If not all the non-LDH codes belong to the same half-row, but they
+    all belong to the same row (same upper 8 bits), use full-row style:
+    Initialize the bit queue by enqueuing a 0 bit, then a 1 bit, then
+    the designated row number (the 8-bit row number shared by all the
+    codes).  During the encoding procedure the bit string corresponding
+    to each code is its lower 8 bits.
+
+    If not all non-LDH codes belong to the same row, then consider
+    using mixed style, which chooses a priviledged half-row.  For each
+    half-row used by the non-LDH codes, count the number of codes that
+    belong to that half-row.  Then, for each half-row, calculate M, the
+    number of base-32 characters that would be required if that half row
+    were chosen:
+
+        N = total number of non-LDH codes
+        H = number of non-LDH codes in the candidate half-row
+        C = number of non-LDH codes in the complementary half-row (the
+            one with the opposite lowest bit)
+        M = (2 + 9 + 18*(N - H - C) + 8*H + 9*C + 4) / 5
+          = 3 + (18*N - 10*H - 9*C) / 5
+
+    (The division is integer division, which discards any remainder.)
+
+    Choose the half-row with the smallest M, breaking ties in favor of
+    lower-numbered half-rows.  Compare this M with M', the number of
+    base-32 characters that would be required if no-row style were used:
+
+        M' = (2 + 16*N + 4) / 5 = (6 + 16*N) / 5
+
+    If M' <= M, use no-row style:  Initialize the bit queue by
+    enqueueing two 1 bits.  There is no designated row number.  During
+    the encoding procedure the bit string corresponding to each code is
+    the full 16-bit code itself.
+
+    If M < M', use mixed style:  Initialize the bit queue by enqueueing
+    a 1 bit, then a 0 bit, then the designated 9-bit half-row number
+    (the one chosen above).  During the encoding procedure the bit
+    string corresponding to each code is:
+
+        0 followed by the lower 7 bits if the code belongs to the chosen
+        half-row;
+
+        10 followed by the lower 7 bits if the code belongs to the
+        complementary half-row;
+
+        11 followed by the whole 16-bit code otherwise.
+
+Decoding procedure
+
+    The following description assumes that UTF-16 output is desired.
+
+    If the input string does not end with "-8Q9" or "-8q9", output the
+    input string (converted from ASCII to UTF-16) and stop.
+
+    The decoder needs a bit queue capable of holding up to 22 bits.  It
+    is initially empty.  It also needs a literal-mode flag, which is
+    initially unset, and a 4-value style indicator.
+
+    Perform the following actions:
+
+        read the first character and enqueue its base-32 quintet
+        dequeue two bits and use them to set the style indicator
+
+        if the style uses a designated full/half row number then
+          while the queue does not contain enough bits to represent it
+            read the next character and enqueue its base-32
+          endwhile
+
+          dequeue enough bits to set the designated row (or half-row)
+        endif
+
+        for each remaining input character except the last four do
+            if the character is an ASCII hyphen then
+                if the next character is also an ASCII hyphen then
+                    skip it
+                    output an ASCII hyphen (converted to UTF-16)
+                else
+                    toggle the literal-mode flag
+                endif
+            else if the literal-mode flag is set then
+                output the character (converted to UTF-16)
+            else (the literal-mode flag is clear)
+                enqueue the character's base-32 quintet
+
+                if the bit queue contains enough bits to represent a
+                    UTF-16 code (which depends on the style indicator)
+                then
+                    dequeue just enough bits to represent one code
+                    output the code
+                endif
+            endif
+        endfor
+
+    At the end the bit queue may contain up to four 0 bits.  If it
+    contains anything else, the input was invalid.
+
+Comparison with RACE
+
+    BRACE is an extension of RACE [RACE01].  For Unicode strings
+    that contain no LDH characters and use the full-row or no-row
+    encoding styles, BRACE is virtually identical to RACE.  For other
+    strings, BRACE produces a smaller encoding than RACE.  For example,
+    the encoding is substantially more compact for Unicode strings
+    containing a substantial number of LDH characters, or containing
+    many Japanese kana with some kanji.
+
+    Unlike RACE, any LDH characters present in the Unicode string are
+    represented literally in the BRACE-encoded string.  This may or may
+    not be useful, but it happens to be the most compact way to encode
+    LDH characters.
+
+    Whereas RACE uses a signature prefix, BRACE uses a signature suffix.
+    This makes it easy to guarantee that the encoded label never ends
+    with a hyphen, even if the original UTF-16 string does.  (Whether
+    such a UTF-16 string should be allowed is a matter of policy, not
+    technical capability).
+
+    The main drawback of BRACE is its greater complexity.
+
+Example strings
+
+    All of these examples use Japanese text, merely because that is the
+    only kind of non-English text that the author has lying around.
+
+    Example of no-row style:
+
+        An actual music group name coerced into the usual format for
+        host name labels:
+
+            AMURONAMIE-with-super-monkeys
+
+        AMURONAMIE stands for five kanji whose Unicode values are (in
+        order):
+
+            U+5B89 U+5BA4 U+5948 U+7F8E U+6075
+
+        The BRACE encoding is:
+
+            UVJ7FUAQCAHY982XA---with--super--monkeys-8Q9
+
+        (Note that the RACE encoding would have been 79 characters long,
+        and hence unusable.)
+
+    Example of mixed style:
+
+        An actual song title coerced into the usual format for host name
+        labels:
+
+            hello-another-way-SOREZORENOBASHO
+
+        SOREZORENOBASHO stands for five hiragana followed by two kanji,
+        whose Unicode values are (in order):
+
+            U+305D U+308C U+305E U+308C U+306E U+5834 U+6240
+
+        The BRACE encoding is:
+
+            JI7-hello--another--way---V3JHAEFVD2UFJ62-8Q9
+
+    Example of full-row style:
+
+        An actual song title, SONOSUPIIDODE, which stands for two
+        hiragana followed by four katakana followed by one hiragana,
+        whose Unicode values are:
+
+            U+305D U+306E U+30B9 U+30D4 U+30FC U+30C9 U+3067
+
+        The BRACE encoding is:
+
+            BIDPRDMP9WT7MI-8Q9
+
+    Example of half-row style:
+
+        An actual song title:
+
+            PAFIIdeRUNBA
+
+        PAFII stands for four katakana whose Unicode values are:
+
+            U+30D1 U+30D5 U+30A3 U+30FC
+
+        RUNBA stands for three katakana whose Unicode values are:
+
+            U+30EB U+30F3 U+30D0
+
+        The BRACE encoding is:
+
+            3IU8PAZT-de-PYGI-8Q9
+
+    Example of an ASCII string that breaks all the rules of host name
+    labels:
+
+        -> $1.00 <-
+
+    The BRACE encoding is:
+
+        229--T2B4-1-W-00-I9I---8Q9
+
+Security considerations
+
+    Users expect each host name in DNS to be controlled by a single
+    authority.  If a UTF-16 string could map to multiple labels, then
+    a UTF-16 host name could map to multiple real host names, each
+    controlled by a different authority, some of which could be spoofs
+    that hijack service requests intended for another.  Therefore BRACE
+    is designed so that each UTF-16 string maps to a unique label.
+
+    However, there can still be multiple UTF-16 representations
+    of the "same" text, for various definitions of "same".  This
+    problem is addressed by the Unicode standard under the topic of
+    canonicalization, but the issue needs to be studied further in the
+    context of host names.
+
+    Also, some text strings may be misleading or ambiguous to humans,
+    such as strings containing dots, slashes, at-signs, etc.  Policies
+    for allowable Unicode strings need to be developed.
+
+References
+
+    [IDN] Internationalized Domain Names (IETF working group),
+    http://www.i-d-n.net/, idn@ops.ietf.org.
+
+    [RACE01] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
+    for IDN", 2000-Aug-31, draft-ietf-idn-race-01.
+
+    [RFC952] K. Harrenstien, M. Stahl, E. Feinler, "DOD Internet Host
+    Table Specification", 1985-Oct, RFC 952.
+
+    [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
+    1987-Nov, RFC 1034.
+
+    [RFC1123] Internet Engineering Task Force, R. Braden (editor),
+    "Requirements for Internet Hosts -- Application and Support",
+    1989-Oct, RFC 1123.
+
+    [SACE] Dan Oscarsson, "Simple ASCII Compatible Encoding (SACE)",
+    draft-ietf-idn-sace.
+
+    [UNICODE] The Unicode Consortium, "The Unicode Standard",
+    http://www.unicode.org/unicode/standard/standard.html.
+
+    [UTF5] James Seng, Martin Duerst, Tin Wee Tan, "UTF-5, a
+    Transformation Format of Unicode and ISO 10646", draft-jseng-utf5.
+
+Author
+
+    Adam M. Costello <amc@cs.berkeley.edu>
+    http://www.cs.berkeley.edu/~amc/
+
+
+Example implementation
+
+
+/* brace.c 0.1.1 (2000-Sep-09-Sat)        */
+/* Adam M. Costello <amc@cs.berkeley.edu> */
+
+/* This is ANSI C code implementing BRACE version 0.1.*. */
+
+/* Public interface (would normally go in its own .h file): */
+
+enum {
+  brace_encoder_in_max = 63,
+  brace_encoder_out_max = 4 + (6 + 16 * brace_encoder_in_max) / 5 + 1,
+  brace_decoder_in_max = 63 + 1,
+  brace_decoder_out_max = brace_decoder_in_max - 1
+};
+
+    /* The above constants are the maximum array sizes */
+    /* that the encoder/decoder will accept/produce    */
+    /* (including null terminators for ASCII strings). */
+
+void brace_encode(
+  unsigned int input_length,
+  unsigned short *input,
+  char output[brace_encoder_out_max] );
+
+    /* brace_encode() converts UTF-16 input to null-terminated */
+    /* BRACE-encoded ASCII output.  The input_length must not  */
+    /* exceed brace_encoder_in_max, and the output array must  */
+    /* have at least the size indicated below.  Under those    */
+    /* constraints, this function never fails.                 */
+
+int brace_decode(
+  char *input,
+  unsigned int *output_length,
+  unsigned short output[brace_decoder_out_max] );
+
+    /* brace_decode() converts null-terminated BRACE-encoded ASCII   */
+    /* input to UTF-16 output.  The input length (including the null */
+    /* terminator) must not exceed brace_encoder_in_max, and output  */
+    /* array must have at least the size indicated below.  Returns 1 */
+    /* on success, 0 if the input was malformed.  If 0 is returned   */
+    /* the output array may contain garbage, but *output_length will */
+    /* not have been affected.                                       */
+
+
+/* Implementation (would normally go in its own .c file): */
+
+#include <assert.h>
+
+static const char base32[] = {
+  50, 51, 52, 53, 54, 55, 56, 57, 65, 66, 67, 68, 69, 70, 71, 72,
+  73, 74, 75, 77, 78, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90
+};
+
+/* We can't use string literals for ASCII characters because */
+/* an ANSI C compiler does not necessarily use ASCII.        */
+
+enum encoding_style {
+  half_row_style = 0,
+  full_row_style = 1,
+  mixed_style    = 2,
+  no_row_style   = 3
+};
+
+/* is_ldh(code) returns 1 if the UTF-16 code represents an LDH */
+/* character (ASCII letter, digit, or hyphen), 0 otherwise.    */
+
+static int is_ldh(unsigned short code)
+{
+  if (code ==  45) return 1;
+  if (code <   48) return 0;
+  if (code <=  57) return 1;
+  if (code <   65) return 0;
+  if (code <=  90) return 1;
+  if (code <   97) return 0;
+  if (code <= 122) return 1;
+  return 0;
+}
+
+void brace_encode(
+  unsigned int input_length,
+  unsigned short *input,
+  char output[brace_encoder_out_max] )
+{
+  unsigned long queue;
+  enum encoding_style style;
+  unsigned short half_rows[brace_encoder_in_max],
+                 half_row_counts[brace_encoder_in_max];
+  unsigned int num_nonldh, num_half_rows, i, half_row, j, queue_length,
+               best_half_row, next_literal_position, non_hyphen_flag,
+               next_base32_position, code;
+
+  assert(input_length <= brace_encoder_in_max);
+
+  /* Count the non-LDH codes and half-rows: */
+
+  num_nonldh = 0;
+  num_half_rows = 0;
+
+  for (i = 0;  i < input_length;  ++i) {
+    if (is_ldh(input[i])) continue;
+    ++num_nonldh;
+    half_row = input[i] >> 7;
+
+    for (j = 0;  j < num_half_rows;  ++j) {
+      if (half_rows[j] == half_row) {
+        ++half_row_counts[j];
+        break;
+      }
+    }
+
+    if (j == num_half_rows) {
+      half_rows[num_half_rows] = half_row;
+      half_row_counts[num_half_rows] = 1;
+      ++num_half_rows;
+    }
+  }
+
+  /* If the input is already a valid label and does not end */
+  /* with the BRACE signature, output it and we're done:    */
+
+  if (num_nonldh == 0 &&                     /* all codes are LDH and */
+      input[0] != 45 &&                      /* first not hyphen and  */
+      input[input_length - 1] != 45 &&       /* last not hyphen and   */
+      !( input[input_length - 1] == 57 &&    /* last four not -8Q9    */
+         ( input[input_length - 2] == 81 ||
+           input[input_length - 2] == 113  ) &&   /* (or -8q9) */
+         input[input_length - 3] == 56 &&
+         input[input_length - 4] == 45 ) ) {
+    for (i = 0;  i < input_length;  ++i) output[i] = input[i];
+    output[input_length] = 0;  /* null terminator */
+    return;
+  }
+
+  /* Choose an encoding style and initialize the bit queue: */
+
+  if (num_half_rows == 1) {
+    style = half_row_style;
+    queue_length = 11;
+    queue = half_rows[0];
+  }
+  else if ( num_half_rows == 2 &&
+            (half_rows[0] >> 1) == (half_rows[1] >> 1) ) {
+    style = full_row_style;
+    queue_length = 10;
+    queue = (1 << 8) | (half_rows[0] >> 1);
+  }
+  else {
+    unsigned int M, H, C, Mprime, best_M = 230;  /* M is always < 230 */
+
+    /* Find the best half-row for mixed style: */
+
+    best_half_row = 512;  /* half_row is always < 512 */
+
+    for (i = 0;  i < num_half_rows;  ++i) {
+      half_row = half_rows[i];
+      H = half_row_counts[i];
+      C = 0;
+
+      for (j = 0;  j < num_half_rows;  ++j) {
+        if (j != i && (half_rows[j] >> 1) == (half_row >> 1)) {
+          C = half_row_counts[j];
+          break;
+        }
+      }
+
+      M = 3 + (18 * num_nonldh - 10*H - 9*C) / 5;
+
+      if (M < best_M || (M == best_M && half_row < best_half_row)) {
+        best_M = M;
+        best_half_row = half_row;
+      }
+    }
+
+    /* Compare mixed style to no-row style: */
+
+    Mprime = (6 + 16 * num_nonldh) / 5;
+
+    if (Mprime <= best_M) {
+      style = no_row_style;
+      queue_length = 2;
+      queue = 3;
+    }
+    else {
+      style = mixed_style;
+      queue_length = 11;
+      queue = (1 << 10) | best_half_row;
+    }
+  }
+
+  /* Flush the bit queue: */
+
+  next_base32_position = 0;
+
+  while (queue_length >= 5) {
+    queue_length -= 5;
+    output[next_base32_position++] =
+      base32[(queue >> queue_length) & 0x1f];
+  }
+
+  /* To avoid unnecessary copies, we use the output       */
+  /* array itself for the LDH buffer.  The following      */
+  /* equalities should hold whenever the buffer is empty: */
+
+  next_literal_position = next_base32_position + (queue_length > 0);
+  non_hyphen_flag = 0;  /* set whenever buffer contains a non-hyphen */
+
+  /* Main encoding loop: */
+
+  for (i = 0;  i < input_length;  ++i) {
+    code = input[i];
+
+    if (code == 45) {
+      /* Encode a hyphen as two hyphens into the buffer: */
+      output[next_literal_position++] = 45;
+      output[next_literal_position++] = 45;
+    }
+    else if (is_ldh(code)) {
+      if (!non_hyphen_flag) {
+        /* Indicate a change to literal mode: */
+        output[next_literal_position++] = 45;
+        non_hyphen_flag = 1;
+      }
+
+      /* Encode the LDH character literally: */
+      output[next_literal_position++] = code;
+    }
+    else { /* non-LDH code */
+      if (non_hyphen_flag) {
+        /* Indicate a change to base-32 mode: */
+        output[next_literal_position++] = 45;
+        non_hyphen_flag = 0;  /* we will empty the buffer */
+      }
+
+      /* If the bit queue is empty, flush the LDH buffer: */
+
+      if (queue_length == 0) {
+        next_base32_position = next_literal_position;
+      }
+
+      /* Enqueue the bit string corresponding to the code: */
+
+      if (style == half_row_style) {
+        queue = (queue << 7) | (code & 0x7f);
+        queue_length += 7;
+      }
+      else if (style == full_row_style) {
+        queue = (queue << 8) | (code & 0xff);
+        queue_length += 8;
+      }
+      else if (style == no_row_style) {
+        queue = (queue << 16) | code;
+        queue_length += 16;
+      }
+      else /* style == mixed_style */ {
+        if ((code >> 7) == best_half_row) {
+          queue = (queue << 8) | (code & 0x7f);
+          queue_length += 8;
+        }
+        else if ((code >> 8) == (best_half_row >> 1)) {
+          queue = (queue << 9) | (1 << 8) | (code & 0x7f);
+          queue_length += 9;
+        }
+        else {
+          queue = (queue << 18) | (3ul << 16) | code;
+          queue_length += 18;
+        }
+      }
+
+      /* Output one base-32 character: */
+      queue_length -= 5;
+      output[next_base32_position] =
+        base32[(queue >> queue_length) & 0x1f];
+
+      if (next_base32_position == next_literal_position) {
+        /* LDH buffer is already empty. */
+        ++next_base32_position;
+      }
+      else {
+        /* Flush the LDH buffer: */
+        next_base32_position = next_literal_position;
+      }
+
+      /* next_literal_position is momentarily invalid, */
+      /* but we know the LDH buffer is empty.          */
+
+      /* Flush the bit queue: */
+
+      while (queue_length >= 5) {
+        queue_length -= 5;
+        output[next_base32_position++] =
+          base32[(queue >> queue_length) & 0x1f];
+      }
+
+      /* Fix next_literal_position: */
+      next_literal_position = next_base32_position + (queue_length > 0);
+    }
+
+    assert(next_literal_position < brace_encoder_out_max);
+  }
+
+  /* Flush the bit queue: */
+
+  if (queue_length > 0) {
+    assert(queue_length < 5);
+    output[next_base32_position] =
+      base32[(queue << (5 - queue_length)) & 0x1f];
+  }
+
+  /* Flushing the LDH buffer at this point is a no-op. */
+
+  /* Output "-8Q9" and the null terminator: */
+
+  assert(next_literal_position + 4 < brace_encoder_out_max);
+  output[next_literal_position++] = 45;
+  output[next_literal_position++] = 56;
+  output[next_literal_position++] = 81;
+  output[next_literal_position++] = 57;
+  output[next_literal_position] = 0;
+}
+
+/* base32_decode() converts a base-32 character to a value from  */
+/* 0 to 31.  If the character is valid, its value is written to  */
+/* *quintet and 1 is returned.  Otherwise, *value is not changed */
+/* and 0 is returned.                                            */
+
+static int base32_decode(char c, unsigned int *quintet)
+{
+  if (c <  50) return 0;
+  if (c <= 57) { *quintet = c - 50; return 1; }
+  if (c <  65) return 0;
+  if (c >= 97) c -= 32;
+  if (c <= 75) { *quintet = c - 57; return 1; }
+  if (c == 76) return 0;
+  if (c <= 78) { *quintet = c - 58; return 1; }
+  if (c == 79) return 0;
+  if (c <= 90) { *quintet = c - 59; return 1; }
+  return 0;
+}
+
+int brace_decode(
+  char *input,
+  unsigned int *output_length,
+  unsigned short output[brace_decoder_out_max] )
+{
+  unsigned long queue;
+  unsigned int i, input_length, queue_length, literal_mode_flag,
+               quintet, n, next_code_position;
+  enum encoding_style style;
+  unsigned short common_prefix;
+  char c;
+
+  /* Check whether input ends with "-8Q9": */
+
+  for (i = 0;  input[i];  ++i) assert(i < brace_decoder_in_max);
+
+  if (!(input[i-1] == 57 && input[i-3] == 56 &&
+        input[i-4] == 45 && (input[i-2] == 81 || input[i-2] == 113))) {
+
+    /* Copy input to output and we're done: */
+
+    for (i = 0;  input[i];  ++i) output[i] = input[i];
+    assert(i <= brace_decoder_out_max);
+    *output_length = i;
+    return 1;
+  }
+
+  /* Initialize using the first base-32 character: */
+
+  input_length = i;
+  i = 0;
+  if (!base32_decode(input[i], &quintet)) return 0;
+  queue = quintet;
+  queue_length = 3;
+  literal_mode_flag = 0;
+  style = quintet >> 3;
+
+  /* Determine common_prefix: */
+
+  if (style == no_row_style) n = 0;
+  else if (style == full_row_style) n = 8;
+  else n = 9;
+
+  while (queue_length < n) {
+    if (!base32_decode(input[++i], &quintet)) return 0;
+    queue = (queue << 5) | quintet;
+    queue_length += 5;
+  }
+
+  common_prefix = (queue >> (queue_length - n)) << (16 - n);
+  queue_length -= n;
+
+  /* Main decoding loop: */
+
+  next_code_position = 0;
+
+  while (++i < input_length - 4) {
+    c = input[i];
+
+    if (c == 45) {
+      if (input[i+1] == 45) {
+        ++i;
+        output[next_code_position++] = 45;  /* "--" means "-" */
+      }
+      else literal_mode_flag ^= 1;  /* "-" toggles literal mode */
+    }
+    else if (literal_mode_flag) { /* literal non-hyphen */
+      output[next_code_position++] = c;
+    }
+    else { /* base-32 character */
+      /* Enqueue the corresponding quintet: */
+      if (!base32_decode(c, &quintet)) return 0;
+      queue = (queue << 5) | quintet;
+      queue_length += 5;
+
+      /* If the queue contains enough bits for a UTF-16 code, */
+      /* dequeue them, decode them, and output the code:      */
+
+      if (style == no_row_style && queue_length >= 16) {
+        output[next_code_position++] =
+          (queue >> (queue_length - 16)) & 0xffff;
+        queue_length -= 16;
+      }
+      else if (style == full_row_style && queue_length >= 8) {
+        output[next_code_position++] =
+          common_prefix | ((queue >> (queue_length - 8)) & 0xff);
+        queue_length -= 8;
+      }
+      else if (style == half_row_style && queue_length >= 7) {
+        output[next_code_position++] =
+          common_prefix | ((queue >> (queue_length - 7)) & 0x7f);
+        queue_length -= 7;
+      }
+      else if (style == mixed_style) {
+        n = (queue >> (queue_length - 2)) & 3;  /* top 2 bits */
+
+        if (n <= 1 && queue_length >= 8) {
+          output[next_code_position++] =
+            common_prefix | ((queue >> (queue_length - 8)) & 0x7f);
+          queue_length -= 8;
+        }
+        else if (n == 2  && queue_length >= 9) {
+          output[next_code_position++] = (common_prefix ^ 0x80) |
+            ((queue >> (queue_length - 9)) & 0x7f);
+          queue_length -= 9;
+        }
+        else if (n == 3 && queue_length >= 18) {
+          output[next_code_position++] =
+            (queue >> (queue_length - 18)) & 0xffff;
+          queue_length -= 18;
+        }
+      }
+    }
+  }
+
+  assert(next_code_position <= brace_decoder_out_max);
+
+  /* Check that the bit queue contains only zeros, at most four: */
+
+  if (queue_length > 4) return 0;
+  if ((queue & ((1 << queue_length) - 1)) != 0) return 0;
+
+  /* Set the output length and we're done: */
+
+  *output_length = next_code_position;
+  return 1;
+}
+
+
+/* Wrapper for testing (would normally go in a separate .c file): */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+static void usage(char **argv)
+{
+  fprintf(stderr,
+    "%s -e reads big-endian UTF-16 and writes BRACE-format ASCII.\n"
+    "%s -d reads BRACE-format ASCII and writes big-endian UTF-16.\n"
+    , argv[0], argv[0]);
+  exit(EXIT_FAILURE);
+}
+
+static void fail(const char *msg)
+{
+  fputs(msg,stderr);
+  exit(EXIT_FAILURE);
+}
+
+static const char input_too_large[] = "input is too large\n";
+
+int main(int argc, char **argv)
+{
+  unsigned int input_length;
+
+  if (argc != 2) usage(argv);
+  if (argv[1][0] != '-') usage(argv);
+  if (argv[1][2] != '\0') usage(argv);
+
+  if (argv[1][1] == 'e') {
+    unsigned short input[brace_encoder_in_max];
+    char output[brace_encoder_out_max];
+    int hi, lo;
+
+    /* Read the UTF-16 input string: */
+
+    input_length = 0;
+
+    for (;;) {
+      hi = getchar();
+      lo = getchar();
+
+      if (lo == EOF) {
+        if (hi != EOF) fail("input contained an odd number of bytes\n");
+        break;
+      }
+
+      if (input_length == brace_encoder_in_max) fail(input_too_large);
+
+      if (hi > 0xff || lo > 0xff) {
+        fail("input bytes do not fit in 8 bits\n");
+      }
+
+      input[input_length++] =
+        (unsigned short) hi << 8 | (unsigned short) lo;
+    }
+
+    /* Encode, and output the result: */
+
+    brace_encode(input_length, input, output);
+    if (strlen(output) > brace_decoder_in_max) fail(input_too_large);
+    fputs(output,stdout);
+    return EXIT_SUCCESS;
+  }
+
+  if (argv[1][1] == 'd') {
+    char input[brace_decoder_in_max];
+    unsigned short output[brace_decoder_out_max];
+    unsigned int output_length, i;
+    size_t n;
+
+    /* Read the BRACE-encoded ASCII input string: */
+
+    n = fread(input, 1, brace_decoder_in_max, stdin);
+    if (n == brace_decoder_in_max) fail(input_too_large);
+    input[n] = 0;
+
+    /* Decode, and output the result: */
+
+    if (!brace_decode(input, &output_length, output)) {
+      fail("input was malformed\n");
+    }
+
+    for (i = 0;  i < output_length;  ++i) {
+      putchar(output[i] >> 8);
+      putchar(output[i] & 0xff);
+    }
+
+    return EXIT_SUCCESS;
+  }
+
+  usage(argv);
+  return EXIT_SUCCESS;  /* not reached, but quiets compiler warning */
+}
+
+
+
+                   INTERNET-DRAFT expires 2001-Mar-14
diff --git a/doc/draft/draft-ietf-idn-cjk-00.txt b/doc/draft/draft-ietf-idn-cjk-00.txt
new file mode 100644
index 00000000..d979e3d8
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-cjk-00.txt
@@ -0,0 +1,530 @@
+Internet Draft                                                James SENG
+<draft-ietf-idn-cjk-00.txt>                               Yoshiro YONEYA
+12th Sep 2000                                                Kenny HUANG
+Expires 12 Mar 2001                                         KIM Kyongsok
+
+        Han Ideograph (CJK) for Internationalized Domain Names
+
+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
+
+During the development of Internationalized Domain Name (IDN), it is
+discovered that there is a substantial lack of information and
+misunderstanding on Han ideographs and its folding mechanism.
+
+This document attempts to address some of the issues on doing han
+folding with respect to IDN. Hopefully, this will dispel some of the
+common misunderstanding of this problem and to discuss some of the
+issues with han ideograph and its folding mechanism.
+
+This document addresses very specific problem to IDN and thus is not
+meant as a reference for generic Han folding. Generic Han folding are
+much more complicated and certainly beyond this document. However, the
+use of this document may be applicable to other areas that are related
+with names, e.g. Common Name Resolution Protocol [CNRP].
+
+1. Definition and convention
+
+Characters mentioned in this document are identified by their position
+or code point in the Unicode character set [UCS]. The notation U+12AB,
+for example, indicates the character at the position 12AB (hexadecimal)
+in the [UCS]. It is strongly recommended that a [UCS] table is available
+for reference for the ideograph described.
+
+Han ideographs are defined as the Chinese ideographs starting from
+U+3400 to U+9FFF or commonly known as CJK Unification Ideographs. This
+
+                    Expires 12th March 2001 [Page  1]
+
+Internet Draft         Han Ideograph (CJK) for IDN         12th Mar 2001
+
+covers Chinese 'hanzi' {U+6F22 U+5B57/U+6C49 U+5B57}, Japanese 'kanji'
+(U+6F22 U+5B57) and Korean 'hanja' {U+6F22 U+5B57/U+D55C U+C790}.
+Additional Han ideographs will appear in other location (not necessary
+in plane 0) in the future.
+
+Conversion between ideographs can be done using four different
+approaches: Code-base substitution, character-based substitution,
+lexicon-based substitution and context-based substitution. Han folding
+refers only to code-base substitution, similar to case mapping of
+alphabetic characters.
+
+2. Introduction
+
+Traditionally, domain names have been case insensitive (as defined in
+[RFC1035] Section 2.3.3). While this is not a problem when domain names
+are restricted to English alphanumeric letters and digits, it becomes a
+serious problem for IDN. An important criterion for having a robust IDN
+is to have good normalization and canonicalization forms. This is to
+ensure domain name duplications are kept to the minimal.
+
+Fortunately, Unicode Consortium is developing technical reports on
+canonicalization [UTR21] and normalization [UTR15]. Hence, it becomes
+simple for IDN to ride upon the work of Unicode and use these
+references.
+
+Unfortunately, both [UTR15] and [UTR21] are limited in scope and do not
+address many other scripts. In particular, Han ideographs are not
+discussed in detail in these documents and most experts are quick to
+point out that this problem is technically impossible.
+
+2.1 Han ideographs
+
+While there are many forms or writing style for Chinese characters, the
+most common used 'zhengti' {U+6B63 U+4F53/U+6B63 U+9AD4} represent
+Chinese ideographs by radicals (U+2E80-U+2FDF) that is composed of
+simple strokes.
+
+When the Unicode Consortium started work on Universal Character Set, it
+was suggested that Hanzi, Kanji and Hanja ideographs should be unified
+into a single code space. This resulted in the CJK Unification, whereby
+27,786 Han ideographs are allocated in U+3400-U+9FFF and U+F900-U+FAFF
+range. Another 41,000 Han ideographs will be added to Plane 2.
+
+Ideographs are common in China, Korea and Japan but as ideographs spread
+and evolve, the form of the ideographs sometimes differs slightly from
+country to country. For example, the word 'villa' {U+838A} 'zhuang' in
+Chinese, in Japanese is 'sou' {U+8358}. These are given different code
+points in Unicode.
+
+3. Chinese (Hanzi)
+
+Chinese ideographs or hanzi {U+6F22 U+5B57/U+6C49 U+5B57} originated
+from pictograph. They are 'pictures' which evolved into ideographs
+during several thousand years. For instance, the ideograph for "hill"
+
+                    Expires 12th March 2001 [Page  2]
+
+Internet Draft         Han Ideograph (CJK) for IDN         12th Mar 2001
+
+{U+5C71} still bears some resembles to 3 peaks of a hill.
+
+Not all ideographs are pictograph. There are other classifications such
+as compound ideographs, phonetic ideographs etc. For example,
+'endurance' {U+5FCD} is a pierced 'knife' {U+5200} above the 'heart'
+{U+5FC3}, or as a Chinese saying goes, 'endurance is like having a
+pierced knife in your heart'.
+
+Hence, almost all Han ideographs are associated with some meaning by
+itself which is very different from most other scripts. This causes some
+confusion that Han folding is a form of lexicon-substitution.
+
+Chinese ideographs underwent a major change in the 1950s after the
+establishment of People's Republic of China. A committee on Language
+Reform was established in China whose activities include simplification
+of Chinese ideographs. The Simplified Chinese (SC) are used in China
+and Singapore and Traditional Chinese (TC) in Taiwan, Hong Kong PRC,
+Macau PRC, and most other oversea Chinese.
+
+The process is to take complex ideographs and simplify them. The main
+purposes is to make it easier to remember and write and thus to raise
+the literacy of the population.
+
+For example, 'lightning' TC {U+96FB} becomes SC {U+6535} (They drop the
+'rain' {U+96E8} part from the TC). In many cases, they bear no
+resemblance to any of the original traditional forms e.g. 'dragon' TC
+{U+9F8D} SC {U+9F99}. Two different TC may also have the same SC since
+it means fewer ideographs to learn, e.g. SC {U+53D1} can be {U+667C} or
+{U+9AEE} depending on semantics. The official 'Comprehensive List of
+Simplified Characters' latest published in 1986 listed 2244 SC
+[ZONGBIAO].
+
+Therefore, the process of SC-to-TC is very complicated. It is not
+possible to do it accurately without considering the semantics of the
+phrase.
+
+On the other hand, TC-to-SC is much simple although different TCs may
+map to one single SC. While Unicode does not handle TC & SC, in the
+informal [UNIHAN] document, it listed 2145 TC and its equivalent mapping
+of SC. However, because that document is informal and not part of the
+Unicode standard, it is incomplete and has mistakes in the code points.
+Hence, precise tables for TC-to-SC conversion have not been fully laid
+out.
+
+In domain names, we are particularly interested in is to equivalences
+comparison of the names, and not converting SC-to-TC. Therefore, for
+this purpose, it is possible that equivalency matching be done in the
+TC-to-SC folding prior to comparison, similar to lower-case English
+strings before comparing them, e.g. 'taiwan' SC {U+53F0 U+6E7E} will
+match with TC {U+81FA U+5F4E} or TC {U+53F0 U+5F4E}.
+
+The side effect of this method is that comparing SC {U+53D1} to TC
+{U+667C} or TC {U+9AEE} will both be positive. This implies that SC
+'hair' SC …ñ³…Åæ {U+5934 U+53D1} will match TC
+
+                    Expires 12th March 2001 [Page  3]
+
+Internet Draft         Han Ideograph (CJK) for IDN         12th Mar 2001
+
+(U+982D U+9AEE). It will also match TC {U+982D U+9AEE} that does not
+have any meaning in Chinese.
+
+It should also be noted that SC are not used together with TC. Hence,
+'hair' is either written as SC {U+5934 U+53D1} or TC {U+982D U+9AEE}
+but (almost) never {U+5934 U+9AEE} or {U+982D U+53D1}. So the problem
+of SC and TC may not too serious for IDN.
+
+Unfortunately, when it comes to names in Chinese, places where SC are
+used (i.e. Singapore and China), traditional and simplified ideographs
+are sometimes mixed within a single name for artistic reasons. Some of
+them even 'create' ideographs for their names.
+
+[Need to add a section on Bopomofo U+3118 to U+312A in future draft]
+
+4. Korean (Hanja and Hangeul)
+
+Korean is one of the first cultures to imported Chinese ideographs into
+Korean language as a written form. These Korean ideographs are known as
+'hanja' {U+6F22 U+5B57/U+D55C U+C790} and they are widely used until
+recently where 'hangeul' {U+D55C U+AE00} become more popular.
+
+Hangeul {U+D55C U+AE00} is a systemic script designed by a 15th century
+ruler and linguistic expert, King Sejong {U+4E16 U+5B97}. It is based
+on the pronunciation of the Korean language, hanmal. A Korean syllable
+is composed of 'jamo' {U+5B57 U+6BCD/U+C790 U+BAA8} elements that
+represent different sound. Hence, unlike Han ideographs, each hangeul
+syllable does not have any meaning.
+
+Each hanja ideographs can be represented by hangeul syllable. For
+example, 'samsung' hanja {U+4E09 U+661F} hangeul {U+C0BC U+C131}. Note
+that {U+4E09} is pronounced as 'sa-ah-am' or in jamo {U+3145} {U+314F}
+{U+3141}, which gives hangeul {U+C0BC}. While Jamo decompositions are
+described in [UTR15] in Form D decomposition, this document also
+suggested another hanguel canonical decomposition in Appendix A to
+accommodates both modern and old hangeul.
+[Need to fill up Appendix A when information is more complete]
+
+Most hanja characters have only one pronunciation. However, some hanja
+pronunciation differs as according to orthography (same for Chinese &
+Japanese) or the position in a word, which make this more complex. And
+of course, conversation of Hangeul back to hanja is impossible by code
+substitution without consideration for semantics.
+
+Korean also invented their own ideographs that are called 'gugja'
+{U+56FD U+5B57/U+AD6D U+C790}.
+
+5. Japanese (Kanji, Hiragana, Katakana)
+
+Japanese adopted Chinese ideograph from the Korean and the Chinese since
+the 5th century. Chinese ideographs in Japanese are known as 'kanji'
+{U+6F22 U+5B57}. They also developed their own syllabary hiragana
+{U+5E73 U+4EEE U+540D} (U+3040-U+309F) and katakana {U+7247 U+4EEE
+U+540D} (U+30A0-U+30FF), both are derivative of kanji that has same
+
+                    Expires 12th March 2001 [Page  4]
+
+Internet Draft         Han Ideograph (CJK) for IDN         12th Mar 2001
+
+pronunciation. Hiragana is a simplified cursive form, for example, 'a'
+{U+3042} was derived from 'an' {U+5B89}. Katakana is a simplified part
+form, for example, 'a' {U+30A2} was derived from 'a' {U+963F}. However,
+kanji all remain very integrated within the Japanese language.
+
+Japanese also invented ideographs known as 'kokuji' {U+56FD U+5B57}. For
+example, 'iwashi' {U+9C2F} is a Japanese kokuji ideograph. Kokuji are
+invented according to Han ligature rules. For example, 'touge' "mountain
+pass" {U+5CE0} is a conjunction of meaning with 'yama' "mountain"
+{U+5C71} + 'ue' "up" {U+4E0A} + 'shita' "down" {U+4E0B}.
+
+Japanese is also a vocal language, i.e. the script itself is based on
+pronunciation. Each hiragana corresponding to one pronunciation and 48
+hiragana forms the basic of the Japanese language, including the less
+commonly used 'we' {U+3091}. Furthermore, hiragana has more 35 forms to
+represent voiced sound, P-sound, double consonant. For example, 'ga'
+{U+304C} is a voiced sound of 'ka' {U+304B}. Katakana is a mirror of
+hiragana with few more forms and they are used to integrate foreign
+words or phrases into Japanese, or to emphasize words or phrases even
+in Japanese, or to represent onomatopoeia. For example, 'hamburger'
+pronounced as 'han-baa-gaa' in Japanese is written as {U+30CF U+30F3
+U+30D0 U+30FC U+30AC U+30FC} instead of {U+306F U+3093 U+3070 U+3041
+U+304C U+3041} because it is a foreign word.
+
+If Japanese uses hiragana and katakana only, then it is fairly obvious
+that written Japanese is going to be very long. Hence, kanji are used
+when referring to nouns or verbs. Each kanji corresponds to one or more
+hiragana characters. For example, 'japan' pronounced as 'nippon'
+{U+306B U+3063 U+307D U+3093} are written as {U+65E5 U+672C} instead.
+
+Hiragana, like Korean jamo, has no meaning itself. And also, Kanji can
+take on different pronunciation (which means different hiragana)
+depending where and how it is use in the sentence. For example, 'sky'
+{U+7A7A} can be pronounced as {U+305D U+3089} or {U+30BD U+30E9}.
+
+Hence, a code substitution between hiragana and kanji is impractical.
+
+On the other hand, there are Kanji that has the same meaning with the
+same pronunciation and equivalent. For example, 'river' "kawa" can be
+either {U+5DDD} or {U+6CB3}. The only differential between the two
+ideographs is that it signifies the 'size of the river' (the latter is
+bigger river).
+
+Japanese also reduce complex Chinese ideographs to a simplified form.
+For example, 'both' {U+5169} was simplified {U+4E21}. Note that Chinese
+simplified it to {U+4E24} instead. However, traditional Japanese kanji
+are seldom used nowadays beyond documenting old historical text that
+they are treated different from the more commonly used simplified form,
+or used to express proper noun such as person's name or trademarks.
+Hence, Han folding here is not recommended.
+
+4. Vietnamese
+
+While Vietnamese also adopted Chinese ideographs ('chu han') and created
+
+                    Expires 12th March 2001 [Page  5]
+
+Internet Draft         Han Ideograph (CJK) for IDN         12th Mar 2001
+
+their own ideographs ('chu nom'), they were now replaced by romanized
+'quoc ngu' today. Hence, this document does not attempt to address any
+issues with 'chu han' or 'chu nom'.
+
+
+5. zVariant
+
+Unicode has a three dimension conceptual model to Ideograph
+Unification. The three dimensions are semantic (X axis - meaning,
+function), abstract shape (Y-axis - general form) and actual shape
+(Z-axis ‚Çô instantiated, type-faced).
+
+When two ideographs have similar etymology but are given two different
+code points in Unicode, they are known as zVariant ideograph i.e. they
+belong to the same 'Z' axis. For example, 'villa' {U+838A} and {U+8358}.
+
+
+6. Ideographic Description
+
+In Unicode v3.0, an ideographic description (U+2FF0-U+2FFB) was
+introduced allowing Han ideograph to be constructed using radical
+(U+2E80-U+2FD5) and Han ideograph (U+3400-U+9FFF).
+
+The intention of this description method is to allow ideograph that is
+not defined by Unicode to be described. Hence, it is not necessary that
+these ideograph can be display properly. In addition, this method are
+not deterministic and allowing same ideograph to be represented in
+different sequence.
+
+For example, 'zong' {U+9B03} (for discussion sake, we are going to use
+an ideograph which is already in Unicode) can be decomposed to U+2FF1
+U+9ADF U+5B97 using descriptive code points and Unified Ideograph.
+U+9ADF can also be decomposed as U+2FF0 U+2ED2 U+2F3A and U+5B97 as
+U+2FF5 U+2F28 U+2F70. In addition, U+9ADF is equivalent to U+2FBD.
+Hence, if we were to use only descriptive code points and radicals only,
+we can get U+2FF1 U+2FBD U+2FF5 U+2F28 U+2F70 or U+2FF1 U+2FF0 U+2ED2
+U+2F3A U+2FF5 U+2F28 U+2F70.
+
+In addition, certain radical has been simplified and thus, in some
+context, equivalent. For example, the radical for 'bird' can be either
+U+2EE6 or U+2FC3.
+
+Hence, until there is a deterministic well-defined rule for
+ideographic description, ideographs formed by this method are not
+recommended for domain names use.
+
+It should be noted that the Unicode Consortium never intended the
+ideographic description to be used in protocols like IDN where exact
+comparison must be done. But it is certainly desirable to this feature
+as it is commons for Chinese to invent ideographs for names by adding
+or removing radical from standard ideographs.
+
+7. Mechanism
+
+
+                    Expires 12th March 2001 [Page  6]
+
+Internet Draft         Han Ideograph (CJK) for IDN         12th Mar 2001
+
+The implicit proposal in this document is that CJKV ideographs may or
+may not be "folded" for the purposes of comparison of domain names.
+
+But if folding is required, there are four different ways that this
+folding could be done.
+
+a) Folding by DNS clients, or by user agents
+b) Folding by DNS servers
+c) Folding by Domain Name registration services for the purposes of
+   preventing confusing allocations CJKV Domain Names which would,
+   if transcoded, be the same
+
+Before we can give much more reaction, we need to know which use is
+planned.
+
+The third use is important.  It should be put in place. This problem can
+be reduced alternately by representing non-ASCII characters that are
+domain names or other URL characters using hex-escaped character
+references in HTML pages.
+
+To characterize Han characters as ideographs or pictograms is
+inadequate, because most of the Han ideograph have both a phonetic and
+a semantic element. Indeed, this is enough to characterize Chinese
+writing as phonetic, though it is other things as well. Thus, it's
+difficult to comment on whether folding is useful for Chinese or not.
+
+The first use has the problem that lightweight devices do not have
+enough room to fit a Unicode X-axis mapping table.
+
+The second use has the problem that introducing mapping will limit the
+performance of DNS servers.  Alphabetic case mapping can be performed
+using a single logical AND instruction; CJKV character folding requires
+a lookup table.
+
+In alphabetic scripts, there is also requirement to fold Latin, Greek,
+Hebrew, Cyrillic, Hebrew and Arabic together. There may be a stronger
+requirement for CJKV characters.
+
+Note also that because modern OS are Unicode based and have network-
+downloadable IMEs, "interoperability" is becoming less equivalent to
+"use BIG5 characters only" or "use GB2312 character only" or "use
+Shift-JIS characters only".
+
+If conservative safety is really required, then
+1) find the x-axis characters which are available in all major CJK
+   character sets used on the internet;
+2) only allow variants of those in domain names;
+3) when one variant is used, no other can be allocated.  So comparisons
+   are made on x-axis characters, but the license of that domain name
+   can pick which y or z variants they wish to use..
+
+
+
+
+
+                    Expires 12th March 2001 [Page  7]
+
+Internet Draft         Han Ideograph (CJK) for IDN         12th Mar 2001
+
+Acknowledgement
+
+The editor gratefully acknowledge the contributions of:
+
+Paul Hoffman <phoffman@imc.org>
+Jiang Mingliang <jiang@i-DNS.net>
+Dongman Lee <dlee@icu.ac.kr>
+Karlsson Kent <keka@im.se>
+
+Author(s)
+
+James SENG 
+i-DNS.net International Pte Ltd.
+8 Temasek Boulevard
+Suntec Tower 3 #24-02
+Singapore 038988
+Email: James@Seng.cc
+Tel: +65 2468208
+
+Yoshiro YONEYA
+NTT Software Corporation
+Shinagawa IntercityBldg., B-13F
+2-15-2 Kohnan, Minato-ku Tokyo 108-6113 Japan
+Email: yone@po.ntts.co.jp
+Tel: +81-3-5782-7291
+
+Kenny HUANG 
+Geotempo International Ltd; TWNIC
+3F, No 16 Kang Hwa Street, Nei Hu
+Taipei 114, Taiwan
+Email: huangk@alum.sinica.edu
+Tel: +886-2-2658-6510
+
+KIM Kyongsok/GIM Gyeongseog
+
+References
+
+[UNISTD3]   The Unicode Standard v3.0. Unicode Consortium.
+[UCS]       ISBN 0-201-61633-5
+
+[IDN]       "IETF Internationalized Domain Names Working Group",
+            idn@ops.ietf.org, James Seng, Marc Blanchet
+
+[CNRP]      "Common Name Resolution Protocol",
+            cnrp-ietf@lists.netsol.com, Leslie Daigle
+
+[CJKV]      CJKV Information Processing ISBN 1-56592-224-7
+
+[C2C]       The pitfalls and Complexities of Chinese to Chinese
+            Conversion. http://www.basistech.com/articles/C2C.html,
+            Jack Halpern, Jouni Kerman
+
+[KANJIDIC]  Sanseido‚ÇÖs Unicode Kanji Information Dictionary
+            ISBN 4-385-13690-4
+
+                    Expires 12th March 2001 [Page  8]
+
+Internet Draft         Han Ideograph (CJK) for IDN         12th Mar 2001
+
+
+[UNICHART]  Unicode chart http://charts.unicode.org/
+
+[ZONGBIAO]  Simplified Characters Standard Chart 2nd Edition, 1986
+
+[UNIHAN]    Unicode Han Database, Unicode Consortium
+            ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt
+
+[ISO11941]  ISO TS 11941: Information and documentation ‚Çô
+            Transliteration of Korean script into Latin characters.
+            Technical Specification 11941. First edition. 1996-12-31.
+            ISO (International Organization for Standardization).
+
+[KimK 1990] "A New Proposal for a Standard Hangeul (or Korean Script)
+            Code", KIM Kyongsok.  Computer Standards & Interfaces,
+            Vol. 9, No. 3, pp. 187-202, 1990.
+
+[KimK 1992] "A common Approach to Designing the Hangeul Code and
+            Keyboard", KIM Kyongsok.  Computer Standards & Interfaces,
+            Vol. 14, No. 4, pp. 297-325, Aug. 1992.
+
+[KimK 1999] A Hangeul story inside computers.  KIM, Kyongsok.  Busan
+            National University  Press.  1999. [in Hangeul]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                    Expires 12th March 2001 [Page  9]
diff --git a/doc/draft/draft-ietf-idn-compare-01.txt b/doc/draft/draft-ietf-idn-compare-01.txt
new file mode 100644
index 00000000..22df4611
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-compare-01.txt
@@ -0,0 +1,687 @@
+Internet Draft                                         Paul Hoffman
+draft-ietf-idn-compare-01.txt                            IMC & VPNC
+July 11, 2000
+Expires in six months                         
+
+Comparison of Internationalized Domain Name Proposals
+
+Status of this memo
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC 2026.
+
+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
+
+The IDN Working Group is working on proposals for internationalized
+domain names that might become a standard in the IETF. Before a single
+full proposal can be made, competing proposals must be compared on a
+wide range of requirements and desired features. This document compares
+the many parts of a comprehensive protocol that have been proposed. It
+is the companion document to "Requirements of Internationalized Domain
+Names" [IDN-REQ], which lays out the requirements for the
+internationalized domain name protocol.
+
+
+1. Introduction
+
+As the IDN Working Group has discussed the requirements for IDN,
+suggestions have been made for various candidate protocols that might
+meet the requirements. These proposals have been somewhat helpful in
+bringing up real-world needs for the requirements.
+
+It became clear no single proposal had wide agreement from the working
+group. In fact, the authors of various proposals found themselves taking
+some features from other proposals as they revised their drafts. At the
+same time, working group participants were making suggestions for
+incremental changes that might affect more than one proposal.
+
+Because of this mixing and matching, it was decided that this IDN
+comparisons document should compare features that might end up in the
+final protocol, not full protocol suggestions themselves. The features
+that had been discussed in the working group were divided by function,
+and appear in this document in separate sections. For each function,
+there are multiple suggestions for protocol elements that might meet the
+requirements that are described in [IDN-REQ].
+
+This document is being discussed on the "idn" mailing list. To join the
+list, send a message to <majordomo@ops.ietf.org> with the words
+"subscribe idn" in the body of the message. Archives of the mailing list
+can also be found at ftp://ops.ietf.org/pub/lists/idn*.
+
+1.1 Format of this document
+
+Each section covers one feature that has been discussed as being part of
+the final IDN solution. Within each section, alternate proposals are
+listed with the major perceived pros and cons of the proposal. Also,
+each proposal is given a label to make discussion of this document (and
+of the proposals themselves) easier.
+
+References to the numbered requirements in [IDN-REQ] are from version
+-02 of that document. These numbers are expected to change and the
+requirements document evolves. In this draft, the requirements are show
+as "[#n-02]", where "n" is the requirement number from draft -02 of
+[IDN-REQ]. This document only lists where particular proposals don't
+meet particular requirmenents from [IDN-REQ], not the ones that they
+fulfill.
+
+Note that this document is supposed to reflect the discussion of all
+proposed alternatives, not just the ones that fully match the
+requirements in [IDN-REQ]. It will serve as a summary of the discussion
+in the IDN WG for readers in the future who may want to know why certain
+alternatives were not chosen for the eventual protocol.
+
+The proposal drafts covered in this document are:
+
+[DUERST] Character Normalization in IETF Protocols,
+draft-duerst-i18n-norm-03
+
+[IDNE] Internationalized domain names using EDNS (IDNE),
+draft-ietf-idn-idne-01
+
+[KWAN] Using the UTF-8 Character Set in the Domain Name System,
+draft-skwan-utf8-dns-03
+
+[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
+draft-ietf-idn-race-00
+
+[SENG] UTF-5, a transformation format of Unicode and ISO 10646,
+draft-jseng-utf5-01
+
+[UDNS] Using the Universal Character Set in the Domain Name System
+(UDNS), draft-ietf-idn-udns-00
+
+
+2. Architecture
+
+One of the biggest questions raised early in the IDN discussion was what
+the format of internationalized name parts would be on the wire, that
+is, between the user's computer and the DNS resolvers. It was agreed
+that the DNS protocols certainly allow non-ASCII octets in domain name
+parts and resource records, but there was also acknowledgement that many
+protocols that rely on the DNS could not handle non-ASCII names due to
+the design of the protocol. Section 3.1 of this document describes the
+proposed encodings for the non-ASCII name parts.
+
+Because of requirement [#2-02], there were proposals for
+ASCII-compatible encodings (ACEs) of non-ASCII characters. Different
+ACEs were proposed (and are discussed in Section 4 of this document),
+but they all have the same goal: to allow non-ASCII characters to be
+represented in host names that conform to RFC 1034 [RFC1034].
+
+2.1 arch-1: Just send binary
+
+[KWAN] proposes beginning to send characters outside the range allowed
+in RFC 1034.
+
+Pro: Easiest to describe. Only changes host name syntax, not any of the
+related DNS protocols.
+
+Con: Doesn't work with many exiting protocols that relies on DNS.
+Violates requirement [#9-02].
+
+2.2 arch-2: Send binary or ACE
+
+[UDNS] (and, later, [IDNE]) proposes using both binary and ACE formats
+on the wire.
+
+Pro: Allows protocols that can handle binary name parts to use them
+directly, while allowing protocols that cannot use binary name parts to
+also handle names without conversion. Allows domain names in free text
+to be displayed in binary even in systems that require ACE-formatted
+names on the wire.
+
+Con: Requires all software that uses domain names to handle both
+formats. Requires processing time for conversion of ACE formats into the
+format must likely used internally to the software.
+
+2.3 arch-3: Just send ACE
+
+[RACE] and [SENG] propose that host naming rules remain the same and
+that all internationalize domain names be sent in ACE format.
+
+Pro: No changes at all to current DNS protocols.
+
+Con: Requires all software to recognize ACE domain names and convert
+them to human-readable for display. This is true not only in domain
+names used on the wire but also domain names used in free text.
+
+
+3. Names in binary
+
+Both arch-1 and arch-2 include domain name parts that are represented on
+the wire in a binary format. This section describes some of the features
+of such names.
+
+3.1 bin-1: Format
+
+There are many different charsets and encodings for the scripts of the
+world. The WG has discussed which binary encoding should be used on the
+wire.
+
+3.1.1 bin-1.1: UTF-8
+
+The IETF policy on character sets [RFC2277] states that UTF-8 [RFC2279]
+is the preferred charset for IETF protocols. UTF-8 encodes all
+characters in the ISO 10646 repertoire.
+
+Pro: Well-supported in other IETF protocols. Compact for most scripts.
+Wide implementation in programming languages. US-ASCII characters have
+the same encoding in UTF-8 as they do in US-ASCII. Because it is based
+on ISO 10646, expansion of the repertoire comes from respected
+international standards bodies.
+
+Con: Asian scripts require three octets per character.
+
+3.1.2 bin-1.2: Labelled charsets
+
+Mailing list discussion mentioned using multiple charsets for the binary
+representation. Each name part would be labelled with the charset used.
+
+Pro: Allows users to specify names in the charsets they are most
+familiar with.
+
+Con: All resolvers would have to know all charsets. Thus, the number of
+charsets would probably have to be limited and never expand. Mapping of
+characters between charsets would have to be exact and not change over
+time.
+
+3.2 bin-2: Distinguishing binary from current format
+
+Software built for current domain names might give unexpected results
+when dealing with non-ASCII characters in domain names. For example, it
+was reported on the mailing list that some software crashes when a
+non-ASCII domain name is returned for in-addr.arpa requests. Thus, there
+may be a need for IDN to prevent software that is not binary-aware from
+receiving domain names with binary parts. This would only apply to an
+IDN that used arch-2, not arch-1.
+
+3.2.1 bin-2.1: Don't mark binary
+
+[KWAN] does not specify any way of changing requests to prevent binary
+name parts from being transmitted.
+
+Pro: No changes to current DNS requests and responses.
+
+Con: Likely to cause disruption in software that is not binary-aware.
+Likely to cause systems to misread names and possibly (and incorrectly)
+convert them to ASCII names by stripping off the high bit in octets;
+this in turn would lead to security problems due to mistaken identities.
+Returning binary host names to DNS queries is known to break some
+current software.
+
+3.2.2 bin-2.2: Mark binary with IN bit
+
+[UDNS] describes using a bit from the header of DNS queries to mark the
+query as possibly containing a binary name part and indicating that the
+response to the query can contain binary name parts.
+
+Pro: This bit is currently unused and must be set to zero, so current
+software won't use it accidentally. No changes to any other part of the
+query or RRs.
+
+Con: It's the last unused bit in the header and DNS folks have indicated
+that they are very hesitant to give it up.
+
+3.2.3 bin-2.3: Mark binary with new QTYPEs
+
+[UDNS] using new QTYPEs to mark the query as possibly containing a
+binary name part and indicating that the response to the query can
+contain binary name parts. QTYPEs are two octets long, and no QTYPEs to
+date use more than the lower eight bits, so one of the bits from the
+upper octet could be used to indicate binary names.
+
+Pro: These bits are currently unused and must be set to zero, so current
+software won't use them accidentally. No changes to any other part of
+the query or RRs. Uses a bit that isn't as prized as the IN bit.
+
+Con: Software must pay more attention to the QTYPEs than it might have
+previously.
+
+3.2.4 bin-2.4: Mark binary with EDNS
+
+[IDNE] uses EDNS [RFC2671] to mark the query and response as containing
+a binary name part.
+
+Pro: There is little use of EDNS at this point, so it is very unlikely
+to have bad interactions with old software. EDNS allows longer name
+parts, and allows additional information (such as IDN version number)
+in each name part.
+
+Con: There is little use of EDNS and this might make implementation
+harder.
+
+
+4. Names in ASCII-compatible encoding (ACE)
+
+Both arch-2 and arch-3 include domain name parts that are represented on
+the wire in an ASCII-compatible encoding (ACE). This section describes
+some of the features of such names.
+
+4.1 ace-1: Format
+
+A variety of proposals for the format of ACE have been proposed. Each
+proposal has different features, such as how many characters can be
+encoded within the 63 octet limit for each name part. The length
+descriptions in this section assume that there is no distinguishing of
+ACE from current names; this is not a likely outcome of the WG work.
+
+The descriptions of lengths is based on script block names from
+[BLOCK-NAMES].
+
+4.1.1 ace-1.1: UTF-5
+
+[SENG] Describes UTF-5, which is a fairly direct encoding of ISO 10646
+characters using a system similar to UTF-8. Characters from Basic Latin
+and Latin-1 Supplement take 2 octets; Latin Extended-A through Tibetan
+take 3 octets; Myanmar through the end of BMP take 4 octets; non-BMP
+characters take 5 octets. This means that names using all characters
+in the Myanmar through the end of BMP are limited to 15 characters.
+
+Pro: Extremely simple.
+
+Con: Poor compression, particularly for Asian scripts.
+
+4.1.2 ace-1.2: RACE
+
+[RACE] describes RACE, which is a two-step algorithm that first
+compresses the name part, then converts the compressed string into and
+ACE. Name parts in all scripts other than Han, Yi, Hangul syllables,
+Ethiopic, and non-BMP take up ceil(1.6*(n+1)) octets; name parts in
+those scripts and any name that mixes characters from different rows in
+ISO 10646 take up ceil(3.2*(n+1)) octets. This means that names using
+Han, Yi, Hangul syllables, or Ethiopic, are limited to 18 characters.
+(Note: this document used to be called CIDNUC.)
+
+Pro: Best compression for most scripts, and similar compression for the
+scripts where it is not the best.
+
+Con: More complicated than UTF-5. Not well optimized for names that have
+mixed scripts, such as non-Latin names that use hyphen or ASCII digits.
+
+4.1.3 ace-1.3: Hex of UTF-8
+
+An early draft described "hex of UTF-8", which is a straight-forward
+hexadecimal encoding of UTF-8. Characters in Basic Latin (other than
+non-US-ASCII and hyphen) take 3 octets; Latin Extended-A through Tibetan
+take 5 octets; Myanmar through end of BMP take 7 octets; non-BMP
+characters take 9 octets. This means that names using all characters
+in the Myanmar through the end of BMP are limited to 9 characters.
+
+Pros: Very simple to describe.
+
+Cons: Very poor compression for all scripts.
+
+4.1.4 ace-1.5: SACE
+
+A message on the mailing list pointed to code for SACE, an ASCII
+encoding that purports to compact to about the same size as UTF-8.
+
+Pros: Similar compression to UTF-8.
+
+Cons: No description of how the algorithm works.
+
+4.2 ace-2: Distinguishing ACE from current names
+
+Software that finds ACE name parts in free text probably should
+display the name part using the actual characters, not the ACE
+equivalent. Thus, software must be able to identify which ASCII name
+parts are ACE and which are non-ACE ASCII parts (such as current names).
+This would only apply to an IDN proposal that used arch-2, not arch-3.
+
+4.2.1 ace-2.1: Currently legal names
+
+Name parts that are currently legal in RFC 1034 can be tagged to
+indicate the part is encoded with ACE.
+
+4.2.1.1 ace-2.1.1: Add hopefully-unique legal tag
+
+[RACE] proposes adding a hopefully-unique legal tag to the beginning
+of the name. The proposal would also work with such a tag at the end of
+the name part, but it is easier for most people to recognize at the
+beginning of name parts.
+
+Pros: Easy for software (and humans) to recognize.
+
+Cons: There is no way to prevent people from beginning non-ACE names
+with the tag. Unless the tag is very unlikely to appear in any name in
+any human language, non-ACE names that begin with the tag will display
+oddly or be rejected by some systems.
+
+4.2.1.2 ace-2.1.2: Add a checksum
+
+Off-list discussion has mentioned the possibility of creating a checksum
+mechanism where the checksum would be added to the beginning (or end) of
+ACE name parts.
+
+4.2.2 ace-2.2: Currently illegal names
+
+Instead of creating names that are currently legal, another proposal is
+to create names that use the current ASCII characters but are illegal.
+
+4.2.2.1 ace-2.2.1: Add trailing hyphen
+
+An earlier draft described using a trailing hyphen as a signifier of an
+ACE name.
+
+Pros: It is surmised that most current software does not reject names
+that are illegal in this fashion. Thus, there would be little disruption
+to current systems. This mechanism takes up fewer characters than any
+proposed in ace-2.1.
+
+Cons: Some current software is will probably break with this mechanism.
+It goes against some current protocols that match the rules in RFC 1034.
+
+5. Prohibited characters
+
+There was a short but active discussion on the mailing list about which
+characters from the ISO 10646 character set should never appear in host
+names. To date, there are no Internet Drafts on the subject. This
+section summarizes some of the suggestions.
+
+5.1 prohib-1: Identical and near-identical characters
+
+Some characters are visually identical or incredibly similar to other
+characters, thus making it impossible to accurately enter host names
+that are seen in print.
+
+5.2 prohib-2: Separators
+
+Horizontal and vertical spacing characters would make it unclear where a
+host name begins and ends. Also, allowing periods and period-like
+characters as characters within a name part would also cause similar
+confusion.
+
+5.3 prohib-3: Non-displaying and non-spacing characters
+
+There are many characters that cannot be seen in the ISO 10646 character
+set. These include control characters, non-breaking spaces, formatting
+characters, and tagging characters. These characters would certainly
+cause confusion if allowed in host names.
+
+5.4 prohib-4: Private use characters
+
+Private use characters from ISO 10646 inherently have no specified
+visual form (and in fact can be used for non-displaying characters).
+Thus, there could be no visual interoperability for characters in the
+private use areas.
+
+5.5 prohib-5: Punctuation
+
+Some punctuation characters are disallowed in URLs because they are used
+in URL syntax.
+
+5.6 prohib-6: Symbols
+
+Some mailing list discussion stated that characters that do not normally
+appear in human or company names should not be allowed in host names.
+This includes symbols and non-name punctuation.
+
+
+6. Canonicalization
+
+The working group has a spirited discussion on the need for
+canonicalization. [IDN-REQ] describes many requirements for when and what
+type of canonicalization might be performed.
+
+6.1 canon-1: Type of canonicalization
+
+The Unicode Consortium's recommendations and definitions of
+canonicalization [UTR-15] describes many forms of canonicalization that
+can be performed on character strings. [DUERST] covers much of the same
+ground but makes more focused requirements for canonicalization on the
+Internet.
+
+6.1.1 canon-1.1: Normalization Form C
+
+[DUERST] recommends Normalization Form C, as described in [UTR-15], for
+use on the Internet. This form is a canonical decomposition, followed by
+canonical composition.
+
+6.1.2 canon-1.2: Normalization Form KC
+
+Discussion on the mailing list recommended Normalization Form KC. This
+form is a compatibility decomposition, followed by canonical
+composition. Compatibility decomposition makes characters that have
+compatibility equivalence the same after decomposing.
+
+6.2 canon-2: Other canonicalization
+
+Host names may have special canonicalization needs that can be added to
+those given in canon-1.
+
+6.2.1 canon-2.1: Case folding in ASCII
+
+RFC 1034 specifies that there is no difference between host names that
+have the same letters but the letters have different case. Thus, the
+name part "example" is considered the same as "Example" and "EXamPLe".
+Neither uppercase nor lowercase is specified as being canonical.
+
+6.2.2 canon-2.2: Case folding in non-ASCII
+
+Discussion on the mailing list has raised the issue of whether or not
+non-ASCII Latin characters should have the same case-folding rules as
+ASCII. Such rules would match the expectations of native speakers of
+some languages, but would go counter to the expectations of native
+speakers of other languages.
+
+6.2.3 canon-2.3: Han folding
+
+Discussion on the mailing list has raised the issue of equivalences in
+some languages use of Han characters. For example, in Chinese, there are
+many traditional characters that have equivalent simplified characters.
+Similarly, there are some Han ideographs for which there are multiple
+representations in ISO 10646. There are no well-established rules for
+such folding, and some of the proposed folding would be locale-specific.
+
+6.3 canon-3: Location of canonicalization
+
+Canonicalization can be performed in any system in the DNS. Because it
+is not a trivial operation and can require large tables, the location of
+where canonicalization is performed is important.
+
+6.3.1 canon-3.1: Canonicalize only in the application
+
+Early canonicalization is a cleaner architecture design. Spending the
+cycles on the end systems puts less burden on resolvers or servers in
+the DNS service. When IDN is first adopted, the applications need to be
+updated anyway to handle the new format for the names. It is easier for
+people to upgrade their applications than their resolvers if they need a
+new IDN feature.
+
+6.3.2 canon-3.2: Canonicalize only in the resolver
+
+Updating a single resolver provides new service to large number of
+applications and (possibly) users. It is easier to find canonicalization
+bugs in resolvers than in applications because the resolver has
+predictable programmatic interfaces. IDN will probably be revised often
+as new characters are added to ISO 10646, so updating smaller number of
+resolvers is better than revising more applications. When an end user
+has a problem with resolving an IDN name, it is much easier to test if
+the problem is in the resolver than in the user's application.
+
+6.3.3 canon-3.3: Canonicalize in the DNS service
+
+Canonicalization should happen as late as possible so that changes in
+the canonicalization algorithm don't orphan all applications and
+resolvers. Some canonicalization discards information and so should be
+delayed as long as possible. Canonicalization is practically free,
+computationally (although it involves some large tables). Because adding
+IDN to the DNS will happen over time, canonicalizing at the server will
+minimize the number of things that need to be changed, and simplify and
+centralize the process of change.
+
+
+7. Transitions
+
+Early in the working group discussion, there was active debate about how
+the transition from the current host name rules to IDN would be handled.
+Given requirement [#1-02], this transition is quite important to
+deciding which proposals might be feasible.
+
+7.1 trans-1: Always do current plus new architecture
+
+In this proposal, IDN will be used at the same time as the current DNS
+forever. That is, IDN will be in addition to the current DNS.
+
+7.2 trans-2: Transition period
+
+In this proposal, IDN will be used at the same time as the current DNS
+for a specified period of time, after which only IDN will exist. That
+is, IDN will replace the current DNS.
+
+
+8. Root server considerations
+
+DNS root servers receive all requests for top-level domains that are not
+in the local DNS cache. They are critical to the Internet.  Care must be
+taken to ensure that root servers will not be affected by new mechanisms
+introduced.
+
+Any IDN proposal that includes a binary encoding will have an impact on
+the root servers. The binary requests will affect the root servers
+because the current root server software is designed to handle current
+host names. Further, the root zone files which contain ccTLDs and gTLDs
+would have to support binary domain names and possibly binary host names
+for NS records. Because all the root servers are equivalent, they would
+have to be synchronized to support the binary domain names at the same
+time.
+
+Proposals that only use ACE and use tagging with currently-legal names
+would, by definition, not affect the root servers.
+
+
+9. Security considerations
+
+All security considerations listed in [IDN-REQ] apply to this document.
+Further, all security considerations listed in each of the IDN proposals
+must be considered when comparing the proposals.
+
+Some proposals described in this document may create new security
+considerations. However, these considerations will have to be addressed
+in the eventual protocol document. All the proposals described here are
+still incomplete and security considerations may be added to them as
+they are revised. All the proposals listed in this document use the ISO
+10646 character set, so the proposals inherit any security
+characteristics of that character set.
+
+Many protocols and applications rely on domain names to identify the
+parties involved in a network transaction. For example, a user who
+connects to a web site by entering or selecting a URL expects that their
+software will select the web site named in the URL. The uniqueness of
+domain names are crucial to ensure identification of Internet entities.
+
+To make round-trip translation between local charsets and ISO 10646, the
+ISO 10646 specification has assigned multiple code points to individual
+glyphs. Moreover, some glyphs might look similar to some users, but look
+clearly different by other users. This means that it would be simple for
+an attacker to mimic a domain name by using similar-looking but
+different glyphs and guessing that some users will not see the
+difference in their user interface.
+
+Some IDN protocols may have denial of service attacks, such as by using
+non-identified chars, exception characters, or under-specified behavior
+in using some special characters.
+
+
+10. IANA considerations
+
+This document does not create any new IANA registries. However, it is
+possible that a character property registry may need to be set up when
+the IDN protocol is created in order to list prohibited characters
+(section 5) and canonicalization mappings (section 6).
+
+
+11. Acknowledgements
+
+James Seng and Marc Blanchet gave many helpful suggestions on the
+pre-release versions of this document.
+
+
+12. References
+
+[BLOCK-NAMES] Unicode Consortium,
+<ftp://ftp.unicode.org/Public/UNIDATA/Blocks.txt>.
+
+[DUERST] Character Normalization in IETF Protocols,
+draft-duerst-i18n-norm-03
+
+[IDN-REQ] Requirements of Internationalized Domain Names,
+draft-ietf-idn-requirements-02
+
+[IDNE] Internationalized domain names using EDNS (IDNE),
+draft-ietf-idn-idne-01
+
+[KWAN] Using the UTF-8 Character Set in the Domain Name System,
+draft-skwan-utf8-dns-03
+
+[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
+draft-ietf-idn-race-00
+
+[RFC2277] IETF Policy on Character Sets and Languages, RFC 2277
+
+[RFC2279] UTF-8, a transformation format of ISO 10646, RFC 2279
+
+[RFC2671] Extension Mechanisms for DNS (EDNS0), RFC 2671
+
+[SENG] UTF-5, a transformation format of Unicode and ISO 10646,
+draft-jseng-utf5-01
+
+[UDNS] Using the Universal Character Set in the Domain Name System
+(UDNS), draft-ietf-idn-udns-00
+
+[UTR15] Unicode Normalization Forms, Unicode Technical Report #15
+
+
+A. Differences Between -00 and -01 Drafts
+
+Throughout: Changed references from [HOFFMAN] to [RACE].
+
+Throughout: Changed references from [OSCARSSON] to [UDNS].
+
+Throughout: Added [IDNE].
+
+Removed section 1.2.
+
+3.2.3: Updated to mention [UDNS].
+
+3.2.4: Updated with [IDNE], changed "EDNS0" to "EDNS", and reworded.
+
+4.1.2: Added Ethiopic to the list of scripts that require two octets per
+character.
+
+4.1.3: Removed reference to [OSCARSSON] because that is no longer in the
+[UDNS] draft.
+
+4.2.2.1: Removed reference to [OSCARSSON] because that is no longer in
+the [UDNS] draft.
+
+6.1.1: Reworded first sentence.
+
+6.3: Added entire section and subsections.
+
+8: Fixed typo in first sentence.
+
+
+B. Author Contact
+
+Paul Hoffman
+IMC & VPNC
+127 Segre Place
+Santa Cruz, CA  95060
+phoffman@imc.org or paul.hoffman@vpnc.org
diff --git a/doc/draft/draft-ietf-idn-dnsii-mdnp-01.txt b/doc/draft/draft-ietf-idn-dnsii-mdnp-01.txt
new file mode 100644
index 00000000..1ce903ea
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-dnsii-mdnp-01.txt
@@ -0,0 +1,799 @@
+
+IDN Working Group                             Edmon Chung & David Leung
+Internet Draft                                              Neteka Inc.
+<draft-ietf-idn-dnsii-mdnp-01.txt>                          August 2000
+ 
+ 
+                  DNSII Multilingual Domain Name Protocol 
+ 
+ 
+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 reader is cautioned not to depend on the values that appear in 
+   examples to be current or complete, since their purpose is primarily 
+   educational.  Distribution of this memo is unlimited. 
+    
+   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 
+    
+   Historically, the DNS is capable of handling only names within the 
+   basic English alphanumeric character set (plus the hyphen), yet the 
+   standards were so elegantly and openly designed that the extension of 
+   the DNS into a multilingual and symbols based system proves to be 
+   possible with simple adjustments. 
+    
+   These adjustments will be made on both the client side and the server 
+   side. However, DNSII works on the principal that it is preferable to 
+   make the transition to multilingual domain names seamless and 
+   transparent to the end-user. Which means initially the server, or 
+   more specifically, the resolver, SHOULD take the primary 
+   responsibility for the technical implementation of the changes 
+   required for a multilingual Internet. 
+    
+   The DNSII protocol is designed to allow the preservation of 
+   interoperability, consistency and simplicity of the original DNS, 
+   while being expandable and flexible for the handling of any character 
+   or symbol used for the naming of an Internet domain.  DNSII intends 
+   to provide a platform for the implementation of multilingual domain 
+   names.  Besides the original specifications therefore, four 
+   alternatives are included for discussion purposes in this document. 
+  
+Chung & Leung		                                        [Page 1]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+   This draft forms the introduction of a series of draft including 
+   intended resolution processes and other DNSII documents. 
+    
+Table Of Contents 
+    
+   1. Introduction....................................................2 
+   1.1 Terminology....................................................2 
+   1.2 DNSII..........................................................2 
+   2. DNSII Protocol..................................................3 
+   2.1 InPacket DNSII Identifier......................................3 
+   2.2 InPacket Label Encoding Type (ILET)............................4 
+   2.3 The Rationale for using ILET...................................5 
+   2.4 Considerations for Specific Requests...........................6 
+   2.4.1 PTR Records..................................................6 
+   3. Alternate Implementations.......................................7 
+   3.1 Restricted ILET Values.........................................7 
+   3.2 Reduced ILET Bit Allocation....................................8 
+   3.3 DNSII over EDNS................................................9 
+   3.3.1 DNSII Identifier using EDNS..................................9 
+   3.3.2 ILET using EDNS OPT RRs.....................................10 
+   4. Implementation & Deployment Strategies.........................11 
+   5. IDN Requirements Considerations................................12 
+   6. DNSSEC, EDNS and IPv6 Considerations...........................12 
+   7. Intellectual Property Considerations...........................13 
+   8. References.....................................................13 
+    
+    
+1. Introduction 
+    
+   This Internet-draft describes details of the DNSII Multilingual 
+   Domain Name protocol. The Internet-Draft assumes that the reader is 
+   familiar with the concepts discussed in the widely distributed RFCs 
+   "Domain Names Concepts and Facilities" [RFC 1034] and "Domain Names 
+   Implementation and Specification" [RFC 1035]. 
+    
+    
+1.1 Terminology 
+    
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 
+   and "MAY" in this document are to be interpreted as described in RFC 
+   2119 [RFC2119]. 
+    
+   A number of multilingual characters are used in this document for 
+   examples.  Please select your view encoding type to UTF-8 for it to 
+   be displayed properly. 
+    
+1.2 DNSII 
+    
+   Many of the current proposals for a multilingual domain name system 
+   involve working around the current ANSI based DNS.  So doing either 
+   affects the integrity of the original spirit of the DNS or does not 
+   well address the encoding conflict issues apparent in different 
+   character encoding schemes.  
+  
+Chung & Leung		                                        [Page 2]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+    
+   The DNSII specifications takes a radically different approach: it 
+   successfully identifies the difference between original DNS and DNSII 
+   packets within the labels and at the same time allows the use of 
+   multiple charsets to be easily incorporated in a standardized manner.  
+   It causes no harm to the current DNS because it embraces the original 
+   format for DNS laid out in RFC1035, complemented with the ideas 
+   incorporated in EDNS [RFC2671].  
+    
+    
+2. DNSII Protocol 
+    
+   The DNSII Protocol consists mainly of two parts: the InPacket DNSII 
+   Identifier and the InPacket Label Encoding Type.  In addition, there 
+   are several special considerations for specific record types. 
+    
+    
+2.1 InPacket DNSII Identifier 
+    
+   In the DNSII specifications, an InPacket DNSII Identifier MUST be 
+   inserted before a label to signify that it contains extended 
+   characters that are not supported by the current DNS. 
+    
+   This DNSII flag, which is the first two bits of a label, effectively 
+   distinguishes a DNSII compliant request from the existing format, 
+   without having to conduct a guess from a name check whether the 
+   incoming packet is multilingual aware.  This is a substantial 
+   improvement over character encoding schemes and multilingual 
+   implementations in which it is almost impossible to determine the 
+   language of an incoming request. The DNSII flag makes the process 
+   clear and simple.     
+    
+   Currently: 
+   "00"   regular label [RFC1035] 
+   "11"   a redirection for DNS compression [RFC1035] 
+   "01"   indicates the use of EDNS for multiple UDP packets [RFC2671] 
+    
+   DNSII calls for the use of the bit sequence "10" to identify that the 
+   querying node is DNSII aware.  This will mean that all the possible 
+   variations at top two label bits will be used.  Therefore, in 
+   consideration, following two bits MUST be reserved for future 
+   flagging use.  The 2 bits SHOULD be arbitrarily set to "00".  This 
+   effectively opens up 3 more possible implementations for future 
+   enhancements. 
+    
+   The motivation for this approach is the belief there should be no 
+   ambiguity in name resolution.  Any name that the client wishes to 
+   resolve, should resolve, regardless of the client side-encoding 
+   scheme. 
+    
+    
+
+
+  
+Chung & Leung		                                        [Page 3]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+2.2 InPacket Label Encoding Type (ILET) 
+    
+   Immediately following the 2 assigned DNSII flag and the 2 reserved 
+   bits are 12 bits assigned to determine the InPacket Label Encoding 
+   Type (ILET). 
+    
+   The ILET is a 12-bit number that is used to determine the encoding 
+   scheme used by the characters of the label.  The MIBenum numbers 
+   [RFC1700] SHOULD be used in this field.  The allocation of 12 bits 
+   aligns perfectly with the MIBenum specification, of which the value 
+   goes up to over 2200.  With 12 bits, the total possible values would 
+   be 4096 (with 11 bits, the largest value that can be represented is 
+   only 2047, slightly short of the specification).  The reason for the 
+   adoption of MIBenum is to make use of the existing list of encoding 
+   numbering schemes rather than re-inventing the wheel. 
+    
+   The value in the ILET field SHOULD only be allowed for the valid 
+   encoding schemes defined in the MIBenum list.  After identifying the 
+   encoding type, the regular count-label scheme of the DNS resumes.  
+   The resulting label should look like this: 
+    
+                        1 1 1 1 1 1   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+   +---+---+-------+---------------+ 
+   |1 0| z |         ILET          | 
+   +---------------+---------------+ 
+   |     COUNT     | characters... | 
+   +---------------+---------------+ 
+    
+   To minimize the size of a DNS packet, if the entire label is 
+   constituted in characters only from the ANSI table, the DNS label 
+   will appear identical to current implementations.  The first two bits 
+   will remain "00". 
+   For example, using the DNSII format the label for "dns" MAY be 
+   represented as: 
+    
+     0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  
+   | 1  0| 0  0| 0  0  0  0  0  0  0  0  0  0  1  1|  MIBenum 3 = ANSI 
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+   |           3           |     6           4     |  "d"=64 
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+   |     6           E     |     7           3     |  "n"=6E  "s"=73 
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+    
+   Or, the same domain label "dns" MAY also be represented as: 
+    
+     0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+   |           3           |           d           | 
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+   |           n           |           s           | 
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+  
+Chung & Leung		                                        [Page 4]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+   With a multilingual domain name ns.…––…Éì‡þ©‡´˜.tld as an example: 
+    
+                        1 1 1 1 1 1                     1 1 1 1 1 1   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+   +---------------------------------------------------------------+ 
+   |1 0| z |        ANSI=3         |       2       |       n       | 
+   +---------------------------------------------------------------+ 
+   |       s       |1 0|0 0|       UCS-2=1000      |       4       | 
+   +---------------------------------------------------------------+ 
+   |          …––   (U+57DF)        |          …Éì    (U+540D)         | 
+   +---------------------------------------------------------------+ 
+   |          ‡þ©   (U+7CFB)        |          ‡´˜    (U+7D71)         | 
+   +---------------------------------------------------------------+ 
+   |0 0|     3     |       t       |       l       |       d       | 
+   +---------------------------------------------------------------+ 
+   |       0       | 
+   +---------------+ 
+   From the above example, we can see that the DNSII format is used for 
+   the first label "ns", as well as for the second label, which is in 
+   Chinese (the MIBenum for UCS-2 or ISO 10646 [Unicode] is 1000).  The 
+   third label "tld" however uses the current format. 
+    
+   In any case, the count-label-count-label mechanism is largely 
+   preserved.  Especially in the case of extended characters where in 
+   other proposals, the "count" no longer represents the character 
+   count.  In the above example, the domain is still represented as 2ns4
+   …––…Éì‡þ©‡´˜3t ld0, exactly in line with the original specifications. 
+    
+   Note that the first label in any query could be represented in DNSII 
+   format to alert the destination server that it is DNSII aware.  This 
+   is not required but is specifically configured for the considerations 
+   with CNAME, A6, DNAME and PTR records. 
+    
+   This approach is used to ensure that there is no confusion about the 
+   encoding format of the label.  ILET allows the capability of 
+   employing all existing encoding schemes (UTF-7, UTF-8, ISO 10646 
+   [UCS-2], ISO 10646 [UCS-4]).  ILET also allows the flexibility of 
+   employing future encoding schemes. 
+    
+    
+2.3 The Rationale for using ILET 
+    
+   Besides being able to preserve the count-label-count-label structure, 
+   which in itself is actually a very important part because of the 
+   problematic non-uniform byte encoding schemes, the use of ILET aligns 
+   perfectly with previous IETF specifications as well as beneficial for 
+   tricky case folding and canonicalization issues. 
+    
+   We know that all protocols MUST identify, for all character data, 
+   which charset is in use [RFC2277], therefore it is necessary to 
+   specify whatever encoding scheme, whether it be UTF-8, UTF-7, 16-bit 
+   UCS-2 or ISO 8859 that is being used.  In essence, we understand that 
+
+  
+Chung & Leung		                                        [Page 5]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+   it is paramount that a charset be clearly identified, especially in 
+   situation like the DNS where no direct communication is established. 
+    
+   At times and in specific cases, language information may be required 
+   to achieve a particular level of quality for the purpose of 
+   displaying a text stream.  For example, UTF-8 encoded Han may require 
+   transmission of a language tag to select the specific glyphs to be 
+   displayed at a particular level of quality. 
+    
+   Note that information other than language may be used to achieve the 
+   required level of quality in a display process.  In particular, a 
+   font tag is sufficient to produce identical results.  However, the 
+   association of a language with a specific block of text has 
+   usefulness far beyond its use in display.  In particular, as the 
+   amount of information available in multiple languages on the World 
+   Wide Web grows, it becomes critical to specify which language is in 
+   use in particular documents, to assist automatic indexing and 
+   retrieval of relevant documents._ [RFC2130] 
+   In effect, this means for different languages, it is beneficial to be 
+   able to identify the language in order to perform specific functions 
+   to the characters, including case folding.  With ILET, the local    
+   encoding scheme could be used and with them there are well defined 
+   folding methods.  Therefore, the use of ILET enables an optimized 
+   folding mechanism brought about by the preservation of local encoding 
+   schemes, which is otherwise very difficult or virtually impossible to 
+   do if only UTF-8 is used.  
+    
+   For the DNS however, a language tag is less feasible because if a 
+   name is consisted of multiple languages, it would be very difficult 
+   for tagging to be performed.  The possibility of having multiple 
+   languages is very sound, and is used frequently as trademarks around 
+   the world.  For example the famous Toys"ϯ"Us name, uses a character 
+   from the Cyrillic language set. 
+    
+    
+2.4 Considerations for Specific Requests 
+    
+   For certain requests, an ANSI only name could result in a 
+   multilingual domain as an answer.  These include PTR, CNAME, A6 and 
+   DNAME requests.  Special considerations are made within the DNSII 
+   protocol to make sure that non-DNSII aware servers will not be fed 
+   with a DNSII format packet. 
+    
+    
+2.4.1 PTR Records 
+    
+   For all PTR requests, the first label of the query MUST use DNSII 
+   format to alert the destination server.  Upon which, a DNSII packet 
+   will be replied should the name contain extended characters. 
+    
+   If the DNSII format is not used, and the PTR record stumbles upon a 
+   multilingual domain name, one of the following responses SHOULD be 
+   given: 
+  
+Chung & Leung		                                        [Page 6]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+   a. The implementer of DNSII MAY chose to reject the request; 
+    
+   or 
+    
+   b. An ACE format domain with a "for.ref.only" suffix MAY be returned; 
+    
+   or 
+    
+   c. A DNSII compliant server MAY return an 8-bit format of the 
+   requested domain. 
+    
+   Since the PTR record is usually used for display purposes only, the 
+   rejection (the IP address will then be used) or ACE format is 
+   acceptable.  If the response is however used for further resolution, 
+   an ACE format MUST not be used. 
+    
+    
+2.4.2 CNAME, A6 & DNAME 
+    
+   For queries concerning the record types CNAME, A6 or DNAME, a DNSII 
+   aware server should first check to see if the incoming request is 
+   DNSII compliant (flagged by the "10" bits in the first label): 
+    
+   If so, and the domain to be returned includes extended characters, 
+   the response SHOULD be in DNSII format. 
+    
+   If not, any multilingual domains returned should be in an 8 bit form. 
+    
+   For the above record types it is strongly RECOMMENDED not to 
+   associate an alphanumeric label to a multilingual label as the 
+   RDATA.  However, it is permissible to associate a multilingual label 
+   with an alphanumeric label as the RDATA. 
+    
+    
+3. Alternate Implementations 
+    
+   The DNSII-MDNP is intended to be a framework for the implementation 
+   of multilingual domain names.  While the core concepts and the design 
+   principles remain consistent, it is possible to contemplate 
+   alternative implementations.  The four alternatives introduced here 
+   include the arbitrary restriction of ILET values, the reduction of 
+   ILET bit allocation for reflecting ISO 10646 transformations only, 
+   and finally two implementations using DNSII over EDNS. 
+    
+    
+3.1 Restricted ILET Values 
+    
+   One possible implementation guideline is for the ILET to be 
+   restricted to values only representing ISO 10646 transformations 
+   including UCS-2, UCS-4, UTF-7, UTF-8, UTF-16 and other as they become 
+   available and included as a standard MIBenum. 
+    
+
+  
+Chung & Leung		                                        [Page 7]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+   Although this takes away some of the benefits of keeping the local 
+   encoding scheme which includes the issues of case folding, 
+   canonicalization and other related concerns, it creates a system that 
+   on one hand contains only encoding schemes from ISO 10646, but on the 
+   other hand still provides the flexibility of deploying new encoding 
+   schemes that stem from ISO 10646, such as the 32-bit format that is 
+   due to be used soon. 
+    
+   We understand it is specified that in protocols, which up to now have 
+   used US-ASCII only, UTF-8 forms a simple upgrade path; however, its 
+   use should be negotiated either by negotiating a protocol version or 
+   by negotiating charset usage, and a fallback to UTF-7 MUST be 
+   available. [RFC2130]  With DNSII, the required fallback to UTF-7 
+   could easily be done by setting the ILET value to reflect UTF-7. 
+    
+    
+3.2 Reduced ILET Bit Allocation 
+    
+   Furthering the restriction of the ILET to ISO 10646 transformations 
+   only, the ILET bit allocations could also be reduced from 12 bit to 5 
+   bit.  This successfully creates a total of 32 possible values.  The 
+   reserved bits are also reduced to one. 
+    
+                        1 1 1 1 1 1   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+   +---+-+---------+---------------+ 
+   |1 0|z|  ILET   |     COUNT     | 
+   +---------------+---------------+ 
+   | characters... | 
+   +---------------+ 
+    
+   For example, the label "…––…Éì‡þ©‡´˜" will now be reflected in DNS packets 
+   in the following form: 
+    
+                        1 1 1 1 1 1                     1 1 1 1 1 1   
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+   +---------------------------------------------------------------+ 
+   |1 0|z| ILET=1  |       4       |          …––   (U+57DF)        | 
+   +---------------------------------------------------------------+ 
+   |          …Éì   (U+540D)         |         ‡þ©    (U+7CFB)         | 
+   +---------------------------------------------------------------+ 
+   |          ‡´˜   (U+7D71)         | 
+   +--------------------------------+ 
+    
+   To start off with, the ILET values MAY be determined as follows: 
+    
+   0 = reserved for ANSI               1 = UTF-7 
+   2 = UCS-2                           3 = UTF-8 
+   4 = UCS-4                           5 = UTF-16 
+   6 = 6 octets per character          7 = 7 octets per character 
+   8 = UCS-8 (8 octets per character)  9 = UTF-31 
+   etc. 
+    
+  
+Chung & Leung		                                        [Page 8]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+   The ILET number will be the number of octets that should be read each 
+   time, with exceptions at 0,3,5,9 or any number that is just after a 
+   full UCS.  ILET=3 corresponds to UTF8 because ILET=2 = UCS2 and UTF-8 
+   is a compatibility transformation for UCS-2 (in 16bit) in 8bit.  A 
+   possible future expansion to UCS-8 is also included to make the 
+   schema truly future prove. 
+    
+   This arrangement opens up opportunity and versatility of the use of 
+   private schemes that make use of odd byte length characters or 
+   symbols such as 6, 7 or even 18octet representations without the need 
+   for the DNS to update or adjust to, while maintaining the integrity 
+   and unique nature of domain names.   
+    
+    
+3.3 DNSII over EDNS 
+    
+   While DNSII and EDNS could coexist, it is possible to implement the 
+   DNSII concept onto an EDNS based platform.  It is however preferable 
+   to use both EDNS and the DNSII scheme together as described in 
+   Section 6, because EDNS(0) compliant servers may have trouble when 
+   the label count exceeds the value of 63 (and smaller than 127) 
+   because then, the EDNS mechanism MAY be reiterated. 
+    
+   Nevertheless, it is possible to utilize EDNS to act as a DNSII 
+   Identifier.  The short-comings and pit-falls are however further laid 
+   in another draft DNSII-EDNS. 
+    
+    
+3.3.1 DNSII Identifier using EDNS 
+    
+   EDNS could simply be used in place of the DNSII Identifier.  Assuming 
+   that the reduced ILET values introduced in Section 3.2 is used, the 
+   ILET will fit nicely into one octet immediately following the ELT 
+   portion.  The resulting representation for the domain "host.…––…Éì‡þ©‡´˜
+   .tld" would be as follows: 
+    
+                          1 1 1 1 1 1                     1 1 1 1 1 1   
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+     +---------------------------------------------------------------+ 
+   20|0 0|      4    |       h       |       o       |       s       | 
+     +---------------------------------------------------------------+ 
+     |       t       |0 1|0 0 0 0 1 0| ILET=UCS-2=2  |       4       | 
+     +---------------------------------------------------------------+ 
+     |          …––   (U+57DF)        |          …Éì    (U+540D)         | 
+     +---------------------------------------------------------------+ 
+     |          ‡þ©   (U+7CFB)        |          ‡´˜    (U+7D71)         | 
+     +---------------------------------------------------------------+ 
+     |0 0|     3     |       t       |       l       |       d       | 
+     +---------------------------------------------------------------+ 
+     |       0       | 
+     +---------------+ 
+    
+
+  
+Chung & Leung		                                        [Page 9]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+   The OPT RR could be used not only for version control but also as a 
+   notification for the destination server on the level of conformance 
+   of the inquirer.  This is especially beneficial when considering the 
+   issues raised in Section 2.4 where ANSI only requests my result in a 
+   multilingual response. 
+    
+   Proposed identifications within the OPT RR (used in this document for 
+   discussion purposes): 
+   ELT = 0b000010 
+   EDNS-VERSION = 2 (DNSII) 
+   OPTION-CODE = 1 (IDN) 
+   OPTION-DATA = conformance level (defined in DNSII-MDNR Section 4) 
+                 Plus other information if required 
+    
+   The conformance level SHOULD be included in the first octet of the 
+   OPTION-DATA field and reflect the value corresponding to: 
+    
+   BASIC conformance = 1 
+   INTERMEDIATE conformance = 2 
+   FULL conformance = 3 
+    
+   A resulting DNSII OPT RR from a fully compliant inquirer SHOULD be in 
+   the form: 
+    
+                          1 1 1 1 1 1                     1 1 1 1 1 1   
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+     +---------------------------------------------------------------+ 
+     |    NAME=0     |       TYPE = OPT = 41         | Sender's UDP  | 
+     +---------------------------------------------------------------+ 
+     | Payload Size  |EXTENDED-RCODE=0|EDNS-VERSION=2|       z       | 
+     +---------------------------------------------------------------+ 
+     |       z       |         RDLENGTH = 5          | OPTION-CODE = | 
+     +---------------------------------------------------------------+ 
+     |    IDN = 1    |      OPTION-LENGTH = 1        | Conformance=3 | 
+     +---------------------------------------------------------------+ 
+    
+    
+3.3.2 ILET using EDNS OPT RRs 
+    
+   Instead of using the OPT RR only as a notification of DNSII 
+   awareness, it utilized to indicate the type of encoding that is being 
+   used in the labels.  In other words, the ILET value could be included 
+   in the OPT RR instead of within the label. 
+    
+   The ILET value will be included right after the conformance level 
+   octet in the OPTION-DATA field within the OPT RR RDATA.
+
+
+
+
+
+
+
+  
+Chung & Leung		                                       [Page 10]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+   The resulting QNAME labels and OPT RR for the domain "www.…––…Éì‡þ©‡´˜
+   .tld" from a fully compliant inquirer sending the name in UCS-2 
+   would become: 
+    
+                          1 1 1 1 1 1                     1 1 1 1 1 1   
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+     +---------------------------------------------------------------+ 
+     |0 0|     3     |       w       |       w       |       w       | 
+     +---------------------------------------------------------------+ 
+     |0 1|0 0 0 0 1 0|       4       |          …––   (U+57DF)        | 
+     +---------------------------------------------------------------+ 
+     |          …Éì   (U+540D)        |          ‡þ©    (U+7CFB)        | 
+     +---------------------------------------------------------------+ 
+     |          ‡´˜   (U+7D71)        |0 0|     3     |       t       | 
+     +---------------------------------------------------------------+ 
+     |       l       |       d       |       0       | 
+     +-----------------------------------------------+ 
+    
+   (OPT RR containing ILET information) 
+     :                                                               : 
+     /                                                               / 
+     +---------------------------------------------------------------+ 
+     |    NAME=0     |       TYPE = OPT = 41         | Sender's UDP  | 
+     +---------------------------------------------------------------+ 
+     | Payload Size  |EXTENDED RCODE=0|EDNS-VERSION=2|       z       | 
+     +---------------------------------------------------------------+ 
+     |       z       |         RDLENGTH = 9          | OPTION-CODE = | 
+     +---------------------------------------------------------------+ 
+     |    IDN = 1    |      OPTION-LENGTH = 4        | Conformance=3 | 
+     +---------------------------------------------------------------+ 
+     |       1       |       0       |       0       |       0       | 
+     +---------------------------------------------------------------+ 
+    
+    
+   Note that instead of allocating only 12 bits for the ILET, the 
+   MIBenum value is expressed over 4 octets with each octet carrying a 
+   numeric value.  Since UCS-2 is used and the MIBenum value for UCS-2 = 
+   1000, the 4 octets corresponds to the values 1, 0, 0, 0 respectively. 
+    
+   If the reduced ILET values are used, only 1 octet is required to 
+   reflect the encoding scheme being used. 
+    
+    
+4. Implementation & Deployment Strategies 
+    
+   The first step in any multilingual domain name implementation should 
+   be to encourage an 8-bit clean approach to DNS.  However, even when 
+   the system is 8-bit clean the problem with conflicting characters 
+   still exists.  This is where the DNSII protocol becomes most 
+   valuable. 
+    
+   Although the DNSII protocol could be implemented at any level of the 
+   DNS, the following phased rollout is contemplated. 
+  
+Chung & Leung		                                       [Page 11]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+    
+   (1) Registry Level - The most meaningful starting point for 
+   deployment would be at the registry level since this creates the 
+   demand from the end users to use multilingual and extended character 
+   domain names for Second Level Domains. 
+    
+   (2) Host Level - At the same time, registrants of the new extended 
+   domain names could start to implement DNSII to host these special 
+   kinds of domain names.  All other hosts that do not wish to use 
+   extended characters do not have to migrate to the DNSII. 
+    
+   (3) Client Level - Once the multilingual aspect and the DNSII 
+   specifications become mainstream, the user level resolvers will begin 
+   to migrate.  This will include both the client resolver as well as 
+   the ISP's DNS. 
+    
+   (4) Root Level - Eventually, as the DNSII is proven to be stable and 
+   beneficial for the Internet at large, it could be used in the Root 
+   Level so that new multilingual TLDs could be created. 
+    
+    
+5. IDN Requirements Considerations 
+    
+   The DNSII protocol specification is in line with most if not all of 
+   the requirements identified by the IDN work group. 
+    
+    
+6. DNSSEC, EDNS and IPv6 Considerations 
+    
+   The use of DNSII should not require any adjustments with the 
+   implementation of DNSSEC, EDNS or IPv6.  EDNS as well as compression 
+   in fact will be done exactly the same as the existing system.     
+   For example, the domain host.dns.…––…Éì‡þ©‡´˜.tld running with EDNS as 
+   well as compression after host will look as follows: 
+    
+    
+                          1 1 1 1 1 1                     1 1 1 1 1 1   
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+     +---------------------------------------------------------------+ 
+   20|0 1|    ELT    |0 0|     3     |       d       |       n       | 
+     +---------------------------------------------------------------+ 
+     |       s       |1 0|0 0|       UCS-2=1000      |       4       | 
+     +---------------------------------------------------------------+ 
+     |          …––   (U+57DF)        |          …Éì    (U+540D)         | 
+     +---------------------------------------------------------------+ 
+     |          ‡þ©   (U+7CFB)        |          ‡´˜    (U+7D71)         | 
+     +---------------------------------------------------------------+ 
+     |0 0|     3     |       t       |       l       |       d       | 
+     +---------------------------------------------------------------+ 
+     |       0       | 
+     +---------------+ 
+    
+  
+Chung & Leung		                                       [Page 12]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+     :                                                               : 
+     /                                                               / 
+     +---------------------------------------------------------------+ 
+     |0 0|     4     |       h       |       o       |       s       | 
+     +---------------------------------------------------------------+ 
+     |       t       |1 1|           21              | 
+     +-----------------------------------------------+ 
+    
+    
+7. Intellectual Property Considerations 
+    
+   It is the intention of Neteka to submit the DNSII protocol and other 
+   elements of the multilingual domain name server software to IETF for 
+   review, comment or standardization. 
+    
+   Neteka Inc. has applied for one or more patents on the technology 
+   related to multilingual domain name server software and multilingual 
+   email server software suite.  If a standard is adopted by IETF and 
+   any patents are issued to Neteka with claims that are necessary for 
+   practicing the standard, any party will be able to obtain the right 
+   to implement, use and distribute the technology or works when 
+   implementing, using or distributing technology based upon the 
+   specific specifications under fair, reasonable and non-discriminatory 
+   terms. 
+    
+   Other DNSII related documents and discussions could be found at 
+   http://www.dnsii.org. 
+    
+8. References 
+    
+   [DNSII-MDNR] E. Chung, D. Leung, _DNSII Multilingual Domain Name 
+              Resolution_, August 2000 
+    
+   [RFC1700]  J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, 
+              October 1994. 
+     
+   [ISO10646] ISO/IEC 10646-1:2000. International Standard - 
+              Information technology -- Universal Multiple-Octet Coded 
+              Character Set (UCS) 
+    
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and 
+              Facilities," STD 13, RFC 1034, USC/ISI, November 1987 
+       
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and  
+              Specification," STD 13, RFC 1035, USC/ISI, November 1987 
+    
+   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate  
+              Requirement Levels," RFC 2119, March 1997 
+    
+   [RFC2130]  C. Weider, et al. _The Report of the IAB Character Set 
+              Workshop held 29 February - 1 March, 1996_ RFC 2130, 
+              April 1997 
+    
+  
+Chung & Leung		                                       [Page 13]
+DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
+ 
+   [RFC2277]  H. Alvestrand, _IETF Policy on Character Sets and 
+              Languages_ RFC 2277, January 1998 
+    
+   [RFC2671]  Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", 
+              August 1999, RFC 2671. 
+ 
+    
+    
+   Authors: 
+    
+   Edmon Chung 
+   Neteka Inc. 
+   2462 Yonge St. Toronto, 
+   Ontario, Canada M4P 2H5 
+   edmon@neteka.com 
+    
+   David Leung 
+   Neteka Inc. 
+   2462 Yonge St. Toronto, 
+   Ontario, Canada M4P 2H5 
+   david@neteka.com 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chung & Leung		                                       [Page 14]  
+
+
diff --git a/doc/draft/draft-ietf-idn-dnsii-mdnr-00.txt b/doc/draft/draft-ietf-idn-dnsii-mdnr-00.txt
new file mode 100644
index 00000000..48cc4a0f
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-dnsii-mdnr-00.txt
@@ -0,0 +1,855 @@
+
+IDN Working Group                             Edmon Chung & David Leung
+Internet Draft                                              Neteka Inc.
+<draft-ietf-idn-dnsii-mdnr-00.txt>                          August 2000
+ 
+ 
+                                     
+               DNSII Multilingual Domain Name Resolution 
+ 
+ 
+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 reader is cautioned not to depend on the values that appear in 
+   examples to be current or complete, since their purpose is primarily 
+   educational.  Distribution of this memo is unlimited. 
+    
+   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 
+    
+   The Internet-Draft for DNSII-MDNP was focused purely on discussing 
+   the ultimate packet protocol that is being sent around the Internet 
+   for multilingual domain names.  This paper complements the previous 
+   paper by outlining the contemplated resolution process with the DNSII 
+   protocol throughout the DNS name resolution process. 
+    
+   The DNSII-MDNR outlines a resolution process that forms a framework 
+   for the resolution of multilingual domain names.  Whether the DNSII 
+   protocol is implemented exactly as specified in DNSII-MDNP is less 
+   relevant, rather it is the idea of having a multilingual packet 
+   identifier and the fall back process that matters.  The DNSII-MDNR 
+   successfully addresses the transitional issues at each node of the 
+   DNS resolution process providing a clear migration path and strategy 
+   for the deployment of a multilingual enabled DNS system.  It also 
+   outlines the conformance levels required for basic or complete 
+   implementations for applications, resolvers and name servers. 
+    
+   This document also introduces a tunneling mechanism for the short-run 
+   to transition the system through to a truly multilingual capable name 
+   space. 
+  
+Chung & Leung		                                        [Page 1]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+Table of Contents 
+    
+   1. Introduction....................................................2 
+   1.1 Terminology....................................................2 
+   1.2 Multilingual Domain Name Resolution............................3 
+   1.2 DNSII-MDNR.....................................................3 
+   2. DNSII Proposal with respect to the DNS Layers...................3 
+   3. The Resolution Process..........................................5 
+   3.1 Steady State Resolution........................................5 
+   3.2 Client-End or Inquirer Transitional Fall-Back Strategy.........6 
+   3.2.1 Tunneling MDNP through DNSII RR..............................6 
+   3.2.2 Tunneling ILET RRs...........................................8 
+   3.3 Resolvers & Server-End Transitional Fallback Strategy..........9 
+   3.3.1 Tunneling MDNP Responses through DNSII ANS RR................9 
+   3.3.2 Reinsertion of ILET and DNSII Identifier....................10 
+   4. DNSII Conformance Levels.......................................10 
+   4.1 Application Conformance Levels................................11 
+   4.2 Resolver Conformance Levels...................................11 
+   4.3 Authoritative Server Conformance Levels.......................11 
+   5. Transition Schedule & Strategy.................................12 
+   6. Summary of Discussion..........................................12 
+   6.1 Client/Application Resolution Strategy........................13 
+   6.2 Resolver Resolution Strategy..................................13 
+   6.3 Authoritative Name Server Resolution Strategy.................13 
+   7. Security Considerations........................................14 
+   8. Intellectual Property Considerations...........................14 
+   9. References.....................................................14 
+    
+    
+1. Introduction 
+    
+   This Internet-Draft describes details of the contemplated resolution 
+   process after the deployment of DNSII-MDNP, or other multilingual 
+   domain name efforts containing a bit flag multilingual packet 
+   identifier or otherwise InPacket identifications for that matter. 
+    
+   The reader is assumed to be familiar with the concepts discussed in 
+   the DNSII-MDNP Internet-Draft <draft-ietf-idn-dnsii-mdnp.txt>. 
+    
+    
+1.1 Terminology 
+    
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 
+   and "MAY" in this document are to be interpreted as described in RFC 
+   2119 [RFC2119]. 
+    
+   A number of multilingual characters are used in this document for 
+   examples.  Please select your view encoding type to Big-5 
+   (Traditional Chinese) for them to be displayed properly. 
+    
+    
+    
+    
+  
+Chung & Leung		                                        [Page 2]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+1.2 Multilingual Domain Name Resolution 
+    
+   The original specifications for the DNS were designed to be open 
+   enough for simple implementation of a multilingual naming system with 
+   slight adjustments as laid out in DNSII-MDNP.  The transition and 
+   especially its resolution process during migration is however a 
+   tricky problem.  Several things that MUST be kept in mind is that 
+   there is a initial phase, an intermediate phase and an ultimate 
+   steady state phase.  DNSII-MDNP only described the ideal protocol at 
+   steady state, with incorporated flexibility for transition from the 
+   present to multilingual as well as again towards future unknown 
+   grounds. 
+    
+   It is important to remember that the ultimate form SHOULD be 
+   determined and then the transition scheme laid out.  While an ASCII 
+   translation system might seem favorable in the short-run, it 
+   effectively creates an alternative universe which is counter to the 
+   spirit of the DNS.  However an ASCII translation is implemented, it 
+   immediately creates a "human-multilingual" universe and a "machine-
+   ASCII" universe.  This document introduces a tunneling mechanism to 
+   transition the DNS from today's monolingual system, through an 8-bit 
+   or 7-bit migration scheme towards a truly sustainable multilingual 
+   name space, arriving at a DNSII type system. 
+     
+    
+1.2 DNSII-MDNR 
+    
+   While DNSII-MDNP describes the framework for the ultimate protocol 
+   format of a multilingual DNS, DNSII-MDNR will discuss how the packet 
+   SHOULD be transported and interpreted throughout the DNS.  The 
+   document will describe both the intended resolution process as well 
+   as part of the transition strategy from the existing DNS to a DNSII 
+   enabled system. 
+    
+    
+2. DNSII Proposal with respect to the DNS Layers 
+    
+   The following diagram illustrates the use of DNSII-MDNP at a steady 
+   state.  Section 3 will discuss the fallback strategies while Section 
+   4 will talk about issues on conformance levels. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Chung & Leung		                                        [Page 3]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+   +---------------+ 
+   |               | NamePrep: 
+   |  Application  | Canonicalize in Form C/KC 
+   |               | Insert DNSII Identifier    +---------------------+ 
+   |               | Insert appropriate ILET    |    (Base data)      | 
+   +---------------+                            +---------------------+ 
+           |                                            | 
+           |  DNS Packet with DNSII                     | (no standard) 
+           |  Identifier & ILET                         |  RECOMMENDS 
+           |                                            |  UCS-2/4 
+   +---------------+                                    | 
+   |   Resolver    | Canonicalize, Case Fold    +---------------------+ 
+   |               | (for cache lookup) or      | Auth DNS server     | 
+   +---------------+ leave as is & Resolve      | (Canonicalize,      | 
+           |                                    | Case Fold & Lookup) | 
+           |  Pass Along without                +---------------------+ 
+           |  Altering Case or Canonicalization         | 
+           |                                            | 
+           |   <-----   DNS service interface  ----->   | 
+   +------------------------------------------------------------------+ 
+   |  DNS service                                                     | 
+   |  +-----------------------+         +--------------------+        | 
+   |  | Forwarding DNS server |         | Caching DNS server |        | 
+   |  +-----------------------+         +--------------------+        | 
+   |                                                                  | 
+   |                 +-------------------------+                      | 
+   |                 | Parent-zone DNS servers |                      | 
+   |                 +-------------------------+                      | 
+   |                                                                  | 
+   |                 +-------------------------+                      | 
+   |                 | Root DNS servers        |                      | 
+   |                 +-------------------------+                      | 
+   |                                                                  | 
+   +------------------------------------------------------------------+ 
+    
+   Please note that at each level, the domain name is being 
+   canonicalized.  This is to ensure that at the end, characters that 
+   can be represented by a single code point will not be otherwise 
+   compared resulting in inconsistent reply to a humanly identical name.  
+   It is RECOMMENDED that applications SHOULD conduct canonicalization 
+   while servers MUST.  Duplicating the process is fine because if a 
+   character is already composed, it will not compose again with another 
+   character. 
+    
+   This arrangement is very similar to the ASCII case folding 
+   experienced in the DNS today.  In the original specifications, it was 
+   RECOMMENDED that query sent be left as they are and case folding done 
+   only at the server end.  Some application implementations however do 
+   perform the case folding at the user end.  As the query arrives at 
+   the server, it is still case folded. 
+    
+
+
+  
+Chung & Leung		                                        [Page 4]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+   Case folding for multilingual domain names should follow the existing 
+   implementations for ASCII names, where the application SHOULD and the 
+   server MUST. 
+    
+ 
+3. The Resolution Process 
+    
+   It is inevitable that at the end of the day, the entire DNS chain 
+   SHOULD be updated in order for multilingual domain names to be as 
+   efficiently resolved as names under the current DNS.  DNSII strives 
+   to provide a schema that ultimately brings the system to a desirable 
+   steady state while carefully giving considerations to all the 
+   transition issues.  These include the considerations that at the 
+   application end, there is already a preference and an installed base 
+   of character encoding that may or may not conform to the desires of 
+   the server end operations.  The use of ILET is therefore highly 
+   desirable and essential. 
+    
+    
+3.1 Steady State Resolution 
+    
+   At steady state, the resolution process of multilingual domain names 
+   SHOULD be identical to the existing system.  Additional steps of 
+   going through alphanumeric translation are unnecessary and 
+   undesirable. 
+    
+   With DNSII, the contemplated steady state process resembles the well-
+   known DNS model laid out in RFC1035. 
+    
+    
+                   Local Host                          |    Foreign 
+                                                       | 
+    +---------+                   +----------+         |  +---------+ 
+    |         | user queries      |          |queries  |  |         | 
+    |         |(DNSII identifier  |          |         |  |         | 
+    |         | ILET=UCS without  |          |         |  |         | 
+    |  User   | Transformation)   |          |         |  | Foreign | 
+    | Program |------------------>| Resolver |---------|->| Name    | 
+    |         |                   |          |         |  | Server  | 
+    |         |<------------------|          |<--------|--|         | 
+    |         | user responses    |          |responses|  |         | 
+    |         |                   |          |         |  |         | 
+    +---------+                   +----------+         |  +---------+ 
+                                    |     ^            | 
+                    cache additions |     | references | 
+                                    v     |            | 
+                                  +----------+         | 
+                                  |  cache   |         | 
+                                  +----------+         | 
+    
+    
+   Eventually, an ISO 10646 UCS without transformation is desired as the 
+   common format.  The benefits of having a uniform byte length encoding 
+  
+Chung & Leung		                                        [Page 5]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+   far exceeds the seemingly easier transformation solution.  Especially 
+   considering that the DNS requires a label count that should reflect 
+   the number of characters in a label.  Of course there exists 
+   combination characters in the ISO 10646 specifications as well, but 
+   after canonicalization, only the ones that must use combinations 
+   remain and they are usually meaningful depictions. 
+    
+   The importance of this count value is further demonstrated by 
+   scrambling efforts to extend the size of this field or to compress 
+   character encoding to accommodate multilingual characters.  With 
+   DNSII, this no longer constitutes an issue because any language will 
+   be able to share the same number of characters thanks to the use of 
+   ISO 10646.  As a matter of fact, the desire to use uniform byte 
+   length characters formed part of the original intent of the ISO 10646 
+   initiative anyway. 
+    
+3.2 Client-End or Inquirer Transitional Fall-Back Strategy 
+    
+   For a DNSII aware Client, it will be able to create DNSII packets 
+   which provides precise character data of the domain name in question.  
+   However, if it encounters a non-compliant resolver, it MUST be able 
+   to fallback to a format acceptable by current resolvers. 
+    
+    
+    +---------+                        +----------+  
+    |         | (1) user queries       |          | (2) if Resolver is  
+    |         | (DNSII identifier      |          |  DNSII compliant,  
+    |         |  ILET=UCS without      |          |  Packet is resolved  
+    |  User   |  Transformation)       |          |  accordingly.  If  
+    | Program |----------------------->| Resolver |  not fallback to (3) 
+    |         |                        |          |  
+    |         |<-----------------------|          |  
+    |         | (3) Upon the detection |          |  
+    |         |  of the DNSII Flag     |          | 
+    |         |  resolver will reply   |          | 
+    |         |  with "Format Error"   |          | 
+    |         |                        |          |  
+    |         |----------------------->|          | (5) Current resolu-  
+    |         | (4) Send QNAME using   |          |  tion process begins 
+    |         |  local encoding or     |          |  with the DNSII RR 
+    |         |  UTF-8 with or without |          |  passed along as an 
+    |         |  Additional DNSII RR   |          |  Additional RR 
+    +---------+                        +----------+  
+    
+    
+3.2.1 Tunneling MDNP through DNSII RR 
+    
+   An additional DNSII RR would be tunneled through using the format of 
+   a TXT RR with the RDATA part containing the multilingual labels in a 
+   DNSII compliant format.  The TTL of the RR MUST be set to zero to 
+   avoid caching. 
+    
+
+  
+Chung & Leung		                                        [Page 6]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+   It is not feasible to have a new RR type just for DNSII because the 
+   resolver might reject RRs with unknown types.  For the name used in 
+   the QNAME as well as the NAME field of the DNSII RR UTF-8 MAY be used 
+   as the default fallback encoding.  However, an arbitrary ASCII name 
+   MAY also be used just for the purpose of tunneling.  The TTL for 
+   responses to tunneled requests MUST be set to zero to avoid caching 
+   at any level in the DNS.  More detailed description in Section 3.4. 
+    
+   For older DNS servers, requests with a non-empty additional 
+   information section MAY produce error returns, however since the 
+   deployment of DNSSEC, especially for TSIG considerations, this no-
+   longer constitutes a problem.  Basic security prepared servers such 
+   as BIND 4 or 8 is already capable of bearing the tunneled DNSII RR. 
+    
+   It is possible to use ACE/RACE type translations at this level, 
+   however it is more advisable to use a truly arbitrary label such as 
+   "-for-tunneling-only-".  So doing requires only reserving one 
+   arbitrary name while ACE/RACE creates one more arbitrary name for 
+   each new multilingual name registered, which will eventually 
+   contribute to the fracturing of the DNS. 
+    
+   As an example, a tunneling packet for the domain name: host. —ŒªW¿t™ð
+   .tld. (4host4—ŒªW¿t™ð3 tld0) will be represented as: 
+    
+   (in the QNAME field) 
+    
+                          1 1 1 1 1 1                     1 1 1 1 1 1   
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+     +---------------------------------------------------------------+ 
+   12|0 0|     4     |       h       |       o       |       s       | 
+     +---------------------------------------------------------------+ 
+   16|       t       |      20       |       -       |       f       | 
+     +---------------------------------------------------------------+ 
+   20|       0       |       r       |       -       |       t       | 
+     +---------------------------------------------------------------+ 
+   24|       u       |       n       |       n       |       e       | 
+     +---------------------------------------------------------------+ 
+   28|       l       |       i       |       n       |       g       | 
+     +---------------------------------------------------------------+ 
+   32|       -       |       o       |       n       |       l       | 
+     +---------------------------------------------------------------+ 
+   36|       y       |       -       |       3       |       t       | 
+     +---------------------------------------------------------------+ 
+   40|       l       |       d       |       0       |... 
+     +-----------------------------------------------+ 
+    
+
+
+
+
+
+
+
+  
+Chung & Leung		                                        [Page 7]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+   (The Additional DNSII RR Tunneled in TXT RR form) 
+    
+      :                                                               : 
+      /                                                               / 
+      +---------------------------------------------------------------+ 
+    80|1 1|             12            |        TYPE = TXT = 16        | 
+      +---------------------------------------------------------------+ 
+    84|        CLASS = IN = 1         |              TTL              | 
+      +---------------------------------------------------------------+ 
+    88|              = 0              |        RDLENGTH = 22          | 
+      +---------------------------------------------------------------+ 
+    92|0 0|     4     |       h       |       o       |       s       | 
+      +---------------------------------------------------------------+ 
+    96|       t       |1 0|0 0|       UCS-2=1000      |       4       | 
+      +---------------------------------------------------------------+ 
+   100|1 1|            13             |1 0|z|  ILET=2 |       4       | 
+      +---------------------------------------------------------------+ 
+   104|          —Œ   (U+57DF)        |          ªW    (U+540D)         | 
+      +---------------------------------------------------------------+ 
+   108|          ¿t   (U+7CFB)        |          ™ð    (U+7D71)         | 
+      +---------------------------------------------------------------+ 
+   112|1 1|             38            | 
+      +-------------------------------+ 
+    
+    
+   The reason a DNSII RR is attached is to alert the authoritative DNS 
+   server that the query is DNSII compliant while being able to tunnel 
+   the request through non-compliant resolvers without any loss of 
+   information. 
+    
+3.2.2 Tunneling ILET RRs 
+    
+   Another fallback strategy is to tunnel just the ILET instead of the 
+   entire DNSII label.  If UTF-8 or a local encoding is used as the 
+   QNAME, then the arbitrary ASCII label is no longer necessary.  The 
+   tunneled RR therefore need only consist of an ILET indicating the 
+   encoding format used. 
+    
+   Within the RDATA of an ILET RR masked as a TXT RR the first 4 bytes 
+   will be used to indicate that it is an ILET and the following 4 bytes 
+   to reflect the MIBenum of the encoding used. 
+    
+
+
+
+
+
+
+
+
+
+
+
+  
+Chung & Leung		                                        [Page 8]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+   Following the example given in 3.2.1, the QNAME would be in UTF-8 
+   (MIBenum = 106), while the additional ILET RR would be in the form: 
+    
+      :                                                               : 
+      /                                                               / 
+      +---------------------------------------------------------------+ 
+    80|1 1|             12            |        TYPE = TXT = 16        | 
+      +---------------------------------------------------------------+ 
+    84|        CLASS = IN = 1         |              TTL              | 
+      +---------------------------------------------------------------+ 
+    88|              = 0              |        RDLENGTH = 22          | 
+      +---------------------------------------------------------------+ 
+    92|       I       |       L       |       E       |       T       | 
+      +---------------------------------------------------------------+ 
+    96|       0       |       1       |       0       |       6       | 
+      +---------------------------------------------------------------+ 
+    
+    
+3.3 Resolvers & Server-End Transitional Fallback Strategy 
+    
+   The tunneling scheme described in Section 3.2 assumes that the 
+   authoritative server is fully DNSII compliant.  This assertion is 
+   laid out in Section 4.3 where it is discussed that only fully 
+   compliant servers SHOULD serve multilingual names directly under 
+   their authoritative zone.  In any other case, the arbitrary domain  
+   "-for-tunneling-only-" should result in an NXDomain response. 
+    
+   For security aware servers, an NXT RR of the last name wrapped by its 
+   first name in the zone records will be returned because of the 
+   leading "-" for the tunneling label.  
+    
+   If the application end is not DNSII compliant, the fallback 
+   resolution strategy for resolvers would simply be to pass along the 
+   labels in their 8-bit format and determine the existence of the 
+   requested name as usual.  If a tunneled DNSII RR is detected, by way 
+   of a label constituting entirely of "-for-tunneling-only-" and the 
+   existence of a valid DNSII RR, the resolver should attempt to resolve 
+   the name according to the DNSII specification and tunnel the answer 
+   back to the inquirer. 
+    
+    
+3.3.1 Tunneling MDNP Responses through DNSII ANS RR 
+    
+   To tunnel a DNSII compliant answer through a non-compliant resolver, 
+   another DNSII ANS RR is tunneled.  Also using the TXT RR format as a 
+   mask.  TXT RRs are best used because it is a valid RR and its RDATA 
+   is an unrestricted byte stream determined only by the RDLENGTH.  The 
+   RDATA for a DNSII ANS RR would be the entire content of a regular 
+   response RR attached to a DNSII format name. 
+    
+   Continuing on the example given in Section 3.2, suppose an A record 
+   is requested and the IP address returned for the domain host.—ŒªW¿t™ð
+  
+
+Chung & Leung		                                        [Page 9]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+   .tld. is 123.4.5.6, then an additional DNSII ANS RR (TXT) in the 
+   following form will be included: 
+    
+      :                                                               : 
+      /                                                               / 
+      +---------------------------------------------------------------+ 
+   114|1 1|             12            |        TYPE = TXT = 16        | 
+      +---------------------------------------------------------------+ 
+   118|        CLASS = IN = 1         |              TTL              | 
+      +---------------------------------------------------------------+ 
+   122|              = 0              |         RDLENGTH = 16         | 
+      +---------------------------------------------------------------+ 
+   126|1 1|             92            |          TYPE = A = 1         | 
+      +---------------------------------------------------------------+ 
+   130|        CLASS = IN = 1         |              TTL              | 
+      +---------------------------------------------------------------+ 
+   134|            = 3600             |         RDLENGTH = 4          | 
+      +---------------------------------------------------------------+ 
+   138|      123      |       4       |       5       |       6       | 
+      +---------------------------------------------------------------+ 
+    
+   Note that compression is available in the DNSII RRs.  While the 
+   tunneling TXT mask uses the ASCII tunneling name and therefore points 
+   back to the QNAME at offset 12, the tunneled A Record response uses 
+   the offset corresponding to the DNSII compliant labels at 92.  While 
+   the TTL of the TXT mask MUST be zero, the tunneled A Record RR 
+   contains a regular TTL, in this case 3600. 
+    
+    
+3.3.2 Reinsertion of ILET and DNSII Identifier 
+    
+   When a resolver receives an incoming query with a tunneled DNSII/ILET 
+   RR, it SHOULD reconfigure the query into a fully compliant format 
+   before engaging in further resolution.  If a "00" query is received, 
+   the resolver should convert the label into UTF-8, set the DNSII 
+   identifier "10" on and set the ILET to UTF-8. 
+    
+   In the scenario where the client end is not DNSII compliant, either a 
+   local encoding 8-bit stream or a UTF-8 encoded stream without the 
+   DNSII flag nor ILET will be transported.  During the transition 
+   period, should this occur, the above forced UTF-8 conversion and ILET 
+   insertion would take place and it would be up to the authoritative 
+   server to determine the existence of the requested domain.  InZone 
+   DNSII handling mechanism will serve to take care of these 
+   transitional exceptions. 
+    
+    
+4. DNSII Conformance Levels 
+    
+   DNSII is designed for a smooth transition from the existing ASCII 
+   based DNS to a multilingual capable DNS.  Therefore, it is not 
+   necessary for all servers and applications to be switched to 
+   multilingual capable before starting the deployment. 
+  
+Chung & Leung		                                       [Page 10]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+
+4.1 Application Conformance Levels 
+    
+   The BASIC compliancy for applications would be to remove validity 
+   checks for domain names.  The resolution process will determine a 
+   non-existing domain name, so there really is no need to prevent a DNS 
+   packet with multilingual labels to be sent through the wires. 
+    
+   The INTERMEDIATE compliancy for applications involves the insertion 
+   of the DNSII identifier as well as the ILET according to the local 
+   inputting and screen scheme.  If a user is using a JIS format scheme, 
+   it should set the ILET to reflect it being used.  At the same time, 
+   the tunneling mechanism discussed in Section 3.2 MUST also be in 
+   place. 
+    
+   FULLY compliant applications will send all DNS packets with the DNSII 
+   identifier and the ILET set to UCS-2/4. The fallback scheme discussed 
+   in Section 3.2 MUST also be in place.  InZone DNSII mechanisms SHOULD 
+   also be available to deal with local encoding exceptions. 
+    
+    
+4.2 Resolver Conformance Levels 
+    
+   The BASIC compliancy for resolvers would be to allow an 8-bit clean 
+   approach to name resolution.  Also, it should be made sure that the 
+   additional DNSII RR (TXT) will not be truncated during resolution. 
+    
+   The INTERMEDIATE compliant resolvers MUST understand how to process 
+   the DNSII identifier as well as not reject the ILET.  Interpretation 
+   of the name is not required so it is NOT necessary for the resolvers 
+   to be able to map all or any of the ILET values (with the alternative 
+   approach in DNSII-MDNP, the ILET value corresponds to the byte length 
+   of the characters contained in the label, which makes the count 
+   workable even if the ILET value is not known by the resolver).  In 
+   this scenario caching will be for exact comparison only (label to 
+   label with ILET intact).  The important criteria is for the resolver 
+   to be able to pass along the DNS query to the corresponding 
+   authoritative server and obtain a correct response. 
+    
+   FULLY compliant resolvers will be able to process the DNSII identifer 
+   and know all the ILET values for full function name mapping.  Cache 
+   name lookup will be fully enabled and inquiry fallback mechanism 
+   discussed in Section 3.2.2 SHOULD be performed in the event of 
+   encountering a non-compliant server. 
+    
+    
+4.3 Authoritative Server Conformance Levels 
+    
+   Authoritative servers MUST be fully compliant before attempting to 
+   serve multilingual sub-domains under its authoritative zone.  They 
+   should however prepare for the transition towards a multilingual name 
+   space even if they do not intend to deploy it right away. 
+  
+
+Chung & Leung		                                       [Page 11]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+    
+   The BASIC compliancy for authoritative name servers is to allow an 8-
+   bit clean approach towards sub-domains that are not directly under 
+   its authority (i.e. sub-sub-domains). 
+    
+   The INTERMEDIATE compliant name server will be able to process the 
+   DNSII identifier and ILET without rejecting the query.  The 
+   authoritative zone as well as its direct sub-domains however SHOULD 
+   not include the use of the DNSII flags because ILET values are not 
+   understood at this compliancy level. 
+    
+   FULLY compliant name servers will be able to handle DNSII compliant 
+   label formats at its sub-domain levels.  That is, fully compliant 
+   root servers will be able to serve multilingual TLDs, fully compliant 
+   TLD servers will be able to serve multilingual SLDs, etc. 
+    
+    
+5. Transition Schedule & Strategy 
+    
+   DNSII is designed to allow a gradual adoption of multilingual domain 
+   names on the Internet.  The transition strategy is therefore geared 
+   to be demand-pull instead of a technology-push incentive.  However, 
+   to provide a platform for a demand-pull approach, it is required for 
+   operators to first safeguard their system.  The simple approach as 
+   laid out in Section 4 is to propose that servers take a 8-bit clean 
+   approach on name resolution. 
+    
+   As discussed in DNSII-MDNP, it is reasonable for the deployment of 
+   DNSII-MDNP at the registry level first to draw demand for the service 
+   and let the host level DNSs with multilingual names to begin 
+   migration first.  DNS operators around the world should however 
+   prepare for the transition and begin the deployment of DNSII 
+   depending on their interest in serving multilingual domain names, 
+   according to the conformance levels laid out in Section 4, beginning 
+   from BASIC compliancy for operators that are least interested to a 
+   FULLY compliant server for operators who wishes to provide 
+   multilingual capabilities for their users. 
+    
+   The root servers could easily be adjusted to be a BASIC compliant 
+   authoritative name server.  Once the demand is proven and the 
+   stability of the system tested, they too could transition to fully 
+   compliant authoritative servers so that multilingual TLDs could be 
+   rolled out. 
+    
+    
+6. Summary of Discussion 
+    
+   This document introduces the contemplated transition and steady state 
+   resolution process for multilingual domain names with a DNSII 
+   compliant format.  Two tunneling mechanisms using the TXT RR was 
+   introduced for the preservation of information during transitional 
+   resolution. 
+    
+  
+Chung & Leung		                                       [Page 12]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+6.1 Client/Application Resolution Strategy 
+    
+   Send Query in DNSII format 
+   IF RCODE = Format Error 
+        THEN send query in UTF-8/Local Encoding AND append DNSII RR 
+        IF RCODE = Format Error 
+             THEN send Query in ASCII with "-for-tunneling-only-" label 
+             AND append DNSII RR 
+             AND check for DNSII ANS RR in response 
+        ELSE proceed and check for DNSII ANS RR in response 
+   ELSE proceed as usual 
+    
+    
+6.2 Resolver Resolution Strategy 
+    
+   (*)IF incoming request is in pure DNSII format 
+        THEN resolve according to ILET in cache and by recursive lookup 
+        IF encounter RCODE = Format Error 
+             THEN send query in UTF-8 AND append DNSII RR 
+             IF RCODE = Format Error 
+                  THEN send query in ASCII with "-for-tunneling-only-"  
+                       label 
+                  AND append DNSII RR 
+                  AND check for DNSII ANS RR in response 
+             ELSE proceed and check for DNSII ANS RR in response 
+        ELSE proceed as usual with pure DNSII Format (*) 
+        AND respond in pure DNSII format 
+   ELSE IF incoming request has tunneled MDNP information 
+        THEN resolve using the information in the appended DNSII RR 
+             Reset Query using DNSII Format and go through (*) 
+        AND convert back to tunneling format before responding to query 
+             With DNSII ANS RR appended to response 
+        AND set TTL for regular RRs in the Answer field to be = 0 
+   ElSE IF incoming request is in the original "00" label format 
+        AND no tunneled information is included 
+        AND the label contains characters beyond A-z, 0-9 or "-" 
+        THEN force convert all labels to UTF-8 
+        AND query using DNSII Format and go through (*) 
+   ELSE proceed as usual (existing ASCII based names) 
+    
+    
+6.3 Authoritative Name Server Resolution Strategy 
+    
+   IF incoming request is in pure DNSII format 
+        THEN resolve according to ILET 
+        AND respond in pure DNSII format 
+   ELSE IF incoming request has tunneled MDNP information 
+        THEN resolve using the information in the appended DNSII RR 
+        AND convert back to tunneling format before responding to query 
+             With DNSII ANS RR appended to response 
+        AND set TTL for regular RRs in the Answer field to be = 0 
+   ELSE use InZone DNSII mechanisms AND use 8-bit clean approach 
+    
+  
+Chung & Leung		                                       [Page 13]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+7. Security Considerations 
+    
+   DNSII RRs will be secured through transaction authentication, while 
+   DNSII ANS RRs could have their own SIG RRs.  In general, the DNSII-
+   MDNR should not constitute any extra burden on DNS security. 
+    
+    
+8. Intellectual Property Considerations 
+    
+   It is the intention of Neteka to submit the DNSII protocol and other 
+   elements of the multilingual domain name server software to IETF for 
+   review, comment or standardization. 
+    
+   Neteka Inc. has applied for one or more patents on the technology 
+   related to multilingual domain name server software and multilingual 
+   email server software suite.  If a standard is adopted by IETF and 
+   any patents are issued to Neteka with claims that are necessary for 
+   practicing the standard, any party will be able to obtain the right 
+   to implement, use and distribute the technology or works when 
+   implementing, using or distributing technology based upon the 
+   specific specifications under fair, reasonable and non-discriminatory 
+   terms. 
+    
+   Other DNSII related documents and discussions could be found at 
+   http://www.dnsii.org. 
+    
+9. References 
+ 
+   [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name 
+              Protocol", August 2000 
+    
+   [RFC1700]   J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 
+              1700, October 1994. 
+     
+   [ISO10646] ISO/IEC 10646-1:2000. International Standard -- 
+              Information technology -- Universal Multiple-Octet Coded 
+              Character Set (UCS) 
+    
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and  
+              Facilities," STD 13, RFC 1034, USC/ISI, November 1987 
+       
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and  
+              Specification," STD 13, RFC 1035, USC/ISI, November  
+              1987 
+    
+   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate  
+              Requirement Levels," RFC 2119, March 1997 
+    
+    
+    
+    
+    
+    
+  
+Chung & Leung		                                      [Page 14]
+DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
+ 
+   Authors: 
+    
+   Edmon Chung 
+   Neteka Inc. 
+   2462 Yonge St. Toronto, 
+   Ontario, Canada M4P 2H5 
+   edmon@neteka.com 
+    
+   David Leung 
+   Neteka Inc. 
+   2462 Yonge St. Toronto, 
+   Ontario, Canada M4P 2H5 
+   david@neteka.com 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chung & Leung		                                       [Page 15]
+
+  
+
+
diff --git a/doc/draft/draft-ietf-idn-dnsii-trace-00.txt b/doc/draft/draft-ietf-idn-dnsii-trace-00.txt
new file mode 100644
index 00000000..c6b1e69e
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-dnsii-trace-00.txt
@@ -0,0 +1,636 @@
+Working Group                                 Edmon Chung & David Leung
+Internet Draft                                              Neteka Inc.
+<draft-ietf-idn-dnsii-trace-00.txt>                      September 2000
+ 
+ 
+     DNSII Transitional Reflexive ASCII Compatible Encoding (TRACE) 
+ 
+ 
+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 reader is cautioned not to depend on the values that appear in 
+   examples to be current or complete, since their purpose is primarily 
+   educational.  Distribution of this memo is unlimited. 
+    
+   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 
+    
+   ASCII Compatible Encoding (ACE) schemes should only be used as a 
+   transitional strategy with a well-defined way forward to the eventual 
+   enabling of a truly multilingual name space for the DNS. 
+    
+   The previous DNSII documents surrounding multilingual domain names 
+   have focused on the ultimate form with the DNSII-MDNR suggesting 
+   possible tunneling techniques where ACE may be used.  This document 
+   furthers the discussion on an ACE system, which not only provides a 
+   pathway towards the ultimate DNSII scheme but also an interim 
+   solution taking care of the immediate needs. 
+    
+   A reflexive CNAME process RENAME is introduced where non-ASCII 
+   incoming queries will be automatically CNAMEd to its ASCII 
+   counterpart without requiring an actual lookup.  The resolver will 
+   then be responsible for recursively looking up the corresponding 
+   translated alphanumeric name. 
+    
+   This document does not attempt to create another ACE scheme, instead 
+   it discusses the way an ACE scheme could be used as a transition 
+   towards the ultimate goal of a true multilingual name on the wire. 
+    
+  
+Chung & Leung                                                  [Page 1] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+Table of Contents 
+    
+   1. Introduction....................................................2 
+   1.1 Terminology....................................................2 
+   2. TRACE - Introduced with Due Obsolescence........................3 
+   2.1 Problems & Benefits of ACE.....................................3 
+   2.2 TRACE Format...................................................3 
+   2.3 TRACE Identifier...............................................3 
+   2.4 TRACE Zone Handling............................................4 
+   3. REflexive CNAME (RENAME)........................................4 
+   3.1 Non-Recursive Name Servers with RENAME-ON......................5 
+   3.1 Recursive Name Servers (Resolvers) with RENAME-ON..............6 
+   3.2 Benefits of RENAME.............................................6 
+   3.3 Problems with RENAME...........................................7 
+   4. Use of RENAME with Respect to DNS Hierarchy.....................7 
+   4.1 General Rules for using RENAME.................................8 
+   4.2 Transitioning towards Identification Based DNSII...............8 
+   5. Security Considerations.........................................9 
+   6. Conclusion......................................................9 
+   7. Intellectual Property Considerations...........................10 
+   8. References.....................................................10 
+    
+    
+1. Introduction 
+    
+   ACE usage should be limited to machine read only and steps should be 
+   taken to avoid the user being able to easily input the names through 
+   an application onto the wire.  This is a well-understood concept 
+   because without this requirement, the creation of an ACE system 
+   effectively creates an alternate universe model that is counter to 
+   the spirit of the DNS.  In essence, if an ACE scheme could easily be 
+   typed in, people who are typing that sequence of characters may be 
+   unexpectedly be brought to another site which happens to have the 
+   same "code". 
+    
+   TRACE outlines a scheme that uses an ACE scheme but is identified in 
+   a 7-bit format that could not easily be typed in by a user.  Thereby 
+   preventing an inconsistent expectation of a domain name.  Beyond the 
+   specification of an identifier a RENAME function for an ACE 
+   resolution process is also introduced. 
+    
+    
+1.1 Terminology 
+    
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 
+   and "MAY" in this document are to be interpreted as described in RFC 
+   2119 [RFC2119]. 
+    
+   A number of characters used in this document are in a Big-5 encoding, 
+   you could select your view encoding type to traditional Chinese or 
+   Big-5 for it to be displayed properly. 
+    
+    
+  
+Chung & Leung                                                  [Page 2] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+2. TRACE - Introduced with Due Obsolescence 
+    
+   TRACE is designed to be a transitional scheme with due obsolescence 
+   once a full-fledged DNSII mode is attained. 
+    
+    
+2.1 Problems & Benefits of ACE 
+    
+   One of the major problems with ACE is the evident result of creating 
+   an extra layer on top of the DNS.  DNS was designed to be the human 
+   friendly machine identifier with its names human readable.  With ACE, 
+   it is certain that an added layer is required to decode a domain 
+   name.  This also effectively results in a quasi-alternate universe 
+   mode whereby the actual characters represent a translation into the 
+   existing domain name space. 
+    
+   However, ACE has its benefits as well and the most prominent one is 
+   that host servers need not migrate to new name servers.  Also it will 
+   ensure that there is a lengthy enough migration period for other 
+   applications to start adapting to the new DNS specifications. 
+    
+    
+2.2 TRACE Format 
+    
+   TRACE does not intend to introduce a new type of encoding.  Rather, 
+   it is concerned with using a 7-bit compatible identifier and a 
+   reflexive mechanism for switching from regular DNS packets to TRACE. 
+    
+    
+2.3 TRACE Identifier 
+    
+   In other ACE proposals, identifiers are often created from 
+   alphanumeric characters, which end users can easily type in.  The 
+   problem with this approach is easy to understand, for each 
+   multilingual name, one alphanumeric name must be reserved simply for 
+   the use of the multilingual conversion and will not be available for 
+   normal usage. 
+    
+   For example from Paul Hoffman's draft [RACE-01], the sample 
+   conversion for a value 0x3a27 would result in a string "bq--hitq".  
+   The name "bq--hitq" which is a perfectly usable name on its own must 
+   now be reserved for a multilingual name.  Also, 4 character spaces 
+   will be wasted just for the identifier. 
+    
+   Instead of using an alphanumeric identifier, a single 7-bit compliant 
+   control character is used.  The proposed character is the control 
+   character with the value 0x7F.  With this character, a multilingual 
+   name part could be effectively identified while it would be very 
+   difficult for the average user to enter the character into an 
+   application, thereby avoiding the issue discussed above. 
+    
+   In any case, an ACE form name is not intended for an end user to type 
+   in.  The only reason for ACE is that the current name servers could 
+  
+Chung & Leung                                                  [Page 3] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+   easily handle them.  TRACE provides a simple and effective way which 
+   is 7-bit compliant and a string that is could not be easily imitated. 
+    
+    
+2.4 TRACE Zone Handling 
+    
+   A zone administrator could also easily enter the TRACE Identifier 
+   into the zone file.  To insert the TRACE Identifier in a BIND server, 
+   the administrator could simply append the string "\127" before the 
+   ACE label.  Current BIND servers will understand that "\127" calls 
+   for the character with the value 127 and therefore load it into 
+   memory accordingly.  The BIND should also be reconfigured to set the 
+   options for "check-names" to "ignore". 
+    
+   In the following examples, the ACE format used is simply the hex 
+   value of the corresponding character encoding.  RACE or other ACE 
+   formats or hex of other encoding schemes may be used. 
+    
+   To set up an NS record to ns1.trace.tld and an A record to 123.4.5.6 
+   for the name "ñññ…" <U+4e2d><U+6587> in a BIND server, using UTF-8 
+   (E4B8AD E69687) the following lines are included into the zone file: 
+    
+   \127e4b8ade69687      IN   NS   ns1.trace.tld. 
+   \127e4b8ade69687      IN   A    123.4.5.6 
+    
+   Section 4.3 will discuss a method to prepare the zone file for the 
+   transition into a fully DNSII compliant mode. 
+    
+    
+3. REflexive CNAME (RENAME) 
+    
+   To complement an ACE transition, a reflexive mechanism is introduced.  
+   REflexive CNAME (RENAME) successfully creates a scheme whereby child 
+   DNS nodes could keep using their BIND name servers while be capable 
+   of hosting multilingual domain names. 
+    
+   RENAME is simply a mechanism that attaches an incoming multilingual 
+   name to its ACE counterpart as it enters a RENAME-ON name server.  
+   When to use RENAME is discussed in Section 4. 
+    
+   As an example, if an incoming query contains a the domain name "ññ
+   ñ….tld" <U+4e2d><U+6587>.tld in UTF-8 encoding reaches a RENAME-ON 
+   name server, the following automatic response will be created: 
+    
+   ñññ….tld   IN   CNAME   \127e4b8ade69687.tld 
+    
+   If the server is in non-recursive mode, the RENAMEd name will now be 
+   used for a lookup within the zone and the corresponding response 
+   returned to the inquirer, including the CNAME process.  If the server 
+   is in recursive mode, the RENAMEd name will be used for lookup within 
+   cache and passed on through the DNS hierarchy when not found. 
+    
+    
+  
+Chung & Leung                                                  [Page 4] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+3.1 Non-Recursive Name Servers with RENAME-ON 
+    
+   The two basic modes for a name server includes a non-recursive mode, 
+   which are usually used by registries, root or authoritative host 
+   servers; and a recursive mode, which are usually resolvers installed 
+   in ISPs. 
+    
+   A non-recursive mode server with RENAME-ON would upon receiving a 
+   multilingual name label, automatically CNAME the name to an ACE 
+   format.  If a complete match is found, the response will be passed 
+   back to the inquirer including the CNAME record.  If no direct match 
+   is found, it will pass along either an authoritative NXDomain or the 
+   nearest NS Record in ACE format so that the inquirer may continue its 
+   recursive request. 
+    
+   The following diagram and descriptions details the resolution process 
+   for the domain "www.ñññ….ñññ….tld" or <U+4e2d><U+6587>.<U+4e2d> 
+   <U+6587>.tld, with a DNSII TRACE RENAME-ON server installed at the 
+   Parent domain "ñññ….tld" and a BIND server installed at the Child DNS 
+   domain "ñññ….ñññ….tld": 
+    
+                                                     (3) 
+    +--------+         +------------+         +---------------+ 
+    |        |   (1)   |            |   (2)   |               | 
+    | Client |-------->|  Resolver  |-------->| Parent Domain | ñññ….tld 
+    |        |<--------|            |<--------|  (RENAME-ON)  | 
+    |        |   (8)   |            |   (4)   |               | 
+    +--------+         +------------+         +---------------+ 
+                             ^ |                
+                             | |               (6) 
+                             | |  (5)    +--------------+ 
+                             | +-------->|              | 
+                             +-----------| Child Domain | ñññ….ñññ….tld 
+                                 (7)     | (using BIND) | 
+                                         |              | 
+                                         +--------------+ 
+    
+    
+   (1) A user enters a query for the A record of "www.ñññ….ñññ….tld" or 
+       <U+4e2d><U+6587>.<U+4e2d><U+6587>.tld using an ISO10646 encoding 
+       input. 
+    
+   (2) The DNS recursive resolver arrives at the parent domain "ññ
+       ñ….tld" <U+4e2d><U+6587>.tld 
+    
+   (3) With RENAME-ON and detection that the incoming query is non-ASCII, 
+       the server reflexively assigns the CNAME to the domain: 
+        
+       www.ñññ….ñññ….tld.  IN CNAME  www.\127e4b8ade69687. 
+       \127e4b8ade69687.tld. 
+    
+
+
+  
+Chung & Leung                                                  [Page 5] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+   (4) Since a direct match is not found in the Parent DNS, the closest 
+       NS record is returned to the Resolver, with the CNAME part 
+       included: 
+        
+       www.ñññ….ñññ….tld.   IN CNAME   www.\127e4b8ade69687. 
+       \127e4b8ade69687.tld. 
+        
+       \127e4b8ade69687.\127e4b8ade69687.tld.   IN NS 
+       ns1.\127e4b8ade69687.\127e4b8ade69687.tld. 
+        
+       ns1.\127e4b8ade69687.\127e4b8ade69687.tld.   IN A   123.5.6.7 
+    
+   (5) The recursive resolver passes on the request using the CNAME 
+       record to the Child DNS as: 
+        
+       www.\127e4b8ade69687.\127e4b8ade69687.tld. 
+        
+       Asking for an A record for the corresponding domain. 
+    
+   (6) The Child DNS simply does a regular look up for the domain with 
+       the corresponding response. 
+        
+   (7) Assuming that the correct IP address for www.ñññ….ñññ….tld is 
+       123.6.7.8, the response would be: 
+        
+       www.\127e4b8ade69687.\127e4b8ade69687.tld.   IN A   123.6.7.8 
+    
+   (8) The resolver will then respond to the client request accordingly, 
+       including the CNAME record. 
+    
+    
+3.1 Recursive Name Servers (Resolvers) with RENAME-ON 
+    
+   If the recursive resolver is DNSII compatible and have switched the 
+   RENAME-ON, then both the parent and child DNSs could still run BIND 
+   and be able to serve multilingual names.  As the request goes through 
+   the resolver, it is automatically CNAMEd to the corresponding ACE 
+   format name and passed along for further resolution. 
+    
+   When the corresponding response is obtained, the definite answer 
+   including the CNAME record will both be passed to the client. 
+    
+    
+3.2 Benefits of RENAME 
+    
+   The immediate benefit for using RENAME is that once it is deployed at 
+   a particular DNS level, all its child, or sub-level DNSs could 
+   continue to run a BIND-based or current name server while still be 
+   capable of serving multilingual domain names. 
+    
+   Most ACE implementations expect the client application to begin 
+   migration first.  This is unfortunately would take a long time 
+   because we understand that client end migration may take years to 
+  
+Chung & Leung                                                  [Page 6] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+   complete.  With RENAME however, the migration could be dynamic.  
+   Section 4 explains further how and when RENAME should be used to 
+   complement and facilitate the resolution of multilingual names even 
+   when some of the components are not fully multilingual aware. 
+    
+    
+3.3 Problems with RENAME 
+    
+   RENAME effectively creates an ACE based name space which is 
+   ultimately undesired.  Also, wherever the RENAME function is located, 
+   it will intensify the processing requirements for the machine to 
+   handle the conversion of the incoming multilingual label into an ACE 
+   format and package the CNAME record accordingly. 
+    
+    
+4. Use of RENAME with Respect to DNS Hierarchy 
+    
+   For the discussion within this document, the DNS hierarchy is 
+   summarized into four nodes, beginning with the client end 
+   application, through the resolver, to the root or NIC servers then 
+   finally at the authoritative host for a second-level domain.  This 
+   more or less summarizes the DNS process from the initiation of a 
+   request to the authoritative host. 
+    
+   All together, there are 16 combinations with the basic DNS 
+   environments.  The following chart outlines the different 
+   combinations with the denotations as: 
+    
+    
+   B = B-DNS = Current Bind-based DNS 
+   D = DNSII = DNSII Compliant Name Servers 
+   RENAME(X-X-X-X) = RENAME(Client/application-Resolver-Root/NIC-Host) 
+            with X = ON = RENAME-ON  
+                     FF = RENAME-OFF 
+                     OP = Optional ON/OFF 
+                     NA = Not Applicable 
+     
+   Scenario | Client |Resolver|Root/NIC|  Host  |   RENAME(ON/OFF) 
+   ---------+--------+--------+--------+--------+--------------------- 
+   1)  BBBB | B-DNS  | B-DNS  | B-DNS  | B-DNS  | existing system 
+            +--------+--------+--------+--------+ 
+   2)  BBBD | B-DNS  | B DNS  | B-DNS  | DNSII  | RENAME(NA-NA-NA-FF) 
+            +--------+--------+--------+--------+ 
+   3)  BBDB | B-DNS  | B DNS  | DNSII  | B-DNS  | RENAME(NA-NA-ON-NA) 
+            +--------+--------+--------+--------+ 
+   4)  BDBB | B-DNS  | DNSII  | B DNS  | B-DNS  | RENAME(NA-ON-NA-NA) 
+            +--------+--------+--------+--------+ 
+   5)  DBBB | DNSII  | B-DNS  | B-DNS  | B-DNS  | RENAME(ON-NA-NA-NA) 
+            +--------+--------+--------+--------+ 
+   6)  BBDD | B-DNS  | B-DNS  | DNSII  | DNSII  | RENAME(NA-NA-FF-FF) 
+            +--------+--------+--------+--------+ 
+   7)  DNND | B-DNS  | DNSII  | DNSII  | B-DNS  | RENAME(NA-OP-ON-NA) 
+            +--------+--------+--------+--------+ 
+  
+Chung & Leung                                                  [Page 7] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+   Scenario | Client |Resolver|Root/NIC|  Host  |   RENAME(ON/OFF) 
+   ---------+--------+--------+--------+--------+--------------------- 
+   8)  DDBB | DNSII  | DNSII  | B-DNS  | B-DNS  | RENAME(OP-ON-NA-NA) 
+            +--------+--------+--------+--------+ 
+   9)  DBBD | DNSII  | B-DNS  | B-DNS  | DNSII  | RENAME(ON-NA-NA-FF) 
+            +--------+--------+--------+--------+ 
+   10) BDBD | B-DNS  | DNSII  | B-DNS  | DNSII  | RENAME(NA-ON-NA-FF) 
+            +--------+--------+--------+--------+ 
+   11) DBDB | DNSII  | B-DNS  | DNSII  | B-DNS  | RENAME(ON-NA-OP-NA) 
+            +--------+--------+--------+--------+ 
+   12) BDDD | B-DNS  | DNSII  | DNSII  | DNSII  | RENAME(NA-FF-FF-FF) 
+            +--------+--------+--------+--------+ 
+   13) DDDB | DNSII  | DNSII  | DNSII  | B-DNS  | RENAME(OP-OP-ON-NA) 
+            +--------+--------+--------+--------+ 
+   14) DDBD | DNSII  | DNSII  | B-DNS  | DNSII  | RENAME(OP-ON-NA-FF) 
+            +--------+--------+--------+--------+ 
+   15) DBDD | DNSII  | B-DNS  | DNSII  | DNSII  | RENAME(ON-NA-FF-FF) 
+            +--------+--------+--------+--------+ 
+   16) DDDD | DNSII  | DNSII  | DNSII  | DNSII  | Full DNSII mode 
+            +--------+--------+--------+--------+ 
+    
+    
+4.1 General Rules for using RENAME 
+    
+   As a general rule, RENAME should be turned on whenever there is an 
+   anticipation that further down the DNS hierarchy or resolution 
+   process, a host has not been migrated and is still using existing 
+   name server software.  For example, Scenario(3),(4) or (5) and their 
+   equivalents. 
+    
+   If it is known that the entire set of child hosts is DNSII compliant, 
+   then RENAME is optional even if there exists child sub-sub-domain 
+   host beneath the sub-domain level that uses existing name servers.  
+   For example, Scenario(7) and the sample given in Section 3. 
+    
+   The end host without any more child sub-domains SHOULD never turn on 
+   RENAME.  This consideration is given to reduce the amount of 
+   transition traffic created due to the reflexive answer where no 
+   further resolution is required. 
+    
+    
+4.2 Transitioning towards Identification Based DNSII 
+    
+   Following the DNSII-MDNP recommendations, TRACE could smooth the 
+   transition into a multilingual name space by starting at the registry 
+   level and without requiring the host DNSs to migrate. 
+    
+   As the user-end applications or recursive ISP resolvers began the 
+   migration, new multilingual TLDs could also be introduced even before 
+   the root servers begin any migration. 
+    
+   Eventually, when the root servers migrate, they should be enabled 
+   with both the full DNSII capability with the InPacket Identifier, 
+  
+Chung & Leung                                                  [Page 8] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+   ILET as well as TRACE as a fallback should there be any host DNS 
+   still using existing servers. 
+    
+   From the general rules, we understand that if the entire child DNSs 
+   are DNSII enabled, then the RENAME function of the parent DNS could 
+   be turned off.  This therefore makes way for a very sensible 
+   migration strategy owing to the hierarchical structure of the DNS.  
+   Since a parent DNS must know a glue record for its immediate 
+   children, it is easy for the zone administrator to determine whether 
+   it could turn off the RENAME function for its zone. 
+    
+   While it is understood that gradually, all name servers should 
+   migrate to be DNSII capable and that multilingual names, TRACE 
+   creates a very effective way of monitoring the migration by 
+   encouraging child DNSs to begin transition first followed by upper 
+   and more important levels, up to the root. 
+    
+   A fully DNSII aware server should also be prepared for DNSII queries.  
+   That is, it should be able to process requests containing the DNSII 
+   Identifier and ILET.  As a working example, a Neteka Enhanced BIND 
+   (for a demo copy please mailto:netekare@neteka.com) has been 
+   developed as a demonstration.  To enter a full DNSII label, in the 
+   product, simply duplicate the TRACE identifier and insert a 
+   corresponding ILET.  As an example, for "ñññ….tld" <U+4e2d> 
+   <U+6587>.tld with ILET = 1000 = Unicode, an A record for the IP 
+   address 123.4.5.6 could be added to the zone file as: 
+    
+   \127\12710004e2d6587.tld.   IN  A   123.4.5.6 
+    
+   In such an environment, DNSII aware queries will be answered 
+   accordingly utilizing the "\127\127" record. 
+    
+    
+5. Security Considerations 
+    
+   The implementation of TRACE constitutes no further security burden on 
+   the DNS.  DNSSEC could be used in parallel with TRACE resolution and 
+   records.  RENAME records will be secured through transaction 
+   authentication, while authoritative records will have their own SIG 
+   RRs. 
+    
+   Moreover, the TRACE identifier actually increases the security for 
+   multilingual names over other ACE implementations by using the 0x7F 
+   character, which is difficult for an end user to key in, thereby 
+   reducing the possible confusions. 
+    
+    
+6. Conclusion 
+    
+   With any implementation, the first step towards universal deployment 
+   of a multilingual aware name space should be an 8-bit clean approach.  
+   For current BIND servers it is a simple configuration matter, which 
+   could be set as an option for checknames to be ignored. 
+  
+Chung & Leung                                                  [Page 9] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+    
+   With TRACE, the migration from the current system could be dynamic.  
+   While it is encouraged that the registries begin the migration first 
+   because it is most sensible, client end or recursive resolvers could 
+   also begin the migration. 
+    
+   The use of the control character 0x7F also solves two problems at 
+   once: 1) a 7-bit identifier to avoid disruption of other applications 
+   using DNS; and, 2) an identifier that is not easily input by a client 
+   end user to prevent confusion between a multilingual name and an 
+   English alphanumeric only name. 
+    
+   RENAME successfully creates an environment where host level DNSs 
+   could hold on to their existing BIND based name servers while being 
+   able to host multilingual domains, thereby relieving the migration 
+   stress for hosting facilities and ISPs. 
+    
+    
+7. Intellectual Property Considerations 
+    
+   It is the intention of Neteka to submit the DNSII protocol and other 
+   elements of the multilingual domain name server software to IETF for 
+   review, comment or standardization. 
+    
+   Neteka Inc. has applied for one or more patents on the technology 
+   related to multilingual domain name server software and multilingual 
+   email server software suite.  If a standard is adopted by IETF and 
+   any patents are issued to Neteka with claims that are necessary for 
+   practicing the standard, any party will be able to obtain the right 
+   to implement, use and distribute the technology or works when 
+   implementing, using or distributing technology based upon the 
+   specific specifications under fair, reasonable and non-discriminatory 
+   terms. 
+    
+    
+8. References 
+ 
+   [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name 
+              Protocol", August 2000 
+    
+   [RACE]     P. Hoffman "RACE: Row-based ASCII Compatible Encoding for 
+              IDN", August 31, 2000 
+    
+   [RFC1700]  J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 
+              1700, October 1994. 
+     
+   [ISO10646] ISO/IEC 10646-1:2000. International Standard -- 
+              Information technology -- Universal Multiple-Octet Coded 
+              Character Set (UCS) 
+    
+   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate  
+              Requirement Levels," RFC 2119, March 1997 
+    
+  
+Chung & Leung                                                 [Page 10] 
+
+DNSII-TRACE    DNSII Transitional Reflexive ACE (TRACE)     August 2000  
+ 
+    
+   Authors: 
+    
+   Edmon Chung 
+   Neteka Inc. 
+   2462 Yonge St. Toronto, 
+   Ontario, Canada M4P 2H5 
+   edmon@neteka.com 
+    
+   David Leung 
+   Neteka Inc. 
+   2462 Yonge St. Toronto, 
+   Ontario, Canada M4P 2H5 
+   david@neteka.com 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Chung & Leung                                                 [Page 11] 
diff --git a/doc/draft/draft-ietf-idn-dude-00.txt b/doc/draft/draft-ietf-idn-dude-00.txt
new file mode 100644
index 00000000..86e05d46
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-dude-00.txt
@@ -0,0 +1,596 @@
+Internet Engineering Task Force (IETF)                         Mark Welter
+INTERNET-DRAFT                                          Brian W. Spolarich
+draft-ietf-idn-dude-00.txt                                     WALID, Inc.
+November 16, 2000                                     Expires May 16, 2001
+
+
+              DUDE: Differential Unicode Domain Encoding        
+        
+
+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.
+
+The distribution of this document is unlimited.
+
+Copyright (c) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+This document describes a tranformation method for representing
+Unicode character codepoints in host name parts in a fashion that is 
+completely compatible with the current Domain Name System.  It provides
+for very efficient representation of typical Unicode sequences as
+host name parts, while preserving simplicity.  It is proposed as a 
+potential candidate for an ASCII-Compatible Encoding (ACE) for supporting 
+the deployment of an internationalized Domain Name System.
+
+
+Table of Contents
+
+1.        Introduction
+1.1         Terminology
+2.        Hostname Part Transformation
+2.1         Post-Converted Name Prefix
+2.2         Radix Selection
+2.3         Hostname Prepartion
+2.4         Definitions
+2.5         DUDE Encoding
+2.5.1         Extended Variable Length Hex Encoding
+2.5.2         DUDE Compression Algorithm 
+2.5.3         Forward Transformation Algorithm
+2.6         DUDE Decoding
+2.6.1         Extended Variable Length Hex Decoding
+2.6.2         DUDE Decompression Algorithm
+2.6.3         Reverse Transformation Algorithm
+3.        Examples
+3.1         'www.walid.com' (in Arabic)
+4.        DUDE Extensions
+4.1         Extended DUDE Encoding
+4.1.1         Modified Extended Variable Length Hex Encoding
+4.1.2         Extended Compression Algorithm
+4.1.3         Extended Forward Transformation Algorithm
+4.2         Extended DUDE Decoding
+4.2.1         Modified Extended Variable Length Hex Decoding
+4.2.2         Extended Decompression Algorithm
+4.2.3         Extended Reverse Transformation Algorithm
+5.        Security Considerations
+6.        References
+
+
+1. Introduction
+
+DUDE describes an encoding scheme of the ISO/IEC 10646 [ISO10646]
+character set (whose character code assignments are synchronized
+with Unicode [UNICODE3]), and the procedures for using this scheme
+to transform host name parts containing Unicode character sequences
+into sequences that are compatible with the current DNS protocol
+[STD13].  As such, it satisfies the definition of a 'charset' as
+defined in [IDNREQ].
+
+1.1 Terminology
+
+The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
+"MAY" in this document are to be interpreted as described in RFC 2119
+[RFC2119].
+
+Hexadecimal values are shown preceded with an "0x". For example,
+"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
+shown preceded with an "0b". For example, a nine-bit value might be
+shown as "0b101101111".
+
+Examples in this document use the notation from the Unicode Standard
+[UNICODE3] as well as the ISO 10646 names. For example, the letter "a"
+may be represented as either "U+0061" or "LATIN SMALL LETTER A".
+
+DUDE converts strings with internationalized characters into
+strings of US-ASCII that are acceptable as host name parts in current
+DNS host naming usage. The former are called "pre-converted" and the
+latter are called "post-converted".  This specification defines both
+a forward and reverse transformation algorithm.
+
+
+2. Hostname Part Transformation
+
+According to [STD13], hostname parts must start and end with a letter 
+or digit, and contain only letters, digits, and the hyphen character 
+("-"). This, of course, excludes most characters used by non-English 
+speakers, characters, as well as many other characters in the ASCII 
+character repertoire. Further, domain name parts must be 63 octets or 
+shorter in length.
+
+2.1  Post-Converted Name Prefix
+
+This document defines the string 'dq--' as a prefix to identify 
+DUDE-encoded sequences.  For the purposes of comparison in the IDN 
+Working Group activities, the 'dq--' prefix should be used solely to 
+identify DUDE sequences.  However, should this document proceed beyond 
+draft status the prefix should be changed to whatever prefix, if any,
+is the final consensus of the IDN working group.
+
+Note that the prepending of a fixed identifier sequence is only one
+mechanism for differentiating ASCII character encoded international
+domain names from 'ordinary' domain names.  One method, as proposed in
+[IDNRACE], is to include a character prefix or suffix that does not
+appear in any name in any zone file.  A second method is to insert a
+domain component which pushes off any international names one or more
+levels deeper into the DNS hierarchy.  There are trade-offs between
+these two methods which are independent of the Unicode to ASCII
+transcoding method finally chosen.  We do not address the international
+vs. 'ordinary' name differention issue in this paper.  
+
+2.2  Radix Selection
+
+There are many proposed methods for representing Unicode characters
+within the allowed target character set, which can be split into groups
+on the basis of the underlying radix.  We have chosen a method with
+radix 16 because both UTF-16 and ASCII are represented by even multiples
+of four bits.  This allows a Unicode character to be encoded as a 
+whole number of ASCII characters, and permits easier manipulation of
+the resulting encoded data by humans.  
+
+2.3  Hostname Prepartion
+
+The hostname part is assumed to have at least one character disallowed
+by [STD13], and that is has been processed for logically equivalent 
+character mapping, filtering of disallowed characters (if any), and 
+compatibility composition/decomposition before presentation to the DUDE 
+conversion algorithm.  
+
+While it is possible to invent a transcoding mechanism that relies
+on certain Unicode characters being deemed illegal within domain names
+and hence available to the transcoding mechanism for improving encoding
+efficiency, we feel that such a proposal would complicate matters
+excessively.  We also believe that Unicode name preprocessing for
+both name resolution and name registration should be considered as 
+separate, independent issues, which we will address in a separate 
+document.
+
+2.4  Definitions
+
+For clarity:
+
+  'integer' is an unsigned binary quantity;
+  'byte' is an 8-bit integer quantity;
+  'nibble' is a 4-bit integer quantity.
+
+2.5  DUDE Encoding
+
+The idea behind this scheme is to provide compression by encoding the
+contiguous least significant nibbles of a character that differ from the
+preceding character.  Using a variant of the variable length hex encoding
+desribed in [IDNDUERST] and elsewhere, by encoding leading zero nibbles
+this technique allows recovery of the differential length. The encoding
+is, with some practice, easy to perform manually.
+
+There are two extensions to this basic idea:  one enables encoding the
+preferred case for each charcter (for reverse DNS resolution) and
+another improves the worse case behaviour related to surrogates.  The
+basic algorithms will be formally described first and then the extended 
+algorithms will be described.
+
+2.5.1  Extended Variable Length Hex Encoding
+
+The variable length hex encoding algorithm was introduced by Duerst in 
+[IDNDUERST].  It encodes an integer value in a slight modification of 
+traditional hexadecimal notation, the difference being that the most 
+significant digit is represented with an alternate set of "digits" 
+- -- 'g through 'v' are used to represent 0 through 15.  The result is a 
+variable length encoding which can efficiently represent integers of 
+arbitrary length. 
+
+This specification extends the variable length hex encoding algorithm
+to support the compression scheme defined below by potentially not
+supressing leading zero nibbles.
+
+The extended variable length nibble encoding of an integer, C, 
+to length N, is defined as follows:
+
+  1.  Start with I, the Nth least significant nibble from the least
+      significant nibble of C;  
+
+  2.  Emit the Ith character of the sequence [ghijklmnopqrstuv];
+
+  3.  Continue from the most to least significant, encoding each
+      remaining nibble J by emitting the Jth character of the
+      sequence [0123456789abcdef].
+
+2.5.2  DUDE Compression Algorithm 
+
+  1.  Let PREV = 0;
+
+  2.  If there are no more characters in the input, terminate successfully;
+
+  4.  Let C be the next character in the input;
+
+  5.  If C != '-' , then go to step 5;
+
+  6.  Consume the input character, emit '-', and go to step 2;
+
+  7.  Let D be the result of PREV exclusive ORed with C;
+
+  8.  Find the least positive value N such that 
+        D bitwise ANDed with M is zero
+        where M = the bitwise complement of (16**N) - 1;
+
+  9.  Let V be C ANDed with the bitwise complement of M;
+
+ 10.  Variable length hex encode V to length N and emit the result;
+
+ 11.  Let PREV = C and go to step 2.
+
+
+2.5.3  Forward Transformation Algorithm
+
+The DUDE transformation algorithm accepts a string in UTF-16 
+[ISO10646] format as input.  The encoding algorithm is as follows:
+
+  1.  Break the hostname string into dot-separated hostname parts. 
+      For each hostname part which contains one or more characters
+      disallowed by [STD13], perform steps 2 and 3 below;
+
+  2.  Compress the hostname part using the method described in section
+      2.5.2 above, and encode using the encoding described in section 
+      2.5.1;
+
+  3.  Prepend the post-converted name prefix 'dq--' (see section 2.1
+      above) to the resulting string.
+
+
+2.6  DUDE Decoding
+
+2.6.1  Extended Variable Length Hex Decoding
+
+  Decoding extended variable length hex encoded strings is identical
+to the standard variable length hex encoding, and is defined as 
+follows:
+
+  1.  Let CL be the lower case of the first input character,  
+
+      If CL is not in set [ghijklmnopqrstuv], 
+        return error,
+      else 
+        consume the input character;
+
+  2.  Let R = CL - 'g',
+      Let N = 1;
+
+  3.  If no more input characters exist, go to step 9.
+
+  4.  Let CL be the lower case of the next input character;
+
+  5.  If CL is not in the set [0123456789abcdef], go to Step 9;
+
+  6.  Consume the next input character,
+      Let N = N + 1;
+      Let R = R * 16;
+
+  7.  If N is in set [0123456789], 
+        then let R = R + (N - '0')
+        else let R = R + (N - 'a') + 10;
+
+  8.  Go to step 3;
+
+  9.  Let MASK be the bitwise complement of (16**N) - 1;
+
+ 10.  Return decoded result R as well as MASK.
+
+2.6.2  DUDE Decompression Algorithm
+
+  1.  Let PREV = 0;
+
+  2.  If there are no more input characters then terminate successfully;
+
+  3.  Let C be the next input character;
+
+  4.  If C == '-', append '-' to the result string, consume the character,
+        and go to step 2,
+       
+  5.  Let VPART, MASK be the next variable length hex decoded
+        value and mask;
+
+  6.  If VPART > 0xFFFF then return error status,
+  
+  7.  Let CU = ( PREV bitwise-AND MASK) + VPART,
+      Let PREV = CU;
+
+  8.  Append the UTF-16 character CU to the result string;
+
+  9.  Go to step 2.
+
+      
+2.6.3  Reverse Transformation Algorithm
+
+  1.  Break the string into dot-separated components and apply Steps
+      2 through 4 to each component;
+
+  2.  Remove the post converted name prefix 'dq--' (see Section 2.1);
+
+  3.  Decompress the component using the decompression algorithm
+      described above;
+
+  4.  Concatenate the decoded segments with dot separators and return.
+
+3.  Examples
+
+The examples below illustrate the encoding algorithm and provide
+comparisons to alternate encoding schemes.  UTF-5 sequences are
+prefixed with '----', as no ACE prefix was defined for that encoding.
+
+3.1  'www.walid.com' (in Arabic):
+
+  UTF-16:  U+0645 U+0648 U+0642 U+0639 . U+0648 U+0644 U+064A U+062F .
+           U+0634 U+0631 U+0643 U+0629
+
+  DUDE:    dq--m45oij9.dq--m48kqif.dq--m34hk3i9
+
+  UTF-6:   wq--ymk5k8k2j9.wq--ymk8k4kaif.wq--ymj4j1k3i9
+
+  UTF-5:   ----m45m48m42m39.----m48m44m4am2f.----m34m31m43m29
+
+  RACE:    bq--azcuqqrz.bq--azeeisrp.bq--ay2dcqzj
+
+  LACE:    bq--aqdekscche.bq--aqdeqrckf5.bq--aqddimkdfe
+
+  (more examples to come)
+
+4. DUDE Extensions
+
+The first extension to the DUDE concept recognizes that the first 
+character emitted by the variable length hex encoding algorithm is
+always alphabetic.  We encode the case (if any) of the original Unicode
+character in the case of the initial "hex" character.  Because the DNS
+performs case-insensitive comparisons, mixed case international domain
+names behave in exactly the same way as traditional domain names.
+In particular, this enables reverse lookups to return names in the
+preferred case.
+
+The second extension regards the treatment of Unicode surrogate
+characters.  If surrogates are not expanded, two 16-bit surrogates are 
+needed to represent a single codepoint in the range of 0x10000 
+through 0x10FFFF.  This cuts the worse case limits in half for most
+proposals.  We will assume that our input and output Unicode are in
+UTF-32 format -- that is, any surrogates are expanded to their UCS-4
+equivalents.  If the input codes all fall under 0x10000, then the 
+extended method will emit the same length string as the basic method.
+One final modification takes note of the fact that the only only
+codepoints forcing the use of six hex digits is for those with a "10"
+as the fifth and sixth digits.  We will encode the fifth digit using
+a seventeenth digit as a special case to avoid this extra expansion.
+
+4.1  Extended DUDE Encoding
+
+4.1.1  Modified Extended Variable Length Hex Encoding
+
+The modified extended variable length hex encoding of an integer C to
+length N with case U is performed as follows:
+
+  1.  If C > 0x10FFFF return error status;
+
+  2.  If N < 6 go to step 5;  (this is true for characters from
+                              the first 16 Planes)
+
+  3.  If U is 'Uppercase' then emit 'W'
+        else emit 'w';   (special case for the 17th Plane)
+
+  4.  go to step 7;
+
+  5.  Let I be the Nth nibble from the right of C;
+
+  6.  If U is 'Uppercase'
+        then emit the Ith character of sequence [GHIJKLMNOPQRSTUV],
+        else emit the Ith character of sequence [ghijklmnopqrstuv];
+
+  7.  Let N = N - 1;
+
+  8.  Continue from N to 1, encoding each remaining nibble, J, by
+      emitting the Jth character of sequence [0123456789abcdef].
+
+
+4.1.2  Extended Compression Algorithm
+
+  1.  Let PREV = 0;
+
+  2.  If there are no more characters in the input, terminate successfully;
+
+  4.  Let U be the case of the next character in the input;
+      Let C be the lowercase value of the next input character;
+
+  5.  If C != '-' , then go to step 7;
+
+  6.  Consume the input character, emit '-', and go to step 2;
+
+  7.  Let D be the result of PREV exclusive ORed with C;
+
+  8.  Find the least positive value N such that 
+        D bitwise ANDed with M is zero
+        where M = the bitwise complement of (16**N) - 1;
+
+  9.  Let V = C ANDed with the bitwise complement of M;
+
+ 10.  Emit the modified variable length hex encoding of V to length
+      N with case U;
+
+ 11.  Let PREV = C and go to step 2.
+
+4.1.3  Extended Forward Transformation Algorithm
+
+The overall extended encoding algorithm is as follows:
+
+  1.  Break the hostname string into dot-separated hostname parts. 
+      For each hostname part, perform steps 2 and 3 below;
+
+  2.  Compress the component using the method described in section
+      4.1.2 above, and encode using the encoding described in section 
+      4.1.1;
+
+  3.  Prepend the post-converted name prefix 'dq--' (see section 2.1
+      above) to the resulting string.
+
+4.2 Extended DUDE Decoding
+
+4.2.1  Modified Extended Variable Length Hex Decoding
+
+  1.  Let U be the case of the next input character,
+      Let C0 be the lower case of the next input character;
+
+  2.  If C0 is not in set [ghijklmnopqrstuw] then return error status,
+        else, consume the input character;
+
+  3.  Let R = C0 - 'g'
+      Let N = 1;
+
+  4.  If no more input characters exist then go to step 8;
+
+  5.  Let CL be the lower case of the next input character,
+      If CL is not in set [0123456789abcdef] then go to step 8;
+
+  6.  Consume the next input character,
+      Let N = N + 1,
+      Let R = R * 16,
+      If CL is in set [0-9] 
+        then let R = R + (CL - '0')
+        else let R = R + (CL - 'a') + 10;
+
+  7.  Go to step 4;
+
+  8.  If R < 0x100000 then go to step 10;
+
+  9.  Let N = N + 1,
+      If (N > 6) or (C0 != 'w')
+        then return error status;
+
+ 10.  Let MASK be the bitwise complement of (16**N) - 1.  Return 
+      result R, MASK, and U.
+
+4.2.2  Extended Decompression Algorithm
+
+  1.  Let PREV = 0;
+
+  2.  If there are no more input characters then terminate successfully;
+
+  3.  Let C be the next input character;
+
+  4.  If C == '-', append '-' to the result
+      string, consume the character, and go to step 2;
+
+  5.  Let VPART, MASK, and U be the result of the modified extended
+      variable length decoded value;
+
+  6.  Let CU = (PREV 'bitwise AND' MASK) + VPART,
+      Let PREV = CU;
+
+  7.  If U == 'Uppercase' then let CU = the corresponding upper case value
+      of CU;
+
+  8.  Append CU to the result string and go to step 2.
+
+4.2.3  Extended Reverse Transformation Algorithm
+
+  1.  Break the string into dot-separated components and apply Steps
+      2 through 4 to each component;
+
+  2.  Remove the post converted name prefix 'dq--' (see Section 2.1);
+
+  3.  Decompress the component using the extended decompression 
+      algorithm described in section 4.2.2 above;
+
+  4.  Concatenate the decoded segments with dot separators and return.
+
+Note that DUDE decoding will return error for input strings which do
+not comply with RFC1035.
+
+5. Security Considerations
+
+Much of the security of the Internet relies on the DNS and any
+change to the characteristics of the DNS may change the security of
+much of the Internet. Therefore DUDE makes no changes to the DNS itself.
+
+DUDE is designed so that distinct Unicode sequences map to distinct
+domain name sequences (modulo the Unicode and DNS equivalence rules).
+Therefore use of DUDE with DNS will not negatively affect security.
+
+
+6. References
+
+[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name 
+Proposals", draft-ietf-idn-compare;
+
+[IDNRACE] Paul Hoffman, "RACE: Row-Based ASCII Compatible Encoding for
+IDN", draft-ietf-idn-race;
+
+[IDNREQ] James Seng, "Requirements of Internationalized Domain Names",
+draft-ietf-idn-requirement;
+
+[IDNNAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of 
+Internationalized Host Names", draft-ietf-idn-nameprep;
+
+[IDNDUERST] M. Duerst, "Internationalization of Domain Names",
+draft-duerst-dns-i18n;
+
+[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
+technology -- Universal Multiple-Octet Coded Character Set (UCS) --
+Part 1: Architecture and Basic Multilingual Plane.  Five amendments and
+a technical corrigendum have been published up to now. UTF-16 is
+described in Annex Q, published as Amendment 1. 17 other amendments are
+currently at various stages of standardization; 
+
+[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels", March 1997, RFC 2119;
+
+[STD13] Paul Mockapetris, "Domain names - implementation and
+specification", November 1987, STD 13 (RFC 1035);
+
+[UNICODE3] The Unicode Consortium, "The Unicode Standard -- Version
+3.0", ISBN 0-201-61633-5. Described at
+<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
+
+
+A. Acknowledgements
+
+The structure (and some of the structural text) of this document is 
+intentionally borrowed from the LACE IDN draft (draft-ietf-idn-lace-00) 
+by Mark Davis and Paul Hoffman.
+
+B. IANA Considerations
+
+There are no IANA considerations in this document.
+
+
+C. Author Contact Information
+
+Mark Welter
+Brian W. Spolarich
+WALID, Inc.
+State Technology Park
+2245 S. State St.
+Ann Arbor, MI  48104
++1-734-822-2020
+
+mwelter@walid.com
+briansp@walid.com
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.0.1 (GNU/Linux)
+Comment: For info see http://www.gnupg.org
+
+iD8DBQE6FZ/D/DkPcNgtD/0RAoswAKCUGBTSFJv96+Z+YnA8m47qrnheAgCeLQ6C
+1+knyHluauC+66esCtPVoKU=
+=hbT+
+-----END PGP SIGNATURE-----
+
diff --git a/doc/draft/draft-ietf-idn-icu-00.txt b/doc/draft/draft-ietf-idn-icu-00.txt
new file mode 100644
index 00000000..3d85c6a6
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-icu-00.txt
@@ -0,0 +1,514 @@
+IETF IDN Working Group            Seungik Lee, Hyewon Shin, Dongman Lee
+Internet Draft                                                      ICU
+draft-ietf-idn-icu-00.txt                      Eunyong Park, Sungil Kim
+Expires: 14 January 2001                                KKU, Netpia.com
+                                                           14 July 2000
+
+         Architecture of Internationalized Domain Name System
+
+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.
+
+
+
+1. Abstract
+
+   For restrict use of Domain Name System (DNS) for domain names with 
+   alphanumeric characters only, there needs a way to find an Internet 
+   host using multi-lingual domain names: Internationalized Domain Name 
+   System (IDNS).
+   
+   This document describes how multi-lingual domain names are handled in 
+   a new protocol scheme for IDNS servers and resolvers in architectural 
+   view and it updates the [RFC1035] but still preserves the backward 
+   compatibility with the current DNS protocol.
+
+
+
+2. 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].
+   
+   "IDNS" (Internationalized Domain Name System) is used here to 
+   indicate a new system designed for a domain name service, which 
+   supports multi-lingual domain names.
+   
+   "The current/conventional DNS" or "DNS" (Domain Name System) is used 
+   here to indicate the domain name systems currently in use. It 
+   fulfills the [RFC1034, RFC1035], but implementations and functional 
+   operations may be different from each other.
+   
+   The "alphanumeric" character data used here is the character set that 
+   is allowed for a domain name in DNS query format, [a-zA-Z0-9-]. 
+
+
+
+3. Introduction
+
+   Domain Name System (DNS) has eliminated the difficulty of remembering 
+   the IP addresses. As the Internet becomes spread over all the people, 
+   the likelihood that the people who are not familiar with alphanumeric 
+   characters use the Internet increases. The domain names in 
+   alphanumeric characters are difficult to remember or use for the 
+   people who is not educated English. Therefore, it needs a way to find 
+   an Internet host using multi-lingual domain name: Internationalized 
+   Domain Name System.
+
+
+3.1 The current issues of IDNS
+
+   IDNS maps a name to an IP address as the typical DNS does, but it 
+   allows domain names to contain multi-lingual characters. The multi-
+   lingual characters need to be encoded/decoded into one standardized 
+   format, and it needs changes in the conventional DNS protocol 
+   described in [RFC1034] and [RFC1035]. But it is required to minimize 
+   the changes in the present DNS protocol so that it guarantees the 
+   backward compatibility.
+   
+   The IDNS issues have been discussed in IETF IDN Working Group. These 
+   issues are well described in [IDN-REQ]. The main issues are:
+   
+   - Compatibility and interoperability. The DNS protocol is in use 
+   widely in the Internet. Although a new protocol is introduced for DNS, 
+   the current protocol may be used with no changes. Therefore, a new 
+   design for DNS protocol, IDNS must provide backward compatibility and 
+   interoperability with the current DNS.
+   
+   - Internationalization. IDNS is on the purpose of using multi-lingual 
+   domain names. The international character data must be represented by 
+   one standardized format in domain names.
+   
+   - Canonicalization. DNS indexes and matches domain names to look up a 
+   domain name from zone data. In the conventional DNS, canonicalization 
+   is subjected to US-ASCII only. However, every multi-lingual character 
+   data must be canonicalized in its own rules for a DNS standardized 
+   matching policy, e.g. case-insensitive matching rule.
+   
+   - Operational issues. IDNS uses international character data for 
+   domain names. Normalization and canonicalization of domain names are 
+   needed in addition to the current DNS operations. IDNS also needs an 
+   operation for interoperability with the current DNS. Therefore, it is 
+   needed to specify the operational guidelines for IDNS.
+
+
+3.2 Overview of the proposed scheme
+
+   Our proposed scheme for IDNS is also subjected on the issues 
+   described earlier to fulfill the requirements of IDN [IDN-REQ].
+   
+   The proposed scheme can be summarized as following:
+   
+   - The IN bit, which is reserved and currently unused in the DNS 
+   query/response format header, is used to distinguish between the 
+   queries generated by IDNS servers or resolvers and those of non-IDNS 
+   ones [Oscarsson]. This mechanism is also needed to indicate whether 
+   the query is generated by the appropriate IDNS operations for 
+   canonicalization and normalization or not.
+   
+   - The multi-lingual domain names are encoded into UTF-8 as a wire 
+   format. UTF-8 is recommended as a default character encoding scheme 
+   (CES) in the creation of new protocols which transmit text in 
+   [RFC2130]. This scheme allows the IDNS server to handle the DNS query 
+   from non-IDNS servers or resolvers because the ASCII code has no 
+   changes in UTF-8.
+   
+   - The UTF-8 domain names must be case-folded before transmission. It 
+   minimizes the overhead on server's operations of matching names in 
+   case-insensitive. It also guarantees that the result of caching 
+   queries can be used without any further normalization and 
+   canonicalization. If IDNS server gets non-IDNS query that is not 
+   case-folded, it case-folds the query before transmitting to another 
+   servers.
+
+
+
+4. Design considerations
+
+   Our proposed scheme is designed to fulfill the requirements of IETF 
+   IDN WG [IDN-REQ]. All the methods for IDNS schemes must be approved 
+   by the requirements documents. The design described in this document 
+   is based on these requirements.
+
+
+4.1 Protocol Extensions
+
+   To indicate an IDNS query format, we use an unallocated bit in the 
+   current DNS query format header, named 'IN' bit [Oscarsson]. All IDNS 
+   queries are set IN bit to 1. Without this bit set to 1, we cannot 
+   guarantee that the query is in the appropriate format for IDNS.
+
+   'IN' bit is to indicate whether the query is from IDNS 
+   resolvers/servers or not. It also reduces overhead on canonicalizing 
+   operation at IDNS server. It will be described further in <4.4. 
+   Canonicalization>.
+   
+   We devise new operations and new structures of resolvers and name 
+   servers to add the multi-lingual domain name handling features into 
+   the DNS. This causes changes of all DNS servers and resolvers to use 
+   multi-lingual domain names. The new architectures for resolvers and 
+   servers will be described in <5. Architectures>
+
+
+4.2 Compatibility and interoperability
+
+   The 'IN' bit is valid bit location of query for the conventional DNS 
+   protocol to be set to zero [RFC1035]. And operations and structures 
+   of IDNS preserve the conventional rules of DNS to guarantee the 
+   interoperability with the conventional DNS servers or resolvers so 
+   that the changes are optional. These make this scheme for IDNS 
+   compatible with the current protocol.
+   
+   Although the current DNS protocol uses 7-bit ASCII characters only, 
+   the query format of the current DNS protocol set is 8 bit-clean. 
+   Therefore, we can guarantee the backward compatibility and 
+   interoperability with the current DNS using UTF-8 code because the 
+   ASCII code is preserved with no changes in UTF-8.
+   
+   Note: There are also in use implementations that are compatible with 
+   the current DNS but extend their operations to use UTF-8 domain names. 
+   The IDNS described here interoperates well with these implementations. 
+   The interoperability with these implementations will be described in 
+   <5.4 Interoperability with the current DNS>.
+
+
+4.3 Internationalization
+
+   All international character data must be represented in one 
+   standardized format and the standardized format must be compatible 
+   with the current ASCII-based protocols. Therefore, the coded 
+   character set (CCS) for IDNS protocol must be Unicode [Unicode], and 
+   be encoded using the UTF-8 [RFC2279] character encoding scheme (CES).
+   
+   The client-side interface may allow the domain names encoded in any 
+   local character sets, Unicode, ASCII and so on. But they must be 
+   encoded into Unicode before being used in IDNS resolver. The IDNS 
+   resolver accepts Unicode character data only, and converts it to UTF-
+   8 finally for transmission.
+
+
+4.4 Canonicalization
+
+   In the current DNS protocol, the domain names are matched in case-
+   insensitive. Therefore, the domain names in a query and zone file 
+   must be case-folded before equivalence test.
+   
+   The case-folding issue has been discussed for a long time in IETF IDN 
+   WG. The main problem is for case folding in locale-dependent. Some 
+   different local characters are overlapped within case-folded format. 
+   For example, Latin capital letter I (U+0049) case-folded to lower 
+   case in the Turkish context will become Latin small letter dotless i 
+   (U+0131). But in the English context, it will become Latin small 
+   letter i (U+0069)
+   
+   Therefore, we case-fold the domain names in locale-independent in our 
+   new IDNS design with a method defined in [UTR21].
+   
+   Multi-lingual domain names should be case-folded in IDNS resolvers or 
+   IDNS servers before transmitting to other IDNS/DNS servers. That is, 
+   IDNS resolver should case-fold the domain name and converts it to 
+   UTF-8 before transmission. In case of IDNS server, if it gets a query 
+   with IN bit set to 1, then it needs not to make the multi-lingual 
+   domain name canonicalized anymore. If the IDNS server gets a query 
+   with IN bit set to 0, then it cannot determine the query is 
+   appropriate canonicalized format for IDNS server, so that it case-
+   folds that multi-lingual domain name in the query, and set 'IN' bit 
+   to 1.
+   
+   The current DNS queries contain the original case of domain names to 
+   preserve the original cases. To be consistent with this rule, all 
+   case-folded multi-lingual domain names should be stored by IDNS 
+   resolvers or servers before case-folding, and should be restored 
+   before sending response.
+   
+   In the case of case-folding UTF-8 code, using the case-folding method 
+   in [UTR21], the UTF-8 should be converted to Unicode and it must be 
+   mapped to the mapping table finally. Of course that if we could make 
+   a case-folding mapping table of UTF-8 character data, this overhead 
+   could be reduced.
+   
+   However it cannot avoid an overhead in IDNS servers for 
+   canonicalization, because the canonicalization of international 
+   character data is complicated.
+   
+   To minimize this overhead, we use 'IN' bit to indicate that the 
+   canonicalization for the query has been already handled. That means 
+   it needs not canonicalization operation anymore. The detailed 
+   operations according to the 'IN' bit are described later in <5. 
+   Architectures>.
+   
+   With international character data, the canonicalization (e.g. case-
+   folding) is much more complicated than the one with US-ASCII, and is 
+   different from each other's by their locale contexts.
+   
+   But this document doesn't specify any method or recommendation more 
+   than case-folding. For canonicalization of international character 
+   data, [UTR15] is a good start. It must be discussed further and 
+   specified in the IDNS protocol specification. 
+
+
+4.5 Operational issues
+
+   In the current DNS scheme, it uses only ASCII code for a wire format. 
+   But our new IDNS scheme uses UTF-8 code for a wire format. All the 
+   IDNS resolvers must transmit queries encoded in UTF-8 and case-folded. 
+   This format can be guaranteed by checking the IN bit: if IN bit is 
+   set to 1, the query is encoded in UTF-8 and case-folded. Otherwise 
+   the IDNS server cannot assure that the query is encoded in UTF-8 and 
+   case-folded. Therefore it needs additional operations for encoding to 
+   UTF-8 and case-folding, etc in this case.
+   
+   The current DNS resolvers transmit the queries in ASCII code. But 
+   it's not considerable in IDNS servers because the ASCII code is 
+   preserved with no changes in UTF-8.
+   
+   Some applications and resolvers transmit the queries in UTF-8 
+   although they don't fit on the new IDNS resolvers' structures, e.g. 
+   Microsoft's DNS servers. We cannot guarantee that those queries are 
+   case-folded correctly. Therefore, the IDNS servers should convert 
+   them to appropriate IDNS queries instead of the IDNS resolver in that 
+   case.
+   
+   All detailed operations of IDNS servers and resolvers are described 
+   in <5. Architectures>.
+
+
+
+5. Architectures
+
+
+5.1 New header format
+
+   A new IDNS servers and resolvers must interoperate with the ones of 
+   current DNS. Therefore, we need a way to determine whether the query 
+   is for IDN or not. For this reason, we use a new header format as 
+   proposed in [Oscarsson].
+
+                                         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|IN|AD|CD|   RCODE   |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                    QDCOUNT                    |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                    ANCOUNT                    |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                    NSCOUNT                    |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                    ARCOUNT                    |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+   The IDNS resolvers and servers identify themselves in a query or a 
+   response by setting the 'IN' bit to 1 in the DNS query/response 
+   format header. This bit is defined to be zero by default in the 
+   current DNS servers and resolvers.
+
+
+5.2 Structures of IDNS resolvers
+
+   To use multi-lingual domain names with IDNS servers, all the IDNS/DNS 
+   resolvers must generate the query in a format of UTF-8 or ASCII. The 
+   design of a resolver could be different with each other according to 
+   the local operating systems or applications. We propose new design 
+   guidelines of a resolver for a new standardization. 
+   
+   The IDNS resolver accepts Unicode from user interface for domain 
+   names. The other character sets should be rejected. It encodes all 
+   such character data into UTF-8 for transmission to name servers.
+   
+   The procedures of the operation of an IDNS resolver are below:
+   
+   <1>. If the resolver gets a domain name in Unicode or ASCII then it 
+   stores the original domain name query. Otherwise the request for 
+   lookup is rejected. In the current DNS protocol, the original case of 
+   the domain name should be preserved. Therefore, the resolver must 
+   store the original cases of the domain names before canonicalization 
+   (e.g. case-folding).
+   
+   <2>. Make the domain name case-folded with locale-independent case-
+   mapping table defined in [UTR21].
+   
+   <3>. Convert it to UTF-8.
+   
+   <4>. Set IN bit to 1. It indicates the query is from IDNS resolver 
+   and the format is UTF-8, case-folded.
+    
+   <5>. Send request query to name servers.
+   
+   <6>. Restore the original domain name query into the response query 
+   format.
+   
+   <7>. Send response to the application.
+
+
+5.3 Structures of IDNS servers
+
+   The operation of IDNS server is similar to the current one of DNS 
+   server, but the IDNS server accepts UTF-8 queries and converts them 
+   to the appropriate formats additionally.
+   
+   The IDNS server distinguishes between the IDNS queries and DNS 
+   queries by checking IN bit in the query/response format header. 
+   According to the 'IN' bit, it operates differently.
+   
+   The procedures of the operation of an IDNS server are below:
+   
+   <1>. If the IN bit in the query/response format header is set to 1 
+   then it matches the domain name within zone file data or forwards 
+   request query to resolve. It operates as same as the operations of 
+   the current DNS servers but retrieves UTF-8 code. In this case, it 
+   needs not to make domain name canonicalized because the domain name 
+   is already canonicalized in the previous procedures of IDNS resolvers 
+   or IDNS servers. Go to step <7>.
+   
+   <2>. Set IN bit to 1.
+   
+   <3>. Store the original domain name query.
+   
+   <4>. Make the domain name case-folded with locale-independent case-
+   mapping table defined in [UTR21].
+   
+   <5>. Match the domain name within zone file data or send request 
+   query to lookup.
+   
+   <6>. Restore the original domain name query into the response query 
+   format.
+   
+   <7>. Send response for the query to the resolver or the other server 
+   requested.
+
+
+5.4 Interoperability with the current DNS
+
+   The DNS servers and resolvers accept domain names in ASCII only. But 
+   IDNS servers and resolvers accept domain names in UTF-8. Therefore, 
+   the queries from DNS ones to IDNS ones can be well handled because 
+   the UTF-8 is a superset of ASCII code. But the queries from IDNS ones 
+   to DNS ones will be rejected because the UTF-8 code is beyond the 
+   range of ASCII code.
+   
+   Note: There are some implementations which can handle UTF-8 domain 
+   names although they don't fit on this specification of IDNS and fully 
+   implemented with DNS protocol specification, e.g. Microsoft's DNS 
+   server and resolvers. In this case, we cannot guarantee that the 
+   queries from these 3rd-party implementations are encoded into UTF-8 
+   and well canonicalized. But this queries are set 'IN' bit to 0, so 
+   that the IDNS evaluates whether the domain name is the range of UTF-8 
+   or not, and converts it into UTF-8 and makes it canonicalized finally.
+
+
+
+6. Security Considerations
+
+   This architecture of IDNS uses 8bit-clean queries for transmission 
+   and the UTF-8 code is handled instead of ASCII. The DNS protocol has 
+   already allocated 8bit query format for domain names Therefore, the 
+   IDNS protocol inherits the security issues for the current DNS.
+   
+   Canonicalization of IDNS is defined in [UTR15] and case folding in 
+   [UTR21]. All security issues related with canonicalization or 
+   normalization inherits ones described in [UTR15, UTR21].
+   
+   As always with data, if software does not check for data that can be 
+   a problem, security may be affected. As more characters than ASCII is 
+   allowed, software only expecting ASCII and with no checks may now get 
+   security problems.
+
+
+
+7. References
+
+   [IDN-REQ]    James Seng, "Requirements of Internationalized Domain 
+                Names," Internet Draft, June 2000
+   
+   [KWAN]       Stuart Kwan, "Using the UTF-8 Character Set in the 
+                Domain Name System," Internet Draft, February 2000
+   
+   [Oscarsson]  Dan Oscarsson, "Internationalisation of the Domain Name 
+                Service," Internet Draft, February 2000
+   
+   [RFC1034]	Mockapetris, P., "Domain Names - Concepts and 
+                Facilities," STD 13, RFC 1034, USC/ISI, November 1987
+   
+   [RFC1035]    Mockapetris, P., "Domain Names - Implementation and 
+                Specification," STD 13, RFC 1035, USC/ISI, November 
+                1987
+   
+   [RFC2119]    S. Bradner, "Key words for use in RFCs to Indicate 
+                Requirement Levels," RFC 2119, March 1997
+   
+   [RFC2130]    C. Weider et. Al., "The Report of the IAB Character Set 
+                Workshop held 29 February - 1 March 1996," RFC 2130, 
+                Apr 1997.
+   
+   [RFC2279]    F. Yergeau, "UTF-8, a transformation format of ISO 
+                10646," RFC 2279, January 1998
+   
+   [RFC2535]    D. Eastlake, "Domain Name System Security Extensions," 
+                RFC 2535, March 1999
+   
+   [UNICODE]    The Unicode Consortium, "The Unicode Standard - Version 
+                3.0," http://www.unicode.org/unicode/
+   
+   [UTR15]      M. Davis and M. Duerst, "Unicode Normalization Forms", 
+                Unicode Technical Report #15, Nov 1999, 
+                http://www.unicode.org/unicode/reports/tr15/
+   
+   [UTR21]      Mark Davis, "Case Mappings," Unicode Technical Report 
+                #21, May 2000, 
+                http://www.unicode.org/unicode/reports/tr21
+
+
+8. Acknowledgments
+
+   Kyoungseok Kim <gimgs@asadal.cs.pusan.ac.kr>
+   Chinhyun Bae <piano@netpia.com>
+
+
+
+9. Author's Addresses
+
+   Seungik Lee
+   Email: silee@icu.ac.kr
+   
+   Hyewon Shin
+   Email: hwshin@icu.ac.kr
+   
+   Dongman Lee
+   Email: dlee@icu.ac.kr
+   
+   Information & Communications University
+   58-4 Whaam-dong Yuseong-gu Taejon, 305-348 Korea
+   
+   
+   Eunyong Park
+   Email: eunyong@eunyong.pe.kr
+   Konkuk University
+   93-1 Mojindong, Kwangjin-ku Seoul, 143-701 Korea
+   
+   
+   Sungil Kim
+   Email: clicky@netpia.com
+   Netpia.com
+   35-1 8-ga Youngdeungpo-dong Youngdeungpo-gu Seoul, 150-038 Korea
diff --git a/doc/draft/draft-ietf-idn-idna-00.txt b/doc/draft/draft-ietf-idn-idna-00.txt
new file mode 100644
index 00000000..d70e5910
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-idna-00.txt
@@ -0,0 +1,272 @@
+Internet Draft                                        Paul  Hoffman
+draft-ietf-idn-idna-00.txt                               IMC & VPNC
+September 12, 2000                                 Patrik Faltstrom
+Expires in six months                                         Cisco
+
+         Internationalizing Host Names In Applications (IDNA)
+
+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
+
+The current DNS infrastructure does not provide a way to use
+internationalized host names (IDN). This document describes a mechanism
+that requires no changes to any DNS server or resolver that will allow
+internationalized host names to be used by end users with changes only
+to applications. It allows flexibility for user input and display, and
+assures that host names that have non-ASCII characters are not sent to
+DNS servers or resolvers.
+
+
+1. Introduction
+
+In the discussion of IDN solutions, a great deal of discussion has
+focused on transition issues and how IDN will work in a world where not
+all of the components have been updated. Earlier proposed solutions
+require that user applications, resolvers, and DNS servers to be updated
+in order for a user to use an internationalized host name. Instead of
+this requirement for widespread updating of all components, the current
+proposal is that only user applications be updated; no changes are
+needed to the DNS protocol or any DNS servers or the resolvers on user's
+computers.
+
+1.1 Design philosophy
+
+To date, the proposals for IDN protocols have required that DNS servers
+be updated to handle internationalized host names. Because of this, the
+person who wanted to use an internationalized host name had to be sure
+that their request went to a DNS server that was updated for IDN.
+Further, that server could only send queries to other servers that had
+been updated for IDN because the queries contain new protocol elements
+to differentiate IDN name parts from current host parts. In addition,
+these proposals require that resolvers must be updated to use the new
+protocols, and in most cases the applications would need to be updated
+as well.
+
+Updating all (or even a significant percentage) of the DNS servers in
+the world will be difficult, to say the least. Because of this, we have
+designed a protocol that requires no updating of any name servers. IDNA
+still requires the updating of applications, but once a
+user has updated these, she or he could immediately start using
+internationalized host names. The cost of implementing IDN would thus be
+much lower, and the speed of implementation will be much higher.
+
+1.2 Terminology
+
+The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
+"MAY" in this document are to be interpreted as described in RFC 2119
+[RFC2119].
+
+1.3 IDN summary
+
+Using the terminology in [IDNCOMP],  this protocol specifies an IDN
+architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE),
+and the method for distinguishing ACE name parts from current name parts
+is ace-2.1.1 (add hopefully-unique legal tag). Because there is no
+changes needed to the DNS, the transition strategy is trans-1 (always do
+current plus new architecture).
+
+
+2. Structural Overview
+
+In IDNA, users' applications are updated to perform the processing
+needed to input internationalized host names from users, display
+internationalized host names that are returned from the DNS to users,
+and process the inputs and outputs from the DNS.
+
+2.1 Interfaces between DNS components in IDNA
+
+The interfaces in IDNA can be represented pictorially as:
+
+                 +------+
+                 | User |
+                 +------+
+                     ^
+                     |   Input and display: local interface methods
+                     |   (pen, keyboard, glowing phosphorus, ...)
+    +--------------- v -------------------------------+
+    |         +-------------+                         |
+    |         | Application |                         | End system
+    |         +-------------+
+    |                ^
+    |                |   API call and return: nameprepped RACE
+    |                v
+    |          +----------+
+    |          | Resolver |
+    |          +----------+                           |
+    +----------------^--------------------------------+
+                     |   DNS query and response: nameprepped RACE
+                     v
+              +-------------+
+              | DNS servers |
+              +-------------+
+
+
+2.1.1 Users and applications
+
+Applications can accept host names using any character set or sets
+desired by the application developer, and can display host names in any
+charset. That is, this protocol does not affect the interface between
+users and applications.
+
+An IDNA-aware application can accept and display internationalized host
+names in two formats: the internationalized character set(s) supported
+by the application, and in RACE [RACE] ASCII-compatible encoding.
+Applications MAY allow RACE input and output, but are not encouraged to
+do so except as an interface for advanced users, possibly for debugging.
+RACE encoding is opaque and ugly, and should thus only be exposed to
+users who absolutely need it. The optional use, especially during a
+transition period, of RACE encodings in the user interface is described
+in section 3. Since RACE can be rendered either as the encoded ASCII
+glyphs or the proper decoded character glyphs, the rendering engine for
+an application SHOULD have an option for the user to select the
+preferred display; if it does, rendering the RACE SHOULD NOT be the
+default.
+
+2.1.2 Applications and resolvers
+
+Applications communicate with resolver libraries through a programming
+interface (API). Typically, the IETF does not standardize APIs, although
+it has for IPv6. This protocol does not specify a specific API, but
+instead specifies only the input and output formats of the host names to
+the resolver library.
+
+Before converting the name parts into RACE, the application MUST prepare
+each name part as specified in [NAMEPREP]. The application MUST use RACE
+ASCII-compatible encoding for the name parts that are sent to the
+resolver, and will always get name parts encoded in RACE from the
+resolver.
+
+IDNA-aware applications MUST be able to work with both
+non-internationalized host name parts (those that conform to RFC 1035
+[STD13]) and internationalized host name parts. An IDNA-aware
+application that is resolving a non-internationalized host name parts
+MUST NOT do any preparation or conversion to RACE on any
+non-internationalized name part.
+
+2.1.3 Resolvers and DNS servers
+
+An operating system might have a set of libraries for converting host
+names to nameprepped RACE. 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). The output would
+be either the unchanged name part (if the input already conforms to [STD
+13]), or the nameprepped, RACE-encoded name part. Such a library would
+help keep applications smaller.
+
+DNS servers MUST use the RACE format for internationalized host name
+parts.
+
+If a signalling 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 RACE 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.
+
+2.1.4 Avoiding exposing users to the raw ACE encoding
+
+All applications that might show the user a host name that was received
+from a gethostbyaddr or other such lookup SHOULD update as soon as
+possible in order to prevent users from seeing the ACE. However, this is
+not considered a big problem because so few applications show this type
+of resolution to users.
+
+
+3. Name Server Considerations
+
+It is imperative that there be only one encoding for a particular host
+name. RACE is an encoding for host name parts that use characters
+outside those allowed for host names [STD 13]. Thus, a primary master
+name server MUST NOT contain an RACE-encoded name that decodes to a host
+name that is allowed in [STD 13].
+
+Name servers MUST NOT have any records with host names that contain
+internationalized name parts unless those name parts have be prepared
+according to [NAMEPREP]. If names that are not legal in [NAMEPREP] are
+passed to an application, it will result in an error being passed to the
+application with no error being reported to the name server. Further, no
+application will ever ask for a name that is not legal in [NAMEPREP]
+because requests always go through [NAMEPREP] before getting to the DNS.
+
+The host name data in zone files (as specified by section 5 of RFC 1035)
+MUST be both nameprepped and RACE encoded.
+
+
+4. Root Server Considerations
+
+Because there are no changes to the DNS protocols, adopting this
+protocol has no effect on the root servers.
+
+
+5. Security Considerations
+
+Much of the security of the Internet relies on the DNS. Thus, any change
+to the characteristics of the DNS can change the security of much of the
+Internet.
+
+Host 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 host name.
+
+Because this document normatively refers to [NAMEPREP], it includes the
+security considerations from that document as well.
+
+
+6. References
+
+[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
+Proposals", draft-ietf-idn-compare.
+
+[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
+Internationalized Host Names", draft-ietf-idn-nameprep.
+
+[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
+draft-ietf-idn-race.
+
+[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels", March 1997, RFC 2119.
+
+[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
+10646", January 1998, RFC 2279.
+
+[STD13] Paul Mockapetris, "Domain names - implementation and
+specification", November 1987, STD 13 (RFC 1035).
+
+
+A. Authors' Addresses
+
+Paul Hoffman
+Internet Mail Consortium and VPN Consortium
+127 Segre Place
+Santa Cruz, CA  95060  USA
+phoffman@imc.org
+
+Patrik Faltstrom
+Cisco Systems
+170 West Tasman Drive SJ-13/2
+San Jose, CA 95134  USA
+paf@cisco.com
diff --git a/doc/draft/draft-ietf-idn-idne-01.txt b/doc/draft/draft-ietf-idn-idne-01.txt
new file mode 100644
index 00000000..8abd90dc
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-idne-01.txt
@@ -0,0 +1,441 @@
+Internet Draft                                   Marc Blanchet
+draft-ietf-idn-idne-01.txt                            Viagenie
+July 8, 2000                                     Paul  Hoffman
+Expires in six months                               IMC & VPNC
+
+           Internationalized domain names using EDNS (IDNE)
+
+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
+
+The current DNS infrastructure does not provide a way to use
+internationalized domain names (IDN). This document describes an
+extension mechanism based on EDNS which enables the use of IDN without
+causing harm to the current DNS. IDNE enables IDN host names with a as
+many characters as current ASCII-only host names. It fully supports
+UTF-8 and conforms to the IDN requirements.
+
+
+1. Introduction
+
+Various proposals for IDN have tried to integrate IDN into the current
+limited ASCII DNS. However, the compatibility issues make too many
+constraints on the architecture. Many of these proposals require
+modifications to the applications or to the DNS protocol or to the
+servers. This proposal take a different approach: it uses the
+standardized extension mechanism for DNS (EDNS) and uses UTF-8 as the
+mandatory charset. It causes no harm to the current DNS because it uses
+the EDNS extension mechanism. The major drawback of this proposal is
+that all protocols, applications and DNS servers will have to be
+upgraded to support this proposal.
+
+1.1 Terminology
+
+The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
+"MAY" in this document are to be interpreted as described in RFC 2119
+[RFC2119].
+
+Hexadecimal values are shown preceded with an "0x". For example,
+"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
+shown preceded with an "0b". For example, a nine-bit value might be
+shown as "0b101101111".
+
+Examples in this document use the notation from the Unicode Standard
+[UNICODE3] as well as the ISO 10646 [ISO10646] names. For example, the
+letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER
+A". In the lists of prohibited characters, the "U+" is left off to make
+the lists easier to read.
+
+1.2 IDN summary
+
+Using the terminology in [IDNCOMP],  this protocol specifies an IDN
+architecture of arch-2 (send binary or ACE). The binary format is
+bin-1.1 (UTF-8), and the method for distinguishing binary from current
+names is bin-2.4 (mark binary with EDNS0). The transition period is not
+specified.
+
+
+2. Functional Description
+
+DNS query and responses containing IDNE labels have the following
+properties:
+
+- The string in the label MUST be pre-processed as described in
+[NAMEPREP] before the query or response is prepared.
+
+- The characters in the label MUST be encoded using UTF-8 [RFC2279].
+
+- The entire label MUST be encoded EDNS [RFC2671].
+
+- The version of the IDN protocol MUST be identified.
+
+
+3. Encoding
+
+An IDNE label uses the EDNS extended label type prefix (0b01), as
+described in [RFC2671]. (A normal label type always begin with 0b00). A
+new extended label type for IDNE is used to identify an IDNE label. This
+document uses 0b000010 as the extended label type; however, the label
+type will be assigned by IANA and it may not be 0b000010.
+
+         0                   1                   2
+bits  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    |     Size      |        IDN label ...        |
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
+
+
+ELT: The six-bit extended label type to be assigned by the IANA for an
+IDN label. In this document, the value 0b000010 is used, although that
+might be changed by IANA.
+
+Size: Size (in octets) of the IDN label following. This MUST NOT
+be zero.
+
+IDN label: Label, encoded in UTF-8 [RFC2279]. Note that this label might
+contain all ASCII characters, and thus can be used for host name labels
+that are legal in [STD13].
+
+IDNE labels can be mixed with STD13 labels in a domain name.
+
+The compression scheme in section 4.1.4 of [STD13] is supported as is.
+Pointers can refer to either IDN labels or non-IDN labels.
+
+3.1 Examples
+
+3.1.1 Basic example
+
+The following example shows the label me.com where the "e" in "me" is
+replaced by a <LATIN CAPITAL LETTER E WITH ACUTE>, which is U+00C9. The
+decomposition and downcasing specified in [NAMEPREP] changes the second
+character to <LATIN SMALL LETTER E WITH ACUTE>, U+00E9. This string is
+then transformed using UTF-8 [RFC2279] to 0x6DC3A9.
+
+Ignoring the other fields of the message, the domain name portion of the
+datagram could look like:
+
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      20 | 0  1  0  0  0  0  1  0| 0  0  0  0  0  0  1  1|
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      22 |         0x6D (m)      |       0xC3 (e'(1))    |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      24 |         0xA9 (e'(2))  |       3               |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      26 |         0x63 (c)      |       0x6F (o)        |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      28 |         0x6D (m)      |       0x00            |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+Octet 20 means EDNS extended label type (0b01) using the IDN label
+       type (0b000010)
+Octet 21 means size of label is 3 octets following
+Octet 22-24 are the "m*" label encoded in UTF-8
+Octet 25-28 are "com" encoded as a STD13 label
+Octet 29 is the root domain
+
+3.1.2 Example with compression
+
+Using the previous labels, one datagram might contain "www.m*.com" and
+"m*.com" (where the "*" is <LATIN CAPITAL LETTER E WITH ACUTE>).
+
+Ignoring the other fields of the message, the domain name portions of
+the datagram could look like:
+
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      20 | 0  1  0  0  0  0  1  0| 0  0  0  0  0  0  1  1|
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      22 |         0x6D (m)      |       0xC3 (e'(1))    |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      24 |         0xA9 (e'(2))  |       3               |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      26 |         0x63 (c)      |       0x6F (o)        |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      28 |         0x6D (m)      |       0x00            |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     .    .    .
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      40 |           3           |       0x77 (w)        |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      42 |       0x77 (w)        |       0x77 (w)        |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      44 | 1  1|                20                       |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+The domain name "m*.com" is shown at offset 20. The domain name
+"www.m*.com" is shown at offset 40; this definition uses a pointer to
+concatenate a label for www to the previously defined "m*.com".
+
+
+4. Label Size
+
+In IDNE, the maximum length of a label is 255 octets, and the maximum
+size for a domain name is 1023 octets. The reason for using these values
+is so that IDNE labels can have the same number of characters as the
+ASCII-based labels in [STD13]. Because character encoding in UTF-8 is
+variable length, the maximum octet length for characters expected in the
+foreseeable future (that is, 4 octets for a single character) was used.
+Note that this extension allows some IDNE labels to be longer than 63
+characters and some IDNE names to be longer than 255 octets.
+
+Software creating DNS queries or responses using IDNE MUST verify that,
+after IDN preparation and transformation to UTF8, that no labels are
+longer than 255 octets and that no names are longer than 1023 octets. If
+there is a user interface associated with the process creating the query
+or response, that interface SHOULD give the user an error message.
+
+Software MUST NOT transmit DNS queries or responses which contain labels
+that are longer than 255 octets or names that are longer than 1023
+octets. Servers MUST NOT accept DNS queries or responses which contain
+labels that are longer than 255 octets or names that are longer than
+1023 octets, and MUST send the NOTIMPL RCODE error message if such
+queries or responses are received.
+
+
+5. UDP Packet Size
+
+IDNE-capable senders and receivers MUST support UDP packet sizes of 1220
+octets, not including IP and UDP headers (note that the minimum MTU for
+IPv6 is 1280 [RFC2460]). A sender MUST announce its capability in the
+OPT pseudo-RR described in section 4.3 of [RFC2671] by having the CLASS
+sender's UDP payload size be greater than or equal to 1220.
+
+
+6. Canonalization, Prohibited Characters, and Case Folding
+
+The string in the label MUST be pre-processed as described in [NAMEPREP]
+before the query or response is prepared. A query or response MUST NOT
+contain a label that does not conform to [NAMEPREP].
+
+
+7. Versions of IDNE
+
+The IDN protocol version number MUST be included in the OPT RR RDATA of
+EDNS (described in Section 4.4 of [RFC2671]). An OPTION-CODE will be
+assigned by IANA for storing the IDNE protocol version number; this
+document uses 0x0001 for the OPTION-CODE. The value (that
+is, the OPTION-DATA) is the version number coded in 8 bits.
+
+All requesters MUST send this information as part of the OPT RR included
+in the EDNS packet.
+
+7.1 This version of IDNE
+
+This document describes version 1 of IDNE. This version is a combination
+of the protocol in this document and the rules as described in
+[NAMEPREP]. Note that [NAMEPREP] describes a single version of the list
+of canonicalization, case folding, and prohibited characters, and that
+this document is linked to that single version of [NAMEPREP].
+
+The identifiers for this specification are:
+OPTION-CODE =   0x0001  (IDNE protocol version)
+OPTION-LENGTH = 0x0001  (1 octet following)
+OPTION-DATA =   0x01  (IDNE protocol version 1)
+
+7.2 Creating new versions of IDNE
+
+A new version of IDNE is created by a standards-track RFC that
+specifies:
+
+- a normative reference to [NAMEPREP] or a successor document to
+[NAMEPREP]
+
+- an IDNE version number that is 1 greater than the highest IDNE version
+number at the time the RFC is published
+
+If there are any changes to the encoding or interpretation of the
+protocol, they must also be specified in the same standards-track RFC.
+
+7.3 Prohibited characters and versions of IDNE
+
+If a server receives a request containing an illegal or unknown
+character (as described in the version number in the request), it MUST
+send a NOTIMPL RCODE to the client. For example, if a server that
+understands both version 1 and version 2 receives a request that is
+marked as version 1, but contains a label that includes a character that
+is prohibited in version 1 but allowed in version 2, that server must
+still send a NOTIMPL RCODE to the client.
+
+
+8. API Specifications
+
+The current API for TCP/IP uses gethostbyname and gethostbyaddr for IPv4
+and getnodeipbyname and getnodeipbyaddr (specified in [RFC 2671]) for
+both IPv4 and IPv6. These function calls returns hostent structs, where
+the h_name field contains a pointer to a char. In this context,
+receiving a UTF-8 string mean that the application should know that
+UTF-8 uses more than one octet per char.
+
+A new flag "IDN" (to appear in netdb.h) is defined to be passed in the
+flags argument of getnodeipbynode and getnodeipbyaddr. This flag tells
+the resolver to request an IDNE-encoded name. No new return code is
+defined since the returned codes in RFC 2671 are meaningful in the IDNE
+context.
+
+If one has not yet converted his code to IPv6 and still wants to enable
+IDNs with this API, one can do a macro of the getnodeipby* functions
+mapped to the IPv4 gethostby* ones, including the "IDN" flag, and then
+process differently based on the presence of the flag.
+
+
+9. Transition and Deployment
+
+Deployment of this proposal means updating clients and servers, as well
+as applications and protocols, and therefore a transition strategy is
+proposed. Because many DNS servers do not yet handle IDNE and may take
+years or decades to do so, an ASCII-compatible encoding (ACE) format for
+IDN names is also needed as a transition to an all-IDNE DNS. Note that
+IDNE and an ACE are not related, and do not interact in the DNS. If the
+IETF chooses to have an ACE mechanism in use at the same time as IDNE,
+it would be wise to choose an ACE that allows as many characters as
+possible in the name parts and full names.
+
+IDNE allows names with as many characters as current names. This means
+that it is possible to create names in IDNE that are longer than those
+that can be created in the ACE protocols that have been described so
+far. Although not prohibited, it is unwise to create a name that can be
+legally represented in IDNE but not in the ACE, or a name that can be
+legally represented in the ACE but not in IDNE.
+
+The IETF should periodically evaluate the benefits and problems
+associated with having three different formats for names (STD13, IDNE,
+and ACE). If at some point it is decided that the problems outweigh the
+benefits, the IETF can state a time when one or more of the services
+should not be used on the Internet.
+
+
+10. Root Server Considerations
+
+Because this specification uses EDNS, root servers should be prepared to
+receive EDNS requests. This specification handles IDN top-level domains
+in exactly the same fashion as it does every other domain.
+Considerations about IDN top-level domains are outside of this work, but
+the first IDN top-level domains would require all root servers to be
+ready for IDNE requests.
+
+
+11. IANA Considerations
+
+[[ TBD. This section will have two parts. The first will request an EDNS
+option code. The second will specify how IDNE version numbers are
+allocated (namely, standards-track RFC only). ]]
+
+
+12. Security Considerations
+
+Because IDNE uses EDNS, it inherits the same security considerations as
+EDNS.
+
+Much of the security of the Internet relies on the DNS. Thus, any change
+to the characteristics of the DNS can change the security of much of the
+Internet.
+
+Host 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 host name.
+
+Because this document normatively refers to [NAMEPREP] and [RFC2671],
+it includes the security considerations from those documents as well.
+
+
+13. References
+
+[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
+Proposals", draft-ietf-idn-compare.
+
+[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
+technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part
+1: Architecture and Basic Multilingual Plane.  Five amendments and a
+technical corrigendum have been published up to now. UTF-16 is described
+in Annex Q, published as Amendment 1. 17 other amendments are currently
+at various stages of standardization. [[[ THIS REFERENCE NEEDS TO BE
+UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
+
+[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
+Internationalized Host Names", draft-ietf-idn-nameprep.
+
+[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels", March 1997, RFC 2119.
+
+[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
+10646", January 1998, RFC 2279.
+
+[RFC2460] Steve Deering & Bob Hinden, "Internet Protocol, Version 6 (IPv6)
+Specification", December 1998, RFC 2460.
+
+[RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", August
+1999, RFC 2671.
+
+[STD13] Paul Mockapetris, "Domain names - implementation and
+specification", November 1987, STD 13 (RFC 1035).
+
+[UNICODE3] The Unicode Consortium, "The Unicode Standard -- Version
+3.0", ISBN 0-201-61633-5. Described at
+<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
+
+
+A. Acknowledgements
+
+This document is the result of the thinking of many people. The following
+people made significant comments on the early drafts:
+
+Andre Cormier
+Andrew Draper
+Bill Sommerfeld
+Francois Yergeau
+
+
+B. Changes from -00 to -01
+
+1.1: Added reference to Unicode names.
+
+3: Clarified that a size of zero is not allowed.
+
+3.1.1 and 3.1.2: Fixed two very serious errors in the examples.
+
+6: Removed second paragraph, which was redundant with 7.3.
+
+12: Beefed up the security considerations.
+
+13: Added [ISO10646] and [UNICODE3].
+
+Added Appendix A.
+
+Added Appendex B.
+
+
+C. Authors' Addresses
+
+Marc Blanchet
+Viagenie
+2875 boul. Laurier, bureau 300
+Sainte-Foy, QC  G1V 2M2 Canada
+Marc.Blanchet@viagenie.qc.ca
+
+Paul Hoffman
+Internet Mail Consortium and VPN Consortium
+127 Segre Place
+Santa Cruz, CA  95060 USA
+phoffman@imc.org
+
+
diff --git a/doc/draft/draft-ietf-idn-idnra-00.txt b/doc/draft/draft-ietf-idn-idnra-00.txt
new file mode 100644
index 00000000..d13e858d
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-idnra-00.txt
@@ -0,0 +1,334 @@
+Internet Draft                                        Paul  Hoffman
+draft-ietf-idn-idnra-00.txt                              IMC & VPNC
+August 17, 2000                                    Patrik Faltstrom
+Expires in six months                                         Cisco
+
+                 Internationalized Host Names
+           Using Resolvers and Applications (IDNRA)
+
+
+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
+
+The current DNS infrastructure does not provide a way to use
+internationalized host names (IDN). This document describes a mechanism
+that requires no changes to any DNS server that will allow
+internationalized host names to be used by end users with changes only
+to resolvers and applications. It allows flexibility for user input and
+display, and assures that host names that have non-ASCII characters are
+not sent to servers.
+
+
+1. Introduction
+
+In the discussion of IDN solutions, a great deal of discussion has
+focused on transition issues and how IDN will work in a world where not
+all of the components have been updated. Earlier proposed solutions
+require that user applications, resolvers, and DNS servers to be updated
+in order for a user to use an internationalized host name. Instead of
+this requirement for widespread updating of all components, the current
+proposal is that only user applications and the resolvers on user's
+systems be updated; no changes are needed to the DNS protocol or any DNS
+servers. We also show that it is enough to update only the application,
+and at the same time an encoded version of the host name can be used
+even in current existing applications.
+
+The proposal is called IDNRA because it only requires changes to
+resolvers and applications (the "R" and "A" in the name).
+
+1.1 Design philosophy
+
+To date, the proposals for IDN protocols have required that DNS servers
+be updated to handle internationalized host names. Because of this, the
+person who wanted to use an internationalized host name had to be sure
+that their request went to a DNS server that was updated for IDN.
+Further, that server could only send queries to other servers that had
+been updated for IDN because the queries contain new protocol elements
+to differentiate IDN name parts from current host parts. In addition,
+these proposals require that resolvers must be updated to use the new
+protocols, and in most cases the applications would need to be updated
+as well.
+
+Updating all (or even a significant percentage) of the DNS servers in
+the world will be difficult, to say the least. Because of this, we have
+designed a protocol that requires no updating of any name servers. IDNRA
+still requires the updating of applications and resolvers, but once a
+user has updated these, she or he could immediately start using
+internationalized host names. The cost of implementing IDN would thus be
+much lower, and the speed of implementation will be much higher.
+
+IDNRA also specifies how to use old applications and/or old resolvers in
+parallel with updated ones.
+
+1.2 Terminology
+
+The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
+"MAY" in this document are to be interpreted as described in RFC 2119
+[RFC2119].
+
+1.3 IDN summary
+
+Using the terminology in [IDNCOMP],  this protocol specifies an IDN
+architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE),
+and the method for distinguishing ACE name parts from current name parts
+is ace-2.1.1 (add hopefully-unique legal tag). Because there is no
+changes needed to the DNS, the transition strategy is trans-1 (always do
+current plus new architecture).
+
+
+2. Structural Overview
+
+In IDNRA, users' applications and resolvers are updated to perform the
+processing needed to input internationalized host names from users,
+display internationalized host names that are returned from the DNS to
+users, and process the inputs and outputs from the DNS.
+
+2.1 Interfaces between DNS components in IDNRA
+
+The interfaces in IDNRA can be represented pictorially as:
+
+                +------+
+                | User |
+                +------+
+                    ^
+                    |   Input and display: any charset
+                    v
+             +-------------+
+             | Application |
+             +-------------+
+                    ^
+                    |   API call and return: UTF-8
+                    v
+              +----------+
+              | Resolver |
+              +----------+
+                    ^
+                    |   DNS query and response: RACE
+                    v
+             +-------------+
+             | DNS servers |
+             +-------------+
+
+2.1.1 Users and applications
+
+Applications can accept host names using any character set or sets
+desired by the application developer, and can display host names in any
+charset. That is, this protocol does not affect the interface between
+users and applications.
+
+An IDNRA-aware application can accept and display internationalized host
+names in two formats: the internationalized character set(s) supported
+by the application, and in RACE [RACE] ASCII-compatible encoding.
+Applications MAY allow RACE input and output, but are not encouraged to
+do so except as an interface for advanced users, possibly for debugging.
+RACE encoding is opaque and ugly, and should thus only be exposed to
+users who absolutely need it. The optional use, especially during a
+transition period, of RACE encodings in the user interface is described
+in section 3.
+
+2.1.2 Applications and resolvers
+
+Applications communicate with resolver libraries through a programming
+interface (API). Typically, the IETF does not standardize APIs, although
+it has for IPv6. This protocol does not specify a specific API, but
+instead specifies only the input and output formats of the host names to
+the resolver library.
+
+This protocol specifies that host names SHOULD be passed to resolvers
+using UTF-8 [RFC2279] because there are many libraries for converting
+between arbitrary charsets and UTF-8. However, because the API is not
+specified in this document, some resolvers may use different charsets
+for input and output, and applications must, of course, use the same
+charset as the resolver library they call.
+
+IDNRA-aware applications MUST be able to work with both IDNRA-aware and
+non-aware resolvers. An IDNRA-aware application that is resolving a
+non-internationalized host name (one that conforms to RFC 1035[STD13])
+MUST use non-aware APIs such as "gethostbyname" and "gethostbyaddr". An
+IDNRA-aware application that is resolving a internationalized host name
+(one that does not conform to RFC 1035) MUST use an API that is specific
+to IDNRA.
+
+2.1.3 Resolvers and DNS servers
+
+Before converting the name parts into RACE, the resolver MUST prepare
+each name part as specified in [NAMEPREP]. The resolver MUST use RACE
+ASCII-compatible encoding for the name parts that are sent in the DNS
+query, and will always get name parts encoded in RACE from the DNS
+service. DNS servers MUST use the RACE format for internationalized host
+name parts.
+
+If a signalling 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 RACE 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.
+
+
+3. Combinations of Resolvers and Applications
+
+IDNRA allows non-IDNRA applications to coexist with IDNRA-aware
+resolvers, and non-IDNRA resolvers to coexist with IDNRA-aware
+applications. This section describes the interactions between
+applications and resolvers as users update each separately.
+
+In this section, "old" means an application or resolver that has not bee
+upgraded to be IDNRA-aware, and "new" means an IDNRA-aware application
+or resolver. The two APIs are also called "old" and "new". "Binary"
+means any host name that is not compatible with current DNS character
+restrictions.
+
+3.1 Old application, old resolver
+
+Because it is an old resolver (and an old application), all host names
+MUST (and will) be resolved using the old API. A user cannot enter
+binary names in the application. A user MAY enter a name that uses RACE
+encoding. Each RACE-encoded name part in such a name MUST already have
+had all name preparation done on it and be correctly converted to RACE
+encoding; otherwise, it will not be matched in the DNS.
+
+When the resolver receives a RACE name in a response to a old API
+gethostbyaddr-type query, the resolver will not convert the host name to
+a binary form, and the application will thus display the name in RACE
+format. Showing the results of a gethostbyaddr-type queries is rare in
+typical Internet applications, so the display of RACE names is not
+likely in typical environments.
+
+3.2 Old application, new resolver
+
+Because it is an old application, all host names MUST (and will) be
+resolved using the old API. A user cannot enter binary names in the
+application. A user MAY enter a name that uses RACE encoding. Each
+RACE-encoded name part in such a name MUST already have had all name
+preparation done on it and be correctly converted to RACE encoding;
+otherwise, it will not be matched in the DNS. Note that, even though the
+resolver is new, the resolver MUST NOT do further name preparation on
+RACE-encoded name parts because the call was using the old API, which
+tells the resolver that the resolver is dealing with an old application.
+
+If the resolver receives a RACE name in a response to a old API
+gethostbyaddr-type query, the resolver MUST NOT convert the host name to
+a binary form, and the application will thus display the name in RACE
+format. Showing the results of a gethostbyaddr-type queries is rare in
+typical Internet applications, so the display of RACE names is not
+likely in typical environments.
+
+3.3 New application, old resolver
+
+Because it is an old resolver, all host names MUST (and will) be
+resolved using the old API. If the user enters a binary host name, the
+application SHOULD reject the name as illegal. This is due to the fact
+that, if the application did not reject the name as illegal, the
+application would have to contain all of the name preparation logic and
+RACE-encoding logic, but that logic would only be used in the rare case
+where a user had updated applications but not the resolver. It is likely
+that applications would not fully implement and rigorously test the name
+preparation logic, and it is therefore likely that some applications in
+this scenario would give incorrect information to the user, and would
+possibly be susceptible to spoofing attacks. If an application is going
+allow the input of binary names and convert them to their RACE-encoded
+form for use on the old API, the application MUST do full name
+preparation exactly as it would have been done in a new resolver.
+
+If the application receives a RACE-encoded name part in a response to a
+old API gethostbyaddr-type query, the application SHOULD convert the
+host name to a binary form for display. However, the application MAY
+have an interface that allows the display of RACE names that are
+returned by gethostbyaddr-type queries, but the default setting of such
+an interface SHOULD be to show the binary form, not the RACE form.
+
+3.4 New application, new resolver
+
+All host names MUST be resolved using the new API. A user MAY enter a
+name that uses RACE encoding. Each RACE-encoded name part in such a name
+MUST already have had all name preparation done on it and be correctly
+converted to RACE encoding; otherwise, it will not be matched in the
+DNS.
+
+When the resolver receives a RACE name in a response to a
+gethostbyaddr-type query, if the query was to the old API, the resolver
+MUST NOT convert the host name and MUST pass the RACE-formatted name to
+the application. If the query was to the new API, the resolver MUST
+convert the host name part to the binary form. The application MAY have
+an interface that allows the user to decide whether to use the old or
+new API, and therefore to show the results in RACE or binary format, but
+the default setting of such an interface SHOULD be to use the new API.
+
+
+4. Root Server Considerations
+
+Because there are no changes to the DNS protocols, adopting this
+protocol has no effect on the root servers.
+
+
+5. Security Considerations
+
+Much of the security of the Internet relies on the DNS. Thus, any change
+to the characteristics of the DNS can change the security of much of the
+Internet.
+
+Host 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 host name.
+
+Because this document normatively refers to [NAMEPREP], it includes the
+security considerations from that document as well.
+
+
+6. References
+
+[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
+Proposals", draft-ietf-idn-compare.
+
+[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
+Internationalized Host Names", draft-ietf-idn-nameprep.
+
+[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
+draft-ietf-idn-race.
+
+[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels", March 1997, RFC 2119.
+
+[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
+10646", January 1998, RFC 2279.
+
+[STD13] Paul Mockapetris, "Domain names - implementation and
+specification", November 1987, STD 13 (RFC 1035).
+
+
+A. Authors' Addresses
+
+Paul Hoffman
+Internet Mail Consortium and VPN Consortium
+127 Segre Place
+Santa Cruz, CA  95060  USA
+phoffman@imc.org
+
+Patrik Faltstrom
+Cisco Systems
+170 W Tasman Drive SJ-13/2
+San Jose, CA 9 5134  USA
+paf@cisco.com
diff --git a/doc/draft/draft-ietf-idn-iptr-01.txt b/doc/draft/draft-ietf-idn-iptr-01.txt
new file mode 100644
index 00000000..9e9f3ec7
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-iptr-01.txt
@@ -0,0 +1,600 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                                Hongbo Shi
+draft-ietf-idn-iptr-01.txt                             Waseda University
+17 November 2000                                        Jiang Ming Liang
+Expires: 17 May 2001                                           i-DNS.net
+
+
+              Internationalized PTR Resource Record (IPTR)
+
+
+
+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 draft attempts to address the problem of how an IP address SHOULD
+  be properly mapped to a set of Internationalized Domain Names(IDNs).
+  It is currently unspecified how a PTR record can be used for this
+  purpose.  In addition, the syntax of the PTR resource record may be
+  too restrictive for such a mapping in a more culturally meaningful
+  context.  This document suggests a new TYPE called IPTR using EDNS0
+  and a mechanism to combined language information with such a mapping.
+
+1. Introduction
+
+  Reverse mapping is a very important and essential function in the DNS.
+  In today's Domain Name System, PTR RRs are used to support address-
+  to-domain mappings. However, a current PTR RR does not provide support
+  for proper address-to-IDN mappings, without certain modifications.
+  Modifying the PTR structure will also affect the current reverse
+
+
+
+Shi, Jiang                                                      [Page 1]
+
+
+
+
+
+INTERNET-DRAFT   Internationalized PTR Resource Record      14 Nov. 2000
+
+
+  mapping architecture. This document describes a new RR TYPE named IPTR
+  to provide address-to-IDN mappings and it also specifies that on
+  receiving of a IPTR query a name server should respond with all the
+  corresponding IPTR RRs in one response. In short, "one IP several
+  IDNs".
+
+1.1 Terminology
+
+  The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+  and "MAY" in this document are to be interpreted as described in RFC
+  2119 [RFC2119].
+
+1.2 Background and Designs
+
+  When Internationalized Domain Names come into wide use, an Internet
+  host is likely to have domain names in different languages.  In
+  today's Internet, even thought the [RFC2181] redefine the
+  consideration of PTR, because of the design of the PTR mapping
+  algorithm and implementation of most resolvers, IP address to domain
+  names mapping is still limited to "one IP one domain name".
+
+  For example, BIND treats PTRs specially so that the normal sorting
+  preference (e.g. cyclic/random) doesn't apply. But as usual, "fixed"
+  order is always used. So a client that is querying a BIND server and
+  doesn't look beyond the first PTR RR, no matter how many times it
+  queries the name. In other words, PTR RRset is different from A RRset,
+  where the first record in the RRset might differ from query to query.
+
+  This is more restrictive in a world of IDNs, for choosing some names
+  in a particular language. Briefly, according to the use of PTR, it is
+  no meaning of returning an IDN in an unknown language.
+
+  The authors also believe that putting language information into
+  address-to-name mappings will be benifitial to future applications.
+
+  The design purpose of the IPTR RR type is to provide a mechanism that
+  can map an IP address to the corresponding IDN per language. It also
+  means that IPTR suggests a new mapping algorithm for the reverse
+  mapping by using an language information.
+
+  CNAME MUST continue to work for IPTR as it works now for PTR records.
+
+  The behavior of a resolver on the use of IPTR will be specified in a
+  seperate draft or a later version of this draft.
+
+1.3 Functional Description
+
+  DNS query and responses involving IPTR type MUST have the following
+
+
+
+Shi, Jiang                                                      [Page 2]
+
+
+
+
+
+INTERNET-DRAFT   Internationalized PTR Resource Record      14 Nov. 2000
+
+
+  properties:
+
+
+       - When the QTYPE is IPTR, the corresponding IDNs SHOULD be
+         returned in one response.
+
+
+       - The characters in the label MUST be encoded using UTF-8
+         [RFC2279].
+
+
+       - The entire label MUST be encoded EDNS [RFC2671].
+
+
+       - An exceptional handling of PTR for the IDN is REQUIRED.
+
+
+2. IPTR definition
+
+  The structure of an IPTR RR is somewhat like the MX RR.  In addtion to
+  the IP address in the IN-ADDR.ARPA domain and the domain name field
+  (similar to a PTR RR), a new field called LANGUAGE has been defined.
+  A domain name in an IPTR RR MUST be encoded in UTF8.  And IDN in this
+  document MUST be NAMEPREPPED. [NAMEPREP] Below is an example of an
+  IPTR RR:
+
+   1.2.3.4.IN-ADDR.ARPA.    IPTR  "LANGUAGE" "name-in-utf8"
+
+  [RFC1766] describes the ISO 639/ISO 3166 conventions.  A language name
+  is always written in lower case, while country codes are written in
+  upper case. At here, the "LANGUAGE" field in an IPTR RR SHOULD be done
+  in a case-insensitive manner and MUST follow the conventions defined
+  in [RFC1766].
+
+  For Example:
+
+   4.3.2.1.IN-ADDR.ARPA.            IPTR     "zh-CN"   "name-in-utf8"
+   4.3.2.1.IN-ADDR.ARPA.            IPTR     "zh-TW"   "name-in-utf8"
+   4.3.2.1.IN-ADDR.ARPA.            IPTR     "ja-JP"   "name-in-utf8"
+   4.3.2.1.IN-ADDR.ARPA.            IPTR     "ko-KR"   "name-in-utf8"
+
+  The notion of canonical names and aliases described in 3.6.2
+  [RFC1034], and 10.2 [RFC2181] MUST be preserved for IPTR record types.
+  An IPTR RR SHOULD be limited to one primary IDN per LANGUAGE, similar
+  to the a PTR RR.
+
+3. IPTR on IPv6
+
+
+
+
+Shi, Jiang                                                      [Page 3]
+
+
+
+
+
+INTERNET-DRAFT   Internationalized PTR Resource Record      14 Nov. 2000
+
+
+  Mapping IPv6 to IDNs can be similarly supported. This document recom-
+  mands to continue using the IP6.INT domain defined in [RFC1886] for
+  IPTR mappings.  For example, the lookup 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.
+  IPTR  "LANGUAGE" "name-in-utf8"
+
+4. Packet format for IPTR
+
+  EDNS0[RFC2671] is REQUIRED to implement IPTR.
+
+
+       0                   1       2       3                   4
+  bits 0 1 2 3 4 5 6 7 8 9 0 1...9 0...8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 ...
+      +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+
+      |0 1|    ELT    |   LANGUAGE    |      Size     | IDN label... |
+      +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+
+
+     LANGUAGE: An argument for IPTR to define the kind of language
+               used in the following IDN label. The size is 2 octets.
+     ELT: To be defined in [IDNE].
+
+
+5. Coexistence
+
+5.1 IDN Consideration
+
+  IPTR described above is based on "a set of IDNs", strictly speaking, a
+  set of canonical IDNs. On the other hand, confusion about IDN, such as
+  "IDN MUST exist with ASCII domain name" has led to a belief that PTR
+  record should have exactly RRs in its RRSet. In short, the phenomenon
+  "IDN ONLY" will exist. Thus, the exceptional handling of PTR is
+  REQUIRED.
+
+  On the other hand, IDN is still RECOMMENDED to exist with more than
+  one ASCII domain name.
+
+5.2 PTR Extension
+
+  In the case of "IDN ONLY", if IPTR RR is not NULL, PTR RR MUST contain
+  a domain name in ACE to coexist with those IDN unaware systems. Else a
+  "Syntax Error" message SHOULD be sent back, when an administrator con-
+  figures DNS zone files.
+
+5.3 IPTR and PTR
+
+  It is a kind of backward compatible handle for those IDN unaware sys-
+  tems that can not provide the IPTR function. Besides, if a client can
+
+
+
+Shi, Jiang                                                      [Page 4]
+
+
+
+
+
+INTERNET-DRAFT   Internationalized PTR Resource Record      14 Nov. 2000
+
+
+  not find the corresponding LANGUAGE IDN finally, then the correspond-
+  ing PTR RR SHOULD be used as the answer.
+
+6. IPTR query/response
+
+  When the QTYPE is IPTR in a query, all of the corresponding IPTR RRs
+  SHOULD be returned in one response. DNS messages are limited to 512
+  octets or less in size when sent over UDP. Therefore, if all the RRs
+  cannot fit in one UDP packet, this draft describe two solutions. One
+  is for recent environment and the other is for the near future.
+
+6.1 Transport
+
+  Today, DNS queries and responses are carried in UDP datagrams or over
+  TCP connections.[RFC1034] specifies, IPTR RRSet is RECOMMENDED to be
+  returned in one response. The size of a DNS message could exceed 512
+  octets, when multiple RRs are present. Therefore, this draft makes the
+  two following recommendations.
+
+
+     - "Use UDP first, if UDP is not large enough then change to TCP" is
+       RECOMMENDED.
+
+       The server MUST send back the response with the TC bit set. Then
+       the resolver SHOULD resend the query using TCP on server port
+       53(decimal). This behavior is consistent with the current DNS
+       specification [RFC1035].
+
+
+     - In future, EDNS0 is REQUIRED to send large packets.
+
+       Then, before a client send a query to ask for IPTR record, it
+       MUST query the server whether it knows the EDNS0 first. If the
+       server knows EDNS0, then the client MAY send the IPTR query.
+       Else, unfortunally, the client MUST change the QTYPE to PTR.
+
+       Hence, the size of the UDP payload is no longer limited to 512
+       octets any more.
+
+6.2 Standard sample
+
+     A resolver who wants to find the IDNs corresponding to an IP
+     address 1.2.3.4 whould pursue a query of the form QTYPE=IPTR,
+     QCLASS=IN, QNAME=4.3.2.1.IN-ADDR.ARPA, and would receive:
+
+
+
+
+
+
+
+Shi, Jiang                                                      [Page 5]
+
+
+
+
+
+INTERNET-DRAFT   Internationalized PTR Resource Record      14 Nov. 2000
+
+
+
+                 +------------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE, AA                          |
+                 +------------------------------------------------------+
+      Question   | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR     |
+                 +------------------------------------------------------+
+      Answer     | 4.3.2.1.IN-ADDR.ARPA. IPTR  "zh-CN" "name1-in-utf8"  |
+                 | 4.3.2.1.IN-ADDR.ARPA. IPTR  "zh-TW" "name2-in-utf8"  |
+                 | 4.3.2.1.IN-ADDR.ARPA. IPTR  "zh-JP" "name3-in-utf8"  |
+                 | 4.3.2.1.IN-ADDR.ARPA. IPTR  "ko-KR" "name4-in-utf8"  |
+                 +------------------------------------------------------+
+      Authority  | ...                                                  |
+                 +------------------------------------------------------+
+      Additional | ...                                                  |
+                 +------------------------------------------------------+
+
+
+7. IPTR Usage
+
+     The "foo1.example" in following samples MAY or MAY NOT be
+     represented in the same characters.
+
+     4.3.2.1.IN-ADDR.ARPA  IPTR  "zh-TW" "[foo1.example] in utf8"
+                           IPTR  "zh-CN" "[foo1.example] in utf8"
+                           IPTR  "ja-JP" "[foo1.example] in utf8"
+                           IPTR  "ko-KR" "[foo1.example] in utf8"
+
+     Moreover,
+
+     4.3.2.1.IN-ADDR.ARPA  IPTR  "zh-TW" "[foo1.example] in utf8"
+                           IPTR  "zh-TW" "[foo2.example] in utf8"
+                           ...
+                           IPTR  "zh-CN" "[foo1.example] in utf8"
+                           IPTR  "zh-CN" "[foo2.example] in utf8"
+                           ...
+                           IPTR  "ja-JP" "[foo1.example] in utf8"
+                           IPTR  "ja-JP" "[foo2.example] in utf8"
+                           ...
+                           IPTR  "ko-KR" "[foo1.example] in utf8"
+                           IPTR  "ko-KR" "[foo2.example] in utf8"
+                           ...
+
+     will exist also. And "foo2.example" MUST be different from
+     "foo1.example", if they are in signed with same LANGUAGE. Or a
+     "Syntax Error" SHOULD be sent back, when an administrator config-
+     ures the zone files. Furthermore "foo2.example" in the samples
+     above MAY or MAY NOT be represented in the same characters.
+
+
+
+
+Shi, Jiang                                                      [Page 6]
+
+
+
+
+
+INTERNET-DRAFT   Internationalized PTR Resource Record      14 Nov. 2000
+
+
+     Thus,
+
+     4.3.2.1.IN-ADDR.ARPA  IPTR "zh-TW" "[samefoo.sample] in utf8"
+                           IPTR "zh-TW" "[samefoo.sample] in utf8"
+
+     occurs a "Syntax Error".
+
+     And,
+
+     4.3.2.1.IN-ADDR.ARPA  IPTR "zh-TW" "[samefoo.sample] in utf8"
+                           IPTR "zh-TW" "[difffoo.sample] in utf8"
+                           IPTR "zh-CN" "[samefoo.sample] in utf8"
+                           IPTR "ja-JP" "[samefoo.sample] in utf8"
+                           IPTR "ko-KR" "[samefoo.sample] in utf8"
+
+     is allowed.
+
+8. Open Issues
+
+     1.   Is it necessary to let a IDN aware server to send back all of
+          the corresponding IDNs to a resolver? Meanings,
+
+
+                      +------------------------------------------------------+
+           Header     | OPCODE=SQUERY, RESPONSE, AA                          |
+                      +------------------------------------------------------+
+           Question   | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR     |
+                      +------------------------------------------------------+
+           Answer     | 4.3.2.1.IN-ADDR.ARPA. IPTR  "zh-CN" "name1-in-utf8"  |
+                      | 4.3.2.1.IN-ADDR.ARPA. IPTR  "zh-CN" "name2-in-utf8"  |
+                      | 4.3.2.1.IN-ADDR.ARPA. IPTR  "zh-CN" "name3-in-utf8"  |
+                      | 4.3.2.1.IN-ADDR.ARPA. IPTR  "zh-TW" "name4-in-utf8"  |
+                      | 4.3.2.1.IN-ADDR.ARPA. IPTR  "ko-KR" "name5-in-utf8"  |
+                      | 4.3.2.1.IN-ADDR.ARPA. IPTR  "ko-KR" "name6-in-utf8"  |
+                      +------------------------------------------------------+
+           Authority  | ...                                                  |
+                      +------------------------------------------------------+
+           Additional | ...                                                  |
+                      +------------------------------------------------------+
+
+
+          Or, just using current fixed/cyclic/random options to return
+          one of the corresponding IDNs per LANGUAGE? In short, "one IP
+          one IDN per LANGUAGE". Such like
+
+
+
+
+
+
+
+Shi, Jiang                                                      [Page 7]
+
+
+
+
+
+INTERNET-DRAFT   Internationalized PTR Resource Record      14 Nov. 2000
+
+
+
+                      +------------------------------------------------------+
+           Header     | OPCODE=SQUERY, RESPONSE, AA                          |
+                      +------------------------------------------------------+
+           Question   | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR     |
+                      +------------------------------------------------------+
+           Answer     | 4.3.2.1.IN-ADDR.ARPA. IPTR  "zh-CN" "name1-in-utf8"  |
+                      | 4.3.2.1.IN-ADDR.ARPA. IPTR  "zh-TW" "name4-in-utf8"  |
+                      | 4.3.2.1.IN-ADDR.ARPA. IPTR  "ko-KR" "name5-in-utf8"  |
+                      | 4.3.2.1.IN-ADDR.ARPA. IPTR  "ko-KR" "name6-in-utf8"  |
+                      +------------------------------------------------------+
+           Authority  | ...                                                  |
+                      +------------------------------------------------------+
+           Additional | ...                                                  |
+                      +------------------------------------------------------+
+
+
+
+
+     2.   If QTYPE is IPTR, should an IDN aware server send all of the
+          corresponding IDNs to the resolver? Is this kind of behavior
+          friendly to implent the resolver? How about letting a server
+          just feedback the corresponding PTR record, if a server
+          doesn't find the corresponding LANGUAGE IDN that a client
+          requires.
+
+          In the following case, it is wasteful to return all the
+          corresponding IDNs to the clients.
+
+          4.3.2.1.IN-ADDR.ARPA  IPTR  "zh-TW" "[foo1.example] in utf8"
+                                IPTR  "zh-TW" "[foo2.example] in utf8"
+                                ...
+                                IPTR  "zh-CN" "[foo1.example] in utf8"
+                                IPTR  "zh-CN" "[foo2.example] in utf8"
+                                ...
+                                IPTR  "ja-JP" "[foo1.example] in utf8"
+                                IPTR  "ja-JP" "[foo2.example] in utf8"
+                                ...
+                                IPTR  "ko-KR" "[foo1.example] in utf8"
+                                IPTR  "ko-KR" "[foo2.example] in utf8"
+                                ...
+
+          The benefit of the IPTR is introducing LANGUAGE. It SHOULD be
+          used in query from clients, then servers can select minimum
+          size of corresponding IDNs. For working this effectively, you
+          should introduce default LANGUAGE if no corresponding LANGUAGE
+          exists. The default MUST be ASCII. So that default IPTR can be
+          natural extension of PTR. I.E.
+
+
+
+Shi, Jiang                                                      [Page 8]
+
+
+
+
+
+INTERNET-DRAFT   Internationalized PTR Resource Record      14 Nov. 2000
+
+
+          4.3.2.1.in-addr.arpa. IN PTR ASCII-domain-name
+
+          is equivalent to
+
+          4.3.2.1.in-addr.arpa. IN IPTR "default" ASCII-domain-name
+
+          Of course, ASCII includes ACE.
+
+
+     3.   According to the consideration above, how about the following
+          thinking? That means a response MAY include not only a
+          corresponding IDN in a specific LANGUAGE but also the LANGUAGE
+          tags of the corresponding IDNs. And the client will load these
+          LANGUAGE tags in the DNS cache for the next IPTR query.
+
+References
+
+     [IDNREQ] Zita Wenzel & James Seng, "Requirements of International-
+     ized Domain Names", draft-ietf-idn-requirements.
+
+     [IDNE] Marc Blanchet & Paul Hoffman, "Internationalized domain
+     names using EDNS", draft-ietf-idn-idne.
+
+     [NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of Interna-
+     tionalized Host Names", draft-ietf-idn-nameprep.
+
+     [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES",
+     November 1987, RFC1034
+
+     [RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
+     SPECIFICATION", November 1987, RFC1035
+
+     [RFC1766] H. Alvestrand, "Tags for the Identification of
+     Languages", March 1999, RFC 1766
+
+     [RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP
+     version 6", December 1995, RFC1886
+
+     [RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specifica-
+     tion", July 1997, RFC2181
+
+     [RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
+     10646", January 1998, RFC 2279.
+
+     [RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)",
+     August 1999, RFC 2671.
+
+     [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names
+
+
+
+Shi, Jiang                                                      [Page 9]
+
+
+
+
+
+INTERNET-DRAFT   Internationalized PTR Resource Record      14 Nov. 2000
+
+
+     of languages - The International Organization for Standardization,
+     1st edition, 1988 17 pages Prepared by ISO/TC 37 - Terminology
+     (principles and coordination).
+
+     [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of
+     names of countries - The International Organization for Standardi-
+     zation, 3rd edition, 1988-08-15.
+
+Acknowledgements
+
+     James Seng and Yoshiro Yoneya have given many comments in our e-
+     mail discussions. Harald Alvestrand, Mark Davis have given many
+     suggestions in the idn-wg mailing list discussions. And there are
+     also a lot of people who have given us their comments in the idn-wg
+     and BIND-user mailing list discussions.
+
+Authors' Information
+
+     Hongbo Shi
+     Waseda University
+     3-4-1 Okubo, Shinjyuku-ku
+     Tokyo, 169-8555 Japan
+     shi@goto.info.waseda.ac.jp
+
+     Jiang Ming Liang
+     i-DNS.net
+     8 Temasek Boulevard
+     #24-02 Suntec Tower Three
+     Singapore 038988
+     jiang@i-DNS.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shi, Jiang                                                     [Page 10]
+
+
diff --git a/doc/draft/draft-ietf-idn-jpchar-00.txt b/doc/draft/draft-ietf-idn-jpchar-00.txt
new file mode 100644
index 00000000..634ccc3a
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-jpchar-00.txt
@@ -0,0 +1,159 @@
+Internet Draft                                        Yoshiro Yoneya
+draft-ietf-idn-jpchar-00.txt                      Yasuhiro Morishita
+November 17, 2000                                              JPNIC
+Expires May 17, 2001
+
+        Japanese characters in multilingual domain name label
+
+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 explains about Japanese characters and its canonicalization
+rules in multilingual domain name labels.  This document is based on
+discussions and examinations in JPNIC.
+
+Despite of IDN WG rough consensus that character set in multilingual
+domain name is UCS [UCS], most popular Japanese character set used in
+Japan is Japanese Industrial Standards X 0208 -- hereafter abbreviated
+as "JIS" -- [JISX0208].  This means that many of PCs and most of PDAs
+including handy phones in Japan can display only JIS and ASCII.
+Therefore, Japanese characters used in multilingual domain name are
+strongly recommended as common part of JIS, ASCII and UCS.
+
+Furthermore, for historical reasons, JIS have many compatible code
+points in Kana and Alpha-numericals.  Such compatible code points are
+still used widely, so that these characters SHOULD be acceptable
+especially in user interface, and MUST be canonicalized before
+transmission to the wire.  The former half should be implemented for
+localization, and the latter half must be implemented for
+internationalization.
+
+
+1. Japanese characters in multilingual domain name labels
+
+In principle domain name is a symbolic name of resources on the
+Internet for understanding and memorizing easily to the Internet
+users.  Internationalization or multilingualization of domain name
+MUST obey this principle.  That is, characters in multilingualized
+domain name labels SHOULD be unambiguous.
+
+JIS has a lot of characters including graphical and compatible
+characters.  But as for domain name, significant characters to
+represent names are Kanji, Hiragana and Katakana [CJK].  Therefore,
+according to the principle, Japanese characters in multilingual domain
+name MUST be Kanji, Hiragana and Katakana in JIS.
+
+The file "idntabjp10.txt" defines Japanese characters in the format of
+[VERSION], with additional corresponding JIS code points as 3rd field,
+that can be used in multilingual domain name labels.  Some of them,
+such as PROLONGED SOUND MARK (U+30FC), are categorized into graphical
+character in JIS, but usage of them are part of Kanji, Hiragana or
+Katakana.  These characters are in canonicalized form.
+
+
+2. Canonicalization rules of Japanese characters in multilingual
+   domain name labels
+
+In this section, this document describes two parts of canonicalization
+rules.  One explains "localization", and the other comments on
+"internationalization".  In other words, one is for Input/Display
+level, and another is for API level [IDNA].
+
+2.1 Localization: Characters to be canonicalized before NAMEPREP
+
+As mentioned above, JIS has a lot of compatible characters that are
+regarded alpha-numeric or Katakana.  The former is so called
+FULL-WIDTH Alpha-numeric, and the latter is so called HALF-WIDTH kana.
+These characters are prohibited in [NAMEPREP], but still widely used
+in many PCs and most PDAs in Japan.  Hence, application softwares that
+treat Japanese characters in multilingual domain name label SHOULD
+accept these compatible characters as input and canonicalize them
+before [NAMEPREP].
+
+The file "idntabjpcanon10.txt" defines compatible characters, with
+additional canonicalized character code as 3rd field; that is, mapping
+table of FULL-WIDTH Alpha-numeric to ASCII, and HALF-WIDTH kana to
+Katakana.
+
+The file "idntabjpcomp10.txt" defines compatible character sequences
+as composed, with additional canonicalized characters code as 3rd
+field; that is, composition table of Kana and voiced sound mark.
+
+Recommended order of applying canonicalization rules is as follows:
+
+        (1) "idntabjpcanon10"
+        (2) "idntabjpcom10"
+
+This part is a local part of canonicalization.
+
+2.2 Internationalization: Characters to be canonicalized in NAMEPREP
+
+Japanese characters in multilingual domain name labels MUST be
+characters defined in "idntabjp10".  Another characters except for
+"idntabjp10" SHOULD be canonicalized at [NAMEPREP].
+
+[NAMEPREP] is common and recommended rule for IDN.
+
+This part is an international part of canonicalization.
+
+
+3. Security considerations
+
+None in particular.
+
+
+4. References
+
+[UCS]       "Universal Multiple-Octet Coded Character Set",
+            ISO/IEC 10646-1:1993, ISBN 0-201-61633-5
+[JISX0208]  "Japanese Industrial Standards",
+            Information Technology (Terms/Code/Date elements)-99,
+            ISBN4-542-12976-4
+[IDNREQ]    "Requirements of Internationalized Domain Names",
+            draft-ietf-idn-requirements-03.txt, Jun 2000, Z Wenzel, J Seng
+[NAMEPREP]  "Preparation of Internationalized Host Names",
+            draft-ietf-idn-nameprep-00.txt, Jul 2000, P Hoffman, M Blanchet
+[CJK]       "Han Ideograph (CJK) for Internationalized Domain Names",
+            draft-ietf-idn-cjk-00.txt, Sep 2000, J Seng, Y Yoneya,
+            K Huang, K Kyongsok
+[VERSION]   "Handling versions of internationalized domain names protocols",
+            draft-ietf-idn-version-00.txt, Nov 2000, M Blanchet
+
+
+5. Acknowledgements
+
+JPNIC IDN-TF members.
+
+
+6. Author's Address
+
+Yoshiro Yoneya
+Japan Network Information Center
+Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
+Chiyoda-ku Tokyo 101-0052, Japan
+yone@nic.ad.jp
+
+Yasuhiro Morishita
+Japan Network Information Center
+Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
+Chiyoda-ku Tokyo 101-0052, Japan
+yasuhiro@nic.ad.jp
diff --git a/doc/draft/draft-ietf-idn-lace-00.txt b/doc/draft/draft-ietf-idn-lace-00.txt
new file mode 100644
index 00000000..464b8755
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-lace-00.txt
@@ -0,0 +1,522 @@
+Internet Draft                                            Mark Davis
+draft-ietf-idn-lace-00.txt                                       IBM
+November 6, 2000                                        Paul Hoffman
+Expires May 6, 2001                                       IMC & VPNC
+
+        LACE: Length-based ASCII Compatible Encoding for IDN
+
+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 describes a transformation method for representing
+non-ASCII characters in host name parts in a fashion that is completely
+compatible with the current DNS. It is a potential candidate for an
+ASCII-Compatible Encoding (ACE) for internationalized host names, as
+described in the comparison document from the IETF IDN Working Group.
+This method is based on the observation that many internationalized host
+name parts will have a few substrings from a small number of rows of the
+ISO 10646 repertoire. Run-length encoding for these types of
+host names will be fairly compact, and is fairly easy to describe. 
+
+
+1. Introduction
+
+There is a strong world-wide desire to use characters other than plain
+ASCII in host names. Host names have become the equivalent of business
+or product names for many services on the Internet, so there is a need
+to make them usable by people whose native scripts are not representable
+by ASCII. The requirements for internationalizing host names are
+described in the IDN WG's requirements document, [IDNReq].
+
+The IDN WG's comparison document [IDNComp] describes three potential
+main architectures for IDN: arch-1 (just send binary), arch-2 (send
+binary or ACE), and arch-3 (just send ACE). LACE is an ACE, called
+Row-based ACE or LACE, that can be used with protocols that match arch-2
+or arch-3. LACE specifies an ACE format as specified in ace-1 in
+[IDNComp]. Further, it specifies an identifying mechanism for ace-2 in
+[IDNComp], namely ace-2.1.1 (add hopefully-unique legal tag to the
+beginning of the name part).
+
+In formal terms, LACE describes a character encoding scheme of the
+ISO/IEC 10646 [ISO10646] coded character set (whose assignment of
+characters is synchronized with Unicode [Unicode3]) and the rules for
+using that scheme in the DNS. As such, it could also be called a
+"charset" as defined in [IDNReq].
+
+The LACE protocol has the following features:
+
+- There is exactly one way to convert internationalized host parts to
+and from LACE parts. Host name part uniqueness is preserved.
+
+- Host parts that have no international characters are not changed.
+
+- Names using LACE can include more internationalized characters than
+with other ACE protocols that have been suggested to date. LACE-encoded
+names are variable length, depending on the number of transitions
+between rows in the ISO 10646 repertoire that appear in the name part.
+Name parts that cannot be compressed using run-length encoding can have
+up to 17 characters, and names that can be compressed can have up to 35
+characters. Further, a name that has just a few row transitions
+typically can have over 30 characters.
+
+It is important to note that the following sections contain many
+normative statements with "MUST" and "MUST NOT". Any implementation that
+does not follow these statements exactly is likely to cause damage to
+the Internet by creating non-unique representations of host names.
+
+1.1 Terminology
+
+The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
+"MAY" in this document are to be interpreted as described in RFC 2119
+[RFC2119].
+
+Hexadecimal values are shown preceded with an "0x". For example,
+"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
+shown preceded with an "0b". For example, a nine-bit value might be
+shown as "0b101101111".
+
+Examples in this document use the notation from the Unicode Standard
+[Unicode3] as well as the ISO 10646 names. For example, the letter "a"
+may be represented as either "U+0061" or "LATIN SMALL LETTER A".
+
+LACE converts strings with internationalized characters into
+strings of US-ASCII that are acceptable as host name parts in current
+DNS host naming usage. The former are called "pre-converted" and the
+latter are called "post-converted".
+
+1.2 IDN summary
+
+Using the terminology in [IDNComp], LACE specifies an ACE format as
+specified in ace-1. Further, it specifies an identifying mechanism for
+ace-2, namely ace-2.1.1 (add hopefully-unique legal tag to the beginning
+of the name part).
+
+LACE has the following length characteristics. In this list, "row" means
+a row from ISO 10646.
+
+- LACE-encoded names are variable length, depending on the number of
+transitions between rows that appear in the name part.
+
+- Name parts that cannot be compressed using run-length encoding can
+have up to 17 characters.
+
+- Names that can be compressed can have up to 35 characters.
+
+-A name that has just a few row transitions typically can have over 30
+characters.
+
+
+2. Host Part Transformation
+
+According to [STD13], host parts must be case-insensitive, start and
+end with a letter or digit, and contain only letters, digits, and the
+hyphen character ("-"). This, of course, excludes any internationalized
+characters, as well as many other characters in the ASCII character
+repertoire. Further, domain name parts must be 63 octets or shorter in
+length.
+
+2.1 Name tagging
+
+All post-converted name parts that contain internationalized characters
+begin with the string "bq--". (Of course, because host name parts are
+case-insensitive, this might also be represented as "Bq--" or "bQ--" or
+"BQ--".) The string "bq--" was chosen because it is extremely unlikely
+to exist in host parts before this specification was produced. As a
+historical note, in late August 2000, none of the second-level host name
+parts in any of the .com, .edu, .net, and .org top-level domains began
+with "bq--"; there are many tens of thousands of other strings of three
+characters followed by a hyphen that have this property and could be
+used instead. The string "bq--" will change to other strings with the
+same properties in future versions of this draft.
+
+Note that a zone administrator might still choose to use "bq--" at the
+beginning of a host name part even if that part does not contain
+internationalized characters. Zone administrators SHOULD NOT create host
+part names that begin with "bq--" unless those names are post-converted
+names. Creating host part names that begin with "bq--" but that are not
+post-converted names may cause two distinct problems. Some display
+systems, after converting the post-converted name part back to an
+internationalized name part, might display the name parts in a
+possibly-confusing fashion to users. More seriously, some resolvers,
+after converting the post-converted name part back to an
+internationalized name part, might reject the host name if it contains
+illegal characters.
+
+2.2 Converting an internationalized name to an ACE name part
+
+To convert a string of internationalized characters into an ACE name
+part, the following steps MUST be preformed in the exact order of the
+subsections given here.
+
+If a name part consists exclusively of characters that conform to the
+host name requirements in [STD13], the name MUST NOT be converted to
+LACE. That is, a name part that can be represented without LACE MUST NOT
+be encoded using LACE. This absolute requirement prevents there from
+being two different encodings for a single DNS host name.
+
+If any checking for prohibited name parts (such as ones that are
+prohibited characters, case-folding, or canonicalization) is to be done,
+it MUST be done before doing the conversion to an ACE name part.
+
+The input name string consists of characters from the ISO 10646
+character set in big-endian UTF-16 encoding. This is the pre-converted
+string.
+
+Characters outside the first plane of characters
+(those with codepoints above U+FFFF) MUST be represented using surrogates, as
+described in the UTF-16 description in ISO 10646.
+
+2.2.1 Compress the pre-converted string
+
+The entire pre-converted string MUST be compressed using the compression
+algorithm specified in section 2.4. The result of this step is the
+compressed string.
+
+2.2.2 Check the length of the compressed string
+
+The compressed string MUST be 36 octets or shorter. If the compressed
+string is 37 octets or longer, the conversion MUST stop with an error.
+
+2.2.3 Encode the compressed string with Base32
+
+The compressed string MUST be converted using the Base32 encoding
+described in section 2.5. The result of this step is the encoded string.
+
+2.2.4 Prepend "bq--" to the encoded string and finish
+
+Prepend the characters "bq--" to the encoded string. This is the host
+name part that can be used in DNS resolution.
+
+2.3 Converting a host name part to an internationalized name
+
+The input string for conversion is a valid host name part. Note that if
+any checking for prohibited name parts (such as prohibited characters,
+case-folding, or canonicalization is to be done, it MUST be done after
+doing the conversion from an ACE name part.
+
+If a decoded name part consists exclusively of characters that conform
+to the host name requirements in [STD13], the conversion from LACE MUST
+fail. Because a name part that can be represented without LACE MUST NOT
+be encoded using LACE, the decoding process MUST check for name parts
+that consists exclusively of characters that conform to the host name
+requirements in [STD13] and, if such a name part is found, MUST
+beconsidered an error (and possibly a security violation).
+
+2.3.1 Strip the "bq--"
+
+The input string MUST begin with the characters "bq--". If it does not,
+the conversion MUST stop with an error. Otherwise, remove the characters
+"bq--" from the input string. The result of this step is the stripped
+string.
+
+2.3.2 Decode the stripped string with Base32
+
+The entire stripped string MUST be checked to see if it is valid Base32
+output. The entire stripped string MUST be changed to all lower-case
+letters and digits. If any resulting characters are not in Table 1, the
+conversion MUST stop with an error; the input string is the
+post-converted string. Otherwise, the entire resulting string MUST be
+converted to a binary format using the Base32 decoding described in
+section 2.5. The result of this step is the decoded string.
+
+2.3.3 Decompress the decoded string
+
+The entire decoded string MUST be converted to ISO 10646 characters
+using the decompression algorithm described in section 2.4. The result
+of this is the internationalized string.
+
+2.4 Compression algorithm
+
+The basic method for compression is to reduce a substring that consists
+of characters all from a single row of the ISO 10646 repertoire to a
+count octet followed by the row header followed by the lower octets of
+the characters. If this ends up being longer than the input, the string
+is not compressed, but instead has a unique one-octet header attached.
+
+Although the uncompressed mode limits the number of characters in a LACE
+name part to 17, this is still generally enough for almost all names in
+almost scripts. Also, this limit is close to the limits set by other
+encoding proposals.
+
+Note that the compression and decompression rules MUST be followed
+exactly. This requirement prevents a single host name part from having
+two encodings. Thus, for any input to the algorithm, there is only one
+possible output. An implementation cannot chose to use one-octet mode or
+two-octet mode using anything other than the logic given in this
+section.
+
+2.4.1 Compressing a string
+
+The input string is in big-endian UTF-16 encoding with no byte order
+mark.
+
+Design note: No checking is done on the input to this algorithm. It is
+assumed that all checking for valid ISO/IEC 10646 characters has already
+been done by a previous step in the conversion process.
+
+1) If the length of the input is not even, or is less than 2, stop with
+an error.
+
+2) Set the input pointer, called IP, to the first octet of the input
+string.
+
+3) Set the variable called HIGH to the octet at IP.
+
+4) Determine the number of pairs at or after IP that have HIGH as the
+first octet; call this COUNT.
+
+5) Put into an output buffer the single octet for COUNT followed by the
+single octet for HIGH, followed by all those low octets. Move IP to the
+end of those pairs; that is, set IP to IP+(2*(COUNT+1)).
+
+6) If IP is not at the end of the input string, go to step 3.
+
+7) If the length of the output buffer is less than or equal to the
+length of the input buffer (in octets, not in characters), output the
+buffer. Otherwise, output the octet 0xFF followed by the input buffer.
+Note that there can only be one possible representation for a name part,
+so that outputting the wrong name part is a serious security error.
+Decompression schemes MUST accept only the valid form and MUST NOT
+accept invalid forms.
+
+
+2.4.2 Decompressing a string
+
+1. Set the input pointer, called IP, to the first octet of the input
+string. If there is no first octet, stop with an error.
+
+2. If the octet at IP is 0xFF, go to step 10.
+
+3. Get the octet at IP, call it COUNT. Set IP to IP+1. If IP is now at
+the end of the input string, stop with an error.
+
+4. Get the octet at IP, call it HIGH. Set IP to IP+1. If IP is now at
+the end of the input string, stop with an error.
+
+5. Get the octet at IP, call it LOW. Set IP to IP+1.
+
+6. Output HIGH, then LOW, to the output buffer.
+
+7. Decrement COUNT. If COUNT is greater than 0, go to step 5.
+
+8. If IP is not at the end of the input buffer, go to step 3.
+
+9. Compare the length of the input string with the length of the output
+buffer. If the length of the output buffer is longer than the length of
+the input buffer, stop with an error because the wrong compression form
+was used. Otherwise, send out the output buffer and stop.
+
+10. Set IP to IP+1. Copy the rest of the input buffer to the output
+buffer. Compress the output buffer into a separate comparison buffer
+following the steps for compression above. If the length of the
+comparison buffer is less than or equal to the length of the output
+buffer, stop with an error because the wrong compression form was used.
+Otherwise, send out the output buffer and stop.
+
+2.4.3 Compression examples
+
+The five input characters <U+30E6 U+30CB U+30B3 U+30FC U+30C9> are
+represented in big-endian UTF-16 as the ten octets <30 E6 30 CB 30 B3 30
+FC 30 C9>. All the code units are in the same row (03). The output
+buffer has seven octets <05 30 E6 CB B3 FC C9>, which is shorter than
+the input string. Thus the output is <05 30 E6 CB B3 FC C9>.
+
+The four input characters <U+012E U+0110 U+014A U+00C5> are represented
+in big-endian UTF-16 as the eight octets <01 2E 01 10 01 4A 00 C5>. The
+output buffer has eight octets <03 01 2E 10 4A 01 00 C5>, which is the
+same length as the input string. Thus, the output is <03 01 2E 10 4A 01
+00 C5>.
+
+The three input characters <U+012E U+00D0 U+014A> are represented in
+big-endian UTF-16 as the six octets <01 2E 00 D0  01 4A>. The output
+buffer is nine octets <01 01 2E 01 00 D0 01 01 4A>, which is longer than
+the input buffer. Thus, the output is <FF 01 2E 00 D0 01 4A>.
+
+2.5 Base32
+
+In order to encode non-ASCII characters in DNS-compatible host name parts,
+they must be converted into legal characters. This is done with Base32
+encoding, described here.
+
+Table 1 shows the mapping between input bits and output characters in
+Base32. Design note: the digits used in Base32 are "2" through "7"
+instead of "0" through "6" in order to avoid digits "0" and "1". This
+helps reduce errors for users who are entering a Base32 stream and may
+misinterpret a "0" for an "O" or a "1" for an "l".
+
+                    Table 1: Base32 conversion
+             bits   char  hex         bits   char  hex
+             00000   a    0x61        10000   q    0x71
+             00001   b    0x62        10001   r    0x72
+             00010   c    0x63        10010   s    0x73
+             00011   d    0x64        10011   t    0x74
+             00100   e    0x65        10100   u    0x75
+             00101   f    0x66        10101   v    0x76
+             00110   g    0x67        10110   w    0x77
+             00111   h    0x68        10111   x    0x78
+             01000   i    0x69        11000   y    0x79
+             01001   j    0x6a        11001   z    0x7a
+             01010   k    0x6b        11010   2    0x32
+             01011   l    0x6c        11011   3    0x33
+             01100   m    0x6d        11100   4    0x34
+             01101   n    0x6e        11101   5    0x35
+             01110   o    0x6f        11110   6    0x36
+             01111   p    0x70        11111   7    0x37
+
+2.5.1 Encoding octets as Base32
+
+The input is a stream of octets. However, the octets are then treated
+as a stream of bits.
+
+Design note: The assumption that the input is a stream of octets
+(instead of a stream of bits) was made so that no padding was needed.
+If you are reusing this algorithm for a stream of bits, you must add a
+padding mechanism in order to differentiate different lengths of input.
+
+1) Set the read pointer to the beginning of the input bit stream.
+
+2) Look at the five bits after the read pointer. If there are not five
+bits, go to step 5.
+
+3) Look up the value of the set of five bits in the bits column of
+Table 1, and output the character from the char column (whose hex value
+is in the hex column).
+
+4) Move the read pointer five bits forward. If the read pointer is at
+the end of the input bit stream (that is, there are no more bits in the
+input), stop. Otherwise, go to step 2.
+
+5) Pad the bits seen until there are five bits.
+
+6) Look up the value of the set of five bits in the bits column of
+Table 1, and output the character from the char column (whose hex value
+is in the hex column).
+
+2.5.2 Decoding Base32 as octets
+
+The input is octets in network byte order. The input octets MUST be
+values from the second column in Table 1.
+
+1) Set the read pointer to the beginning of the input octet stream.
+
+2) Look up the character value of the octet in the char column (or hex
+value in hex column) of Table 1, and output the five bits from the bits
+column.
+
+3) Move the read pointer one octet forward. If the read pointer is at
+the end of the input octet stream (that is, there are no more octets in
+the input), stop. Otherwise, go to step 2.
+
+2.5.3 Base32 example
+
+Assume you want to encode the value 0x3a270f93. The bit string is:
+
+3   a    2   7    0   f    9   3
+00111010 00100111 00001111 10010011
+
+Broken into chunks of five bits, this is:
+
+00111 01000 10011 10000 11111 00100 11
+
+Padding is added to make the last chunk five bits:
+
+00111 01000 10011 10000 11111 00100 11000
+
+The output of encoding is:
+
+00111 01000 10011 10000 11111 00100 11000
+  h     i     t     q     7     e     y
+or "hitq7ey".
+
+
+3. Security Considerations
+
+Much of the security of the Internet relies on the DNS. Thus, any
+change to the characteristics of the DNS can change the security of
+much of the Internet. Thus, LACE makes no changes to the DNS
+itself.
+
+Host 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 host
+name.
+
+LACE is designed so that every internationalized host name part
+can be represented as one and only one DNS-compatible string. If there
+is any way to follow the steps in this document and get two or more
+different results, it is a severe and fatal error in the protocol.
+
+
+4. References
+
+[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals",
+draft-ietf-idn-compare.
+
+[IDNReq] James Seng, "Requirements of Internationalized Domain Names",
+draft-ietf-idn-requirement.
+
+[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
+technology -- Universal Multiple-Octet Coded Character Set (UCS) --
+Part 1: Architecture and Basic Multilingual Plane.  Five amendments and
+a technical corrigendum have been published up to now. UTF-16 is
+described in Annex Q, published as Amendment 1. 17 other amendments are
+currently at various stages of standardization. [[[ THIS REFERENCE
+NEEDS TO BE UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
+
+[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels", March 1997, RFC 2119.
+
+[STD13] Paul Mockapetris, "Domain names - implementation and
+specification", November 1987, STD 13 (RFC 1035).
+
+[Unicode3] The Unicode Consortium, "The Unicode Standard -- Version
+3.0", ISBN 0-201-61633-5. Described at
+<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
+
+
+A. Acknowledgements
+
+Base32 is quite obviously inspired by the tried-and-true Base64
+Content-Transfer-Encoding from MIME.
+
+
+B. IANA Considerations
+
+There are no IANA considerations in this document.
+
+
+C. Author Contact Information
+
+Mark Davis
+IBM
+10275 N. De Anza Blvd
+Cupertino, CA 95014
+mark.davis@us.ibm.com and mark.davis@macchiato.com
+
+Paul Hoffman
+Internet Mail Consortium and VPN Consortium
+127 Segre Place
+Santa Cruz, CA  95060 USA
+paul.hoffman@imc.org and paul.hoffman@vpnc.org
diff --git a/doc/draft/draft-ietf-idn-nameprep-00.txt b/doc/draft/draft-ietf-idn-nameprep-00.txt
new file mode 100644
index 00000000..da21fad9
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-nameprep-00.txt
@@ -0,0 +1,855 @@
+Internet Draft                                          Paul Hoffman
+draft-ietf-idn-nameprep-00.txt                            IMC & VPNC
+July 3, 2000                                           Marc Blanchet
+Expires in six months                                       ViaGenie
+
+             Preparation of Internationalized Host Names
+
+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 describes how to prepare internationalized host names for
+transmission on the wire. The steps include excluding characters that
+are prohibited from appearing in internationalized host names, changing
+all characters that have case properties to be lowercase, and
+normalizing the characters. Further, this document lists the prohibited
+characters.
+
+
+1. Introduction
+
+When expanding today's DNS to include internationalized host names,
+those new names will be handled in many parts of the DNS. The IDN
+Working Group's requirements document [IDNReq] describes a framework for
+domain name handling as well as requirements for the new names. The IDN
+Working Group's comparison document [IDNComp] gives a framework for how
+various parts of the IDN solution work together.
+
+A user can enter a domain name into an application program in a myriad
+of fashions. Depending on the input method, the characters entered in
+the domain name may or may not be those that are allowed in
+internationalized host names. Thus, there must be a way to canonicalized
+the user's input before the name is resolved in the DNS.
+
+It is a design goal of this document to allow users to enter host names
+in applications and have the highest chance of getting the name correct.
+This means that the user should not be limited to only entering exactly
+the characters that might have been used, but to instead be able to
+enter characters that unambiguously canonicalize to characters in the
+desired host name. At the same time, this process must not introduce any
+chance that two host names could be represented by two distinct strings
+of characters that look identical to typical users. It is also a design
+goal to have all preprocessing of IDN done before going on the wire, so
+that no transformation is done in the DNS server space.
+
+This document describes the steps needed to convert a name part from one
+that is entered by the user to one that can be used in the DNS.
+
+1.1 Terminology
+
+The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
+"MAY" in this document are to be interpreted as described in RFC 2119
+[RFC2119].
+
+Examples in this document use the notation from the Unicode Standard
+[Unicode3] as well as the ISO 10646 [ISO10646] names. For example, the
+letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER
+A". In the lists of prohibited characters, the "U+" is left off to make
+the lists easier to read.
+
+1.2 IDN summary
+
+Using the terminology in [IDNComp], this document specifies all of the
+prohibited characters and the canonicalization for an IDN solution.
+Specifically, it covers the following sections from [IDNComp]:
+
+prohib-1: Identical and near-identical characters
+prohib-2: Separators
+prohib-3: Non-displaying and non-spacing characters
+prohib-4: Private use characters
+prohib-5: Punctuation
+prohib-6: Symbols
+canon-1.2: Normalization Form KC
+canon-2.1: Case folding in ASCII
+canon-2.2: Case folding in non-ASCII
+
+Note that this document does not cover:
+canon-1.1: Normalization Form C
+canon-2.3: Han folding
+
+1.3 Open issues
+
+This is the first draft of this document. Although there has been much
+discussion on the WG mailing list about the topics here, there has not
+yet been much agreement on some issues. Now that there is a document to
+talk about, that discussion can be more focussed.
+
+1.3.1 Where to do name preparation
+
+Section 2.1 says to do name preparation in the resolver. An argument can
+be made for doing name preparation in the application, before the
+application service interface. An advantage of that proposal is that
+resolvers would not need to do any name preparation. A disadvantage is
+that applications would have to be updated each time the IDN protocol is
+updated, such as if new characters are added to the repertoire of
+allowed characters. It seems likely that resolvers are more easily
+updated than all the individual applications that use internationalized
+host names.
+
+1.3.2 Choosing between normalization form C and KC
+
+Much of the discussion of normalization on the WG mailing list assumed
+that normalization form C would be used. Near the time that this
+document was written, people started considering form KC instead of C.
+This document used form KC, but the reasons for doing so could be
+contentious.
+
+1.3.3 Does the prohibition catch all bad characters?
+
+On the mailing list, it was discussed doing prohibition in two steps: a
+short list of prohibited characters before case folding in order to
+prevent uppercase characters that have no lowercase equivalents from
+getting through, and then a full check on the output of normalization.
+In this draft, all checking is done before case folding, based on the
+(possibly wrong) assumption that none of the prohibited characters will
+re-appear after the case folding and normalization. If that assumption
+turns out to be wrong, a check for just those problematic characters can
+be added after normalization, or a full check against the prohibited
+characters can be added.
+
+
+2. Preparation Overview
+
+This section describes where name preparation happens and the steps that
+name preparation software must take.
+
+2.1 Where name preparation happens
+
+Part of the chart in section 1.4 of [IDNReq] looks like this:
+
++---------------+
+| Application   |
++---------------+
+      |  Application service interface
+      |  For ex. GethostbyXXXX interface
++---------------+
+| Resolver      |
++---------------+
+      |     <-----   DNS service interface
++-------------------------------------------+
+ 
+In this specification, the name preparation is done in the resolver,
+before the DNS service interface. That is, it is acceptable for software
+in the application service interface (such as a "GetHostByName" API) to
+pass the resolver a name that has not been prepared. However, the
+resolver MUST prepare the name as described in this specification before
+passing it to the DNS service interface.
+
+2.2 Name preparation steps
+
+The steps for preparing names are:
+
+1) Input from the application service interface -- This can be done in
+many ways and is not specified in this document
+
+2) Look for prohibited input -- Check for any characters that are not
+allowed in the input. If any are found, return an error to the
+application service interface. This step is necessary to prevent errors
+in the following two steps. This step fulfills prohib-1, prohib-2,
+prohib-3, prohib-4, prohib-5, and prohib-6 from [IDNComp].
+
+3) Fold case -- Change all uppercase characters into lowercase
+characters. Design note: this step could just as easily have been
+"change all lowercase characters into uppercase characters". However,
+the upper-to-lower folding was chosen because most users of the Internet
+today enter host names in lowercase. This step fulfills canon-2.1 and
+canon-2.2 from [IDNComp].
+
+4) Canonicalize -- Normalize the characters. This step fulfils canon-1.2
+from [IDNComp].
+
+5) Resolution of the prepared name -- This must be specified in a
+different IDN document.
+
+The above steps MUST be performed in the order given in order to comply
+with this specification.
+
+
+3. Prohibited Input
+
+Before the text can be processed, it must be checked for prohibited
+characters. There is a variety of prohibited characters, as described in
+this section.
+
+Note that one of the goals of IDN is to allow the widest possible set of
+host names as long as those host names do not cause other problems, such
+as possible ambiguity. Specifically, experience with current DNS names
+have shown that there is a desire for host names that include personal
+names, company names, and spoken phrases. A goal of this section is to
+prohibit as few characters that might be used in these contexts as
+possible while making sure that characters that might easily cause
+confusion or ambiguity are prohibited.
+
+Note that every character listed in this section MUST NOT be transmitted
+on the DNS service interface. Although the checking is being performed
+before case folding and canonicalization, those steps cannot result in
+any of these characters if these characters are not in the input stream.
+[[[NOTE: THIS STATEMENT NEEDS TO BE CHECKED ALGORITHMICALLY.]]] If a DNS
+server receives a request containing a prohibited character, then the
+IDN protocol MUST return an error message.
+
+
+Note that some characters listed in one section would also appear in
+other sections. Each character is only listed once.
+
+3.1 prohib-1: Identical and near-identical characters
+
+Many characters in [ISO10646] are identical or nearly identical to other
+characters. These were often included for compatibility with other
+character sets.
+
+The characters prohibited because they are identical or nearly identical
+to allowed characters are:
+
+00AD        SOFT HYPHEN
+00D7        MULTIPLICATION SIGN
+01C3        LATIN LETTER RETROFLEX CLICK
+02B0-02FF   [SPACING MODIFIER LETTERS]
+066D        ARABIC FIVE POINTED STAR
+1806        MONGOLIAN TODO SOFT HYPHEN
+2010        HYPHEN
+2011        NON-BREAKING HYPHEN
+2012        FIGURE DASH
+2013        EN DASH
+2014        EM DASH
+2160-217F   [ROMAN NUMERALS]
+FB1D-FB4F   [HEBREW PRESENTATION FORMS]
+FB50-FDFF   [ARABIC PRESENTATION FORMS A]
+FE20-FE2F   [COMBINING HALF MARKS]
+FE30-FE4F   [CJK COMPATIBILITY FORMS]
+FE50-FE6F   [SMALL FORM VARIANTS]
+FE70-FEFC   [ARABIC PRESENTATION FORMS B]
+FF00-FFEF   [HALFWIDTH AND FULLWIDTH FORMS]
+
+3.2 prohib-2: Separators
+
+Horizontal and vertical spacing characters would make it unclear where a
+host name begins and ends. The prohibited spacing characters are:
+
+0020        SPACE
+00A0        NO-BREAK SPACE
+1680        OGHAM SPACE MARK
+2000-200B   [SPACES]
+2028        LINE SEPARATOR
+2029        PARAGRAPH SEPARATOR
+202F        NARROW NO-BREAK SPACE
+3000        IDEOGRAPHIC SPACE
+
+Allowing periods and period-like characters as characters within a name
+part would also cause similar confusion. The prohibited periods,
+characters that look like periods, and characters that canonicalize to a
+period or to a period-like character are:
+
+002E        FULL STOP
+06D4        ARABIC FULL STOP
+2024        ONE DOT LEADER
+2025        TWO DOT LEADER
+2026        HORIZONTAL ELLIPSIS
+2488        DIGIT ONE FULL STOP
+2489        DIGIT TWO FULL STOP
+248A        DIGIT THREE FULL STOP
+248B        DIGIT FOUR FULL STOP
+248C        DIGIT FIVE FULL STOP
+248D        DIGIT SIX FULL STOP
+248E        DIGIT SEVEN FULL STOP
+248F        DIGIT EIGHT FULL STOP
+2490        DIGIT NINE FULL STOP
+2491        NUMBER TEN FULL STOP
+2492        NUMBER ELEVEN FULL STOP
+2493        NUMBER TWELVE FULL STOP
+2494        NUMBER THIRTEEN FULL STOP
+2495        NUMBER FOURTEEN FULL STOP
+2496        NUMBER FIFTEEN FULL STOP
+2497        NUMBER SIXTEEN FULL STOP
+2498        NUMBER SEVENTEEN FULL STOP
+2499        NUMBER EIGHTEEN FULL STOP
+249A        NUMBER NINETEEN FULL STOP
+249B        NUMBER TWENTY FULL STOP
+33C2        SQUARE AM
+33C2        SQUARE AM
+33C7        SQUARE CO
+33D8        SQUARE PM
+33D8        SQUARE PM
+
+3.3 prohib-3: Non-displaying and non-spacing characters
+
+There are many characters that cannot be seen in the ISO 10646 character
+set. These include control characters, non-breaking spaces, formatting
+characters, and tagging characters. These characters would certainly
+cause confusion if allowed in host names.
+
+0000-001F   [CONTROL CHARACTERS]
+007F        DELETE
+0080-009F   [CONTROL CHARACTERS]
+070F        SYRIAC ABBREVIATION MARK
+180B        MONGOLIAN FREE VARIATION SELECTOR ONE
+180C        MONGOLIAN FREE VARIATION SELECTOR TWO
+180D        MONGOLIAN FREE VARIATION SELECTOR THREE
+180E        MONGOLIAN VOWEL SEPARATOR
+200C        ZERO WIDTH NON-JOINER
+200D        ZERO WIDTH JOINER
+200E        LEFT-TO-RIGHT MARK
+200F        RIGHT-TO-LEFT MARK
+202A        LEFT-TO-RIGHT EMBEDDING
+202B        RIGHT-TO-LEFT EMBEDDING
+202C        POP DIRECTIONAL FORMATTING
+202D        LEFT-TO-RIGHT OVERRIDE
+202E        RIGHT-TO-LEFT OVERRIDE
+206A        INHIBIT SYMMETRIC SWAPPING
+206B        ACTIVATE SYMMETRIC SWAPPING
+206C        INHIBIT ARABIC FORM SHAPING
+206D        ACTIVATE ARABIC FORM SHAPING
+206E        NATIONAL DIGIT SHAPES
+206F        NOMINAL DIGIT SHAPES
+FEFF        ZERO WIDTH NO-BREAK SPACE
+FFF9        INTERLINEAR ANNOTATION ANCHOR
+FFFA        INTERLINEAR ANNOTATION SEPARATOR
+FFFB        INTERLINEAR ANNOTATION TERMINATOR
+FFFC        OBJECT REPLACEMENT CHARACTER
+FFFD        REPLACEMENT CHARACTER
+
+3.4 prohib-4: Private use characters
+
+Because private-use characters do not have defined meanings, they are
+prohibited. The private-use characters are:
+
+E000-F8FF   [PRIVATE USE, PLANE 0]
+
+3.5 prohib-5: Punctuation
+
+The following characters are reserved or delimiters in URLs [RFC2396]
+and [RFC2732]:
+
+" # $ % & + , . / : ; < = > ? @ [ ]
+
+3.5.1 Characters from URLs
+
+The following punctuation characters are prohibited because they are
+reserved or delimiters in URLs.
+
+0022        QUOTATION MARK
+0023        NUMBER SIGN
+0024        DOLLAR SIGN
+0025        PERCENT SIGN
+0026        AMPERSAND
+002B        PLUS SIGN
+002C        COMMA
+002E        FULL STOP
+002F        SOLIDUS
+003A        COLON
+003B        SEMICOLON
+003C        LESS-THAN SIGN
+003D        EQUALS SIGN
+003E        GREATER-THAN SIGN
+003F        QUESTION MARK
+0040        COMMERCIAL AT
+005B        LEFT SQUARE BRACKET
+005D        RIGHT SQUARE BRACKET
+
+3.5.2 Characters that canonicalize to characters from URLs
+
+The following punctuation characters are prohibited because their
+normalization contains one or more of the characters from section 3.5.1.
+
+037E        GREEK QUESTION MARK
+2048        QUESTION EXCLAMATION MARK
+2049        EXCLAMATION QUESTION MARK
+207A        SUPERSCRIPT PLUS SIGN
+207C        SUPERSCRIPT EQUALS SIGN
+208A        SUBSCRIPT PLUS SIGN
+208C        SUBSCRIPT EQUALS SIGN
+2100        ACCOUNT OF
+2101        ADDRESSED TO THE SUBJECT
+2105        CARE OF
+2106        CADA UNA
+
+3.5.3 Characters that look like characters from URLs
+
+The following are prohibited because they look indistinguishable from
+the characters listed in section 3.5.1.
+
+037E        GREEK QUESTION MARK
+0589        ARMENIAN FULL STOP
+060C        ARABIC COMMA
+061B        ARABIC SEMICOLON
+066A        ARABIC PERCENT SIGN
+201A        SINGLE LOW-9 QUOTATION MARK
+2030        PER MILLE SIGN
+2031        PER TEN THOUSAND SIGN
+2033        DOUBLE PRIME
+2039        SINGLE LEFT-POINTING ANGLE QUOTATION MARK
+2044        FRACTION SLASH
+203A        SINGLE RIGHT-POINTING ANGLE QUOTATION MARK
+203D        INTERROBANG
+3001        IDEOGRAPHIC COMMA
+3002        IDEOGRAPHIC FULL STOP
+3003        DITTO MARK
+3008        LEFT ANGLE BRACKET
+3009        RIGHT ANGLE BRACKET
+3014        LEFT TORTOISE SHELL BRACKET
+3015        RIGHT TORTOISE SHELL BRACKET
+301A        LEFT WHITE SQUARE BRACKET
+301B        RIGHT WHITE SQUARE BRACKET
+
+3.5.4 Other punctuation
+
+The following punctuation are prohibited because they are unlikely to
+be used in names and may be confusing to users or to character-entry
+processes:
+
+005C        REVERSE SOLIDUS
+
+3.6 prohib-6: Symbols
+
+[UniData] has non-normative categories for symbols. The four symbol
+categories are:
+
+Symbol, Currency: Currency symbols could appear in company names and
+spoken phrases, so they are not prohibited.
+
+Symbol, Modifier: Stand-alone modifiers might appear in personal names,
+company names, and spoken phrases, so they are not prohibited.
+
+Symbol, Math: It is very unlikely that there are any significant
+personal names, company names, or spoken phrases that contain
+mathematical symbols. Further, many of these symbols are the same or
+similar to other punctuation, thereby leading to ambiguity. For this
+reason, math-specific symbols are prohibited. These prohibited math
+symbols are:
+
+00AC        NOT SIGN
+00B1        PLUS-MINUS SIGN
+2200-22FF   [MATHEMATICAL OPERATORS]
+
+Further, the following characters canonicalize to characters in the
+above math list, and therefore are also prohibited:
+
+00BC        VULGAR FRACTION ONE QUARTER
+00BD        VULGAR FRACTION ONE HALF
+00BE        VULGAR FRACTION THREE QUARTERS
+207B        SUPERSCRIPT MINUS
+208B        SUBSCRIPT MINUS
+2153        VULGAR FRACTION ONE THIRD
+2154        VULGAR FRACTION TWO THIRDS
+2155        VULGAR FRACTION ONE FIFTH
+2156        VULGAR FRACTION TWO FIFTHS
+2157        VULGAR FRACTION THREE FIFTHS
+2158        VULGAR FRACTION FOUR FIFTHS
+2159        VULGAR FRACTION ONE SIXTH
+215A        VULGAR FRACTION FIVE SIXTHS
+215B        VULGAR FRACTION ONE EIGHTH
+215C        VULGAR FRACTION THREE EIGHTHS
+215D        VULGAR FRACTION FIVE EIGHTHS
+215E        VULGAR FRACTION SEVEN EIGHTHS
+215F        FRACTION NUMERATOR ONE
+33A7        SQUARE M OVER S
+33A8        SQUARE M OVER S SQUARED
+33AE        SQUARE RAD OVER S
+33AF        SQUARE RAD OVER S SQUARED
+33C6        SQUARE C OVER KG
+
+Symbol, Other: This category covers a multitude of symbols, few of which
+would ever appear in personal names, company names, and spoken phrases.
+The rest of the prohibited symbols are:
+
+2190-21FF   [ARROWS]
+2300-23FF   [MISCELLANEOUS TECHNICAL]
+2400-243F   [CONTROL PICTURES]
+2440-245F   [OPTICAL CHARACTER RECOGNITION]
+2500-257F   [BOX DRAWING]
+2580-259F   [BLOCK ELEMENTS]
+25A0-25FF   [GEOMETRIC SHAPES]
+2600-267F   [MISCELLANEOUS SYMBOLS]
+2700-27BF   [DINGBATS]
+2800-287F   [BRAILLE PATTERNS]
+
+3.7 Additional prohibited characters
+
+3.7.1 Unassigned characters
+
+All characters not yet assigned in [ISO10646] are prohibited. Although
+this may at first seem trivial, it is extremely important because
+characters that may be assigned in the future might have properties that
+would cause them to be prohibited or might have case-folding properties.
+As is the case of all prohibited characters, if a DNS server receives a
+request containing an unassigned character, then the IDN protocol MUST
+return an error message.
+
+3.7.2 Surrogate characters
+
+So far, all proposals for binary encodings of internationalized name
+parts have specified UTF-8 as the encoding format. In such an encoding,
+surrogate characters MUST NOT be used. Therefore, for UTF-8 encodings,
+the following are prohibited:
+
+D800-DFFF   [SURROGATE CHARACTERS]
+
+3.7.3 Uppercase characters with no lowercase mappings
+
+There are many uppercase characters in [ISO10646] which do not have
+lowercase equivalents in [UniData]. Therefore, they are prohibited on
+input because they would get through the case mapping step while still
+being in uppercase.
+
+The characters that are prohibited on input because they are uppercase
+but have no lowercase mappings are:
+
+03D2        GREEK UPSILON WITH HOOK SYMBOL
+03D3        GREEK UPSILON WITH ACUTE AND HOOK SYMBOL
+03D4        GREEK UPSILON WITH DIAERESIS AND HOOK SYMBOL
+04C0        CYRILLIC LETTER PALOCHKA
+10A0-10C5   [GEORGIAN CAPITAL LETTERS]
+
+Note that many characters in the range U+1200 to U+213A, the letterlike
+symbols, also are uppercase but have no lowercase mappings. However,
+they are not listed here because the entire range is already prohibited
+in section 3.6.
+
+3.7.4 Radicals and Ideographic Description
+
+Some Han characters can be informally defined in terms of ideographic
+descriptions. However, ideographic descriptions can lead to multiple
+character streams leading to the same character in a fashion that does
+not canonicalize. Thus, the radicals for ideographic description and the
+ideographic description characters themselves are prohibited. These
+characters are:
+
+2E80-2EFF   [CJK RADICALS SUPPLEMENT]
+2F00-2FDF   [KANGXI RADICALS]
+2FF0-2FFF   [IDEOGRAPHIC DESCRIPTION CHARACTERS]
+
+3.8 Summary of prohibited characters
+
+The following is a collected list from the previous sections.
+
+0000-001F   [CONTROL CHARACTERS]
+0020        SPACE
+0022        QUOTATION MARK
+0023        NUMBER SIGN
+0024        DOLLAR SIGN
+0025        PERCENT SIGN
+0026        AMPERSAND
+002B        PLUS SIGN
+002C        COMMA
+002E        FULL STOP
+002E        FULL STOP
+002F        SOLIDUS
+003A        COLON
+003B        SEMICOLON
+003C        LESS-THAN SIGN
+003D        EQUALS SIGN
+003E        GREATER-THAN SIGN
+003F        QUESTION MARK
+0040        COMMERCIAL AT
+005B        LEFT SQUARE BRACKET
+005C        REVERSE SOLIDUS
+005D        RIGHT SQUARE BRACKET
+007F        DELETE
+0080-009F   [CONTROL CHARACTERS]
+00A0        NO-BREAK SPACE
+00AC        NOT SIGN
+00AD        SOFT HYPHEN
+00B1        PLUS-MINUS SIGN
+00BC        VULGAR FRACTION ONE QUARTER
+00BD        VULGAR FRACTION ONE HALF
+00BE        VULGAR FRACTION THREE QUARTERS
+00D7        MULTIPLICATION SIGN
+01C3        LATIN LETTER RETROFLEX CLICK
+02B0-02FF   [SPACING MODIFIER LETTERS]
+037E        GREEK QUESTION MARK
+037E        GREEK QUESTION MARK
+03D2        GREEK UPSILON WITH HOOK SYMBOL
+03D3        GREEK UPSILON WITH ACUTE AND HOOK SYMBOL
+03D4        GREEK UPSILON WITH DIAERESIS AND HOOK SYMBOL
+04C0        CYRILLIC LETTER PALOCHKA
+0589        ARMENIAN FULL STOP
+060C        ARABIC COMMA
+061B        ARABIC SEMICOLON
+066A        ARABIC PERCENT SIGN
+066D        ARABIC FIVE POINTED STAR
+06D4        ARABIC FULL STOP
+070F        SYRIAC ABBREVIATION MARK
+10A0-10C5   [GEORGIAN CAPITAL LETTERS]
+1680        OGHAM SPACE MARK
+1806        MONGOLIAN TODO SOFT HYPHEN
+180B        MONGOLIAN FREE VARIATION SELECTOR ONE
+180C        MONGOLIAN FREE VARIATION SELECTOR TWO
+180D        MONGOLIAN FREE VARIATION SELECTOR THREE
+180E        MONGOLIAN VOWEL SEPARATOR
+2000-200B   [SPACES]
+200C        ZERO WIDTH NON-JOINER
+200D        ZERO WIDTH JOINER
+200E        LEFT-TO-RIGHT MARK
+200F        RIGHT-TO-LEFT MARK
+2010        HYPHEN
+2011        NON-BREAKING HYPHEN
+2012        FIGURE DASH
+2013        EN DASH
+2014        EM DASH
+201A        SINGLE LOW-9 QUOTATION MARK
+2024        ONE DOT LEADER
+2025        TWO DOT LEADER
+2026        HORIZONTAL ELLIPSIS
+2028        LINE SEPARATOR
+2029        PARAGRAPH SEPARATOR
+202A        LEFT-TO-RIGHT EMBEDDING
+202B        RIGHT-TO-LEFT EMBEDDING
+202C        POP DIRECTIONAL FORMATTING
+202D        LEFT-TO-RIGHT OVERRIDE
+202E        RIGHT-TO-LEFT OVERRIDE
+202F        NARROW NO-BREAK SPACE
+2030        PER MILLE SIGN
+2031        PER TEN THOUSAND SIGN
+2033        DOUBLE PRIME
+2039        SINGLE LEFT-POINTING ANGLE QUOTATION MARK
+203A        SINGLE RIGHT-POINTING ANGLE QUOTATION MARK
+203D        INTERROBANG
+2044        FRACTION SLASH
+2048        QUESTION EXCLAMATION MARK
+2049        EXCLAMATION QUESTION MARK
+206A        INHIBIT SYMMETRIC SWAPPING
+206B        ACTIVATE SYMMETRIC SWAPPING
+206C        INHIBIT ARABIC FORM SHAPING
+206D        ACTIVATE ARABIC FORM SHAPING
+206E        NATIONAL DIGIT SHAPES
+206F        NOMINAL DIGIT SHAPES
+207A        SUPERSCRIPT PLUS SIGN
+207B        SUPERSCRIPT MINUS
+207C        SUPERSCRIPT EQUALS SIGN
+208A        SUBSCRIPT PLUS SIGN
+208B        SUBSCRIPT MINUS
+208C        SUBSCRIPT EQUALS SIGN
+2100        ACCOUNT OF
+2101        ADDRESSED TO THE SUBJECT
+2105        CARE OF
+2106        CADA UNA
+2153        VULGAR FRACTION ONE THIRD
+2154        VULGAR FRACTION TWO THIRDS
+2155        VULGAR FRACTION ONE FIFTH
+2156        VULGAR FRACTION TWO FIFTHS
+2157        VULGAR FRACTION THREE FIFTHS
+2158        VULGAR FRACTION FOUR FIFTHS
+2159        VULGAR FRACTION ONE SIXTH
+215A        VULGAR FRACTION FIVE SIXTHS
+215B        VULGAR FRACTION ONE EIGHTH
+215C        VULGAR FRACTION THREE EIGHTHS
+215D        VULGAR FRACTION FIVE EIGHTHS
+215E        VULGAR FRACTION SEVEN EIGHTHS
+215F        FRACTION NUMERATOR ONE
+2160-217F   [ROMAN NUMERALS]
+2190-21FF   [ARROWS]
+2200-22FF   [MATHEMATICAL OPERATORS]
+2300-23FF   [MISCELLANEOUS TECHNICAL]
+2400-243F   [CONTROL PICTURES]
+2440-245F   [OPTICAL CHARACTER RECOGNITION]
+2488        DIGIT ONE FULL STOP
+2489        DIGIT TWO FULL STOP
+248A        DIGIT THREE FULL STOP
+248B        DIGIT FOUR FULL STOP
+248C        DIGIT FIVE FULL STOP
+248D        DIGIT SIX FULL STOP
+248E        DIGIT SEVEN FULL STOP
+248F        DIGIT EIGHT FULL STOP
+2490        DIGIT NINE FULL STOP
+2491        NUMBER TEN FULL STOP
+2492        NUMBER ELEVEN FULL STOP
+2493        NUMBER TWELVE FULL STOP
+2494        NUMBER THIRTEEN FULL STOP
+2495        NUMBER FOURTEEN FULL STOP
+2496        NUMBER FIFTEEN FULL STOP
+2497        NUMBER SIXTEEN FULL STOP
+2498        NUMBER SEVENTEEN FULL STOP
+2499        NUMBER EIGHTEEN FULL STOP
+249A        NUMBER NINETEEN FULL STOP
+249B        NUMBER TWENTY FULL STOP
+2500-257F   [BOX DRAWING]
+2580-259F   [BLOCK ELEMENTS]
+25A0-25FF   [GEOMETRIC SHAPES]
+2600-267F   [MISCELLANEOUS SYMBOLS]
+2700-27BF   [DINGBATS]
+2800-287F   [BRAILLE PATTERNS]
+2E80-2EFF   [CJK RADICALS SUPPLEMENT]
+2F00-2FDF   [KANGXI RADICALS]
+2FF0-2FFF   [IDEOGRAPHIC DESCRIPTION CHARACTERS]
+3000        IDEOGRAPHIC SPACE
+3001        IDEOGRAPHIC COMMA
+3002        IDEOGRAPHIC FULL STOP
+3003        DITTO MARK
+3008        LEFT ANGLE BRACKET
+3009        RIGHT ANGLE BRACKET
+33A7        SQUARE M OVER S
+33A8        SQUARE M OVER S SQUARED
+33AE        SQUARE RAD OVER S
+33AF        SQUARE RAD OVER S SQUARED
+33C2        SQUARE AM
+33C2        SQUARE AM
+33C6        SQUARE C OVER KG
+33C7        SQUARE CO
+33D8        SQUARE PM
+33D8        SQUARE PM
+D800-DFFF   [SURROGATE CHARACTERS]
+E000-F8FF   [PRIVATE USE, PLANE 0]
+FB1D-FB4F   [HEBREW PRESENTATION FORMS]
+FB50-FDFF   [ARABIC PRESENTATION FORMS A]
+FE20-FE2F   [COMBINING HALF MARKS]
+FE30-FE4F   [CJK COMPATIBILITY FORMS]
+FE50-FE6F   [SMALL FORM VARIANTS]
+FE70-FEFC   [ARABIC PRESENTATION FORMS B]
+FEFF        ZERO WIDTH NO-BREAK SPACE
+FF00-FFEF   [HALFWIDTH AND FULLWIDTH FORMS]
+FFF9        INTERLINEAR ANNOTATION ANCHOR
+FFFA        INTERLINEAR ANNOTATION SEPARATOR
+FFFB        INTERLINEAR ANNOTATION TERMINATOR
+FFFC        OBJECT REPLACEMENT CHARACTER
+FFFD        REPLACEMENT CHARACTER
+Unassigned characters
+
+
+4. Case Folding
+
+After it has been verified that the input text has none of the
+characters prohibited for case folding, the case-folding step itself is
+quite straight-forward. For each character in the input, if there is a
+lowercase mapping for that character in [UniData], the input character
+is changed to the mapped lowercase letter.
+
+
+5. Canonicalization
+
+After case folding, the input string is normalized using form KC, as
+described in [UTR15].
+
+6. IDN Table Revisions
+
+A table consisting of all characters allowed and prohibited and the
+rules for case folding and canonicalization will be created based on the
+content of the [UniData] and on the content of this document. This table
+will be the authority for implementations to follow and will be
+normatively referenced by this document. Such a table will enable the
+IDN protocol to have versions independent of the revisions to Unicode
+and/or to ISO 10646 because the revision of IDN and its deployment may
+not in sync with revisions to Unicode and ISO 10646.
+
+In a future draft of this document, IANA will be asked to keep this
+table, with an initial version number of 1. Each new version of the
+table will have a new, higher version number.
+
+
+7. Security Considerations
+
+Much of the security of the Internet relies on the DNS. Thus, any change
+to the characteristics of the DNS can change the security of much of the
+Internet.
+
+Host 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 host name.
+
+
+8. References
+
+[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name
+Proposals", draft-ietf-idn-compare.
+
+[IDNReq] James Seng, "Requirements of Internationalized Domain Names",
+draft-ietf-idn-requirement.
+
+[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
+technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part
+1: Architecture and Basic Multilingual Plane.  Five amendments and a
+technical corrigendum have been published up to now. UTF-16 is described
+in Annex Q, published as Amendment 1. 17 other amendments are currently
+at various stages of standardization. [[[ THIS REFERENCE NEEDS TO BE
+UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
+
+[Normalize] Character Normalization in IETF Protocols,
+draft-duerst-i18n-norm-03
+
+[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels", March 1997, RFC 2119.
+
+[RFC2396] Tim Berners-Lee, et. al., "Uniform Resource Identifiers (URI):
+Generic Syntax", August 1998, RFC 2396.
+
+[RFC2732] Robert Hinden, et. al., Format for Literal IPv6 Addresses in
+URL's, December 1999, RFC 2732.
+
+[STD13] Paul Mockapetris, "Domain names - implementation and
+specification", November 1987, STD 13 (RFC 1035).
+
+[Unicode3] The Unicode Consortium, "The Unicode Standard -- Version
+3.0", ISBN 0-201-61633-5. Described at
+<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
+
+[UniData] The Unicode Consortium. UnicodeData File.
+<ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt>.
+
+[UTR15] Mark Davis and Martin Duerst. Unicode Normalization Forms.
+Unicode Technical Report #15.
+<http://www.unicode.org/unicode/reports/tr15/>.
+
+
+A. Acknowledgements
+
+Many people from the IETF IDN Working Group and the Unicode Technical
+Committee contributed ideas that went into the first draft of this
+document. Mark Davis was particularly helpful in some of the early
+ideas.
+
+
+B. Changes From Previous Versions of this Draft
+
+This is the -00 version, so there are no changes.
+
+
+C. IANA Considerations
+
+There are no specific IANA considerations in this draft, but there will
+be in a future draft of this document.
+
+
+D. Author Contact Information
+
+Paul Hoffman
+Internet Mail Consortium and VPN Consortium
+127 Segre Place
+Santa Cruz, CA  95060 USA
+paul.hoffman@imc.org and paul.hoffman@vpnc.org
+
+Marc Blanchet
+Viagenie inc.
+2875 boul. Laurier, bur. 300
+Ste-Foy, Quebec, Canada, G1V 2M2
+Marc.Blanchet@viagenie.qc.ca
diff --git a/doc/draft/draft-ietf-idn-race-03.txt b/doc/draft/draft-ietf-idn-race-03.txt
new file mode 100644
index 00000000..9b8db38f
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-race-03.txt
@@ -0,0 +1,588 @@
+Internet Draft                                          Paul Hoffman
+draft-ietf-idn-race-03.txt                                IMC & VPNC
+November 22, 2000
+Expires in six months                         
+
+        RACE: Row-based ASCII Compatible Encoding for IDN
+
+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 describes a transformation method for representing
+non-ASCII characters in host name parts in a fashion that is completely
+compatible with the current DNS. It is a potential candidate for an
+ASCII-Compatible Encoding (ACE) for internationalized host names, as
+described in the comparison document from the IETF IDN Working Group.
+This method is based on the observation that many internationalized
+host name parts will have all their characters in one row of the ISO
+10646 repertoire.
+
+
+1. Introduction
+
+There is a strong world-wide desire to use characters other than plain
+ASCII in host names. Host names have become the equivalent of business
+or product names for many services on the Internet, so there is a need
+to make them usable by people whose native scripts are not representable
+by ASCII. The requirements for internationalizing host names are
+described in the IDN WG's requirements document, [IDNReq].
+
+The IDN WG's comparison document [IDNComp] describes three potential
+main architectures for IDN: arch-1 (just send binary), arch-2 (send
+binary or ACE), and arch-3 (just send ACE). RACE is an ACE, called
+Row-based ACE or RACE, that can be used with protocols that match arch-2
+or arch-3. RACE specifies an ACE format as specified in ace-1 in
+[IDNComp]. Further, it specifies an identifying mechanism for ace-2 in
+[IDNComp], namely ace-2.1.1 (add hopefully-unique legal tag to the
+beginning of the name part).
+
+Author's note: although earlier drafts of this document supported the
+ideas in arch-3, I no longer support that idea and instead only support
+arch-2. Of course, someone else might right an IDN proposal that matches
+arch-3 and use RACE as the protocol.
+
+In formal terms, RACE describes a character encoding scheme of the
+ISO/IEC 10646 [ISO10646] coded character set (whose assignment of
+characters is synchronized with Unicode [Unicode3]) and the rules for
+using that scheme in the DNS. As such, it could also be called a
+"charset" as defined in [IDNReq].
+
+The RACE protocol has the following features:
+
+- There is exactly one way to convert internationalized host parts to
+and from RACE parts. Host name part uniqueness is preserved.
+
+- Host parts that have no international characters are not changed.
+
+- Names using RACE can include more internationalized characters than
+with other ACE protocols that have been suggested to date. Names in the
+Han, Yi, Hangul syllables, or Ethiopic scripts can have up to 17
+characters, and names in most other scripts can have up to 35
+characters. Further, a name that consist of characters from one
+non-Latin script but also contains some Latin characters such as digits
+or hyphens can have close to 33 characters.
+
+It is important to note that the following sections contain many
+normative statements with "MUST" and "MUST NOT". Any implementation that
+does not follow these statements exactly is likely to cause damage to
+the Internet by creating non-unique representations of host names.
+
+1.1 Terminology
+
+The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
+"MAY" in this document are to be interpreted as described in RFC 2119
+[RFC2119].
+
+Hexadecimal values are shown preceded with an "0x". For example,
+"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
+shown preceded with an "0b". For example, a nine-bit value might be
+shown as "0b101101111".
+
+Examples in this document use the notation from the Unicode Standard
+[Unicode3] as well as the ISO 10646 names. For example, the letter "a"
+may be represented as either "U+0061" or "LATIN SMALL LETTER A".
+
+RACE converts strings with internationalized characters into
+strings of US-ASCII that are acceptable as host name parts in current
+DNS host naming usage. The former are called "pre-converted" and the
+latter are called "post-converted".
+
+1.2 IDN summary
+
+Using the terminology in [IDNComp], RACE specifies an ACE format as
+specified in ace-1. Further, it specifies an identifying mechanism for
+ace-2, namely ace-2.1.1 (add hopefully-unique legal tag to the beginning
+of the name part).
+
+RACE has the following length characteristics. In this list, "row" means
+a row from ISO 10646.
+
+- If the characters in the input all come from the same row, up to 35
+characters per name part are allowed.
+
+- If the characters in the input come from two or more rows, neither of
+which is row 0, up to 17 characters per name part are allowed.
+
+- If the characters in the input come from two rows, one of which is row
+0, between 17 and 33 characters per name part are allowed.
+
+
+2. Host Part Transformation
+
+According to [STD13], host parts must be case-insensitive, start and
+end with a letter or digit, and contain only letters, digits, and the
+hyphen character ("-"). This, of course, excludes any internationalized
+characters, as well as many other characters in the ASCII character
+repertoire. Further, domain name parts must be 63 octets or shorter in
+length.
+
+2.1 Name tagging
+
+All post-converted name parts that contain internationalized characters
+begin with the string "bq--". (Of course, because host name parts are
+case-insensitive, this might also be represented as "Bq--" or "bQ--" or
+"BQ--".) The string "bq--" was chosen because it is extremely unlikely
+to exist in host parts before this specification was produced. As a
+historical note, in late August 2000, none of the second-level host name
+parts in any of the .com, .edu, .net, and .org top-level domains began
+with "bq--"; there are many tens of thousands of other strings of three
+characters followed by a hyphen that have this property and could be
+used instead. The string "bq--" will change to other strings with the
+same properties in future versions of this draft.
+
+Note that a zone administrator might still choose to use "bq--" at the
+beginning of a host name part even if that part does not contain
+internationalized characters. Zone administrators SHOULD NOT create host
+part names that begin with "bq--" unless those names are post-converted
+names. Creating host part names that begin with "bq--" but that are not
+post-converted names may cause two distinct problems. Some display
+systems, after converting the post-converted name part back to an
+internationalized name part, might display the name parts in a
+possibly-confusing fashion to users. More seriously, some resolvers,
+after converting the post-converted name part back to an
+internationalized name part, might reject the host name if it contains
+illegal characters.
+
+2.2 Converting an internationalized name to an ACE name part
+
+To convert a string of internationalized characters into an ACE name
+part, the following steps MUST be preformed in the exact order of the
+subsections given here.
+
+If a name part consists exclusively of characters that conform to the
+host name requirements in [STD13], the name MUST NOT be converted to
+LACE. That is, a name part that can be represented without LACE MUST NOT
+be encoded using LACE. This absolute requirement prevents there from
+being two different encodings for a single DNS host name.
+
+If any checking for prohibited name parts (such as ones that are
+prohibited characters, case-folding, or canonicalization) is to be done,
+it MUST be done before doing the conversion to an ACE name part.
+
+Characters outside the first plane of characters (those with codepoints
+above U+FFFF) MUST be represented using surrogates, as described in the
+UTF-16 description in ISO 10646.
+
+The input name string consists of characters from the ISO 10646
+character set in big-endian UTF-16 encoding. This is the pre-converted
+string.
+
+2.2.1 Check the input string for disallowed names
+
+If the input string consists only of characters that conform to the host
+name requirements in [STD13], the conversion MUST stop with an error.
+
+2.2.2 Compress the pre-converted string
+
+The entire pre-converted string MUST be compressed using the compression
+algorithm specified in section 2.4. The result of this step is the
+compressed string.
+
+2.2.3 Check the length of the compressed string
+
+The compressed string MUST be 36 octets or shorter. If the compressed
+string is 37 octets or longer, the conversion MUST stop with an error.
+
+2.2.4 Encode the compressed string with Base32
+
+The compressed string MUST be converted using the Base32 encoding
+described in section 2.5. The result of this step is the encoded string.
+
+2.2.5 Prepend "bq--" to the encoded string and finish
+
+Prepend the characters "bq--" to the encoded string. This is the host
+name part that can be used in DNS resolution.
+
+2.3 Converting a host name part to an internationalized name
+
+The input string for conversion is a valid host name part. Note that if
+any checking for prohibited name parts (such as prohibited characters,
+case-folding, or canonicalization is to be done, it MUST be done after
+doing the conversion from an ACE name part.
+
+If a decoded name part consists exclusively of characters that conform
+to the host name requirements in [STD13], the conversion from LACE MUST
+fail. Because a name part that can be represented without LACE MUST NOT
+be encoded using LACE, the decoding process MUST check for name parts
+that consists exclusively of characters that conform to the host name
+requirements in [STD13] and, if such a name part is found, MUST
+beconsidered an error (and possibly a security violation).
+
+2.3.1 Strip the "bq--"
+
+The input string MUST begin with the characters "bq--". If it does not,
+the conversion MUST stop with an error. Otherwise, remove the characters
+"bq--" from the input string. The result of this step is the stripped
+string.
+
+2.3.2 Decode the stripped string with Base32
+
+The entire stripped string MUST be checked to see if it is valid Base32
+output. The entire stripped string MUST be changed to all lower-case
+letters and digits. If any resulting characters are not in Table 1, the
+conversion MUST stop with an error; the input string is the
+post-converted string. Otherwise, the entire resulting string MUST be
+converted to a binary format using the Base32 decoding described in
+section 2.5. The result of this step is the decoded string.
+
+2.3.3 Decompress the decoded string
+
+The entire decoded string MUST be converted to ISO 10646 characters
+using the decompression algorithm described in section 2.4. The result
+of this is the internationalized string.
+
+2.3.4 Check the internationalized string for disallowed names
+
+If the internationalized string consists only of characters that conform
+to the host name requirements in [STD13], the conversion MUST stop with
+an error.
+
+2.4 Compression algorithm
+
+The basic method for compression is to reduce a full string that
+consists of characters all from a single row of the ISO 10646
+repertoire, or all from a single row plus from row 0, to as few octets
+as possible. Any full string that has characters that come from two
+rows, neither of which are row 0, or three or more rows, has all the
+octets of the input string in the output string.
+
+If the string comes from only one row, compression is to one octet per
+character in the string. If the string comes from only one row other
+than row 0, but also has characters only from row 0, compression is to
+one octet for the characters from the non-0 row and two octets for the
+characters from row 0. Otherwise, there is no compression and the output
+is a string that has two octets per input character.
+
+The compressed string always has a one-octet header. If the string comes
+from only one row, the header octet is the upper octet of the
+characters. If the string comes from only one row other than row 0, but
+also has characters only from row 0, the header octet is the upper octet
+of the characters from the non-0 row. Otherwise, the header octet is
+0xD8, which is the upper octet of a surrogate pair. Design note: It is
+impossible to have a legal stream of UTF-16 characters that has all the
+upper octets being 0xD8 because a character whose upper octet is 0xD8
+must be followed by one whose upper octet is in the range 0xDC through
+0xDF.
+
+Although the two-octet mode limits the number of characters in a RACE
+name part to 17, this is still generally enough for almost all names in
+almost scripts. Also, this limit is close to the limits set by other
+encoding proposals.
+
+Note that the compression and decompression rules MUST be followed
+exactly. This requirement prevents a single host name part from having
+two encodings. Thus, for any input to the algorithm, there is only one
+possible output. An implementation cannot chose to use one-octet mode or
+two-octet mode using anything other than the logic given in this
+section.
+
+2.4.1 Compressing a string
+
+The input string is in big-endian UTF-16 encoding with no byte order
+mark.
+
+Design note: No checking is done on the input to this algorithm. It is
+assumed that all checking for valid ISO/IEC 10646 characters has already
+been done by a previous step in the conversion process.
+
+Design note: In step 5, 0xFF was chosen as the escape character because
+it appears in the fewest number of scripts in ISO 10646, and therefore
+the "escaped escape" will be needed the least. 0x99 was chosen as the
+second octet for the "escaped escape" because the character U+0099 has
+no value, and is not even used as a control character in the C1 controls
+or in ISO 6429.
+
+1) Starting at the beginning of the input, read each pair of octets in
+the input stream, comparing the upper octet of each. Reset the input
+pointer to the beginning of the input again. If all of the upper octets
+(called U1) are the same, go to step 4. Note that if the input is only
+one character, this test will always be true.
+
+2) Read each pair of octets in the input stream, comparing the upper
+octet of each. Reset the input pointer to the beginning of the input
+again. If all of the upper octets are either 0x00 or one single other
+value (called U1), go to step 4.
+
+3) Output 0xD8, followed by the entire input stream. Finish.
+
+4) If U1 is in the range 0xD8 to 0xDC, stop with an error. Otherwise,
+output U1.
+
+5) If you are at the end of the input string, finish. Otherwise, read
+the next octet, called U2, and the octet after that, called N1. If U2 is
+0x00 and N1 is 0x99, stop with an error.
+
+6) If U2 is equal to U1, and N1 is not equal to 0xFF, output N1, and go
+to step 5.
+
+7) If U2 is equal to U1, and N1 is equal to 0xFF, output 0xFF followed
+by 0x99, and go to step 5.
+
+8) Output 0xFF followed by N1. Go to step 5.
+
+2.4.2 Decompressing a string
+
+1) Read the first octet of the input string. Call the value of the first
+octet U1. If there are no more octets in the input string (that is, if
+the input string had only one octet total), stop with an error. If U1 is
+0xD8, go to step 8.
+
+2) If you are at the end of the input string, go to step 11. Otherwise,
+read the next octet in the input string, called N1. If N1 is 0xFF, go to
+step 5.
+
+3) If U1 is 0x00 and N1 is 0x99, stop with an error.
+
+4) Put U1 followed by N1 in the output buffer. Go to step 2.
+
+5) If you are at the end of the input string, stop with an error.
+
+6) Read the next octet of the input string, called N1. If N1 is 0x99,
+put U1 followed by 0xFF in the output buffer, and go to step 2.
+
+7) Put 0x00 followed by N1 in the output buffer. Go to step 2.
+
+8) Read the rest of the input stream into a temporary string called
+LCHECK. If the length of LCHECK is an odd number, stop with an error.
+
+9) Perform the checks from steps 1 and 2 of the compression algorithm in
+section 2.4.1 on LCHECK. If either checks pass (that is, if either would
+have created a compressed string), stop with an error because the input
+to the decompression is in the wrong format.
+
+10) If the length of LCHECK is odd, stop with and error. Otherwise,
+output LCHECK and finish.
+
+11) If the length of the output buffer is odd, stop with and error.
+Otherwise, emit the output buffer and finish.
+
+2.4.3 Compression examples
+
+For the input string of <U+012D><U+0111><U+014B>, all characters are in
+the same row, 0x01. Thus, the output is 0x012D114B.
+
+For the input string of <U+012D><U+00E0><U+014B>, the characters are all
+in row 0x01 or row 0x00. Thus, the output is 0x012DFFE04B.
+
+For the input string of <U+1290><U+12FF><U+120C>, the characters are all
+in row 0x12. Thus, the output is 0x1290FF990C.
+
+For the input string of <U+012D><U+00E0><U+24D3>, the characters are
+from two rows other than 0x00. Thus, the output is 0xD8012D00E024D3.
+
+2.5 Base32
+
+In order to encode non-ASCII characters in DNS-compatible host name parts,
+they must be converted into legal characters. This is done with Base32
+encoding, described here.
+
+Table 1 shows the mapping between input bits and output characters in
+Base32. Design note: the digits used in Base32 are "2" through "7"
+instead of "0" through "6" in order to avoid digits "0" and "1". This
+helps reduce errors for users who are entering a Base32 stream and may
+misinterpret a "0" for an "O" or a "1" for an "l".
+
+                    Table 1: Base32 conversion
+             bits   char  hex         bits   char  hex
+             00000   a    0x61        10000   q    0x71
+             00001   b    0x62        10001   r    0x72
+             00010   c    0x63        10010   s    0x73
+             00011   d    0x64        10011   t    0x74
+             00100   e    0x65        10100   u    0x75
+             00101   f    0x66        10101   v    0x76
+             00110   g    0x67        10110   w    0x77
+             00111   h    0x68        10111   x    0x78
+             01000   i    0x69        11000   y    0x79
+             01001   j    0x6a        11001   z    0x7a
+             01010   k    0x6b        11010   2    0x32
+             01011   l    0x6c        11011   3    0x33
+             01100   m    0x6d        11100   4    0x34
+             01101   n    0x6e        11101   5    0x35
+             01110   o    0x6f        11110   6    0x36
+             01111   p    0x70        11111   7    0x37
+
+2.5.1 Encoding octets as Base32
+
+The input is a stream of octets. However, the octets are then treated
+as a stream of bits.
+
+Design note: The assumption that the input is a stream of octets
+(instead of a stream of bits) was made so that no padding was needed.
+If you are reusing this algorithm for a stream of bits, you must add a
+padding mechanism in order to differentiate different lengths of input.
+
+1) If the input bit stream is not an even multiple of five bits, pad
+the input stream with 0 bits until it is an even multiple of five bits.
+Set the read pointer to the beginning of the input bit stream.
+
+2) Look at the five bits after the read pointer.
+
+3) Look up the value of the set of five bits in the bits column of
+Table 1, and output the character from the char column (whose hex value
+is in the hex column).
+
+4) Move the read pointer five bits forward. If the read pointer is at
+the end of the input bit stream (that is, there are no more bits in the
+input), stop. Otherwise, go to step 2.
+
+2.5.2 Decoding Base32 as octets
+
+The input is octets in network byte order. The input octets MUST be
+values from the second column in Table 1.
+
+1) Count the number of octets in the input and divide it by 8; call the
+remainder INPUTCHECK. If INPUTCHECK is 1 or 3 or 6, stop with an error.
+
+2) Set the read pointer to the beginning of the input octet stream.
+
+3) Look up the character value of the octet in the char column (or hex
+value in hex column) of Table 1, and add the five bits from the bits
+column to the output buffer.
+
+4) Move the read pointer one octet forward. If the read pointer is not
+at the end of the input octet stream (that is, there are more octets in
+the input), go to step 3.
+
+5) Count the number of bits that are in the output buffer and divide it
+by 8; call the remainder PADDING. If the PADDING number of bits at the
+end of the output buffer are not all zero, stop with an error.
+Otherwise, emit the output buffer and stop.
+
+2.5.3 Base32 example
+
+Assume you want to encode the value 0x3a270f93. The bit string is:
+
+3   a    2   7    0   f    9   3
+00111010 00100111 00001111 10010011
+
+Broken into chunks of five bits, this is:
+
+00111 01000 10011 10000 11111 00100 11
+
+Padding is added to make the last chunk five bits:
+
+00111 01000 10011 10000 11111 00100 11000
+
+The output of encoding is:
+
+00111 01000 10011 10000 11111 00100 11000
+  h     i     t     q     7     e     y
+or "hitq7ey".
+
+
+3. Security Considerations
+
+Much of the security of the Internet relies on the DNS. Thus, any
+change to the characteristics of the DNS can change the security of
+much of the Internet. Thus, RACE makes no changes to the DNS
+itself.
+
+Host 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 host
+name.
+
+RACE is designed so that every internationalized host name part
+can be represented as one and only one DNS-compatible string. If there
+is any way to follow the steps in this document and get two or more
+different results, it is a severe and fatal error in the protocol.
+
+
+4. References
+
+[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals",
+draft-ietf-idn-compare.
+
+[IDNReq] James Seng, "Requirements of Internationalized Domain Names",
+draft-ietf-idn-requirement.
+
+[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
+technology -- Universal Multiple-Octet Coded Character Set (UCS) --
+Part 1: Architecture and Basic Multilingual Plane.  Five amendments and
+a technical corrigendum have been published up to now. UTF-16 is
+described in Annex Q, published as Amendment 1. 17 other amendments are
+currently at various stages of standardization. [[[ THIS REFERENCE
+NEEDS TO BE UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
+
+[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels", March 1997, RFC 2119.
+
+[STD13] Paul Mockapetris, "Domain names - implementation and
+specification", November 1987, STD 13 (RFC 1035).
+
+[Unicode3] The Unicode Consortium, "The Unicode Standard -- Version
+3.0", ISBN 0-201-61633-5. Described at
+<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
+
+
+A. Acknowledgements
+
+Mark Davis contributed many ideas to the initial draft of this document,
+as well as comments in later versions. Graham Klyne and Martin Duerst
+offered technical comments on the algorithms used. GIM Gyeongseog and
+Pongtorn Jentaweepornkul helped fix technical errors in early drafts.
+Rick Wesson and Mark Davis contributed many suggestions on error
+conditions in the processing.
+
+Base32 is quite obviously inspired by the tried-and-true Base64
+Content-Transfer-Encoding from MIME.
+
+
+
+B. Changes from Versions -02 to -03 of this Draft
+
+1: Wording corrections to third paragraph.
+
+2.2 and 2.3: Added need to check for all-STD13.
+
+2.4.1: Wording corrections in the first two paragraphs. Made step 1 and
+2 clearer with resetting the input pointer. Also added sentence at the
+end of step 1. Also added error conditions in steps 4 and 5.
+
+2.4.2: Added error condition in step 1. Added a new step 3 for an error
+check. Expanded step 8 to check for malformed input error. Added error
+check for odd-length output.
+
+2.4.3: Changed all the examples to use lowercase characters on input.
+ 
+2.5.1: Made the list of steps shorter by padding with 0 bits at the
+beginning of the steps.
+
+2.5.2: Changed the sense of the test in step 3 and added step 4 to be
+checkfor malformed input. Also made the output a buffer. Also added
+new step 1.
+
+
+C. IANA Considerations
+
+There are no IANA considerations in this document.
+
+
+D. Author Contact Information
+
+Paul Hoffman
+Internet Mail Consortium and VPN Consortium
+127 Segre Place
+Santa Cruz, CA  95060 USA
+paul.hoffman@imc.org and paul.hoffman@vpnc.org
diff --git a/doc/draft/draft-ietf-idn-requirements-03.txt b/doc/draft/draft-ietf-idn-requirements-03.txt
new file mode 100644
index 00000000..24b98689
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-requirements-03.txt
@@ -0,0 +1,564 @@
+IETF IDN Working Group               Editors Zita Wenzel, James Seng
+Internet Draft                       draft-ietf-idn-requirements-03.txt
+28 June 2000                         Expires 28 November 2000
+
+             Requirements of Internationalized Domain Names
+
+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 describes the requirement for encoding international
+characters into DNS names and records. This document is guidance for
+developing protocols for internationalized domain names.
+
+1. Introduction
+
+At present, the encoding of Internet domain names is restricted to a
+subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many
+other text based items on the Internet have already been at least
+partially internationalized. It is important for domain names to be
+similarly internationalized or for an equivalent solution to be found.
+This document assumes that the most effective solution involves putting
+non-ASCII names inside some parts of the overall DNS system.
+
+This document is being discussed on the "idn" mailing list. To join the
+list, send a message to <majordomo@ops.ietf.org> with the words
+"subscribe idn" in the body of the message. Archives of the mailing
+list can also be found at ftp://ops.ietf.org/pub/lists/idn*.
+
+1.1 Definitions and Conventions
+
+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].
+
+Characters mentioned in this document are identified by their position
+in the Unicode [UNICODE] character set. The notation U+12AB, for
+example, indicates the character at position 12AB (hexadecimal) in the
+Unicode character set. Note that the use of this notation is not an
+indication of a requirement to use Unicode.
+
+Examples quoted in this document should be considered as a method to
+further explain the meanings and principles adopted by the document. It
+is not a requirement for the protocol to satisfy the examples.
+
+A character is a member of a set of elements used for organization,
+control, or representation of data.
+
+A coded character is a character with its coded representation.
+
+A coded character set ("CCS") is a set of unambiguous rules that
+establishes a character set and the relationship between the characters
+of the set and their coded representation.
+
+A graphic character or glyph is a character, other than a control
+function, that has a visual representation normally handwritten,
+printed, or displayed.
+
+A character encoding scheme or "CES" is a mapping from one or more
+coded character sets to a set of octets. Some CESs are associated with
+a single CCS; for example, UTF-8 [RFC2279] applies only to ISO 10646.
+Other CESs, such as ISO 2022, are associated with many CCSs.
+
+A charset is a method of mapping a sequence of octets to a sequence of
+abstract characters. A charset is, in effect, a combination of one or
+more CCS with a CES. Charset names are registered by the IANA according
+to procedures documented in [RFC2278].
+
+A language is a way that humans interact. In written form, a language
+is expressed in characters. The same set of characters can often be
+used in many languages, and many languages can be expressed using
+different scripts. A particular charset MAY have different glyphs
+(shapes) depending on the language being used.
+
+1.2 Description of the Domain Name System
+
+The Domain Name System is defined by [RFC1034] and [RFC1035], with
+clarifications, extensions and modifications given in [RFC1123],
+[RFC1996], [RFC2181], and others. Of special importance here is the
+security extensions described in [RFC2535] and companions.
+
+Over the years, many different words have been used to describe the
+components of resource naming on the Internet (e.g., [URI], [URN]); to make
+certain that the set of terms used in this document are well-defined and
+non-ambiguous, the definitions are given here.
+
+A master server for a zone holds the main copy of that zone. This copy
+is sometimes stored in a zone file. A slave server for a zone holds a
+complete copy of the records for that zone. Slave servers MAY be either
+authorized by the zone owner (secondary servers) or unauthorized
+(so-called "stealth secondaries"). Master and authorized slave servers
+are listed in the NS records for the zone, and are termed
+"authoritative" servers. In many contexts, outside this document the
+term "primary" is used interchangeably with "master" and "secondary" is
+used interchangeably with "slave".
+
+A caching server holds temporary copies of DNS records; it uses records
+to answer queries about domain names. Further explanation of these terms
+can be found in [RFC1034] and [RFC1996].
+
+DNS names can be represented in multiple forms, with different
+properties for internationalization. The most important ones are:
+
+- Domain name: The binary representation of a name used internally in
+  the DNS protocol. This consists of a series of components of 1-63
+  octets, with an overall length limited to 255 octets (including the
+  length fields).
+
+- Master file format domain name: This is a representation of the name
+  as a sequence of characters in some character sets; the common
+  convention (derived from [RFC1035] section 5.1) is to represent the
+  octets of the name as ASCII characters where the octet is in the set
+  corresponding to the ASCII values for [a-zA-Z0-9-], using an escape
+  mechanism (\x or \NNN) where not, and separating the components of the
+  name by the dot character (".").
+
+The form specified for most protocols using the DNS is a limited form of
+the master file format domain name. This limited form is defined in
+[RFC1034] Section 3.5 and [RFC1123]. In most implementations of
+applications today, domain names in the Internet have been limited to
+the much more restricted forms used, e.g., in email.   Those names are
+limited to the ASCII upper and lower-case characters (interpreted in a
+case-independent fashion), the digits, and the hyphen.
+
+1.3 Definition of "hostname" and "Internationalized Domain Name"
+
+In the DNS protocols, a name is referred to as a sequence of octets.
+However, when discussing requirements for internationalized domain
+names, what we are looking for are ways to represent characters that
+are meaningful for humans.
+
+In this document, this is referred to as a "hostname". While this term
+has been used for many different purposes over the years, it is used
+here in the sense of "sequence of characters (not octets) representing a
+domain name conforming to the limited hostname syntax".
+
+This document attempts to define the requirements for an
+"Internationalized Domain Name" (IDN). This is defined as a sequence of
+characters that can be used in the context of functions where a hostname
+is used today, but contains one or more characters that are outside the
+set of characters specified as legal characters for host names.
+
+1.4 A multilayer model of the DNS function
+
+The DNS can be seen as a multilayer function:
+
+- The bottom layer is where the packets are passed across the Internet
+  in a DNS query and a DNS response. At this level, what matters is
+  the format and meaning of bits and octets in a DNS packet.
+
+- Above that is the "DNS service", created by an infrastructure of DNS
+  servers, NS records that point to those DNS servers, that is
+  pointed to by the root servers (listed in the "root cache file" on each DNS
+  server, often called "named.cache". It is at this level that the
+  statement "the DNS has a single root" [RFC2826] makes sense, but
+  still, what are being transferred are octets, not characters.
+
+- Interfacing to the user is a service layer, often called "the resolver
+  library", and often embedded in the operating system or system
+  libraries of the client machines. It is at the top of this layer that
+  the API calls commonly known as "gethostbyname" and "gethostbyaddress"
+  reside.  These calls are modified to support IPv6 [RFC2553]. A
+  conceptually similar layer exists in authoritative DNS servers,
+  comprising the parts that generate "meaningful" strings in DNS files.
+  Due to the popularity of the "master file" format, this layer often
+  exists only in the administrative routines of the service maintainers.
+
+- The user of this layer (resolver library) is the application programs
+  that use the DNS, such as mailers, mail servers, Web clients, Web
+  servers, Web caches, IRC clients, FTP clients, distributed file
+  systems, distributed databases, and almost all other applications on
+  TCP/IP.
+
+Graphically, one can illustrate it like this:
+
++---------------+                            +---------------------+
+| Application   |                            | (Base data)         |
++---------------+                            +---------------------+
+      |  Application service interface                 |
+      |  For ex. GethostbyXXXX interface               | (no standard)
++---------------+                            +---------------------+
+| Resolver      |                            | Auth DNS server     |
++---------------+                            +---------------------+
+      |     <-----   DNS service interface   ----->    |
++------------------------------------------------------------------+
+|  DNS service                                                     |
+|  +-----------------------+         +--------------------+        |
+|  | Forwarding DNS server |         | Caching DNS server |        |
+|  +-----------------------+         +--------------------+        |
+|                                                                  |
+|                 +-------------------------+                      |
+|                 | Parent-zone DNS servers |                      |
+|                 +-------------------------+                      |
+|                                                                  |
+|                 +-------------------------+                      |
+|                 | Root DNS servers        |                      |
+|                 +-------------------------+                      |
+|                                                                  |
++------------------------------------------------------------------+
+
+1.5 Service model of the DNS
+
+The Domain Name Service is used for multiple purposes, each of which is
+characterized by what it puts into the system (the query) and what it
+expects as a result (the reply).
+
+The most used ones in the current DNS are:
+
+- Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get
+  back an IPv4 or IPv6 address.
+
+- Hostname-to-Mail server service (MX): As above, but the expected
+  return value is a hostname and a priority for SMTP servers.
+
+- Address-to-hostname service (PTR): Enter an IPv4 or IPv6 address (in
+  in-addr.arpa or ip6.int form respectively) and get back a hostname.
+
+- Domain delegation service (NS). Enter a domain name and get back
+  nameserver records (designated hosts who provides authoritive
+  nameservice) for the domain.
+
+New services are being defined, either as entirely new services (IPv6 to
+hostname mapping using binary labels) or as embellishments to other
+services (DNSSEC returning information about whether a given DNS service
+is performed securely or not).
+
+These services exist, conceptually, at the Application/Resolver
+interface, NOT at the DNS-service interface. This document attempts to
+set requirements for an equivalent of the "used services" given above,
+where "hostname" is replaced by "Internationalized Domain Name". This
+doesn't preclude the fact that IDN should work with any kind of DNS
+queries.  IDN is a new service. Since existing protocols like SMTP or
+HTTP use the old service, it is a matter of great concern how the new
+and old services work together, and how other protocols can take
+advantage of the new service.
+
+2. General Requirements
+
+These requirements address two concerns: The service offered to the
+users (the application service), and the protocol extensions, if needed,
+added to support this service.
+
+In the requirements, we attempt to use the term "service" whenever a
+requirement concerns the service, and "protocol" whenever a requirement
+is believed to constrain the possible implementation.
+
+2.1 Compatibility and Interoperability
+
+[1] The DNS is essential to the entire Internet. Therefore, the service
+MUST NOT damage present DNS protocol interoperability. It MUST make the
+minimum number of changes to existing protocols on all layers of the
+stack. It MUST continue to allow any system anywhere to resolve any
+internationalized domain name.
+
+[2] The service MUST preserve the basic concept and facilities of domain
+names as described in [RFC1034]. It MUST maintain a single, global,
+universal, and consistent hierarchical namespace.
+
+[2.5] The DNS service layer (the packet formats that go on the wire)
+MUST NOT limit the codepoints that can be used. This interface SHOULD
+NOT assign meaning to name strings; the application service layer,
+where "gethostbyname" et al reside, MAY constrain the name strings to
+be used in certain services. (conflict)
+
+[3] The same name resolution request MUST generate the same response,
+regardless of the location or localization settings in the resolver, in
+the master server, and in any slave servers involved in the resolution
+process.
+
+[4] The protocol SHOULD allow creation of caching servers that do
+not understand the charset in which a request or response is encoded.
+The caching server SHOULD perform correctly for IDN as well as for
+current domain names (without the authoritative bit) as the master
+server would have if presented with the same request.
+
+[5] A caching server MUST NOT return data in response to a query that
+would not have been returned if the same query had been presented to an
+authoritative server. This applies fully for the cases when:
+
+- The caching server does not know about IDN
+- The caching server implements the whole specification
+- The caching server implements a valid subset of the specification
+
+[7] The service MAY modify the DNS protocol [RFC1035] and other related
+work undertaken by the [DNSEXT] WG. However, these changes SHOULD be as
+small as possible and any changes SHOULD be coordinated with the
+[DNSEXT] WG.
+
+[8] The protocol supporting the service SHOULD be as simple as possible
+from the user's perspective. Ideally, users SHOULD NOT realize that IDN
+was added on to the existing DNS.
+
+[10] The best solution is one that maintains maximum feasible
+compatibility with current DNS standards as long as it meets the other
+requirements in this document.
+
+2.2 Internationalization
+
+[11] Internationalized characters MUST be allowed to be represented and
+used in DNS names and records. The protocol MUST specify what charset is
+used when resolving domain names and how characters are encoded in DNS
+records.
+
+[12] This document RECOMMENDS Unicode only. If multiple charsets are
+allowed, each charset MUST be tagged and conform to [RFC2277].
+
+[12.5] IDN MUST NOT return illegal code points in responses, SHOULD
+reject queries with illegal codepoints. (one request to add; one request
+to remove)
+
+[13] CES(s) chosen SHOULD NOT encode ASCII characters differently
+depending on the other characters in the string. In other words, unless
+IDN names are identified and coded differently from ASCII-only ones,
+characters in the ASCII set SHOULD remain as specified in [US-ASCII]
+(one request to remove).
+
+[14] The protocol SHOULD NOT invent a new CCS for the purpose of IDN
+only and SHOULD use existing CES. The charset(s) chosen SHOULD also be
+non-ambiguous.
+
+[15] The protocol SHOULD NOT make any assumptions about the location in
+a domain name where internationalization might appear. In other words,
+it SHOULD NOT differentiate between any part of a domain name because
+this MAY impose restrictions on future internationalization efforts.
+
+[16] The protocol also SHOULD NOT make any localized restrictions in the
+protocol. For example, an IDN implementation which only allows domain
+names to use a single local script would immediately restrict
+multinational organization.
+
+[17] While there are a wide range of devices that use the DNS and a wide
+range of characteristics of international scripts and methods of
+domain name input and display, IDN is only concerned with the
+protocol. Therefore, there MUST be a single way of encoding an
+internationalized domain name within the DNS.
+
+[18] The protocol SHOULD NOT place any restrictions on the
+application service layer. It SHOULD only specify changes in the DNS
+service layer and within the DNS itself.
+
+2.4 Canonicalization
+
+Matching rules are a complicated process for IDN. Canonicalization
+of characters MUST follow precise and predictable rules to ensure
+consistency. [CHARREQ] is RECOMMENDED as a guide on canonicalization.
+
+The DNS has to match a host name in a request with a host name held
+in one or more zones. It also needs to sort names into order. It is
+expected that some sort of canonicalization algorithm will be used as
+the first step of this process. This section discusses some of the
+properties which will be REQUIRED of that algorithm.
+
+[22] To achieve interoperability, canonicalization MUST be done at a
+single well-defined place in the DNS resolution process.  The protocol
+MUST specify canonicalization; it MUST specify exactly where in the
+DNS that canonicalization happens and does not happen; it MUST specify
+how additions to ISO 10646 will affect the stability of the DNS and
+the amount of work done on the root DNS servers.
+
+[23] The canonicalization algorithm MAY specify operations for case,
+ligature, and punctuation folding.
+
+[24] In order to retain backwards compatibility with the current DNS,
+the service MUST retain the case-insensitive comparison for [US-ASCII]
+as specified in [RFC1035]. For example, Latin capital letter A (U+0041)
+MUST match Latin small letter a (U+0061). [UTR21] describes some of
+the issues with case mapping. Case-insensitivity for non [US-ASCII]
+MUST be discussed in the protocol proposal.
+
+[25] Case folding MUST be locale independent. For example, Latin
+capital letter I (U+0049) case folded to lower case in the Turkish
+context will become Latin small letter dotless i (U+0131). But in the
+English context, it will become Latin small letter i (U+0069).
+
+[26] If other canonicalization is done, it MUST be done before the
+domain name is resolved. Further, the canonicalization MUST be easily
+upgradable as new languages and writing systems are added.
+
+[27] Any conversion (case, ligature folding, punctuation folding, etc)
+from what the user enters into a client to what the client asks for
+resolution MUST be done identically on any request from any client.
+
+[30] If the charset can be normalized, then it SHOULD be normalized
+before it is used in IDN. Normalization SHOULD follow [UTR15].
+(conflict)
+
+[31] The protocol SHOULD avoid inventing a new normalization form
+provided a technically sufficient one is available.
+
+2.5 Operational Issues
+
+[32] Zone files SHOULD remain easily editable.
+
+[33] An IDN-capable resolver or server SHALL NOT generate more traffic
+than a non-IDN-capable resolver or server would when resolving an
+ASCII-only domain name.  The amount of traffic generated when resolving
+an IDN SHALL be similar to that generated when resolving an ASCII-only
+name.
+
+[34] The service SHOULD NOT add new centralized administration for the
+DNS. A domain administrator SHOULD be able to create internationalized
+names as easily as adding current domain names.
+
+[35] Within a single zone, the zone manager MUST be able to define
+equivalence rules that suit the purpose of the zone, such as, but not
+limited to, and not necessarily, non-ASCII case folding, Unicode
+normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or
+traditional/simplified Chinese equivalence. Such defined equivalences
+MUST NOT remove equivalences that are assumed by (old or
+local-rule-ignorant) caches.
+
+[36] The protocol MUST work with DNSSEC.
+
+[37] The protocol MUST work for all features of DNS, IPv4, and IPv6.
+
+4. Security Considerations
+
+Any solution that meets the requirements in this document MUST NOT be
+less secure than the current DNS. Specifically, the mapping of
+internationalized host names to and from IP addresses MUST have the
+same characteristics as the mapping of today's host names.
+
+Specifying requirements for internationalized domain names does not
+itself raise any new security issues. However, any change to the DNS MAY
+affect the security of any protocol that relies on the DNS or on
+DNS names. A thorough evaluation of those protocols for security
+concerns will be needed when they are developed. In particular, IDNs
+MUST be compatible with DNSSEC and, if multiple charsets or
+representation forms are permitted, the implications of this name-spoof
+MUST be throughly understood.
+
+5. References
+
+[CHARREQ]   "Requirements for string identity matching and String
+            Indexing", http://www.w3.org/TR/WD-charreq, July 1998,
+            World Wide Web Consortium.
+
+[DNSEXT]    "IETF DNS Extensions Working Group",
+            namedroppers@internic.net, Olafur Gudmundson, Randy Bush.
+
+[RFC1034]   "Domain Names - Concepts and Facilities", rfc1034.txt,
+            November 1987, P. Mockapetris.
+
+[RFC1035]   "Domain Names - Implementation and Specification",
+            rfc1035.txt, November 1987, P. Mockapetris.
+
+[RFC1123]   "Requirements for Internet Hosts -- Application and
+            Support", rfc1123.txt, October 1989, R. Braden.
+
+[RFC1996]   "A Mechanism for Prompt Notification of Zone Changes
+            (DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie.
+
+[RFC2119]   "Key words for use in RFCs to Indicate Requirement
+            Levels", rfc2119.txt, March 1997, S. Bradner.
+
+[RFC2181]   "Clarifications to the DNS Specification", rfc2181.txt,
+            July 1997, R. Elz, R. Bush.
+
+[RFC2277]   "IETF Policy on Character Sets and Languages",
+            rfc2277.txt, January 1998, H. Alvestrand.
+
+[RFC2278]   "IANA Charset Registration Procedures", rfc2278.txt,
+            January 1998, N. Freed and J. Postel.
+
+[RFC2279]   "UTF-8, a transformation format of ISO 10646",
+            rfc2279.txt, F. Yergeau, January 1998.
+
+[RFC2535]   "Domain Name System Security Extensions", rfc2535.txt,
+            March 1999, D. Eastlake.
+
+[RFC2553]   "Basic Socket Interface Extensions for IPv6", rfc2553.txt,
+            March 1999, R. Gilligan et al.
+
+[RFC2825]   "A Tangled Web: Issues of I18N, Domain Names, and the
+            Other Internet protocols", rfc2825.txt, May 2000,
+            L. Daigle et al.
+
+[RFC2826]   "IAB Technical Comment on the Unique DNS Root",
+            rfc2826.txt, May 2000, Internet Architecture Board.
+
+[IDNCOMP]   "Comparison of Internationalized Domain Name Proposals",
+            draft-ietf-idn-compare-00.txt, June 2000, P. Hoffman.
+
+[UNICODE]   The Unicode Consortium, "The Unicode Standard -- Version
+            3.0", ISBN 0-201-61633-5. Described at
+            http://www.unicode.org/unicode/standard/versions/
+            Unicode3.0.html
+
+[US-ASCII]  Coded Character Set -- 7-bit American Standard Code for
+            Information Interchange, ANSI X3.4-1986.
+
+[UTR15]     "Unicode Normalization Forms", Unicode Technical Report
+            #15, http://www.unicode.org/unicode/reports/tr15/,
+            Nov 1999, M. Davis & M. Duerst, Unicode Consortium.
+
+[UTR21]     "Case Mappings", Unicode Technical Report #21,
+            http://www.unicode.org/unicode/reports/tr21/, Dec 1999,
+            M. Davis, Unicode Consortium.  Approved status.
+
+6. Editors' Contact
+
+Zita Wenzel, Ph.D.
+Information Sciences Institute
+University of Southern California
+4676 Admiralty Way
+Marina del Rey, CA  
+90292  USA
+Tel: +1 310 448 8462
+Fax: +1 310 823 6714
+zita@isi.edu
+
+James Seng
+8 Temesek Boulevand
+#24-02 Suntec Tower 3
+Singapore 038988
+Tel: +65 248 6208
+Fax: +65 248 6198
+Email: jseng@pobox.org.sg
+
+7. Acknowledgements
+
+The editors gratefully acknowledge the contributions of:
+
+Harald Tveit Alvestrand <Harald@Alvestrand.no>
+Mark Andrews <Mark.Andrews@nominum.com>
+RJ Atkinson <request not to have email>
+Alan Barret <apb@cequrux.com>
+Randy Bush <randy@psg.com>
+Andrew Draper <ADRAPER@altera.com>
+Martin Duerst <duerst@w3.org>
+Patrik Faltstrom <paf@swip.net>
+Ned Freed <ned.freed@innosoft.com>
+Olafur Gudmundsson <ogud@tislabs.com>
+Paul Hoffman <phoffman@imc.org>
+Simon Josefsson <jas+idn@pdc.kth.se>
+Karlsson Kent <keka@im.se>
+John Klensin <klensin+idn@jck.com>
+Tan Juay Kwang <tanjk@i-dns.net>
+Dongman Lee <dlee@icu.ac.kr>
+Bill Manning <bmanning@ISI.EDU>
+Dan Oscarsson <Dan.Oscarsson@trab.se>
+J. William Semich <bill@mail.nic.nu>
+James Seng <jseng@pobox.org.sg>
+
diff --git a/doc/draft/draft-ietf-idn-requirment-00.txt b/doc/draft/draft-ietf-idn-requirment-00.txt
deleted file mode 100644
index 62863572..00000000
--- a/doc/draft/draft-ietf-idn-requirment-00.txt
+++ /dev/null
@@ -1,412 +0,0 @@
-IETF IDN Working Group                                       James Seng
-Internet Draft                         draft-ietf-idn-requirment-00.txt
-22nd Feb 2000                                     Expires 22nd Aug 2000
-
-             Requirements of Internationalized Domain Names
-
-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 describes the requirement for encoding international
-characters into DNS names and records. This document is guidance for
-developing protocols for internationalized domain names.
-
-1. Introduction
-
-At present, the encoding of Internet domain names is restricted to a
-subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many
-other text based items on the Internet have already been
-internationalized. It is important for domain names to be similarly
-internationalized.
-
-This document is being discussed on the "idn" mailing list. To join the
-list, send a message to <majordomo@ops.ietf.org> with the words
-"subscribe idn" in the body of the message. Archives of the mailing
-list can also be found at ftp://ops.ietf.org/pub/lists/idn*.
-
-1.1 Definitions and Conventions
-
-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].
-
-"IDN" is used in this document as an abbreviation for "internationalized
-domain name". This is defined as a domain name that contains one or more
-characters that are outside the set of characters specified as legal
-
-                   Expires 22nd of August 2000       [Page  1]
-
-Internet Draft              Requirements of IDN           22nd Feb 2000
-
-characters for domain names in [RFC1034] Section 3.5.
-
-A master server for a zone holds the main copy of that zone. This copy
-is sometimes stored in a zone file. A slave server for a zone holds a
-complete copy of the records for that zone. A caching server holds
-temporary copies of DNS records; it uses records to answer queries
-about domain names. Further explanation of these terms can be found in
-[RFC1034] and [RFC1996].
-
-Characters mentioned in this document are identified by their position
-in the Unicode character set. The notation U+12AB, for example,
-indicates the character at position 12AB (hexadecimal) in the Unicode
-character set. Note that the use of this notation is not an indication
-of a requirement to use Unicode.
-
-Examples quoted in this document should be considered as a method to
-further explain the meanings and principles adopted by the document. It
-is not a requirement for the protocol to satisfy the examples.
-
-A character is a member of a set of elements used for organization,
-control, or representation of data.
-
-A coded character is a character with its coded representation.
-
-A coded character set ("CCS") is a set of unambiguous rules that
-establishes a character set and the relationship between the characters
-of the set and their coded representation.
-
-A graphic character or glyph is a character, other than a control
-function, that has a visual representation normally handwritten,
-printed, or displayed.
-
-A character encoding scheme or "CES" is a mapping from one or more
-coded character sets to a set of octets. Some CESs are associated with
-a single CCS; for example, UTF-8 applies only to ISO 10646. Other CESs,
-such as ISO 2022, are associated with many CCSs.
-
-A charset is a method of mapping a sequence of octets to a sequence of
-abstract characters. A charset is, in effect, a combination of one or
-more CCS with a CES. Charset names are registered by the IANA according
-to procedures documented in RFC 2278.
-
-A language is a way that humans interact. In written form, a language
-is expressed in characters. The same set of characters can often be
-used in many languages, and many languages can be expressed using
-different scripts. A particular charset may have different glyphs
-(shapes) depending on the language being used.
-
-2. General Requirements
-
-2.1 Compatibility and Interoperability
-
-The DNS is essential to the entire Internet. Therefore, the protocol
-must not damage present DNS interoperability. It must make the minimum
-
-                   Expires 22nd of August 2000       [Page  2]
-
-Internet Draft              Requirements of IDN           22nd Feb 2000
-
-number of changes to existing protocols on all layers of the stack. It
-must continue to allow any system anywhere to resolve any domain name.
-
-The protocol must preserve the basic concept and facilities of domain
-names as described in [RFC1034]. It must maintain a single, global,
-universal, and consistent hierarchical namespace.
-
-The same name resolution request must generate the same response,
-regardless of the location or localization settings in the resolver, in
-the master server, and in any slave or caching servers involved in the
-resolution process.
-
-If the protocol allows more than one charset, it should also allow
-creation of caching servers that do not understand the charset in which
-a request or response is encoded. Such caching servers should work as
-well for IDNs as they do for current domain names. The caching server
-performs correctly if it gives the essentially the same answer (without
-the authoritative bit) as the master server would have if presented
-with the same request.
-
-A caching server must not return data in response to a query that would
-not have been returned if the same query had been presented to an
-authoritative server. This applies fully for the cases when:
-
-- The caching server does not know about IDN
-- The caching server implements the whole specification
-- The caching server implements a legal subset of the specification
-
-The protocol should be able to be upgraded at any time with new features
-and retain backwards compatibility with the current specification.
-
-The protocol may modify the DNS protocol [RFC1035] and other related
-work undertaken by the DNSEXT WG. However, these changes should be as
-small as possible and any changes must be approved by the DNSEXT WG.
-
-The protocol should be as simple as possible from the user's
-perspective. Ideally, users should not realize that IDN was added on
-to the existing DNS.
-
-A fall-back strategy or mechanism based upon ASCII may be needed during
-a transition period during deployment and adoption of IDN. Therefore,
-if an encoding is not mapped into ASCII, then there should be an ASCII-
-only representation compatible with the current DNS and there should be
-a way for a program to find the ASCII-only representation for IDN.
-
-The best solution is one that maintains maximum feasible compatibility
-with current DNS standards as long as it meets the other requirements
-in this document.
-
-2.2 Internationalization
-
-Internationalized characters must be allowed to be represented and used
-in DNS names and records. The protocol must specify what charset is used
-when resolving domain names and how characters are encoded in DNS
-
-                   Expires 22nd of August 2000       [Page  3]
-
-Internet Draft              Requirements of IDN           22nd Feb 2000
-
-records.
-
-This document does not recommend any charset for I18N. If more than one
-charset is used in the protocol, then the protocol must specify all the
-charsets being used and for what purpose. A CCS(s) chosen must at
-least cover the range of characters as currently defined (and as being
-added) by ISO 10646/Unicode.
-
-CES(s) chosen should not encode ASCII characters differently depending
-on the other characters in the string. In other words, ASCII
-character should remain as specified in [US-ASCII].
-
-The protocol must not invent a new CCS for the purpose of IDN only
-and should use existing CES. The charset(s) chosen should also be
-non-ambiguous.
-
-The protocol should not make any assumptions where in a domain name
-that internationalization might appear. In other words, it should not
-differentiate between any part of a domain name because this may impose
-a restriction on future internationalization efforts.
-
-The protocol should also not make any localized restrictions in the
-protocol. For example, an IDN implementation which only allows domain
-names to use a single local script would immediately restrict
-multinational organization.
-
-Because of the wide range of devices that use the DNS and the wide
-range of characteristics of international scripts, the protocol should
-allow more than one method of domain name input and display. However,
-there has to be a single way of encoding an internationalized domain
-name within the core of the DNS.
-
-2.3 Localization
-
-The protocol must be able to handle localized requirement of different
-languages. For example, IDN must be able to handle bidirectional
-writing for scripts such as Arabic.
-
-Historically, "." has been the separator of labels in the domain names.
-The protocol should not use different separators for different
-languages.
-
-Most localization can be handled by the user interface. It should not
-matter how the domain names are input or presented, such as in a
-reverse order or bidirectional, or with the introduction of a new
-separator. However, the final wire format must be in canonical order.
-
-2.4 Canonicalization
-
-Matching rules are a complicated process for IDN. Canonicalization of
-characters must follow precise and predictable rules to ensure
-consistency. [CHARREQ] is a recommended as a guide on canonicalization.
-
-The DNS has to match a domain name in a request with a domain name held
-
-                   Expires 22nd of August 2000       [Page  4]
-
-Internet Draft              Requirements of IDN           22nd Feb 2000
-
-in one or more zones. It also needs to sort names into order. It is
-expected that some sort of canonicalization algorithm will be used as
-the first step of this process. This section discusses some of the
-properties which will be required of that algorithm.
-
-The canonicalization algorithm might specify operations for case,
-ligature, and punctuation folding.
-
-In order to retain backwards compatibility with the current DNS, the
-protocol must retain the case-insensitive comparison for US-ASCII as
-specified in [RFC1035]. For example, Latin capital letter A (U+0041)
-must match Latin small letter A (U+0061). [UTR-21] describes some of
-the issues with case mapping.
-
-Case folding must not be locale dependent. For example, Latin capital
-letter I (U+0049) case folded to lower case in the Turkish context will
-become Latin small letter dotless I (U+0131). But in the English
-context, it will become Latin small letter I (U+0069).
-
-If other canonicalization is done, then it must be done before the
-domain name is resolved. Further, the canonicalization must be easily
-upgrade able as new languages and writing systems are added.
-
-Any conversion (case, ligature folding, punctuation folding, ...) from
-what the user enters into a client to what the client asks for
-resolution must be done identically on all requests from any client.
-
-If the protocol specifies a canonicalization algorithm, a caching
-server should perform correctly regardless of how much (or how little)
-of that algorithm it has implemented. [1 request to remove]
-
-If the protocol requires a canonicalization algorithm, all requests
-sent to a caching server must already be in the canonical form.
-
-The protocol should avoid inventing a new normalization form provided
-a technically sufficient one is available (such as in an ISO standard).
-
-2.5 Operational Issues
-
-Zone files should remain easily editable.
-
-An IDN-capable resolver or server should not generate more traffic than
-a non-IDN-capable resolver or server would when resolving an ASCII-only
-domain name.  The amount of traffic generated when resolving an IDN
-should be similar to that generated when resolving an ASCII-only name.
-
-The protocol should add no new centralized administration for the DNS.
-A domain administrator should be able to create internationalized names
-as easily as adding current domain names.
-
-Within a single zone, the zone manager must be able to define
-equivalence rules that suit the purpose of the zone, such as, but not
-limited to, and not necessarily, non-ASCII case folding, Unicode
-normalizations, Cyrillic/Latin folding, or traditional/simplified
-
-                   Expires 22nd of August 2000       [Page  5]
-
-Internet Draft              Requirements of IDN           22nd Feb 2000
-
-Chinese equivalence. Such defined equivalences must not remove
-equivalences that are assumed by (old or local-rule-ignorant) caches.
-
-The character set of a signed zone file should be capable of being the
-same as the character set of the unsigned zone file. The protocol must
-allow offline DNSSEC signing. It should be possible to look at the
-signed file and see that it is the same as the unsigned one.
-
-2.6 Others
-
-The protocol may provide the same DNS resources using internationalized
-text as it currently provides using ASCII text.
-
-To get full semantics for IDN, an upgrade of the DNS and related
-software may be needed.
-
-3. Technical Analysis
-
-There are many standard protocols and RFCs which are depend on
-domain names and have make various assumptions about the characters
-in them always conforming to [RFC-1034]. We expect that the protocols
-listed below to be affected:
-
-<...list the sets of RFCs which we would like to have an summary...>
-RFC821, RFC822, ...
-
-All idn protocol documents must fully detail the expected effects of
-leaking of the specified encoding to protocols other than the DNS
-resolution protocol. They must also contain a summary of the technical
-opinions of the IDN Working Group.
-
-4. Security Considerations
-
-Any solution that meets the requirements in this document must not
-be less secure than the current DNS. Specifically, the mapping of
-internationalized host names to and from IP addresses must have the
-same characteristics as the mapping of today's host names.
-
-Specifying requirements for internationalized domain names does not
-itself raise any new security issues. However, any change to the DNS
-may affect the security of any protocol that relies on the DNS or on
-DNS names. A thorough evaluation of those protocols for security
-concerns will be needed when they are developed. In particular, IDNs
-must be compatible with DNSSEC.
-
-5. References
-
-[CHARREQ]   "Requirements for string identity matching and String
-            Indexing", http://www.w3.org/TR/WD-charreq, July 1998,
-            World Wide Web Consortium.
-
-[DNSEXT]    "IETF DNS Extensions Working Group",
-            namedroppers@internic.net, Olafur Gudmundson, Randy Bush.
-
-
-                   Expires 22nd of August 2000       [Page  6]
-
-Internet Draft              Requirements of IDN           22nd Feb 2000
-
-[RFC1034]   "Domain Names - Concepts and Facilities", rfc1034.txt,
-            November 1987, P. Mockapetris.
-
-[RFC1035]   "Domain Names - Implementation and Specification",
-            rfc1035.txt, November 1987, P. Mockapetris.
-
-[RFC1123]   "Requirements for Internet Hosts -- Application and
-            Support", rfc1123.txt, October 1989, R. Braden.
-
-[RFC1996]   "A Mechanism for Prompt Notification of Zone Changes
-            (DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie.
-
-[RFC2119]   "Key words for use in RFCs to Indicate Requirement
-            Levels", rfc2119.txt, March 1997, S. Bradner.
-
-[UNICODE]   The Unicode Consortium, "The Unicode Standard -- Version
-            3.0", ISBN 0-201-61633-5. Described at
-            http://www.unicode.org/unicode/standard/versions/
-                   Unicode3.0.html
-
-[US-ASCII]  Coded Character Set -- 7-bit American Standard Code for
-            Information Interchange, ANSI X3.4-1986.
-
-[UTR15]     "Unicode Normalization Forms", Unicode Technical Report
-            #15, http://www.unicode.org/unicode/reports/tr15/,
-            Nov 1999, M. Davis & M. Duerst, Unicode Consortium.
-
-[UTR21]     "Case Mappings", Unicode Technical Report #21,
-            http://www.unicode.org/unicode/reports/tr21/, Dec 1999,
-            M. Davis, Unicode Consortium.
-
-Appendix A. Acknowledgements
-
-The editor gratefully acknowledges the contributions of:
-
-Harald Tveit Alvestrand <Harald@Alvestrand.no>
-Martin Duerst <duerst@w3.org>
-Patrik Faltstrom <paf@swip.net>
-Andrew Draper <ADRAPER@altera.com>
-Bill Manning <bmanning@ISI.EDU>
-Paul Hoffman <phoffman@imc.org>
-James Seng <jseng@pobox.org.sg>
-Randy Bush <randy@psg.com>
-Alan Barret <apb@cequrux.com>
-Olafur Gudmundsson <ogud@tislabs.com>
-Karlsson Kent <keka@im.se>
-Dan Oscarsson <Dan.Oscarsson@trab.se>
-J. William Semich <bill@mail.nic.nu>
-RJ Atkinson <rja@inet.org>
-Simon Josefsson <jas+idn@pdc.kth.se>
-Ned Freed <ned.freed@innosoft.com>
-
-
-
-
-                   Expires 22nd of August 2000       [Page  7]
diff --git a/doc/draft/draft-ietf-idn-sace-00.txt b/doc/draft/draft-ietf-idn-sace-00.txt
new file mode 100644
index 00000000..59a76477
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-sace-00.txt
@@ -0,0 +1,276 @@
+Internet Draft                                            Dan Oscarsson
+draft-ietf-idn-sace-00.txt                                Telia ProSoft
+Expires: 27 February 2001                                 27 August 2000
+
+                Simple ASCII Compatible Encoding (SACE)
+
+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 describes a way to encode non-ASCII characters in host
+   names in a way that is completely compatible with the current ASCII
+   only host names that are used in DNS. It can be used both with DNS to
+   support software only handling ASCII host names and as a way to
+   downgrade from 8-bit text to ASCII in protocols.
+
+
+1. Introduction
+
+   This document defines an ASCII Compatible Encoding (ACE) of names
+   that can be used when communicating with DNS. It is needed during a
+   transition period when non-ASCII names are introduced in DNS to avoid
+   breaking programs expecting ASCII only.
+
+   The Simple ASCII Compatible Encoding (SACE) defined here can be
+   compared to [RACE]. The main differences are:
+    - RACE encodes by first compressing and the encoding the resulting
+      bit stream into ASCII. SACE encodes each character directly in one
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 1]
+
+Internet Draft                    SACE                    27 August 2000
+
+
+      pass.
+    - SACE recognises that at lot of latin based names are mostly
+      composed of ASCII characters and gives a higher compression for
+      those.  In the 63 byte limit of DNS RACE will allow 36 characters
+      for ISO 8859-1 and less if characters from the additional Latin
+      characters are needed. SACE will allow around 40 characters if
+      about 10 % of a Latin name is non-ASCII (in the UCS [ISO10646]
+      range 0-0x217).  SACE is closer to the compression that UTF-8 have
+      than RACE.
+    - Most ASCII characters will not be encoded so Latin based names
+      composed of mostly ASCII characters will be somewhat readable.
+
+
+1.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].
+
+2. Simple ASCII Compatible Encoding
+
+   The encoding encodes values using the available characters allowed in
+   a ASCII host name (a-z0-9 and hyphen).
+
+   Values are encoded as follows:
+
+                    Character - value mapping
+
+      value  character               value  character
+         0       a                     18       s
+         1       b                     19       t
+         2       c                     20       u
+         3       d                     21       v
+         4       e                     22       w
+         5       f                     23       x
+         6       g                     24       y
+         7       h                     25       z
+         8       i                     26       1
+         9       j                     27       2
+        10       k                     28       3
+        11       l                     29       4
+        12       m                     30       7
+        13       n                     31       9
+        14       o                     32       0
+        15       p                     33       8
+        16       q                     34       5
+        17       r                     35       6
+
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 2]
+
+Internet Draft                    SACE                    27 August 2000
+
+
+   In the following description the following syntax will be used:
+      B => one value in the range 0-35 mapped to a character as above
+      X => one value in the range 0-31 mapped to a character as above
+
+   Each UCS character is identified as follows:
+      latin  => a character in the range 0-0x217
+      10bit  => a character in the range 0x218-0x2FFF
+      base36 => all other characters
+
+   During encoding/decoding a string a current mode is used. In each
+   mode characters are encoded like this:
+      latin  => as themselves, 00 for 0, 88 for 8 or as 10 bit value
+                encoded as 0XX (two 5 bit values)
+      10bit  => as 15 bits represented by its current prefix of 5 bits
+                followed by 10 bits encoded as XX
+                (the value is the 15 bits of prefix and
+                10 bits concatenated)
+      base36 => as a base 36 value represented by its current base 36
+                prefix followed by three base 36 digits encoded as BBB
+                (the value is prefix*36*36*36*36+B*36*36+B*36+B)
+                Before encoding the character value must first be
+                reduced:
+                  if >= 0xd800 reduce by 8192 (private/surrogate start)
+                  then reduce by 0x2FFF.
+                After decoding the character value need to be restored
+   as
+                  add 0x2FFF
+                  followed by adding 8192 if >= 0xd800
+
+
+2.1 Decoding a string
+
+   During decode you start with:
+      Mode: latin
+      10bit prefix: 0
+      base36 prefix: 0
+
+   Then the characters in an encoded string are interpreted as follows
+   depending on current mode:
+
+    When in latin mode:
+      00  => the character 0
+      0XX => XX represents 10 bits which decodes to one character
+      88  => the character 8
+      85  => switch to 10bit mode with same prefix as last time
+      8X5 => switch 10 10bit mode setting X as current 10bit prefix
+      87  => switch to base36 mode with same prefix as last time
+      8X7 => switch to base36 mode setting X as current base36 prefix
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 3]
+
+Internet Draft                    SACE                    27 August 2000
+
+
+      other  => the characters represent itself
+
+    When in 10bit mode
+      - => the character -
+      0 => switch to latin mode
+      X5 => switch 10 10bit mode using X as current prefix
+      7  => switch to base36 mode with same prefix as last time
+      X7 => switch to base36 mode using X as current prefix
+      XX => current 10bit prefix plus XX gives the character
+
+    When in base36 mode
+      -- => the character -
+      -0 => switch to latin mode
+      -5 => switch to 10bit mode with same prefix as last time
+      -X5 => switch 10 10bit mode setting X as current prefix
+      -X7 => switch to base36 mode setting X as current prefix
+      XXX => current base36 prefix plus XXX as base 36 values gives
+   character
+
+
+   2.2 Encoding a string
+
+   To encode a string you start with the data as UCS characters and:
+      Mode: latin
+      10bit prefix: 0
+      base36 prefix: 0
+
+   Then for each UCS character, the mode and/or prefix is switched if
+   needed and then the character is encoded as defined above.
+
+
+3. References
+
+   [RFC2119]  Scott Bradner, "Key words for use in RFCs to Indicate
+              Requirement Levels", March 1997, RFC 2119.
+
+   [RFC2279]  F. Yergeau, "UTF-8, a transformation format of ISO 10646",
+              RFC 2279, January 1998.
+
+   [ISO10646] ISO/IEC 10646-1:2000. International Standard --
+              Information technology -- Universal Multiple-Octet Coded
+              Character Set (UCS)
+
+   [Unicode]  The Unicode Consortium, "The Unicode Standard -- Version
+              3.0", ISBN 0-201-61633-5. Described at
+              http://www.unicode.org/unicode/standard/versions/
+              Unicode3.0.html
+
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 4]
+
+Internet Draft                    SACE                    27 August 2000
+
+
+   [IDNREQ]   James Seng, "Requirements of Internationalized Domain
+              Names", draft-ietf-idn-requirement.
+
+   [RACE]     Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
+   for IDN", draft-ietf-idn-race.
+
+4. Acknowledgements
+
+   Paul Hoffman for many good ideas.
+
+
+
+Author's Address
+
+   Dan Oscarsson
+   Telia ProSoft AB
+   Box 85
+   201 20 Malmo
+   Sweden
+
+   E-mail: Dan.Oscarsson@trab.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 5]
+
diff --git a/doc/draft/draft-ietf-idn-udns-01.txt b/doc/draft/draft-ietf-idn-udns-01.txt
new file mode 100644
index 00000000..085a2203
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-udns-01.txt
@@ -0,0 +1,557 @@
+Internet Draft                                            Dan Oscarsson
+draft-ietf-idn-udns-01.txt                                Telia ProSoft
+Updates: RFC 2181, 1035, 1034, 2535                       27 August 2000
+Expires: 27 February 2001
+
+   Using the Universal Character Set in the Domain Name System (UDNS)
+
+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
+
+   Since the Domain Name System (DNS) [RFC1035] was created there have
+   been a desire to use other characters than ASCII in domain names.
+   Lately this desire have grown very strong and several groups have
+   started to experiment with non-ASCII names.
+
+   This document defines how the Universal Character Set (UCS)
+   [ISO10646] can be used in DNS without extending the current [RFC1035]
+   protocol and how DNS is extended to overcome length limits in the
+   future.
+
+
+1. Introduction
+
+   While the need for non-ASCII domain names have existed since the
+   creation of the DNS, the need have increased very much during the
+   last few years. Currently there are at least two implementations
+   using UTF-8 in use, and others using other methods.
+
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 1]
+
+Internet Draft               Universal DNS                27 August 2000
+
+
+   To avoid several different implementations of non-ASCII names in DNS
+   that do not work together, and to avoid breaking the current ASCII
+   only DNS, there is an immediate need to standardise how DNS shall
+   handle non-ASCII names.
+
+   While the DNS protocol allow any octet in character data, so far the
+   octets are only defined for the ASCII code points. Octets outside the
+   ASCII range have no defined interpretation. This document defines how
+   all octets are to be used in character data allowing a standardised
+   way to use non-ASCII in DNS.
+
+   To support the software where only ASCII host and domain names are
+   allowed, this document defines how resource records are to be
+   returned in a response to avoid breaking that software.
+
+   The specification here conforms to the IDN requirements [IDNREQ].
+
+1.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].
+
+    IDN: Internationalised Domain Name, here used to mean a domain name
+      containing non-ASCII characters.
+
+    ACE: ASCII Compatible Encoding. Used to encode IDNs in a way
+      compatible with the ASCII host name syntax.
+
+1.2 Previous versions of this document
+
+   The second version of this document was available as draft-ietf-idn-
+   udns-00.txt. It included a lot of possibilities as well as a flag bit
+   that is now removed.
+
+   The first version of this document was available as draft-oscarsson-
+   i18ndns-00.txt.
+
+
+2. The DNS Protocol
+
+   The DNS protocol is used when communicating between DNS servers and
+   other DNS servers or DNS clients. User interface issues like the
+   format of zone files or how to enter or display domain names are not
+   part of the protocol.
+
+   The update of the protocol defined here can be used immediately as it
+   is fully compatible with the DNS of today.
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 2]
+
+Internet Draft               Universal DNS                27 August 2000
+
+
+2.1 Character data
+
+   Character data need to be able to represent as much as possible of
+   the characters in the world as well as being compatible with ASCII.
+   It must also be well defined so that it can easily be handled and
+   should be compact as only 63 octets is available without an extension
+   of the protocol. Character data is used in labels and in text fields
+   in the RDATA part of a RR.
+
+   Character data used in the DNS protocol MUST:
+    - Use ISO 10646 (UCS) [ISO10646] as coded character set.
+    - Be normalised using form C as defined in Unicode technical report
+      #15 [UTR15]. See also [CHNORM].
+    - Encoded using the UTF-8 [RFC2279] character encoding scheme.
+
+2.2 Name matching
+
+   RFC 1035 states that the labels of a name are matched case-
+   insensitively.  When using UCS this is no longer enough as there are
+   other forms than case that need to match as equivalent.
+
+   The original definition is now extended to be: labels must be
+   compared using form-insensitivity.
+
+   For the UCS character code range 0-255 (ASCII and ISO 8859-1) the
+   case folding MUST be done by case-insensitive matching following the
+   one to one mapping as defined in the Unicode 3.0 Character Database
+   [UDATA].
+
+   How to do form-insensitive matching for the rest of UCS will be
+   defined in a separate document.
+
+2.2.1 Rules for matching of domain names in DNS servers
+
+   To be able to handle correct domain name matching in lookups, the
+   following MUST be followed by DNS servers:
+    - Do matching on authorative data using form-insensitive matching
+      for the characters used in the data (for example a zone using only
+      ASCII need only handle matching of ASCII characters).
+    - On non-authorative data, either do binary matching or case-
+      insensitive matching on ASCII letters and binary matching on all
+      others.
+
+   The effect of the above is:
+    - only servers handling authorative data must implement form-
+      insensitive matching of names. And they need only implement the
+      subset needed for the subset of characters of UCS they support in
+      their authorative zones.
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 3]
+
+Internet Draft               Universal DNS                27 August 2000
+
+
+    - it normally gives fast lookup because data is usually sent like:
+      resolver <-> server <-> authorative server.
+      While form-insensitive matching can be complex and CPU consuming,
+      the server in the middle will do caching with only simple and fast
+      binary matching. So the impact of complex matching rules should
+      not slow down DNS very much.
+
+2.3 Supporting older software and allowing for ASCII aliases.
+
+   As there is a lot of software expecting host and domain names to only
+   use a subset of ASCII, they may work incorrectly if receiving a
+   response with non-ASCII characters. And when communicating between
+   nations it is sometimes good to also have a version of a name that
+   can be used by most people.
+
+   To support this the following MUST be followed:
+    - Queries for PTR records must return two records if the name
+      pointed to includes non-ASCII. They may also return two records if
+      an alternative name exist for the object pointed to.
+      The two records MUST be ordered with the ASCII version of the name
+      first and the non-ASCII or true name second. The second record
+      defines the true name of the object, the first record an ASCII
+      version of the name.
+
+      Note: older software will normally stop analysing a response when
+      finding the first PTR record so they will get the ASCII name.
+      Newer software can select the name best suited for its needs.
+    - Queries for other records with non-ASCII in the RDATA section MUST
+      return an ASCII version also, unless the client is known to handle
+      non-ASCII.
+
+   At a future date IETF can decide that it is no longer necessary to
+   support the software only handling ASCII names, and the servers can
+   stop including ASCII versions in the responses.
+
+   NOTE: a cache server shall return data in the same way as an
+   authorative server. If some do not and change the order of the PTR
+   records, some old software will not get the ASCII version of the
+   name.
+
+2.3.1 ASCII versions of a name
+
+   When returning an ASCII version of a name, there are two
+   possibilities:  returning a user defined ASCII alias or an ASCII
+   compatible encoding (ACE) of the name.
+
+   The ASCII Compatible Encoding (ACE) is used to support older software
+   expecting only ASCII and to support downgrading from 8-bit to 7-bit
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 4]
+
+Internet Draft               Universal DNS                27 August 2000
+
+
+   ASCII in other protocols (like SMTP). It is a transition mechanism
+   and will no longer be supported at some future time when it is so
+   decided.
+
+   All software following this specification MUST recognise ACE and
+   decode them into their true name when doing matching and handling. A
+   DNS server must recognise ACE in a query.
+
+   The definition of the ACE to be used, is defined in a separate
+   document.  Typical definitions that are suitable are [SACE] and
+   [RACE].
+
+   NOTE: To support the transition to UTF-8 in resolver code, it is
+   recommended that a server recognise local encodings for the zones it
+   is authorative for. This will allow clients using the local character
+   set in many cases even before the resolver code is upgraded.
+
+
+2.4 Handling long names
+
+   The current DNS protocol limits a label to 63 octets. As UTF-8 take
+   more than one octet for some characters, an UTF-8 name cannot have 63
+   characters in a label like an ASCII name can. For example a name
+   using Hangul would have a maximum of 21 characters.
+
+   The limits imposed by RFC 1035 is 63 octets per label and 255 octets
+   for the full name. The 255 limit is not a protocol limit but one to
+   simplify implementations.
+
+   To support longer names a long label type is defined using [RFC2671]
+   as extended label 0b000011 (the label type will be assigned by IANA
+   and may not be the number used here).
+
+                                 1 1 1 1 1 1 1 1 1 1
+             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+            |0 1 0 0 0 0 1 1|  length       |  label data ...
+            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   length: length of label in octets
+   label data: the label
+
+   The long label MUST be handled by all software following this
+   specification.  Also, they MUST support a UDP packet size of up to
+   1280 bytes.
+
+   The limits for labels are updated since RFC 1025 as follows:
+   A label is limited to a maximum of 63 character code points in UCS
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 5]
+
+Internet Draft               Universal DNS                27 August 2000
+
+
+   normalised using Unicode form C.  The full name is limited to a
+   maximum of 255 character code points normalised as for a label.
+
+   As long labels are not understood by older software, a response MUST
+   not include a long label unless the query did. At a later date, IETF
+   may change this.
+
+2.5 Handling to large responses and identifying non-ASCII clients
+
+   If a client sends the QNAME in the query using the long label type,
+   the client shows that it implements this specification and do not
+   need ASCII compatibility.
+
+   If the client is not identified to follow this specification, the UDP
+   packet size is limited to 512 bytes. If then a response will not fit,
+   the response MUST set the TC bit (truncated) to indicate that. A
+   client may then resend the query using a long label in the query to
+   show that it can handle larger responses.
+
+2.6 DNSSEC
+
+   As labels now can have non-ASCII in them, DNSSEC [RFC2535] need to be
+   revised so that it also can handle that.
+
+3. User interface issues
+
+   Locally on a system or in a user interface a different character set
+   than the one defined to be used in the DNS protocol may be used.
+   Therefore software must map between the local character set and the
+   character set of the protocol, so that human beings can understand
+   it.
+
+   This means that a zone file that is edited in a text editor by a
+   person before being loaded into a DNS server must be allowed to be in
+   the local character set. Software may not assume that the user can
+   edit text encoded in UTF-8. A zone file transmitted between DNS
+   software that is not handled by a human, can be transmitted using any
+   format.
+
+   When character data is presented to a human or entered by a human,
+   software must, as good as possible, present it using local character
+   set and allow it to be entered using the local character set.  It is
+   the responsibility of the software to convert between the local
+   character set and the one used in the protocol, not the human.
+
+   The down coding defined above allows all names to be entered and
+   displayed for all users, as long as at least the ASCII characters are
+   supported.
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 6]
+
+Internet Draft               Universal DNS                27 August 2000
+
+
+4.1 Applications using DNS software
+
+   If an application does a call to DNS, it must present the data to the
+   users in the local character set used by the user, down coding if
+   necessary. Software used to access DNS should give the application
+   programmer both the possibility of doing queries and getting
+   responses using local character set, and using UTF-8.
+
+   APIs like getipnodebyname should be updated with a IDN flag that
+   results in the name being returned using the current locale, instead
+   of native UTF-8 or ASCII format.
+
+5. Effect on other protocols
+
+   As now a domain name may include non-ASCII many other protocols that
+   include domain names need to be updated. For example SMTP, HTTP and
+   URIs. The ACE format can be used when interfacing with ASCII only
+   software or protocols.  Protocols like SMTP could be extended using
+   ESMTP and a UTF8 option that defines that all headers are in UTF-8.
+
+   It is recommended that protocols updated to handle i18n do this by
+   encoding character data in the same standard format as defined for
+   DNS in this document (UCS normalised form C). The use of encoding it
+   in ASCII or by tagged character sets should be avoided.
+
+   DNS do not only have domain names in them, for example e-mail
+   addresses are also included. So an e-mail address would be expected
+   to be changed to include non-ASCII both before and after the @-sign.
+
+   Software need to be updated to follow the user interface
+   recommendations given above, so that a human will see the characters
+   in their local character set, if possible.
+
+5.1 An example: SMTP
+
+   When using SMTP it may be extended to allow UTF-8 in headers and
+   addresses.  It will then have to, when transferring an e-mail to a
+   SMTP system that have not been extended, encoded e-mail addresses and
+   IDNs into an ACE.
+
+   In this case an e-mail address could look like:
+   ra--XXXXX.surname@ra--YYYYY.com
+   where ra--XXXXX is the ACE of the given name and ra--YYYYY is the ACE
+   of one part of the domain name.
+
+6. Security Considerations
+
+   As always with data, if software does not check for data that can be
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 7]
+
+Internet Draft               Universal DNS                27 August 2000
+
+
+   a problem, security may be affected. As more characters than ASCII is
+   allowed, software only expecting ASCII and with no checks may now get
+   security problems.
+
+7. References
+
+   [RFC1034]  P. Mockapetris, "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  P. Mockapetris, "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Scott Bradner, "Key words for use in RFCs to Indicate
+              Requirement Levels", March 1997, RFC 2119.
+
+   [RFC2181]  R. Elz and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2279]  F. Yergeau, "UTF-8, a transformation format of ISO 10646",
+              RFC 2279, January 1998.
+
+   [RFC2535]  D. Eastlake, "Domain Name System Security Extensions".
+              RFC 2535, March 1999.
+
+   [RFC2671]  P. Vixie, "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [ISO10646] ISO/IEC 10646-1:2000. International Standard --
+              Information technology -- Universal Multiple-Octet Coded
+              Character Set (UCS)
+
+   [Unicode]  The Unicode Consortium, "The Unicode Standard -- Version
+              3.0", ISBN 0-201-61633-5. Described at
+              http://www.unicode.org/unicode/standard/versions/
+              Unicode3.0.html
+
+   [UTR15]    M. Davis and M. Duerst, "Unicode Normalization Forms",
+              Unicode Technical Report #15, Nov 1999,
+              http://www.unicode.org/unicode/reports/tr15/.
+
+   [UTR21]    M. Davis, "Case Mappings", Unicode Technical Report #21,
+              Dec 1999, http://www.unicode.org/unicode/reports/tr21/.
+
+   [UDATA]    The Unicode Character Database,
+              ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt.
+              The database is described in
+              ftp://ftp.unicode.org/Public/UNIDATA/
+              UnicodeCharacterDatabase.html.
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 8]
+
+Internet Draft               Universal DNS                27 August 2000
+
+
+   [IDNREQ]   James Seng, "Requirements of Internationalized Domain
+   Names", draft-ietf-idn-requirement.
+
+   [IANADNS]  Donald Eastlake, Eric Brunner, Bill Manning, "Domain Name
+   System (DNS) IANA Considerations",draft-ietf-dnsext-iana-dns.
+
+   [IDNE]     Marc Blanchet,Paul  Hoffman, "Internationalized domain
+   names using EDNS (IDNE)", draft-ietf-idn-idne.
+
+   [CHNORM]   M. Duerst, M. Davis, "Character Normalization in IETF
+   Protocols", draft-duerst-i18n-norm.
+
+   [IDNCOMP]  Paul Hoffman, "Comparison of Internationalized Domain Name
+   Proposals", draft-ietf-idn-compare.
+
+   [NAMEPREP] Paul Hoffman, "Comparison of Internationalized Domain Name
+   Proposals", draft-ietf-idn-compare.
+
+   [SACE]     Dan Oscarsson, "Simple ASCII Compatible Encoding", draft-
+   ietf-idn-sace.
+
+   [RACE]     Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
+   for IDN", draft-ietf-idn-race.
+
+8. Acknowledgements
+
+   Paul Hoffman giving many comments in our e-mail discussions.
+
+   Ideas from drafts by Paul Hoffman, Stuart Kwan, James Gilroy and Kent
+   Karlsson.
+
+   Magnus Gustavsson, Mark Davis, Kent Karlsson and Andrew Draper for
+   comments on my draft.
+
+   Discussions and comments by the members of the IDN working group.
+
+
+
+Author's Address
+
+   Dan Oscarsson
+   Telia ProSoft AB
+   Box 85
+   201 20 Malmo
+   Sweden
+
+   E-mail: Dan.Oscarsson@trab.se
+
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001                [Page 9]
+
+Internet Draft               Universal DNS                27 August 2000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dan Oscarsson          Expires: 27 Februray 2001               [Page 10]
+
diff --git a/doc/draft/draft-ietf-idn-utf6-00.txt b/doc/draft/draft-ietf-idn-utf6-00.txt
new file mode 100644
index 00000000..e17a1007
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-utf6-00.txt
@@ -0,0 +1,451 @@
+Internet Engineering Task Force (IETF)                         Mark Welter
+INTERNET-DRAFT                                          Brian W. Spolarich
+draft-ietf-idn-utf6-00                                         WALID, Inc.
+November 16, 2000                                     Expires May 16, 2001
+
+
+        UTF-6 - Yet Another ASCII-Compatible Encoding for IDN
+
+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.
+
+The distribution of this document is unlimited.
+
+Copyright (c) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+This document describes a tranformation method for representing
+Unicode character codepoints in host name parts in a fashion that is 
+completely compatible with the current Domain Name System.  It is 
+proposed as a potential candidate for an ASCII-Compatible Encoding (ACE)
+for supporting the deployment of an internationalized Domain Name System.
+The tranformation method, an extension of the UTF-5 encoding proposed by
+Duerst, provides both for more efficient representation of typical Unicode 
+sequences while preserving simplicity and readability.  This transformation 
+method is deployed as part of the current WALID multilingual domain name 
+system implementation, although that status should not necessarily influence 
+the evaluation of its merits as a candidate encoding method.
+
+
+Table of Contents
+
+1.        Introduction
+1.1         Terminology
+2.        Hostname Part Transformation
+2.1         Post-Converted Name Prefix
+2.2         Hostname Prepartion
+2.3         Definitions
+2.4         UTF-6 Encoding
+2.4.1         Variable Length Hex Encoding
+2.4.2         UTF-6 Compression Algorithm
+2.4.3         Forward Transformation Algorithm
+2.5         UTF-6 Decoding
+2.5.1         Variable Length Hex Decoding
+2.5.2         UTF-6 Decompression Algorithm
+2.5.3         Reverse Transformation Algorithm
+3.        Examples
+3.1         'www.walid.com' (in Arabic)
+4.        Security Considerations
+5.        References
+
+
+1.  Introduction
+
+UTF-6 describes an encoding scheme of the ISO/IEC 10646 [ISO10646]
+character set (whose character code assignments are synchronized
+with Unicode [UNICODE3]), and the procedures for using this scheme
+to transform host name parts containing Unicode character sequences
+into sequences that are compatible with the current DNS protocol
+[STD13].  As such, it satisfies the definition of a 'charset' as
+defined in [IDNREQ].
+
+1.1  Terminology
+
+The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
+"MAY" in this document are to be interpreted as described in RFC 2119
+[RFC2119].
+
+Hexadecimal values are shown preceded with an "0x". For example,
+"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
+shown preceded with an "0b". For example, a nine-bit value might be
+shown as "0b101101111".
+
+Examples in this document use the notation from the Unicode Standard
+[UNICODE3] as well as the ISO 10646 names. For example, the letter "a"
+may be represented as either "U+0061" or "LATIN SMALL LETTER A".
+
+UTF-6 converts strings with internationalized characters into
+strings of US-ASCII that are acceptable as host name parts in current
+DNS host naming usage. The former are called "pre-converted" and the
+latter are called "post-converted".  This specification defines both
+a forward and reverse transformation algorithm.
+
+
+2.  Hostname Part Transformation
+
+According to [STD13], hostname parts must be case-insensitive, start and
+end with a letter or digit, and contain only letters, digits, and the
+hyphen character ("-"). This, of course, excludes most characters used
+by non-English speakers, characters, as well as many other characters in 
+the ASCII character repertoire. Further, domain name parts must be 
+63 octets or shorter in length.
+
+
+2.1  Post-Converted Name Prefix
+
+This document defines the string 'wq--' as a prefix to identify 
+UTF-6-encoded sequences.  For the purposes of comparison in the IDN 
+Working Group activities, the 'wq--' prefix should be used solely to 
+identify UTF-6 sequences.  However, should this document proceed beyond 
+draft status the prefix should be changed to whatever prefix, if any,
+is the final consensus of the IDN working group.
+
+Note that the prepending of a fixed identifier sequence is only one
+mechanism for differentiating ASCII character encoded international
+domain names from 'ordinary' domain names.  One method, as proposed in
+[IDNRACE], is to include a character prefix or suffix that does not
+appear in any name in any zone file.  A second method is to insert a
+domain component which pushes off any international names one or more
+levels deeper into the DNS heirarchy.  There are trade-offs between
+these two methods which are independent of the Unicode to ASCII
+transcoding method finally chosen.  We do not address the international
+vs. 'ordinary' name differention issue in this paper.
+
+2.2  Hostname Prepartion
+
+The hostname part is assumed to have at least one character disallowed
+by [STD13], and that is has been processed for logically equivalent 
+character mapping, filtering of disallowed characters (if any), and 
+compatibility composition/decomposition before presentation to the UTF-6 
+conversion algorithm.  
+
+While it is possible to invent a transcoding mechanism that relies
+on certain Unicode characters being deemed illegal within domain names
+and hence available to the transcoding mechanism for improving encoding
+efficiency, we feel that such a proposal would complicate matters
+excessively.  We also believe that Unicode name preprocessing for
+both name resolution and name registration should be considered as s
+separate, independent issues, which we will attempt to address in a
+separate document.
+
+2.3  Definitions
+
+For clarity:
+
+  'integer' is an unsigned binary quantity;
+  'byte' is an 8-bit integer quantity;
+  'nibble' is a 4-bit integer quantity.
+
+2.4  UTF-6 Encoding
+
+The idea behind this scheme was to improve on the UTF-5 transformation
+algorithm described in [IDNDUERST] by providing a straightforward
+compression mechanism.  UTF-6 defines a compression mechanism by
+indentifying identical leading byte or nibble values in the pre-converted
+string, and using the length of this leading value to select a mask which
+can be applied to the pre-converted string.  The resulting post-converted
+string is preserves the simplicity and readability of UTF-5 while 
+enabling longer sequences to be encoded into a single host name part.
+
+2.4.1  Variable Length Hex Encoding
+
+The variable length hex encoding algorithm was introduced by Duerst in 
+[IDNDUERST].  It encodes an integer value in a slight modification of 
+traditional hexadecimal notation, the difference being that the most 
+significant digit is represented with an alternate set of "digits" 
+- -- 'g through 'v' are used to represent 0 through 15.  The result is a 
+variable length encoding which can efficiently represent integers of 
+arbitrary length. 
+
+The variable length nibble encoding of an integer, C, is defined
+as follows:
+
+  1.  Skip over leading non-significant zero nibbles to find I,
+      the first significant nibble of c;
+
+  2.  Emit the Ith character of the set [ghijklmopqrstuv];
+
+  3.  Continue from most to least significant, encoding each remaining
+      nibble J by emitting the Jth character of the set [0123456789abcdef].
+
+Examples:
+
+  0x1f4c    is encoded as "hf4c"
+  0x0624    is encoded as "m24"
+  0x0000    is encoded as "g"
+  'n'       a single character in single quotes stands for the 
+            Unicode code point for that character.  
+
+2.4.2  UTF-6 Compression Algorithm
+
+UTF-6 improves on the UTF-5 encoding by providing compression, which
+enables encoding of a larger number of characters in each hostname
+part.  The compression algorithm is defined as follows:
+
+  1.  Set the mask to 0xFFFF;
+
+  2.  If the number of non '-' characters is less than 2, proceed to 
+      step 5;
+
+  3.  If the most significant byte of every non '-' character is the
+      same value:
+
+      3a.  Set HB to this value;
+      3b.  Emit 'Y';
+      3c.  Emit the variable length hex encoding of HB;
+      3d.  Set the mask to 0x00FF;
+      3e.  Proceed to step 5.
+
+  4.  If the most significant nibble of every non '-' character is the
+      same value:
+
+      4a.  Set HN to this value;
+      4b.  Emit 'Z';
+      4c.  Emit the variable length hex encoding of HN;
+      4d.  Set the mask to 0x0FFF.
+
+  5.  Foreach input character:
+
+      5a.  Set HN to the result of the bitwise AND of the input
+           character and the mask;
+      5b.  Emit the variable length nibble encoding of HN. 
+  
+2.4.3  Forward Transformation Algorithm
+
+The UTF-6 transformation algorithm accepts a string in UTF-16 
+[ISO10646] format as input.  The encoding algorithm is as follows:
+
+  1.  Break the hostname string into dot-separated hostname parts. 
+      For each hostname part, perform steps 2 and 3 below;
+
+  2.  Compress the component using the method described in section
+      2.4.2 above, and encode using the encoding described in section 2.4.1;
+
+  3.  Prepend the post-converted name prefix 'wq--' (see section 2.1
+      above) to the resulting string.
+
+
+2.5  UTF-6 Decoding
+
+2.5.1  Variable Length Hex Decoding
+
+  1.  Let N be the lower case of the first input character;
+
+      If N is not in set [ghijklmnopqrstuv] return error,
+        else consume the input character;
+
+  2.  Let R = N - 'g';
+
+  3.  If another input character exists,
+        then let N be the lower case of the next input character,
+        else goto Step 9;
+
+  4.  If N is not in the set [0123456789abcdef], go to Step 9;
+
+  5.  Let N = the lower case of the next input character and consume
+      the input character;
+
+  6.  Let R = R * 16;
+
+  7.  If N is in set [0123456789], 
+        then let R = R + (N - '0'),
+        else let R = R + (N - 'a') + 10;
+
+  8.  Go to step 3;
+
+  9.  Return decoded result R.
+
+2.5.2  UTF-6 Decompression Algorithm
+
+  1.  Let N be the lower case of the first input character;
+
+  2.  If N != 'y' and N != 'z',
+
+      2a.  Let CPART be 0;
+      2b.  Let VMAX be 0xFFFF;
+
+      This is the no-compression case;
+
+  3.  If N == 'y',
+        
+      3a.  Let M be the variable length hex decoding of the next 
+           character;
+      3b.  Let CPART be the result of M * 0x0100;
+      3c.  Let VMAX be 0x00FF;
+      3d.  Continue to Step 5;
+
+  4.  If N == 'z',
+
+      4a.  Let M be the variable length hex decoding of the next
+           character;
+      4b.  Let CPART be the result of M * 0x1000;
+      4c.  Let VMAX be 0x0FFF;
+      4d.  Continue to Step 5;
+
+  5.  While another input character exists, let N be the lower case of
+      the next input character, and do the following:
+
+      5a.  If N == '-' consume the character and 
+             then append '-' to the result string,
+             else let VPART be the next variable hex decoded value;
+      5b.  If VPART > VMAX, return error,
+             else append CPART + VPART to the result string;
+
+  6.  Return the result string.
+      
+2.5.3  Reverse Transformation Algorithm
+
+  1.  Break the string into dot-separated components and apply Steps
+      2 through 4 to each component:
+
+  2.  Check for legality (in terms of RFC1035 permitted characters) and
+      return error status if illegal,
+  
+  3.  Remove the post converted name prefix 'wq--' (see Section 2.1),
+
+  4.  Decompress the component using the decompression algorithm
+      described above.
+
+  5.  Concatenate the decoded segments with dot separators and return.
+
+
+3.  Examples
+
+The examples below illustrate the encoding algorithm and provide
+comparisons to alternate encoding schemes.  UTF-5 sequences are
+prefixed with '----', as no ACE prefix was defined for that encoding.
+
+3.1  'www.walid.com' (in Arabic):
+
+  UTF-16:  U+0645 U+0648 U+0642 U+0639 . U+0648 U+0644 U+064A U+062F .
+           U+0634 U+0631 U+0643 U+0629
+
+  UTF-6:   wq--ymk5k8k2j9.wq--ymk8k4kaif.wq--ymj4j1k3i9
+
+  UTF-5:   ----m45m48m42m39.----m48m44m4am2f.----m34m31m43m29
+
+  RACE:    bq--azcuqqrz.bq--azeeisrp.bq--ay2dcqzj
+
+  LACE:    bq--aqdekscche.bq--aqdeqrckf5.bq--aqddimkdfe
+
+
+3.2  Mixed Katakana and Hiragana (SOREZORENOBASHO)
+
+  UTF-16:  U+305D U+308C U+305E U+308C U+306E U+5834 U+6240
+ 
+  UTF-6:   
+
+  UTF-5:   
+
+  RACE:    bq--4ayf3memgbpdbdbqnzmdiysa
+
+  LACE:    bq--auyf4dc7rrxacwbuafrea
+
+
+3.3  Currently Disallowed ASCII Characters ($OneBillionDollars!):
+
+  UTF-16:  U+0024 U+004F U+006E U+0065 U+0042 U+0069 U+006C U+006C 
+           U+0069 U+006F U+006E U+0044 U+006F U+006C U+006C U+0061 
+           U+0072 U+0073 U+0021 
+
+  UTF-6:
+
+  UTF-5:
+
+  RACE:   bq--aase74tfijuwy4djn6xei44mnrqxe5zb
+
+  LACE:   bq--cmacit4omvbgs4dmnfxw5rdpnrwgc5ttee
+
+4.  Security Considerations
+
+Much of the security of the Internet relies on the DNS and any
+change to the characteristics of the DNS may change the security of
+much of the Internet. Therefore UTF-6 makes no changes to the DNS itself.
+
+UTF-6 is designed so that distinct Unicode sequences map to distinct
+domain name sequences (modulo the Unicode and DNS equivalence rules).
+Therefore use of UTF-6 with DNS will not negatively affect security.
+
+5.  References
+
+[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name 
+Proposals", draft-ietf-idn-compare.
+
+[IDNREQ] James Seng, "Requirements of Internationalized Domain Names",
+draft-ietf-idn-requirement.
+
+[IDNNAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of 
+Internationalized Host Names", draft-ietf-idn-nameprep
+
+[IDNDUERST] M. Duerst, "Internationalization of Domain Names",
+draft-duerst-dns-i18n.
+
+[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
+technology -- Universal Multiple-Octet Coded Character Set (UCS) --
+Part 1: Architecture and Basic Multilingual Plane.  Five amendments and
+a technical corrigendum have been published up to now. UTF-16 is
+described in Annex Q, published as Amendment 1. 17 other amendments are
+currently at various stages of standardization. 
+
+[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels", March 1997, RFC 2119.
+
+[STD13] Paul Mockapetris, "Domain names - implementation and
+specification", November 1987, STD 13 (RFC 1035).
+
+[UNICODE3] The Unicode Consortium, "The Unicode Standard -- Version
+3.0", ISBN 0-201-61633-5. Described at
+<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
+
+A.  Acknowledgements
+
+The structure (and some of the structural text) of this document is 
+intentionally borrowed from the LACE IDN draft (draft-ietf-idn-lace) 
+by Mark Davis and Paul Hoffman.
+
+The 'SOREZORENOBASHO' example was taken from draft-ietf-idn-brace draft
+by Adam Costello.
+
+B.  IANA Considerations
+
+There are no IANA considerations in this document.
+
+C.  Author Contact Information
+
+Mark Welter
+Brian W. Spolarich
+WALID, Inc.
+State Technology Park
+2245 S. State St.
+Ann Arbor, MI  48104
++1-734-822-2020
+
+mwelter@walid.com
+briansp@walid.com
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.0.1 (GNU/Linux)
+Comment: For info see http://www.gnupg.org
+
+iD8DBQE6FaCt/DkPcNgtD/0RAtRmAJwISVeJGY6qmll71mL+Axc51o8iIwCgmNt/
+86RcQh1JQYWTux+8FS+XvMU=
+=bxiv
+-----END PGP SIGNATURE-----
+
diff --git a/doc/draft/draft-ietf-idn-version-00.txt b/doc/draft/draft-ietf-idn-version-00.txt
new file mode 100644
index 00000000..2e67d206
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-version-00.txt
@@ -0,0 +1,254 @@
+Internet Draft                                   Marc Blanchet
+
+draft-ietf-idn-version-00.txt                         Viagenie
+October 26, 2000
+Expires in six 
+months 
+
+
+
+
+     Handling versions of internationalized domain names protocols
+
+
+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 describes some issues related to handling changes in the
+codepoints and other features in the chars space of an internationalized
+domain name as well as changes in the protocol that supports it (whatever
+that be).  It also presents some solutions to these issues.
+
+
+1. Rationale
+
+The nameprep draft [NAMEPREP] is defining prohibited chars, normalization 
+algorithms, etc.. The current concensus is to take the safer approach of 
+not accepting new chars if they are not listed, since the new characters 
+that can be included in the subsequent releases of the universal character 
+set can have an impact on the domain name (for example, a new variation of 
+the dot . will mostly be non-compatible and being excluded).
+
+The Unicode and ISO-10646 versioning is designed not for the same purpose 
+as the idn work: for example, some chars or properties can be changed or 
+added to those repertoires that cannot be taken as is by the idn 
+protocol.  In essence, the idn nameprep versions cannot be in sync with 
+unicode/iso versions. idn need its own versioning of the accepted character 
+set, which can or cannot be synchronized with the two others. While saying 
+that, there is no intent at all to define new codepoints inside this work 
+and any attempt to do that must be rejected.
+
+Since internationalization and specifically internationalization of the 
+domain names is new, we don't really know if the chosen algorithm, protocol 
+and codepoitns will not have any problem in the future. We need to handle 
+versions of the protocol and to have a specific table for idn accepted chars.
+
+2. Versioning of the protocol
+
+Since the idn table of chars will be changed in the future, and possibly 
+the algorithms and the processing, then there is a need to handle these 
+situations in a controlled way. A version of the idn protocol should be 
+defined and included as part of the exchange between the parties so that 
+they can handle smoothly the new revisions.
+
+2.1 Implementing the version in the protocol
+Depending on which way the idn protocol will be, a different versioning 
+will have to be defined. We will discuss the current proposals and identify 
+where a versioning system can be handled.
+
+2.1.1 Proposals based on extensions of the DNS protocol
+  Proposals based on extensions of the DNS protocol should include in the 
+bits the version number and a way to exchange version numbers between the 
+parties. [IDNE] already defined a version number as part of the use of 
+EDNS. Similar versioning should be defined in the other proposed protocols.
+
+2.1.2 Proposals based on ACE and application
+  Since ACEs (for example [RACE]) in applications [IDNA] do not change the 
+DNS protocol but only encode the idn in a ascii compatible way, it looks 
+more difficult to include a version number in the ACE encoding, since it 
+will change the domain name.  The proposal is to use a different 
+prefix/suffix for each version, by using one of the chars used in the 
+prefix as a version number, beginning with the lowest possible ascii char 
+available and increase the ascii codepoint of the char by 1 for each 
+version. For example, if the prefix is "ra--", then the first version of 
+idn will be "ra--", the second version will be "rb--", the third "rc--". 
+While this would be more elegant, one can handle versioning by having 
+different prefixes for each version, while chosing prefixes randomly (i.e. 
+1st version: rq--, 2nd version: wz--, ...). IANA should block all possible 
+prefixes so that no pre-registration is permitted.
+
+2.2 Major and minor version numbers
+
+  A <major>.<minor> version number is proposed (i.e. 1.0, 1.1, 2.0). A 
+minor revision is defined to be as new chars or small changes in the table 
+to be handled without any modification of algorithm.  The idea here is to 
+enable easy upgrading of idn processors when only new chars will be 
+handled.  In this case, the binary software do not have to be changed and 
+only the table containing the chars has to be changed to enable a new 
+version.  A major revision means that the software has to be upgraded since 
+it implies new ways of handling idn which are not identified in the table.
+
+2.3 Processing of the version numbers
+Any idn processor MUST verify the version number before processing. When a 
+major version number is higher than what the processor currently handle is 
+detected, processing MUST be stopped and rejected. When a minor version 
+number is higher than what the processor currently handle, then any 
+intermediate processors MUST forward the idn but the end processor (i.e. 
+the dns server authoritative for that zone that is handling the request) 
+MUST stop and reject the request.  Specific handling of rejecting the 
+request should be defined in the protocol document.
+
+2.4 Version numbers
+  Version numbers of the idn protocol will be handled by IANA. A 
+IESG-reviewed document should be used as the basis for IANA to define a new 
+protocol version number.
+
+3. Idn table
+  Since the unicode consortium and ISO will issue new versions not at the 
+same time as the idn protocol versioning, the IETF need to have its own 
+registered table of accepted idn chars. This will also enable specific data 
+only useful for idn. The intent is not to duplicate the unicode/iso effort, 
+it is to support the specific needs of the idn group.  For example, it is 
+possible that specific chars will have a different behavior than the normal 
+Unicode way: the special casing for final or non-final letters in the 
+Unicode SpecialCasing.txt file can be merged (ie not totally identical to 
+the unicode processing) to only one casing since final and non-final 
+letters have less meaning in a domain name. Simpler processing for idn is 
+also useful: for example, the Lud property is probably not useful in the 
+idn context and can be considered equivalent to Lu. Combining those 
+properties together means much simple table and simpler processing and less 
+errors in implementations. Added chars, codepoint, properties MUST NOT be 
+done in this file, but must be done within the Unicode/ISO process.
+
+This document proposes a table contained in an ascii file handled by IANA 
+and available in the IANA public directory. The source of the table will be 
+the Unicode table, with a similar format, but a simpler, and perhaps 
+different, content based on the needs of the idn protocol. Proposed 
+filename is: idntab.txt.
+
+This file format will also help implementors to have the same input 
+description and exhaustive list of which chars and processing to handle 
+idn. This is easier for implementors to have a complete list of accepted 
+chars instead a list of non-accepted chars.  The hope is also to help 
+decrease the different behaviors between the different implementations. 
+This table can be considered as an implementation of [NAMEPREP].
+
+3.1 File format
+
+The file is divided in two parts. The first part contains variables. The 
+second part contains all the chars accepted for idn. The two parts are 
+separated by a empty line.
+
+The format of the first part is:
+tag=value<CR><LF>
+
+Currently, only the version tag is defined. The "version" tag defines the 
+highest idn version number that can be found in this table.  The intent is 
+to have only one file that is kept current but where the beginning of the 
+file can be used by parsers to identify the latest version of the file.
+
+The first idntab.txt file will define version=1.0:
+version=1.0<CR><LF>
+
+The format of the second part is:
+  one codepoint per line
+  lines separated by CR/LF
+  each field in the line separated by ";"
+
+The fields are (in order, from left to right):
+  1. codepoint in hexadecimal (as in unicode table): HHHH
+  2. first version of idn table that this char is supported
+
+It is possible that new fields will be added in the future. Parsers should 
+ignore the fields that they don't understand.
+
+Spaces (ascii  0x20) are ignored. Comments are identified by "#". All text 
+following the comment char up to the end of line is ignored. Any codepoint 
+not in the table is considered prohibited. Codepoints that are prohibited 
+may be included in the table inside commented lines in order to help a 
+reader to see explicitly which ones are prohibited.
+
+Example of the file idntab10.txt:
+version=1.0<CR><LF>
+<CR><LF>
+0041;1.0;
+
+4. Security Considerations
+
+Changing the way a software react about domain names is clearly something 
+that have security impacts. While the actual table doesn't present any 
+security threat by itself, if there is someways by a intruder to reload a 
+new table into a idn processor software without the knowledge of the user, 
+then it can completly disables name resolution or have other possible 
+threats.  In conclusion, care must be taken by software developers on how 
+to manage the insertion of a new idn table in a idn processor software.
+
+5. IANA Considerations
+  This document describes versions of the idn file called idntab.txt. The 
+file should be kept in the IANA public directory for references purposes. 
+New versions of the file should be made available after IESG review of a 
+document.  Old revisions of the file (idntab-xy.txt) should be kept for 
+documentation purposes.
+
+6. Acknowledgements
+  The author would like to acknowledge the comments and idea of the 
+following people: Fran‡ois Yergeau and Paul Hoffman.
+
+7. Author
+
+Marc Blanchet
+Viagenie
+2875 boul. Laurier, bur. 300
+Ste-Foy, Quebec, Canada
+G1V 2M2
+Marc.Blanchet@viagenie.qc.ca
+tel: 418-656-9254
+
+8. References
+
+[NAMEPREP] Preparation of Internationalized Host Names, Paul Hoffman, Marc 
+Blanchet. Work in progress.
+
+[RACE] RACE: Row-based ASCII Compatible Encoding for IDN, Paul Hoffman. 
+Work in progress.
+
+[IDNA] Internationalizing Host Names In Applications (IDNA), Paul Hoffman, 
+Patrick Falstrom. Work in progress.
+
+
+Marc Blanchet
+Viag‰nie inc.
+tel: 418-656-9254
+http://www.viagenie.qc.ca
+
+----------------------------------------------------------
+Normos (http://www.normos.org): Internet standards portal:
+IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.
+
diff --git a/doc/draft/draft-ietf-idn-vidn-00.txt b/doc/draft/draft-ietf-idn-vidn-00.txt
new file mode 100644
index 00000000..fbf31502
--- /dev/null
+++ b/doc/draft/draft-ietf-idn-vidn-00.txt
@@ -0,0 +1,537 @@
+
+IETF IDN Working Group                                    Sung Jae Shim
+Internet Draft                                           DualName, Inc.
+Document: draft-ietf-idn-vidn-00.txt                   14 November 2000
+Expires: 14 May 2001 
+ 
+ 
+              Virtually Internationalized Domain Names (VIDN) 
+    
+    
+   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. 
+    
+    
+   1. Abstract 
+    
+   This document describes a method that internationalizes existing as 
+   well as future domain names in English, not making any change to the 
+   current DNS, not requiring separate name server or resolver, and not 
+   creating domain names in non-English languages. Based upon the 
+   knowledge of transliteration between a local language and English, 
+   the method allows a user to use virtual domain names in the user's 
+   preferred local language by converting them into the corresponding 
+   actual domain names in English that comply with the current DNS. The 
+   conversion takes place automatically and transparently in the user's 
+   applications before DNS queries are sent. The method uses the current 
+   DNS as it is and meets all the requirements of internationalized 
+   domain names as described in Wenzel and Seng [2]. 
+    
+    
+   2. Conventions and definitions used in this document 
+    
+   The key words "REQUIRED" and "MAY" in this document are to be 
+   interpreted as described in RFC-2119 [1]. 
+    
+   A "host" is a computer or device attached to the Internet. A "user 
+   host" is a computer or device with which a user is connected to the 
+
+  
+
+               Virtually Internationalized Domain Names  November 2000 
+ 
+   Internet, and a "user" is a person who uses a user host. A "server 
+   host" is a computer or device that provides services to user hosts. 
+    
+   An "entity" is an organization or individual that has a domain name 
+   registered with the DNS. 
+    
+   A "local language" is a language other than English that a user 
+   prefers to use in a local context. 
+    
+   A "virtual domain name" is a domain name in a local language, and it 
+   is not registered with the DNS but used for the convenience of a 
+   user. An "actual domain name" is a domain name in English, and it is 
+   actually used in the DNS. A "domain name" refers to an actual domain 
+   name in English that complies with the DNS, unless specified 
+   otherwise. 
+    
+   A "coded portion" is a pre-coded portion of a domain name (e.g., 
+   generic organization codes including `com', `edu', `gov', `int', 
+   `mil', `net', `org', and country codes such as `kr', `jp', and so 
+   on). An "entity-defined portion" is a portion of a domain name, which 
+   is defined by the entity that holds the domain name (e.g., 
+   organization name, server name, and so on). 
+    
+   The method proposed in this document is called "virtually 
+   internationalized domain names (VIDN)" because it uses virtual domain 
+   names in local languages to internationalize actual domain names in 
+   English that comply with the DNS. 
+    
+   A number of Korean-language characters are used in the original of 
+   this document for examples, which is available from the author upon 
+   request. The software used for Internet-Drafts does not allow using 
+   multilingual characters other than ASCII characters. Thus, this 
+   document may not display Korean-language characters properly, 
+   although it may be comprehensible without the examples using Korean-
+   language characters. Also, when you open the original of this 
+   document, please select your view encoding type to Korean for Korean-
+   language characters to be displayed properly. 
+    
+    
+   3. Introduction 
+    
+   Domain names are valuable to Internet users as a main identifier of 
+   hosts on the Internet. The current DNS allows using only English 
+   characters in naming hosts or clusters of hosts on the Internet. More 
+   specifically, the DNS uses only the basic Latin alphabets (case-
+   insensitive), the decimal digits (0-9) and the hyphen (-) in domain 
+   names. But there is a growing need for internationalized or non-
+   English domain names. Recognizing this need, various methods have 
+   been proposed to use non-English characters in domain names. But to 
+   date, it seems that no method has met all the requirements of 
+   internationalized domain names as described in Wenzel and Seng [2]. 
+    
+   A group of earlier methods has tried to put internationalized domain 
+   names inside some parts of the overall DNS system, using UCS encoding 
+  
+
+               Virtually Internationalized Domain Names  November 2000 
+ 
+   schemes. But these methods put too much of a burden on the DNS, 
+   requiring a great deal of work for transition and update of the DNS 
+   components. Another group of earlier methods has tried to build 
+   separate directory services for internationalized domain names or 
+   internationalized keywords. But these methods also require complex 
+   implementation efforts, duplicating much of the work already done for 
+   the DNS. Both the groups of earlier methods have tried to build some 
+   mechanisms inside or outside the DNS and put internationalized domain 
+   names or internationalized keywords there in addition to existing 
+   domain names in English. 
+    
+   Unlike earlier methods that involve a lengthy and costly process of 
+   implementation, VIDN provides a more immediate and less costly 
+   solution to internationalized domain names by focusing on 
+   internationalizing existing as well as future domain names in English 
+   that comply with the current DNS, without actually creating domain 
+   names in local languages. VIDN takes notice of the fact that most 
+   domain names used in regions where English is not widely spoken, have 
+   their entity-defined portions consisting of characters or words in 
+   English as transliterated from characters and words in the respective 
+   local languages. Based upon the knowledge of transliteration between 
+   a local language and English, VIDN allows using virtual domain names 
+   in a local language by converting them into the corresponding actual 
+   domain names in English that comply with the current DNS. VIDN allows 
+   the same domain names to be used not only in English as usual but 
+   also in local languages, without creating additional domain names in 
+   local languages. 
+    
+    
+   4. VIDN method 
+    
+   4.1. Objectives 
+    
+   To date, the methods for internationalized domain names have tried to 
+   create domain names or keywords in local languages one way or another 
+   in addition to existing domain names in English, and put them inside 
+   or outside the DNS, using special encoding schemes or lookup 
+   services. These methods require a lengthy and costly process of 
+   implementation. Even when they are successfully implemented, these 
+   methods may localize the Internet by separating it into groups of 
+   local languages that are less universal than English. Further, these 
+   methods may cause disputes on copyrights, trademarks, and so on in 
+   local contexts, in addition to all those disputes we observe with 
+   current domain names in English. VIDN intends to provide a solution 
+   to the problems of earlier methods, by (1) allowing the same domain 
+   names to be used both in English and local languages, without 
+   creating domain names in local languages, (2) working in applications 
+   at user hosts automatically and transparently before DNS requests are 
+   sent, (3) using the current DNS as it is, without requiring any 
+   additional name server or resolver, and (4) being implemented 
+   immediately with little cost. 
+    
+    
+   4.2. Description 
+  
+
+               Virtually Internationalized Domain Names  November 2000 
+ 
+    
+   It is important to note that most domain names used in regions where 
+   English is not widely spoken have their entity-defined portions 
+   consisting of characters or words in English as transliterated from 
+   characters or words in local languages. These transliterated 
+   characters or words in English do not have any meanings in English, 
+   but their originals in local languages before the transliteration 
+   into English have some meanings in local contexts, usually indicating 
+   organization names, brand names, trademarks, and so on. VIDN allows 
+   using these original characters or words in local languages as the 
+   entity-defined portions of virtual domain names in local languages, 
+   by transliterating them into the corresponding entity-defined 
+   portions of actual domain names in English. In this way, VIDN allows 
+   the same domain names in English to be also used virtually in local 
+   languages without actually creating domain names in local languages. 
+    
+   As domain names overlay IP addresses, so virtual domain names in 
+   local languages do actual domain names in English. The relationship 
+   between virtual domain names in a local language and actual domain 
+   names in English can be depicted as: 
+    
+                  +---------------------------------+ 
+                  |              User               | 
+                  +---------------------------------+ 
+                       |                       | 
+      +----------------|-----------------------|------------------+ 
+      |                v   (Transliteration)   v                  | 
+      |   +---------------------+  |  +-----------------------+   | 
+      |   | Virtual domain name |  |  |   Actual domain name  |   |  
+      |   | in a local language |--+->|   in English          |   | 
+      |   +---------------------+     +-----------------------+   | 
+      |                    User application    |                  | 
+      +----------------------------------------|------------------+ 
+                                               v 
+                                           DNS request 
+    
+   VIDN uses the phonemes of a local language and English as a medium in 
+   transliterating the entity-defined portions of virtual domain names 
+   in the local language into those of actual domain names in English. 
+   This process of transliteration can be depicted as: 
+    
+           Local language                           English 
+   +----------------------------+       +-----------------------------+ 
+   | Characters ----> Phonemes -----------> Phonemes ----> Characters | 
+   |              |             |   |   |              |              | 
+   |              |             |   |   |              |              | 
+   | (Inverse of transcription) | Match |        (Transcription)      | 
+   +----------------------------+       +-----------------------------+ 
+                  |                                    ^ 
+                  |         (Transliteration)          | 
+                  +------------------------------------+ 
+    
+   First, each entity-defined portion of a virtual domain name in the 
+   local language is decomposed into individual characters or sets of 
+  
+
+               Virtually Internationalized Domain Names  November 2000 
+ 
+   characters so that each individual character or set of characters can 
+   represent an individual phoneme of the local language, which is the 
+   inverse of transcription of phonemes into characters. Second, each 
+   individual phoneme of the local language is matched with an 
+   equivalent phoneme of English that has the same or most proximate 
+   sound. Third, each phoneme of English is transcribed into the 
+   corresponding character or set of characters in English. Finally, all 
+   the characters or sets of characters converted into English are 
+   united to compose the corresponding entity-defined portion of an 
+   actual domain name in English. 
+    
+   For example, a word in Korean, `??' that means `century' in  English, 
+   is transliterated into `segi' in English, and so, the entity whose 
+   name contains `??' in Korean may have an entity-defined portion of 
+   its domain name as `segi' in English. VIDN allows using `??' in 
+   Korean as an entity-defined portion of a virtual domain name in 
+   Korean, which is converted into `segi' in English, the corresponding 
+   entity-defined portion of an actual domain name in English. More 
+   specifically, the phonemes represented by the characters consisting 
+   of `??' in Korean have the same sounds as the phonemes represented 
+   by the characters consisting of `segi' in English. In the local 
+   context, `??' in Korean is clearly easier to remember and type and 
+   more intuitive and meaningful than `segi' in English. 
+    
+   An entity-defined portion of a virtual domain name in Korean, `??', 
+   is transliterated into `yahoo' in English, since the phonemes 
+   represented by the characters consisting of `??' in Korean have the 
+   same sounds as the phonemes represented by the characters consisting 
+   of `yahoo' in English. That is, `??' in Korean is pronounced as the 
+   same as `yahoo' in English, and so, it is easy for Korean-speaking 
+   people to deduce `??' in Korean as the virtual equivalent of 
+   `yahoo' in English. VIDN allows using virtual domain names in a local 
+   language for domain names whose originals are in the local language, 
+   e.g., `??' in Korean, as well as domain names whose originals are 
+   in English, e.g., `??' in Korean. In this way, VIDN can make domain 
+   names truly international, allowing the same domain names to be used 
+   both in English and local languages. 
+    
+   The coded portions of domain names such as organization codes, 
+   geographic codes and country codes, can also be transliterated from a 
+   local language into English, using the phonemes of the two languages 
+   as a medium. For example, seven generic organization codes in English, 
+   `com', `edu', `gov', `int', `mil', `net', and `org', can be 
+   transliterated from `?', `??', `??', `??', `?', `??', `??' in 
+   Korean, respectively, which can be used as the corresponding 
+   organization codes of virtual domain names in Korean. Based upon its 
+   meaning in English, each coded portion of actual domain names also 
+   can be pre-assigned a virtual equivalent word or code in a local 
+   language. For example, seven generic organization codes in English, 
+   `com', `edu', `gov', `int', `mil', `net', and `org', can be pre-
+   assigned `??' (meaning `commercial' in Korean), `??' (meaning 
+   `education' in Korean), `??' (meaning `government' in Korean), 
+   `??' (meaning `international' in Korean), `??' (meaning `military' 
+   in Korean), `??' (meaning `network' in Korean), and `??' (meaning 
+  
+
+               Virtually Internationalized Domain Names  November 2000 
+ 
+   `organization' in Korean), respectively, which can be used as the 
+   corresponding organization codes of virtual domain names in Korean. 
+    
+   Since VIDN uses the phonemes of a local language and English as a 
+   medium of the transliteration, it does not create such complexities 
+   as other conversion methods based upon semantics do. Further, most 
+   languages have a small number of phonemes. For example, Korean 
+   language has nineteen consonant phonemes and twenty-one vowel 
+   phonemes, and English language has twenty-four consonant phonemes and 
+   twenty vowel phonemes. Each phoneme of Korean language can be matched 
+   with a phoneme of English language that has the same or proximate 
+   sound, and vice versa. 
+    
+   Some characters or sets of characters of a language may represent 
+   more than one phoneme. Also, some phonemes of a language may be 
+   represented by more than one character or set of characters. But 
+   these variations usually occur in particular situations, and so, VIDN 
+   incorporates the special provisions to deal with such variations. In 
+   addition, not every character or set of characters in a local 
+   language may be neatly transliterated into only one character or set 
+   of characters in English. In practice, people often transliterate the 
+   same word in a local language differently into English or vice versa. 
+   VIDN also incorporates the provisions to deal with such variations 
+   caused by common usages or idiomatic expressions. Because of these 
+   variations, however, it is probable for one virtual domain name 
+   entered in a local language to result in more than one actual domain 
+   name in English. 
+    
+   VIDN includes a coding scheme in order to make each virtual domain 
+   name entered in a local language correspond to exactly one actual 
+   domain name in English. In this coding scheme, a unique code is pre-
+   assigned to one of the corresponding actual domain names in English 
+   for each virtual domain name to be entered in a local language. The 
+   code is kept somewhere at the server host that has the actual domain 
+   name in English, for example, in the main HTML document at the server 
+   host, so that VIDN can check the code. VIDN also generates the same 
+   unique code whenever the corresponding virtual domain name is entered 
+   in user applications. Then, VIDN checks whether the code at each 
+   server host matches with the code generated in user applications. If 
+   one of the server hosts has the code that matches with the code 
+   generated in user applications, VIDN recognizes that the virtual 
+   domain name entered by the user corresponds only to the actual domain 
+   name of that server host, and connects the user host to the server 
+   host. The domain names of the remaining server hosts that do not have 
+   the matching code may be listed to the user as alternative sites. For 
+   security purpose, this coding scheme may use an encryption technique. 
+    
+   For example, `??.?', a virtual domain name entered in Korean, may 
+   result in four corresponding domain names in English including 
+   `jungang.com', `joongang.com,' `chungang.com', and `choongang.com', 
+   since the phonemes represented by characters consisting of `??.?' 
+   in Korean can have the same or almost the same sounds as the phonemes 
+   represented by characters consisting of `jungang.com', 
+   `joongang.com,' `chungang.com', or `choongang.com' in English. In 
+  
+
+               Virtually Internationalized Domain Names  November 2000 
+ 
+   this case, we assume that the server host with its domain name 
+   `jungang.com' has the pre-assigned code that matches with the code 
+   generated when `??.?' in Korean is entered in user applications. 
+   Then, the user host is connected to this server host, and the other 
+   server hosts may be listed to the user as alternative sites so that 
+   the user can try them. 
+    
+   The process of this coding scheme that makes each virtual domain name 
+   in a local language correspond to only one actual domain name in 
+   English, can be depicted as: 
+    
+                  +---------------------------------+ 
+                  |              User               | 
+                  +---------------------------------+ 
+                       |                       | 
+      +----------------|-----------------------|------------------+ 
+      |                v                       v                  | 
+      |   +---------------------+     +-----------------------+   | 
+      |   | Virtual domain name |     | Potential domain names|   |  
+      |   | in a local language |---->| in English            |   | 
+      |   | e.g., `??.?'      |     | e.g., `jungang.com'   |   | 
+      |   |       (code: 297437)|     |       `joongang.com'  |   | 
+      |   |                     |     |       `chungang.com'  |   | 
+      |   |                     |     |       `choongang.com' |   | 
+      |   +---------------------+     +-----------------------+   | 
+      |                    User application    |                  | 
+      +----------------------------------------|------------------+ 
+                       ^                       | 
+                       |                       | Code check by VIDN 
+       Connection to   |                       |    +-- `jungang.com'   
+       the server host |                       |    |   (code: 297437) 
+       `jungang.com'   |                       |    |-- `joongang.com' 
+                       |                       |----+   (not active) 
+                       |                       |    |-- `chungang.com' 
+                       |                       |    |   (code: 381274) 
+                       |    DNS request and    |    +-- `choongang.com' 
+                       |    response           |        (not active) 
+                       +-----------------------+ 
+    
+   Since VIDN converts separately the entity-defined portions and the 
+   coded portions of a virtual domain name, it preserves the current 
+   syntax of domain names, that is, the hierarchical dotted notation, 
+   which Internet users are familiar with. Also, VIDN allows using a 
+   virtual domain name mixed with characters in a local language and 
+   English as the user wishes to, since the conversion takes place on 
+   each individual portion of the domain name and each individual 
+   character or set of characters of the portion. 
+    
+   While VIDN preserves the hierarchical dotted notation of current 
+   domain names, the principles of VIDN are also applicable to domain 
+   names in other possible notations such as those in a natural language 
+   (e.g., `microsoft windows' rather than `windows.microsoft.com'). Also, 
+   the principles of VIDN can be applied into other identifiers used on 
+   the Internet, such as user IDs of e-mail addresses, names of 
+  
+
+               Virtually Internationalized Domain Names  November 2000 
+ 
+   directories and folders, names of web pages and files, keywords used 
+   in search engines and directory services, and so on, allowing them to 
+   be used interchangeably in a local language and English, without 
+   creating additional identifiers in the local language. The conversion 
+   of VIDN can be done between any two languages interchangeably. Thus, 
+   even when the DNS accepts and registers domain names in other 
+   languages in addition to English, VIDN can allow using the same 
+   domain names in any two languages by converting virtual domain names 
+   in one language into actual domain names in another language. 
+    
+    
+   4.3. Implementation 
+    
+   In a preferred arrangement, VIDN is implemented in applications at 
+   the user host. That is, the conversion of virtual domain names in a 
+   local language into the corresponding actual domain names in English 
+   takes place at the user host before DNS requests are sent. Thus, 
+   neither a special encoding nor a separate lookup service is needed to 
+   implement VIDN. VIDN is also modularized with each module being used 
+   for conversion of virtual domain names in one local language into the 
+   corresponding actual domain names in English. A user needs only the 
+   module for conversion of his or her preferred local language into 
+   English. Also, VIDN can be implemented at a central server host or a 
+   cluster of local server hosts. A central server with all the language 
+   modules of VIDN can provide the conversion service for all local 
+   languages, or a cluster of local server hosts can share the 
+   conversion service. In the latter case, each local server host with a 
+   language module or a set of language modules can provide the 
+   conversion service for the respective local language or set of local 
+   languages used in a certain region. 
+    
+   Because of its small size, VIDN can be easily embedded into 
+   applications software such as web browser, e-mail software, ftp 
+   system, and so on at the user host, or it can work as an add-on 
+   program to such software. In either case, the only requirement on the 
+   part of the user is to install VIDN or software embedding VIDN at the 
+   user host. Using virtual domain names in a local language in 
+   accordance with the principles of VIDN is very intuitive to those who 
+   speak the local language. The only requirement on the part of the 
+   entity whose server host provides Internet services to user hosts is 
+   to have an actual domain name in English into which a virtual domain 
+   name in a local language is neatly transliterated in accordance with 
+   the principles of VIDN, and to have a pre-assigned code kept at its 
+   server host for one-to-one matching of its actual domain name and a 
+   virtual domain name to be used by users. Most entities in regions 
+   where English is not widely spoken already have such domain names in 
+   English. Finally, there is nothing to change on the part of the DNS, 
+   since VIDN uses the current DNS as it is. 
+    
+   Taken together, the features of VIDN can meet all the requirement of 
+   internationalized domain names as described in Wenzel and Seng [2], 
+   with respect to compatibility and interoperability, 
+   internationalization, canonicalization, and operating issues. Given 
+   the fact that different methods toward internationalized domain names 
+  
+
+               Virtually Internationalized Domain Names  November 2000 
+ 
+   confuse users, as already observed in some regions where some of 
+   these methods have already been commercialized, e.g., Korea, it is 
+   important to find and implement the most effective solution to 
+   internationalized domain names as soon as possible. 
+    
+    
+   4.4. Testing results 
+    
+   A testing version of VIDN has been developed for Korean-English 
+   conversion as a web browser add-on program. The program contains all 
+   the features described in this document except the coding scheme. 
+   While the final version of the program is planned to include the 
+   coding scheme, the testing version lists all the domain names in 
+   English that correspond to a virtual domain name entered in Korean so 
+   that a user can choose one. The testing results of a sample of 
+   randomly selected domain names used in Korea show that the program 
+   can cover more than ninety percent of the sample. The results 
+   indicate that more than ninety percent of web sites in Korea can be 
+   accessed using virtual domain names in Korean without creating 
+   additional domain names in Korean. The remaining ten percent of 
+   domain names are mostly those that contain acronyms, abbreviations or 
+   initials. With improvement of its knowledge of transliteration, the 
+   final version of the program is expected to cover most domain names 
+   used in Korea. 
+    
+    
+   5. Security considerations 
+    
+   Because VIDN uses the DNS as it is, it inherits the same security 
+   considerations as the DNS. 
+    
+    
+   6. Intellectual property considerations 
+    
+   It is the intention of DualName, Inc. to submit the VIDN method and 
+   other elements of VIDN software to IETF for review, comment or 
+   standardization. 
+    
+   DualName has applied for one or more patents on the technology 
+   related to virtual domain name software and virtual email software. 
+   If a standard is adopted by IETF and any patents are issued to 
+   DualName with claims that are necessary for practicing the standard,  
+   DualName is prepared to make available, upon written request, a non-
+   exclusive license under fair, reasonable and non-discriminatory terms 
+   and condition, based on the principle of reciprocity, consistent with 
+   established practice. 
+    
+    
+   7. References 
+    
+   1  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+
+  
+
+               Virtually Internationalized Domain Names  November 2000 
+ 
+   2  Wenzel, Z. and Seng, J. (Editors), "Requirements of 
+     Internationalized Domain Names," draft-ietf-idn-requirements-
+     03.txt, August 2000 
+    
+    
+   8. Author's address 
+    
+   Sung Jae Shim 
+   DualName, Inc. 
+   3600 Wilshire Boulevard, Suite 1814 
+   Los Angeles, California 90010 
+   USA 
+   Email: shimsungjae@dualname.com 
+
diff --git a/doc/draft/draft-ietf-ipngwg-default-addr-select-00.txt b/doc/draft/draft-ietf-ipngwg-default-addr-select-00.txt
deleted file mode 100644
index f62bd8d5..00000000
--- a/doc/draft/draft-ietf-ipngwg-default-addr-select-00.txt
+++ /dev/null
@@ -1,587 +0,0 @@
-IPng Working Group                                               R. Draves 
-Internet Draft                                          Microsoft Research 
-Document: draft-ietf-ipngwg-default-addr-select-00.txt    October 22, 1999 
-Category: Standards Track                                               
- 
-                   Default Address Selection for IPv6 
-
-Status of this Memo 
-
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC 2026 [1]. 
-
-   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 describes two algorithms, for destination address 
-   ordering and for source address selection. The algorithms specify 
-   default behavior for all IPv6 implementations. They do not override 
-   choices made by applications or upper-layer protocols, nor do they 
-   preclude the development of more advanced mechanisms for address 
-   selection. The two algorithms share a common framework, including an 
-   optional mechanism for allowing administrators to provide policy 
-   that can override the default behavior. 
-
-1. Introduction 
-
-   The IPv6 addressing architecture [2] allows multiple unicast 
-   addresses to be assigned to interfaces. These addresses may have 
-   different reachability scopes (link-local, site-local, or global). 
-   These addresses may be "preferred" or "deprecated" [3]. In addition, 
-   multi-homing situations will result in more addresses per node. For 
-   example, a node may have multiple interfaces, some of them tunnels 
-   or virtual interfaces, or a site may have multiple ISP attachments. 
-
-   The end result is that IPv6 implementations will very often be faced 
-   with multiple possible source and destination addresses when 
-   initiating communication. It is desirable to have simple default 
-   algorithms, common across all implementations, for selecting source 
-  
-Draves            Standards Track - Expires May 2000                 1 
-
-Default Address Selection for IPv6                    October 22, 1999 
- 
- 
-   and destination addresses so that developers and administrators can 
-   reason about and predict the behavior of their systems. 
-
-   This document specifies source address selection and destination 
-   address selection separately, but using a common framework so that 
-   together the two algorithms yield useful results. The algorithms 
-   attempt to choose source and destination addresses of appropriate 
-   scope and configuration status (preferred or deprecated). 
-   Furthermore, this document suggests a preferred method, longest 
-   matching prefix, for choosing among otherwise equivalent addresses 
-   in the absence of better information. 
-
-   The framework also has policy hooks to allow administrative override 
-   of the default behavior. For example, using these hooks an 
-   administrator can specify a preferred source prefix for use with a 
-   destination prefix, or prefer destination addresses with one prefix 
-   over addresses with another prefix. These hooks give an 
-   administrator flexibility in dealing with some multi-homing and 
-   transition scenarios, but they are certainly not a panacea. 
-
-   The rules specified in this document MUST NOT be construed to 
-   override an application or upper-layer's explicit choice of 
-   destination or source address. 
-
-1.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 RFC-2119 [4]. 
-
-2. Framework 
-
-   Our framework for address selection derives from the most common 
-   implementation architecture, which separates the choice of 
-   destination address from the choice of source address. Consequently, 
-   the framework specifies two separate algorithms for these tasks. The 
-   algorithms are designed to work well together and they share a 
-   mechanism for administrative policy override. 
-
-   In this implementation architecture, applications use APIs [5] like 
-   getipnodebyname() and getaddrinfo() that return a list of addresses 
-   to the application. The application then passes a destination 
-   address to the IPv6 layer with connect() or sendto(). The 
-   application might just use the first address in the list, or it 
-   might loop over the list of addresses to find a working address. In 
-   any case, the IPv6 network layer is never in a position where it 
-   needs to choose a destination address from several alternatives. The 
-   application might also specify a source address with bind(), but 
-   often the source address is left unspecified. Therefore the IPv6 
-   layer does often choose a source address from several alternatives. 
-
-   As a consequence, we intend that implementations of 
-   getipnodebyname() and getaddrinfo() will use the destination address 
-  
-Draves            Standards Track - Expires May 2000                 2 
-
-Default Address Selection for IPv6                    October 22, 1999 
- 
- 
-   ordering algorithm specified here to sort the list of addresses that 
-   they return. Separately, the IPv6 network layer will use the source 
-   address selection algorithm when an application or upper-layer has 
-   not specified a source address. 
-
-   The algorithms use several criteria in making their decisions. The 
-   combined effect is to prefer destination/source address pairs for 
-   which the two addresses are of equal scope or type, prefer smaller 
-   scopes over larger scopes for the destination address, prefer non-
-   deprecated source addresses of sufficient scope to reach the 
-   destination, avoid the use of transitional addresses when native 
-   addresses are available, and all else being equal prefer address 
-   pairs having the longest possible common prefix. 
-
-   The framework optionally allows for the possibility of 
-   administrative configuration of policy that can override the default 
-   behavior of the algorithms. The policy override takes the form of a 
-   configurable table that provides precedence values and preferred 
-   source prefixes for destination prefixes. If an implementation is 
-   not configurable, or if an implementation has not been configured, 
-   then the default policy table specified in this document MUST be 
-   used. 
-
-2.1. Scope Comparisons 
-
-   Multicast destination addresses have a 4-bit scope field that 
-   controls the propagation of the multicast packet. The IPv6 
-   addressing architecture defines scope field values for node-local 
-   (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), 
-   and global (0xE) scopes. 
-
-   Application of the address selection algorithms in the presence of 
-   multicast destination addresses requires the comparison of a unicast 
-   address scope with a multicast address scope. We map unicast link-
-   local to multicast link-local, unicast site-local to multicast site-
-   local, and unicast global scope to multicast global scope. For 
-   example, unicast site-local is equal to multicast site-local, which 
-   is smaller than multicast organization-local, which is smaller than 
-   unicast global, which is equal to multicast global. 
-
-   We write Scope(A) to mean the scope of address A. For example, if A 
-   is a link-local unicast address and B is a site-local multicast 
-   address, then Scope(A) < Scope(B). 
-
-   This mapping implicitly conflates unicast site boundaries and 
-   multicast site boundaries. 
-
-2.2. IPv4-Compatible Addresses and Other Format Prefixes 
-
-   For the purposes of this document, IPv4-compatible addresses have 
-   global scope and "preferred" configuration status. 
-
-
-  
-Draves            Standards Track - Expires May 2000                 3 
-
-Default Address Selection for IPv6                    October 22, 1999 
- 
- 
-   Similarly, NSAP addresses, IPX addresses, or addresses with as-yet-
-   undefined format prefixes should be treated as having global scope 
-   and "preferred" configuration status. Later standards may supercede 
-   this treatment. 
-
-   The loopback address should be treated as having link-local scope 
-   and "preferred" configuration status. 
-
-2.3. Policy Table 
-
-   The policy table is a longest-matching-prefix lookup table, like a 
-   routing table. Given an address A, a lookup in the policy table 
-   produces three values: a precedence value Precedence(A), a 
-   classification or label Label(A), and a second label 
-   MatchSrcLabel(A). 
-
-   The precedence value Precedence(A) is used for sorting destination 
-   addresses. If Precedence(A) > Precedence(B), we say that address A 
-   has higher precedence than address B, meaning that our algorithm 
-   will prefer to sort destination address A before destination address 
-   B. 
-
-   The labels Label(A) and MatchSrcLabel(A) allow for policies that 
-   prefer a particular source address prefix for use with a destination 
-   address prefix. The algorithms prefer to use a source address S with 
-   a destination address D if Label(S) = MatchSrcLabel(D). 
-
-   IPv6 implementations SHOULD support configurable address selection 
-   via a mechanism at least as powerful as the policy tables defined 
-   here. If an implementation is not configurable or has not been 
-   configured, then it MUST operate according to the algorithms 
-   specified here in conjunction with the following default policy 
-   table: 
-
-                Prefix    Precedence Label MatchSrcLabel 
-                fe80::/10     40       1         1 
-                fec0::/10     30       2         2 
-                ::/0          20       3         3 
-                2002::/16     10       4         4 
-                ::/96         10       5         5 
- 
-   One effect of the default policy table is to prefer using native 
-   source addresses with native destination addresses, 6to4 source 
-   addresses with 6to4 destination addresses, and v4-compatible source 
-   addresses with v4-compatible destination addresses. Another effect 
-   of the default policy table is to prefer communication using native 
-   addresses to communication using either 6to4 or v4-compatible 
-   addresses, but not to express a preference for 6to4 addresses over 
-   v4-compatible addresses or vice-versa. 
-
-
-
-
-  
-Draves            Standards Track - Expires May 2000                 4 
-
-Default Address Selection for IPv6                    October 22, 1999 
- 
- 
-2.4. Candidate Source Addresses 
-
-   Both the destination address ordering algorithm and the source 
-   address selection algorithm use the concept of a "candidate set" of 
-   potential source addresses for a given destination address. 
-
-   We write CandidateSrc(A) to denote the candidate set for the address 
-   A. In some cases the destination address A may be qualified with a 
-   scope-id or other information that will constrain the candidate set. 
-   We write PreferSrc(A) to denote the subset of preferred (non-
-   deprecated) addresses in CandidateSrc(A)  We write MatchSrc(A) to 
-   denote the subset of addresses S in PreferSrc(A) for which Label(S) 
-   = MatchSrcLabel(A). 
-
-   The destination address ordering algorithm and the source address 
-   selection algorithm specify somewhat different definitions for 
-   CandidateSrc(A). This is because the two algorithms operate in 
-   different environments. The source address selection algorithm 
-   assumes that an outgoing interface for a packet has already been 
-   selected, while the destination address ordering algorithm does not 
-   assume that knowledge. Therefore the destination address ordering 
-   algorithm uses a broader or more-inclusive definition of 
-   CandidateSrc(A). 
-
-   In any case, anycast addresses, multicast addresses, and the 
-   unspecified address MUST NOT be included in a candidate set. 
-
-2.5. Common Prefix Length 
-
-   We define the common prefix length CommonPrefixLen(A, B) of two 
-   addresses A and B as the length of the longest prefix that the two 
-   addresses have in common. It ranges from 0 to 128. 
-
-   We define the maximum common prefix length MaxCommonPrefixLen(A, X) 
-   of an address A and a non-empty set of addresses X as the maximum of 
-   CommonPrefixLen(A, B) for addresses B in the set X. 
-
-3. Destination Address Ordering 
-
-   The destination address ordering algorithm takes a list of 
-   destination addresses and sorts the addresses to produce a new list. 
-   It is specified here in terms of the pair-wise comparison of 
-   addresses DA and DB, where DA appears before DB in the original 
-   list. 
-
-   The pair-wise comparison consists of four rules, which MUST be 
-   applied in order. If a rule determines a result, then the remaining 
-   rules are not relevant and MUST be ignored. Subsequent rules act as 
-   tie-breakers for earlier rules. 
-
-   Rule 1: If MatchSrc(DA) is non-empty and MatchSrc(DB) is empty, then 
-   sort DA before DB. Similarly, if MatchSrc(DA) is empty and 
-   MatchSrc(DB) is non-empty, then sort DB before DA. 
-  
-Draves            Standards Track - Expires May 2000                 5 
-
-Default Address Selection for IPv6                    October 22, 1999 
- 
- 
-   Rule 2: If Precedence(A) > Precedence(B), then sort DA before DB. 
-   Similarly, if Precedence(B) > Precedence(A), then sort DB before DA. 
-
-   Rule 3: If MatchSrc(DA) and MatchSrc(DB) are both non-empty. If 
-   MaxCommonPrefixLen(DA, MatchSrc(DA)) > MaxCommonPrefixLen(DB, 
-   MatchSrc(DB)), then sort DA before DB. Similarly, if 
-   MaxCommonPrefixLen(DB, MatchSrc(DB)) > MaxCommonPrefixLen(DA, 
-   MatchSrc(DA)), then sort DB before DA. 
-
-   Rule 4: Sort DA before DB. 
-
-   The third and fourth rules MAY be superceded if the implementation 
-   has other means of sorting destination addresses. For example, if 
-   the implementation somehow knows which destination addresses will 
-   result in the "best" communications performance. 
-
-3.1. Candidate Source Addresses 
-
-   For the purposes of destination address ordering, the candidate set 
-   of source addresses CandidateSrc(D) for a destination address D 
-   SHOULD contain all and only the unicast addresses assigned to 
-   interfaces that might be used to send to the destination D. 
-
-   For example, if the address D is a link-local unicast address that 
-   is qualified with a scope-id value specifying a particular 
-   interface, then CandidateSrc(D) SHOULD contain all and only the 
-   unicast addresses assigned to that interface. 
-
-   For example, if the address D is a global scope unicast address, 
-   then CandidateSrc(D) MAY contain every unicast address assigned to 
-   all interfaces. However if the implementation wishes to consult a 
-   routing table and determine a likely outgoing interface, then 
-   CandidateSrc(D) MAY contain only unicast addresses assigned to that 
-   outgoing interface. 
-
-4. Source Address Selection 
-
-   The source address selection algorithm chooses a source address for 
-   use with a destination address D. It is specified here in terms of 
-   the pair-wise comparison of addresses SA and SB. The pair-wise 
-   comparison can be used to select an address from the set 
-   CandidateSrc(D). 
-
-   The pair-wise comparison consists of six rules, which MUST be 
-   applied in order. If a rule chooses an address, then the remaining 
-   rules are not relevant and MUST be ignored. Subsequent rules act as 
-   tie-breakers for earlier rules. If the six rules fail to choose an 
-   address, some unspecified tie-breaker MUST be used. 
-
-   Rule 1: If SA is in MatchSrc(D) and SB is not, then choose SA. 
-   Similarly, if SB is in MatchSrc(D) and SA is not, then choose SB. 
-
-
-  
-Draves            Standards Track - Expires May 2000                 6 
-
-Default Address Selection for IPv6                    October 22, 1999 
- 
- 
-   Rule 2: If SA is equal to D, then choose SA. Similarly, if SB is 
-   equal to D, then choose SB. 
-
-   Rule 3a: If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then 
-   choose SB. Otherwise, if one of the source addresses is "preferred" 
-   and one of them is "deprecated", then choose the "preferred" 
-   address. Otherwise, choose SA. 
-
-   Rule 3b: Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < 
-   Scope(D), then choose SA. Otherwise, if one of the source addresses 
-   is "preferred" and one of them is "deprecated", then choose the 
-   "preferred" address. Otherwise, choose SB. 
-
-   Rule 4: The addresses SA and SB have the same scope. If one of the 
-   source addresses is "preferred" and one of them is "deprecated", an 
-   implementation MUST choose the one that is preferred. 
-
-   Rule 5: If Label(SA) = MatchSrcLabel(D) and Label(SB) <> 
-   MatchSrcLabel(D), then choose SA. Similarly, if Label(SA) <> 
-   MatchSrcLabel(D) and Label(SB) = MatchSrcLabel(D), then choose SB. 
-   (Note that this rule will apply only when both SA and SB are 
-   deprecated.) 
-
-   Rule 6: If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then 
-   choose SA. Similarly, if CommonPrefixLen(SB, D) > 
-   CommonPrefixLen(SA, D), then choose SB. 
-
-   The sixth rule MAY be superceded if the implementation has other 
-   means of choosing among source addresses. For example, if the 
-   implementation somehow knows which source address will result in the 
-   "best" communications performance. 
-
-4.1. Candidate Source Addresses 
-
-   For the purposes of source address selection, the candidate set of 
-   source addresses CandidateSrc(D) for a destination address D MUST 
-   contain all and only the unicast addresses assigned to the interface 
-   that will be used to send to the destination D. 
-
-5. Interactions with Routing 
-
-   All IPv6 nodes, including both hosts and routers, MUST conform to 
-   this specification. 
-
-   This specification of source address selection implies that routing 
-   (more precisely, selecting an outgoing interface on a node with 
-   multiple interfaces) is done before source address selection. 
-   However, implementations MAY use source address considerations as a 
-   tiebreaker when choosing among otherwise equivalent routes. 
-
-   For example, suppose a node has interfaces on two different links, 
-   with both links having a working default router. One of the 
-   interfaces has a preferred global address and the other interface 
-  
-Draves            Standards Track - Expires May 2000                 7 
-
-Default Address Selection for IPv6                    October 22, 1999 
- 
- 
-   only has a deprecated global address. When sending to a global 
-   destination address, if there's no routing reason to prefer one 
-   interface over the other, then an implementation MAY preferentially 
-   choose the outgoing interface that will allow it to use the 
-   preferred global source address. 
-
-6. Interactions with Mobility 
-
-   TBD 
-
-7. Implementation Considerations 
-
-   The destination address ordering algorithm needs information about 
-   potential source addresses. One possible implementation strategy is 
-   for getipnodebyname() and getaddrinfo() to call down to the IPv6 
-   network layer with a list of destination addresses, sort the list in 
-   the network layer with full current knowledge of available source 
-   addresses, and return the sorted list to getipnodebyname() or 
-   getaddrinfo(). This is simple but it introduces overhead. 
-
-   Another implementation strategy is to call down to the network layer 
-   to retrieve source address information and then sort the list of 
-   addresses directly in the context of getipnodebyname() or 
-   getaddrinfo(). To reduce overhead in this approach, the source 
-   address information SHOULD be cached, amortizing the overhead of 
-   retrieving it across multiple calls to getipnodebyname() and 
-   getaddrinfo(). If an implementation uses cached and possibly stale 
-   source address information in its implementation of destination 
-   address ordering, then it MUST ensure that the source address 
-   information is no more than one second out of date. 
-
-8. Security Considerations 
-
-   This document has no direct impact on Internet infrastructure 
-   security. 
-
-References 
- 
-   1  S. Bradner, "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-
-   2  R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 
-      RFC 2373, July 1998. 
-
-   3  S. Thompson, T. Narten, "IPv6 Stateless Address 
-      Autoconfiguration", RFC 2462 , December 1998. 
-
-   4  S. Bradner, "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997. 
-
-   5  R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket 
-      Interface Extensions for IPv6", RFC 2553, March 1999. 
-
-  
-Draves            Standards Track - Expires May 2000                 8 
-
-
-
-Acknowledgments 
-
-   The author would like to acknowledge the contributions of the IPng 
-   Working Group. 
-
-Author's Address 
-
-   Richard Draves 
-   Microsoft Research 
-   One Microsoft Way 
-   Redmond, WA 98052 
-   Email: richdr@microsoft.com 
-
-Revision History 
-
-Changes from draft-draves-ipngw-simple-srcaddr-01 
-
-   Added framework discussion. 
-
-   Added algorithm for destination address ordering. 
-
-   Added mechanism to allow the specification of administrative policy 
-   that can override the default behavior. 
-
-   Added section on routing interactions and TBD section on mobility 
-   interactions. 
-
-   Changed the candidate set definition for source address selection, 
-   so that only addresses assigned to the outgoing interface are 
-   allowed. 
-
-   Changed the loopback address treatment to link-local scope. 
-
-Changes from draft-draves-ipngw-simple-srcaddr-00 
-
-   Minor wording changes because DHCPv6 also supports "preferred" and 
-   "deprecated" addresses. 
-
-   Specified treatment of other format prefixes; now they are 
-   considered global scope, "preferred" addresses. 
-
-   Reiterated that anycast and multicast addresses are not allowed as 
-   source addresses. 
-
-   Recommended that source addresses be taken from the outgoing 
-   interface. Required this for multicast destinations. Added analogous 
-   requirements for link-local and site-local destinations. 
-
-   Specified treatment of the loopback address. 
-
-   Changed the second selection rule so that if both candidate source 
-   addresses have scope greater or equal than the destination address 
-   and only of them is preferred, the preferred address is chosen. 
-
-  
-Draves            Standards Track - Expires May 2000                 9 
-
-Default Address Selection for IPv6                    October 22, 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. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Draves            Standards Track - Expires May 2000                10 
-
diff --git a/doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt b/doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt
new file mode 100644
index 00000000..2047267e
--- /dev/null
+++ b/doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt
@@ -0,0 +1,695 @@
+
+
+IPng Working Group                                          Richard Draves 
+Internet Draft                                          Microsoft Research 
+Document: draft-ietf-ipngwg-default-addr-select-01.txt       July 14, 2000 
+Category: Standards Track                                                  
+ 
+                   Default Address Selection for IPv6 
+
+Status of this Memo 
+
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC 2026 [1]. 
+
+   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 describes two algorithms, for source address selection 
+   and for destination address selection. The algorithms specify 
+   default behavior for all IPv6 implementations. They do not override 
+   choices made by applications or upper-layer protocols, nor do they 
+   preclude the development of more advanced mechanisms for address 
+   selection. The two algorithms share a common framework, including an 
+   optional mechanism for allowing administrators to provide policy 
+   that can override the default behavior. In dual stack 
+   implementations, the framework allows the destination address 
+   selection algorithm to consider both IPv4 and IPv6 addresses - 
+   depending on the available source addresses, the algorithm might 
+   prefer IPv6 addresses over IPv4 addresses, or vice-versa. 
+
+1. Introduction 
+
+   The IPv6 addressing architecture [2] allows multiple unicast 
+   addresses to be assigned to interfaces. These addresses may have 
+   different reachability scopes (link-local, site-local, or global). 
+   These addresses may also be "preferred" or "deprecated" [3]. Privacy 
+   considerations have introduced the concepts of "public addresses" 
+   and "anonymous addresses" [4]. The mobility architecture introduces 
+   "home addresses" and "care-of addresses" [5]. In addition, multi-
+   homing situations will result in more addresses per node. For 
+  
+Draves          Standards Track - Expires January 2001               1 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+   example, a node may have multiple interfaces, some of them tunnels 
+   or virtual interfaces, or a site may have multiple ISP attachments 
+   with a global prefix per ISP. 
+
+   The end result is that IPv6 implementations will very often be faced 
+   with multiple possible source and destination addresses when 
+   initiating communication. It is desirable to have simple default 
+   algorithms, common across all implementations, for selecting source 
+   and destination addresses so that developers and administrators can 
+   reason about and predict the behavior of their systems. 
+
+   Furthermore, dual or hybrid stack implementations, which support 
+   both IPv6 and IPv4, will very often need to choose between IPv6 and 
+   IPv4 when initiating communication. For example, when DNS name 
+   resolution yields both IPv6 and IPv4 addresses and the network 
+   protocol stack has available both IPv6 and IPv4 source addresses. In 
+   such cases, a simple policy to always prefer IPv6 or always prefer 
+   IPv4 can produce poor behavior. As one example, suppose a DNS name 
+   resolves to a global IPv6 address and a global IPv4 address. If the 
+   node has assigned a global IPv6 address and a 169.254/16 "autonet" 
+   IPv4 address, then IPv6 is the best choice for communication. But if 
+   the node has assigned only a link-local IPv6 address and a global 
+   IPv4 address, then IPv4 is the best choice for communication. The 
+   destination address selection algorithm solves this with a unified 
+   procedure for choosing among both IPv6 and IPv4 addresses. 
+
+   This document specifies source address selection and destination 
+   address selection separately, but using a common framework so that 
+   together the two algorithms yield useful results. The algorithms 
+   attempt to choose source and destination addresses of appropriate 
+   scope and configuration status (preferred or deprecated). 
+   Furthermore, this document suggests a preferred method, longest 
+   matching prefix, for choosing among otherwise equivalent addresses 
+   in the absence of better information. 
+
+   The framework also has policy hooks to allow administrative override 
+   of the default behavior. For example, using these hooks an 
+   administrator can specify a preferred source prefix for use with a 
+   destination prefix, or prefer destination addresses with one prefix 
+   over addresses with another prefix. These hooks give an 
+   administrator flexibility in dealing with some multi-homing and 
+   transition scenarios, but they are certainly not a panacea. 
+
+   The rules specified in this document MUST NOT be construed to 
+   override an application or upper-layer's explicit choice of 
+   destination or source address. 
+
+1.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 RFC-2119 [6]. 
+
+  
+Draves            Standards Track - Expires May 2000                 2 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+2. Framework 
+
+   Our framework for address selection derives from the most common 
+   implementation architecture, which separates the choice of 
+   destination address from the choice of source address. Consequently, 
+   the framework specifies two separate algorithms for these tasks. The 
+   algorithms are designed to work well together and they share a 
+   mechanism for administrative policy override. 
+
+   In this implementation architecture, applications use APIs [7] like 
+   getaddrinfo() and getipnodebyname() that return a list of addresses 
+   to the application. This list might contain both IPv6 and IPv4 
+   addresses (sometimes represented as IPv4-mapped addresses). The 
+   application then passes a destination address to the network stack 
+   with connect() or sendto(). The application might use only the first 
+   address in the list, or it might loop over the list of addresses to 
+   find a working address. In any case, the network layer is never in a 
+   situation where it needs to choose a destination address from 
+   several alternatives. The application might also specify a source 
+   address with bind(), but often the source address is left 
+   unspecified. Therefore the network layer does often choose a source 
+   address from several alternatives. 
+
+   As a consequence, we intend that implementations of getaddrinfo() 
+   and getipnodebyname() will use the destination address selection 
+   algorithm specified here to sort the list of IPv6 and IPv4 addresses 
+   that they return. Separately, the IPv6 network layer will use the 
+   source address selection algorithm when an application or upper-
+   layer has not specified a source address. Application of this 
+   framework to source address selection in an IPv4 network layer may 
+   be possible but this is not explored further here. 
+
+   The algorithms use several criteria in making their decisions. The 
+   combined effect is to prefer destination/source address pairs for 
+   which the two addresses are of equal scope or type, prefer smaller 
+   scopes over larger scopes for the destination address, prefer non-
+   deprecated source addresses of sufficient scope to reach the 
+   destination, avoid the use of transitional addresses when native 
+   addresses are available, and all else being equal prefer address 
+   pairs having the longest possible common prefix. For source address 
+   selection, an anonymous address [4] is preferred over its 
+   corresponding public address. In mobile situations [5], home 
+   addresses are preferred over care-of addresses. 
+
+   The framework optionally allows for the possibility of 
+   administrative configuration of policy that can override the default 
+   behavior of the algorithms. The policy override takes the form of a 
+   configurable table that provides precedence values and preferred 
+   source prefixes for destination prefixes. If an implementation is 
+   not configurable, or if an implementation has not been configured, 
+   then the default policy table specified in this document SHOULD be 
+   used. 
+
+  
+Draves            Standards Track - Expires May 2000                 3 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+2.1. Scope Comparisons 
+
+   Multicast destination addresses have a 4-bit scope field that 
+   controls the propagation of the multicast packet. The IPv6 
+   addressing architecture defines scope field values for node-local 
+   (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), 
+   and global (0xE) scopes. 
+
+   Use of the source address selection algorithm in the presence of 
+   multicast destination addresses requires the comparison of a unicast 
+   address scope with a multicast address scope. We map unicast link-
+   local to multicast link-local, unicast site-local to multicast site-
+   local, and unicast global scope to multicast global scope. For 
+   example, unicast site-local is equal to multicast site-local, which 
+   is smaller than multicast organization-local, which is smaller than 
+   unicast global, which is equal to multicast global. 
+
+   We write Scope(A) to mean the scope of address A. For example, if A 
+   is a link-local unicast address and B is a site-local multicast 
+   address, then Scope(A) < Scope(B). 
+
+   This mapping implicitly conflates unicast site boundaries and 
+   multicast site boundaries. 
+
+2.2. IPv4-Compatible Addresses and Other Format Prefixes 
+
+   For the purposes of this document, IPv4-compatible addresses have 
+   global scope and "preferred" configuration status. 
+
+   Similarly, NSAP addresses, IPX addresses, or addresses with as-yet-
+   undefined format prefixes should be treated as having global scope 
+   and "preferred" configuration status. Later standards may supercede 
+   this treatment. 
+
+   The loopback address should be treated as having link-local scope 
+   and "preferred" configuration status. 
+
+2.3. IPv4 Addresses and IPv4-Mapped Addresses 
+
+   The destination address selection algorithm operates on both IPv6 
+   and IPv4 addresses. For this purpose, IPv4 addresses should be 
+   represented as IPv4-mapped addresses. For example, to lookup the 
+   precedence or other attributes of an IPv4 address in the policy 
+   table, lookup the corresponding IPv4-mapped IPv6 address. 
+
+2.4. Policy Table 
+
+   The policy table is a longest-matching-prefix lookup table, much 
+   like a routing table. Given an address A, a lookup in the policy 
+   table produces three values: a precedence value Precedence(A), a 
+   classification or label Label(A), and a second label 
+   MatchSrcLabel(A). 
+
+  
+Draves            Standards Track - Expires May 2000                 4 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+   The precedence value Precedence(A) is used for sorting destination 
+   addresses. If Precedence(A) > Precedence(B), we say that address A 
+   has higher precedence than address B, meaning that our algorithm 
+   will prefer to sort destination address A before destination address 
+   B. 
+
+   The labels Label(A) and MatchSrcLabel(A) allow for policies that 
+   prefer a particular source address prefix for use with a destination 
+   address prefix. The algorithms prefer to use a source address S with 
+   a destination address D if Label(S) = MatchSrcLabel(D). 
+
+   IPv6 implementations SHOULD support configurable address selection 
+   via a mechanism at least as powerful as the policy tables defined 
+   here. If an implementation is not configurable or has not been 
+   configured, then it SHOULD operate according to the algorithms 
+   specified here in conjunction with the following default policy 
+   table: 
+
+          Prefix                 Precedence Label MatchSrcLabel 
+          ::1/128                       100     1             1 
+          fe80::/10                      90     2             2 
+          fec0::/10                      80     3             3 
+          ::/0                           70     4             4 
+          2002::/16                      60     5             5 
+          ::/96                          50     6             6 
+          ::ffff:169.254.0.0/112         30     7             7 
+          ::ffff:10.0.0.0/104            20     8             8 
+          ::ffff:172.16.0.0/108          20     9             9 
+          ::ffff:192.168.0.0/112         20    10            10 
+          ::ffff:0:0/96                  10    11            11 
+ 
+   One effect of the default policy table is to prefer using native 
+   source addresses with native destination addresses, 6to4 source 
+   addresses with 6to4 destination addresses, and v4-compatible source 
+   addresses with v4-compatible destination addresses. Another effect 
+   of the default policy table is to prefer communication using IPv6 
+   addresses to communication using IPv4 addresses, if matching source 
+   addresses are available. 
+
+   Policy table entries for scoped address prefixes MAY be qualified 
+   with an optional scope-id. If so, a prefix table entry only matches 
+   against an address during a lookup if the scope-id also matches the 
+   address's scope-id. 
+
+2.5. Common Prefix Length 
+
+   We define the common prefix length CommonPrefixLen(A, B) of two 
+   addresses A and B as the length of the longest prefix (looking at 
+   the most significant, or leftmost, bits) that the two addresses have 
+   in common. It ranges from 0 to 128. 
+
+
+
+  
+Draves            Standards Track - Expires May 2000                 5 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+3. Candidate Source Addresses 
+
+   The source address selection algorithm uses the concept of a 
+   "candidate set" of potential source addresses for a given 
+   destination address. We write CandidateSource(A) to denote the 
+   candidate set for the address A. 
+
+   It is RECOMMENDED that the candidate source addresses be the set of 
+   unicast addresses assigned to the interface that will be used to 
+   send to the destination. (The "outgoing" interface.) On routers, the 
+   candidate set MAY include unicast addresses assigned to any 
+   interface that could forward the destination address to the outgoing 
+   interface. 
+
+   In some cases the destination address may be qualified with a scope-
+   id or other information that will constrain the candidate set. 
+
+   For multicast and link-local destination addresses, the set of 
+   candidate source addresses MUST only include addresses assigned to 
+   interfaces belonging to the same link as the outgoing interface. 
+
+   For site-local destination addresses, the set of candidate source 
+   addresses MUST only include addresses assigned to interfaces 
+   belonging to the same site as the outgoing interface. 
+
+   In any case, anycast addresses, multicast addresses, and the 
+   unspecified address MUST NOT be included in a candidate set. 
+
+4. Source Address Selection 
+
+   The source address selection algorithm chooses a source address for 
+   use with a destination address D. It is specified here in terms of 
+   the pair-wise comparison of addresses SA and SB. The pair-wise 
+   comparison can be used to select an address from the set 
+   CandidateSource(D). 
+
+   The pair-wise comparison consists of eight rules, which MUST be 
+   applied in order. If a rule chooses an address, then the remaining 
+   rules are not relevant and MUST be ignored. Subsequent rules act as 
+   tie-breakers for earlier rules. If the eight rules fail to choose an 
+   address, some unspecified tie-breaker must be used. 
+
+   Rule 1: Prefer same address. 
+   If SA = D, then choose SA. Similarly, if SB = D, then choose SB. 
+
+   Rule 2: Prefer matching label. 
+   If Label(SA) = MatchSrcLabel(D) and Label(SB) <> MatchSrcLabel(D), 
+   then choose SA. Similarly, if Label(SB) = MatchSrcLabel(D) and 
+   Label(SA) <> MatchSrcLabel(D), then choose SB. 
+
+
+
+
+  
+Draves            Standards Track - Expires May 2000                 6 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+   Rule 3: Prefer appropriate scope. 
+   If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB. 
+   Otherwise, if one of the source addresses is "preferred" and one of 
+   them is "deprecated", then choose the "preferred" address. 
+   Otherwise, choose SA. 
+   Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < Scope(D), then 
+   choose SA. Otherwise, if one of the source addresses is "preferred" 
+   and one of them is "deprecated", then choose the "preferred" 
+   address. Otherwise, choose SB. 
+
+   Rule 4: Avoid deprecated addresses. 
+   The addresses SA and SB have the same scope. If one of the source 
+   addresses is "preferred" and one of them is "deprecated", an 
+   implementation MUST choose the one that is preferred. 
+
+   Rule 5: Prefer home addresses. 
+   If SA is a home address and SB is a care-of address, then prefer SA. 
+   Similarly, if SB is a home address and SA is a care-of address, then 
+   prefer SB. 
+   An implementation MAY support a per-connection configuration 
+   mechanism (for example, a socket option) to reverse the sense of 
+   this preference and prefer care-of addresses over home addresses. 
+
+   Rule 6: Prefer outgoing interface. 
+   If SA is assigned to the interface that will be used to send to D 
+   and SB is assigned to a different interface, then prefer SA. 
+   Similarly, if SB is assigned to the interface that will be used to 
+   send to D and SA is assigned to a different interface, then prefer 
+   SB. 
+
+   Rule 7: Prefer anonymous addresses. 
+   If SA is an anonymous address and SB is its corresponding public 
+   address, then prefer SA. Similarly, if SB is an anonymous address 
+   and SA is its corresponding public address, then prefer SB. 
+   An implementation MAY support a per-connection configuration 
+   mechanism (for example, a socket option) to reverse the sense of 
+   this preference and prefer public addresses over anonymous 
+   addresses. 
+
+   Rule 8: Use longest matching prefix. 
+   If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. 
+   Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 
+   choose SB. 
+
+   Rule 8 MAY be superceded if the implementation has other means of 
+   choosing among source addresses. For example, if the implementation 
+   somehow knows which source address will result in the "best" 
+   communications performance. 
+
+5. Destination Address Selection 
+
+   The destination address selection algorithm takes a list of 
+   destination addresses and sorts the addresses to produce a new list. 
+  
+Draves            Standards Track - Expires May 2000                 7 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+   It is specified here in terms of the pair-wise comparison of 
+   addresses DA and DB, where DA appears before DB in the original 
+   list. 
+
+   The destination address selection algorithm uses the source address 
+   selection algorithm as a subroutine. We write Source(D) to indicate 
+   the selected source address for a destination D. 
+
+   The pair-wise comparison of destination addresses consists of four 
+   rules, which MUST be applied in order. If a rule determines a 
+   result, then the remaining rules are not relevant and MUST be 
+   ignored. Subsequent rules act as tie-breakers for earlier rules. 
+
+   Rule 1: Prefer destinations with a matching source. 
+   If Label(Source(DA)) = MatchSrcLabel(DA) and Label(Source(DB)) <> 
+   MatchSrcLabel(DB), then sort DA before DB. Similarly, if 
+   Label(Source(DB)) = MatchSrcLabel(DB) and Label(Source(DA)) <> 
+   MatchSrcLabel(DA), then sort DB before DA. 
+
+   Rule 2: Prefer higher precedence. 
+   If Precedence(DA) > Precedence(DB), then sort DA before DB. 
+   Similarly, if Precedence(DB) > Precedence(DA), then sort DB before 
+   DA. 
+
+   Rule 3: Use longest matching prefix. 
+   Applies only if Label(Source(DA)) = MatchSrcLabel(DA) and 
+   Label(Source(DB)) = MatchSrcLabel(DB). 
+   If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, 
+   Source(DB)), then sort DA before DB. Similarly, if 
+   CommonPrefixLen(DB, Source(DB)) > CommonPrefixLen(DA, Source(DA)), 
+   then sort DB before DA. 
+
+   Rule 4: Otherwise, leave the order unchanged. 
+   Sort DA before DB. 
+
+   The third and fourth rules MAY be superceded if the implementation 
+   has other means of sorting destination addresses. For example, if 
+   the implementation somehow knows which destination addresses will 
+   result in the "best" communications performance. 
+
+6. Interactions with Routing 
+
+   All IPv6 nodes, including both hosts and routers, SHOULD conform to 
+   this specification. 
+
+   This specification of source address selection assumes that routing 
+   (more precisely, selecting an outgoing interface on a node with 
+   multiple interfaces) is done before source address selection. 
+   However, implementations MAY use source address considerations as a 
+   tiebreaker when choosing among otherwise equivalent routes. 
+
+   For example, suppose a node has interfaces on two different links, 
+   with both links having a working default router. Both of the 
+  
+Draves            Standards Track - Expires May 2000                 8 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+   interfaces have preferred global addresses. When sending to a global 
+   destination address, if there's no routing reason to prefer one 
+   interface over the other, then an implementation MAY preferentially 
+   choose the outgoing interface that will allow it to use the source 
+   address that shares a longer common prefix with the destination. 
+
+7. Implementation Considerations 
+
+   The destination address selection algorithm needs information about 
+   potential source addresses. One possible implementation strategy is 
+   for getipnodebyname() and getaddrinfo() to call down to the IPv6 
+   network layer with a list of destination addresses, sort the list in 
+   the network layer with full current knowledge of available source 
+   addresses, and return the sorted list to getipnodebyname() or 
+   getaddrinfo(). This is simple and gives the best results but it 
+   introduces the overhead of another system call. One way to reduce 
+   this overhead is to cache the sorted address list in the resolver, 
+   so that subsequent calls for the same name do not need to resort the 
+   list. 
+
+   Another implementation strategy is to call down to the network layer 
+   to retrieve source address information and then sort the list of 
+   addresses directly in the context of getipnodebyname() or 
+   getaddrinfo(). To reduce overhead in this approach, the source 
+   address information can be cached, amortizing the overhead of 
+   retrieving it across multiple calls to getipnodebyname() and 
+   getaddrinfo(). 
+
+   In any case, if the implementation uses cached and possibly stale 
+   information in its implementation of destination address selection, 
+   or if the ordering of a cached list of destination addresses is 
+   possibly stale, then it MUST ensure that the destination address 
+   ordering returned to the application is no more than one second out 
+   of date. For example, an implementation might make a system call to 
+   check if any routing table entries or source address assignments 
+   that might affect these algorithms have changed. 
+
+8. Security Considerations 
+
+   This document has no direct impact on Internet infrastructure 
+   security. 
+
+References 
+ 
+   1  S. Bradner, "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+
+   2  R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 
+      RFC 2373, July 1998. 
+
+   3  S. Thompson, T. Narten, "IPv6 Stateless Address 
+      Autoconfiguration", RFC 2462 , December 1998. 
+ 
+  
+Draves            Standards Track - Expires May 2000                 9 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+ 
+   4  T. Narten, R. Draves, "Privacy Extensions for Stateless Address 
+      Autoconfiguration in IPv6", draft-ietf-ipngwg-addrconf-privacy-
+      01.txt, July 2000. 
+
+   5  D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-
+      mobileip-ipv6-12.txt, April 2000. 
+
+   6  S. Bradner, "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+
+   7  R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket 
+      Interface Extensions for IPv6", RFC 2553, March 1999. 
+
+Acknowledgments 
+
+   The author would like to acknowledge the contributions of the IPng 
+   Working Group. 
+
+Author's Address 
+
+   Richard Draves 
+   Microsoft Research 
+   One Microsoft Way 
+   Redmond, WA 98052 
+   Phone: 1-425-936-2268 
+   Email: richdr@microsoft.com 
+
+Revision History 
+
+Changes from draft-ietf-ipngwg-default-addr-select-00 
+
+   Changed the candidate set definition so that the strong host model 
+   is recommended but not required. Added a rule to source address 
+   selection to prefer addresses assigned to the outgoing interface. 
+
+   Simplified the destination address selection algorithm, by having it 
+   use source address selection as a subroutine. 
+
+   Added a rule to source address selection to handle anonymous/public 
+   addresses. 
+
+   Added a rule to source address selection to handle home/care-of 
+   addresses. 
+
+   Changed to allow destination address selection to sort both IPv6 and 
+   IPv4 addresses. Added entries in the default policy table for IPv4-
+   mapped addresses. 
+
+   Changed default precedences, so v4-compatible addresses have lower 
+   precedence than 6to4 addresses. 
+
+
+  
+Draves            Standards Track - Expires May 2000                10 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+Changes from draft-draves-ipngwg-simple-srcaddr-01 
+
+   Added framework discussion. 
+
+   Added algorithm for destination address ordering. 
+
+   Added mechanism to allow the specification of administrative policy 
+   that can override the default behavior. 
+
+   Added section on routing interactions and TBD section on mobility 
+   interactions. 
+
+   Changed the candidate set definition for source address selection, 
+   so that only addresses assigned to the outgoing interface are 
+   allowed. 
+
+   Changed the loopback address treatment to link-local scope. 
+
+Changes from draft-draves-ipngwg-simple-srcaddr-00 
+
+   Minor wording changes because DHCPv6 also supports "preferred" and 
+   "deprecated" addresses. 
+
+   Specified treatment of other format prefixes; now they are 
+   considered global scope, "preferred" addresses. 
+
+   Reiterated that anycast and multicast addresses are not allowed as 
+   source addresses. 
+
+   Recommended that source addresses be taken from the outgoing 
+   interface. Required this for multicast destinations. Added analogous 
+   requirements for link-local and site-local destinations. 
+
+   Specified treatment of the loopback address. 
+
+   Changed the second selection rule so that if both candidate source 
+   addresses have scope greater or equal than the destination address 
+   and only of them is preferred, the preferred address is chosen. 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Draves            Standards Track - Expires May 2000                11 
+Default Address Selection for IPv6                       July 14, 2000 
+ 
+ 
+   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. 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Draves            Standards Track - Expires May 2000                12 
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-ipngwg-prefix-rr-disc-00.txt b/doc/draft/draft-ietf-ipngwg-prefix-rr-disc-00.txt
new file mode 100644
index 00000000..f0cd1061
--- /dev/null
+++ b/doc/draft/draft-ietf-ipngwg-prefix-rr-disc-00.txt
@@ -0,0 +1,224 @@
+
+IPng Working Group                                         Matt Crawford
+Internet Draft                                                  Fermilab
+                                                       November 17, 2000
+
+      Discovery of Resource Records Designating IPv6 Address prefixes
+                 <draft-ietf-ipngwg-prefix-rr-disc-00.txt>
+
+
+
+Status of this Memo
+
+    This document is an Internet-Draft and is in full conformance with
+    all provisions of Section 10 of RFC 2026.  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
+
+    The A6 resource record type [A6] was introduced to store IPv6
+    addresses in a manner which facilitates prefix changes and
+    assignment of addresses from multiple prefixes.  In order to allow
+    use of dynamic DNS updates while still respecting whatever prefix
+    hierarchy may be in use in a site's "reverse" DNS zone, a method is
+    needed for discovering the name(s) of the A6 record(s) which specify
+    an address prefix.
+
+    This memo specifies such a method of prefix name discovery.
+
+
+1.  Introduction
+
+    The A6 resource record type [A6] was introduced to store IPv6
+    addresses in a manner which facilitates prefix changes and
+    assignment of addresses from multiple prefixes.  In order to allow
+    use of dynamic DNS updates while still respecting whatever prefix
+    hierarchy may be in use in a site's "reverse" DNS zone, a method is
+    needed for discovering the name(s) of the A6 record(s) which specify
+    an address prefix.
+
+
+
+Expires May 22, 2001        Crawford et al.                     [Page 1]
+
+Internet Draft                  IPv6 DNS               November 17, 2000
+
+
+    This memo specifies such a method.  No new protocols or DNS record
+    types are involved -- only a convention for storing the required
+    information and a procedure for finding it.
+
+    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.  Prefix Name Storage
+
+    Recall from [A6] that address-to-name mapping information may be
+    stored in a subzone of IP6.ARPA, or in another zone reached by a
+    chain of one or more DNAME records.  Nodenames are stored in PTR
+    records in such a zone.  Extending that custom, we specify that
+    prefixes are to be named in PTR records in the same way.  For a
+    prefix "P" of length "L" bits there should be a PTR whose RDATA
+    contains the owner name of an A6 record suitable for designating the
+    prefix P/L, and this PTR record is to be stored so that it will be
+    returned by a DNS query for the QNAME \[P/L].IP6.ARPA (possibly
+    after resolving intervening DNAMEs [DNAME]).
+
+    Since the purpose of prefix name discovery is to facilitate dynamic
+    registration by hosts of their IPv6 addresses in DNS, only the names
+    of "longest" prefixes need to be discoverable.  Accordingly, this
+    example will show just a prefix which is not subnetted further.
+
+    Building on the example from [A6], section 5.2.3, the addition of
+    the required PTR record is shown below.
+
+           $ORIGIN X.EXAMPLE.
+           N            A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
+           SUBNET-1.IP6 A6 48 0:0:0:1::  IP6
+                        PTR   SUBNET-1.IP6        ; added record
+           IP6          A6 48 0::0       SUBSCRIBER-X.IP6.A.NET.
+           IP6          A6 48 0::0       SUBSCRIBER-X.IP6.B.NET.
+           $ORIGIN IP6
+           \[x0001/16]                   DNAME   SUBNET-1
+           \[x123456789ABCDEF0].SUBNET-1 PTR     N.X.EXAMPLE.
+
+    Notice that the owner and RDATA are the same.  This is a consequence
+    of a somewhat arbitrary choice.  The new record could equally well
+    have been
+
+         \[x0001/16].IP6.X.EXAMPLE.  PTR   SUBNET-1.IP6.X.EXAMPLE.
+
+
+    It cannot be determined by inspecting an A6 DNS record whether that
+
+
+
+Expires May 22, 2001        Crawford et al.                     [Page 2]
+
+Internet Draft                  IPv6 DNS               November 17, 2000
+
+
+    record is meant to specify all the trailing bits of a 128-bit IPv6
+    address or merely a prefix.  Inclusion of the trailing bits does not
+    preclude its being pointed to as a prefix by some other A6 record.
+    Nevertheless, a human or automated zone maintainer will generally
+    know the intended purpose of each A6 record and which one should be
+    named in a PTR for prefix name discovery.
+
+
+3.  Prefix Name Discovery
+
+    If a process wishing to do prefix name discovery has the prefix
+    itself available (as opposed to a full address of which an unknown
+    initial portion is the prefix), the prefix can be looked up
+    directly.  Otherwise, two heuristics are available.
+
+    First, it is possible that looking up a PTR record based on the full
+    IPv6 address, as would be done for ordinary address-to-name mapping,
+    will yield a PTR record containing a hostname.  That hostname will
+    then be the owner of an A6 record.  If its prefix length field is
+    non-zero, its prefix name field will contain the desired name.
+
+    Otherwise, looking up a PTR record will fail, returning an
+    authoritative name error no no data of the requested type.  There
+    will be a set of DNAME records in the answer section of the reply.
+    The last of these DNAMEs will indicate where to start looking for
+    the required PTR record.  First its target should be tried, then its
+    owner.  An especially persistent implementation can then prepend one
+    bit at a time from the portion of the IPv6 address not mapped by the
+    DNAME records to the target name, looking for a PTR record which was
+    not at a DNAME cut point of its own.  An authoritative name error is
+    a stopping signal for this search.
+
+
+4.  Security Considerations
+
+    No security concerns are raised by this specification beyond those
+    which apply to all uses of the DNS.
+
+
+5.  References
+
+
+    [A6] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6
+        Address Aggregation and Renumbering", RFC 2874, July 2000.
+
+    [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
+        Requirement Levels," RFC 2119.
+
+
+
+
+Expires May 22, 2001        Crawford et al.                     [Page 3]
+
+Internet Draft                  IPv6 DNS               November 17, 2000
+
+
+    [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
+        August 1999.
+
+6.  Authors' Addresses
+
+    Matt Crawford
+    Fermilab
+    MS 368
+    PO Box 500
+    Batavia, IL 60510
+    USA
+
+    +1 630 840-3461
+    crawdad@fnal.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 22, 2001        Crawford et al.                     [Page 4]
+
diff --git a/doc/draft/draft-klensin-dns-role-00.txt b/doc/draft/draft-klensin-dns-role-00.txt
new file mode 100644
index 00000000..d708ec5f
--- /dev/null
+++ b/doc/draft/draft-klensin-dns-role-00.txt
@@ -0,0 +1,571 @@
+INTERNET-DRAFT                                John C. Klensin

+November 10, 2000

+Expires May 2001

+

+

+                  Role of the Domain Name System

+                 draft-klensin-dns-role-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."

+

+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 document represents a summary of the personal opinions of the

+author on the subject covered and is not intended to evolve into a

+standard of any kind.

+

+Copyright Notice

+

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

+

+

+

+0. Abstract

+

+The original function and purpose of the DNS is reviewed, and

+contrasted with some of the functions into which it is being forced

+today 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.

+

+

+1. History

+

+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 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 we got to

+where we are today, but they probably don't, of themselves,

+invalidate the inferences and conclusions.

+

+1.1  Context for DNS development

+

+During the entire 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, 811, 952].  This table was just a list in an

+agreed-upon format; sites were expected to frequently obtain copies

+of, and install, new versions.  The host tables themselves were

+introduced to

+

+  * 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.

+

+  * 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.

+

+  * Some hosts (so-called "multihomed" ones) needed multiple

+  addresses to reflect different types of connectivity and topology.

+  Again, the names were very useful for avoiding the requirement that

+  would otherwise exist for users and other hosts to track these

+  multiple host numbers and addresses. 

+Toward the end of that long (in network time) period, the community

+concluded that the host table model did not scale adequately and that

+it would not adequately support new service variations.  A working

+group was created, and the DNS was the result of that effort.  The

+role of the DNS was to preserve the capabilities of the host table

+arrangements (especially unique, unambiguous, host names), provide

+for addition of additional services (e.g., the special record types

+for electronic mail routing which rather quickly followed

+introduction of the DNS), and to do so on the base of a robust,

+hierarchical, distributed, name lookup system.  That system 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

+

+The DNS was designed primarily 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 accomodate new data types and structures through

+the addition of new record types to the initial "INternet" class.

+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-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 accomodate any binary representation, DNS

+names as used are historically not [even] ASCII, but a very

+restricted subset of it, a subset that derives primarily 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. X.9, X.29).

+

+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 large ratio of names representing physical

+hosts to total names.  There are domains that follow this model: many

+university and corporate domains use fairly deep hierarchies, as do a

+few country code TLDs (".US" is an excellent example).  However, the

+RIPE hostcount list is now showing a count of SOA records that is

+approaching (and may have passed) the number of distinct hosts.

+While recent experience 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 huge, flat,

+structure under ".COM"), 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, with the sole

+exception (at least in the "IN" class) of one field of the SOA

+record, electronic mail addresses in the Internet have preserved the

+original, pre-DNS, "user at location" conceptual format rather than a

+flatter one.  Location, in that instance, is a reference to a host.

+

+Both the DNS architecture itself and the two-level provisions for

+email and similar functions (e.g., see the finger protocol), also

+anticipated a relatively high ratio of users to actual hosts.  It was

+never clear that the DNS was intended to, 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.

+

+Like the host table before it, the DNS has provided criticial

+uniqueness for names and universal accessibility to them as part of

+overall "single internet" and "end to end" models (cf [RFC2826]).

+However, there are many signs that, as new uses evolve and original

+assmumptions are abused, the system is being stretched to, or beyond,

+its practical limits.

+ 

+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 design decision to use "A record" domain names, 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 who have been anxious

+to "sell" additional names).  And, of course, the perception that one

+needs a top-level domain per product, rather than a (usually

+organizational) collection of network resources has led to a rapid

+acceleration in the number of names being registered, a phenonenum

+that has clearly benefited registrars charging on a per-name basis,

+"cybersquatters", and others in the business of "selling" names, but

+has not obviously benefitted the Internet as a whole.

+

+The 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 --possibly including significant changes to the underlying

+legislation and conventions-- and 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 but by depending largely on main force, 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 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

+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, 

+While additional implications are still being discovered and

+seriously evaluated, it appears, not surprisingly, that rewriting DNS

+names in the middle of the network, or trying to give them different

+values or interpretations depending on the topological location of

+the user trying to resolve the name interferes with end-to-end

+applications in the general case.  These problems occur even if the

+rewriting machinery is accompanied by additional workarounds for

+particular applications: security associations and applications that

+need to identify "the same host" as the applications for which these

+tools have been designed often run into one problem or another.

+

+

+1.4 A pessimistic history of the evolution of Internet applications

+protocols.

+

+At the applications level, few of the protocols in active, widespread

+use on the Internet reflect the 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 permit very rapid dissemination (i.e., they

+fill a vacuum, even if one that no one previously knew existed).

+But, once the vacuum is filled, the installed base 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.  

+

+2. Signs of DNS overloading

+

+Parts of the historical discussion above identify areas in which it

+is becoming clear that the DNS is becoming overloaded (semantically

+if not in the mechanical ability to resolve names).  While we seem to

+still be well within the "just about good enough" range -- current

+mechanisms and proposals to deal with these problems are all focused

+on patching or working around limitations within the DNS rather than

+dramatic rethinking -- the number of these issues that are arising

+at the same time may argue for rethinging mechanisms and

+relationships, not just more patches and kludges.  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 doesn't deal

+especially well with high-multiple names per host (needed for 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 names (labels) that

+are over 63 octets long.  This requirement will undoubtedly increase

+over time; while there are workarounds to accomodate 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 differentiators 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 may claim trademark rights to do

+so, even though conflict or confusion would not occcur with

+traditional trademarks.

+

+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.  Arguably, the name resolution mechanism should

+provide information about multiple sites that can provide information

+associated with the same name and sufficient attributes associated

+with each of those sites to permit applications to make sensible

+choices, or should accept client-site attributes and utilize them in

+the search process.  

+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 and queries may be slightly ambiguous or

+fuzzy.  The DNS can accomodate only one set of (quite rigid) matching

+rules.  Current proposals to permit different rules in different

+localities help to identify the problem, but, if applied directly to

+the DNS either don't provide the level of flexibility that would be

+desirable or tend to isolate different parts of the Internet from

+each other (or both).  Fuzzy or ambiguous searches are desirable for

+(at least) resolution of business names that might have spelling

+variations and for names that can be resolved into different sets of

+glyphs depending on context.  This goes beyond "mere"

+canonicalization differences (different ways of representing the same

+character) and into such relationships as the use of different

+alphabets for the same language, Kanji-Hiragana relationships, etc.

+

+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.  Cf RFC 2825.

+

+o In order to provide proper functionality to the Internet, the DNS

+must have a single unique root (see RFC 2826 for a discussion of this

+issue).  There are many desires for local treatment of names or

+character sets that cannot be accomodated without either multiple

+roots (e.g., a separate root for multilingual names) or mechanisms

+that would have similar effects in terms of Internet fragmentation

+and isolation.

+

+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 successfully deployed

+into the marketplace.

+

+Several of the above problems are addressed well by a good directory

+system (supported by the LDAP protocol or otherwise) 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 kludges are bad enough,

+or will scale up to bad enough, that new solutions are needed and can

+be deployed.

+

+

+3.  The directory story.

+

+3.1 Overview 

+The constraints of the DNS argue for introducing an intermediate

+protocol mechanism, referred to here as a "directory layer".

+Directory layer proposals would use a two-stage lookup, not unlike

+several of the IDN proposals, but would do the first lookup in a

+directory system, rather than in the DNS itself.  This would permit

+us to relax several constraints and produce a more comprehensive

+system.

+

+Ultimately, many of the issues with domain names arise as the result

+of people attempting to use the DNS as a directory.  While there

+hasn't been enough pressure/demand to justify a change to date, it

+has already been 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 directory requirement is a directory, not a series of

+DNS patches, kludges, or workarounds.

+

+In particular...

+

+* A directory system would not require imposition of particular

+length limits on names.

+

+* A directory system could permit explicit association of attributes

+of, 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).

+

+* There is considerable experience 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 one provides, the

+greater the possibility of real or imagined trademark conflicts, but

+we would have the opportunity to design a directory structure that

+dealt with those issues in an intelligent way, while DNS constraints

+arguably make a general and equitable DNS-only solution impossible.

+

+* 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, since the DNS

+name(s) would (continue to) uniquely identify the host.

+

+* Solutions to multilingual transcription problems that are common in

+"normal life" (e.g., two-sided business cards to be sure that a

+recipient trying to contact a person can access romanized spellings

+and numbers when the original language may not be comprehensible to

+that recipient) can be easily handled in a directory system by

+inserting both sets of entries.

+

+* One can easily imagine a directory system 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" problems that are a

+significant concern for organizations hosting web and other sites

+that are accessed from a wide range of locations and subnets.

+

+* Names bound to countries and languages might help to manage

+trademark realities, while use of the DNS in trademark-significant

+areas tends to require worldwide "flattening" of the trademark

+system. 

+3.2 Some details and comments.

+

+As several proposals have noted, almost any i18n 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, 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" stories and

+multi-attribute ones.  The DNS requires strict hierarchies, limiting

+its ability to handle differentiation 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 argument for a single directory structure (implying

+a need for mechanisms for registration, delegation, etc.).  But it 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 4).

+

+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 IDN purposes and might require "charset" if we cannot

+agree on a character set and encoding.  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 might argue for a few other attributes (as outlined

+above).

+

+4.  The Controversies

+

+4.1. One directory or many

+

+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

+directory with universal applicability, a single directory but

+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 we have assigned more and more names per host address.  

+Locally-tailored search 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, which is not, in

+general, a desirable situation.

+

+And, of course, completely separate directories would permit

+translation and transliteration functions to be embedded in the

+directory, given 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 roots.

+

+4.2 Why not a proposal?

+

+As this document has gone through various preliminary drafts and

+reviews, the question has been raised as to whether it should contain

+a specific proposal: a specific directory mechanism, schema, and so

+on.  It deliberately does not take that step.  It has been difficult

+to get directory systems deployed in significant ways in the Internet

+infrastructure, partially because we have a surplus of options.

+There are also some approaches that could be used to implement the

+general concepts described here, such as the Common Name Resolution

+Protocol [RFC2972], which some would not consider directory protocols

+at all.  Consequently, it appeared better to present the general

+concepts and arguments here and leave the specifics to other sources,

+documents, and proposals.

+ 

+5.  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 this purpose would presumably need to be as

+carefully protected against unauthorized changes as the DNS itself.

+There also might be new opportunities for problems in the two-layer

+arrangement; but those problems are not more severe than a two-stage

+lookup in the DNS.

+

+

+6.  References

+

+RFC 625 On-line hostnames service. M.D. Kudlick, E.J. Feinler.

+Mar-07-1974.

+

+RFC 811 Hostnames Server. K. Harrenstien, V. White, E.J. Feinler.

+Mar-01-1982.

+

+RFC 952 DoD Internet host table specification. K. Harrenstien, M.K.

+Stahl, E.J. Feinler. Oct-01-1985.

+

+RFC 882 Domain names: Concepts and facilities. P.V. Mockapetris.

+Nov-01-1983.

+

+RFC 883 Domain names: Implementation specification. P.V. Mockapetris.

+Nov-01-1983.

+

+RFC 1035 Domain names - implementation and specification. P.V.

+Mockapetris. Nov-01-1987.

+

+RFC 1591 Domain Name System Structure and Delegation. J. Postel.

+March 1994.

+

+RFC 2825 A Tangled Web: Issues of I18N, Domain Names, and the Other

+Internet protocols. IAB, L. Daigle, ed.. May 2000.

+

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

+

+RFC 2972 Context and Goals for Common Name Resolution. N. Popp, M.

+Mealling, L. Masinter, K. Sollins. October 2000.

+

+ITU Recommendation X.9

+

+ITU Recommendation X.25

+

+

+7. Culprit address

+

+John Klensin

+AT&T Labs

+99 Bedford Street

+Boston, MA 02111

+klensin@research.att.com

+

+Expires May 2001

diff --git a/doc/draft/draft-kosters-dnsext-dnssec-opt-in-00.txt b/doc/draft/draft-kosters-dnsext-dnssec-opt-in-00.txt
new file mode 100644
index 00000000..ec4893a1
--- /dev/null
+++ b/doc/draft/draft-kosters-dnsext-dnssec-opt-in-00.txt
@@ -0,0 +1,448 @@
+
+
+Network Working Group                                         M. Kosters
+Internet-Draft                                   Network Solutions, Inc.
+Expires: May 18, 2001                                  November 17, 2000
+
+
+                     DNSSEC Opt-in for Large Zones
+               draft-kosters-dnsext-dnssec-opt-in-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."
+
+   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 May 18, 2001.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+   In order for DNSSEC to be deployed operationally with large zones
+   and little operational impact, there needs to be included a
+   mechanism that allows for the separation of secure versus unsecure
+   views of zones. This needs to be done in a transparent fashion that
+   allows DNSSEC to be deployed in an incremental manner.  This
+   document proposes the use of an extended RCODE to signify that a
+   DNSSEC-aware requestor may have to re-query for the information, if
+   and only if, the delegation is not yet secure. Thus, one can
+   maintain two views of the zone and expand the DNSSEC zone as demand
+   warrants.
+
+
+
+
+
+Kosters                   Expires May 18, 2001                  [Page 1]
+
+Internet-Draft               DNSSEC Opt In                 November 2000
+
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2. Rationale  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+   3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . . 4
+   4. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
+   5. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
+   6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
+      References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
+      Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kosters                   Expires May 18, 2001                  [Page 2]
+
+Internet-Draft               DNSSEC Opt In                 November 2000
+
+
+1. Introduction
+
+   DNS is an unsecure system. The key features that gives DNS its power
+   can also be its chief weaknesses. One feature is the facility to
+   delegate branches of information from one set of servers to another.
+   Currently, this is done in a non-cryptographically verified way that
+   allows spoofing attacks. For example, Eugene Kashpureff exploited
+   this vulnerability to redirect www.netsol.com and www.internic.net
+   to his own website. If this delegated information had been
+   cryptographically verified, this attack would not have been able to
+   occur. 
+
+   In recent years, there has been much work within the IETF regarding
+   DNS security. There are  a number of RFCs that integrate public key
+   technology within DNS to enable cryptographically-verified answers.
+   To this end, three new resource record types (RR's) have been
+   defined: 
+
+   o  KEY -- a public key of the zone
+   o  SIG - a signature of an accompanying RR
+   o  NXT - a negative response record
+
+   Within the zone, each authoritative RR will have accompanying SIG
+   RR's that can be verified with the KEY RR of the zone. Each KEY RR
+   can be verified hierarchically with a SIG RR from the direct parent
+   zone. For unsecure delegations, a null-KEY RR is inserted in the
+   parent zone. Finally, NXT RR's and their accompanying SIG RR's are
+   issued in the case of a negative reply. 
+
+   As a zone maintainer, transitioning to a secure zone has a high
+   overhead in the following areas: 
+
+   KEY RR 
+      At a delegation point, the zone maintainer needs to place a NULL
+      key and accompanying SIG RR's when the child zone is not known to
+      be secure.
+   NXT RR 
+      Each delegation needs to be lexigraphically ordered so that a NXT
+      RR can be generated and signed with SIG RR's. For large zone
+      operators, generating the zone file is a very time consuming
+      process. In the resolution process, NXT lookups require that the
+      server replace efficient hash structures with a lexigraphically
+      ordered search structure which degrades lookup performance. This
+      lookup performance is a critical element for a high-query rate
+      DNS server. 
+
+   Thus, the net effect is when one initially secures a zone as defined
+   in RFC2535[4], the net overhead is massive because of the following
+   factors: 
+
+
+Kosters                   Expires May 18, 2001                  [Page 3]
+
+
+   1.  Zone ordering and maintenance for large zones is difficult and
+       expensive.
+   2.  Adding null-KEY RR's, NXT RR's and their accompanying SIG RR's
+       for unsecure delegations will consume large amounts of memory
+       (6x the current memory requirements).
+   3.  Having a less efficient look-up algorithm to provide answers to
+       queries will degrade overall performance.
+   4.  Very little initial payoff (anticipate only a small fraction of
+       delegations to be signed. This equates to less than 1% over the
+       first six months).
+   5.  Unsecured delegations are more expensive at the parent than
+       secure delegations (NULL KEY).
+
+2. Rationale
+
+   As DNSSEC is initially deployed, it is anticipated that DNSSEC
+   adoption will be slow to materialize. It is also anticipated that
+   DNSSEC security resolution will be top down. Thus for DNSSEC to be
+   widely adopted, the root zone and GTLD zones will need to be signed.
+   Based on the implications previously listed, a large zone maintainer
+   such as the administrator of COM, needs to create an infrastructure
+   that is an order of magnitude larger than its current state with
+   very little initial benefit. 
+
+   This document proposes an alternative opt-in approach that minimizes
+   the expense and complexity to ease adoption of DNSSEC for large
+   zones by allowing for an alternate view of secured only delegations. 
+
+3. Protocol Additions
+
+   The opt-in proposal allows for a zone operator to maintain two views
+   of its delegations - one being non-DNSSEC and the other being
+   DNSSSEC aware. The non-DNSSEC view will have all delegations - both
+   secured and non-secured. The DNSSEC aware view will only have
+   secured delegations. It is assumed that neither view will have any
+   innate knowledge of the other's delegations. Thus, the cost of
+   securing a zone is proportional to the demand of its delegations
+   with the added benefit of no longer having to maintain NULL KEY RRs
+   for unsecure delegations. 
+
+   To determine which view each DNS query packet is to be queried
+   against, there is a simple algorithm to be followed: 
+
+   1.  The DNSSEC view is to be queried when the DO bit is set within
+       the EDNS0 OPT meta RR as indicated in [6].
+   2.  The DNSSEC view is to be queried when the query type is SIG,
+       KEY, or NXT and the RRs added match the query name and query
+       type.
+   If the query does not follow either case (1) or (2), the non-DNSSEC
+   view MUST be consulted by default. 
+
+
+
+Kosters                   Expires May 18, 2001                  [Page 4]
+
+Internet-Draft               DNSSEC Opt In                 November 2000
+
+
+   Since the DNSSEC view will have a subset of the actual delegations
+   of that zone, it will not be able to respond to an unsecured
+   delgation. To that end, a new extended RCODE MUST be set within the
+   EDNS OPT RR for the resolver to retry again with the DO bit not set.
+   This RCODE is referred to as "RETRY-NO-SEC" (RS).  In the context of
+   the EDNS0 OPT meta-RR, the RS value will be determined by IANA.
+   Setting the RS RCODE in a response indicates to the resolver that
+   the resolver is retrying the query again without the DO bit set. The
+   behavior of the authority and additional records section being
+   populated should be the same using the RS RCODE as the the RCODE
+   being set to NXDOMAIN. Therefore, the resolver will be able to
+   verify that the answer does not exist within the secure zone since
+   the NXT RR will be sent in the Authority section. To avoid caching,
+   the server SHOULD set the TTL on the NXT RR to 0. 
+
+   Example: 
+
+   Consider a zone with the secure names 3, 6, and 9, and unsecure
+   names 2, 4, 5, 7, and 8. 
+
+   Unsecured zone Contents: 
+
+     @ SOA
+     2 NS
+     3 NS
+     4 NS
+     5 NS
+     6 NS
+     7 NS
+     8 NS
+     9 NS
+
+   Secured zone Contents:
+     @ SOA, SIG SOA, NXT(3), SIG NXT
+     3 NS, SIG NS, NXT(6), SIG NXT
+     6 NS, SIG NS, NXT(9), SIG NXT
+     9 NS, SIG NS, NXT(@), SIG NXT
+
+   1.  Query for 5 RR type A with EDNS0 DO bit set, the response would
+       return with the extended RCODE RS bit set: 
+
+
+     RCODE=RS
+     Authority Section:
+       SOA, SIG SOA, 3 NXT(6), SIG NXT
+     Additional Section:
+       KEY, SIG KEY
+
+
+
+
+Kosters                   Expires May 18, 2001                  [Page 5]
+
+Internet-Draft               DNSSEC Opt In                 November 2000
+
+
+        The source would then retry without the EDNS0 DO bit set which
+       would return an answer as defined in RFC1035[2].
+
+   2.  Query for 55 RR type A with EDNS0 DO bit set, the response would
+       return with the extended RCODE RS bit set: 
+
+
+     RCODE=RS
+     Authority Section:
+       SOA, SIG SOA, 3 NXT(6), SIG NXT
+     Additional Section:
+       KEY, SIG KEY
+
+
+        The source would then retry without the EDNS0 DO bit set which
+       would return an answer as defined in RFC1035[2].
+
+   3.  Query for 33 RR type KEY without EDNS DO bit set. The response
+       would return with an answer as defined in RFC2535[4]. 
+
+   4.  Query for 3 RR type A, with EDNS0 DO bit set, the response would
+       be the same as defined in RFC2535[4]. 
+
+
+4. Security Considerations
+
+   This draft is different and separate from RFC2535[4] in that it
+   allows for secured delegation paths to exist but does not allow for
+   secure answers to unsecured delegations at the parent level.
+   Increased exposure will be marginal given that the children are
+   unsecure. 
+
+5. IANA Considerations
+
+   Allocation of the most significant bit of the RCODE field in the
+   EDNS0 OPT meta-RR is required. 
+
+6. Acknowledgements
+
+   This document is based on a rough draft by Brian Wellington, and
+   input from Olafur Gudmundsson. 
+
+References
+
+   [1]  Mockapetris, P.V., "Domain names - concepts and facilities",
+        RFC 1034, STD 13, Nov 1987.
+
+   [2]  Mockapetris, P.V., "Domain names - implementation and
+        specification", RFC 1035, STD 13, Nov 1987.
+
+
+Kosters                   Expires May 18, 2001                  [Page 6]
+
+Internet-Draft               DNSSEC Opt In                 November 2000
+
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119, BCP 14, March 1997.
+
+   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [5]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
+        August 1999.
+
+   [6]  Conrad, D. R., "Indicating Resolver Support of DNSSEC (work in
+        progress)", August 2000.
+
+
+Author's Address
+
+   Mark Kosters
+   Network Solutions, Inc.
+   505 Huntmar Park Drive
+   Herndon, VA  22070
+   US
+
+   Phone: +1 703 948-3362
+   EMail: markk@netsol.com
+   URI:   http://www.netsol.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kosters                   Expires May 18, 2001                  [Page 7]
+
+Internet-Draft               DNSSEC Opt In                 November 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kosters                   Expires May 18, 2001                  [Page 8]
+
diff --git a/doc/draft/draft-msawyer-dnsext-edns-attributes-00.txt b/doc/draft/draft-msawyer-dnsext-edns-attributes-00.txt
new file mode 100644
index 00000000..93cd28f2
--- /dev/null
+++ b/doc/draft/draft-msawyer-dnsext-edns-attributes-00.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                                 M. Sawyer
+                                                           A. Gustafsson
+                                                                M. Graff
+                                                                 Nominum
+<draft-msawyer-dnsext-edns-attributes-00.txt>           15 November 2000
+
+                  Handling of unknown EDNS0 attributes
+
+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 draft expires on May 15, 2001.
+
+Abstract
+
+   This document provides a clarification of the EDNS0 protocol,
+   specifying the behavior of servers when they receive unknown EDNS
+   options.
+
+1.1 - Introduction
+
+   Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms
+   [RFC2671] is helpful.
+
+   EDNS0 [RFC2671] specifies a general framework for extending the
+   packet format used by the Domain Name System protocol.  The framework
+   provides for a series of additional options, identified by a 16 bit
+   attribute ID and arbitrary sized payload.  Any number of these
+   additional options can be specified in the DNS packet.  As specified,
+   the current scheme has drawbacks:
+
+
+
+Expires May 2001                                               [Page 1]
+
+INTERNET-DRAFT     Handling of unknown EDNS attributes      October 2000
+
+
+   - It provides no way for implementers to deploy test systems with
+   experimental features prior to approval of the feature and assignment
+   of an attribute ID.
+
+   - It provides no specification on what an application should do when
+   receiving unrecognized options.
+
+   This draft proposes to clarify the original EDNS0 draft [RFC2671],
+   addressing these drawbacks.
+
+1.2 - Requirements
+
+   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 - Protocol changes:
+
+   This document updates [RFC2671].  Conformance to this specification
+   is claimed by specifying EDNS version 1.
+
+2.1 - Advisory and Required Options:
+
+
+   Some potential uses of EDNS options are advisory in nature,  For
+   example, a hypothetical option indicating that "I understand frobozz
+   compression in responses" can be safely ignored by the recipient,
+   which will then simply not use frobozz compression.  Others uses of
+   options, such as a hypothetical "send only cryptographically verified
+   data in responses" option, cannot be safely ignored, and should cause
+   the request to fail if not understood by the receiver.
+
+   This suggests that we need two types of options, "advisory" options
+   (that can be ignored) and "required" options (that can not).  Because
+   a server needs to classify options as advisory or required even if
+   they were not yet defined when the server was implemented, the type
+   of an option must be evident without knowing its internal structure.
+   This is achieved by splitting the option type codes into two ranges:
+   options with type code 0x0000-0x7FFF are considered "advisory", and
+   options with type code 0x8000-0xFFFF are considered "required".
+
+2.2 - Handling of Unknown and Unsupported EDNS Option Types
+
+   When a server receives an unknown or unsupported advisory option in a
+   request or response message, it MUST ignore the unknown option and
+   process the message as if the option was not present.  In the reply,
+   it SHOULD include an advisory UNSUPPORTED option (TBD).
+
+
+
+
+Expires May 2001                                               [Page 2]
+
+INTERNET-DRAFT     Handling of unknown EDNS attributes      October 2000
+
+
+   When a server receives an unknown or unsupported required option in a
+   request message, it MUST NOT act on the request, and it MUST return
+   an error response with the extended result code BADOPT (TBD).  In the
+   reply, it SHOULD include an advisory UNSUPPORTED option.
+
+   When a server receives an unknown or unsupported required option in a
+   response message, it MUST ignore the response.  The server SHOULD
+   continue to parse options after the unknown option, including a list
+   of all unsupported options in the UNSUPPORTED option in the reply.
+
+   Servers MAY include SUPPORTED options in replies to messages, listing
+   option codes which they understand.  This message SHOULD contain all
+   option codes the server understands.  This facility MAY NOT be used
+   in place of the UNSUPPORTED option to identify unsupported options in
+   replies.
+
+   Clients MAY include SUPPORTED or UNSUPPORTED options in queries.
+   UNSUPPORTED options SHOULD only list those option codes which the
+   client has received in previous replies from the server, not an
+   inclusive list of all unsupported option codes.
+
+2.3 - Use of Reserved Options for Development
+
+   Option codes in the range of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF
+   are considered "reserved" and shall not be assigned to new protocols.
+   Software vendors SHOULD use these options for testing of protocols
+   under development, provided the following conditions are met:
+
+   - Vendors MUST NOT ship any versions of the software which use option
+   codes in this range.  They MUST delay shipping software with the new
+   options until IANA has assigned permanent option codes.
+
+   - Vendors MUST NOT place development servers on the live internet
+   which send options in this range to remote servers or which
+   understand options in this range as having any meaning.
+
+3.1 - SUPPORTED and UNSUPPORTED options
+
+   The SUPPORTED and UNSUPPORTED options contain a list of option codes
+   which the server or client does or doesn't support.  The list
+   contains, in network byte order, the supported or unsupported 16 bit
+   option codes:
+
+                                     1  1  1  1  1  1
+       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     |        SUPPORTED or UNSUPPORTED (TBD)         |
+     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+
+Expires May 2001                                               [Page 3]
+
+INTERNET-DRAFT     Handling of unknown EDNS attributes      October 2000
+
+
+     |        LENGTH (number of options * 2)         |
+     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     /               OPTION CODE(s)                  /
+     /                                               /
+     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   Sending a SUPPORTED option with a zero-length payload indicates that
+   the server or client supports no EDNS options, so none should be
+   used.  UNSUPPORTED options with zero-length payloads SHOULD NOT be
+   sent, as such a message is meaningless.
+
+4 - IANA considerations
+
+   When allocating EDNS Option Codes, the IANA shall henceforth require
+   the RFC defining the new option to specify whether the option is an
+   "advisory" or a "required" option.  The option code for an advisory
+   option shall be allocated from the range 0x0000-0x7FEF, and the code
+   for a required option shall be allocated from the range
+   0x8000-0xFFEF.
+
+   Option codes in the ranges of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF
+   are considered "reserved."
+
+   The IANA is hereby requested to assign EDNS Version Number 1 to this
+   specification, to assign a new extended RCODE value for BADOPT, and
+   to assign advisory option codes for UNSUPPORTED and SUPPORTED.
+
+
+5 - Security considerations
+
+   This document provides a mechanism for users to override the default
+   behavior of the server when accessing data from its internal zone
+   databases.  Software developers and administrators should use some
+   care when enabling these options, as they may provide outside users
+   the ability to retrieve information otherwise not available.
+
+6 - Acknowledgments
+
+   The authors would like to thank Olafur Gudmundsson for his input on
+   this draft.
+
+7 - References
+
+   [RFC2119] S. Brander, ``Key words for use in RFCs to Indicate
+   Requirement Levels,'' RFC 2119, ISI, November 1997.
+
+   [RFC2671]   P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC
+   2671, ISI, August, 1999
+
+
+
+Expires May 2001                                               [Page 4]
+
+INTERNET-DRAFT     Handling of unknown EDNS attributes      October 2000
+
+
+Author's Address
+
+   Michael Sawyer
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   Phone: +1-650-779-6021
+   michael.sawyer@nominum.com
+
+   Andreas Gustafsson
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   Phone: +1-650-779-6004
+   andreas.gustafsson@nominum.com
+
+   Michael Graff
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   Phone: +1-650-779-6034
+   michael.graff@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 2001                                               [Page 5]
+
diff --git a/doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt b/doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt
new file mode 100644
index 00000000..574b5f29
--- /dev/null
+++ b/doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt
@@ -0,0 +1,221 @@
+INTERNET-DRAFT                                                 M. Sawyer
+                                                           B. Wellington
+                                                                M. Graff
+                                                                 Nominum
+<draft-sawyer-dnsext-edns0-zone-option-00.txt>            9 October 2000
+
+              ZONE and VIEW option records in DNS messages
+
+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 draft expires on April 9, 2001.
+
+Abstract
+
+   This document defines two new EDNS option codes used to specify what
+   zone and view should be used in query messages to a remote DNS
+   server.
+
+1 - Introduction
+
+   Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms
+   [RFC2671] is helpful.
+
+   Domain Concepts and Facilities [RFC1034] Section 3.7 shows a typical
+   reply to a DNS query, containing the answer as well as additional
+   data related to the answer provided.  The server's zone database may
+   contain out-of-zone data glue which is internally used but is never
+   returned in a reply to a query.  If recursion is requested by the
+   client and available in the server, or if the data is available in
+
+
+
+Expires April 2001                                             [Page 1]
+
+INTERNET-DRAFT        ZONE and VIEW option records          October 2000
+
+
+   the server's cache, the additional information will be taken from
+   these sources on most servers.
+
+   There is no method currently available for an administrator to query
+   a server specifying that only data from a specific zone should be
+   used in formulating the reply and that all available data from that
+   zone's database should be used, including out-of-zone glue.  As such,
+   there is no mechanism for an administrator to ensure that out-of-zone
+   data in the zone's database is correct except through direct
+   manipulation of the zone database files.  In addition, zone transfers
+   via AXFR or IXFR do not include out-of-zone glue.  The ZONE option
+   code is provided to specify directly which zone database should be
+   queried.
+
+   In addition, DNS server software exists which may present different
+   "views" of the DNS space to different clients.  In some cases, a
+   query may match the criteria of multiple views, and a user may wish
+   to specify which of the acceptable views match the query.  The VIEW
+   option code is provided to specify which view should be searched for
+   the appropriate zone database.
+
+1.2 - Requirements
+
+   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 - Protocol changes:
+
+   This document updates [RFC2671].  The ZONE and VIEW option records
+   are intended as optional features.  Servers MAY support either or
+   both of these options.  Servers SHOULD provide configuration options
+   to enable or disable these optional records as needed.
+
+   Servers and clients SHOULD NOT use the ZONE or VIEW option codes in
+   normal use.
+
+   Servers SHOULD NOT use the VIEW option record in zone transfers
+   unless the administrator has specifically configured the server to
+   use these records.  Servers MAY provide a mechanism for such
+   configuration.  Servers SHOULD NOT use the ZONE option record in zone
+   transfers under any configuration.
+
+3 - ZONE option record
+
+   The ZONE OPTION-DATA MUST contain a standard uncompressed wire-format
+   name in the format specified by [RFC1035] Section 3.3.  Wildcards are
+   not permitted in ZONE option records.
+
+
+
+Expires April 2001                                             [Page 2]
+
+INTERNET-DRAFT        ZONE and VIEW option records          October 2000
+
+
+   When a server receives a query with a ZONE option record, it MUST
+   reply with a REFUSED reply if it understands the ZONE record but is
+   not configured to allow ZONE specific requests, if the specified zone
+   does not exist on the server, or if the client is not authorized to
+   use the ZONE option.  If the ZONE option is allowed, it MUST return a
+   normally formatted reply with a ZONE optional record, containing the
+   same zone as the one queried.  When replying to AXFR or IXFR queries
+   with ZONE options, the entire zone, including out-of-zone glue,
+   should be returned to the client.
+
+   Servers SHOULD treat ZONE options in zone transfer requests as an
+   unauthorized request and return REFUSED.
+
+3.2 - VIEW option record
+
+   The VIEW OPTION-RECORD contains an arbitrary length text field, which
+   is used to match the name of the view in the server's configuration.
+
+   When a server receives a query with a VIEW option record, it MUST
+   reply with a REFUSED reply if it understands the VIEW record but is
+   not configured to allow VIEW specific requests, the specified view
+   does not exist, or the client is not authorized to access the
+   specified view.  If a VIEW option is allowed, it MUST return a
+   normally formatted reply with a VIEW optional record containing the
+   same view as the one queried.  The information used in generating the
+   reply should contain only information from the specified view of the
+   DNS space.
+
+4 - IANA considerations
+
+   We request IANA assign option codes for the ZONE and VIEW options.
+
+5 - Security considerations
+
+   This document provides a mechanism for users to override the default
+   behavior of the server when accessing data from its internal zone
+   databases.  Software developers and administrators should use some
+   care when enabling these options, as they may provide outside users
+   the ability to retrieve information otherwise not available.
+
+6 - References
+
+   [RFC1034]   P. Mockapetris, ``Domain Names - Concepts and
+   Facilities,'' RFC 1034, ISI, November 1987.
+
+   [RFC1035]   P. Mockapetris, ``Domain Names - Implementation and
+   Specification,'' RFC 1035, ISI, November 1987.
+
+
+
+
+Expires April 2001                                             [Page 3]
+
+INTERNET-DRAFT        ZONE and VIEW option records          October 2000
+
+
+   [RFC2119] S. Brander, ``Key words for use in RFCs to Indicate
+   Requirement Levels,'' RFC 2119, ISI, November 1997.
+
+   [RFC2671]   P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC
+   2671, ISI, August, 1999
+
+
+Author's Address
+
+   Michael Sawyer
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   Phone: +1-650-779-6021
+   michael.sawyer@nominum.com
+
+   Brian Wellington
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   Phone: +1-650-779-6022
+   brian.wellington@nominum.com
+
+   Michael Graff
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   Phone: +1-650-779-6034
+   michael.graff@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires April 2001                                             [Page 4]
+
diff --git a/doc/draft/draft-skwan-gss-tsig-05.txt b/doc/draft/draft-skwan-gss-tsig-05.txt
deleted file mode 100644
index 8535e96f..00000000
--- a/doc/draft/draft-skwan-gss-tsig-05.txt
+++ /dev/null
@@ -1,738 +0,0 @@
-INTERNET-DRAFT                                             Stuart Kwan
-                                                          Praerit Garg
-                                                          James Gilroy
-                                                       Microsoft Corp.
-                                                         February 2000
-<draft-skwan-gss-tsig-05.txt>                      Expires August 2000
-
-
-                 GSS Algorithm for TSIG (GSS-TSIG)
-
-
-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
-
-The 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) [RFC2078].
-
-
-
-
-
-
-
-
-
-
-
-Expires August 2000                                           [Page 1]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-Table of Contents
-
-1: Introduction......................................................2
-2: Protocol Overview.................................................3
-  2.1: GSS Details...................................................4
-3: Client Protocol Details...........................................4
-  3.1: Negotiating Context...........................................4
-    3.1.1: Call GSS_Init_sec_context.................................5
-    3.1.2: Send TKEY Query to Server.................................6
-    3.1.3: Receive TKEY Query-Response from Server...................6
-  3.2: Context Established...........................................8
-4: Server Protocol Details...........................................8
-  4.1: Negotiating Context...........................................8
-    4.1.1: Receive TKEY Query from Client............................9
-    4.1.2: Call GSS_Accept_sec_context...............................9
-    4.1.3: Send TKEY Query-Response to Client........................9
-  4.2: Context Established..........................................10
-    4.2.1: Terminating a Context....................................10
-5: Sending and Verifying Signed Messages............................11
-  5.1: Sending a Signed Message - Call GSS_GetMIC...................11
-  5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............12
-6: Security Considerations..........................................12
-7: Acknowledgements.................................................13
-8: References.......................................................13
-
-
-1. Introduction
-
-The Secret Key Transaction Signature for DNS [TSIG] protocol was
-developed to provide a lightweight alternative to full DNS security
-[RFC2535] and secure dynamic update [RFC2137], where full security is
-impractical due to implementation complexity, management overhead, or
-computational cost.
-
-The [TSIG] protocol is extensible through the definition of new
-algorithms.  This document specifies an algorithm based on the Generic
-Security Service Application Program Interface (GSS-API) [RFC2078].
-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 for one
-transaction, whereas that same server may use TLS with a different
-client.
-
-
-
-
-Expires August 2000                                           [Page 2]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-* 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.
-
-
-2. Protocol Overview
-
-Readers that are unfamiliar with the GSS-API concepts are encouraged
-to read the characteristics and concepts section of [RFC2078] before
-examining this protocol in detail.
-
-In GSS, client and server interact to create a "security context".
-The security context is 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:
-
-
-                           +----------+
-                           |          |
-                           V          |
-                   +---------------+  |
-                   | Uninitialized |  |
-                   |               |  |
-                   +---------------+  |
-                           |          |
-                           V          |
-                   +---------------+  |
-                   | Negotiating   |  |
-                   | Context       |  |
-                   +---------------+  |
-                           |          |
-                           V          |
-                   +---------------+  |
-                   | Context       |  |
-                   | Established   |  |
-                   +---------------+  |
-                           |          |
-                           +----------+
-
-Every connection begins in the uninitialized state.
-
-
-
-Expires August 2000                                           [Page 3]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-2.1 GSS Details
-
-Client and server must be locally authenticated and have acquired
-default credentials per [RFC2078] before using this protocol.
-
-Not all flags used in GSS-API interfaces are specified in this
-document.  Where omitted, clients and servers may select the default
-or use a value based on local system policy.
-
-Not all error return values from GSS-API interfaces are specified in
-this document.  When errors are encountered, the caller should act
-appropriately.
-
-
-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 handles to servers,
-
-     (target_server_name, key_name, context_handle)
-
-The value key_name also identifies a context handle, and is used on
-the wire to indicate to a server which context should be used to
-process the current request.
-
-
-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.
-
-The TKEY resource record [TKEY] 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 [TKEY].
-
-
-
-
-
-
-
-
-
-Expires August 2000                                           [Page 4]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-3.1.1 Call GSS_Init_sec_context
-
-The client obtains the first token by calling GSS_Init_sec_context.
-The following input parameters are used.  The outcome of the call
-is indicated with the output values below.  Consult [RFC2078] for
-syntax definitions.
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = 0
-     INTERNAL NAME  targ_name             = DNS/<target_server_name>
-     OCTET STRING   input_token           = NULL
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-     BOOLEAN        deleg_req_flag        = TRUE (optional)
-
-   OUTPUTS
-     INTEGER        major_status
-     CONTEXT HANDLE output_context_handle
-     OCTET STRING   output_token
-     BOOLEAN        replay_det_state
-     BOOLEAN        mutual_state
-
-The values of replay_det_state and mutual_state indicate if the
-security package can provide replay detection and mutual
-authentication, respectively.  If one or both of these values
-are FALSE, the client must abandon this protocol.
-
-The deleg_req_flag is optional, and can be used if the client wants
-the server to be able to call out to other services under the
-context of the client.
-
-If major_status indicates an error, the client must abandon the
-protocol.  Success values of major_status are GSS_S_CONTINUE_NEEDED
-and GSS_S_COMPLETE.  The exact success code is important during later
-processing.
-
-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_server_name.
-
-
-
-
-
-
-
-
-
-
-
-
-Expires August 2000                                           [Page 5]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-3.1.2 Send TKEY Query to Server
-
-The output_token from GSS_Init_sec_context is transmitted to the
-server in a query request for a TKEY record.  The token itself
-will be placed in a TKEY record in the additional records section of
-the query.  The domain-like name of the TKEY record set queried for
-and the name of the supplied TKEY record in the additional section
-will uniquely identify the security context to both the client and
-server, and thus the client should use a value which is globally
-unique.
-
-   TKEY Record
-     NAME = client-generated globally unique domain name string
-            (see [TKEY])
-     RDATA
-        Algorithm Name      = gss-tsig.microsoft.com
-        Mode                = 3 (GSS-API negotiation - see [TKEY])
-        Key Size            = size of output_token
-        Key                 = output_token
-
-Assign the remaining fields in the TKEY RDATA appropriate values
-per [TKEY].
-
-If the last call to GSS_Init_sec_context yielded a major_status value
-of GSS_S_COMPLETE, then the message should be signed with a TSIG
-record before being sent to the server.  See section 5, Sending
-and Verifying Signed Messages, for the signing procedure.
-
-The query is transmitted to the server.
-
-
-3.1.3 Receive TKEY Query-Response from Server
-
-The server will return a standard TKEY query-response (see [TKEY]).
-The response may indicate that TKEY is not supported, or that the
-GSS-API mode and algorithm are not supported.  If this is the case,
-the client must abandon this algorithm.
-
-If the value of the Error field in the TKEY RDATA (TKEY.Error) is
-BADKEY, then the token provided by the client was invalid.  The
-client must abandon this algorithm.
-
-If TKEY.Error indicates success, then the client may continue.  The
-next processing step depends on the value of major_status from the
-most recent call to GSS_Init_sec_context: either GSS_S_COMPLETE or
-GSS_S_CONTINUE.
-
-
-
-
-
-Expires August 2000                                           [Page 6]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-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 will be in the form of a NOERROR query response
-containing the last client supplied TKEY record in the answer section
-of the query.  The response may also be signed with a TSIG record,
-and if present this signature must be verified using the procedure
-detailed in section 5, Sending and Verifying Signed Messages.
-
-If the message verification completes without an error, or if a TSIG
-signature was not included, 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
-
-If the last call to GSS_Init_sec_context yielded a major_status value
-of GSS_S_CONTINUE, then the negotiation is not yet complete.  The
-server will respond to the TKEY query with a NOERROR query response
-that contains a TKEY record in the answer section.  The TKEY record
-contains a token that is passed to GSS_Init_sec_context using the
-parameters from the previous call and the following modifications:
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = context_handle
-     OCTET STRING   input_token           = token from Key field of
-                                            TKEY record
-
-   OUTPUTS
-     INTEGER        major_status
-     OCTET STRING   output_token
-
-If major_status indicates an error, the client must abandon this
-algorithm.  Success values are GSS_S_CONTINUE and GSS_S_COMPLETE.
-
-If major_status is GSS_S_CONTINUE the negotiation is not yet
-finished.  The token output_token must again be passed to the server
-in a TKEY record. The negotiation sequence is repeated beginning
-with section 3.1.2.  The client should place a limit on the number
-of continuations in a context negotiation to prevent endless
-looping.
-
-
-
-
-
-Expires August 2000                                           [Page 7]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-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.  The negotiation
-sequence is repeated beginning with section 3.1.2.
-
-If major_status is GSS_S_COMPLETE and output_token is NULL, context
-negotiation is complete.  The response from the server may be signed
-with a TSIG record, and if present this signature must be verified
-using the procedure detailed in section 5, Sending and
-Verifying Signed Messages.
-
-If the message verification completes without an error, or if a TSIG
-signature was not included, 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 is
-used for the generation and verification of transaction signatures.
-
-The procedures for sending and receiving signed messages are given in
-section 5, Sending and Verifying Signed Messages.
-
-
-4.  Server Protocol Details
-
-As on the client-side, the result of a successful context negotiation
-is a context handle used in future processing.
-
-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 recognizes TKEY queries as security context negotiation
-messages.
-
-
-
-
-
-
-
-
-
-Expires August 2000                                           [Page 8]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-4.1.1 Receive TKEY Query from Client
-
-Upon receiving a TKEY query, the server must examine the Mode and
-Algorithm Name fields to see if they match this algorithm.  If they
-match, the (key_name, context_handle) mapping table is searched for
-the NAME value of the TKEY record.  If the name is found in the table,
-the corresponding context_handle is used in following GSS operations.
-If the name is not found a new negotiation is started.
-
-
-4.1.2 Call GSS_Accept_sec_context
-
-The server performs its side of a context negotiation by calling
-GSS_Accept_sec_context with the token provided by the client in the
-TKEY record.
-
-The server calls GSS_Accept_sec_context:
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = 0 if new negotiation,
-                                            context_handle if ongoing
-     OCTET STRING   input_token           = Key field from TKEY RR
-
-   OUTPUTS
-     INTEGER        major_status
-     CONTEXT_HANDLE output_context_handle
-     OCTET STRING   output_token
-
-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
-
-If major_status returns a GSS failure code, the negotiation has
-failed.  The server must respond to the client with a standard
-TKEY query-response where the TKEY error field value is set to
-BADKEY.
-
-Success values for major_status are GSS_S_COMPLETE or GSS_S_CONTINUE.
-
-
-
-
-
-
-
-
-
-Expires August 2000                                           [Page 9]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-If major_status is GSS_S_COMPLETE the server component of the
-negotiation is finished. The message from the client may be signed
-with a TSIG RR, and if present this signature must be verified
-using the procedure detailed in section 5, Sending and
-Verifying Signed Messages.  The server responds to the TKEY query
-using a standard query response. If output_token is non-NULL, then it
-must be returned to the client in a TKEY in the Answer section of the
-response.  If output_token is NULL, then the TKEY record received from
-the client must be returned in the Answer section of the response.
-The answer should be signed with a TSIG record per the procedure given
-in section 5, Sending and Verifying Signed Messages.
-The context state is advanced to Established.  Section 4.2 discusses
-the usage of the security context.
-
-If major_status is GSS_S_CONTINUE, the server component of the
-negotiation is not yet finished.  The server responds to the TKEY
-query with a standard query response, placing a TKEY record containing
-output_token in the answer section.  The negotiation sequence then
-repeats beginning with section 4.1.1.  The server must limit the
-number of times that a given context is allowed to repeat, to prevent
-endless looping.
-
-
-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.
-
-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
-"key deletion".  See [TKEY] for more details.
-
-An active context is deleted by calling GSS_Delete_sec_context
-providing the associated context_handle.
-
-
-
-
-
-
-
-Expires August 2000                                          [Page 10]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-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 [TSIG].  The data to be passed to the signature routine includes
-the whole DNS message with specific TSIG variables appended.  For the
-exact format, see [TSIG].  For this protocol, use the following
-TSIG variable values: 
-
-   TSIG Record
-     NAME = key_name that identifies this context
-     RDATA
-        Algorithm Name = gss-tsig.microsoft.com
-
-Assign the remaining fields in the TKEY RDATA appropriate values
-per [TKEY].
-
-For the GSS algorithm, the signature is generated by calling
-GSS_GetMIC:
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for key_name
-     OCTET STRING   message        = outgoing message plus TSIG
-                                     variables (see [TSIG])
-
-   OUTPUTS
-     INTEGER        major_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 or GSS_S_CREDENTIALS_EXPIRED,
-the caller needs to return to the uninitialized state and negotiate
-a new security context.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires August 2000                                          [Page 11]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-5.2 Verifying a Signed Message - Call GSS_VerifyMIC
-
-The procedure for verifying a signature-protected message is specified
-in [TSIG].
-
-The NAME of the TSIG record determines which context_handle
-maps to this context.  If the NAME does not map to a currently active
-context, the server must send a standard TSIG error response to the
-client indicating BADKEY in the TSIG error field (see [TSIG]).
-
-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 (see [TSIG])
-     OCTET STRING   per_msg_token  = Signature field from TSIG RR
-
-   OUTPUTS
-     INTEGER        major_status
-
-If major_status is GSS_S_COMPLETE, the signature is authentic and the
-message was delivered intact.  Per [TSIG], 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.
-
-If major_status is GSS_S_CONTEXT_EXPIRED, the negotiated context is no
-longer valid.  If this failure occurs 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 (see [TSIG]).
-
-If major_status is any other error code or 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
-per [TSIG].
-
-
-6. 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.
-
-
-
-
-
-
-
-Expires August 2000                                          [Page 12]
-
-
-INTERNET-DRAFT                   GSS-TSIG                February 2000
-
-
-7. 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 and Donald E. Eastlake 3rd.
-
-
-8. References
-
-[RFC2078] J. Linn, "Generic Security Service Application Program
-          Interface, Version 2," RFC 2078, OpenVision Technologies,
-          January 1997.
-
-[TSIG]    P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key
-          Transaction Signatures for DNS (TSIG),"
-          draft-ietf-dnsind-tsig-*..txt, ISC, TIS, Cybercash.
-
-[TKEY]    D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY
-          RR)," draft-ietf-dnssec-tkey-*.txt.
-
-[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
-          RFC 2535, IBM, March 1999.
-
-[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
-          RFC 2137, CyberCash, April 1997.
-
-
-9. Author's Addresses
-
-Stuart Kwan                         Praerit Garg
-Microsoft Corporation               Microsoft Corporation
-One Microsoft Way                   One Microsoft Way
-Redmond, WA  98052                  Redmond, WA  98052
-USA                                 USA
-<skwan@microsoft.com>               <praeritg@microsoft.com>
-
-James Gilroy
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA  98052
-USA
-<jamesg@microsoft.com>
-
-
-
-
-
-
-
-
-
-Expires August 2000                                          [Page 13]
-
-
diff --git a/doc/draft/draft-skwan-gss-tsig-06.txt b/doc/draft/draft-skwan-gss-tsig-06.txt
new file mode 100644
index 00000000..c760fda5
--- /dev/null
+++ b/doc/draft/draft-skwan-gss-tsig-06.txt
@@ -0,0 +1,11 @@
+

+This document has been replaced by draft-ietf-dnsext-gss-tsig-00.txt.

+For more information or a copy of the document, contact the author directly.

+

+Draft Author(s):

+

+S. Kwan: skwan@microsoft.com                                                     

+J. Gilroy: jamesg@microsoft.com                                                    

+P. Garg: praeritg@microsoft.com                                                  

+

+

diff --git a/doc/draft/draft-skwan-utf8-dns-03.txt b/doc/draft/draft-skwan-utf8-dns-04.txt
index 3d7cdbc6..d6558ee4 100644
--- a/doc/draft/draft-skwan-utf8-dns-03.txt
+++ b/doc/draft/draft-skwan-utf8-dns-04.txt
@@ -1,9 +1,8 @@
-
 INTERNET-DRAFT                                             Stuart Kwan
                                                           James Gilroy
                                                        Microsoft Corp.
-                                                         February 2000
-<draft-skwan-utf8-dns-03.txt>                      Expires August 2000
+                                                             July 2000
+<draft-skwan-utf8-dns-04.txt>                     Expires January 2001
 
 
      Using the UTF-8 Character Set in the Domain Name System
@@ -50,10 +49,10 @@ superset of ASCII and a translation of the UCS-2 character encoding.
 
 
 
-Expires August 2000                                           [Page 1]
+Expires January 2001                                          [Page 1]
 
 
-INTERNET-DRAFT                  UTF-8 DNS                February 2000
+INTERNET-DRAFT                  UTF-8 DNS                    July 2000
 
 1. Introduction
 
@@ -106,10 +105,10 @@ UTF-8 characters before transmitting those names in any message.
 
 
 
-Expires August 2000                                           [Page 2]
+Expires January 2001                                          [Page 2]
 
 
-INTERNET-DRAFT                  UTF-8 DNS                February 2000
+INTERNET-DRAFT                  UTF-8 DNS                    July 2000
 
 
 For consistency, UTF-8-aware DNS servers must compare names that
@@ -163,10 +162,10 @@ Cliff Van Dyke and Bjorn Rettig.
 
 
 
-Expires August 2000                                           [Page 3]
+Expires January 2001                                          [Page 3]
 
 
-INTERNET-DRAFT                  UTF-8 DNS                February 2000
+INTERNET-DRAFT                  UTF-8 DNS                    July 2000
 
 
 6. References
@@ -184,7 +183,7 @@ INTERNET-DRAFT                  UTF-8 DNS                February 2000
               Application and Support," STD 3, RFC 1123, January 1989.
 
 [RFC2130]     C. Weider et. al., "The Report of the IAB Character 
-              Set Workshop held 29 February - 1 March 1996",
+              Set Workshop held 29 July - 1 March 1996",
               RFC 2130, Apr 1997.
 
 [RFC2181]     R. Elz and R. Bush, "Clarifications to the DNS 
@@ -220,6 +219,8 @@ USA                                 USA
 
 
 
-Expires August 2000                                           [Page 4]
+Expires January 2001                                          [Page 4]
+
+
 
 
diff --git a/doc/draft/draft-whr-dnsext-secure-online-update-00.txt b/doc/draft/draft-whr-dnsext-secure-online-update-00.txt
index 8d941bee..6833196c 100644
--- a/doc/draft/draft-whr-dnsext-secure-online-update-00.txt
+++ b/doc/draft/draft-whr-dnsext-secure-online-update-00.txt
@@ -20,7 +20,7 @@ Status of this Memo
    Drafts.
 
    Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other 
+   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.''
@@ -55,8 +55,8 @@ INTERNET-DRAFT    Secure Online DNS Dynamic Update            June 2000
 
    to enable a DNS zone to provide online dynamic update and at the
    same time, maintain the zone's security including role separation
-   and intrusion tolerance against insider and outsider attacks. 
-   Threshold digital signature is used to implement the proposed 
+   and intrusion tolerance against insider and outsider attacks.
+   Threshold digital signature is used to implement the proposed
    architecture.
 
 1 - Introduction
@@ -67,7 +67,7 @@ INTERNET-DRAFT    Secure Online DNS Dynamic Update            June 2000
    distinguishes itself in that it provides high security
    for a zone when allowing it support online dynamic update.
 
-   Familiarity with the DNS system [RFC1034, RFC1035], DNS 
+   Familiarity with the DNS system [RFC1034, RFC1035], DNS
    Security Extension [RFC2535], dynamic update [RFC2136] and
    secure dynamic update [RFC2137] is helpful and is assumed by
    this document.
@@ -110,7 +110,7 @@ INTERNET-DRAFT    Secure Online DNS Dynamic Update            June 2000
       has been pointed out that DNS dynamic updates, which enable
       real-time changes (that is, add, delete, or update) in
       name/address bindings, are useful under many circumstances
-      [Liu99,RFC2136]. (For example, such an update allows a 
+      [Liu99,RFC2136]. (For example, such an update allows a
 
 Wang, Huang & Rine	                                   [Page 2]
 
@@ -124,7 +124,7 @@ INTERNET-DRAFT    					  June 2000
       be computed online. It is worthwhile to note that although
       a DNS dynamic update requestor is communicating with a name
       server, the name server itself has no rights to update the
-      zone data. Instead, it is the zone private key, instead of 
+      zone data. Instead, it is the zone private key, instead of
       the name server's private key, that is needed in the dynamic
       update.
 
@@ -135,7 +135,7 @@ INTERNET-DRAFT    					  June 2000
       private key is not kept online,  zone transfer security is
       not automatically provided for dynamically added RRs, where
       they could be omitted, and authorization is not provided for
-      the server denial of the existence of a dynamically added 
+      the server denial of the existence of a dynamically added
       type [RFC2137]. In this sense, this mode is not a genuine
       DNS dynamic update. In mode B, on the other hand, the zone
       private key is kept online at the zone primary name server;
@@ -156,13 +156,13 @@ INTERNET-DRAFT    					  June 2000
       principle and making it possible for the name server
       administrator to abuse his/her power. (The importance of fending
       off insider attacks has been emphasized by the security
-      community [RFC2196].) 
+      community [RFC2196].)
 
 2 - The Secure On-line DNS Dynamic Update Architecture
 
    2.1 - Background: Threshold Cryptography
 
-      Threshold cryptography is a branch of cryptography that 
+      Threshold cryptography is a branch of cryptography that
       enables a group of n members, 1,2, ..., n, to act as a single
       communication party, using one pair of public and private keys
       [Des87,Des94,Des97]. Similar to the traditional public key
@@ -178,7 +178,7 @@ Wang, Huang & Rine	                                   [Page 3]
 INTERNET-DRAFT    					  June 2000
 
 
-      a corresponding key sharing mechanism must be devised.) To 
+      a corresponding key sharing mechanism must be devised.) To
       perform a cryptographic computation (such as decryption, signing,
       identification, etc.) on message m with key K_private, b,
       b <= n , group members will be required. Each member will compute
@@ -186,7 +186,7 @@ INTERNET-DRAFT    					  June 2000
       to produce the final result. The combiner is not necessarily to
       be trusted. Note that during this whole process the shared
       private key, K_private, is never reconstructed.  Further,
-      threshold cryptography requires that the shared private key 
+      threshold cryptography requires that the shared private key
       cannot be reconstructed from any t < b group members.
 
       Practical threshold cryptography for RSA and DSS have been
@@ -219,19 +219,19 @@ INTERNET-DRAFT    					  June 2000
 		  |   Name Server   |
 		  +-----------------+
 
-      In the above proposed architecture, we assume that there exist 
-      (n-1), n >= 2, machines in a given DNS zone that are under the 
-      control of the zone manager, but not under the control of the 
-      name server administrators. These machines are called the 
+      In the above proposed architecture, we assume that there exist
+      (n-1), n >= 2, machines in a given DNS zone that are under the
+      control of the zone manager, but not under the control of the
+      name server administrators. These machines are called the
       zone-security servers.
 
       Using a threshold cryptography scheme with n > t >= 1, the
       zone private key is shared among the (n-1) zone-security servers
       and the primary name server.  To update zone's data dynamically,
       some of the servers will be needed. Let b > t be the number of
-      zone private key shares needed in the computation of the 
+      zone private key shares needed in the computation of the
       signature of an RR. Since b >= 2, any change to the zone data
-      will need the cooperation of at least one zone-security server; 
+      will need the cooperation of at least one zone-security server;
 
 
 Wang, Huang & Rine	                                   [Page 4]
@@ -239,54 +239,54 @@ Wang, Huang & Rine	                                   [Page 4]
 INTERNET-DRAFT    					  June 2000
 
 
-      the name server administrator will have no way to modify the 
+      the name server administrator will have no way to modify the
       digitally signed zone data. Thus, the role separation principle
       holds. Moreover, the above architecture enhances intrusion
       tolerance of DNS.
 
       A DNS system is said to be k-intrusion-tolerant against an
-      entity, E, if breaking into k servers (including the 
-      zone-security servers and the DNS name servers, if applicable) 
-      that are outside E's control will not help E gain any knowledge 
-      of the zone private key. A DNS system is said to be intrusion 
-      tolerant against an outsider (insider) if it is at least 
-      1-intrusion-tolerant against the outsider (insider). The 
-      architecture proposed in this document can be configured to be 
+      entity, E, if breaking into k servers (including the
+      zone-security servers and the DNS name servers, if applicable)
+      that are outside E's control will not help E gain any knowledge
+      of the zone private key. A DNS system is said to be intrusion
+      tolerant against an outsider (insider) if it is at least
+      1-intrusion-tolerant against the outsider (insider). The
+      architecture proposed in this document can be configured to be
       intrusion tolerant against outside and inside attackers.
 
 	 Intrusion tolerance against outsider attacks. In the
 	    architecture, the zone private key cannot be recovered from
-	    any single location, thus, making the system intrusion 
+	    any single location, thus, making the system intrusion
 	    tolerant against an outside attacker. That is, even when an
 	    outside attacker manages to corrupt l, l <= t, of relevant
 	    servers (including the name servers and the zone-security
-	    servers), secrecy of the zone private key is still 
+	    servers), secrecy of the zone private key is still
 	    maintained.
 
 	 Intrusion tolerance against insider attacks.  The presence of
 	    zone security servers and the necessity of their involvement
-	    in signature computations constitute a defense line 
-	    against insider attacks, in particular, attacks from name 
-	    server administrators. Clearly, a hostile name server 
-	    administrator must break into at least t zone security 
-	    servers (to get access to the respective key shares) in 
+	    in signature computations constitute a defense line
+	    against insider attacks, in particular, attacks from name
+	    server administrators. Clearly, a hostile name server
+	    administrator must break into at least t zone security
+	    servers (to get access to the respective key shares) in
 	    order to perform unauthorized RR signature computations.
 
 3 - Implementation Details
 
    [RFC2535] defines two types of SIG records, the DSA SIG and
-   the RSA/MD5 SIG. The important configuration and implementation 
-   aspects of our proposed architecture with respect to these two types 
+   the RSA/MD5 SIG. The important configuration and implementation
+   aspects of our proposed architecture with respect to these two types
    of SIGs are given next.  In the following statement,
    the primary name server will be referred to as server 0 and the
-   (n-1) zone-security servers will be referred to as servers 
+   (n-1) zone-security servers will be referred to as servers
    1, 2, ... , (n-1).
 
    3.1 - Example Configurations
 
-      The following table gives some representative configurations, in 
-      terms of t and n, to achieve the above security levels in 
-      different application cases. 
+      The following table gives some representative configurations, in
+      terms of t and n, to achieve the above security levels in
+      different application cases.
 
 
 Wang, Huang & Rine	                                   [Page 5]
@@ -296,7 +296,7 @@ INTERNET-DRAFT    					  June 2000
 
       +----------------------------+----------------------------+
       |                            | RSA/MD5 SIG |  DSA SIG     |
-      |   SECURITY LEVEL           +-------------+--------------+ 
+      |   SECURITY LEVEL           +-------------+--------------+
       |                            | 1-2 |  2-4  |  1-3  | 2-5  |
       +----------------------------+-----+-------+-------+------+
       |Intrusion tolerant against  |     |       |       |      |
@@ -310,9 +310,9 @@ INTERNET-DRAFT    					  June 2000
 
       Assume that, in RSA, the zone's private key is d and its
       public key is (e, N). Phi(N) is the Euler function of N, i.e.,
-      phi(N) = (p-1)(q-1) where N = p * q. We use the threshold 
+      phi(N) = (p-1)(q-1) where N = p * q. We use the threshold
       digital signature scheme given in [DDB94] and now give
-      how the zone private key is shared and how to generate a 
+      how the zone private key is shared and how to generate a
       RSA/MD5 SIG RR online.
 
       The 1-2 case. In this case, the zone manager generates a random,
@@ -355,11 +355,11 @@ INTERNET-DRAFT    					  June 2000
 
 
 	 To generate a RSA/MD5 SIG, any 3 of the 4 servers will be
-	 needed. For example, if the primary name server and the 
+	 needed. For example, if the primary name server and the
 	 zone-security servers 1 and 2 are present (the (0,1,2) case in
-	 the above table), the three servers will compute m^d1 mod N, 
+	 the above table), the three servers will compute m^d1 mod N,
 	 m^d2 mod N, and m^d3 mod N respectively. After that any one of
-	 them can combine the partial results to produce 
+	 them can combine the partial results to produce
 	 m^d1 * m^d2 * m^d3 mod N = m^d mod N, the digital signature of
 	 m by the zone private key.  Other possibilities of computing
 	 the signature of m are summarized in the above table.
@@ -375,7 +375,7 @@ INTERNET-DRAFT    					  June 2000
 
 5 - Security considerations
 
-   This document proposes an architecture to allow a DNS zone to 
+   This document proposes an architecture to allow a DNS zone to
    provide secure online DNS dynamic update. It uses threshold
    digital signature to maintain the role separation principle and can
    also provide intrusion tolerance against both outside attackers
@@ -393,18 +393,18 @@ INTERNET-DRAFT    					  June 2000
 
 7 - References
 
-   [DDB94]   Y. Desmedt, G. Di Crescenzo, and M. Burmester. 
+   [DDB94]   Y. Desmedt, G. Di Crescenzo, and M. Burmester.
 	     ``Multiplicative nonabelian sharing schemes and their
-	     application to threshold cryptography''. In J. Pieprzyk 
+	     application to threshold cryptography''. In J. Pieprzyk
 	     and R. SafaviNaini, editors, Advances in Cryptology -
-	     Asiacrypt '94, volume 917 of Lecture Notes in Computer 
-	     Science, pages 21--32, Wollongong, Australia, 
-	     November/December 1994. Springer-Verlag. 
+	     Asiacrypt '94, volume 917 of Lecture Notes in Computer
+	     Science, pages 21--32, Wollongong, Australia,
+	     November/December 1994. Springer-Verlag.
 
-   [Des87]   Y. Desmedt. ``Society and group oriented cryptography: 
+   [Des87]   Y. Desmedt. ``Society and group oriented cryptography:
 	     a new concept''. In C. Pomerance, editor, Advances in
-	     Cryptology, Proc. of Crypto '87, volume 293 of Lecture 
-	     Notes in Computer Science, pages 120--127, Santa Barbara, 
+	     Cryptology, Proc. of Crypto '87, volume 293 of Lecture
+	     Notes in Computer Science, pages 120--127, Santa Barbara,
 	     California, U.S.A., August 16--20, 1988. Springer-Verlag.
 
 
@@ -416,55 +416,55 @@ INTERNET-DRAFT    					  June 2000
    [Des94]   Y. Desmedt. ``Threshold cryptography''. European Trans.
              on Telecommunications, 5(4):449--457, July-August 1994.
 
-   [Des97]   Y. Desmedt. ``Some recent research aspects of threshold 
-	     cryptography''. In E. Okamoto, G. Davida, and M. Mambo, 
-	     editors, Information Security, volume 1396 of Lecture 
-	     Notes in Computer Science, pages 158--173, Tatsunokuchi, 
-	     Ishikawa, Japan, September 1997. Springer-Verlag. 
+   [Des97]   Y. Desmedt. ``Some recent research aspects of threshold
+	     cryptography''. In E. Okamoto, G. Davida, and M. Mambo,
+	     editors, Information Security, volume 1396 of Lecture
+	     Notes in Computer Science, pages 158--173, Tatsunokuchi,
+	     Ishikawa, Japan, September 1997. Springer-Verlag.
 
-   [DSA2]    National Institute for Standards and Technology. 
-             ``Digital signature standard (DSS)'', February 2000. 
+   [DSA2]    National Institute for Standards and Technology.
+             ``Digital signature standard (DSS)'', February 2000.
 
-   [GJKR96b] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin. 
+   [GJKR96b] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin.
              ``Robust threshold DSS signatures''. In U. Maurer,
-             editor, Advances in Cryptology - Eurocrypt '96, 
-             volume 1070 of Lecture Notes in Computer Science, 
-             pages 354-371, Zaragoza, Spain, May 12--16 1996. 
-             Springer-Verlag. 
+             editor, Advances in Cryptology - Eurocrypt '96,
+             volume 1070 of Lecture Notes in Computer Science,
+             pages 354-371, Zaragoza, Spain, May 12--16 1996.
+             Springer-Verlag.
 
-   [GMP]     T. Granlund. ``GNU MP''. Source code available from 
-	     http://www.gnu.org/manual/gmp/index.html. 
+   [GMP]     T. Granlund. ``GNU MP''. Source code available from
+	     http://www.gnu.org/manual/gmp/index.html.
 
-   [Liu99]   C. Liu. ``Securing an Internet name server''. 
-             Presentation, 1999. Available at 
+   [Liu99]   C. Liu. ``Securing an Internet name server''.
+             Presentation, 1999. Available at
 	     http://www.acmebw.com/papers/securing.pdf.
 
-   [RFC1034]  P. Mockapetris, ``Domain Names - Concepts and 
+   [RFC1034]  P. Mockapetris, ``Domain Names - Concepts and
 	      Facilities,'' RFC 1034, ISI, November 1987.
 
    [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
 	   Specification,'' RFC 1035, ISI, November 1987.
 
    [RFC2136]  P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
-	      Updates in the Domain Name System,'' RFC 2136, ISC & 
+	      Updates in the Domain Name System,'' RFC 2136, ISC &
 	      Bellcore & Cisco & DEC, April 1997.
 
-   [RFC2137]  D. Eastlake ``Secure Domain Name System Dynamic Update,'' 
+   [RFC2137]  D. Eastlake ``Secure Domain Name System Dynamic Update,''
 	      RFC 2137, CyberCash, April 1997.
 
    [RFC2196] B. Fraser. ``Site Security Handbook,'' RFC2196, September
 	     1997.
 
-   [RFC2535]  D. Eastlake, ``Domain Name System Security Extensions,'' 
+   [RFC2535]  D. Eastlake, ``Domain Name System Security Extensions,''
 	      RFC 2535, IBM, March 1999.
 
-   [SBM99]   R. Sandhu, V. Bhamidipati, and Q. Munawer. ``The ARBAC97 
-	     model for role-based administration of roles''. ACM 
+   [SBM99]   R. Sandhu, V. Bhamidipati, and Q. Munawer. ``The ARBAC97
+	     model for role-based administration of roles''. ACM
 	     Transactions on Information System Security, 2(1):105-
 	     135, February 1999.
 
-   [Sha79]   A. Shamir. ``How to share a secret''. Commun. ACM, 
-             22:612-613, November 1979. 
+   [Sha79]   A. Shamir. ``How to share a secret''. Commun. ACM,
+             22:612-613, November 1979.
 
 
 Wang, Huang & Rine	                                   [Page 8]
@@ -473,7 +473,7 @@ INTERNET-DRAFT    					  June 2000
 
 
 8 - Author's Address
-   
+
    A postscript of this document is available from
 	http://www.cs.gmu.edu/~xwang4/dnssecureonline.ps
 
@@ -489,7 +489,7 @@ INTERNET-DRAFT    					  June 2000
        Fax:   +1-703-993-1710
        EMail: xwang4@cs.gmu.edu
 
-   Yih Huang 
+   Yih Huang
        Department of Computer Science
        George Mason University
        Fairfax, VA 22030-4444
@@ -499,7 +499,7 @@ INTERNET-DRAFT    					  June 2000
        Fax:   +1-703-993-1710
        EMail: hyangyih@cs.gmu.edu
 
-   David Rine 
+   David Rine
        Department of Computer Science
        George Mason University
        Fairfax, VA 22030-4444
@@ -516,12 +516,12 @@ INTERNET-DRAFT    					  June 2000
 
    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, 
+   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 
+   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
 
 
 Wang, Huang & Rine	                                   [Page 9]
diff --git a/doc/man/bin/dig.1 b/doc/man/bin/dig.1
index 98f7d972..b79dbb0b 100644
--- a/doc/man/bin/dig.1
+++ b/doc/man/bin/dig.1
@@ -1,9 +1,9 @@
-.\" Copyright (C) @YEARS@  Internet Software Consortium.
-.\" 
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
 .\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
@@ -12,9 +12,9 @@
 .\" 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: dig.1,v 1.3 2000/09/26 23:41:43 gson Exp $
-.\" 
+
+.\" $Id: dig.1,v 1.6 2000/11/30 00:20:37 gson Exp $
+
 .Dd Jun 30, 2000
 .Dt DIG 1
 .Os BIND9 9
@@ -221,9 +221,9 @@ When using TSIG authentication with
 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
-.Dv key{}
+.Dv key
 and
-.Dv server{}
+.Dv server
 statements in 
 .Pa named.conf .
 .Sh QUERY OPTIONS
@@ -335,7 +335,7 @@ answer.
 .It +[no]comments
 Toggle the display of comment lines in the output.
 The default is to print comments.
-.It +[no]sta
+.It +[no]stats
 This query option toggles the printing of statistics: when the query was
 made, the size of the reply and so on.
 The default behaviour is to print the query statistics.
diff --git a/doc/man/bin/host.1 b/doc/man/bin/host.1
index 87c4190f..ec83b18d 100644
--- a/doc/man/bin/host.1
+++ b/doc/man/bin/host.1
@@ -12,9 +12,9 @@
 .\" 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: host.1,v 1.5 2000/08/22 17:02:49 gson Exp $
-.\"
+
+.\" $Id: host.1,v 1.6 2000/11/18 02:57:26 bwelling Exp $
+
 .Dd Jun 30, 2000
 .Dt HOST 1
 .Os BIND9 9
diff --git a/doc/man/bin/lwresd.8 b/doc/man/bin/lwresd.8
index 742402b4..37ede31c 100644
--- a/doc/man/bin/lwresd.8
+++ b/doc/man/bin/lwresd.8
@@ -12,9 +12,9 @@
 .\" 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: lwresd.8,v 1.4.2.1 2000/08/22 01:10:06 gson Exp $
-.\"
+
+.\" $Id: lwresd.8,v 1.9 2000/11/18 02:57:27 bwelling Exp $
+
 .Dd Jun 30, 2000
 .Dt LWRESD 8
 .Os BIND9 9
@@ -29,10 +29,11 @@
 .Op Fl f g s
 .Op Fl i Ar pid-file
 .Op Fl n Ar #cpus
-.Op Fl P Ar query-port#
+.Op Fl P Ar listen-port#
 .Op Fl p Ar port#
 .Op Fl t Ar directory
 .Op Fl u Ar user-id
+.Op Fl v
 .Sh DESCRIPTION
 .Nm lwresd
 is the daemon providing name lookup services to clients that use
@@ -115,16 +116,16 @@ one thread per CPU.  If
 is unable to determine the number of CPUs, a single worker thread
 is created.
 .It Fl P
-send DNS lookups to port number
-.Ar query-port#
-when querying name servers.
-This provides a way of testing the lightweight resolver daemon with a
-name server that listens for queries on a non-standard port number.
-.It Fl p
 listen for lightweight resolver queries on the loopback interface
 using UDP port
 .Ar port#
 instead of the default port number, 921.
+.It Fl p
+send DNS lookups to port number
+.Ar listen-port#
+when querying name servers.
+This provides a way of testing the lightweight resolver daemon with a
+name server that listens for queries on a non-standard port number.
 .It Fl s
 write memory usage statistics to
 .Dv stdout
@@ -148,6 +149,8 @@ The lightweight resolver daemon will change its user-id after it has
 carried out any privileged operations, such as writing the process-id
 file or binding a socket to a privileged port (typically any port
 less than 1024).
+.It Fl v
+report the version number and exit.
 .El
 .Sh FILES
 .Bl -tag -width  /var/run/lwresd.pid -compact
diff --git a/doc/man/bin/named.8 b/doc/man/bin/named.8
index b229aab0..1b398a29 100644
--- a/doc/man/bin/named.8
+++ b/doc/man/bin/named.8
@@ -12,9 +12,9 @@
 .\" 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: named.8,v 1.3.2.1 2000/08/21 20:41:17 gson Exp $
-.\"
+
+.\" $Id: named.8,v 1.11 2000/11/18 02:57:29 bwelling Exp $
+
 .Dd Jun 30, 2000
 .Dt NAMED 8
 .Os BIND9 9
@@ -31,6 +31,7 @@
 .Op Fl p Ar port#
 .Op Fl t Ar directory
 .Op Fl u Ar user-id
+.Op Fl v
 .Op Fl x Ar cache-file
 .Sh DESCRIPTION
 .Nm named
@@ -52,6 +53,13 @@ use
 .Ar config-file
 as the configuration file instead of the default,
 .Pa /etc/named.conf .
+To ensure that reloading the configuration file continues to 
+work after the server has changed its working directory 
+due to to a possible 
+.Dv directory
+option in the configuration file, 
+.Ar config-file
+should be an absolute pathname.
 .It Fl d
 set the daemon's debug level to
 .Ar debuglevel .
@@ -118,6 +126,8 @@ when
 .Nm named
 is run on 2.3.99-pre3 or later kernel, since previous
 kernels did not allow privileges to be retained after setuid().
+.It Fl v
+report the version number and exit.
 .It Fl x
 load data from
 .Ar cache-file .
diff --git a/doc/man/bin/nsupdate.8 b/doc/man/bin/nsupdate.8
index a7793cf4..ac6a55de 100644
--- a/doc/man/bin/nsupdate.8
+++ b/doc/man/bin/nsupdate.8
@@ -12,9 +12,9 @@
 .\" 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: nsupdate.8,v 1.7 2000/08/15 20:15:49 gson Exp $
-.\"
+
+.\" $Id: nsupdate.8,v 1.11 2000/11/30 00:20:38 gson Exp $
+
 .Dd Jun 30, 2000
 .Dt NSUPDATE 8
 .Os BIND9 9
@@ -30,6 +30,7 @@
 .Fl k Ar keyfile
 .Oc
 .Op Fl v
+.Op filename
 .Sh DESCRIPTION
 .Nm nsupdate
 is used to submit Dynamic DNS Update requests as defined in RFC2136
@@ -71,9 +72,9 @@ Once other algorithms are defined for TSIG, applications will need to
 ensure they select the appropriate algorithm as well as the key when
 authenticating each other.
 For instance suitable
-.Dv key{}
+.Dv key
 and
-.Dv server{}
+.Dv server
 statements would be added to
 .Pa /etc/named.conf
 so that the name server can associate the appropriate secret key
@@ -130,7 +131,9 @@ use a TCP connection.
 This may be preferable when a batch of update requests is made.
 .Sh INPUT FORMAT
 .Nm nsupdate
-reads commands from its standard input.
+reads input from
+.Ar filename
+or standard input.
 Each command is supplied on exactly one line of input.
 Some commands are for administrative purposes.
 The others are either update instructions or prerequisite checks on the
@@ -167,6 +170,18 @@ where the dynamic update requests get sent.
 If no port number is specified, the default DNS port number of 53 is
 used.
 .It Xo
+.Ic local Va address Op port
+.Xc
+.sp 1
+Sends all dynamic update requests using the local
+.Va address .
+When no local statement is provided,
+.Nm nsupdate
+will send updates using an address and port choosen by the system.
+.Va port
+can additionally be used to make requests come from a specific port.
+If no port number is specified, the system will assign one.
+.It Xo
 .Ic zone Va zonename
 .Xc
 .sp 1
diff --git a/doc/man/bin/rndc.8 b/doc/man/bin/rndc.8
index d3cd8e7e..95d8d44f 100644
--- a/doc/man/bin/rndc.8
+++ b/doc/man/bin/rndc.8
@@ -12,9 +12,9 @@
 .\" 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: rndc.8,v 1.6.2.1 2000/08/22 01:10:07 gson Exp $
-.\"
+
+.\" $Id: rndc.8,v 1.11 2000/11/30 00:20:39 gson Exp $
+
 .Dd Jun 30, 2000
 .Dt RDNC 8
 .Os BIND9 9
@@ -69,7 +69,7 @@ option can be used to specify an alternate configuration file.
 .Pp
 .Ar server
 is the name or address of the server which matches a
-.Dv server{}
+.Dv server
 statement in the configuration file for
 .Nm rndc .
 If no
@@ -77,7 +77,7 @@ If no
 is supplied on the command line, the host named by the
 .Dv default-server
 clause in the
-.Dv options{}
+.Dv option
 statement of the configuration file will be used.
 .Pp
 The
@@ -106,13 +106,13 @@ option is provided,
 will first look for a
 .Dv key
 clause in the
-.Dv server{}
+.Dv server
 statement of the server being used, or if no
-.Dv server{}
+.Dv server
 statement is present for that host, then the
 .Dv default-key
 clause of the
-.Dv options{}
+.Dv options
 statement.
 Note that the configuration file for
 .Nm rdnc
@@ -129,22 +129,14 @@ options provided debugging information and are primarily of interest
 only to the BIND 9 developers.
 They might be changed or removed in future releases.
 .Pp
-The only valid value for
-.Ar command
-is \*qreload\*q, which forces the name server to reload its configuation
-file and zones.
-Further commands will be provided in future releases as the management
-capabilities of
+For the complete set of commands supported by rndc, see the
+BIND 9 Administrator Reference Manual or run
 .Nm rndc
-are extended.
+without arguments to see its help message.
+.Pp
 .Sh LIMITATIONS
 .Nm rndc
-currently only supports the
-.Dv reload
-command.
-Future releases will provide more commands so that
-.Nm rndc
-offers at least as many management capabilities as the old
+does not yet support all the commands of the BIND 8
 .Xr ndc
 utility.
 .Pp
diff --git a/doc/man/bin/rndc.conf.5 b/doc/man/bin/rndc.conf.5
index f3cf7bcd..9db04908 100644
--- a/doc/man/bin/rndc.conf.5
+++ b/doc/man/bin/rndc.conf.5
@@ -12,9 +12,9 @@
 .\" 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: rndc.conf.5,v 1.4.2.1 2000/08/22 01:10:08 gson Exp $
-.\"
+
+.\" $Id: rndc.conf.5,v 1.8 2000/11/30 00:20:40 gson Exp $
+
 .Dd Jun 30, 2000
 .Dt RDNC.CONF 5
 .Os BIND9 9
@@ -45,15 +45,15 @@ The usual comment styles are supported:
 is much simpler than
 .Pa named.conf .
 The file uses three statements: an
-.Dv options{}
+.Dv options
 statement, a
-.Dv server{}
+.Dv server
 statement and a
-.Dv key{}
+.Dv key
 statement.
 .Pp
 The
-.Dv options{}
+.Dv options
 statement contains two clauses.
 The
 .Dv default-server
@@ -66,7 +66,7 @@ The
 .Dv default-key
 clause
 is followed by the name of a key which is identified by a
-.Dv key{}
+.Dv key
 statement.
 If no
 .Fl y
@@ -75,24 +75,24 @@ option is provided on the
 command line, and no
 .Dv key
 clause is found in a a matching
-.Dv server{}
+.Dv server
 statement, this default key will be used to authenticate the server's
 commands and responses.
 .Pp
 After the keyword
 .Dv server ,
 the
-.Dv server{}
+.Dv server
 statement is followed by a string which is the hostname or address for a
 name server.
 The statement has a single clause,
 .Dv key .
 The key name must match the name of a
-.Dv key{}
+.Dv key
 statement in the file.
 .Pp
 The
-.Dv key{}
+.Dv key
 statement begins with an identifying string, the name of the key.
 The statement has two clauses.
 .Dv algorithm
@@ -147,7 +147,7 @@ Commands to the localhost server will use the
 .Dv samplekey
 key.
 The
-.Dv key{}
+.Dv key
 statement indicates that
 .Dv samplekey
 uses the HMAC-MD5 algorithm and its
@@ -170,7 +170,7 @@ placed in the
 .Nm rndc.conf
 and
 .Xr named.conf
-.Dv key{}
+.Dv key
 statements, the
 .Pa .key
 and
@@ -188,11 +188,11 @@ There is currently no way to specify the port for
 to use.  This will be remedied in future releases by allowing a
 .Dv port
 clause to the
-.Dv server{}
+.Dv server
 statement and a
 .Dv default-port
 clause to the
-.Dv options{}
+.Dv options
 statement.
 .Sh SEE ALSO
 .Xr rndc 8 ,
diff --git a/doc/man/dnssec/dnssec-keygen.8 b/doc/man/dnssec/dnssec-keygen.8
index db60d5a5..e625f23d 100644
--- a/doc/man/dnssec/dnssec-keygen.8
+++ b/doc/man/dnssec/dnssec-keygen.8
@@ -1,7 +1,6 @@
-.\"
 .\" Copyright (C) 2000  Internet Software Consortium.
 .\"
-.\" Permission to use, copy, modify, and distribute this document for any
+.\" 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.
 .\"
@@ -13,9 +12,9 @@
 .\" 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: dnssec-keygen.8,v 1.5.2.1 2000/11/10 18:05:54 gson Exp $
-.\"
+
+.\" $Id: dnssec-keygen.8,v 1.11 2000/11/18 02:57:34 bwelling Exp $
+
 .Dd Jun 30, 2000
 .Dt DNSSEC-KEYGEN 8
 .Os BIND9 9
@@ -27,6 +26,7 @@
 .Nm dnssec-keygen
 .Fl a Ar algorithm
 .Fl b Ar keysize
+.Op Fl c Ar class
 .Op Fl e
 .Op Fl g Ar generator
 .Op Fl h
@@ -85,7 +85,7 @@ argument following the
 .Fl b
 option.
 The choice of key size depends on the algorithm that is used.
-RSA keys must be between 512 and 2000 bits.
+RSA keys must be between 512 and 2048 bits.
 Diffie-Hellman keys must be between 128 and 4096 bits.
 For DSA, the key size must be between 512 and 1024 bits and a multiple
 of 64.
@@ -97,7 +97,7 @@ option specifies how the generated key will be used.
 .Ar nametype
 can be either
 .Dv ZONE ,
-.Dv HOST , 
+.Dv HOST ,
 .Dv ENTITY ,
 or
 .Dv USER
@@ -112,6 +112,11 @@ are identical.
 is case-insensitive.
 .Pp
 The
+.Fl c
+option specifies that the when creating a KEY record, the specified class
+should be used instead of IN.
+.Pp
+The
 .Fl e
 option can only be used when generating RSA keys.
 It tells
@@ -125,7 +130,7 @@ that is to be used.
 The only supported values value of
 .Ar generator
 are 2 and 5.
-If no Diffie-Hellman generator is supplied, a known prime 
+If no Diffie-Hellman generator is supplied, a known prime
 from RFC2539 will be used if possible; otherwise 2 will be used as the
 generator.
 .Pp
@@ -134,7 +139,7 @@ The
 option sets the protocol value for the generated key to
 .Ar protocol-value .
 The default is 2 (email) for keys of type
-.Dv USER 
+.Dv USER
 and 3 (DNSSEC) for all other key types.
 Other possible values for this argument are listed in RFC2535 and its
 successors.
@@ -150,7 +155,7 @@ will prompt for keyboard input and use the time intervals between
 keystrokes to provide randomness.
 The
 .Fl r
-option overrides this behaviour, making 
+option overrides this behaviour, making
 .Nm dnssec-keygen
 use
 .Ar randomdev
@@ -174,16 +179,16 @@ confidentiality.
 can be one of
 .Dv AUTHCONF ,
 .Dv NOAUTHCONF ,
-.Dv NOAUTH 
+.Dv NOAUTH
 or
 .Dv NOCONF .
 The default is
 .Dv AUTHCONF .
 If type is
-.Dv AUTHCONF 
+.Dv AUTHCONF
 the key can be used for authentication and confidentialty.
 Setting
-.Ar type 
+.Ar type
 to
 .Dv NOAUTHCONF
 indicates that the key cannot be used for authentication or confidentialty.
@@ -196,14 +201,14 @@ Similarly,
 defines that the key cannot be used for confidentiality though it can
 be used for authentication.
 .Pp
-The 
+The
 .Fl v
 option can be used to make
 .Nm dnssec-keygen
 more verbose.
 As the debugging/tracing level
 .Ar level
-increases, 
+increases,
 .Nm dnssec-keygen
 generates increasingly detailed reports about what it is doing.
 The default level is zero.
@@ -246,7 +251,7 @@ key(s) for generating or validating signatures.
 The
 .Ar .key
 file contains a KEY resource record that can be inserted into a zone file
-with a 
+with a
 .Dv $INCLUDE
 statement.
 The private part of the key is in the
@@ -260,7 +265,7 @@ The private part of the key is used by
 .Xr dnssec-signzone 8
 to generate signatures and the public part is used to verify the
 signatures.
-Both 
+Both
 .Ar .key
 and
 .Ar .private
@@ -279,13 +284,13 @@ has printed the key identification string
 .Dv Kexample.com.+003+26160 ,
 indicating a DSA key with identifier 26160.
 It will also have created the files
-.Pa Kexample.com.+003+26160.key 
+.Pa Kexample.com.+003+26160.key
 and
 .Pa Kexample.com.+003+26160.private
 containing respectively the public and private keys for the generated
 DSA key.
 .Sh FILES
-.Pa /dev/random 
+.Pa /dev/random
 .Sh SEE ALSO
 .Xr RFC2535,
 .Xr RFC2845,
@@ -297,7 +302,7 @@ DSA key.
 The naming convention for the public and private key files is a little
 clumsy.
 It won't work for domain names that are longer than 236 characters
-because of the 
+because of the
 .Ar .+aaa+iiiii.private
 suffix results in filenames that are too long for most
 .Ux
diff --git a/doc/man/dnssec/dnssec-makekeyset.8 b/doc/man/dnssec/dnssec-makekeyset.8
index f6fd33df..dcb229c6 100644
--- a/doc/man/dnssec/dnssec-makekeyset.8
+++ b/doc/man/dnssec/dnssec-makekeyset.8
@@ -1,7 +1,6 @@
-.\"
 .\" Copyright (C) 2000  Internet Software Consortium.
 .\"
-.\" Permission to use, copy, modify, and distribute this document for any
+.\" 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.
 .\"
@@ -13,9 +12,9 @@
 .\" 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: dnssec-makekeyset.8,v 1.4.2.1 2000/08/02 22:10:10 gson Exp $
-.\"
+
+.\" $Id: dnssec-makekeyset.8,v 1.9 2000/11/18 02:57:35 bwelling Exp $
+
 .Dd Jun 30, 2000
 .Dt DNSSEC-MAKEKEYSET 8
 .Os BIND9 9
@@ -71,7 +70,7 @@ A relative start time is supplied when
 .Ar start-time
 is given as +N: N seconds from the current time.
 If no
-.Fl s 
+.Fl s
 option is supplied, the current date and time is used for the start
 time of the SIG records.
 .Pp
@@ -146,7 +145,7 @@ As the debugging/tracing level
 increases,
 .Nm dnssec-makekeyset
 generates increasingly detailed reports about what it is doing.
-The default level is zero. 
+The default level is zero.
 .Pp
 The
 .Fl h
@@ -157,14 +156,14 @@ to print a short summary of its options and arguments.
 If
 .Nm dnssec-makekeyset
 is successful, it creates a file name of the form
-.Ar nnnn.keyset .
+.Ar keyset-nnnn. .
 This file contains the KEY and SIG records for domain
 .Dv nnnn ,
 the domain name part from the key file identifier produced when
 .Nm dnssec-keygen
 created the domain's public and private keys.
 The
-.Ar .keyset
+.Ar keyset
 file can then be transferred to the DNS administrator of the parent
 zone for them to sign the contents with
 .Xr dnssec-signkey 8 .
@@ -178,13 +177,13 @@ The backslash is for typographic reasons and would not be provided on
 the command line when running
 .Nm dnssec-makekeyset .
 .nf
-.Dl # dnssec-makekeyset -t 86400 -s 20000701120000 \e\p 
+.Dl # dnssec-makekeyset -t 86400 -s 20000701120000 \e\p
 .Dl -e +2592000 Kexample.com.+003+26160
 .fi
 .Pp
 .Nm dnssec-makekeyset
 will create a file called
-.Pa example.com.keyset
+.Pa keyset-example.com.
 containing a SIG and KEY record for
 .Dv example.com.
 These records will have a TTL of 86400 seconds (1 day).
@@ -194,12 +193,12 @@ The SIG record becomes valid at noon UTC on July 1st 2000 and expires
 The DNS administrator for
 .Dv example.com
 could then send
-.Pa example.com.keyset
+.Pa keyset-example.com.
 to the DNS administrator for
 .Dv .com
 so that they could sign the resource records in the file.
 This assumes that the
-.Dv .com 
+.Dv .com
 zone is DNSSEC-aware and the administrators of the two zones have some
 mechanism for authenticating each other and exchanging the keys and
 signatures securely.
diff --git a/doc/man/dnssec/dnssec-signkey.8 b/doc/man/dnssec/dnssec-signkey.8
index 927abd36..415299a3 100644
--- a/doc/man/dnssec/dnssec-signkey.8
+++ b/doc/man/dnssec/dnssec-signkey.8
@@ -1,7 +1,6 @@
-.\"
 .\" Copyright (C) 2000  Internet Software Consortium.
 .\"
-.\" Permission to use, copy, modify, and distribute this document for any
+.\" 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.
 .\"
@@ -13,9 +12,9 @@
 .\" 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: dnssec-signkey.8,v 1.5.2.1 2000/08/02 22:10:12 gson Exp $
-.\"
+
+.\" $Id: dnssec-signkey.8,v 1.11 2000/11/18 02:57:37 bwelling Exp $
+
 .Dd Jun 30, 2000
 .Dt DNSSEC-SIGNKEY 8
 .Os BIND9 9
@@ -26,6 +25,9 @@
 .Sh SYNOPSIS
 .Nm dnssec-signkey
 .Op Fl h
+.Op Fl s Ar start-time
+.Op Fl e Ar end-time
+.Op Fl c Ar class
 .Op Fl p
 .Op Fl r Ar randomdev
 .Op Fl v Ar level
@@ -34,8 +36,8 @@
 .Sh DESCRIPTION
 .Nm dnssec-signkey
 is used to sign a key set for a child zone.
-Typically this would be provided by a 
-.Ar .keyset
+Typically this would be provided by a
+.Ar keyset
 file generated by
 .Xr dnssec-makekeyset 8 .
 This provides a mechanism for a DNSSEC-aware zone to sign the keys of
@@ -44,14 +46,14 @@ The child zone's key set gets signed with the zone keys for its parent
 zone.
 .Ar keyset
 will be the pathname of the child zone's
-.Ar .keyset
+.Ar keyset
 file.
 Each
 .Ar keyfile
 argument will be a key identification string as reported by
 .Xr dnssec-keygen 8
 for the parent zone.
-This allows the child's keys to be signed by more than one 
+This allows the child's keys to be signed by more than one
 parent zone key.
 .Pp
 The
@@ -61,6 +63,53 @@ option makes
 print a short summary of its command line options
 and arguments.
 .Pp
+By default, the validity period of the generated SIG records is copied
+from that of the signatures in the input key set.  This may be overriden
+with the
+.Fl s
+and
+.Fl e
+options, both of which must be present if either is.
+The start of the validity period is specified with the
+.Fl s
+option.
+.Ar start-time
+can either be an absolute or relative date.
+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 supplied when
+.Ar start-time
+is given as +N: N seconds from the current time.
+If no
+.Fl s
+option is supplied, the current date and time is used for the start
+time of the SIG records.
+.Pp
+The expiry date for the SIG records can be set by the
+.Fl e
+option.
+Note that in this context, the expiry date specifies when the SIG
+records are no longer valid, not when they are deleted from caches on name
+servers.
+.Ar end-date
+also represents an absolute or relative date.
+YYYYMMDDHHMMSS notation is used as before to indicate an absolute date
+and time.
+When
+.Ar end-date
+is +N,
+it indicates that the SIG records will expire in N seconds after their
+start date.
+If
+.Ar end-date
+is written as now+N,
+the SIG records will expire in N seconds after the current time.
+.Pp
+The
+.Fl c
+option specifies that the KEY records in the input and output key sets should
+have the specified class instead of IN.
+.Pp
 .Nm dnssec-signkey
 may need random numbers in the process of generating keys.
 If the system does not have a
@@ -104,7 +153,7 @@ The default level is zero.
 When
 .Nm dnssec-signkey
 completes successfully, it generates a file called
-.Ar nnnn.signedkey
+.Ar signedkey-nnnn.
 containing the signed keys for child zone
 .Ar nnnn .
 The keys from the
@@ -127,13 +176,13 @@ The DNS administrator for a DNSSEC-aware
 zone would use the following command to make
 .Nm dnssec-signkey
 sign the
-.Ar .keyset
+.Ar keyset
 file for
 .Dv example.com
 created in the example shown in the man page for
 .Xr dnssec-makekeyset 8 :
 .Pp
-.Dl # dnssec-signkey example.com.keyset Kcom.+003+51944
+.Dl # dnssec-signkey keyset-example.com. Kcom.+003+51944
 .Pp
 where
 .Dv Kcom.+003+51944
@@ -145,7 +194,7 @@ zone.
 .Pp
 .Nm dnssec-signkey
 will produce a file called
-.Dv example.com.signedkey
+.Dv signedkey-example.com.
 which has the keys for
 .Dv example.com
 signed by the
diff --git a/doc/man/dnssec/dnssec-signzone.8 b/doc/man/dnssec/dnssec-signzone.8
index 5928f221..aae32ea1 100644
--- a/doc/man/dnssec/dnssec-signzone.8
+++ b/doc/man/dnssec/dnssec-signzone.8
@@ -1,7 +1,6 @@
-.\"
 .\" Copyright (C) 2000  Internet Software Consortium.
 .\"
-.\" Permission to use, copy, modify, and distribute this document for any
+.\" 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.
 .\"
@@ -13,9 +12,9 @@
 .\" 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: dnssec-signzone.8,v 1.7.2.1 2000/08/02 22:10:13 gson Exp $
-.\"
+
+.\" $Id: dnssec-signzone.8,v 1.15 2000/11/18 02:57:38 bwelling Exp $
+
 .Dd Jun 30, 2000
 .Dt DNSSEC-SIGNZONE 8
 .Os BIND9 9
@@ -26,13 +25,16 @@
 .Sh SYNOPSIS
 .Nm dnssec-signzone
 .Op Fl a
-.Op Fl c Ar cycle-time
+.Op Fl c Ar class
+.Op Fl d Ar directory
 .Op Fl s Ar start-time
 .Op Fl e Ar end-time
+.Op Fl i Ar interval
 .Op Fl o Ar origin
 .Op Fl f Ar output-file
 .Op Fl p
 .Op Fl r Ar randomdev
+.Op Fl t
 .Op Fl v Ar level
 .Ar zonefile
 .Op keyfile ....
@@ -41,7 +43,7 @@
 .Nm dnssec-signzone
 is used to sign a zone.
 Any
-.Ar .signedkey
+.Ar signedkey
 files for the zone to be signed should be present in the current
 directory, along with the keys that will be used to sign the zone.
 If no
@@ -58,7 +60,7 @@ Each
 argument would be an identification string for a key created with
 .Xr dnssec-keygen 8 .
 If the zone to be signed has any secure subzones, the
-.Ar .signedkey
+.Ar signedkey
 files for those subzones need to be available in the
 current working directory used by
 .Nm dnssec-signzone .
@@ -78,7 +80,7 @@ If there is a
 .Ar signedkey
 file from the zone's parent, the parent's signatures will be
 incorporated into the generated signed zone file.
-The security status of delegations from the the signed zone 
+The security status of delegations from the the signed zone
 - i.e. whether the child zones are DNSSEC-aware or not - is
 set according to the presence or absence of a
 .Ar signedkey
@@ -113,7 +115,7 @@ A relative start time is supplied when
 .Ar start-time
 is given as +N: N seconds from the current time.
 If no
-.Fl s 
+.Fl s
 option is supplied, the current date and time is used for the start
 time of the SIG records.
 .Pp
@@ -145,22 +147,22 @@ When a previously signed zone is passed as input to
 .Nm dnssec-signzone ,
 records may be resigned.  Whether or not to resign records is configurable
 by using the
-.Fl c
-option, which specifies the cycle period as an offset from the current time
-(in seconds).  If a SIG record expires after the cycle period, it is retained.
-Otherwise, it is considered to be expiring soon, and
+.Fl i
+option, which specifies the cycle interval as an offset from the current time
+(in seconds).  If a SIG record expires after the cycle interval, it is
+retained.  Otherwise, it is considered to be expiring soon, and
 .Nm dnssec-signzone
 will remove it and generate a new SIG record to replace it.
 .Pp
-The default cycle period is one quarter of the difference between the
-specified signature end and start dates.  So if the 
+The default cycle interval is one quarter of the difference between the
+specified signature end and start dates.  So if the
 .Fl e
-and 
+and
 .Fl s
 options are not specified,
 .Nm dnssec-signzone
 generates signatures that are valid for 30 days from the current date
-by default, with a cycle period of 7.5 days.  Therefore, if any SIG records
+by default, with a cycle interval of 7.5 days.  Therefore, if any SIG records
 are due to expire in less than 7.5 days, they would be replaced
 with new ones.
 .Pp
@@ -183,14 +185,29 @@ as a source of random data.
 The
 .Fl p
 option instructs
-.Nm dnssec-signkey
+.Nm dnssec-signzone
 to use pseudo-random data when signing the keys.  This is faster, but
 less secure, than using genuinely random data for signing.
-This option may be useful when there are many child zone keysets to
-sign or if the entropy source is limited.
-It could also be used for short-lived keys and signatures that don't
-require as much protection against cryptanalysis, such as when the key
-will be discarded long before it could be compromised.
+This option may be useful when signing large zones or when the
+entropy source is limited.
+.Pp
+The
+.Fl t
+option causes
+.Nm dnssec-signzone
+to print various statistics after signing the zone.
+.Pp
+The
+.Fl c
+option specifies that the KEY records in the input and output key sets should
+have the specified class instead of IN.
+.Pp
+The
+.Fl d
+option specifies that
+.Nm dnssec-signzone
+should look in a directory other than the current directory for signedkey
+files.
 .Pp
 An option of
 .Fl h
@@ -223,18 +240,14 @@ The zone file for this zone is
 which is the same as the origin, so there is no need to use the
 .Fl o
 option to set the origin.
-This zone file contains the keyset for
-.Dv example.com
-that was created by
-.Xr dnssec-makekeyset 8 .
 The zone's keys were either appended to the zone file or
-incorporated using a 
-.Dv $INCLUDE 
+incorporated using a
+.Dv $INCLUDE
 statement.
 If there was a
-.Ar .signedkey
-file from the parent zone - i.e. 
-.Dv example.com.signedkey 
+.Ar signedkey
+file from the parent zone - i.e.
+.Dv signedkey-example.com.
 - it should be present in the current directory.
 This allows the parent zone's signature to be included in the signed
 version of the
@@ -259,5 +272,4 @@ so that it can be loaded by the name server.
 .Sh SEE ALSO
 .Xr RFC2535,
 .Xr dnssec-keygen 8 ,
-.Xr dnssec-makekeyset 8 ,
 .Xr dnssec-signkey 8 .
diff --git a/doc/man/lwres/lwres.3 b/doc/man/lwres/lwres.3
new file mode 100644
index 00000000..46cc6ab4
--- /dev/null
+++ b/doc/man/lwres/lwres.3
@@ -0,0 +1,151 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres.3,v 1.8 2000/12/04 18:37:35 gson Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres
+.Nd introduction to the lightweight resolver library
+.Sh SYNOPSIS
+.Fd #include <lwres/lwres.h>
+.Sh DESCRIPTION
+The BIND 9 lightweight resolver library is a simple, name service
+independent stub resolver library.  It provides hostname-to-address
+and address-to-hostname lookup services to applications by
+transmitting lookup requests to a resolver daemon
+.Nm lwresd
+running on the local host. The resover daemon performs the
+lookup using the DNS or possibly other name service protocols,
+and returns the results to the application through the library.  
+The library and resolver daemon communicate using a simple
+UDP-based protocol.
+.Pp
+.Sh OVERVIEW
+The lwresd library implements multiple name service APIs.
+The standard
+.Fn gethostbyname ,
+.Fn gethostbyaddr ,
+.Fn gethostbyname_r ,
+.Fn gethostbyaddr_r ,
+.Fn getaddrinfo ,
+.Fn getipnodebyname ,
+and
+.Fn getipnodebyaddr
+functions are all supported.  To allow the lwres library to coexist
+with system libraries that define functions of the same name, 
+the library defines these functions with names prefixed by
+.Va lwres_ .
+To define the standard names, applications must include the
+header file
+.Fd <lwres/netdb.h>
+which contains macro definitions mapping the standard function names
+into
+.Va lwres_
+prefixed ones.  Operating system vendors who integrate the lwres
+library into their base distributions should rename the functions
+in the library proper so that the renaming macros are not needed.
+.Pp
+The library also provides a native API consisting of the functions
+.Fn lwres_getaddrsbyname
+and
+.Fn lwres_getnamebyaddr .
+These may be called by applications that require more detailed
+control over the lookup process than the standard functions
+provide.
+.Pp
+In addition to these name service independent address lookup
+functions, the library implements a new, experimental API
+for looking up arbitrary DNS resource records, using the
+.Fn lwres_getaddrsbyname
+function.
+.Pp
+Finally, there is a low-level API for converting lookup
+requests and responses to and from raw lwres protocol packets.  
+This API can be used by clients requiring nonblocking operation, 
+and is also used when implementing the server side of the lwres
+protocol, for example in the
+.Nm lwresd
+resolver daemon.  The use of this low-level API in clients
+and servers is outlined in the following sections.
+.P
+.Sh CLIENT-SIDE LOW-LEVEL API CALL FLOW
+When a client program wishes to make an lwres request using the
+native low-level API, it typically performs the following 
+sequence of actions.
+.Pp
+(1) Allocate or use an existing lwres_packet_t, called "pkt" below.
+.Pp
+(2) Set pkt.recvlength to the maximum length we will accept.  
+This is done so the receiver of our packets knows how large our receive 
+buffer is.  The "default" is a constant in lwres.h: LWRES_RECVLENGTH = 4096.
+.Pp
+(3) Set the pkt.serial to a unique serial number.  This value is echoed
+back to the application by the remote server.
+.Pp
+(4) Set pkt.pktflags.  Usually this is set to 0.
+.Pp
+(5) Set pkt.result to 0.
+.Pp
+(6) Call lwres_*request_render, or marshall in the data using the primitives
+such as lwres_packet_render() and storing the packet data.
+.Pp
+(7) Transmit the resulting buffer.
+.Pp
+(8) Call lwres_*response_parse() to parse any packets received.
+.Pp
+(9) Verify that the opcode and serial match a request, and process the
+packet specific information contained in the body.
+.Sh SERVER-SIDE LOW-LEVEL API CALL FLOW
+When implementing the server side of the lightweight resolver
+protocol using the lwres library, a sequence of actions like the
+following is typically involved in processing each request packet.
+.Pp
+Note that the same lwres_packet_t is used
+in both the _parse() and _render() calls, with only a few modifications made
+to the packet header's contents between uses.  This method is recommended
+as it keeps the serial, opcode, and other fields correct.
+.Pp
+(1) When a packet is received, call lwres_*request_parse() to
+unmarshall it.  This returns a lwres_packet_t (also called pkt, below)
+as well as a data specific type, such as lwres_gabnrequest_t.
+.Pp
+(2) Process the request in the data specific type.
+.Pp
+(3) Set the pkt.result, pkt.recvlength as above.  All other fields can
+be left untouched since they were filled in by the *_parse() call
+above.  If using lwres_*response_render(), pkt.pktflags will be set up
+properly.  Otherwise, the LWRES_LWPACKETFLAG_RESPONSE bit should be
+set.
+.Pp
+(4) Call the data specific rendering function, such as
+lwres_gabnresponse_render().
+.Pp
+(5) Send the resulting packet to the client.
+.Pp
+.Sh SEE ALSO
+.Xr lwres_gethostent 3 ,
+.Xr lwres_getipnode 3 ,
+.Xr lwres_getnameinfo 3 ,
+.Xr lwres_noop 3 ,
+.Xr lwres_gabn 3 ,
+.Xr lwres_gnba 3 ,
+.Xr lwres_context 3 ,
+.Xr lwres_config 3 ,
+.Xr resolver 5 ,
+.Xr lwresd 8 .
diff --git a/doc/man/lwres/lwres_addr_parse.3 b/doc/man/lwres/lwres_addr_parse.3
new file mode 100644
index 00000000..960fade4
--- /dev/null
+++ b/doc/man/lwres/lwres_addr_parse.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_addr_parse.3,v 1.4 2000/11/18 02:59:13 bwelling Exp $
+
+.so lwres_resutil.3
diff --git a/doc/man/lwres/lwres_buffer.3 b/doc/man/lwres/lwres_buffer.3
new file mode 100644
index 00000000..d5b9f1b4
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer.3
@@ -0,0 +1,294 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer.3,v 1.5 2000/11/18 02:59:15 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_BUFFER 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_buffer_init ,
+.Nm lwres_buffer_invalidate ,
+.Nm lwres_buffer_add ,
+.Nm lwres_buffer_subtract ,
+.Nm lwres_buffer_clear ,
+.Nm lwres_buffer_first ,
+.Nm lwres_buffer_forward ,
+.Nm lwres_buffer_back ,
+.Nm lwres_buffer_getuint8 ,
+.Nm lwres_buffer_putuint8 ,
+.Nm lwres_buffer_getuint16 ,
+.Nm lwres_buffer_putuint16 ,
+.Nm lwres_buffer_getuint32 ,
+.Nm lwres_buffer_putuint32 ,
+.Nm lwres_buffer_putmem ,
+.Nm lwres_buffer_getmem
+.Nd lightweight resolver buffer management
+.Sh SYNOPSIS
+.Fd #include <lwres/lwbuffer.h>
+.Fd
+.Ft void
+.Fo lwres_buffer_init
+.Fa "lwres_buffer_t *b"
+.Fa "void *base"
+.Fa "unsigned int length"
+.Fc
+.Ft void
+.Fo lwres_buffer_invalidate
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft void
+.Fo lwres_buffer_add
+.Fa "lwres_buffer_t *b"
+.Fa "unsigned int n"
+.Fc
+.Ft void
+.Fo lwres_buffer_subtract
+.Fa "lwres_buffer_t *b"
+.Fa "unsigned int n"
+.Fc
+.Ft void
+.Fo lwres_buffer_clear
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft void
+.Fo lwres_buffer_first
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft void
+.Fo lwres_buffer_forward
+.Fa "lwres_buffer_t *b"
+.Fa "unsigned int n"
+.Fc
+.Ft void
+.Fo lwres_buffer_back
+.Fa "lwres_buffer_t *b"
+.Fa "unsigned int n"
+.Fc
+.Ft lwres_uint8_t
+.Fo lwres_buffer_getuint8
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft void
+.Fo lwres_buffer_putuint8
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_uint8_t val"
+.Fc
+.Ft lwres_uint16_t
+.Fo lwres_buffer_getuint16
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft void
+.Fo lwres_buffer_putuint16
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_uint16_t val"
+.Fc
+.Ft lwres_uint32_t
+.Fo lwres_buffer_getuint32
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft void
+.Fo lwres_buffer_putuint32
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_uint32_t val"
+.Fc
+.Ft void
+.Fo lwres_buffer_putmem
+.Fa "lwres_buffer_t *b"
+.Fa "const unsigned char *base"
+.Fa "unsigned int length"
+.Fc
+.Ft void
+.Fo lwres_buffer_getmem
+.Fa "lwres_buffer_t *b"
+.Fa "unsigned char *base"
+.Fa "unsigned int length"
+.Fc
+.Sh DESCRIPTION
+
+
+These functions provide bounds checked access to a region of memory
+where data is being read or written.
+They are based on, and similar to, the
+.Va isc_buffer_
+functions in the ISC library.
+.Pp
+A buffer is a region of memory, together with a set of related
+subregions.
+The \*qused region\*q and the \*qavailable\*q region are disjoint, and
+their union is the buffer's region.
+The used region extends from the beginning of the buffer region to the
+last used byte.
+The available region extends from one byte greater than the last used
+byte to the end of the  buffer's region.
+The size of the used region can be changed using various
+buffer commands.
+Initially, the used region is empty.
+.Pp
+The used region is further subdivided into two disjoint regions: the
+\*qconsumed region\*q and the \*qremaining region\*q.
+The union of these two regions is the used region.
+The consumed region extends from the beginning of the used region to
+the byte before the \*qcurrent\*q offset (if any).
+The \*qremaining\*q region the current pointer to the end of the used
+region.
+The size of the consumed region can be changed using various
+buffer commands.
+Initially, the consumed region is empty.
+.Pp
+The \*qactive region\*q is an (optional) subregion of the remaining
+region.
+It extends from the current offset to an offset in the
+remaining region.
+Initially, the active region is empty.
+If the current offset advances beyond the chosen offset,
+the active region will also be empty.
+.Pp
+.Bd -literal -offset indent
+ 
+   /------------entire length---------------\\
+   /----- used region -----\\/-- available --\\
+   +----------------------------------------+
+   | consumed  | remaining |                |
+   +----------------------------------------+
+   a           b     c     d                e
+ 
+  a == base of buffer.
+  b == current pointer.  Can be anywhere between a and d.
+  c == active pointer.  Meaningful between b and d.
+  d == used pointer.
+  e == length of buffer.
+ 
+  a-e == entire length of buffer.
+  a-d == used region.
+  a-b == consumed region.
+  b-d == remaining region.
+  b-c == optional active region.
+.Ed
+.Pp
+.Fn lwres_buffer_init
+initializes the
+.Dv lwres_buffer_t
+.Fa *b
+and assocates it with the memory region of size
+.Fa length
+bytes starting at location
+.Fa base.
+.Pp
+.Fn lwres_buffer_invalidate
+marks the buffer
+.Fa *b 
+as invalid.  Invalidating a buffer after use is not required,
+but makes it possible to catch its possible accidental use.
+.Pp
+The functions
+.Fn lwres_buffer_add
+and
+.Fn lwres_buffer_subtract
+respectively increase and decrease the used space in
+buffer
+.Fa *b
+by
+.Fa n
+bytes.
+.Fn lwres_buffer_add
+checks for buffer overflow and
+.Fn lwres_buffer_subtract
+checks for underflow.
+These functions do not allocate or deallocate memory.
+They just change the value of
+.Li used .
+.Pp
+A buffer is re-initialised by
+.Fn lwres_buffer_clear .
+The function sets
+.Li used ,
+.Li current
+and
+.Li active
+to zero.
+.Pp
+.Fn lwres_buffer_first
+makes the consumed region of buffer
+.Fa *p
+empty by setting
+.Li current
+to zero (the start of the buffer).
+.Pp
+.Fn lwres_buffer_forward 
+increases the consumed region of buffer
+.Fa *b
+by
+.Fa n
+bytes, checking for overflow.
+Similarly,
+.Fn lwres_buffer_back
+decreases buffer
+.Fa b 's
+consumed region by
+.Fa n
+bytes and checks for underflow.
+.Pp
+.Fn lwres_buffer_getuint8
+reads an unsigned 8-bit integer from
+.Fa *b
+and returns it.
+.Fn lwres_buffer_putuint8
+writes the unsigned 8-bit integer
+.Fa val
+to buffer
+.Fa *b .
+.Pp
+.Fn lwres_buffer_getuint16
+and
+.Fn lwres_buffer_getuint32
+are identical to
+.Fn lwres_buffer_putuint8
+except that they respectively read an unsigned 16-bit or 32-bit integer 
+in network byte order from
+.Fa b .
+Similarly,
+.Fn lwres_buffer_putuint16
+and
+.Fn lwres_buffer_putuint32
+writes the unsigned 16-bit or 32-bit integer
+.Fa val
+to buffer
+.Fa b ,
+in network byte order.
+.Pp
+Arbitrary amounts of data are read or written from a lightweight
+resolver buffer with
+.Fn lwres_buffer_getmem
+and
+.Fn lwres_buffer_putmem
+respectively.
+.Fn lwres_buffer_putmem
+copies
+.Fa length
+bytes of memory at
+.Fa base
+to
+.Fa b.
+Conversely,
+.Fn lwres_buffer_getmem
+copies
+.Fa length
+bytes of memory from
+.Fa b
+to
+.Fa base .
+.Sh SEE ALSO
diff --git a/doc/man/lwres/lwres_buffer_add.3 b/doc/man/lwres/lwres_buffer_add.3
new file mode 100644
index 00000000..3a63e411
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_add.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_add.3,v 1.4 2000/11/18 02:59:16 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_back.3 b/doc/man/lwres/lwres_buffer_back.3
new file mode 100644
index 00000000..f6e87aa3
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_back.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_back.3,v 1.4 2000/11/18 02:59:17 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_clear.3 b/doc/man/lwres/lwres_buffer_clear.3
new file mode 100644
index 00000000..df21d5fa
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_clear.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_clear.3,v 1.4 2000/11/18 02:59:18 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_first.3 b/doc/man/lwres/lwres_buffer_first.3
new file mode 100644
index 00000000..f8da7a5f
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_first.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_first.3,v 1.4 2000/11/18 02:59:19 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_forward.3 b/doc/man/lwres/lwres_buffer_forward.3
new file mode 100644
index 00000000..a7d8431e
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_forward.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_forward.3,v 1.4 2000/11/18 02:59:20 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_getmem.3 b/doc/man/lwres/lwres_buffer_getmem.3
new file mode 100644
index 00000000..e67f2081
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_getmem.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_getmem.3,v 1.4 2000/11/18 02:59:21 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_getuint16.3 b/doc/man/lwres/lwres_buffer_getuint16.3
new file mode 100644
index 00000000..cc934170
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_getuint16.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_getuint16.3,v 1.4 2000/11/18 02:59:22 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_getuint32.3 b/doc/man/lwres/lwres_buffer_getuint32.3
new file mode 100644
index 00000000..3a27ba08
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_getuint32.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_getuint32.3,v 1.4 2000/11/18 02:59:24 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_getuint8.3 b/doc/man/lwres/lwres_buffer_getuint8.3
new file mode 100644
index 00000000..87452642
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_getuint8.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_getuint8.3,v 1.4 2000/11/18 02:59:25 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_init.3 b/doc/man/lwres/lwres_buffer_init.3
new file mode 100644
index 00000000..53ca2a62
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_init.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_init.3,v 1.4 2000/11/18 02:59:26 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_invalidate.3 b/doc/man/lwres/lwres_buffer_invalidate.3
new file mode 100644
index 00000000..b69a0dd2
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_invalidate.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_invalidate.3,v 1.4 2000/11/18 02:59:28 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_putmem.3 b/doc/man/lwres/lwres_buffer_putmem.3
new file mode 100644
index 00000000..8dc58b8a
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_putmem.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_putmem.3,v 1.4 2000/11/18 02:59:29 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_putuint16.3 b/doc/man/lwres/lwres_buffer_putuint16.3
new file mode 100644
index 00000000..ca2bf21c
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_putuint16.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_putuint16.3,v 1.4 2000/11/18 02:59:30 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_putuint32.3 b/doc/man/lwres/lwres_buffer_putuint32.3
new file mode 100644
index 00000000..a93dc7a9
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_putuint32.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_putuint32.3,v 1.4 2000/11/18 02:59:31 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_putuint8.3 b/doc/man/lwres/lwres_buffer_putuint8.3
new file mode 100644
index 00000000..5ffbb8bc
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_putuint8.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_putuint8.3,v 1.4 2000/11/18 02:59:32 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_buffer_subtract.3 b/doc/man/lwres/lwres_buffer_subtract.3
new file mode 100644
index 00000000..2647fa4f
--- /dev/null
+++ b/doc/man/lwres/lwres_buffer_subtract.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_buffer_subtract.3,v 1.4 2000/11/18 02:59:33 bwelling Exp $
+
+.so lwres_buffer.3
diff --git a/doc/man/lwres/lwres_conf_clear.3 b/doc/man/lwres/lwres_conf_clear.3
new file mode 100644
index 00000000..559631b0
--- /dev/null
+++ b/doc/man/lwres/lwres_conf_clear.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_conf_clear.3,v 1.4 2000/11/18 02:59:34 bwelling Exp $
+
+.so lwres_config.3
diff --git a/doc/man/lwres/lwres_conf_get.3 b/doc/man/lwres/lwres_conf_get.3
new file mode 100644
index 00000000..48bb2356
--- /dev/null
+++ b/doc/man/lwres/lwres_conf_get.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_conf_get.3,v 1.4 2000/11/18 02:59:35 bwelling Exp $
+
+.so lwres_config.3
diff --git a/doc/man/lwres/lwres_conf_init.3 b/doc/man/lwres/lwres_conf_init.3
new file mode 100644
index 00000000..258940e4
--- /dev/null
+++ b/doc/man/lwres/lwres_conf_init.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_conf_init.3,v 1.4 2000/11/18 02:59:37 bwelling Exp $
+
+.so lwres_config.3
diff --git a/doc/man/lwres/lwres_conf_parse.3 b/doc/man/lwres/lwres_conf_parse.3
new file mode 100644
index 00000000..5a8a4ae0
--- /dev/null
+++ b/doc/man/lwres/lwres_conf_parse.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_conf_parse.3,v 1.4 2000/11/18 02:59:38 bwelling Exp $
+
+.so lwres_config.3
diff --git a/doc/man/lwres/lwres_conf_print.3 b/doc/man/lwres/lwres_conf_print.3
new file mode 100644
index 00000000..0586f287
--- /dev/null
+++ b/doc/man/lwres/lwres_conf_print.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_conf_print.3,v 1.4 2000/11/18 02:59:39 bwelling Exp $
+
+.so lwres_config.3
diff --git a/doc/man/lwres/lwres_config.3 b/doc/man/lwres/lwres_config.3
new file mode 100644
index 00000000..9eeb3784
--- /dev/null
+++ b/doc/man/lwres/lwres_config.3
@@ -0,0 +1,108 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_config.3,v 1.5 2000/12/04 18:37:37 gson Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_CONFIG 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_conf_init ,
+.Nm lwres_conf_clear ,
+.Nm lwres_conf_parse ,
+.Nm lwres_conf_print ,
+.Nm lwres_conf_get
+.Nd lightweight resolver configuration
+.Sh SYNOPSIS
+.Fd #include <lwres/lwres.h>
+.Fd
+.Ft void
+.Fo lwres_conf_init
+.Fa "lwres_context_t *ctx"
+.Fc
+.Ft void
+.Fo lwres_conf_clear
+.Fa "lwres_context_t *ctx"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_conf_parse
+.Fa "lwres_context_t *ctx"
+.Fa "const char *filename"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_conf_print
+.Fa "lwres_context_t *ctx"
+.Fa "FILE *fp"
+.Fc
+.Ft lwres_conf_t *
+.Fo lwres_conf_get
+.Fa "lwres_context_t *ctx"
+.Fc
+.Sh DESCRIPTION
+.Fn lwres_conf_init
+creates an empty
+.Dv lwres_conf_t
+structure for lightweight resolver context
+.Fa ctx .
+.Pp
+.Fn lwres_conf_clear
+frees up all the internal memory used by
+that
+.Dv lwres_conf_t
+structure in resolver context
+.Fa ctx .
+.Pp
+.Fn lwres_conf_parse
+opens the file
+.Fa filename
+and parses it to initialise the resolver context
+.Fa ctx 's
+.Dv lwres_conf_t
+structure.
+.Pp
+.Fn lwres_conf_print
+prints the
+.Dv lwres_conf_t
+structure for resolver context
+.Fa ctx
+to the
+.Dv FILE
+.Fa fp.
+.Sh RETURN VALUES
+.Fn lwres_conf_parse
+returns
+.Er LWRES_R_SUCCESS
+if it successfully read and parsed
+.Fa filename .
+It returns
+.Er LWRES_R_FAILURE
+if
+.Fa filename
+could not be opened or contained incorrect
+resolver statements.
+.Pp
+.Fn lwres_conf_print
+returns
+.Er LWRES_R_SUCCESS
+unless an error occurred when converting the network addresses to a
+numeric host address string.
+If this happens, the function returns
+.Er LWRES_R_FAILURE .
+.Sh SEE ALSO
+.Xr stdio 3 ,
+.Xr resolver 5 .
+.Sh FILES
+.Pa /etc/resolv.conf
diff --git a/doc/man/lwres/lwres_context.3 b/doc/man/lwres/lwres_context.3
new file mode 100644
index 00000000..361c5e52
--- /dev/null
+++ b/doc/man/lwres/lwres_context.3
@@ -0,0 +1,212 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_context.3,v 1.5 2000/11/18 02:59:42 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_CONTEXT 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_context_create ,
+.Nm lwres_context_destroy ,
+.Nm lwres_context_nextserial ,
+.Nm lwres_context_initserial ,
+.Nm lwres_context_freemem ,
+.Nm lwres_context_allocmem ,
+.Nm lwres_context_sendrecv
+.Nd lightweight resolver context management
+.Sh SYNOPSIS
+.Fd #include <lwres/lwres.h>
+.Fd
+.Ft lwres_result_t
+.Fo lwres_context_create
+.Fa "lwres_context_t **contextp"
+.Fa "void *arg"
+.Fa "lwres_malloc_t malloc_function"
+.Fa "lwres_free_t free_function"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_context_destroy
+.Fa "lwres_context_t **contextp"
+.Fc
+.Ft void
+.Fo lwres_context_initserial
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_uint32_t serial"
+.Fc
+.Ft lwres_uint32_t
+.Fo lwres_context_nextserial
+.Fa "lwres_context_t *ctx"
+.Fc
+.Ft void
+.Fo lwres_context_freemem
+.Fa "lwres_context_t *ctx"
+.Fa "void *mem"
+.Fa "size_t len"
+.Fc
+.Ft void
+.Fo lwres_context_allocmem
+.Fa "lwres_context_t *ctx"
+.Fa "size_t len"
+.Fc
+.Ft void *
+.Fo lwres_context_sendrecv
+.Fa "lwres_context_t *ctx"
+.Fa "void *sendbase"
+.Fa "int sendlen"
+.Fa "void *recvbase"
+.Fa "int recvlen"
+.Fa "int *recvd_len"
+.Fc
+.Sh DESCRIPTION
+.Fn lwres_context_create
+creates a
+.Dv lwres_context_t
+structure for use in lightweight resolver operations.
+It holds a socket and other data needed for communicating
+with a resolver daemon.
+The new
+.Dv lwres_context_t
+is returned throught
+.Fa contextp ,
+a pointer to a
+.Dv "lwres_context_t"
+pointer.  This 
+.Dv "lwres_context_t"
+pointer must initially be NULL, and is modified 
+to point to the newly created
+.Dv "lwres_context_t" .
+.Pp
+When the lightweight resolver needs to perform dynamic memory
+allocation, it will call
+.Fa malloc_function
+to allocate memory and
+.Fa free_function 
+to free it.  If 
+.Fa malloc_function
+and
+.Fa free_function 
+are NULL, memory is allocated using
+.Xr malloc 3
+and
+.Xr free 3 .
+It is not permitted to have a NULL
+.Fa malloc_function
+and a non-NULL
+.Fa free_function
+or vice versa.
+.Fa arg
+is passed as the first parameter to the memory
+allocation functions.  
+If
+.Fa malloc_function
+and
+.Fa free_function
+are NULL,
+.Fa arg 
+is unused and should be passed as NULL.
+.P
+Once memory for the structure has been allocated,
+it is initialized using
+.Xr lwres_conf_init 3 
+and returned via
+.Fa *contextp .
+.Pp
+.Fn lwres_context_destroy
+destroys a 
+.Dv "lwres_context_t" ,
+closing its socket.
+.Fa contextp
+is a pointer to a pointer to the context that is to be destroyed.
+The pointer will be set to NULL when the context has been destroyed.
+.Pp
+The context holds a serial number that is used to identify resolver
+request packets and associate responses with the corresponding requests.
+This serial number is controlled using
+.Fn lwres_context_initserial
+and
+.Fn lwres_context_nextserial .
+.Fn lwres_context_initserial
+sets the serial number for context
+.Fa *ctx
+to
+.Fa serial .
+.Fn lwres_context_nextserial
+increments the serial number and returns the previous value.
+.Pp
+Memory for a lightweight resolver context is allocated and freed using
+.Fn lwres_context_allocmem
+and
+.Fn lwres_context_freemem .
+These use whatever allocations were defined when the context was
+created with
+.Fn lwres_context_create .
+.Fn lwres_context_allocmem
+allocates
+.Fa len
+bytes of memory and if successful returns a pointer to the allocated
+storage.
+.Fn lwres_context_allocmem
+checks that
+.Fa len
+must be greater than 0.
+.Fn lwres_context_freemem
+frees
+.Fa len
+bytes of space starting at location
+.Fa mem .
+.Pp
+.Fn lwres_context_sendrecv
+performs I/O for the context
+.Fa ctx .
+Data are read and written from the context's socket.
+It writes data from
+.Fa sendbase
+- typically a lightweight resolver query packet -
+and waits for a reply which is copied to the receive buffer at
+.Fa recvbase .
+The number of bytes that were written to this receive buffer is
+returned in
+.Fa *recvd_len .
+.Sh RETURN VALUES
+.Fn lwres_context_create
+returns
+.Er LWRES_R_NOMEMORY
+if memory for the
+.Dv "struct lwres_context"
+could not be allocated, 
+.Er LWRES_R_SUCCESS
+otherwise.
+.Pp
+Successful calls to the memory allocator
+.Fn lwres_context_allocmem
+return a pointer to the start of the allocated space.
+It returns NULL if memory could not be allocated.
+.Pp
+.Er LWRES_R_SUCCESS
+is returned when
+.Fn lwres_context_sendrecv
+completes successfully.
+.Er LWRES_R_IOERROR
+is returned if an I/O error occurs and
+.Er LWRES_R_TIMEOUT
+is returned if
+.Fn lwres_context_sendrecv
+times out waiting for a response.
+.Sh SEE ALSO
+.Xr lwres_conf_init 3 ,
+.Xr malloc 3 ,
+.Xr free 3
diff --git a/doc/man/lwres/lwres_context_allocmem.3 b/doc/man/lwres/lwres_context_allocmem.3
new file mode 100644
index 00000000..440704e4
--- /dev/null
+++ b/doc/man/lwres/lwres_context_allocmem.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_context_allocmem.3,v 1.4 2000/11/18 02:59:43 bwelling Exp $
+
+.so lwres_context.3
diff --git a/doc/man/lwres/lwres_context_create.3 b/doc/man/lwres/lwres_context_create.3
new file mode 100644
index 00000000..a2ed9e66
--- /dev/null
+++ b/doc/man/lwres/lwres_context_create.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_context_create.3,v 1.4 2000/11/18 02:59:44 bwelling Exp $
+
+.so lwres_context.3
diff --git a/doc/man/lwres/lwres_context_destroy.3 b/doc/man/lwres/lwres_context_destroy.3
new file mode 100644
index 00000000..6f83d7e7
--- /dev/null
+++ b/doc/man/lwres/lwres_context_destroy.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_context_destroy.3,v 1.4 2000/11/18 02:59:45 bwelling Exp $
+
+.so lwres_context.3
diff --git a/doc/man/lwres/lwres_context_freemem.3 b/doc/man/lwres/lwres_context_freemem.3
new file mode 100644
index 00000000..5afdbbb5
--- /dev/null
+++ b/doc/man/lwres/lwres_context_freemem.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_context_freemem.3,v 1.4 2000/11/18 02:59:46 bwelling Exp $
+
+.so lwres_context.3
diff --git a/doc/man/lwres/lwres_context_initserial.3 b/doc/man/lwres/lwres_context_initserial.3
new file mode 100644
index 00000000..f6792875
--- /dev/null
+++ b/doc/man/lwres/lwres_context_initserial.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_context_initserial.3,v 1.4 2000/11/18 02:59:47 bwelling Exp $
+
+.so lwres_context.3
diff --git a/doc/man/lwres/lwres_context_nextserial.3 b/doc/man/lwres/lwres_context_nextserial.3
new file mode 100644
index 00000000..a62b02b7
--- /dev/null
+++ b/doc/man/lwres/lwres_context_nextserial.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_context_nextserial.3,v 1.4 2000/11/18 02:59:48 bwelling Exp $
+
+.so lwres_context.3
diff --git a/doc/man/lwres/lwres_context_sendrecv.3 b/doc/man/lwres/lwres_context_sendrecv.3
new file mode 100644
index 00000000..23904a2f
--- /dev/null
+++ b/doc/man/lwres/lwres_context_sendrecv.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_context_sendrecv.3,v 1.4 2000/11/18 02:59:49 bwelling Exp $
+
+.so lwres_context.3
diff --git a/doc/man/lwres/lwres_endhostent.3 b/doc/man/lwres/lwres_endhostent.3
new file mode 100644
index 00000000..b70ae5da
--- /dev/null
+++ b/doc/man/lwres/lwres_endhostent.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_endhostent.3,v 1.4 2000/11/18 02:59:51 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_endhostent_r.3 b/doc/man/lwres/lwres_endhostent_r.3
new file mode 100644
index 00000000..099fded7
--- /dev/null
+++ b/doc/man/lwres/lwres_endhostent_r.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_endhostent_r.3,v 1.4 2000/11/18 02:59:52 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_freeaddrinfo.3 b/doc/man/lwres/lwres_freeaddrinfo.3
new file mode 100644
index 00000000..70245ad1
--- /dev/null
+++ b/doc/man/lwres/lwres_freeaddrinfo.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_freeaddrinfo.3,v 1.4 2000/11/18 02:59:54 bwelling Exp $
+
+.so lwres_getaddrinfo.3
diff --git a/doc/man/lwres/lwres_freehostent.3 b/doc/man/lwres/lwres_freehostent.3
new file mode 100644
index 00000000..84d6797b
--- /dev/null
+++ b/doc/man/lwres/lwres_freehostent.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_freehostent.3,v 1.4 2000/11/18 02:59:55 bwelling Exp $
+
+.so lwres_getipnode.3
diff --git a/doc/man/lwres/lwres_gabn.3 b/doc/man/lwres/lwres_gabn.3
new file mode 100644
index 00000000..c58d418e
--- /dev/null
+++ b/doc/man/lwres/lwres_gabn.3
@@ -0,0 +1,207 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gabn.3,v 1.5 2000/11/18 02:59:56 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_GABN 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_gabnrequest_render ,
+.Nm lwres_gabnresponse_render ,
+.Nm lwres_gabnrequest_parse ,
+.Nm lwres_gabnresponse_parse ,
+.Nm lwres_gabnresponse_free ,
+.Nm lwres_gabnrequest_free
+.Nd lightweight resolver getaddrbyname message handling
+.Sh SYNOPSIS
+.Fd #include <lwres/lwres.h>
+.Fd
+.Ft lwres_result_t
+.Fo lwres_gabnrequest_render
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_gabnrequest_t *req"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_gabnresponse_render
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_gabnresponse_t *req"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_gabnrequest_parse
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_gabnrequest_t **structp"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_gabnresponse_parse
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_gabnresponse_t **structp"
+.Fc
+.Ft void
+.Fo lwres_gabnresponse_free
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_gabnresponse_t **structp"
+.Fc
+.Ft void
+.Fo lwres_gabnrequest_free
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_gabnrequest_t **structp"
+.Fc
+.Sh DESCRIPTION
+These are low-level routines for creating and parsing
+lightweight resolver name-to-address lookup request and 
+response messages.
+.P
+There are four main functions for the getaddrbyname opcode.
+One render function converts a getaddrbyname request structure -
+.Dv lwres_gabnrequest_t -
+to the lighweight resolver's canonical format.
+It is complemented by a parse function that converts a packet in this
+canonical format to a getaddrbyname request structure.
+Another render function converts the getaddrbyname response structure -
+.Dv lwres_gabnresponse_t
+to the canonical format.
+This is complemented by a parse function which converts a packet in
+canonical format to a getaddrbyname response structure.
+.Pp
+These structures are defined in
+.Pa <lwres/lwres.h> .
+They are shown below.
+.Bd -literal -offset indent
+#define LWRES_OPCODE_GETADDRSBYNAME	0x00010001U
+
+typedef struct lwres_addr lwres_addr_t;
+typedef LWRES_LIST(lwres_addr_t) lwres_addrlist_t;
+
+typedef struct {
+	lwres_uint32_t	flags;
+	lwres_uint32_t	addrtypes;
+	lwres_uint16_t	namelen;
+	char	       *name;
+} lwres_gabnrequest_t;
+
+typedef struct {
+	lwres_uint32_t		flags;
+	lwres_uint16_t		naliases;
+	lwres_uint16_t		naddrs;
+	char		       *realname;
+	char		      **aliases;
+	lwres_uint16_t		realnamelen;
+	lwres_uint16_t 	       *aliaslen;
+	lwres_addrlist_t	addrs;
+	void		       *base;
+	size_t			baselen;
+} lwres_gabnresponse_t;
+.Ed
+.Pp
+.Fn lwres_gabnrequest_render
+uses resolver context
+.Fa ctx
+to convert getaddrbyname request structure
+.Fa req
+to canonical format.
+The packet header structure
+.Fa pkt
+is initialised and transferred to
+buffer
+.Fa b .
+The contents of
+.Fa *req
+are then appended to the buffer in canonical format.
+.Fn lwres_gabnresponse_render
+performs the same task, except it converts a getaddrbyname response structure
+.Dv lwres_gabnresponse_t
+to the lightweight resolver's canonical format.
+.Pp
+.Fn lwres_gabnrequest_parse
+uses context
+.Fa ctx
+to convert the contents of packet
+.Fa pkt
+to a
+.Dv lwres_gabnrequest_t
+structure.
+Buffer
+.Fa b
+provides space to be used for storing this structure.
+When the function succeeds, the resulting
+.Dv lwres_gabnrequest_t
+is made available through
+.Fa *structp .
+.Fn lwres_gabnresponse_parse
+offers the same semantics as
+.Fn lwres_gabnrequest_parse
+except it yields a
+.Dv lwres_gabnresponse_t
+structure.
+.Pp
+.Fn lwres_gabnresponse_free
+and
+.Fn lwres_gabnrequest_free
+release the memory in resolver context
+.Fa ctx
+that was allocated to the
+.Dv lwres_gabnresponse_t
+or
+.Dv lwres_gabnrequest_t
+structures referenced via
+.Fa structp .
+Any memory associated with ancillary buffers and strings for those
+structures is also discarded.
+.Sh RETURN VALUES
+The getaddrbyname opcode functions
+.Fn lwres_gabnrequest_render ,
+.Fn lwres_gabnresponse_render
+.Fn lwres_gabnrequest_parse
+and
+.Fn lwres_gabnresponse_parse
+all return
+.Er LWRES_R_SUCCESS
+on success.
+They return
+.Er LWRES_R_NOMEMORY
+if memory allocation fails.
+.Er LWRES_R_UNEXPECTEDEND
+is returned if the available space in the buffer
+.Fa b
+is too small to accommodate the packet header or the
+.Dv lwres_gabnrequest_t
+and
+.Dv lwres_gabnresponse_t
+structures.
+.Fn lwres_gabnrequest_parse
+and
+.Fn lwres_gabnresponse_parse
+will return
+.Er LWRES_R_UNEXPECTEDEND
+if the buffer is not empty after decoding the received packet.
+These functions will return
+.Er LWRES_R_FAILURE
+if
+.Li pktflags
+in the packet header structure
+.Dv lwres_lwpacket_t
+indicate that the packet is not a response to an earlier query.
+.Sh SEE ALSO
+.Xr lwres_packet 3
diff --git a/doc/man/lwres/lwres_gabnrequest_free.3 b/doc/man/lwres/lwres_gabnrequest_free.3
new file mode 100644
index 00000000..5664564c
--- /dev/null
+++ b/doc/man/lwres/lwres_gabnrequest_free.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gabnrequest_free.3,v 1.4 2000/11/18 02:59:57 bwelling Exp $
+
+.so lwres_gabn.3
diff --git a/doc/man/lwres/lwres_gabnrequest_parse.3 b/doc/man/lwres/lwres_gabnrequest_parse.3
new file mode 100644
index 00000000..70f953f1
--- /dev/null
+++ b/doc/man/lwres/lwres_gabnrequest_parse.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gabnrequest_parse.3,v 1.4 2000/11/18 02:59:58 bwelling Exp $
+
+.so lwres_gabn.3
diff --git a/doc/man/lwres/lwres_gabnrequest_render.3 b/doc/man/lwres/lwres_gabnrequest_render.3
new file mode 100644
index 00000000..db878a92
--- /dev/null
+++ b/doc/man/lwres/lwres_gabnrequest_render.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gabnrequest_render.3,v 1.4 2000/11/18 03:00:00 bwelling Exp $
+
+.so lwres_gabn.3
diff --git a/doc/man/lwres/lwres_gabnresponse_free.3 b/doc/man/lwres/lwres_gabnresponse_free.3
new file mode 100644
index 00000000..683b63f2
--- /dev/null
+++ b/doc/man/lwres/lwres_gabnresponse_free.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gabnresponse_free.3,v 1.4 2000/11/18 03:00:01 bwelling Exp $
+
+.so lwres_gabn.3
diff --git a/doc/man/lwres/lwres_gabnresponse_parse.3 b/doc/man/lwres/lwres_gabnresponse_parse.3
new file mode 100644
index 00000000..e71760d2
--- /dev/null
+++ b/doc/man/lwres/lwres_gabnresponse_parse.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gabnresponse_parse.3,v 1.4 2000/11/18 03:00:02 bwelling Exp $
+
+.so lwres_gabn.3
diff --git a/doc/man/lwres/lwres_gabnresponse_render.3 b/doc/man/lwres/lwres_gabnresponse_render.3
new file mode 100644
index 00000000..9f3e5765
--- /dev/null
+++ b/doc/man/lwres/lwres_gabnresponse_render.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gabnresponse_render.3,v 1.4 2000/11/18 03:00:03 bwelling Exp $
+
+.so lwres_gabn.3
diff --git a/doc/man/lwres/lwres_gai_strerror.3 b/doc/man/lwres/lwres_gai_strerror.3
new file mode 100644
index 00000000..9d54377b
--- /dev/null
+++ b/doc/man/lwres/lwres_gai_strerror.3
@@ -0,0 +1,82 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gai_strerror.3,v 1.5 2000/11/18 03:00:05 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_GAI_STRERROR 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm gai_strerror
+.Nd print suitable error string
+.Sh SYNOPSIS
+.Fd #include <lwres/netdb.h>
+.Fd
+.Ft char *
+.Fo gai_strerror
+.Fa "int ecode"
+.Fc
+.Sh DESCRIPTION
+.Fn lwres_gai_strerror
+returns an error message corresponding to an error code returned by
+.Fn getaddrinfo .
+The following error codes and their meaning are defined in
+.Aq Pa include/lwres/netdb.h .
+.Bl -tag -width EAI_ADDRFAMILY -offset indent -compact
+.It Dv EAI_ADDRFAMILY
+address family for hostname not supported
+.It Dv EAI_AGAIN
+temporary failure in name resolution
+.It Dv EAI_BADFLAGS
+invalid value for
+.Li ai_flags
+.It Dv EAI_FAIL
+non-recoverable failure in name resolution
+.It Dv EAI_FAMILY
+.Li ai_family
+not supported
+.It Dv EAI_MEMORY
+memory allocation failure
+.It Dv EAI_NODATA
+no address associated with hostname
+.It Dv EAI_NONAME
+hostname or servname not provided, or not known
+.It Dv EAI_SERVICE
+servname not supported for
+.Li ai_socktype
+.It Dv EAI_SOCKTYPE
+.Li ai_socktype
+not supported
+.It Dv EAI_SYSTEM
+system error returned in errno
+.El
+The message \*qinvalid error code\*q is returned if
+.Fa ecode
+is out of range.
+.Pp
+.Li ai_flags ,
+.Li ai_family
+and
+.Li ai_socktype
+are elements of the
+.Dv "struct  addrinfo"
+used by
+.Fn lwres_getaddrinfo .
+.Sh SEE ALSO
+.Xr strerror 3 ,
+.Xr lwres_getaddrinfo 3 ,
+.Xr getaddrinfo 3 ,
+.Xr RFC2133 .
diff --git a/doc/man/lwres/lwres_getaddrinfo.3 b/doc/man/lwres/lwres_getaddrinfo.3
new file mode 100644
index 00000000..090d922e
--- /dev/null
+++ b/doc/man/lwres/lwres_getaddrinfo.3
@@ -0,0 +1,258 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_getaddrinfo.3,v 1.7 2000/11/18 03:00:08 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_GETADDRINFO 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_getaddrinfo ,
+.Nm lwres_freeaddrinfo
+.Nd socket address structure to host and service name
+.Sh SYNOPSIS
+.Fd #include <lwres/netdb.h>
+.Fd
+.Ft int
+.Fo lwres_getaddrinfo
+.Fa "const char *hostname"
+.Fa "const char *servname"
+.Fa "const struct addrinfo *hints"
+.Fa "struct addrinfo **res"
+.Fc
+.Ft void
+.Fo lwres_freeaddrinfo
+.Fa "struct addrinfo *ai"
+.Fc
+.Pp
+If the operating system does not provide a
+.Dv "struct addrinfo" ,
+the following structure is used:
+.Pp
+.Bd -literal -offset indent
+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 */
+};
+.Ed
+.Sh DESCRIPTION
+.Pp
+.Fn lwres_getaddrinfo
+is used to get a list of IP addresses and port numbers for host
+.Fa hostname
+and service
+.Fa servname .
+The function is the lightweight resolver's implementation of
+.Fn getaddrinfo
+as defined in RFC2133.
+.Fa hostname
+and
+.Fa servname
+are pointers to null-terminated
+strings or
+.Dv NULL .
+.Fa hostname
+is either a host name or a numeric host address string: a dotted decimal
+IPv4 address or an IPv6 address.
+.Fa servname
+is either a decimal port number or a service name as listed in
+.Pa /etc/services .
+.Pp
+.Fa hints
+is an optional pointer to a
+.Dv "struct addrinfo" .
+This structure can be used to provide hints concerning the type of socket
+that the caller supports or wishes to use.
+The caller can supply the following structure elements in
+.Fa *hints :
+.Bl -tag -width ai_socktyp  -offset indent -compact
+.It Li ai_family
+the protocol family that should be used.
+When
+.Li ai_family
+is set to
+.Dv PF_UNSPEC ,
+it means the caller will accept any protocol family supported by the
+operating system.
+.It Dv ai_socktype
+denotes the type of socket -
+.Dv SOCK_STREAM ,
+.Dv SOCK_DGRAM
+or
+.Dv SOCK_RAW
+- that is wanted.
+When
+.Li ai_socktype
+is zero the caller will accept any socket type.
+.It Li ai_protocol
+indicates which transport protocol is wanted: IPPROTO_UDP or 
+IPPROTO_TCP.
+If
+.Li ai_protocol
+is zero the caller will accept any protocol.
+.It Li ai_flags
+Flag bits.
+If the
+.Dv AI_CANONNAME
+bit is set, a successful call to
+.Fn lwres_getaddrinfo
+will return a a null-terminated string containing the canonical name
+of the specified hostname in
+.Li ai_canonname
+of the first
+.Dv addrinfo
+structure returned.
+Setting the
+.Dv AI_PASSIVE
+bit indicates that the returned socket address structure is intended
+for used in a call to
+.Xr bind 2 .
+In this case, if the hostname argument is a
+.Dv NULL
+pointer, then the IP address portion of the socket
+address structure will be set to
+.Dv INADDR_ANY
+for an IPv4 address or
+.Dv IN6ADDR_ANY_INIT
+for an IPv6 address.
+.Pp
+When
+.Li ai_flags
+does not set the
+.Dv AI_PASSIVE
+bit, the returned socket address structure will be ready
+for use in a call to
+.Xr connect 2
+for a connection-oriented protocol or
+.Xr connect 2 ,
+.Xr sendto 2 ,
+or
+.Xr sendmsg 2
+if a connectionless protocol was chosen.
+The IP address portion of the socket address structure will be
+set to the loopback address if
+.Fa hostname
+is a
+.Dv NULL
+pointer and
+.Dv AI_PASSIVE
+is not set in
+.Li ai_flags .
+.Pp
+If
+.Li ai_flags
+is set to
+.Dv AI_NUMERICHOST
+it indicates that
+.Fa hostname
+should be treated as a numeric string defining an IPv4 or IPv6 address
+and no name resolution should be attempted.
+.El
+.Pp
+All other elements of the
+.Dv "struct addrinfo"
+passed via
+.Fa hints
+must be zero.
+.Pp
+A
+.Fa hints
+of
+.Dv NULL
+is treated as if the caller provided a
+.Dv "struct addrinfo"
+initialized to zero with
+.Li ai_family set to
+.Li PF_UNSPEC .
+.Pp
+After a successful call to
+.Fn lwres_getaddrinfo ,
+.Fa *res
+is a pointer to a linked list of one or more
+.Dv addrinfo
+structures.
+Each
+.Dv "struct addrinfo" 
+in this list cn be processed by following
+the
+.Li ai_next
+pointer, until a
+.Dv NULL
+pointer is encountered.
+The three members
+.Li ai_family ,
+.Li ai_socktype ,
+and
+.Li ai_protocol
+in each
+returned
+.Dv addrinfo
+structure contain the corresponding arguments for a call to
+.Xr socket 2 .
+For each
+.Dv addrinfo
+structure in the list, the
+.Li ai_addr
+member points to a filled-in socket address structure of length
+.Li ai_addrlen .
+.Pp
+All of the information returned by
+.Fn lwres_getaddrinfo
+is dynamically allocated: the addrinfo structures, and the socket
+address structures and canonical host name strings pointed to by the
+.Li addrinfo structures.
+Memory allocated for the dynamically allocated structures created by
+a successful call to
+.Fn lwres_getaddrinfo
+is released by
+.Fn lwres_freeaddrinfo .
+.Fa ai
+is a pointer to a
+.Dv "struct addrinfo" 
+created by a call to
+.Fn lwres_getaddrinfo .
+.Sh RETURN VALUES
+.Fn lwres_getaddrinfo
+returns zero on success or one of the error codes listed in
+.Xr gai_strerror 3
+if an error occurs.
+If both
+.Fa hostname
+and
+.Fa servname
+are
+.Dv NULL
+.Fn lwres_getaddrinfo
+returns
+.Er EAI_NONAME .
+.Sh SEE ALSO
+.Xr lwres 3 ,
+.Xr lwres_getaddrinfo 3 ,
+.Xr lwres_freeaddrinfo 3 ,
+.Xr lwres_gai_strerror 3 ,
+.Xr RFC2133 ,
+.Xr getservbyname 3 ,
+.Xr bind 2 ,
+.Xr connect 2 ,
+.Xr sendto 2 ,
+.Xr sendmsg 2 ,
+.Xr socket 2 .
diff --git a/doc/man/lwres/lwres_getaddrsbyname.3 b/doc/man/lwres/lwres_getaddrsbyname.3
new file mode 100644
index 00000000..6fba9780
--- /dev/null
+++ b/doc/man/lwres/lwres_getaddrsbyname.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_getaddrsbyname.3,v 1.4 2000/11/18 03:00:10 bwelling Exp $
+
+.so lwres_resutil.3
diff --git a/doc/man/lwres/lwres_gethostbyaddr.3 b/doc/man/lwres/lwres_gethostbyaddr.3
new file mode 100644
index 00000000..36e4ac8f
--- /dev/null
+++ b/doc/man/lwres/lwres_gethostbyaddr.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gethostbyaddr.3,v 1.4 2000/11/18 03:00:12 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_gethostbyaddr_r.3 b/doc/man/lwres/lwres_gethostbyaddr_r.3
new file mode 100644
index 00000000..a0af7790
--- /dev/null
+++ b/doc/man/lwres/lwres_gethostbyaddr_r.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gethostbyaddr_r.3,v 1.4 2000/11/18 03:00:15 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_gethostbyname.3 b/doc/man/lwres/lwres_gethostbyname.3
new file mode 100644
index 00000000..d4f07df6
--- /dev/null
+++ b/doc/man/lwres/lwres_gethostbyname.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gethostbyname.3,v 1.4 2000/11/18 03:00:17 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_gethostbyname2.3 b/doc/man/lwres/lwres_gethostbyname2.3
new file mode 100644
index 00000000..afbf8a64
--- /dev/null
+++ b/doc/man/lwres/lwres_gethostbyname2.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gethostbyname2.3,v 1.4 2000/11/18 03:00:19 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_gethostbyname_r.3 b/doc/man/lwres/lwres_gethostbyname_r.3
new file mode 100644
index 00000000..faa4c14d
--- /dev/null
+++ b/doc/man/lwres/lwres_gethostbyname_r.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gethostbyname_r.3,v 1.4 2000/11/18 03:00:20 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_gethostent.3 b/doc/man/lwres/lwres_gethostent.3
new file mode 100644
index 00000000..985f7fe2
--- /dev/null
+++ b/doc/man/lwres/lwres_gethostent.3
@@ -0,0 +1,353 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gethostent.3,v 1.6 2000/12/04 18:37:38 gson Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_GETHOSTENT 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_gethostbyname ,
+.Nm lwres_gethostbyname2 ,
+.Nm lwres_gethostbyaddr ,
+.Nm lwres_gethostent ,
+.Nm lwres_sethostent ,
+.Nm lwres_endhostent ,
+.Nm lwres_gethostbyname_r ,
+.Nm lwres_gethostbyaddr_r ,
+.Nm lwres_gethostent_r ,
+.Nm lwres_sethostent_r ,
+.Nm lwres_endhostent_r
+.Nd lightweight resolver get network host entry
+.Sh SYNOPSIS
+.Fd #include <lwres/netdb.h>
+.Fd
+.Ft struct hostent *
+.Fo lwres_gethostbyname
+.Fa "const char *name"
+.Fc
+.Ft struct hostent *
+.Fo lwres_gethostbyname2
+.Fa "const char *name"
+.Fa "int af"
+.Fc
+.Ft struct hostent *
+.Fo lwres_gethostbyaddr
+.Fa "const char *addr"
+.Fa "int len"
+.Fa "int type"
+.Fc
+.Ft struct hostent *
+.Fo lwres_gethostent
+.Fa "void"
+.Fc
+.Ft void
+.Fo lwres_sethostent
+.Fa "int stayopen"
+.Fc
+.Ft void
+.Fo lwres_endhostent
+.Fa "void"
+.Fc
+.Ft struct hostent *
+.Fo lwres_gethostbyname_r
+.Fa "const char *name"
+.Fa "struct hostent *resbuf"
+.Fa "char *buf"
+.Fa "int buflen"
+.Fa "int *error"
+.Fc
+.Ft struct hostent  *
+.Fo lwres_gethostbyaddr_r
+.Fa "const char *addr"
+.Fa "int len"
+.Fa "int type"
+.Fa "struct hostent *resbuf"
+.Fa "char *buf"
+.Fa "int buflen"
+.Fa "int *error"
+.Fc
+.Ft struct hostent  *
+.Fo lwres_gethostent_r
+.Fa "struct hostent *resbuf"
+.Fa "char *buf"
+.Fa "int buflen"
+.Fa "int *error"
+.Fc
+.Ft void
+.Fo lwres_sethostent_r
+.Fa "int stayopen"
+.Fc
+.Ft void
+.Fo lwres_endhostent_r
+.Fa "void"
+.Fc
+.Sh DESCRIPTION
+These functions provide hostname-to-address and
+address-to-hostname lookups by means of the lightweight resolver.
+They are similar to the standard
+.Xr gethostent 3
+functions provided by most operating systems.
+They use a
+.Dv "struct hostent"
+which is usually defined in
+.Pa <namedb.h> .
+.Bd -literal
+struct	hostent {
+	char	*h_name;	/* official name of host */
+	char	**h_aliases;	/* alias list */
+	int	h_addrtype;	/* host address type */
+	int	h_length;	/* length of address */
+	char	**h_addr_list;	/* list of addresses from name server */
+};
+#define	h_addr  h_addr_list[0]	/* address, for backward compatibility */
+.Ed
+.Pp
+The members of this structure are:
+.Bl -tag -width h_addr_list
+.It Li h_name
+The official (canonical) name of the host.
+.It Li h_aliases
+A NULL-terminated array of alternate names (nicknames) for the host.
+.It Li h_addrtype
+The type of address being returned -
+.Dv PF_INET
+or
+.Dv PF_INET6 .
+.It Li h_length
+The length of the address in bytes.
+.It Li h_addr_list
+A
+.Dv NULL
+terminated array of network addresses for the host.
+Host addresses are returned in network byte order.
+.El
+.Pp
+For backward compatibility with very old software,
+.Li h_addr
+is the first address in
+.Li h_addr_list.
+.Pp
+.Fn lwres_gethostent ,
+.Fn lwres_sethostent ,
+.Fn lwres_endhostent ,
+.Fn lwres_gethostent_r ,
+.Fn lwres_sethostent_r
+and
+.Fn lwres_endhostent_r
+provide iteration over the known host entries on systems that
+provide such functionality through facilities like
+.Pa /etc/hosts
+or NIS.  The lightweight resolver does not currently implement
+these functions; it only provides them as stub functions that always
+return failure.
+.Pp
+.Fn lwres_gethostbyname
+and
+.Fn lwres_gethostbyname2
+look up the hostname
+.Fa name .
+.Fn lwres_gethostbyname
+always looks for an IPv4 address while
+.Fn lwres_gethostbyname2
+looks for an address of protocol family
+.Fa af :
+either
+.Dv PF_INET
+or
+.Dv PF_INET6
+- IPv4 or IPV6 addresses respectively.
+Successful calls of the functions return a
+.Dv "struct hostent" for
+the name that was looked up.
+.Dv NULL
+is returned if the lookups by
+.Fn lwres_gethostbyname
+or
+.Fn lwres_gethostbyname2
+fail.
+.Pp
+Reverse lookups of addresses are performed by
+.Fn lwres_gethostbyaddr .
+.Fa addr
+is an address of length
+.Fa len
+bytes and protocol family
+.Fa type -
+.Dv PF_INET
+or
+.Dv PF_INET6 .
+.Fn lwres_gethostbyname_r
+is a thread-safe function for forward lookups.
+If an error occurs, an error code is returned in
+.Fa *error .
+.Fa resbuf
+is a pointer to a
+.Dv "struct hostent"
+which is initialised by a successful call to
+.Fn lwres_gethostbyname_r .
+.Fa buf
+is a buffer of length
+.Fa len
+bytes which is used to store the
+.Li h_name ,
+.Li h_aliases ,
+and
+.Li h_addr_list
+elements of the
+.Dv "struct hostent"
+returned in
+.Fa resbuf .
+Successful calls to
+.Fn lwres_gethostbyname_r
+return
+.Fa resbuf ,
+which is a pointer to the
+.Dv "struct hostent"
+it created.
+.Pp
+.Fn lwres_gethostbyaddr_r
+is a thread-safe function that performs a reverse lookup of address
+.Fa addr
+which is
+.Fa len
+bytes long
+and is of protocol family
+.Fa type -
+.Dv PF_INET
+or
+.Dv PF_INET6 .
+If an error occurs, the error code is returned in
+.Fa *error .
+The other function parameters are identical to those in
+.Fn lwres_gethostbyname_r .
+.Fa resbuf
+is a pointer to a
+.Dv "struct hostent"
+which is initialised by a successful call to
+.Fn lwres_gethostbyaddr_r .
+.Fa buf
+is a buffer of length
+.Fa len
+bytes which is used to store the
+.Li h_name ,
+.Li h_aliases ,
+and
+.Li h_addr_list
+elements of the
+.Dv "struct hostent"
+returned in
+.Fa resbuf .
+Successful calls to
+.Fn lwres_gethostbyaddr_r
+return
+.Fa resbuf ,
+which is a pointer to the
+.Fn "struct hostent"
+it created.
+.Sh RETURN VALUES
+.Pp
+The functions
+.Fn lwres_gethostbyname ,
+.Fn lwres_gethostbyname2 ,
+.Fn lwres_gethostbyaddr ,
+and
+.Fn lwres_gethostent
+return NULL to indicate an error.  In this case the global variable
+.Dv lwres_h_errno
+will contain one of the following error codes defined in
+.Pa <lwres/netdb.h> :
+.Bl -tag -width HOST_NOT_FOUND
+.It Li HOST_NOT_FOUND
+The host or address was not found.
+.It Li TRY_AGAIN
+A recoverable error occurred, e.g., a timeout.
+Retrying the lookup may succeed.
+.It Li NO_RECOVERY
+A non-recoverable error occurred.
+.It Li NO_DATA
+The name exists, but has no address information
+associated with it (or vice versa in the case
+of a reverse lookup).  The code NO_ADDRESS
+is accepted as a synonym for NO_DATA for backwards
+compatibility.
+.El
+.Pp
+.Xr lwres_hstrerror 3
+translates these error codes to suitable error messages.
+.Pp
+.Fn lwres_gethostent
+and
+.Fn lwres_gethostent_r
+always return
+.Dv NULL .
+.Pp
+Successful calls to
+.Fn lwres_gethostbyname_r
+and
+.Fn lwres_gethostbyaddr_r
+return
+.Fa resbuf ,
+a pointer to the
+.Dv "struct hostent"
+that was initialised by these functions.
+They return
+.Dv NULL
+if the lookups fail
+or if
+.Fa buf
+was too small to hold the list of addresses and names referenced by
+the
+.Li h_name ,
+.Li h_aliases ,
+and
+.Li h_addr_list
+elements of the
+.Dv "struct hostent" .
+If
+.Fa buf
+was too small, both
+.Fn lwres_gethostbyname_r
+and
+.Fn lwres_gethostbyaddr_r
+set the global variable
+.Dv errno
+to
+.Er ERANGE .
+.Sh SEE ALSO
+.Xr gethostent 3 ,
+.Xr lwres_getipnode 3 ,
+.Xr lwres_hstrerror 3
+.Sh BUGS
+.Fn lwres_gethostbyname ,
+.Fn lwres_gethostbyname2 ,
+.Fn lwres_gethostbyaddr
+and
+.Fn lwres_endhostent
+are not thread safe; they return pointers to static data and 
+provide error codes through a global variable.
+Thread-safe versions for name and address lookup are provided by
+.Fn lwres_gethostbyname_r ,
+and
+.Fn lwres_gethostbyaddr_r
+respectively.
+.Pp
+The resolver daemon does not currently support any non-DNS
+name services such as 
+.Pa /etc/hosts
+or
+.Dv NIS ,
+consequently the above functions don't, either.
diff --git a/doc/man/lwres/lwres_gethostent_r.3 b/doc/man/lwres/lwres_gethostent_r.3
new file mode 100644
index 00000000..d64587cb
--- /dev/null
+++ b/doc/man/lwres/lwres_gethostent_r.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gethostent_r.3,v 1.4 2000/11/18 03:00:22 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_getipnode.3 b/doc/man/lwres/lwres_getipnode.3
new file mode 100644
index 00000000..fde2479d
--- /dev/null
+++ b/doc/man/lwres/lwres_getipnode.3
@@ -0,0 +1,186 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_getipnode.3,v 1.5 2000/11/18 03:00:23 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_GETIPNODE 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_getipnodebyname ,
+.Nm lwres_getipnodebyaddr ,
+.Nm lwres_freehostent
+.Nd lightweight resolver nodename / address translation API
+.Sh SYNOPSIS
+.Fd #include <lwres/netdb.h>
+.Fd
+.Ft struct hostent *
+.Fo lwres_getipnodebyname
+.Fa "const char *name"
+.Fa "int af"
+.Fa "int flags"
+.Fa "int *error_num"
+.Fc
+.Ft struct hostent *
+.Fo lwres_getipnodebyaddr
+.Fa "const void *src"
+.Fa "size_t len"
+.Fa "int af"
+.Fa "int *error_num"
+.Fc
+.Ft void
+.Fo lwres_freehostent
+.Fa "struct hostent *he"
+.Fc
+.Sh DESCRIPTION
+These functions perform thread safe, protocol independent
+nodename-to-address and address-to-nodename 
+translation as defined in RFC2553.
+.Pp
+They use a
+.Dv "struct hostent"
+which is defined in
+.Pa namedb.h :
+.Bd -literal
+struct	hostent {
+	char	*h_name;	/* official name of host */
+	char	**h_aliases;	/* alias list */
+	int	h_addrtype;	/* host address type */
+	int	h_length;	/* length of address */
+	char	**h_addr_list;	/* list of addresses from name server */
+};
+#define	h_addr  h_addr_list[0]	/* address, for backward compatibility */
+.Ed
+.Pp
+The members of this structure are:
+.Bl -tag -width h_addr_list
+.It Li h_name
+The official (canonical) name of the host.
+.It Li h_aliases
+A NULL-terminated array of alternate names (nicknames) for the host.
+.It Li h_addrtype
+The type of address being returned - usually
+.Dv PF_INET
+or
+.Dv PF_INET6 .
+.It Li h_length
+The length of the address in bytes.
+.It Li h_addr_list
+A
+.Dv NULL
+terminated array of network addresses for the host.
+Host addresses are returned in network byte order.
+.El
+.Pp
+.Fn lwres_getipnodebyname
+looks up addresses of protocol family
+.Fa af 
+for the hostname
+.Fa name .
+The
+.Fa flags
+parameter contains ORed flag bits to 
+specify the types of addresses that are searched
+for, and the types of addresses that are returned. 
+The flag bits are:
+.Bl -tag -width AI_ADDRCONFIG
+.It Li AI_V4MAPPED
+This is used with an
+.Fa af
+of AF_INET6, and causes IPv4 addresses to be returned as IPv4-mapped
+IPv6 addresses.
+.It Li AI_ALL
+This is used with an
+.Fa af
+of AF_INET6, and causes all known addresses (IPv6 and IPv4) to be returned.
+If AI_V4MAPPED is also set, the IPv4 addresses are return as mapped
+IPv6 addresses.
+.It Li AI_ADDRCONFIG
+Only return an IPv6 or IPv4 address if here is an active network
+interface of that type.  This is not currently implemented
+in the BIND 9 lightweight resolver, and the flag is ignored.
+.It Li AI_DEFAULT
+This default sets the
+.Li AI_V4MAPPED
+and
+.Li AI_ADDRCONFIG
+flag bits.
+.El
+.Pp
+.Fn lwres_getipnodebyaddr
+performs a reverse lookup
+of address
+.Fa src
+which is
+.Fa len
+bytes long.
+.Fa af
+denotes the protocol family, typically
+.Dv PF_INET
+or
+.Dv PF_INET6 .
+.Pp
+.Fn lwres_freehostent
+releases all the memory associated with
+the
+.Dv "struct hostent"
+pointer
+.Fa he .
+Any memory allocated for the
+.Li h_name ,
+.Li h_addr_list
+and
+.Li h_aliases
+is freed, as is the memory for the
+.Dv hostent
+structure itself.
+.Sh RETURN VALUES
+If an error occurs,
+.Fn lwres_getipnodebyname
+and
+.Fn lwres_getipnodebyaddr
+set
+.Fa *error_num
+to an approriate error code and the function returns a
+.Dv NULL
+pointer.
+The error codes and their meanings are defined in
+.Pa <lwres/netdb.h> :
+.Bl -tag -width HOST_NOT_FOUND
+.It Li HOST_NOT_FOUND
+No such host is known.
+.It Li 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.
+.It Li TRY_AGAIN
+A temporary and possibly transient error occurred, such as a
+failure of a server to respond.  The request may succeed if
+retried.
+.It Li NO_RECOVERY
+An unexpected failure occurred, and retrying the request
+is pointless.
+.El
+.Pp
+.Xr lwres_hstrerror 3
+translates these error codes to suitable error messages.
+.Sh SEE ALSO
+.Xr RFC2553 ,
+.Xr lwres 3 ,
+.Xr lwres_gethostent 3 ,
+.Xr lwres_getaddrinfo 3 ,
+.Xr lwres_getnameinfo 3 ,
+.Xr lwres_hstrerror 3 .
diff --git a/doc/man/lwres/lwres_getipnodebyaddr.3 b/doc/man/lwres/lwres_getipnodebyaddr.3
new file mode 100644
index 00000000..975c3f37
--- /dev/null
+++ b/doc/man/lwres/lwres_getipnodebyaddr.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_getipnodebyaddr.3,v 1.4 2000/11/18 03:00:25 bwelling Exp $
+
+.so lwres_getipnode.3
diff --git a/doc/man/lwres/lwres_getipnodebyname.3 b/doc/man/lwres/lwres_getipnodebyname.3
new file mode 100644
index 00000000..d4cbb271
--- /dev/null
+++ b/doc/man/lwres/lwres_getipnodebyname.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_getipnodebyname.3,v 1.4 2000/11/18 03:00:26 bwelling Exp $
+
+.so lwres_getipnode.3
diff --git a/doc/man/lwres/lwres_getnamebyaddr.3 b/doc/man/lwres/lwres_getnamebyaddr.3
new file mode 100644
index 00000000..a52aacb5
--- /dev/null
+++ b/doc/man/lwres/lwres_getnamebyaddr.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_getnamebyaddr.3,v 1.4 2000/11/18 03:00:27 bwelling Exp $
+
+.so lwres_resutil.3
diff --git a/doc/man/lwres/lwres_getnameinfo.3 b/doc/man/lwres/lwres_getnameinfo.3
new file mode 100644
index 00000000..02342f6b
--- /dev/null
+++ b/doc/man/lwres/lwres_getnameinfo.3
@@ -0,0 +1,130 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_getnameinfo.3,v 1.7 2000/12/04 18:37:39 gson Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_GETNAMEINFO 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_getnameinfo
+.Nd lightweight resolver socket address structure to hostname and service name
+.Sh SYNOPSIS
+.Fd #include <lwres/netdb.h>
+.Fd
+.Ft int
+.Fo lwres_getnameinfo
+.Fa "const struct sockaddr *sa"
+.Fa "size_t salen"
+.Fa "char *host"
+.Fa "size_t hostlen"
+.Fa "char *serv"
+.Fa "size_t servlen"
+.Fa "int flags"
+.Fc
+.Sh DESCRIPTION
+.Pp
+This function is equivalent to the
+.Xr getnameinfo 3
+function defined in RFC2133.
+.Fn lwres_getnameinfo
+returns the hostname for the
+.Dv "struct sockaddr"
+.Fa sa
+which is
+.Fa salen
+bytes long.
+The hostname is of length
+.Fa hostlen
+and is returned via
+.Fa *host.
+The maximum length of the hostname is
+1025 bytes:
+.Li NI_MAXHOST .
+.Pp
+The name of the service associated with the port number in
+.Fa sa
+is returned in
+.Fa *serv.
+It is
+.Fa servlen
+bytes long.
+The maximum length of the service name is
+.Li NI_MAXSERV
+- 32 bytes.
+.Pp
+The
+.Fa flags
+argument sets the following bits:
+.Bl -tag -width NI_NUMERICSERV
+.It Li NI_NOFQDN
+A fully qualified domain name is not required for local hosts.
+The local part of the fully qualified domain name is returned instead.
+.It Li NI_NUMERICHOST
+Return the address in numeric form, as if calling inet_ntop(),
+instead of a host name.
+.It Li NI_NAMEREQD
+A name is required. If the hostname cannot be found in the DNS and
+this flag is set, a non-zero error code is returned.
+If the hostname is not found and the flag is not set, the 
+address is returned in numeric form.
+.It Li NI_NUMERICSERV
+The service name is returned as a digit string representing the port number.
+.It Li NI_DGRAM
+Specifies that the service being looked up 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.
+.El
+.Pp
+.Sh RETURN VALUES
+.Fn lwres_getnameinfo
+returns 0 on success or a non-zero error code if an error occurs.
+.\"
+.\"	The error codes below were invented by the ISC/Nominum. They
+.\"	should be defined in RFC2133 before getting documented here.
+.\"	XXXJR 28/6/00
+.\" The error codes are:
+.\" Bl -tag -width ENI_NOSERVNAME
+.\" It Li ENI_NOSOCKET
+.\" there was no socket in
+.\" Fa sa
+.\" It Li ENI_NOSERVNAME
+.\" no service name was found
+.\" It Li ENI_NOHOSTNAME
+.\" no hostname was found
+.\" It Li ENI_MEMORY
+.\" memory could not be allocated
+.\" It Li ENI_SYSTEM
+.\" a system error occurred
+.\" It Li ENI_FAMILY
+.\" an unsupported protocol family was requested
+.\" It Li ENI_SALEN
+.\" Fa salen
+.\" is the wrong number of bytes for the address in
+.\" Fa sa .
+.Sh SEE ALSO
+.Xr RFC2133 ,
+.Xr getservbyport 3 ,
+.Xr lwres 3 ,
+.Xr lwres_getnameinfo 3 ,
+.Xr lwres_getnamebyaddr 3 .
+.Xr lwres_net_ntop 3 .
+.Sh BUGS
+RFC2133 fails to define what the nonzero return values of
+.Xr getnameinfo 3 
+are.
diff --git a/doc/man/lwres/lwres_getrrsetbyname.3 b/doc/man/lwres/lwres_getrrsetbyname.3
new file mode 100644
index 00000000..e1670b06
--- /dev/null
+++ b/doc/man/lwres/lwres_getrrsetbyname.3
@@ -0,0 +1,132 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_getrrsetbyname.3,v 1.3 2000/11/29 22:55:11 gson Exp $
+
+.Dd Oct 18, 2000
+.Dt LWRES_GETRRSETBYNAME 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_getrrsetbyname ,
+.Nm lwres_freerrset
+.Nd retrieve DNS records
+.Sh SYNOPSIS
+.Fd #include <lwres/netdb.h>
+.Fd
+.Ft int
+.Fo lwres_getrrsetbyname
+.Fa "const char *hostname"
+.Fa "unsigned int rdclass"
+.Fa "unsigned int rdtype"
+.Fa "unsigned int flags"
+.Fa "struct rrsetinfo **res"
+.Fc
+.Ft void
+.Fo lwres_freerrset
+.Fa "struct rrsetinfo *rrset"
+.Fc
+.Pp
+The following structures are used:
+.Pp
+.Bd -literal -offset indent
+struct 	rdatainfo {
+	unsigned int		rdi_length;	/* length of data */
+	unsigned char		*rdi_data;	/* record data */
+};
+
+struct	rrsetinfo {
+	unsigned int		rri_flags;	/* RRSET_VALIDATED... */
+	unsigned int		rri_rdclass;	/* class number */
+	unsigned int		rri_rdtype;	/* RR type number */
+	unsigned int		rri_ttl;	/* time to live */
+	unsigned int		rri_nrdatas;	/* size of rdatas array */
+	unsigned int		rri_nsigs;	/* size of sigs array */
+	char			*rri_name;	/* canonical name */
+	struct rdatainfo	*rri_rdatas;	/* individual records */
+	struct rdatainfo	*rri_sigs;	/* individual signatures */
+};
+.Ed
+.Sh DESCRIPTION
+.Pp
+.Fn lwres_getrrsetbyname
+gets a set of resource records associated with a
+.Fa hostname ,
+.Fa class ,
+and
+.Fa type .
+.Fa hostname
+is
+a pointer a to null-terminated string.  The
+.Fa flags
+field is currently unused and must be zero.
+.Pp
+After a successful call to
+.Fn lwres_getrrsetbyname ,
+.Fa *res
+is a pointer to an
+.Dv rrsetinfo
+structure, containing a list of one or more
+.Dv rdatainfo
+structures containing resource records and potentially another list of
+.Dv rdatainfo
+structures containing SIG resource records
+associated with those records.
+The members
+.Li rri_rdclass
+and
+.Li rri_rdtype
+are copied from the parameters.
+.Li rri_ttl
+and
+.Li rri_name
+are properties of the obtained rrset.
+The resource records contained in
+.Li rri_rdatas
+and
+.Li rri_sigs
+are in uncompressed DNS wire format.
+Properties of the rdataset are represented in the
+.Li rri_flags
+bitfield.  If the RRSET_VALIDATED bit is set, the data has been DNSSEC
+validated and the signatures verified.  
+.Pp
+All of the information returned by
+.Fn lwres_getrrsetbyname
+is dynamically allocated: the
+.Li rrsetinfo
+and
+.Li rdatainfo
+structures,
+and the canonical host name strings pointed to by the
+.Li rrsetinfo structure.
+Memory allocated for the dynamically allocated structures created by
+a successful call to
+.Fn lwres_getrrsetbyname
+is released by
+.Fn lwres_freerrset .
+.Fa rrset
+is a pointer to a
+.Dv "struct rrset"
+created by a call to
+.Fn lwres_getrrsetbyname .
+.Pp
+.Sh RETURN VALUES
+.Fn lwres_getrrsetbyname
+returns zero on success or an error code if an error occurs.  The defined
+error codes are ERRSET_NOMEMORY (memory could not be allocated),
+ERRSET_INVAL (a parameter is invalid) and ERRSET_FAIL (other failure).
+.Sh SEE ALSO
+.Xr lwres 3 .
diff --git a/doc/man/lwres/lwres_gnba.3 b/doc/man/lwres/lwres_gnba.3
new file mode 100644
index 00000000..a86587b5
--- /dev/null
+++ b/doc/man/lwres/lwres_gnba.3
@@ -0,0 +1,200 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gnba.3,v 1.5 2000/11/18 03:00:30 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_GNBA 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_gnbarequest_render ,
+.Nm lwres_gnbaresponse_render ,
+.Nm lwres_gnbarequest_parse ,
+.Nm lwres_gnbaresponse_parse ,
+.Nm lwres_gnbaresponse_free ,
+.Nm lwres_gnbarequest_free
+.Nd lightweight resolver getnamebyaddress message handling
+.Sh SYNOPSIS
+.Fd #include <lwres/lwres.h>
+.Fd
+.Ft lwres_result_t
+.Fo lwres_gnbarequest_render
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_gnbarequest_t *req"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_gnbaresponse_render
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_gnbaresponse_t *req"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_gnbarequest_parse
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_gnbarequest_t **structp"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_gnbaresponse_parse
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_gnbaresponse_t **structp"
+.Fc
+.Ft void
+.Fo lwres_gnbaresponse_free
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_gnbaresponse_t **structp"
+.Fc
+.Ft void
+.Fo lwres_gnbarequest_free
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_gnbarequest_t **structp"
+.Fc
+.Sh DESCRIPTION
+These are low-level routines for creating and parsing
+lightweight resolver address-to-name lookup request and 
+response messages.
+.Pp
+There are four main functions for the getnamebyaddr opcode.
+One render function converts a getnamebyaddr request structure -
+.Dv lwres_gnbarequest_t -
+to the lighweight resolver's canonical format.
+It is complemented by a parse function that converts a packet in this
+canonical format to a getnamebyaddr request structure.
+Another render function converts the getnamebyaddr response structure -
+.Dv lwres_gnbaresponse_t
+to the canonical format.
+This is complemented by a parse function which converts a packet in
+canonical format to a getnamebyaddr response structure.
+.Pp
+These structures are defined in
+.Pa lwres/lwres.h .
+They are shown below.
+.Bd -literal -offset indent
+#define LWRES_OPCODE_GETNAMEBYADDR	0x00010002U
+
+typedef struct {
+	lwres_uint32_t	flags;
+	lwres_addr_t	addr;
+} lwres_gnbarequest_t;
+
+typedef struct {
+	lwres_uint32_t	flags;
+	lwres_uint16_t	naliases;
+	char	       *realname;
+	char	      **aliases;
+	lwres_uint16_t	realnamelen;
+	lwres_uint16_t *aliaslen;
+	void	       *base;
+	size_t		baselen;
+} lwres_gnbaresponse_t;
+.Ed
+.Pp
+.Fn lwres_gnbarequest_render
+uses resolver context
+.Fa ctx
+to convert getnamebyaddr request structure
+.Fa req
+to canonical format.
+The packet header structure
+.Fa pkt
+is initialised and transferred to
+buffer
+.Fa b .
+The contents of
+.Fa *req
+are then appended to the buffer in canonical format.
+.Fn lwres_gnbaresponse_render
+performs the same task, except it converts a getnamebyaddr response structure
+.Dv lwres_gnbaresponse_t
+to the lightweight resolver's canonical format.
+.Pp
+.Fn lwres_gnbarequest_parse
+uses context
+.Fa ctx
+to convert the contents of packet
+.Fa pkt
+to a
+.Dv lwres_gnbarequest_t
+structure.
+Buffer
+.Fa b
+provides space to be used for storing this structure.
+When the function succeeds, the resulting
+.Dv lwres_gnbarequest_t
+is made available through
+.Fa *structp .
+.Fn lwres_gnbaresponse_parse
+offers the same semantics as
+.Fn lwres_gnbarequest_parse
+except it yields a
+.Dv lwres_gnbaresponse_t
+structure.
+.Pp
+.Fn lwres_gnbaresponse_free
+and
+.Fn lwres_gnbarequest_free
+release the memory in resolver context
+.Fa ctx
+that was allocated to the
+.Dv lwres_gnbaresponse_t
+or
+.Dv lwres_gnbarequest_t
+structures referenced via
+.Fa structp .
+Any memory associated with ancillary buffers and strings for those
+structures is also discarded.
+.Sh RETURN VALUES
+The getnamebyaddr opcode functions
+.Fn lwres_gnbarequest_render ,
+.Fn lwres_gnbaresponse_render
+.Fn lwres_gnbarequest_parse
+and
+.Fn lwres_gnbaresponse_parse
+all return
+.Er LWRES_R_SUCCESS
+on success.
+They return
+.Er LWRES_R_NOMEMORY
+if memory allocation fails.
+.Er LWRES_R_UNEXPECTEDEND
+is returned if the available space in the buffer
+.Fa b
+is too small to accommodate the packet header or the
+.Dv lwres_gnbarequest_t
+and
+.Dv lwres_gnbaresponse_t
+structures.
+.Fn lwres_gnbarequest_parse
+and
+.Fn lwres_gnbaresponse_parse
+will return
+.Er LWRES_R_UNEXPECTEDEND
+if the buffer is not empty after decoding the received packet.
+These functions will return
+.Er LWRES_R_FAILURE
+if
+.Li pktflags
+in the packet header structure
+.Dv lwres_lwpacket_t
+indicate that the packet is not a response to an earlier query.
+.Sh SEE ALSO
+.Xr lwres_packet 3
diff --git a/doc/man/lwres/lwres_gnbarequest_free.3 b/doc/man/lwres/lwres_gnbarequest_free.3
new file mode 100644
index 00000000..fc64030e
--- /dev/null
+++ b/doc/man/lwres/lwres_gnbarequest_free.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gnbarequest_free.3,v 1.4 2000/11/18 03:00:31 bwelling Exp $
+
+.so lwres_gnba.3
diff --git a/doc/man/lwres/lwres_gnbarequest_parse.3 b/doc/man/lwres/lwres_gnbarequest_parse.3
new file mode 100644
index 00000000..32f2a974
--- /dev/null
+++ b/doc/man/lwres/lwres_gnbarequest_parse.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gnbarequest_parse.3,v 1.4 2000/11/18 03:00:33 bwelling Exp $
+
+.so lwres_gnba.3
diff --git a/doc/man/lwres/lwres_gnbarequest_render.3 b/doc/man/lwres/lwres_gnbarequest_render.3
new file mode 100644
index 00000000..0ba9b8b7
--- /dev/null
+++ b/doc/man/lwres/lwres_gnbarequest_render.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gnbarequest_render.3,v 1.4 2000/11/18 03:00:34 bwelling Exp $
+
+.so lwres_gnba.3
diff --git a/doc/man/lwres/lwres_gnbaresponse_free.3 b/doc/man/lwres/lwres_gnbaresponse_free.3
new file mode 100644
index 00000000..f2c09474
--- /dev/null
+++ b/doc/man/lwres/lwres_gnbaresponse_free.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gnbaresponse_free.3,v 1.4 2000/11/18 03:00:36 bwelling Exp $
+
+.so lwres_gnba.3
diff --git a/doc/man/lwres/lwres_gnbaresponse_parse.3 b/doc/man/lwres/lwres_gnbaresponse_parse.3
new file mode 100644
index 00000000..c0d61e9d
--- /dev/null
+++ b/doc/man/lwres/lwres_gnbaresponse_parse.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gnbaresponse_parse.3,v 1.4 2000/11/18 03:00:37 bwelling Exp $
+
+.so lwres_gnba.3
diff --git a/doc/man/lwres/lwres_gnbaresponse_render.3 b/doc/man/lwres/lwres_gnbaresponse_render.3
new file mode 100644
index 00000000..78365448
--- /dev/null
+++ b/doc/man/lwres/lwres_gnbaresponse_render.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_gnbaresponse_render.3,v 1.4 2000/11/18 03:00:38 bwelling Exp $
+
+.so lwres_gnba.3
diff --git a/doc/man/lwres/lwres_herror.3 b/doc/man/lwres/lwres_herror.3
new file mode 100644
index 00000000..2eb2dbd5
--- /dev/null
+++ b/doc/man/lwres/lwres_herror.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_herror.3,v 1.4 2000/11/18 03:00:39 bwelling Exp $
+
+.so lwres_hstrerror.3
diff --git a/doc/man/lwres/lwres_hstrerror.3 b/doc/man/lwres/lwres_hstrerror.3
new file mode 100644
index 00000000..ed7b9a2f
--- /dev/null
+++ b/doc/man/lwres/lwres_hstrerror.3
@@ -0,0 +1,72 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_hstrerror.3,v 1.5 2000/12/04 18:37:40 gson Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_ERROR 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_herror ,
+.Nm lwres_hstrerror
+.Nd lightweight resolver error message generation
+.Sh SYNOPSIS
+.Fd #include <lwres/netdb.h>
+.Fd
+.Ft void
+.Fo lwres_herror
+.Fa "const char *s"
+.Fc
+.Ft const char *
+.Fo lwres_hstrerror
+.Fa "int err"
+.Fc
+.Sh DESCRIPTION
+.Fn lwres_herror
+prints the string
+.Fa s
+on
+.Dv stderr
+followed by the string generated by
+.Fn lwres_hstrerror
+for the error code stored in the global variable
+.Li lwres_h_errno .
+.Pp
+.Fn lwres_hstrerror
+returns an appropriate string for the error code gievn by
+.Fa err .
+The values of the error codes and messages are as follows:
+.Bl -tag -width HOST_NOT_FOUND
+.It Li NETDB_SUCCESS
+\*qResolver Error 0 (no error)\*q
+.It Li HOST_NOT_FOUND
+\*qUnknown host\*q
+.It Li TRY_AGAIN
+\*qHost name lookup failure\*q
+.It Li NO_RECOVERY
+\*qUnknown server error\*q
+.It Li NO_DATA
+\*qNo address associated with name\*q
+.El
+.Sh RETURN VALUES
+The string \*qUnknown resolver error\*q is returned by
+.Fn lwres_hstrerror
+when the value of
+.Li lwres_h_errno
+is not a valid error code.
+.Sh SEE ALSO
+.Xr herror 3 ,
+.Xr lwres_hstrerror 3 .
diff --git a/doc/man/lwres/lwres_inetntop.3 b/doc/man/lwres/lwres_inetntop.3
new file mode 100644
index 00000000..c10f19ab
--- /dev/null
+++ b/doc/man/lwres/lwres_inetntop.3
@@ -0,0 +1,71 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_inetntop.3,v 1.4 2000/11/18 03:00:43 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_INETNTOP 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_net_ntop
+.Nd lightweight resolver IP address presentation
+.Sh SYNOPSIS
+.Fd #include <lwres/net.h>
+.Fd
+.Ft const char *
+.Fo lwres_net_ntop
+.Fa "int af"
+.Fa "const void *src"
+.Fa "char *dst"
+.Fa "size_t size"
+.Fc
+.Sh DESCRIPTION
+.Fn lwres_net_ntop
+converts an IP address of protocol family
+.Fa af
+- IPv4 or IPv6 - at location
+.Fa src
+from network format to its conventional representation as a string.
+For IPv4 addresses, that string would be a dotted-decimal.
+An IPv6 address would be represented in colon notation as described in
+RFC1884.
+.Pp
+The generated string is copied to
+.Fa dst
+provided
+.Fa size
+indicates it is long enough to store the ASCII representation
+of the address.
+.Sh RETURN VALUES
+.Pp
+If successful, the function returns
+.Fa dst :
+a pointer to a string containing
+the presentation format of the address.
+.Fn lwres_net_ntop
+returns
+.Dv NULL
+and sets the global variable
+.Li errno
+to
+.Er EAFNOSUPPORT
+if the protocol family given in
+.Fa af
+is not supported.
+.Sh SEE ALSO
+.Xr RFC1884 ,
+.Xr inet_ntop 3 ,
+.Xr errno 3 .
diff --git a/doc/man/lwres/lwres_lwpacket_parseheader.3 b/doc/man/lwres/lwres_lwpacket_parseheader.3
new file mode 100644
index 00000000..cd41ee6b
--- /dev/null
+++ b/doc/man/lwres/lwres_lwpacket_parseheader.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_lwpacket_parseheader.3,v 1.4 2000/11/18 03:00:44 bwelling Exp $
+
+.so lwres_packet.3
diff --git a/doc/man/lwres/lwres_lwpacket_renderheader.3 b/doc/man/lwres/lwres_lwpacket_renderheader.3
new file mode 100644
index 00000000..1b1cd335
--- /dev/null
+++ b/doc/man/lwres/lwres_lwpacket_renderheader.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_lwpacket_renderheader.3,v 1.4 2000/11/18 03:00:45 bwelling Exp $
+
+.so lwres_packet.3
diff --git a/doc/man/lwres/lwres_net_ntop.3 b/doc/man/lwres/lwres_net_ntop.3
new file mode 100644
index 00000000..59b0fa5d
--- /dev/null
+++ b/doc/man/lwres/lwres_net_ntop.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_net_ntop.3,v 1.4 2000/11/18 03:00:46 bwelling Exp $
+
+.so lwres_inetntop.3
diff --git a/doc/man/lwres/lwres_noop.3 b/doc/man/lwres/lwres_noop.3
new file mode 100644
index 00000000..e4fd5e5e
--- /dev/null
+++ b/doc/man/lwres/lwres_noop.3
@@ -0,0 +1,199 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_noop.3,v 1.5 2000/11/18 03:00:47 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_NOOP 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_nooprequest_render ,
+.Nm lwres_noopresponse_render ,
+.Nm lwres_nooprequest_parse ,
+.Nm lwres_noopresponse_parse ,
+.Nm lwres_noopresponse_free ,
+.Nm lwres_nooprequest_free
+.Nd lightweight resolver no-op message handling
+.Sh SYNOPSIS
+.Fd #include <lwres/lwres.h>
+.Fd
+.Ft lwres_result_t
+.Fo lwres_nooprequest_render
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_nooprequest_t *req"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_noopresponse_render
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_noopresponse_t *req"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_buffer_t *b"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_nooprequest_parse
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_nooprequest_t **structp"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_noopresponse_parse
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_lwpacket_t *pkt"
+.Fa "lwres_noopresponse_t **structp"
+.Fc
+.Ft void
+.Fo lwres_noopresponse_free
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_noopresponse_t **structp"
+.Fc
+.Ft void
+.Fo lwres_nooprequest_free
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_nooprequest_t **structp"
+.Fc
+.Sh DESCRIPTION
+These are low-level routines for creating and parsing
+lightweight resolver no-op request and response messages.
+.P
+The no-op message is analogous to a \*qping\*q packet: 
+a packet is sent to the resolver daemon and is simply echoed back.
+The opcode is intended to allow a client to determine if the server is
+operational or not.
+.Pp
+There are four main functions for the no-op opcode.
+One render function converts a no-op request structure -
+.Dv lwres_nooprequest_t -
+to the lighweight resolver's canonical format.
+It is complemented by a parse function that converts a packet in this
+canonical format to a no-op request structure.
+Another render function converts the no-op response structure -
+.Dv lwres_noopresponse_t
+to the canonical format.
+This is complemented by a parse function which converts a packet in
+canonical format to a no-op response structure.
+.Pp
+These structures are defined in
+.Pa lwres/lwres.h .
+They are shown below.
+.Bd -literal -offset indent
+#define LWRES_OPCODE_NOOP	0x00000000U
+
+typedef struct {
+	lwres_uint16_t	datalength;
+	unsigned char   *data;
+} lwres_nooprequest_t;
+
+typedef struct {
+	lwres_uint16_t	datalength;
+	unsigned char	*data;
+} lwres_noopresponse_t;
+.Ed
+Although the structures have different types, they are identical.
+This is because the no-op opcode simply echos whatever data was sent:
+the response is therefore identical to the request.
+.Pp
+.Fn lwres_nooprequest_render
+uses resolver context
+.Fa ctx
+to convert no-op request structure
+.Fa req
+to canonical format.
+The packet header structure
+.Fa pkt
+is initialised and transferred to
+buffer
+.Fa b .
+The contents of
+.Fa *req
+are then appended to the buffer in canonical format.
+.Fn lwres_noopresponse_render
+performs the same task, except it converts a no-op response structure
+.Dv lwres_noopresponse_t
+to the lightweight resolver's canonical format.
+.Pp
+.Fn lwres_nooprequest_parse
+uses context
+.Fa ctx
+to convert the contents of packet
+.Fa pkt
+to a
+.Dv lwres_nooprequest_t
+structure.
+Buffer
+.Fa b
+provides space to be used for storing this structure.
+When the function succeeds, the resulting
+.Dv lwres_nooprequest_t
+is made available through
+.Fa *structp .
+.Fn lwres_noopresponse_parse
+offers the same semantics as
+.Fn lwres_nooprequest_parse
+except it yields a
+.Dv lwres_noopresponse_t
+structure.
+.Pp
+.Fn lwres_noopresponse_free
+and
+.Fn lwres_nooprequest_free
+release the memory in resolver context
+.Fa ctx
+that was allocated to the
+.Dv lwres_noopresponse_t
+or
+.Dv lwres_nooprequest_t
+structures referenced via
+.Fa structp .
+.Sh RETURN VALUES
+The no-op opcode functions
+.Fn lwres_nooprequest_render ,
+.Fn lwres_noopresponse_render
+.Fn lwres_nooprequest_parse
+and
+.Fn lwres_noopresponse_parse
+all return
+.Er LWRES_R_SUCCESS
+on success.
+They return
+.Er LWRES_R_NOMEMORY
+if memory allocation fails.
+.Er LWRES_R_UNEXPECTEDEND
+is returned if the available space in the buffer
+.Fa b
+is too small to accommodate the packet header or the
+.Dv lwres_nooprequest_t
+and
+.Dv lwres_noopresponse_t
+structures.
+.Fn lwres_nooprequest_parse
+and
+.Fn lwres_noopresponse_parse
+will return
+.Er LWRES_R_UNEXPECTEDEND
+if the buffer is not empty after decoding the received packet.
+These functions will return
+.Er LWRES_R_FAILURE
+if
+.Li pktflags
+in the packet header structure
+.Dv lwres_lwpacket_t
+indicate that the packet is not a response to an earlier query.
+.Sh SEE ALSO
+.Xr lwres_packet 3
diff --git a/doc/man/lwres/lwres_nooprequest_free.3 b/doc/man/lwres/lwres_nooprequest_free.3
new file mode 100644
index 00000000..821ab56f
--- /dev/null
+++ b/doc/man/lwres/lwres_nooprequest_free.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_nooprequest_free.3,v 1.4 2000/11/18 03:00:48 bwelling Exp $
+
+.so lwres_noop.3
diff --git a/doc/man/lwres/lwres_nooprequest_parse.3 b/doc/man/lwres/lwres_nooprequest_parse.3
new file mode 100644
index 00000000..05606c10
--- /dev/null
+++ b/doc/man/lwres/lwres_nooprequest_parse.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_nooprequest_parse.3,v 1.4 2000/11/18 03:00:50 bwelling Exp $
+
+.so lwres_noop.3
diff --git a/doc/man/lwres/lwres_nooprequest_render.3 b/doc/man/lwres/lwres_nooprequest_render.3
new file mode 100644
index 00000000..394b9097
--- /dev/null
+++ b/doc/man/lwres/lwres_nooprequest_render.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_nooprequest_render.3,v 1.4 2000/11/18 03:00:51 bwelling Exp $
+
+.so lwres_noop.3
diff --git a/doc/man/lwres/lwres_noopresponse_free.3 b/doc/man/lwres/lwres_noopresponse_free.3
new file mode 100644
index 00000000..7114f96e
--- /dev/null
+++ b/doc/man/lwres/lwres_noopresponse_free.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_noopresponse_free.3,v 1.4 2000/11/18 03:00:53 bwelling Exp $
+
+.so lwres_noop.3
diff --git a/doc/man/lwres/lwres_noopresponse_parse.3 b/doc/man/lwres/lwres_noopresponse_parse.3
new file mode 100644
index 00000000..ae078db9
--- /dev/null
+++ b/doc/man/lwres/lwres_noopresponse_parse.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_noopresponse_parse.3,v 1.4 2000/11/18 03:00:54 bwelling Exp $
+
+.so lwres_noop.3
diff --git a/doc/man/lwres/lwres_noopresponse_render.3 b/doc/man/lwres/lwres_noopresponse_render.3
new file mode 100644
index 00000000..ee1d3bf5
--- /dev/null
+++ b/doc/man/lwres/lwres_noopresponse_render.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_noopresponse_render.3,v 1.4 2000/11/18 03:00:55 bwelling Exp $
+
+.so lwres_noop.3
diff --git a/doc/man/lwres/lwres_packet.3 b/doc/man/lwres/lwres_packet.3
new file mode 100644
index 00000000..035da6d3
--- /dev/null
+++ b/doc/man/lwres/lwres_packet.3
@@ -0,0 +1,164 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_packet.3,v 1.5 2000/11/18 03:00:56 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_PACKET 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_lwpacket_renderheader ,
+.Nm lwres_lwpacket_parseheader
+.Nd lightweight resolver packet handling functions
+.Sh SYNOPSIS
+.Fd #include <lwres/lwbuffer.h>
+.Fd #include <lwres/lwpacket.h>
+.Fd #include <lwres/result.h>
+.Fd
+.Ft lwres_result_t
+.Fo lwres_lwpacket_renderheader
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_lwpacket_t *pkt"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_lwpacket_parseheader
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_lwpacket_t *pkt"
+.Fc
+.Sh DESCRIPTION
+These functions rely on a
+.Dv "struct lwres_lwpacket"
+which is defined in
+.Pa lwres/lwpacket.h .
+.Bd -literal -offset indent
+typedef struct lwres_lwpacket lwres_lwpacket_t;
+
+struct lwres_lwpacket {
+	lwres_uint32_t		length;
+	lwres_uint16_t		version;
+	lwres_uint16_t		pktflags;
+	lwres_uint32_t		serial;
+	lwres_uint32_t		opcode;
+	lwres_uint32_t		result;
+	lwres_uint32_t		recvlength;
+	lwres_uint16_t		authtype;
+	lwres_uint16_t		authlength;
+};
+.Ed
+.Pp
+.Pp
+The elements of this structure are:
+.Bl -tag -width recvlength
+.It Li length
+the overall packet length, including the entire packet header.
+This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
+calls.
+.It Li version
+the header format. There is currently only one format,
+.Dv LWRES_LWPACKETVERSION_0 .
+This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
+calls.
+.It Li pktflags
+library-defined flags for this packet: for instance whether the packet
+is a request or a reply. Flag values can be set, but not defined by
+the caller.
+This field is filled in by the application wit the exception of the
+LWRES_LWPACKETFLAG_RESPONSE bit, which is set by the library in the
+lwres_gabn_*() and lwres_gnba_*() calls.
+.It Li serial
+is set by the requestor and is returned in all replies. If two or more
+packets from the same source have the same serial number and are from
+the same source, they are assumed to be duplicates and the latter ones
+may be dropped.
+This field must be set by the application.
+.It Li opcode
+indicates the operation.
+Opcodes between 0x00000000 and 0x03ffffff are
+reserved for use by the lightweight resolver library. Opcodes between
+0x04000000 and 0xffffffff are application defined.
+This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
+calls.
+.It Li result
+is only valid for replies.
+Results between 0x04000000 and 0xffffffff are application defined.
+Results between 0x00000000 and 0x03ffffff are reserved for library use.
+This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
+calls.
+.It Li recvlength
+is the maximum buffer size that the receiver can handle on requests
+and the size of the buffer needed to satisfy a request when the buffer
+is too large for replies.
+This field is supplied by the application.
+.It Li authtype
+defines the packet level authentication that is used.
+Authorisation types between 0x1000 and 0xffff are application defined
+and types between 0x0000 and 0x0fff are reserved for library use.
+Currently these are not used and must be zero.
+.It Li authlen
+gives the length of the authentication data.
+Since packet authentication is currently not used, this must be zero.
+.El
+.Pp
+The following opcodes are currently defined:
+.Bl -tag -width GETADDRSBYNAME
+.It Li NOOP
+Success is always returned and the packet contents are echoed.
+The lwres_noop_*() functions should be used for this type.
+.It Li GETADDRSBYNAME
+returns all known addresses for a given name.
+The lwres_gabn_*() functions should be used for this type.
+.It Li GETNAMEBYADDR
+return the hostname for the given address.
+The lwres_gnba_*() functions should be used for this type.
+.El
+.Pp
+.Fn lwres_lwpacket_renderheader
+transfers the contents of lightweight resolver packet structure
+.Dv lwres_lwpacket_t
+.Fa *pkt
+in network byte order to the lightweight resolver buffer,
+.Fa *b .
+.Pp
+.Fn lwres_lwpacket_parseheader
+performs the converse operation.
+It transfers data in network byte order from buffer
+.Fa *b
+to resolver packet
+.Fa *pkt .
+The contents of the buffer
+.Fa b
+should correspond to a
+.Dv "lwres_lwpacket_t" .
+.Pp
+Both functions have assertion checks to ensure that
+.Fa b
+and
+.Fa pkt
+are not
+.Dv NULL .
+.Sh RETURN VALUES
+Successful calls to
+.Fn lwres_lwpacket_renderheader
+and
+.Fn lwres_lwpacket_parseheader
+return
+.Er LWRES_R_SUCCESS .
+If there is insufficient space to copy data between the buffer
+.Fa *b
+and lightweight resolver packet
+.Fa *pkt
+both functions return
+.Er LWRES_R_UNEXPECTEDEND .
diff --git a/doc/man/lwres/lwres_resutil.3 b/doc/man/lwres/lwres_resutil.3
new file mode 100644
index 00000000..d8ba526f
--- /dev/null
+++ b/doc/man/lwres/lwres_resutil.3
@@ -0,0 +1,215 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_resutil.3,v 1.4 2000/11/18 03:00:57 bwelling Exp $
+
+.Dd Jun 30, 2000
+.Dt LWRES_RESUTIL 3
+.Os BIND9 9
+.ds vT BIND9 Programmer's Manual
+.Sh NAME
+.Nm lwres_string_parse ,
+.Nm lwres_addr_parse ,
+.Nm lwres_getaddrsbyname ,
+.Nm lwres_getnamebyaddr
+.Nd lightweight resolver utility functions
+.Sh SYNOPSIS
+.Fd #include <lwres/lwres.h>
+.Fd
+.Ft lwres_result_t
+.Fo lwres_string_parse
+.Fa "lwres_buffer_t *b"
+.Fa "char **c"
+.Fa "lwres_uint16_t *len"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_addr_parse
+.Fa "lwres_buffer_t *b"
+.Fa "lwres_addr_t *addr"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_getaddrsbyname
+.Fa "lwres_context_t *ctx"
+.Fa "const char *name"
+.Fa "lwres_uint32_t addrtypes"
+.Fa "lwres_gabnresponse_t **structp"
+.Fc
+.Ft lwres_result_t
+.Fo lwres_getnamebyaddr
+.Fa "lwres_context_t *ctx"
+.Fa "lwres_uint32_t addrtype"
+.Fa "lwres_uint16_t addrlen"
+.Fa "const unsigned char *addr"
+.Fa "lwres_gnbaresponse_t **structp"
+.Fc
+.Sh DESCRIPTION
+.Fn lwres_string_parse
+retrieves a DNS-encoded string starting the current pointer of
+lightweight resolver buffer
+.Fa b :
+i.e.
+.Li b->current .
+When the function returns, the address of the first byte of the
+encoded string is returned via
+.Fa *c
+and the length of that string is given by
+.Fa *len .
+The buffer's current pointer is advanced to point at the character
+following the string length, the encoded string, and the trailing
+.Dv NULL
+character.
+.Fn lwres_string_parse
+has an assertion check that
+.Fa b
+is not
+.Dv NULL .
+.Pp
+.Fn lwres_addr_parse
+extracts an address from the buffer
+.Fa b .
+It checks that
+.Fa addr
+is not null.
+The buffer's current pointer
+.Li b->current
+is presumed to point at an encoded address: the address preceded by a
+32-bit protocol family identifier and a 16-bit length field.
+The encoded address is copied to
+.Li addr->address
+and
+.Li addr->length
+indicates the size in bytes of the address that was copied.
+.Li b->current
+is advanced to point at the next byte of available data in the buffer
+following the encoded address.
+.Pp
+.Fn lwres_getaddrsbyname
+and
+.Fn lwres_getnamebyaddr
+use the
+.Dv "lwres_gnbaresponse_t"
+structure defined below:
+.Bd -literal -offset indent
+typedef struct {
+	lwres_uint32_t		flags;
+	lwres_uint16_t		naliases;
+	lwres_uint16_t		naddrs;
+	char		       *realname;
+	char		      **aliases;
+	lwres_uint16_t		realnamelen;
+	lwres_uint16_t	       *aliaslen;
+	lwres_addrlist_t	addrs;
+	void		       *base;
+	size_t			baselen;
+} lwres_gabnresponse_t;
+.Ed
+The contents of this structure are not manipulated directly but
+they are controlled through the
+.Xr lwres_gabn 3
+functions.
+.Pp
+The lightweight resolver uses
+.Fn lwres_getaddrsbyname
+to perform foward lookups.
+Hostname
+.Fa name
+is looked up using the resolver context
+.Fa ctx
+for memory allocation.
+.Fa addrtypes
+is a bitmask indicating which type of addresses are to be looked up.
+Current values for this bitmask are
+.Dv LWRES_ADDRTYPE_V4
+for IPv4 addresses and
+.Dv LWRES_ADDRTYPE_V6
+for IPv6 addresses.
+Results of the lookup are returned in
+.Fa *structp .
+.Fn lwres_getaddrsbyname
+checks that its pointer arguments are not
+.Dv NULL
+and that
+.Fa addrtypes
+is non-zero.
+.Pp
+.Fn lwres_getnamebyaddr
+performs reverse lookups.
+Resolver context
+.Fa ctx
+is used for memory allocation.
+The address type is indicated by
+.Fa addrtype :
+.Dv LWRES_ADDRTYPE_V4
+or
+.Dv LWRES_ADDRTYPE_V6 .
+The address to be looked up is given by
+.Fa addr
+and its length is
+.Fa addrlen
+bytes.
+The result of the function call is made available through
+.Fa *structp .
+Like
+.Fn lwres_getaddrsbyname ,
+.Fn lwres_getnamebyaddr
+uses assertion checking to ensure its pointer arguments are not
+.Dv NULL
+and
+.Fa addrtype
+is not zero.
+.Fn lwres_getaddrsbyname
+also checks that
+.Fa addrlen
+is non-zero.
+.Sh RETURN VALUES
+Successful calls to
+.Fn lwres_string_parse
+and
+.Fn lwres_addr_parse
+return
+.Er LWRES_R_SUCCESS.
+Both functions return
+.Er LWRES_R_FAILURE
+if the buffer is corrupt or
+.Er LWRES_R_UNEXPECTEDEND
+if the buffer has less space than expected for the components of the
+encoded string or address.
+.Pp
+.Fn lwres_getaddrsbyname
+returns
+.Er LWRES_R_SUCCESS
+on success and it returns
+.Er LWRES_R_NOTFOUND
+if the hostname
+.Fa name
+could not be found.
+.Pp
+.Er LWRES_R_SUCCESS
+is returned by a successful call to
+.Fn lwres_getnamebyaddr .
+.Pp
+Both
+.Fn lwres_getaddrsbyname
+and
+.Fn lwres_getnamebyaddr
+return
+.Er LWRES_R_NOMEMORY
+when memory allocation requests fail and
+.Er LWRES_R_UNEXPECTEDEND
+if the buffers used for sending queries and receiving replies are too
+small.
+.Sh SEE ALSO
+.Xr lwres_buffer 3 ,
+.Xr lwres_gabn 3 .
diff --git a/doc/man/lwres/lwres_sethostent.3 b/doc/man/lwres/lwres_sethostent.3
new file mode 100644
index 00000000..40fdd38c
--- /dev/null
+++ b/doc/man/lwres/lwres_sethostent.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_sethostent.3,v 1.4 2000/11/18 03:00:58 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_sethostent_r.3 b/doc/man/lwres/lwres_sethostent_r.3
new file mode 100644
index 00000000..86583a61
--- /dev/null
+++ b/doc/man/lwres/lwres_sethostent_r.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_sethostent_r.3,v 1.4 2000/11/18 03:00:59 bwelling Exp $
+
+.so lwres_gethostent.3
diff --git a/doc/man/lwres/lwres_string_parse.3 b/doc/man/lwres/lwres_string_parse.3
new file mode 100644
index 00000000..bece6a8a
--- /dev/null
+++ b/doc/man/lwres/lwres_string_parse.3
@@ -0,0 +1,18 @@
+.\" Copyright (C) 2000  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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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: lwres_string_parse.3,v 1.4 2000/11/18 03:01:00 bwelling Exp $
+
+.so lwres_resutil.3
diff --git a/doc/misc/dnssec b/doc/misc/dnssec
index 73f38c0a..2d5e4eb8 100644
--- a/doc/misc/dnssec
+++ b/doc/misc/dnssec
@@ -7,7 +7,7 @@ This document summarizes the state of the DNSSEC implementation in
 this release of BIND9.
 
 
-Key generation and signing
+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
@@ -18,7 +18,7 @@ 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
+Serving Secure Zones
 
 When acting as an authoritative name server, BIND9 includes KEY, SIG
 and NXT records in responses as specified in RFC2535.
@@ -32,7 +32,7 @@ do not include the NXT records to prove the nonexistence of a
 non-wildcard match or a more specific wildcard match.
 
 
-Secure resolution
+Secure Resolution
 
 Basic support for validation of DNSSEC signatures in responses has
 been implemented but should still be considered experimental.
@@ -58,7 +58,7 @@ 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
+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
@@ -66,4 +66,25 @@ an update occurs.  Advanced access control is possible using the
 "update-policy" statement in the zone definition.
 
 
-$Id: dnssec,v 1.4.2.4 2000/08/15 22:35:06 gson Exp $
+Performance of Cryptographic Operations
+
+The cryptographic primitives used by the BIND 9 DNSSEC implementation
+are based on the OpenSSL library.  A version of that library is
+integrated into the distribution, but for portability reasons this
+version does not make use of any platform-specific assembly language
+routines.
+
+On many platforms, particularly i386 and SPARC, a significant
+improvement in signing and verification speed can be achieved linking
+BIND 9 with a separate OpenSSL library that uses hand-optimized
+assembly language routines.  To do this, you need to install OpenSSL
+version 0.9.5a or newer separately from the BIND 9 tree prior to
+building BIND 9, using the default openssl configuration settings
+which will cause it to be built with assembly language routines.  Then
+specifying the "--with-openssl" option to the BIND 9 configure script
+to make BIND 9 link against the system openssl library rather than its
+own.  For example, if openssl was installed under /usr/local, use
+"configure --with-openssl=/usr/local".
+
+
+$Id: dnssec,v 1.9 2000/08/09 04:37:39 tale Exp $
diff --git a/doc/misc/ipv6 b/doc/misc/ipv6
index 6136813f..15cbd158 100644
--- a/doc/misc/ipv6
+++ b/doc/misc/ipv6
@@ -96,4 +96,4 @@ RELEVANT RFCs
 draft-ietf-ipngwg-rfc2292bis-01:  Advanced Sockets API for IPv6 (draft)
 
 
-$Id: ipv6,v 1.3.2.1 2000/08/15 22:35:10 gson Exp $
+$Id: ipv6,v 1.4 2000/08/09 04:37:40 tale Exp $
diff --git a/doc/misc/migration b/doc/misc/migration
index e2bd6730..9d97ba1f 100644
--- a/doc/misc/migration
+++ b/doc/misc/migration
@@ -12,11 +12,9 @@ upgrading an existing BIND 8 installation to use BIND 9.
 
 1.1. Unimplemented Options and Changed Defaults
 
-BIND 9.0.0 supports most, but not all but not of the named.conf
-options of BIND 8.  Unimplemented options include those for selective
-(per-domain) forwarding, sortlists, statistics, and process limits;
-for a complete list, see doc/misc/options.  We plan to implement most
-of these in in BIND 9.1.
+BIND 9.1 supports most, but not all but not of the named.conf options
+of BIND 8.  For a complete list of implmented 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
@@ -56,6 +54,11 @@ immediately after the "logging" statement was read.
 In BIND 9, ACL names are case sensitive.  In BIND 8 they were case
 insensitive.
 
+1.5. Notify messages and Refesh 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.
 
 2. Zone File Compatibility
 
@@ -102,29 +105,27 @@ line.
 
 2.5. Unimplemented BIND 8 Extensions
 
-BIND 8 supports a nonstandard master file directive "$GENERATE" for
-automatically generating multiple instances of certain RRs from a
-template.  This directive is currently unimplemented in BIND 9.
-
+$GENERATE: The "$$" construct for getting a literal $ into a domain
+name is deprecated.  Use \$ instead.
 
 3. Interoperability Impact of New Protocol Features
 
 BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size.  It
-also sets the AD bit in queries to indicate that it wishes to receive
-DNSSEC responses (this usage of the AD bit is not yet standard, but
-hopefully it will be soon).
+also sets an EDNS flag bit in queries to indicate that it wishes to
+receive DNSSEC responses; this flag bit usage is not yet standardized,
+but we hope it will be.
 
-Most older servers that do not support EDNS0 and/or DNSSEC, including
-all known 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 and AD.
+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 are trying to resolve the issue with them.
+case, and they are working on a solution.
 
 
 4. Unrestricted Character Set
@@ -154,7 +155,7 @@ be upgraded.
 The "ndc" program has been replaced by "rndc", which is capable of
 remote operation.  Unlike ndc, rndc requires a configuration file; 
 see the man pages in doc/man/bin/rndc.1 and doc/man/bin/rndc.conf.5 for
-details.  Many of the ndc commands are still unimplemented in rndc.
+details.  Some of the ndc commands are still unimplemented in rndc.
 
 
-$Id: migration,v 1.1.2.11 2000/09/18 23:41:29 gson Exp $
+$Id: migration,v 1.16 2000/11/30 23:24:01 gson Exp $
diff --git a/doc/misc/options b/doc/misc/options
index ca8bda2b..23e5aadc 100644
--- a/doc/misc/options
+++ b/doc/misc/options
@@ -1,7 +1,7 @@
 Copyright (C) 2000  Internet Software Consortium.
 See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
 
-$Id: options,v 1.29.2.5 2000/08/29 21:51:15 gson Exp $
+$Id: options,v 1.52 2000/12/02 00:25:40 gson Exp $
 
 This is a summary of the implementation status of the various named.conf
 options in BIND 9.
@@ -12,7 +12,7 @@ Legend:
 
   No	    Not implemented, may be implemented in a later release.
 
-  Obsolete  Obsolete, not applicable to BIND 9, or just evil.  
+  Obsolete  Obsolete, not applicable to BIND 9, or just evil.
 	    Will not be implemented.
 
   *	    New in BIND 9.
@@ -23,10 +23,12 @@ Legend:
 
   %	    The default value has changed since BIND 8.
 
+  &	    The option has been extended since BIND 8.
+
   @	    Semantics of certain pathological address match lists, in
-	    particular those involving double negation, have changed.  
+	    particular those involving double negation, have changed.
 	    The new semantics are generally safer.  IPv6 addresses
-	    are supported, but the predefined ACLs "localhost" and 
+	    are supported, but the predefined ACLs "localhost" and
 	    "localnets" match IPv4 addresses only.
 
   #	    BIND 9 accepts both LF and CRLF as end-of-line markers.
@@ -39,33 +41,35 @@ options {
   [ dump-file path_name; ]				    No
   [ memstatistics-file path_name; ]			    No
   [ pid-file path_name; ]				    Yes
-  [ statistics-file path_name; ]			    No
+  [ statistics-file path_name; ]			    Yes
   [ auth-nxdomain yes_or_no; ]				    Yes%
   [ deallocate-on-exit yes_or_no; ]			    Obsolete+
-  [ dialup yes_or_no; ]					    No
+  [ dialup yes_or_no | notify | notify-passive |
+		       refresh | passive; ]		    Yes&
   [ fake-iquery yes_or_no; ]				    Obsolete-
-  [ fetch-glue yes_or_no; ]				    No
+  [ fetch-glue yes_or_no; ]				    Obsolete
   [ has-old-clients yes_or_no; ]			    Obsolete
   [ host-statistics yes_or_no; ]			    No
   [ multiple-cnames yes_or_no; ]			    Obsolete-
-  [ notify yes_or_no; ]					    Yes
+  [ notify yes_or_no | explicit; ]			    Yes&
   [ recursion yes_or_no; ]				    Yes
   [ rfc2308-type1 yes_or_no; ]				    No
   [ use-id-pool yes_or_no; ]				    Obsolete+
+  [ use-ixfr yes_or_no; ]				    Obsolete
   [ treat-cr-as-space yes_or_no; ]			    Obsolete#
   [ also-notify { ip_addr; [ ip_addr; ... ] }; ]	    Yes
   [ forward ( only | first ); ]				    Yes
   [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ]	    Yes
-  [ check-names ... ]					    No
+  [ check-names ... ]					    Obsolete
   [ allow-query { address_match_list }; ]		    Yes@
   [ allow-transfer { address_match_list }; ]		    Yes@
   [ allow-recursion { address_match_list }; ]		    Yes@
-  [ blackhole { address_match_list }; ]			    No
+  [ blackhole { address_match_list }; ]			    Yes
   [ listen-on [ port ip_port ] { address_match_list }; ]    Yes@
   [ listen-on-v6 [ port ip_port ] { address_match_list }; ] Yes*
   [ query-source ... ]					    Yes
   [ query-source-v6 ... ]				    Yes*
-  [ lame-ttl number; ]					    No
+  [ lame-ttl number; ]					    Yes
   [ max-transfer-time-in number; ]			    Yes
   [ max-transfer-idle-in number; ]			    Yes*
   [ max-transfer-time-out number; ]			    Yes*
@@ -73,8 +77,8 @@ options {
   [ max-cache-ttl number; ]				    Yes*
   [ max-ncache-ttl number; ]				    Yes
   [ max-cache-size size_spec; ]				    No*
-  [ min-roots number; ]					    No
-  [ serial-queries number; ]				    No
+  [ min-roots number; ]					    Obsolete
+  [ serial-queries number; ]				    Obsolete
   [ transfer-format ( one-answer | many-answers ); ]	    Yes
   [ transfers-in  number; ]				    Yes
   [ transfers-out number; ]				    Yes
@@ -84,24 +88,30 @@ options {
   [ request-ixfr yes_or_no; ]				    Yes*
   [ provide-ixfr yes_or_no; ]				    Yes*
   [ maintain-ixfr-base yes_or_no; ]			    Obsolete
-  [ max-ixfr-log-size number; ]				    No
-  [ coresize size_spec ; ]				    No
-  [ datasize size_spec ; ]				    No
-  [ files size_spec ; ]					    No
-  [ stacksize size_spec ; ]				    No
+  [ max-ixfr-log-size number; ]				    Obsolete
+  [ coresize size_spec ; ]				    Yes
+  [ datasize size_spec ; ]				    Yes
+  [ files size_spec ; ]					    Yes
+  [ stacksize size_spec ; ]				    Yes
   [ cleaning-interval number; ]				    Yes
-  [ heartbeat-interval number; ]			    No
+  [ heartbeat-interval number; ]			    Yes
   [ interface-interval number; ]			    Yes
   [ statistics-interval number; ]			    No
   [ topology { address_match_list }; ]			    No
-  [ sortlist { address_match_list }; ]			    No
+  [ sortlist { address_match_list }; ]			    Yes
   [ rrset-order { order_spec ; [ order_spec ; ... ] }; ]    No
   [ recursive-clients number; ]				    Yes*
   [ tcp-clients number; ]				    Yes*
   [ tkey-domain ... ]					    Yes*
   [ tkey-dhkey ... ]					    Yes*
+  [ min-refresh-time number ; ]				    Yes*
+  [ max-refresh-time number ; ]				    Yes*
+  [ min-retry-time number ; ]				    Yes*
+  [ max-retry-time number ; ]				    Yes*
   [ port number; ]					    Yes*
   [ sig-validity-interval number; ]			    Yes*
+  [ additional-from-auth yes_or_no; ]			    Yes*
+  [ additional-from-cache yes_or_no; ]			    Yes*
 };
 
 acl							    Yes@
@@ -118,7 +128,7 @@ controls {
 };
 
 server ip_addr {
-  [ bogus yes_or_no; ]					    No
+  [ bogus yes_or_no; ]					    Yes
   [ request-ixfr yes_or_no; ]				    Yes*
   [ provide-ixfr yes_or_no; ]				    Yes*
   [ support-ixfr yes_or_no; ]				    Obsolete
@@ -129,105 +139,121 @@ server ip_addr {
 
 trusted-keys						    Yes
 
-zone "domain_name" [ ( in | hs | hesiod | chaos ) ] { 
+zone "domain_name" [ ( in | hs | hesiod | chaos ) ] {
   type master;						    Yes
   file path_name;					    Yes
-  [ forward ( only | first ); ]				    No
-  [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]	    No
-  [ check-names ( warn | fail | ignore ); ]		    No
+  [ forward ( only | first ); ]				    Yes
+  [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]	    Yes
+  [ check-names ( warn | fail | ignore ); ]		    Obsolete
   [ allow-update { address_match_list }; ]		    Yes@
   [ update-policy ... ]					    Yes*
   [ allow-query { address_match_list }; ]		    Yes@
   [ allow-transfer { address_match_list }; ]		    Yes@
-  [ dialup yes_or_no; ]					    No
+  [ dialup yes_or_no | notify; ]			    Yes&
   [ max-transfer-time-out number; ]			    Yes*
   [ max-transfer-idle-out number; ]			    Yes*
-  [ notify yes_or_no; ]					    Yes
-  [ also-notify { ip_addr; [ ip_addr; ... ] };		    Yes
+  [ notify yes_or_no | explicit; ]			    Yes&
+  [ also-notify { ip_addr; [ ip_addr; ... ] }; ]	    Yes
   [ ixfr-base  path_name; ]				    Obsolete
   [ pubkey number number number string; ]		    No
   [ sig-validity-interval number; ]			    Yes*
+  [ database string ; [string; ... ] ]			    Yes*
+  [ min-refresh-time number ; ]				    Yes*
+  [ max-refresh-time number ; ]				    Yes*
+  [ min-retry-time number ; ]				    Yes*
+  [ max-retry-time number ; ]				    Yes*
 };
 
-zone "domain_name" [ ( in | hs | hesiod | chaos ) ] {	    
+zone "domain_name" [ ( in | hs | hesiod | chaos ) ] {
   type slave;						    Yes
   [ file path_name; ]					    Yes
   [ ixfr-base  path_name; ]				    Obsolete
   masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] };   Yes
-  [ forward ( only | first ); ]				    No
-  [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]	    No
-  [ check-names ( warn | fail | ignore ); ]		    No
+  [ forward ( only | first ); ]				    Yes
+  [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]	    Yes
+  [ check-names ( warn | fail | ignore ); ]		    Obsolete
   [ allow-update { address_match_list }; ]		    Obsolete
   [ allow-update-forwarding { address_match_list }; ]	    No*
   [ allow-query { address_match_list }; ]		    Yes@
   [ allow-transfer { address_match_list }; ]		    Yes@
   [ transfer-source ip_addr; ]				    Yes
   [ transfer-source-v6 ip_addr; ]			    Yes*
-  [ dialup yes_or_no; ]					    No
+  [ dialup yes_or_no | notify | notify-passive |
+		       refresh | passive; ]		    Yes&
   [ max-transfer-time-in number; ]			    Yes
   [ max-transfer-idle-in number; ]			    Yes*
   [ max-transfer-time-out number; ]			    Yes*
   [ max-transfer-idle-out number; ]			    Yes*
-  [ notify yes_or_no; ]					    Yes
-  [ also-notify { ip_addr; [ ip_addr; ... ] };		    Yes
+  [ notify yes_or_no | explicit; ]			    Yes&
+  [ also-notify { ip_addr; [ ip_addr; ... ] }; ]	    Yes
   [ pubkey number number number string; ]		    No
+  [ min-refresh-time number ; ]				    Yes*
+  [ max-refresh-time number ; ]				    Yes*
+  [ min-retry-time number ; ]				    Yes*
+  [ max-retry-time number ; ]				    Yes*
 };
 
 zone "domain_name" [ ( in | hs | hesiod | chaos ) ] {
   type stub;						    Yes
   [ file path_name; ]					    Yes
   masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] };   Yes
-  [ forward ( only | first ); ]				    No
-  [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]	    No
-  [ check-names ( warn | fail | ignore ); ]		    No
+  [ forward ( only | first ); ]				    Yes
+  [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]	    Yes
+  [ check-names ( warn | fail | ignore ); ]		    Obsolete
   [ allow-update { address_match_list }; ]		    Obsolete
-  [ allow-update-forwarding { address_match_list }; ]	    No*
+  [ allow-update-forwarding { address_match_list }; ]	    Yes*
   [ allow-query { address_match_list }; ]		    Yes@
   [ allow-transfer { address_match_list }; ]		    Yes@
   [ transfer-source ip_addr; ]				    Yes
   [ transfer-source-v6 ip_addr; ]			    Yes*
-  [ dialup yes_or_no; ]					    No
+  [ dialup yes_or_no | passive | refresh; ]		    Yes%
   [ max-transfer-time-in number; ]			    Yes
   [ max-transfer-idle-in number; ]			    Yes*
   [ max-transfer-time-out number; ]			    Yes*
   [ max-transfer-idle-out number; ]			    Yes*
   [ pubkey number number number string; ]		    No
+  [ min-refresh-time number ; ]				    Yes*
+  [ max-refresh-time number ; ]				    Yes*
+  [ min-retry-time number ; ]				    Yes*
+  [ max-retry-time number ; ]				    Yes*
 };
 
-zone "domain_name" [ ( in | hs | hesiod | chaos ) ] {	    
-  type forward;						    No
+zone "domain_name" [ ( in | hs | hesiod | chaos ) ] {
+  type forward;						    Yes
+  [ forward ( only | first ); ]				    Yes
+  [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]	    Yes
 };
 
-zone "." [ ( in | hs | hesiod | chaos ) ] {		    
+zone "." [ ( in | hs | hesiod | chaos ) ] {
   type hint;						    Yes
   file path_name;					    Yes
-  [ check-names ( warn | fail | ignore ); ]		    No
+  [ check-names ( warn | fail | ignore ); ]		    Obsolete
 };
 
 view "view_name" [ ( in | hs | hesiod | chaos ) ] {	    Yes*
   match-clients { address_match_list };			    Yes*
   [ zone ... ]						    Yes
   [ auth-nxdomain yes_or_no; ]				    Yes
-  [ fetch-glue yes_or_no; ]				    No
-  [ notify yes_or_no; ]					    Yes
+  [ fetch-glue yes_or_no; ]				    Obsolete
+  [ notify yes_or_no | explicit; ]			    Yes&
   [ recursion yes_or_no; ]				    Yes
   [ rfc2308-type1 yes_or_no; ]				    No
   [ also-notify { ip_addr; [ ip_addr; ... ] }; ]	    Yes
   [ forward ( only | first ); ]				    Yes
   [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ]	    Yes
-  [ check-names ... ]					    No
+  [ check-names ... ]					    Obsolete
   [ allow-query { address_match_list }; ]		    Yes
   [ allow-transfer { address_match_list }; ]		    Yes
   [ allow-recursion { address_match_list }; ]		    Yes
   [ query-source ... ]					    Yes
   [ query-source-v6 ... ]				    Yes
-  [ lame-ttl number; ]					    No
+  [ lame-ttl number; ]					    Yes
   [ max-transfer-time-out number; ]			    Yes*
   [ max-transfer-idle-out number; ]			    Yes*
   [ max-cache-ttl number; ]				    Yes*
   [ max-ncache-ttl number; ]				    Yes
   [ max-cache-size size_spec; ]				    No*
-  [ min-roots number; ]					    No
+  [ min-roots number; ]					    Obsolete
   [ transfer-format ( one-answer | many-answers ); ]	    Yes
   [ transfer-source ip_addr; ]				    Yes
   [ transfer-source-v6 ip_addr; ]			    Yes*
@@ -235,10 +261,14 @@ view "view_name" [ ( in | hs | hesiod | chaos ) ] {	    Yes*
   [ provide-ixfr yes_or_no;]				    Yes*
   [ cleaning-interval number; ]				    Yes
   [ topology { address_match_list }; ]			    No
-  [ sortlist { address_match_list }; ]			    No
+  [ sortlist { address_match_list }; ]			    Yes
   [ rrset-order { order_spec ; [ order_spec ; ... ] }; ]    No
   [ key ... ]						    Yes
   [ server ... ]					    Yes
   [ trusted-keys ... ]					    Yes
   [ sig-validity-interval number; ]			    Yes*
+  [ min-refresh-time number ; ]				    Yes*
+  [ max-refresh-time number ; ]				    Yes*
+  [ min-retry-time number ; ]				    Yes*
+  [ max-retry-time number ; ]				    Yes*
 };
diff --git a/doc/misc/sdb b/doc/misc/sdb
new file mode 100644
index 00000000..30532c1c
--- /dev/null
+++ b/doc/misc/sdb
@@ -0,0 +1,168 @@
+Copyright (C) 2000  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 introduces 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.3 2000/11/30 02:03:18 sjacob Exp $
diff --git a/doc/rfc/index b/doc/rfc/index
new file mode 100644
index 00000000..7b321e8b
--- /dev/null
+++ b/doc/rfc/index
@@ -0,0 +1,59 @@
+ 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
+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)
+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)
+2845:	Secret Key Transaction Authentication for DNS (TSIG)
+2874:	DNS Extensions to Support IPv6 Address Aggregation and Renumbering
+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:   ecure Domain Name System (DNS) Dynamic Update
+3008:   Domain Name System Security (DNSSEC) Signing Authority
diff --git a/doc/rfc/rfc2929.txt b/doc/rfc/rfc2929.txt
new file mode 100644
index 00000000..f0559689
--- /dev/null
+++ b/doc/rfc/rfc2929.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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/doc/draft/draft-ietf-dnsext-tkey-03.txt b/doc/rfc/rfc2930.txt
index 7b4dc7c9..f99573dd 100644
--- a/doc/draft/draft-ietf-dnsext-tkey-03.txt
+++ b/doc/rfc/rfc2930.txt
@@ -1,97 +1,52 @@
 
-DNSEXT Working Group                             Donald E. Eastlake, 3rd
-INTERNET-DRAFT                                                  Motorola
-Expires: December 2000                                         June 2000
-
-
-
-               Secret Key Establishment for DNS (TKEY RR)
-               ------ --- ------------- --- --- ----- ---
-                    <draft-ietf-dnsext-tkey-03.txt>
-
-
-
-Status of This Document
-
-   This draft is intended to be become a Proposed Standard RFC.
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS working group mailing list <namedroppers@ops.ietf.org> or
-   to the author.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
 
 
 
 
 
+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
 
-Donald Eastlake 3rd                                             [Page 1]
-
+   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.
 
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
+Copyright Notice
 
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
 
 Abstract
 
-   [draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating
-   Domain Name System (DNS) queries and responses using shared secret
-   keys via the TSIG resource record (RR).  However, it provides no
-   mechanism for setting up such keys other than manual exchange. This
-   document describes a TKEY RR that can be used in a number of
-   different modes to establish shared secret keys between a DNS
-   resolver and server.
-
-
+   [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)
-
-
+         Olafur Gudmundsson (TIS)
 
+         Stuart Kwan (Microsoft)
 
+         Ed Lewis (TIS)
 
+         Erik Nordmark (SUN)
 
+         Brian Wellington (Nominum)
 
 
 
@@ -100,69 +55,55 @@ Acknowledgments
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                             [Page 2]
+Eastlake                    Standards Track                     [Page 1]
 
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
+RFC 2930                    The DNS TKEY RR               September 2000
 
 
 Table of Contents
 
-      Status of This Document....................................1
-
-      Abstract...................................................2
-      Acknowledgments............................................2
-
-      Table of Contents..........................................3
-
-      1. Introduction............................................4
-      1.1 Overview of Contents...................................4
-      2. The TKEY Resource Record................................5
-      2.1 The Name Field.........................................5
-      2.2 The TTL Field..........................................6
-      2.3 The Algorithm Field....................................6
-      2.4 The Inception and Expiration Fields....................6
-      2.5 The Mode Field.........................................7
-      2.6 The Error Field........................................7
-      2.7 The Key Size and Data Fields...........................8
-      2.8 The Other Size and Data Fields.........................8
-      3. General TKEY Considerations.............................8
-      4. Exchange via Resolver Query.............................9
-      4.1 Query for Diffie-Hellman Exchanged Keying..............9
-      4.2 Query for TKEY Deletion...............................10
-      4.3 Query for GSS-API Establishment.......................11
-      4.4 Query for Server Assigned Keying......................11
-      4.5 Query for Resolver Assigned Keying....................12
-      5. Spontaneous Server Inclusion...........................13
-      5.1 Spontaneous Server Key Deletion.......................13
-      6. Methods of Encryption..................................14
-      7. IANA Considerations....................................14
-      8. Security Considerations................................15
-
-      References................................................16
-
-      Author's Address..........................................17
-      Expiration and File Name..................................17
-
-
-
-
-
+   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.
 
 
 
@@ -170,27 +111,10 @@ Table of Contents
 
 
 
-Donald Eastlake 3rd                                             [Page 3]
+Eastlake                    Standards Track                     [Page 2]
 
+RFC 2930                    The DNS TKEY RR               September 2000
 
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
-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.
-
-   [draft-ietf-dnsext-tsig-*.txt] 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.
 
    Note that TKEY established keying material and TSIGs that use it are
    associated with DNS servers or resolvers.  They are not associated
@@ -211,8 +135,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
@@ -226,14 +148,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    would intuitively be called a "query".
 
    Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
-
-
-Donald Eastlake 3rd                                             [Page 4]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
    servers which is currently used only for key deletion.
 
    Section 6 describes encryption methods for transmitting secret key
@@ -247,32 +161,41 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 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
 
 
 
+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
@@ -284,14 +207,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    name returns a BADNAME error.
 
    For a TKEY with a non-root name appearing in a query, the TKEY RR
-
-
-Donald Eastlake 3rd                                             [Page 5]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
    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
@@ -300,38 +215,40 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
 
    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
-        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 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
+
 
-        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.
+
+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 [draft-ietf-dnsext-tsig-*.txt].  The algorithm
-   determines how the secret keying material agreed to using the TKEY RR
-   is actually used to derive the algorithm specific key.
-
-
+   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
 
@@ -343,21 +260,12 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    keying material asked for or specify the validity interval of keying
    material provided.
 
-
-Donald Eastlake 3rd                                             [Page 6]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
    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
@@ -368,59 +276,53 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    a mode it does not support returns the BADMODE error.  The following
    values of the Mode octet are defined, available, or reserved:
 
-          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
 
 
 
+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
+         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
-
-
-Donald Eastlake 3rd                                             [Page 7]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
    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
@@ -430,6 +332,14 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
 
 
 
+
+
+
+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
@@ -455,16 +365,8 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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)) key and MUST NOT use any
-   key that the response to be verified is itself providing.
-
-
-
-Donald Eastlake 3rd                                             [Page 8]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
+   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
@@ -485,12 +387,19 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
@@ -503,11 +412,9 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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 means whereby two parties can
+   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].
@@ -516,14 +423,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
-
-
-Donald Eastlake 3rd                                             [Page 9]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
    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
@@ -546,9 +445,16 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    modulus) and the data in the TKEY RRs.  The TKEY RR data is mixed
    with the DH result as follows:
 
-        keying material =
-             XOR ( DH value, MD5 ( query data | DH value ) |
-                             MD5 ( server data | DH value ) )
+
+
+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
@@ -565,8 +471,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
@@ -574,14 +478,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
-
-
-Donald Eastlake 3rd                                            [Page 10]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
    the discarded key.
 
    To avoid attempted reliance in requests on keys no longer in effect,
@@ -601,6 +497,17 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
 
 
 
+
+
+
+
+
+
+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
@@ -613,12 +520,10 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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.
+   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
@@ -632,34 +537,33 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
-
-
-Donald Eastlake 3rd                                            [Page 11]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
    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 [draft-ietf-dnsext-
-   tsig-*.txt] 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.
+   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 reponse TKEY error field is zero, the key data portion of the
+   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.
@@ -676,8 +580,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
@@ -690,14 +592,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
-
-
-Donald Eastlake 3rd                                            [Page 12]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
    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
@@ -717,6 +611,15 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
 
 
 
+
+
+
+
+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
@@ -728,8 +631,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
@@ -748,14 +649,6 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    the server and may re-send it in a future query specifying querier
    assigned keying material.
 
-
-
-Donald Eastlake 3rd                                            [Page 13]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
 6. Methods of Encryption
 
    For the server assigned and resolver assigned key agreement modes,
@@ -775,6 +668,14 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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
@@ -784,16 +685,14 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    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 through 0x00FF, and 0XFF00 through 0XFFFF
-   can only be assigned by an IETF standards action.  Special
-   consideration should be given before the allocation of meaning for
-   Mode field values 0x0000 and 0xFFFF.
+   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.
@@ -806,30 +705,20 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
    a specification should not be changed later just because that use's
    status is changed to standards track.
 
-
-
-Donald Eastlake 3rd                                            [Page 14]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
-
-
    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.
+      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 [draft-ietf-dnsext-tsig-*.txt].
+   support of TSIG [RFC 2845].
 
    Protection against denial of service via the use of TKEY is not
    provided.
@@ -838,131 +727,155 @@ INTERNET-DRAFT              The DNS TKEY RR                    June 2000
 
 
 
+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.
 
 
 
 
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 15]
+Eastlake                    Standards Track                    [Page 14]
 
+RFC 2930                    The DNS TKEY RR               September 2000
 
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
 
+   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
 
-References
+   [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s )", RFC 2931, September 2000.
 
-   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
-   Algorithms, and Source Code in C", 1996, John Wiley and Sons
+Author's Address
 
-   RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
-   STD 13, November 1987.
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
 
-   RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
-   Specifications", STD 13, November 1987.
+   Phone: +1 978-562-2827 (h)
+          +1 508-261-5434 (w)
+   Fax:   +1 508-261-4447 (w)
+   EMail: Donald.Eastlake@motorola.com
 
-   RFC 1750 - D. Eastlake, S.  Crocker & J. Schiller, "Randomness
-   Recommendations for Security", December 1994.
 
-   RFC 1982 - Robert Elz, Randy Bush, "Serial Number Arithmetic",
-   09/03/1996.
 
-   RFC 1995 - Masataka Ohta, "Incremental Zone Transfer in DNS", August
-   1996.
 
-   RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4
-   for IPv4, IPv6 and OSI", October 1996.
 
-   RFC 2104 - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
-   for Message Authentication", February 1997.
 
-   RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate
-   Requirement Levels", March 1997.
 
-   RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
-   Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
 
-   RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-   Considerations Section in RFCs, October 1998.
 
-   RFC 2437 -  B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
-   Specifications Version 2.0", October 1998.
 
-   RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
-   March 1999.
 
-   RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
-   Name System (DNS)", March 1999.
 
-   draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
-   Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
 
 
 
 
 
 
-Donald Eastlake 3rd                                            [Page 16]
-
 
-INTERNET-DRAFT              The DNS TKEY RR                    June 2000
 
 
-Author's Address
 
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
 
-   Telephone:   +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
 
 
 
-Expiration and File Name
 
-   This draft expires December 2000.
 
-   Its file name is draft-ietf-dnsext-tkey-03.txt.
 
 
 
 
 
+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.
 
 
 
@@ -982,5 +895,5 @@ Expiration and File Name
 
 
 
-Donald Eastlake 3rd                                            [Page 17]
+Eastlake                    Standards Track                    [Page 16]
 
diff --git a/doc/draft/draft-ietf-dnsext-sig-zero-02.txt b/doc/rfc/rfc2931.txt
index 8621554b..84cc97e2 100644
--- a/doc/draft/draft-ietf-dnsext-sig-zero-02.txt
+++ b/doc/rfc/rfc2931.txt
@@ -1,42 +1,28 @@
 
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-UPDATES RFC 2535                                                Motorola
 
-Expires: December 2000                                         June 2000
 
 
 
-           DNS Request and Transaction Signatures ( SIG(0)s )
-           --- ------- --- ----------- ---------- - ------- -
-                  <draft-ietf-dnsext-sig-zero-02.txt>
-
-
 
-Status of This Document
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 2931                                      Motorola
+Updates: 2535                                             September 2000
+Category: Standards Track
 
-   This draft is intended to become a Proposed Standard RFC updating
-   Proposed Standard [RFC 2535].  Distribution of this document is
-   unlimited. Comments should be sent to the DNS Working Group mailing
-   list <namedroppers@internic.net> or to the author.
 
-   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."
+           DNS Request and Transaction Signatures ( SIG(0)s )
 
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
+Status of this Memo
 
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
+   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
 
@@ -49,59 +35,18 @@ Abstract
    interoperable changes in Request and Transaction signature resource
    records ( SIG(0)s ).  These changes are documented herein.
 
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                 DNS SIG(0)                      June 2000
-
-
 Acknowledgments
 
    The contributions and suggestions of the following persons (in
-   alphabetic order) to this draft are gratefully acknowledged:
-
-        Olafur Gudmundsson
-        Ed Lewis
-        Erik Nordmark
-        Brian Wellington
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-
-      Acknowledgments............................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. SIG(0) Design Rationale.................................3
-      2.1 Transaction Authentication.............................3
-      2.2 Request Authentication.................................4
-      2.3 Keying.................................................4
-      2.4 Differences Between TSIG and SIG(0)....................4
-      3. The SIG(0) Resource Record..............................5
-      3.1 Calculating Request and Transaction SIGs...............6
-      3.2 Processing Responses and SIG(0) RRs....................7
-      3.3 SIG(0) Lifetime and Expiration.........................7
-      4. Security Considerations.................................7
-      5. IANA Considerations.....................................8
-      References.................................................8
-
-      Author's Address...........................................9
-      Expiration and File Name...................................9
-      Appendix: SIG(0) Changes from RFC 2535.....................9
-
+   alphabetic order) to this memo are gratefully acknowledged:
 
+         Olafur Gudmundsson
 
+         Ed Lewis
 
+         Erik Nordmark
 
+         Brian Wellington
 
 
 
@@ -110,13 +55,29 @@ Table of Contents
 
 
 
-
-
-D. Eastlake 3rd                                                 [Page 2]
+Eastlake                    Standards Track                     [Page 1]
 
+RFC 2931                       DNS SIG(0)                 September 2000
+
 
-INTERNET-DRAFT                 DNS SIG(0)                      June 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
 
@@ -127,8 +88,8 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    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 [draft-ietf-dnsext-tsig-*.txt] and the [RFC
-   2535] specification for SIG(0).
+   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
@@ -136,11 +97,25 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    for DNS data.
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   "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
@@ -152,43 +127,27 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    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 [draft-ietf-
-   dnsext-tsig-*.txt] 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.
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                 DNS SIG(0)                      June 2000
-
+   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 the 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 [draft-ietf-dnsext-tkey-*.txt], or
-   future requests requiring authentication.
-
-
+   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
 
@@ -208,6 +167,11 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
 
 
 
+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).
@@ -226,14 +190,6 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    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
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                 DNS SIG(0)                      June 2000
-
-
    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
@@ -252,8 +208,6 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    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
@@ -266,6 +220,14 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    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.)
@@ -282,16 +244,6 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    has the TC bit set and RCODE 0 (NOERROR).  The client should at this
    point retry the request using TCP.
 
-
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                 DNS SIG(0)                      June 2000
-
-
 3.1 Calculating Request and Transaction SIGs
 
    A DNS request may be optionally signed by including one SIG(0)s at
@@ -321,6 +273,17 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    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)
@@ -342,17 +305,9 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
 
    where "|" is concatenations, RDATA is as above, and previous packet
    is the previous DNS payload including DNS header and the SIG(0) but
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                 DNS SIG(0)                      June 2000
-
-
    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 [draft-ietf-dnsext-tkey-*.txt].
+   with TKEY [RFC 2930].
 
    Except where needed to authenticate an update, TKEY, or similar
    privileged request, servers are not required to check a request
@@ -361,8 +316,6 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    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
@@ -379,13 +332,19 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    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
@@ -394,52 +353,61 @@ INTERNET-DRAFT                 DNS SIG(0)                      June 2000
    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
 
-D. Eastlake 3rd                                                 [Page 7]
-
+   No new parameters are created or parameter values assigned by this
+   document.
 
-INTERNET-DRAFT                 DNS SIG(0)                      June 2000
+References
 
+   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              September 1996.
 
-   The inclusion of the SIG(0) inception and expiration time under the
-   signature improves resistance to replay attacks.
+   [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.
 
-5. IANA Considerations
+   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Signatures for DNS
+              (TSIG)", RFC 2845, May 2000.
 
-   No new parameters are created or parameter values assigned by this
-   document.
+   [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
+              2930, September 2000.
 
 
 
-References
 
-   [RFC 1982] - Robert Elz, Randy Bush, "Serial Number Arithmetic",
-   09/03/1996.
 
-   [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
-   Requirement Levels", March 1997.
+Eastlake                    Standards Track                     [Page 7]
+
+RFC 2931                       DNS SIG(0)                 September 2000
 
-   [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
-   Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
 
-   [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
-   March 1999.
+Author's Address
 
-   [draft-ietf-dnsext-tsig-*.txt] - P. Vixie, O. Gudmundsson, D.
-   Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS
-   (TSIG)".
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
 
-   [draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key
-   Establishment for DNS  (RR)".
+   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
 
 
 
@@ -460,37 +428,30 @@ References
 
 
 
-D. Eastlake 3rd                                                 [Page 8]
-
 
-INTERNET-DRAFT                 DNS SIG(0)                      June 2000
 
 
-Author's Address
 
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
 
-   Telephone:   +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
 
 
 
 
-Expiration and File Name
 
-   This draft expires December 2000.
 
-   Its file name is draft-ietf-dnsext-sig-zero-02.txt.
 
 
 
 
+
+
+
+
+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
@@ -518,5 +479,85 @@ Appendix: SIG(0) Changes from RFC 2535
 
 
 
-D. Eastlake 3rd                                                 [Page 9]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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/doc/rfc/rfc3007.txt b/doc/rfc/rfc3007.txt
new file mode 100644
index 00000000..16974753
--- /dev/null
+++ b/doc/rfc/rfc3007.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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/doc/rfc/rfc3008.txt b/doc/rfc/rfc3008.txt
new file mode 100644
index 00000000..08a4a8fa
--- /dev/null
+++ b/doc/rfc/rfc3008.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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]
+