diff --git a/CHANGES b/CHANGES
index d76e389248..a44e20337b 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,8 @@
+	--- 9.3.5-P1 released ---
+
+2375.   [security]      Fully randomize UDP query ports to improve
+			forgery resilience. [RT #17949]
+
 	--- 9.3.5 released ---
 
 	--- 9.3.5rc2 released ---
diff --git a/bin/named/client.c b/bin/named/client.c
index 6d4cc91a4e..3215c6e637 100644
--- a/bin/named/client.c
+++ b/bin/named/client.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: client.c,v 1.176.2.13.4.38 2007/08/28 07:19:08 tbox Exp $ */
+/* $Id: client.c,v 1.176.2.13.4.38.4.1 2008/05/22 21:11:13 each Exp $ */
 
 #include <config.h>
 
@@ -1348,14 +1348,6 @@ client_request(isc_task_t *task, isc_event_t *event) {
 		}
 	}
 
-	/*
-	 * Hash the incoming request here as it is after
-	 * dns_dispatch_importrecv().
-	 */
-	dns_dispatch_hash(&client->now, sizeof(client->now));
-	dns_dispatch_hash(isc_buffer_base(buffer),
-			  isc_buffer_usedlength(buffer));
-
 	/*
 	 * It's a request.  Parse it.
 	 */
diff --git a/bin/named/server.c b/bin/named/server.c
index a01e5e79cf..c705af0ddc 100644
--- a/bin/named/server.c
+++ b/bin/named/server.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: server.c,v 1.339.2.15.2.78 2008/01/17 23:45:27 tbox Exp $ */
+/* $Id: server.c,v 1.339.2.15.2.78.4.1 2008/05/22 21:11:14 each Exp $ */
 
 #include <config.h>
 
@@ -485,6 +485,14 @@ get_view_querysource_dispatch(const cfg_obj_t **maps,
 		attrs |= DNS_DISPATCHATTR_IPV6;
 		break;
 	}
+
+	if (isc_sockaddr_getport(&sa) != 0) {
+		INSIST(obj != NULL);
+		cfg_obj_log(obj, ns_g_lctx, ISC_LOG_INFO,
+			    "using specific query-source port suppresses port "
+			    "randomization and can be insecure.");
+	}
+
 	attrmask = 0;
 	attrmask |= DNS_DISPATCHATTR_UDP;
 	attrmask |= DNS_DISPATCHATTR_TCP;
@@ -494,7 +502,7 @@ get_view_querysource_dispatch(const cfg_obj_t **maps,
 	disp = NULL;
 	result = dns_dispatch_getudp(ns_g_dispatchmgr, ns_g_socketmgr,
 				     ns_g_taskmgr, &sa, 4096,
-				     1000, 32768, 16411, 16433,
+				     1024, 32768, 16411, 16433,
 				     attrs, attrmask, &disp);
 	if (result != ISC_R_SUCCESS) {
 		isc_sockaddr_t any;
@@ -1866,7 +1874,9 @@ scan_interfaces(ns_server_t *server, isc_boolean_t verbose) {
 }
 
 static isc_result_t
-add_listenelt(isc_mem_t *mctx, ns_listenlist_t *list, isc_sockaddr_t *addr) {
+add_listenelt(isc_mem_t *mctx, ns_listenlist_t *list, isc_sockaddr_t *addr,
+	      isc_boolean_t wcardport_ok)
+{
 	ns_listenelt_t *lelt = NULL;
 	dns_acl_t *src_acl = NULL;
 	dns_aclelement_t aelt;
@@ -1876,7 +1886,8 @@ add_listenelt(isc_mem_t *mctx, ns_listenlist_t *list, isc_sockaddr_t *addr) {
 	REQUIRE(isc_sockaddr_pf(addr) == AF_INET6);
 
 	isc_sockaddr_any6(&any_sa6);
-	if (!isc_sockaddr_equal(&any_sa6, addr)) {
+	if (!isc_sockaddr_equal(&any_sa6, addr) &&
+	    (wcardport_ok || isc_sockaddr_getport(addr) != 0)) {
 		aelt.type = dns_aclelementtype_ipprefix;
 		aelt.negative = ISC_FALSE;
 		aelt.u.ip_prefix.prefixlen = 128;
@@ -1935,7 +1946,16 @@ adjust_interfaces(ns_server_t *server, isc_mem_t *mctx) {
 		result = dns_dispatch_getlocaladdress(dispatch6, &addr);
 		if (result != ISC_R_SUCCESS)
 			goto fail;
-		result = add_listenelt(mctx, list, &addr);
+
+		/*
+		 * We always add non-wildcard address regardless of whether
+		 * the port is 'any' (the fourth arg is TRUE): if the port is
+		 * specific, we need to add it since it may conflict with a
+		 * listening interface; if it's zero, we'll dynamically open
+		 * query ports, and some of them may override an existing
+		 * wildcard IPv6 port.
+		 */
+		result = add_listenelt(mctx, list, &addr, ISC_TRUE);
 		if (result != ISC_R_SUCCESS)
 			goto fail;
 	}
@@ -1965,12 +1985,12 @@ adjust_interfaces(ns_server_t *server, isc_mem_t *mctx) {
 			continue;
 
 		addrp = dns_zone_getnotifysrc6(zone);
-		result = add_listenelt(mctx, list, addrp);
+		result = add_listenelt(mctx, list, addrp, ISC_FALSE);
 		if (result != ISC_R_SUCCESS)
 			goto fail;
 
 		addrp = dns_zone_getxfrsource6(zone);
-		result = add_listenelt(mctx, list, addrp);
+		result = add_listenelt(mctx, list, addrp, ISC_FALSE);
 		if (result != ISC_R_SUCCESS)
 			goto fail;
 	}
diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml
index 67f8c89736..710cd36c1d 100644
--- a/doc/arm/Bv9ARM-book.xml
+++ b/doc/arm/Bv9ARM-book.xml
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.88 2008/01/18 23:45:32 tbox Exp $ -->
+<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.88.2.1 2008/05/22 21:11:14 each Exp $ -->
 
 <book>
 <title>BIND 9 Administrator Reference Manual</title>
@@ -3732,7 +3732,15 @@ IPv6, there is a separate <command>query-source-v6</command> option.
 If <command>address</command> is <command>*</command> (asterisk) or is omitted,
 a wildcard IP address (<command>INADDR_ANY</command>) will be used.
 If <command>port</command> is <command>*</command> or is omitted,
-a random unprivileged port will be used. The <command>avoid-v4-udp-ports</command>
+a random unprivileged port number is picked up and will be
+used for each query.
+It is generally strongly discouraged to
+specify a particular port for the
+<command>query-source</command> or
+<command>query-source-v6</command> options;
+it implicitly disables the use of randomized port numbers
+and leads to insecure operation.
+The <command>avoid-v4-udp-ports</command>
 and <command>avoid-v6-udp-ports</command> options can be used to prevent named
 from selecting certain ports. The defaults are:</para>
 <programlisting>query-source address * port *;
diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html
index dd8d8ca33f..d59d9d198b 100644
--- a/doc/arm/Bv9ARM.ch06.html
+++ b/doc/arm/Bv9ARM.ch06.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch06.html,v 1.56.2.12.2.54 2008/01/19 01:52:14 marka Exp $ -->
+<!-- $Id: Bv9ARM.ch06.html,v 1.56.2.12.2.54.2.1 2008/05/27 22:09:04 each Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -1892,7 +1892,15 @@ IPv6, there is a separate <span><strong class="command">query-source-v6</strong>
 If <span><strong class="command">address</strong></span> is <span><strong class="command">*</strong></span> (asterisk) or is omitted,
 a wildcard IP address (<span><strong class="command">INADDR_ANY</strong></span>) will be used.
 If <span><strong class="command">port</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
-a random unprivileged port will be used. The <span><strong class="command">avoid-v4-udp-ports</strong></span>
+a random unprivileged port number is picked up and will be
+used for each query.
+It is generally strongly discouraged to
+specify a particular port for the
+<span><strong class="command">query-source</strong></span> or
+<span><strong class="command">query-source-v6</strong></span> options;
+it implicitly disables the use of randomized port numbers
+and leads to insecure operation.
+The <span><strong class="command">avoid-v4-udp-ports</strong></span>
 and <span><strong class="command">avoid-v6-udp-ports</strong></span> options can be used to prevent named
 from selecting certain ports. The defaults are:</p>
 <pre class="programlisting">query-source address * port *;
diff --git a/doc/arm/Bv9ARM.pdf b/doc/arm/Bv9ARM.pdf
index 7c74c3935b..7b599bab06 100755
--- a/doc/arm/Bv9ARM.pdf
+++ b/doc/arm/Bv9ARM.pdf
@@ -889,8 +889,8 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xڍ�=O1���[����I�V|$P6���^�I큎���5P!��<X��M^_� zI
-!)�'�͡��Rf�
}1j��"��c�$	F��cD���~ᤊAbg�0������2P@&S�; M����}�������RM�������_��z�v��
���������|_$�0��I�˃���"��$�oc���rQ3{��u>���:1����q��QUendstream
+xڍ�=O1���[�3�l���(�pj��R{HG���z�B�
eHl?��TCt$M!:���P���}�g�\�M�TkM��4B-1��L~b�p6à1A����
_����8���-�%B
+.o^&����i-N�4^��a��ޏ}s|���s�m��[�c�l��f?]��"����]N0P(�G�Y?I,�ϱQ���A���6_>��:��۷/kP�endstream
 endobj
 594 0 obj <<
 /Type /Page
@@ -3225,22 +3225,19 @@ endobj
 /ProcSet [ /PDF /Text ]
 >> endobj
 977 0 obj <<
-/Length 2580      
+/Length 2662      
 /Filter /FlateDecode
 >>
 stream
-xڵY_s�8ϧ�=�}S��+��S6M{�٦�lvnnv�A��ZS[r-9���}�R�l%�]zә�A�
F�8�#kWN�R���Œ�3>�s��D��F�i�뇛��o9r�%2�,;�,�֊�������?�\^O���q�&S�����7Dq���p�v�����I��7�WD��|{y}yuq9�
-k��A�#��~��ѻ����ϯ'��xvy��ҵWp��|9��>Z��?�q��5�{���pN�6g�(f�R��>����V`g�/�Q�+�
j5�@�X����Y�h�v}-�	,�g]�M^N�rz��\��D(��mST%xI�qQ�W���Di*���|^,t ���w�l��uY��re[횚hq��U1����HV������/�k��)D]V;��fX���?!�3Fz;�r^m�����}�+�ZE�
��u�1�x��8�̪����
-��N3i�i��8����4�~xM�8�/�;�����9���܎�0�ģ�m��,�چ���]^��q,9�
-�[�	D�7�d�Z;��(pڕ�C����x��acTr�5�Չ���}O�į)��U}%1��L��$�C�6��S�A։oN;� �i���$$
�FL�E���(��H�$N�&.�f���)5d☖�(�ܨ���e(2ڎ�l��f��|��l
�u���� +�#r	�A�2l�
-�m�R���
ܵ��*r��
-z����q�MVo��P���熷96�������!�yU��MMT��^�_�Xi�h���O_E-a'
��xV�1����EDMK=��N�=�
����zѷR�Y��k�]a ��&���T�+��]�M`'��D�����lYU�9�$\����y���;pW��pX~0��6�7��kVY@fښpY�q9@�9X.$�-�ĸZ�)��58��&�"G�o�89�Jd�"�ۜ(`K��s�xe���:�e�H�.$m�Ο�W0n�:���Ю+B��
ֻ3�б�Q��Ek�Y����{��A� ���.heL�a�Y�� q���H��M�~�n
-��
���U���h�	8�r�4�Zy�������u������u�R����H���o������)�.��‘�J���Er.^-n��W/�|=��iE
wN���I����v���uL �>��Ԇ(P}T�TC�QD�Ђ!�`�8�`���hV���X`EEz�F�>�71À�5h5�P�Q8�'��
��
GG�!
N��/QO(��݄3[Z���'M�N�HcqI��~��
-�x'"��G�ʿ���!໙89�(�7���8
c�c�L�n6��1�N5����$��o�t~�U���;[F� BJf�����z����B��<O�
k�Ճ��;p@„r��a+��0�೟�i	��u��%�K�l}��9�c����
M|.��#ެ�:=\��Oh��P�����F�
-�,.��bAj��V�Ag@S˔4񼼤i]�w�|��i�޿1�E8JB��/[q�@
�:\������;&C��HbR�G���)=��)��"w-TM���t �"j*�#��C�7ñOͰ��>�#���z54v괝<�R����W��K�1��oC�1�M�
4�T��g�t�j��h��<M�7E�P���p�� ��#��; �.C`�!뜉�̮�߼9y2�1cE:RF1�S����8튤���zFHfRn;����C
�d�����tgL��LJc��Q�W���U*VH&��*`�5�]�J�����!8X�$O�G��N�'��3�<�2��
w��Ն��vW�����d�
٭tk�
-V���/h���4bRvW�非��)9XY��6��P�F.��"��]*��o��-� O
-a�ɨ��/����]��ʜ;z�������s�Z�U��|u���b�I-[O�C�R���f�/3h
�
L������Z�>���S#!
3.Щ��Q�^������@:�yz��{R�]�:���sO�~R8�a'}��u&��n`��/�.z��+�Ԁ
��˚�q��N�*|�ziYaW�`��a�<Q���ֵ>�Sa`�cz[�:9`-�%#��#�P������3 D��A	i��f����`1u��փ<��l#Fo*�h�1*
-�v%{���f��;0���\[v�H ��
�P�g1��۾=ڤ+Zi�(]���2rL�9���e]���A'u���zr e9Q�3������ѯo>g@5|-����rs����Q7(��z��Ÿ[Tr����G%ߖ�t�G��m�kzȇ���e�]�p��@P�@���Ș��a����ti��e�kf�o��Hf{!�����v)K@�Q7��]���A�3=���ٹ�
��CV*X�@!�����H@�(��
�k����`$E���(���X�Һ���K�S��w�Sx��y(˯*�z��{hx#@u(��ڥ?P�XB�\,�<'`cX�xjtN�y����
V�k����(|�_���Sp��� V��X�aa(�ӓ�&��9puT���՗endstream
+xڭ]�۶��~��T]DŽ�I����|v����E�L'�O�NK�,Rw�v�߻�(��b���A�b��]�' &~bb
�*Փ$��pa&���<�ܻ�q��u���_�|�I��XƓ��C�2n��̗�L��~�q~swIç1��Ļ��n�$����og�~���L�t>�pK໛�7w7��7���F�z�)�Y�v�����z�������7�V����+���/�������3�Z3y��D����BŌV*@6?^���̺�c�3�2ce2�@��hR+�����Ԯ�E�x����u��QUF��G��51�����5EU��4�5��tz��%A�� �._�g�l��*[�~]V.��U��&X��i],.�t=�U���|O���͆�$
+AW��
�'	�O�#�E���E�@�����ǖA�eC�C�b�>>��!=>��`J%��y
:�����+vX���b�A���4�ψ���zyB���s���4�M8���I�b��?�l���u=�d��Z��b�Xk�5�,Yj�7�(�������OTz���f�b}�"ڽI��<�_bR�J��L�m��4,M�n4����Oq~'���d
+~�u�@]��
�6��Y,��FY5�/�u�`6a�.�gMN�!�i	1��u���#
e�O�i�-�4B_�Q����v)��=��'����,ˆEĴ'���=�j����Y?���4^g�N^V����Ǚ�<�0�w�JF�&i��������f�L��ooQ��z[ԩ�woA��4V:U4K��M_D-a'
)�v:+A�l��i�~�,���.�NN=�!�-����/�h����֮�ĀD�MV����W��n�7�tA��Ӧ�e]=�h��Z=���>_g����-�>�X~�ζ7�ǎ�Yg>6����hd�Ʌ$����V+���7��
�o�+bt􆆊����A��+º�	�	� ��p���:��sZ�t���܉;�V
�����vU�]sX/g�#���烷�
�,�QK���΁cO�˼.h�'L�a�Y��d a��y@�o���6M
F795DN�U_9�"S��ܹ�t|�!��K�
�_���3��#�5J���}�{���~��_���Br.	�t��_$����޾z�R���;��JQ���TR�@���7h�\{�`��A��ԙ%��5�Egy.h�}	憾�i��f��5V`��h��9Nt1����Q(�(R��'R�,!���!E�,<�eQ(�ߩ	gv���w������֗�I��qJD(�/�\A�1��Z�~D���2�ӊly�}ʇ�S�`:����p:�P���#�@T�~�Aʪ�����V��!%����C� ����Y����T�F��v/�N"�mɏ=���̄��~���ӽ:�#m|i�jPaTG-2�g�_��TVOܬ���z=\��'�P��P��]E�Z�x��T�X�#N�Ǩ*��eJ�pZ�RTW��"�7j���=O�F�/�Ul�e+�P����x�C=.�(���>���}�4���"�]��v]%bW�n���IQl!�����J`��Ax��f���=�gt`#�WCc�N��
Y�0mE����D�1�6����0~f�H�����*j�R4�;/�!�o��!%u�d?� ��#��;�.c����B� ����͛�� �Sf�H&
+\R�4����uI�]O�=#$3	7ǝ]�{�ϱU�8��Q��2"m8�����JR��D(��1����D2h*�]�L@>�#���6 �[G"�vO\:G
.�v��0�G��^�r�/�M��f�sè<l�O��R�ү�����\/�)d)w���F5B��J�
+z
+��~Po�|��c
��`׏"~�8ӭ�\z&�eQ/�ӳ����ɖ���#�彮džB����������Ľ��m(L
z�3�Y	0�D�p�	)G"��h��hV���@�o�+�b�X�kr������w�u2tﰢ2��_��
��{aD�	P��
4�u0�l,Š{Ś�{Y�C��.��U����ܽ-Pպ���*�ѣ��]DW��
+J9��p�����d�l�'�[,��Z,ʵXm�DHP�/�1':}Ae���>X�6rE��
�&_4���"�7Y�+-DZ���Ƕu�As�K;J
��/���J
귎p"�aF�
+��U��&A��D{%����Ex�s�ڛS���L��;N�ӊ�X�eO�g/I����7�D"�R�U���Y��XR��kX���hZ~V�k��*����j�w",^�Ӗ�}��kᓖQ�?~��|E���4��8��~���3�ù*Bꌝ�G8���VL�T Ф#S u);�������
+B�D(h�h߇ ���l0��o�p}��a�.i��SI��9�'S��K��u9�-��a�m������ե�.���}�]5�~z�0}\�w��Ѫ�)�k����A���2��#�w�i�u����	�� ���
s�����`��{`,�Js���yB��|�������{R��w؍�����!�m���V64G�&,�&O�6�B/6)Tp��1�=߀��C��]��!��_a�aA'PM[9����'�jm5�~�<tr���ڀ�a��n �Xendstream
 endobj
 976 0 obj <<
 /Type /Page
@@ -3253,10 +3250,10 @@ endobj
 /D [976 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 370 0 obj <<
-/D [976 0 R /XYZ 85.0394 419.653 null]
+/D [976 0 R /XYZ 85.0394 388.7711 null]
 >> endobj
 979 0 obj <<
-/D [976 0 R /XYZ 85.0394 393.5443 null]
+/D [976 0 R /XYZ 85.0394 358.9876 null]
 >> endobj
 975 0 obj <<
 /Font << /F62 638 0 R /F43 604 0 R /F42 601 0 R /F57 628 0 R /F84 802 0 R /F86 982 0 R >>
@@ -3264,30 +3261,18 @@ endobj
 /ProcSet [ /PDF /Text ]
 >> endobj
 985 0 obj <<
-/Length 3187      
+/Length 2975      
 /Filter /FlateDecode
 >>
 stream
-x��Z�s�6�_��35�}����l/�k�����]��Rb�ʒג7M��(K��l�7��L� 	? h���I*R��"s�H�J��\�C�w�yV�i5����⛷�^8�R�.n�FcY!�U����(Z,a�~w������������r�����%Q߽����/W�&*z��W?�\���������
�8*���������ח�_o�����2^������_墀e!�q6Y<���9��^ĉIlL��/>\�kp����������
-���i��%����
K�`�ώE�$��d�1��4u"�.���R�%�F��Z�L���!�
-�{���H�X!��"1�TE7�_GO�
C�Lg��Z�ʼn�J��9C<#گ���⛫�Z�ia=�ђ¸���~E6
p
-L�"�RXk���C[�{�`U�re���H�"2o
-"J橫rO5E[2��Dt�ݮ��XF���������E������_3�ž�x����Q�ܼ��U?(����R��#�+�n	B��m�A��:�`
ۿ�g�R@��
�Sj���sf&5`\�̨Td�)e�߶)��,�R�>o��rߍ������%���˜4�6yGĶ\o���]5T���k
Ⱦ�2���u�T��>�K��݋�)�'a	u��znmy	�o�CÌ�wh�f�7y?��ќ�,2�8
�~$�Ǯ/�`h��m�wm]���׮�چG�w���Gi��}��a�'hL��ؑ$
0f6��9̴s�������]�)��O�V2.�3������c�(0uOfS�"�n�5�6ʱȢ����k����'�+Z�~df8�Ke#��?c5��$�+��	E�O}�'�CW6�p���������}�'�v�:��)?{���
v����P���=E�T
�r��$;
-M�ֲ����C��]���/:G�Q�k�ܷ� ��2�W<�����@��[_��Ul�3mP>�d�)���P�Mw۪����XyU27����0��mU]��P�?���7��0�}Ƀ4������*y�,���tYa�
[��PF��>9' ��fSm�����Y�m�ͼ�>�
Wq��̘���Ӕ���:���˥	3uh%��ϯqXp�=��{���}U���;�TGl�xУ�BA�]9����TA��Xs���觍�gf7�dB%ƍ7���|-d��@���˧sZ-�N���vfXP�O��Z�7>~AS��%�k��ӂ*V���YgI2����0�B�	[:��m�Y�W@��`�؃탧����:utEy�jf���Xnw=�:�_d"v|��#��F��ɲ�^���z�8�A���o8�:�
.ܫm��*8cT絛��j����v���3#�n�jh5S9��[�`|���8*����MCA24�msO!6�0oE�y�k��j}�Մ$�n�<�~[�T�
YU6�Tg��"T(-haʀM����=tQm[���ׇr:��<m�85��d�瑤
�T����3H
-\�H��zIq&,�P�K2p͈2E���&�Ѥ4�)���#!	h<�X���}�uT��	5 K
Ȃ�l:�.�fp)�:
����
-����[�7hkJ_
-��\�5p�7R��j�R��Sϋ2p��2�V
-ʒ���0�=������.S�96U�]H�Zyno��
-�a�S�zG
�"dž]ƀr"��M�����2�b�A���3�
-\��,� X���\3�L͕��a��22@�H9�WR���^A9c����W2`��z{%	[K�����/ߋ��
����`0���fi��%�y����l���z���z��P�W{L����~>/���?
�I�3QM�P�qnj>ޓ��	T�@Ķ��y�/��楥�m���XA�����/�>�Q�_Y�Q�E���y�氽�<&O�$��x�
�l]�Y�{��X��e��P}wT��I�ʩ �s�ƴ��
-�Q���Ì���*���x�����G��͛�*����h�,�H��O�!��DP7H
���0"��*0
��
-O��FCv'czX��<��3�kw���2�*��7Y�����t�fR#^\yS�8�s�?�k�a�6��㪕��K��I�K���	n�g^r�Y��A\G��v��MPż�u��n�7�2��a���B9kִ<oTT*4�y_0*#�g�J�:�ފ�s�����0;��L>�(ڈ4F�2��
-գ]���E�si�s8���'����qO�AR��#�C�Q�����~��{��׽�M�a�� $b��x࣏02,	f�}�Z|6J�5���p��E#wO
�y��\�a���Y���Q�oE@�[��A��nx��jlogs����<�
ސ�E�i9�8ښ�|�պ!��%�UR�ղ��j0�IvOS�ob�Bz	d95w1�;�u���ܬ���;�h��ŧ��N�Dy����y��3��Y����9�ř=ِ3�D�Ҥ�^����Λ��k��㣽�v�͟��p�N�1�1p�H1�T$D�q:���K�
/~��! q���+�X)��CKD
���4��º��|�Ʉuq�^ �
-x�
fҒ1(9	�xb�΅�ҿ���y��fE�f8�W�`3�'��<���A�3�<ŝIj���IJ[�|B5��ϐ=��I6K����(�Ŵav:���塉�]��w�&W�;�	o���dz���ˠ��DQ�h��Ѐ�Po�?P
g���X�f��'��;Ԇg"���ڊ�5i8 ���p"VC|��?����f��9ʀ�L���Ʋk��>qQe�����fV��Zn���H��Pk՗��
-��G��g߶��4�J�}��� m�[�@�S��{P�[
-|�#_�J@P�����3�y�溦| "����g�ýCY�1;��น�Xc�o�L�Ղ�����ߡT�ׁ�p"t��?�'!�˛n!��MN��c�“0Rǽ��~ל���'�P�)�еw\��2I9E������2���
�%�S(��*NVUusp�p8���/����ƞ�L
-��sFT�i�A�q�/��,YP�Go�X�S����]��'j���Gc��{W�;F�g� �M	�NO��As�Wp&���/�~��_��g�X{&o�!Ċ-�B�
-b�4`�B�E���N?endstream
+x��Z�s�6�_��R3�~�i��ܹ:�D77wmh��8�HG����bISrz���t<c.�v���@���?5KR�:�f��E"U2[�.����\(�Y�E������S=s¥:�-o{sY!�U����(Z�a�|{����?߿�gq��z{=_�DF���~Iԛ�/~�����B�DE/������=u�<ǏWׯ����Ĥ�/__���~y9�m����[K�J\ȧ�_~��5,��)����
^�P����"N�HbcB�����?�	{�~���u<��02Q_$Vi�\O��`%�Tŧ�q�b2�Nu4o�2���uc3SJ�$�h�T��t�%	�<%�^�{N'�4VȨ$̢Aq��v�HU���:zb�Sf:͔�F��٧�2v�O��+=�o��j�f�jXϬ��0�7�_��{��J¦���CQ�2�ۦ��ٴ7(V�:����}^5�s%�b?�2Z4������f`���ؼZO̯�06L_�my�x~RX��`5!�[�Nh��gݯ�"3q)���F3xF��6�
����Z����…͌z�5��
+��-] �U���F���
�B����z��!@'Q����� ��gO̳-�)|˺.�MDs����;�Qh)ڶ���%sQ�)���b:_��E�3�΍�j�|�7����m���G�W���:� }#n����gqz��TNX��2�JE&�RF������r���|+�M�a2rK�*����I�h�7D��&��f��eE��m�md[�3�n�U9W��6oj�ë�:-�+!	��rW��[�����CŌ�-��5Ii7y;���L�
VI�O/��i�� �2����m���Gݷe]�l�����g���G���'XL�����b��.Ƙeq�9
����ق��X����c��3b;�'r��Q�Fr_�J�+���*>��n[��[jږMK�7�^�cf�����<�Ϙ�FU�+�j��gB�fc�X�/��=CST�p�vy���D�@B~Wx'�C
+�.��aST�gР�e@�e�6Ժ���"��Q�a]R�.Dh���e���D��No��Z���XG?��K��0�R}U�����
d�
꧝�6���IaxUs۪����XyY07�ݏ�0��}�vKԧC���}��pka滂'�h,,1߶j�峪W��e)��8���A�^Q5����l�
�65$h�-��w���&~��vʎ����SY�KC��`d�
>��i!Ŷ$��հ�}�.�
�wj�N_��I�Q	=�r�U�tcm9��0ob�D����pfrL&�r�M�7�	��ch
�PR@��'dZ-�NLW@OH�X�e�j|����_k���ؔTM�J��$h8U
!�g��V��lm`KV�	y��
+�ܐ�g�}�ny{�L��.n�Ö�f���}����W�Ȋ�]��H�1�r�la��P*Dc�L�q�ɂ��j���	ͻh�]�(�'I1�Zݞ׃y&��
P��Pg���n�j�s�P�J��6:T���;*��y(*�cX]�H#weuhn&$!u��]� PetU�S����P��d��

��
��
Y{8آ�v��9����ڲ���7k,�H�Y$(�����V@R��4�:�I$���$��LX���k�qM�2D��Sv��M�C��I!:>��FO��׽���Z}=�:d�Yp��M�B���.��R#p)�qZ���JOaK������D�u��z\g��N���>�Rp:WN�W���e���%�}e�ZV#�ű*�����} �h�}�"*�R�)Ou��<��ʉDJ7���2�J��3�<��\�!�q��V���b9vϨ�qM�2WV#G�!ed���r��:�+�}���D���>^ɀ-��$l�C���J��(�X
+gW5:��$����|���=���._��2�.>���b��<c`���
+0τ�
�L*���j���m�w���9Y�.�@�=�X��U��O���R�.oZ���7^����cM�7�����$��Y`u����l.8���=�Նt�.›�;��X��e��P{sTP��I���A��&�Ӗ�T��Jw�n�I�U�Y}dzUE�P�?��M^��u�S�����8!���9$m�@{-�@3/�/@�V���ޔ�hN+���=l�Vq���=�tW����,�,�p��M\�xu��NE�T8�N�~�,�&�9�Z�ȧD�7	m��,�=��%_� �18Ȁ+���.U8	J��д�����V��zF�$('Ú�'�
+qt&����\��J�5�ޒ��EY�>#�y&�"�6"�!��_�y���6�hcN #M�p.O�>��B�q<	�+�G懖����3�:���
��:�	���~E4�󛂒�I��c�02"	�p�;F����Y���R4r��A��+�>,`�#~�������_����C��
ŋݰ��j�'�����<�
>��A箪��8ƚ���uݵҗ�VI�L����;M�{�.��.\/�.�pc��XG�Ա��U6����\�х��-Qބ*�����zh��'v#�"�-�s10�3;ڐ��:��z��G��t0	L�>�Ի����i��g�Y
:��*�)R�P�ׁ��)��K]|]a*@���JH�9�����5��^M�J�j���Z&��!o�P�
&��������Na��J�5�N�#�7�	$���F9�_��!~�Ӏ�-�;�Nr�8%��>���儖��ZB{�=�I֕I�����GҊ��-=7�C��	�\�Ǿ��B�؞Mxk�E�'�O'���_3�4T�,��ԫ���w���Kl�X����k
�hH�z�[O�I����"ÉXuw����#��?1�D�;�+.��YՄ����_����8�Z=��bblaV
+�ۧNB0H�������endstream
 endobj
 984 0 obj <<
 /Type /Page
@@ -3300,34 +3285,29 @@ endobj
 /D [984 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 374 0 obj <<
-/D [984 0 R /XYZ 56.6929 645.6366 null]
+/D [984 0 R /XYZ 56.6929 573.6377 null]
 >> endobj
 741 0 obj <<
-/D [984 0 R /XYZ 56.6929 622.1818 null]
+/D [984 0 R /XYZ 56.6929 551.8981 null]
 >> endobj
 983 0 obj <<
-/Font << /F62 638 0 R /F43 604 0 R /F84 802 0 R /F42 601 0 R >>
+/Font << /F62 638 0 R /F43 604 0 R /F84 802 0 R /F86 982 0 R /F42 601 0 R >>
 /XObject << /Im1 795 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
 989 0 obj <<
-/Length 3155      
+/Length 3506      
 /Filter /FlateDecode
 >>
 stream
-xڭ]s�6�ݿBo'�D,�
>���s��r��]�J�mN%R)���.����ɍg���������8�1����U�ד��M�a��+p�i>������FL�,7�Ln�k��9�'��_����������\h65�l�
�~���������7?����̪�������������gs�4��"�pf���]���?�����۟��o���˙ă�q��ol��c�t�2�;=y��x����Ji�i%e�Y_�������Q?u�J�Le&sm3f�8�Y�40mn�͔p&�Q&G,dr�+���ܵ�>>1Dø��=ٽ��^��Jd��t�ۇr6�BM7ş�f��F��,���}�z���5�j�0��?4���eQ������뺪�BS/��݌�iYw���|�2"�'�1
��H8�Y���4�ʻb��m��>�}I`����k;8�噓��p*g��2&�M(@�����DZ�"�4kx�Zg�If_����Q	yS<���,W��E��{KO�}Y/C����.C^E�`�\�W����s
�/z�b�!U� P�[R�'�uS�jꓡe�&�}n�r��(mP
c�Lj��E�b�ן+e|��NHɌ+�.o�c��*�˸"%�k���A��5H	�/
����B�"Bh�B�N*�^�X̡
-!�"�
b-�����7�w6�-�Ǿl�6
-}�?�e�� ��W�4>U� 	�r��ݾ-W�'#V�P����7�`	f��\|�
-��B)3����p�uA
-#V*�[��yݞ�6�u��LE�5BFrb�3kY��A�� �؈�(XNw����c�d��,���E��e�
�D����`4�o�
*OM���� }9����˚@Zv�t%��b��ܡY��Z����P��P�g�J(�Yã_c6;˭5� ٫�p+?�
-�X�d89g����{���|��Sm�>4�|#>F�π��3�����
�UGx����t��a�%�
��;$�/�=)�K<�!Ke�L�A/�.�	�>��6�(��J�7�[�p\:PFS��>ھ���:
-Q�hIϴ4�XF�cT1�;b.�vG��o1��eV�K���m$ľ��M��Aa��H�L�/��!�y�c
yA|n��eyj"E��=�Tp�s�_GƱ4
׬s�k��+w�
-�4���C�| 0�@�O�ՊD��h�e0��
6����n>=*�n�}"Ը.�]Ր��E�3�H�=+�MGk����<]z��&{�”��׹o�IڥVVJ�;���Ky����N���mz�Ǝ�R��L�-�X{��������'��6��
�E6��]�K�M�A®�	aή"��aO��Tx�U\o�&�Z��~��i�uG(uӥ'���D	�SK-a�[�P�L0\~G�q���@_�fF�C���}��d��
H�R�}�ˌO	I�<�u��0�j�n���� JD.�
�!������@Yc����ޞNB"m�q�b�-��Vu��!���-q��#6Rr�in��4O�^�O��@J�D��$~��Tp�2�!�JE��,%�0��E�݄�L�H�P*��Vw�Hq�U-u��_V_4CBHL�c�v���00�'$��Y�#O�����I�`��예�1�
-��̑Q
-��?7䁡#����5�~�ʧ��#�8�0=3�τ!�z�"��ŨP�L���Ϙ0��}F���C�������A�|J����,�ٟ�tg
Q����f7��ꌎ�y����l�8����O�������w)vbϺ<.(H? U�Å!��p��:s=�Gs1H��x��k��$��۶JQҧ�-e!cF27.r�U��ǹ�<��soCv��I��q�UaT�uS�BMS�k�^��s��������Xdp��k�=<�v��H#t�w�HB<�����HP���7�T?pp�`�3~��:�YW�W
����͌��km���պ
D׫1�
f=WQ�!��#��A�U�r��3�m���1�����9�`�2	q��0��x��˂/�C��0����h��g�K�#us
yg�W�gO
tOJ���Շ
g��$1!��"r��ln������	k`Q	Q�D�M��})q�����}��؟�����͆O~h�L��������\N%Y�1P*.�w��u��l�<Â�+���A��x�0FF(��)��4h�$�����E�J,�h�m�ѱ��LJA���׫��ޙ�ŀ(�$�Hlz�F �v�.2�u4�b�-�
�B���Y	�7�F,�B@���H&žY��mY�����c��J������$[�~�@v�Ib8��[K<����Y����w(ccy
�4���و�/OTV�`��.1T�o�3�`ɜ����~�mV$;����S��}�+�X��XX��$C�4���1�R��Lf��)-蘄eCDŽ�AYZI*m9�
6Fl������1!<�����y6Q�T���s�;'0��فs"�P`���*��a�1`�X_,��b��s���˱���X�&�r|�Wo��/�c�P�R��:&����\�.ODʹ�H��A�Zn��5_Q�Tۀ�KڰdlB� G�юRT�U�o�ʗ�5R�T�f�UG��FYj�|;pP�K���@��ș̬�c&�\�Uc!n��?�|a��j��'.�I�-dH�j]uπ��!dz���B8�� ����Uw���N��`�q����K� >�L�qb��6|���E�P�§�P@��$���^����F�a�۾0�sBa��>����k/	Z�cuTi�����];�������wt��h���,H�Y�I�,��,㨚ebZ�ۄ�\�VM�Z&Ƿ������W�JqT@�Z�#�[���u���-R�X�s#@�2�$u5���<�u���?�y�ݠ�图���x�+�� �
-1��-\���_´
-�+I?]�tJJ��e�-B46,h�6V�/�\y�]:B�.
�^�i�(𙾃�-:��-�H�����rv�D��u����==IK�͉����֫
-a��V�[�6b!Y�-~�O���C:�ݎ��DI��D�yU~L�F�`j���
^��endstream
+xڭ]s�6�ݿBo'�D,�?���sMr9wn�>Pes*��H�u��b
��(ٙ�d,�%�X�7�'����^M�W�f\O�+6����xę%�Y������1�7�L�V��\Ɯ㓻��w������Lh65��L6����4�y��������ڪ����4�������n�g�iߋ�™���ㆠ?���緟������;K���I<�W���&K8�OW,����tXƽ�͕�2�J�4�����?�{���1�i�2�a��=r�2�}f�����k�ES��(�x���E�eC�yl�uӔ�uD-�����l����y���{����i�ޛ�z��U�T욈ݧ��=s�#rw�Qq�b��/��EYT�r:߷���Q]��	j��m�k�%n8�	�2絘�8ϼ��dٰ���XDZ�x"�Y�E��#�!�`����\H�|�9���ψ\-	���⡈\���t���*����M������^f��E����&G^zG��6_75A^�n���Ix�:h��r��^š_k
�����UbC\��(��a�rK��i�_�te��x*��cD�X�����6�9-tD�^�y/g�,�*��f�M��Z�	�}G
pHJ>���p�]�\��)���l��Ę�i��E �<��o���vT�R`=|"#.wJ�L1�Ӵy[l�:�s�2��WrܼG�Y��Әy��\nfeu�9�63��˻wX#���`D�p� ��u��Yn��T��<\���ؖռޣc篺��u���*B��"`1w�n��*�ID���~G�T�`|8�S�NR$=�"r;�P��+`��1_���hۗO�9���p6"I�^���ۊT�ȃ읊�mb�)K�ƣ-Y���k	P�l4-�ت �a��H�q_T�8.?$ˌ ^�e	��+VDK½�+�Pܣ}'(A�<���@�:_��{4���6�
��y�*�̸���uA֐���=Q %3�@�/n�a��?T �q!Đ��A���a'i�,\�
�Q��G*�PO��T'�
+!0��}B�3*D��Zs���6
w��{��싦m�@P[���h'������M��T��$̋���}S,�{sLu����a�1
� 2��ר�)���k�.Ka�vXC)L�jN�Q��:o.S�a��18�ᙵ�� svF�$a�����9vH��b�Y��,��<b�����]4�p0�B���(\B�<a54��VҲ��-���Aѵ��FC-|���B�B�����Ę�μ���  y�Wn��0��J���Eq���;Def�����<�.F|��
��g�P�3��>˖��;��)z�ޖ<zD
+�]���%�]b �w��y�UL�A/�.�	�>��.RmN�'�(~Q�	-�0t.�dEy,#��1�'��Î����h��-f���Q{.䕐u����#]Ȯ3+�K6��u�F&��|��Eqj"E�z���*��|��בq,M�5�R*�,�b�)Ai@3�<=�!
��s��2��D�&���b"S����GE�ݻO�WŢ
I1�q�9HƑ�7!/ՎւvU��.����d�q��מ�Z�$�VVJ�[�H���d�m���x@ئǠ7�`G�N�
m�����W�~\�N���`V���,��|�b���
B��+�ls�>~ʩ��[>��*4��.Au0w��"��n�'I�H��*Č�;5�&�����g���[��u ƒ70��$^�}d� ��x��P.�,"��|JH�\�n�/�7_�P�u���NQ"r
���>L�xq��)�HB��>��o�E��Ѳ��<ĵ�kK\�ocu�M��I~�S?�:�)��L1�l1��2]��<�RG�)�OJ�7`f;�"�	
���TH3-W�Hq�����_�X죠��ȴ0�l7}2'���d�;w�W�=��P��	6�Ɏ�8C����8Èᄎ�?7�a`����s�&�Xb�1 �!�Ģ�$ό�3!A���/�;�p>**��k9�3&�:v�I& �P�(,{*ۇ��*�R�lf5Kl'>��L#l��ލ�� �6:�3��>�spX�S�.�Ӄ�w���8�#��l� �ɔ~�.�C:,$�3w3{4'ႁ\Ɉ�DtH�T�)�h�䐌.am(�(37��q��W	���ԛC���y�_'�zL���y:�X�-b�&���5�M��i�B=��u����v��H��\�#!��1�:0D"�
!oѼX��*Ú^�'��
+��.cK����Ⱥl�3@���"n3c��Z�b���*/�M$�Z��
0�^%u��g�܎���ٽ<�
+^m����H��ˉ��6�-s�5�҅�L7�����DH�_�>c�T���4K�Ac2�٦/.W�jj���z›n�X���m ���-Eb�����;�_LoN8�Jw'����`��pʇ,�
�p���w�>���3M��J+��K�s95Hw���
 UZ:��^Ξ�����|�C��J���gFz��0�ʃ� H0"u
iJP"X%�a���c�s,403��y���e�����t�Q/I;I4�
�ÂA�H�=�	��:YY�-w�Ȇ��SaȬ�H#�i!���D"��,�Ŷ���~[W)G�[
Ⱦ/ږ,�u!���:��!��<_�!~�^Hlʩ,=��0B��Jf����I^�h��`�� �W�o�3�`I��dvx��6#0>�I���po.x%�a�*�/;��S)Xd ��ɩ_�H#���C�b��K²�_�n��Am9�6�j������/!<�8�b��l8�ީLq%��)>��TZf{���B�Qvª���Q�1`�XW%��RԂtp��rh��:/E֩	��������tX#�Ƀ�)��r~	/u.Y	�"�\_�`� R
M�q�Z(�k*j�&$M\��5a����lK��s����cuK���P�z�9G��&Y��|;pP鍨�!E�ݑ3�Y�S
+�\��a!l��?�|a��2R�WV.%H�-�F�r]�π��!�7En^��!LXį�\=�;ڂ9���;���,����2
�y�̤6|�r�ՌX��7�X9��AS�Bax�Q��A쇊 ~+��L�1��ǟI���7T9��.�Mp���量w���C���^X�3F�2L�X�Ie,�Je,㨌eRVa�Vю��`�t��e<>:�5�܏>'�O�G�4�୕>R��:߇����"��՞17d(�͠�F�0�t�3�{I�h��C�����Y��Y��L@3�J�+�L��W�p�P�B�{�*֬$�f��))1��G����+Y����A�7,Y��p��\r�X�
+Q�3��b-:�֭�g_�zv0�N^�h��`3߱7'i!��|�@��8��r��
+���rՕ-2��鈅d]��Ϳn=��W��`1��!?�(��D�W�cʻ�����?�o%Yendstream
 endobj
 988 0 obj <<
 /Type /Page
@@ -3340,23 +3320,23 @@ endobj
 /D [988 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 987 0 obj <<
-/Font << /F62 638 0 R /F42 601 0 R /F43 604 0 R /F57 628 0 R /F84 802 0 R /F86 982 0 R >>
+/Font << /F62 638 0 R /F43 604 0 R /F42 601 0 R /F57 628 0 R /F84 802 0 R /F86 982 0 R >>
 /XObject << /Im1 795 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
 994 0 obj <<
-/Length 3150      
+/Length 2914      
 /Filter /FlateDecode
 >>
 stream
-xڭZ�s�8�_�Ufj.�E�=u۴םݶ�d���A��DWY�Zr��_Aʒ-;��Mg*~�H?tČ�?13��Lf�4��paf�������h�h>������wV�2�Yig�w^�q���v�{b�d���'o>}|���oׯ/S��~���r.
O�}��Z�_�����˹pF$o������5M�����HF�L���]]_}|su����W��^��\�F����>[����Le�̞�Ù�29[_h���Jő����=���_:u~Z:f�Mg�S܈o��?E7-��e�VR8���h^�W�Y͝`&��l'ÌT��^�fB�����R&Sl��;�t��=eƌ�	gFI
ܑ���܊�����}8�2��Y
-r��(y��L0��L͠���??�ㇵ��m`C������ߒ��R�ŀ�)4�,u^ᛦʷ`�&)�˹�Y��5�zE�"�Te���US�����6��5O�H�ue}O����n��|��m�tw�x������5o�|cO,^^J�|��������9k�1�27��_3�`3������Q�eƜK
h��{9
F���Z�V�2����N�QO�G�R�=�������=�>R M(�����Qc
~)��c��J�"&?Vs�_����J�_�-v5��l��N�ЗXR{
֕�G����1��p2�
-L�R�-��{.�`�(�خѲ�|a���@;_���~���fd�R�`����e������r5���j3"����� �5� �5�UK�p����o`��K:�L$9~88}��@sG#ph:� B�!KC�qh�D?�=��SYU4�q����D8gZ�4z>a�-P��BfN$�s��8֖�5Q�,x��.85��;D&#�<�� C��~(ڂ&*MĀ,����|չ�s͚&�M�z��Z��{�f[86��ȱΆN�fr���)Q��Ȣ�M�B�&�����v�W�T
\~���sWl�§�2iv��Tv4����c�I�WS����=�n��-���]��ݕ�Eh,���+���VTx9�Ϸ����b�����}^�S~ϧ�=��iSls
-r��&�&�eE�t���r�
{,��|�w#]���~hih�PFM�2K�y��hh �o(�_�55�K�J+����e^yc��Ǽ��e9���j��*K���1Ĕ���$I�hm�T�'_���*^M��RL�>��'��F�T�c��2	N�U�p^y��qN��)Ȕ�8��T'��X#��<"/����;�`״U�D/��ݗ���+&Ï�(h.�G���%N(�SHxԟ.
,��M��Z��W��0B��u��\������U���ͮ�T�0��1f���|Wu�*�2�"����Fcyh=偬�)�(
%�U���)mv#��c������(��v�-7]�v�6P�6���?�a"��P2J�p]�Y���%��x`�R˞�|��8oTP���^r�
&�HJ�1a��Б��a
,ʤ��}(a��eO?���6�����X�O�B�rXp�А�q��^�����Ձ�����5��R`~��!��x�񆫱@���0�ˡ}�����3J�R��2C$��i�(e3
���#���/����oR�4'��@���W|����<��ׇ&��8�d(
��Sn�Ou`�3�"yFZh��0��ok*&���H�,˶�yh��@�h;!����E�"�@�ޏq⨰���2��R�k�!�隭��᪁jx"2Ť0/�D�G	�̰�o#��!U��FI}�M� �֛��{t$�����Ĥ#<X���� ��
-���X�є�.e@u�R"��,����b�9+8M>��T1L�	��R����v\�����X7�P�uq}�W���Kɽ���eb�Ҕ�oG�/
)�ݫg��*Y��AN��b ]�V��^tRhz܇�~_z�qCy2�ԡ��b*1Z�K8����jU&��y�y�Av�u���>��r���B�M�6�� �X���+O� Y)}����l��&�nZUA�
F��mZ���!AC_�{�k��x�_U.)�<�M0���Pa��|qOO�2�6jDZm��g�������e2���y���6��������+
-"V$`
W�LͣXBY>����&��kC�
dVP3<J�p�@���6LF�QL7��n��B+@�0ŵ}�k)a��4�~M0��Ls�	}H�h��|nv@̡b+[�'0-�9�D�8��z��҄��	����������i�$	r�Y���u�e�|(�r�%��W���3�c�ֱ��ݶ-�y���F��{Y�E=Y�+���E�>��F5�ɘ$��;��cҐ�tL�P|���Pn
-y?���H4!w�m�1=�c�!�M�a�Ի���̔��QC���}:�@�j3<��⍯͠�lj�5����B$���^�}���t�J���Ų����Kix˄�/\��̕F*�D]��2�g��B�</9MHVOV@�7=��� 0�����e=���J��r��O��b�Czx�r�
��f�!O��w3P�{���1*�
K>�ou2pΗ|؈���i���p��!��`\��<�^�%2��;R��KȊ�˺+�5�g��O���˅��� ��E�?�R�;�S��{�y����HCI�����Us?�r.|R�J�:�D�J�sL0١��L���,dG8�h��芿�#��9�p:_.��/S}�����uH�Œ
����8X6�
\Ģ�ʮ�@�6�C�Nf�A�c_��).�����)`C'�54���u��j�O�Bc�nW^v����-�;iE.cR���
�i+�D��xh@ܜ�i�����5Sx������C4v({�Y4�ܿ�@+hM
-DZmx[�Cj�T�í�{����wu�u�z��h���;Ť6���D�U8�E����8��ӿ�*��'Ύ�G)����u��0sE�Nc�
�#��93��ar�Tx4�Aa�˚jU�^qp��m���'�x���c'Ԓ�Z��|�5k��G�	�'<Y7����wk�SD����f����;��L�/�=����tʔs'2a	�_ʂR����0���H�U�/AS�endstream
+xڥZ_s�8ϧ��*35��E�=u۴��n�K�O{� �J��,���4�� HY�崽Ng*���~��bf,���fi����̖�3>����g"��#�|H���ٯ﬜e,���n���Ή����2�΁O�|�zw������Nn/?^�ϥ�ɻ�4z���?^_�υ3"y��ןn/�i��]^����'�^_�����zsq����g��^��\�F����7��`ۿ�q�2gfO�™�29[�i���Jř����_=����t���t�*���1)��w�UΟ������N�$/���0�_�Y͝`&��lnm�,��޼Z̈́`�1��R&Sl�b���Wx��0c�j�t�3���H��|nEr����βL1���L8<�2��,SD3���O�O�z���
�g6�R�;0�;rz�B*��rΜS�+|�T���$e{>W6K$3L�0�W4(MU[�Y5E�����n�i`Y�$�]W����=a��m�a��Vۢ
���O���7�y���z������g����sP����J��Y0��y�Q�6���=��|z.3�B
+8#
3F�i0,�6��g��:F=���{��q���1	~`�l��H�H4��:�2�)��|(?!d��J�"&?Vs`����J�_�-v
��������'����+��mQwc��Op2�
+|�\�>(Z6��\X��Q�
���/,s �h�+b���O4��l��e.�[�L�<���)W�G=߭6s"�:8�BYc�XE����![�l#���bIg��$���o;�h�hM��0ei�6��W��<�x*���<p��›N�I+��C�(���I��v�:ε�}M�C��W��t�Єs��'^~a�X��E[�B��D�#�m`���Q�;�֬ia��4��������=m����F�u6tj���c?N�ʖfnb^�i�9��s.iOyU�N���݈��]�
>��I����{��v�|}8V��|5�-UE�}���S���S��V}����E����F"��
'���qB�C�X�ÿ�=���z*��T�g!�?n�mNY��D�ĺ�����]N`��R�ߍt�������B
}(�,Y��s���a���P�~��4X.*U��3�Jn�y�	V�j?ˉ]x��扨���p�AL9��>(O�t��&�0@Db�5_o����A1&L_m���	��.U���e-�L��5�W^�8'�q�T
+�,��J�pRO�5�9�#�{!�N�%욶�F����}y�/��b2�(���\��kW#N(�S(xԟ�O���[zm̯�%,a�B��k�ޭ�%��*_Ta-_7���RYB�tVǜ�*��]�M(�4˜�t�G{ ?��a������4�lVd���x��!p��"��B�oCl�8�hU��m���&���!X�!�1���-1���Lk�8w�S\J<�S�e�p>�x\5*�Ԍ䦗�	I�47Y���hPQ�'����������ɏ5��!W߲���[�U������>�R#��
+�BXp6y�h%��2����C���������8�O��#8���$Č�4�̐�����0K5LI��8���t{&@�����Ih��_��p�^G��#����		�<�9:?7�����c��H@�ڣ%L>�ۚzH|��#�^�e��<��x o���A�"TS`X����p�O�&�d�eڼܩ
�Nwj=�OR
4���)&����H4!xT�;�
+{ �6b���P��hT�c����n�	�x��DB�x�HL:�]��fJА:t���6
+���
��^0J���]~�()��G�	�FI5��H0&�E{�`���
Ci�n��k���=x^a<.%�r�F�Ĵ�P?���
)�ëg��I�:+�x��b�H�^����0������`ㆪc��C���b�,�����
TMX�^�]�dȻ���K_���e���x�_!�QEP������*O��D)}���p6h`�n�
���v'#��6-^�ѐ��'�=�5�����U.��<�z{((�C�%��-=�ʐ�h綡g�����n��m�o�q.��Sh|��!M�{Ø=�<D��4�(�X������G� �6:&h�|���%,%�ӆV	Ȭ�a��P�8�z��mX����n9��x�Q��aak���R:�R�i���^���B��n��'<��
1�>�lџ����0��w��1����� �.�f���T�H�'�(�3�R�E���/��C1��{,)T�Jd/_~9�i;�m��m���q�9
;r�eU�d[���3.����
u�'s�T�I����9iHu:'�T�^�TE{(7�r�K���H4!w�mǙvʎ冪6��iR��*2SrxF
�K?ۗ�i4�1�e~����M
V#�;!D�]����+x��W)�SߗZd��ͩo�R�M�qI? :m�H�a�˗�'���YH�/��4�b�����
�N�}}�*?�a�IHp�s&�R�ㅡ¿4p������Dk��ŝ����f���^�
*5%�a���n.���f�w�5�u���eN� $���,@��P{����AFS�B����X�rYwŶ�T�L���qҸ����ޠ4�kP�z'��eL*�}@t:�"QL"�W���W��|*��
+Q+�_ԡ':Vb�W/Ǵ�jAծ�Ծ.�B]�s������^zj_m�����տ�����}����{�o���IJYo���*�>S���P	��8����DZ�S\�� R��Nfjǜ�7ԛ���l!�����nW�s�������S?kP��o&������O����ΝH��
ySE�p��?$U�U'T�����endstream
 endobj
 993 0 obj <<
 /Type /Page
@@ -3364,82 +3344,82 @@ endobj
 /Resources 992 0 R
 /MediaBox [0 0 595.2756 841.8898]
 /Parent 991 0 R
-/Annots [ 998 0 R 1000 0 R ]
+/Annots [ 998 0 R ]
 >> endobj
 998 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [361.118 468.8579 409.8647 480.9176]
+/Rect [361.118 436.2023 409.8647 448.2619]
 /Subtype /Link
 /A << /S /GoTo /D (configuration_file_elements) >>
 >> endobj
-1000 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [347.1258 85.4256 404.2417 97.4853]
-/Subtype /Link
-/A << /S /GoTo /D (journal) >>
->> endobj
 995 0 obj <<
 /D [993 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 378 0 obj <<
-/D [993 0 R /XYZ 56.6929 647.7963 null]
+/D [993 0 R /XYZ 56.6929 621.8163 null]
 >> endobj
 996 0 obj <<
-/D [993 0 R /XYZ 56.6929 624.4206 null]
+/D [993 0 R /XYZ 56.6929 597.0941 null]
 >> endobj
 382 0 obj <<
-/D [993 0 R /XYZ 56.6929 550.3829 null]
+/D [993 0 R /XYZ 56.6929 519.9904 null]
 >> endobj
 997 0 obj <<
-/D [993 0 R /XYZ 56.6929 524.5365 null]
+/D [993 0 R /XYZ 56.6929 492.7975 null]
 >> endobj
 386 0 obj <<
-/D [993 0 R /XYZ 56.6929 216.2206 null]
+/D [993 0 R /XYZ 56.6929 176.8325 null]
 >> endobj
 999 0 obj <<
-/D [993 0 R /XYZ 56.6929 192.8449 null]
+/D [993 0 R /XYZ 56.6929 152.1104 null]
 >> endobj
 992 0 obj <<
 /Font << /F62 638 0 R /F43 604 0 R /F84 802 0 R /F42 601 0 R /F57 628 0 R >>
 /XObject << /Im1 795 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1003 0 obj <<
-/Length 2948      
+1002 0 obj <<
+/Length 3192      
 /Filter /FlateDecode
 >>
 stream
-xڥZKs�6��W�tU��A��3O֩��z���l�D۬�HE��8�~��%gk�4M�����|���/�J�t�¸,U���z{�O0��2�(�K}|�����:-���q4�M��|��5����<��_/�b�N��J�����w�q�|���������pm�����;b��|�����ts��Vq�^��|����������O�{������x��I���W�����W,�Ϊ�+tXʝ��U�d�2)#�����?�	G���9�eʦJdz�TY�M��[��L�ՖF��
-�{+g�V�Rh���m�weە�v���8�9�.�B��x�%z�-�Hn�~����5_�x��$�h�H�]�.�˘(Z�"@�r{ؒx}خ�=
4����ht� �u�/iB�t
1Wa�/Ůg�Z&wM��X,5(�,��SJx����*�0W�!�)kjG^���Q8,�t�9חOt,u�D{)�j_���|)���ړ�T.5<�
-�Ԍ�����T�H`�� 
-�C�
Hж0\uy]4�����N(l�����rص�!��ؿ��^˪"jW��}X���� |��nz~��9�P
�I˒`38��ɰ
`o���$�қ���ʌ��� �1?7g����ZB��	�UD�X燶�ɋ|�L����X;�/Z�r|��=1Ve7�O�Ŷٿ]��$V����Z��q;��7������,���![0�)�f��-�*��ߙ�%�q�Gb�d����4�L��:�
�I�.|��6���o��s�V��F�*�7Ś욷�~S�BC��RES	��>�=,�e�#㞏v
۴�0��}$u!ڣ�?���l�K
�
-sy�^jf�I�K��N���(̡Ӈ9���=
-s����ç_���b�'��缋�_�a��@����t�q�ԧ��4�2��X�"U6��r�:	f��|��a��&.�X����R�"X|��\Q,����4�˔9i.��K�(0�+�f�j�
*�Q!��K�ms�c�
�(@��}@�'<$ Y��8_<`hk��w�I�H_e���P�T��f�>�Y�#�O� j'�0A$��ˉ���1-Kd������P�Ґ��W�>����~BJ����a�T�EDR��+I��;�l��@T��wɦɪ�υ�Q#x�G���P|a��Wں	r���>�����k,I�!P���JB�x)�W�B���aa�U�]E��O���y��!e{�������iH8o�Y�R�D
-�v��T��s��v��Wn^1�u��A�w�X�����k_�q�<R'��<*vvt�O�A��w�m�)�Ѷ)�1pj'�fijo?,P>
-F*2zx�1ԯ��Χ+�Rn�{�j$u!]E�X�*��E���P�9P�
G^֠��Q��r%�T���\B�M�,�/���';���ɭ��-��x���>N��ž.*���n��RȀe#@L�,�4��&�+P�y �=!2�[!+mސAC����+�HAY�ȹ�0�ܼ���7�|�C�)�e2�<� ���!^Yυmܽ����uA�k^vl�㋀h�a<�e.`�ǦO�0�*��vy�q�>{@���Ɯ�`����h����A!��~��LY
D�O���l1]�Bڥ�R�4\�J -ϼ<�@p�!]/�n��R��fS�C�z���_�{w�=`��\�J�R��;q:�:���ϱe�eT8}
p� ^T����a�Ф�S%|�eR�����tBH�rؼxA5Jm��@�P�]�����C���١��١��͜�.e������V#�4G�#���vB�9�cX�Gf�^��#Zͨ=��Р�f�υ
s�o��!�(`1��< ��do��N_t�CZ�
�u���G��v|�o�p�g���J�,�"S��H�BD)�+�}�*��Bhni/��K�(1�M�TjŧZP�
g,�`��/������6G���^C䕖�|�E^'��Z�m��?���9�;���ݔ�J�GﰩQ���I��!��uʸ!$<e��.b9cǾo��5���>|s���WU��%����H��ZNl��Z�q����ۤ���Pyq��C�xC�r����ܚ���] �>����>���]a��Q�%҆�q���7���9��s�X�|$�R}�|�p!e�yvY�(4�´�T9%�:��7��
�
��#	��ӤK�{m�_H���!�$�\]��*s�Ql�G�[�/�'�CJ²��
K��Ga�Gw��'�U�3	R�|���]��7��o�F�=�7�7΍�#޽�@���{Cz��`IA���1���x���#��3�U��3`/��\I��"~�aw�m��tS΄M><zP>�	���.�/�.��*�ʰR��e�]�� u�P/��	LB�@��k�Mٮ\8`#����R����rCRj��%v��y�3�ކwߙram*2
M� =��T�(;��O��% 	�&��kv�yW�ESǟg�}S��N��b��(w�
-��;���x�杜7�:��z)��3�w)�1��Q�����8�1n�Ը˷�	b����&{<�#� ]5O�MÞMqܩT:֙��8�grfe|�@e<�SJ�c@3̐���\�#��L�[_�UD�H�˶b�e��ˠx�#�ijW��`h��L���D
-'�~��xc���ߦ!� �L��s�w�
-d�b:�2j���c�c��+�f��Re�����(�q/�Q�,8���8\��Z$7'��9���h�F�y�,~_�e�I��~��<���-_|��~�-�y���~K6��+��,l�ak�����+�̷k��"t��$#��6����/ə3��Z.F�����j���>�O��9��-$K���c�X����*��8��b�g�tj�3�R�����VР��H��
;J��endstream
+xڥZKs�6��W�tU��A��q2�d�J����=ds�$��E*"e����F$(QrR)���F�@��_�2i�En�T1���[<��7W��,�2������OZ,lj�Ћ��H�I�1|��9���?>��_/�b�N��J��ۻ������w�n������<Kn�����O7�7wo���(�/���n��!���������o�n�����L�B~���������b��F-^��Rn�Xl�2%S�Iz꫟��5�Fݫs�˔I���b)��h�1ke�2V[�ʦZ
+9X9��r�B+o�ߖ�o����]�{y�l�y�1�5���5���T�Z��H3�᧲�a�,)�
JU�ÖN+G=�{"�b�L�W��cL�e��ʓ��\��6z��?-���6𿳰S���u_�
i���c}2�Se��lށ�-N��`
+��oX����k�?��-J��Ou�`R�S��pŠ�n�M����k"�Iݮ\W(���ػ/�42�ڭ�j�^k�M���s_4]���W���16^��S+?\�v[�պ��7�6]�ӿܶ/��"9K�h��M�X�U�o�I��<�8X�9Y����U�u��݀���&=gz�P|��L�Ff�D��t!�=N��v������[BH���M���ө
+���1+B��u�ŝ�&$m�'�!��t�B�������rO�k����qu4R6��"��--u��������2�k{�p
:+���;���.� ��0�ACϨ���K�ej-��73�:�����r}�w�K�\�(םl&D|.��\Ta���a���4g�N��d�$(��&���$�9{aT4e{舋��/����|�u� Ʈܿq>��ڕ{��~FȨn�(��Q�Z��E�jN�@��6��Ϙ��0q��|�K���b�3�f]���@�YD�U�.]I©`!١y���ax�#���Ǣ�SǪ��U�d9l�v�9O\�5�a8�a��������)�A+KN�����nWo}فT)Ux/O^��D<R��Ab��@�d�[d�y�l��Q"��v��&nj�Fs=/~vn�Y���\�]���-ʛB�Z���`邏���}&'�{6��U!su9�c���>p��Z��ƹ W�'�ff�Ĺ�a���)>���C��<�Ga=�/���G��6M9�t�蟋>Pn�|{��aT�^��M[���`���rk�*�E�<�<O���S��k�wjv�ua�W@�kDV�X�2�<��5��d�p�`��S
��ۤض�Vp��!n�$�������6�L3l0����Q�[)&�\�*�}.�@
+�L
hՆ4H����z�&�dS�Q�~��CA�鳆���S�ѐ��W�_�h�N %�A��gX/���H��v1P{�h��:ƫ��;|]�5�{}*y
u�h9��ٴ���m]������n1�X�\�'B� ����v���*_���s��9
+jB^N��=.���/�и�
	��<��xN|m������	�C�cc�r8���2NG���h\����H��/vaS����|r�ڏt\�I���My��S[95K�8�a�rQ�1R����w�~�Nu6]e�I�Q�r���Χ��+ԩ x�,=��r�r���5�fT8�\��v��OX6!E�&m���]���yG����l��V�OyTC\����>N��ž)k���n���-�Dz
�
+��v�jp���۽b�"ü���
;h��RE��)(�=9W�Ǟ�W"�E�F�+ž{,�$��ZP&C�
*��~꫚��V/ u�b]�ZT=
[h�"����O�\�T��adU����8�]��g@,�s�ю��,�!Jz�(K�	�2U
���@Qu�.O!�Rd�eo⠼�+J�U�:��z�G���r_��j�cԡǢ�L�[8R�
Bw��T�"5�x'Lc��a:p�[S2[V^�ӛ�FR�E��q����z����LjWv����c�6��^�*�l���k)î=�IJF�1�f��ݾ�8�P��f6Z
+���s_��K1�E�Gw�]�/-��	���Md�Wl�@��f�<�ΈϠNf���x�ś���Jοb*�niq^�I�߆#}����Hx�/�ٴ�=r�`��|��� ^���VP}a�wNU1ׅ0\��W�~U��8���u�f��&x*��S-(��320���{�x�m�:7E��z�+��4�}E��uԷ-��]�@w���;
���{�W��82x�Ise��=��n27�L�v	�?���c�\nb�7Ix�|�ľ�����m�U�_}�%����R��'�n����q����դ���P�xV�y8�!���n��6��D!7'[St��G���]FPtA?��Į0�*��B:8���W#Q2����1��H��|���B$�T��
+�iF�i=2��JNu�76:Ӎց޵ʆ�I�4e���?�C�IԹ�"$KUfÝؼ	�47/�Oj��e)i�,�J݂Qŭv��O�*|���(g_�p;��ů�{���Ƚ#�޽Q6�7�8�F��;�����ђ8��w�ct��16�lpc��OJ&��zc?�D�n��\�³n:(^I><:L>��z}A��/�N>�*�*?�?��).
��U	�����Y�n?���<M�Z{rSu�'���ꨍ[�ԽT��Ps/c̗ب��5HZ��׾3�˜Td&�@�m=��wz��n	z�G� 6MR]����,�4 ��	_g�uS�+<N��b��(w���;w�<W��;�#�:��.w�3~�������(1p�hq��ϏԸ+��b���>��
����s�퓿�0gS�*�V��ufŧ9�����{F�@Of��1����G��kՀ��-�{���RF*.ۊ�m���A���ijW�W04�?r&ʴ��8���M0ޘ1f��&��j<Þ�E�1��IzC�Z�`�\�I�6��TP��<��#�E^�t��z��ȼ�x���y�Ersb*��N�����u
n�Y+�)��ZG��/o�|�u+Zċ
+���d�*�Mn9���)���5�+W��oׂ%�oL�%cGCO�-��oə�S-�\D��{� 6�ֳ�j��|i�
	�L�b�+���J�$��b�8�/�S#l��*EY�3��?7J̇W��.ќ�endstream
 endobj
-1002 0 obj <<
+1001 0 obj <<
 /Type /Page
-/Contents 1003 0 R
-/Resources 1001 0 R
+/Contents 1002 0 R
+/Resources 1000 0 R
 /MediaBox [0 0 595.2756 841.8898]
 /Parent 991 0 R
+/Annots [ 1004 0 R ]
 >> endobj
 1004 0 obj <<
-/D [1002 0 R /XYZ 85.0394 794.5015 null]
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [375.4723 755.8266 432.5882 767.8862]
+/Subtype /Link
+/A << /S /GoTo /D (journal) >>
+>> endobj
+1003 0 obj <<
+/D [1001 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 390 0 obj <<
-/D [1002 0 R /XYZ 85.0394 449.5881 null]
+/D [1001 0 R /XYZ 85.0394 427.5127 null]
 >> endobj
 1005 0 obj <<
-/D [1002 0 R /XYZ 85.0394 421.8763 null]
+/D [1001 0 R /XYZ 85.0394 402.5515 null]
 >> endobj
-1001 0 obj <<
+1000 0 obj <<
 /Font << /F62 638 0 R /F42 601 0 R /F43 604 0 R /F57 628 0 R /F84 802 0 R >>
 /XObject << /Im1 795 0 R >>
 /ProcSet [ /PDF /Text ]
@@ -5335,7 +5315,7 @@ endobj
 stream
 x��te\���6� �t�����ݡ�000� ������R"��t	�ȋ>������?��?��w���^�Z׺�7����5�
 ���r�pr�t���P(�W琅C�
�f
L9g0���]��#�5@��xDDD0rp'/g���+��������_��.+� ��.[�����;9�a����@=0�j�@�`��������YI������P����C@`��`w@�:@p�5���\8�d\@��y{��N�!v�������
��l��0����
�f�[����G��3����{$ӆ�����!N��Ǭ���t�����y�
p�GOk8�����`�4��+s
��=]��!.NP��c�G2'g�n.�������@gk(�����wu�uO��=��	��'��� �.`�
'&�cN��cn[������l����nN�����
-��{fXE��0��l�ɥ	w}L	`��u��?���@��#
�����ܿ��,��v��N���j���xc�ߏ�s:B�^����F�4�;W�c!d`����������(B<���W��}���
�������SL7��0};�
���A`����?6�x.EU
9U����r�A�˂GP���9p��r�o:#
��?��de�
^7���=*���7�����
tu�x^psr?Fr~�s���O��o4
+��{fXE��0��l�ɥ	w}L	`��u��?���@��#
�����ܿ��,��v��N���j���xc�ߏ�s:B�^����F�4�;W�c!d`����������(B<���W��}���
�������SL7��0};�
���A`����?6�x.9}S����r�A�˂GP���9p��r�o:#
��?��de�
^7���=*���7�����
tu�x^psr?Fr~�s���O��o4
 0�����a֏��O�o������?��x����=�	a.��Ab���9Y�
���/z{x�œ*�����2#�Dj,���8��E�y��;�o��n
�A����ߋ(��X>�.3v�ms�W`g��Ϩ�"�
 rn���蚗ߡR�w�9�_�ҹ�_8=�e4%v>oF�k(�?`Lٽ�`��4����&9[~��;26cL�|r)S�j���l(��
 b��7�����V�h9���,�I��R���e��߷R�%=���
�t��(��%�LǏ�)��>1٥����^�2��O��	%��>�pjÕr{2��w��<�g��-j�!3c��akI�,A�$�L��ƋJ��n��U��m�މD3
@@ -5358,7 +5338,7 @@ $O
 t���=��b���w�6�"���µ?��J�OP2R�oQo+��1)�w�����d�I��Z�V͝�(e��� �
"Q��F�s(�F�$'�qL �/�!��
�Hvk։�h�ȉ��؉�o?�a:���q�c��g�!_Q�~�W�1�a��U�Gm�Y�mn%�R�r9���0q�5�/�E�(�ړ��,W��$�����Lx���|�奕�w�Z|�V���,�Od
 �y�G�
 ����3l�4���\�T2Z��Ag�.7�#�P��v�eŦQL����O���\�	��ĵJ��(�3�].�*,M�>�Bx�(�S��|D�u��ޡ�{:ґ��2G9�C�{ɕ<|?��K����@F)�,�w��?�� ���a��h%ٱo^��{�6��@�-��%
�~j�wXjz1��i���%u�3^��g��`d+�K[�De��]��Y����?�>��Hj�,�kѸ�h�8���v_�
[�J֮�9m=����?\�k>�ଇ�*�ѳ�,Y
�<���u�Z/ZV$S��#�mNO��5M@��r��0H�7�&7[��A���O�Ƨ���5�pE6~d��^.x�T1���$��7��4����j��G1���po��3�Q��Z:�N����,0����Zg����)�Q����X""���0�����BvFA�)Y9(�YÖ���S�|�����qb��N.L�X��_��¿�%�%�����|�
D>W�7}C��#�ZR�
�$�`b�Gο�a�9g�S%\��/���hC|�?s�؅�g����)��m}�v��k��.b�&O
 ���+uqf�`�a�����,I�㯽/������ݛ��'P6ߢH�
�?����ٹ���9��mHr7:pMRY�#� '�W���KC�|-�mW�躖nᲶ�0����3���=j�
��-,n��e����b�i�;��H�l<)�L.��Y���ڷ)�wL=(�����L|�)=�'��-�@����<�Nr�6�E�ʃ3�d�k�����%�����(kD~�(�_y��;���f�O�{&*��yү9ۏB�T�d>�.<S��X3p7��~�"럽��l˴��DQ�f����H�EIA��Ղ��}��l:�$k8�y&3����t���4��Gۆq	�PH��ܹ|
@� a�B�ؠ����r����خ�����i��
���� ")��1i
��s�u�sj	-c��]�JH3��>�Y[a-�Zy��px9���>穾��*|,4��	��=�	a�{Z�wLVq�C�o,�H;�_7Gg[�Gxd�D���*~�JS�/
*���F����jQ�jw	�]_-�q;�,1t��2ߥƐ����{:֧�o$<����J�����λ�b�F=���cT�u;�u˛�#��Z1q��Y�gH�^fiyv|��,Pk�A��FH�s^�E�R�ƇnQWE�t%ڷy3�{����FbK�<%�)�"-L+{卢�zS'�#���Z�+��U��׎#ǩ�Cc�H�,��;�=����.�Y�g:�j��n������S:c���U�W��/�f���cO����M�lD���9��:­����ۘ��˝r6��x��2�]�S��	p7O�,j1�����{�$�S7O�xY�r��s����(�ݚ���D�@��Y#�C�L%��ល1A�ø�3�~M+��A�D�>���c��-N������ߍ	��tz�"�t��'>(���hS���M]��ۅ0�
�<Q�-GSc���o��jԼ�>�SP�KD��dOjn��|KHtޑ�+㢟S'�@6�i���C,��g3B���p��Ρ��φ��n��;ɦc�
_7T,�Q1�TiH�B�WL8����	�,���.�
�u2�)�=�O�����ڴ���,
Aq��r�^T!1����2�)�N\����)���R��b���6Cb5����ޛ�;�mH���L�^Ȭ��ݸ��	{>�m@���z�N���׻���B�]���@)�p[j���6
덶��BSHQ�ר.�ثN��`�G��z�^n)?����892���x������%���3��ZJ��]\�^���SXA������r}[(�0�@�el��mi���EW�9�QѲ��C�ۯ�A�=�g>MF{Q�=��*�k�+�����k<g�_�}�����I�]������Nj,���,���
KcIJ����S��PVB��-"�(��dp�A1`+W�[����H�a�:5JoEM���ny4�K�\��c�p���&�gk\99�t��Qټ�WG;#'>�i@�ħ�W:x<��"�}<=<��C�Q�4���i�U�S�A-�iM�k�qn����O��R<)D���/��T#��M�	�$֞��3�п��\�{U���<UW=�$�&<��Z�0���g��R*���O�1�'�����j*5w�-����T�j4�i��u``�h߯��K�ݻʔ�k��A�����D��tk��2��������$��Z��@�^����^E~������u4߉<*􎱧�KJ��y/�n�C*}���LgI�J�8j�[�޳	��T7%J�O��,�!؞�+���f��Șs�h`�q�O�1�<�3(�d�OfBO� �'"p=Q�B���pJ�}�����Z��!p{���a}�q<I:�\�M�ׄ;�[ݯ��l�,�T�O)��-x#��
�o?�1�pŠۏ�Z6�j��
k+�1�g���jd�3��6�f�J��Cc�g56�n�N��:��F��5��*���Ӎ�=�<���a��7���H��CF��%p�%'�*�m��_>ѥ�䃏�DKX���x�(����
���{����j�dqX���P��v��π�i��A�;�@�y�*�o�L�O��������xO���c	-@Y�Uʳ��;�Bi�M��.�\r�;�U��R�'��)眄��	�@�i/_	A�����r�0�Fx<�Er;�zǴUϚ�S���ل.�m���h���2ؒ�/{I;���j�m��
-*s"}Y
;҉��{Y����]p��ݯ���Xo���}U��Z�: h��)8f�E����D��s��qTM�:ù�ɸX!�l�������΄,�17�b�g��&fܽ�Y'jeAt
]���wV^�%����R��tΏ���l��阦j����ϸ3�m>Yj��C���Ğ���jb�n���
U��?���u���W���#��,M��ߥJBQl���X�-eb<Vڿleq6g�|Kʷ${9;�9I�0������y,B����$9䃦��4���/:Z|�M�j�z�]���8)9I�� u�K�l��/����Z‰wf̨:%���:��AeK�_�^�P�wx��DX9�e�zƟ�JK�&fp�:.0tI%L��$�^�"��oK��ñ6&�BL�����$V��4���C�2�ӱ���n-m��*�pk��ކ�	-W�X�����߿[�Y!Wg�#�Ӥ_��������h<�>tx�]�s<���:X�Q��w��-N;N�?Vl��vG��,�%�9����'b�η9|1.��!]��D���=RԌݬ�I�g�
=�h_�5r�/�����	tv�;�0�����endstream
+*s"}Y
;҉��{Y����]p��ݯ���Xo���}U��Z�: h��)8f�E����D��s��qTM�:ù�ɸX!�l�������΄,�17�b�g��&fܽ�Y'jeAt
]���wV^�%����R��tΏ���l��阦j����ϸ3�m>Yj��C���Ğ���jb�n���
U��?���u���W���#��,M��ߥJBQl���X�-eb<Vڿleq6g�|Kʷ${9;�9I�0������y,B����$9䃦��4���/:Z|�M�j�z�]���8)9I�� u�K�l��/����Z‰wf̨:%���:��AeK�_�^�P�wx��DX9�e�zƟ�JK�&fp�:.0tI%L��$�^�"��oK��ñ6&�BL�����$V��4���C�2�ӱ���n-m��*�pk��ކ�	-W�X�����߿[�Y!Wg�#�Ӥ_��������h<�>tx�]�s<���:X�Q��w��-N;N�?Vl��vG��,�%�9����'b�η9|1.��!]��D���=RԌݬ�I�g�
=�h_�5r�/�����	tv�;�0�����endstream
 endobj
 1195 0 obj <<
 /Type /Font
@@ -5367,14 +5347,14 @@ endobj
 /FirstChar 67
 /LastChar 85
 /Widths 1348 0 R
-/BaseFont /FJYMCJ+URWPalladioL-Bold-Slant_167
+/BaseFont /UCTAZU+URWPalladioL-Bold-Slant_167
 /FontDescriptor 1193 0 R
 >> endobj
 1193 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /FJYMCJ+URWPalladioL-Bold-Slant_167
+/FontName /UCTAZU+URWPalladioL-Bold-Slant_167
 /ItalicAngle -9
 /StemV 123
 /XHeight 471
@@ -5394,13 +5374,15 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-x��RkTSW�����RI�zX%2yj	�@�X0<�!1��ܒ�K/7�4��*�ʲ��.y��RaU��Zb��/�*��q��U�5�����̯YsΟ�������M�3D��`(��09B,�I9l@��l
-���
-��

G �
�u�]
�|!o��ǧ�@0�n��T5
���$>iaQ*P SjXK�P*4@�)�00�H�
�&od�up�g����Q`#���֤&)���-��ߥ2a<���d�
)�P�
@���Z���`R�C����F�V��,?��_�
--�1�����:Ɓ�`�N��ߊ����N�J	�Q��T
��L�ʷ8�!A�0�J5P)4���t%�S:X�H�$8�����JF(��2�À�{*���&�$��l6�$���)iZ31�� M\�P��@!���x��

-�z�I�,&��@:�TN��W6`i���I�-�����#ݛ����� Lod���G�b��|;�OD��a��Ҡw�
-!=�a=��XobJ����;��&W\�y̞���|dk��m��~��^?��x�OQ�G�9os�9�T2�
R����E���������F��/��P9��<�rY[�ڃ;�Y�7z?��������uk�s��ԑ™5�n�z��������5�9TBI*;�f/�ϻEW'�bU��������\_[��w��n;��2��
���9l�^��A�H[l�+��g/��Sn6�{�����e���<��wK�sJ�b�ѣ�U�(kh�C���p}��mz�`�>2�%����_�Io�K[�2���ے�3�&�x�������Pi��q?1#���@`���0��M�����#^���!
-�uXej��=�?�yL�7��n���ʥ��k���M����&˞D��F	����ѿ.��p�%�	�)g�ny_�m�P�Z[03��$�T-i�����p]�7�I�8Ի���E��]x㋎}v����$��8r�gQ��Жi����}�;^�b���=i�q޲}PT6#r_����Z�c������8v��瞊�~P��E��+|ӳ��6چ+��	����)L<>�lK+���'ƍ�ܳ�l��%���8��P�q����o�\�cE���3 ���?/�}�u�'T��,njO�������؇��;����fi@���?�VE2�Ϊ(#[�]h�?A��+��n4�m�r�"���n��~/}�Z��M�%��U%1����U�|<�5c�BT�TzZ��fƝ�cOJ���^�7��oWD�����5��s�2R��˙2��M�|o�|U�A�9/���t�S�>����'�/�_�65n�����F@�٪۷_w���l��Ϗ�u�۽�S��J�5-���+�;��RV���^1��׶�1uC��e���B�Fec�i���bǏc4�xiT���v��ò���vp�����4�Z�s��n��e�+�^p���sN������"5
%�*WL�'�	�~���{�!�K�Ğ5�T���-/�_��j�C���4U��ͭq��^����+�kN��ۋ�y���S�/_'�Z���!���mzڲ&B��`!�k{]��yy�Ҡ��F��
���~A��
ԉ���s8�y���Y�b�ݬ�]�����j���qKҵ�/G#w�_Z�X��"��X�͛g��4+�p~����.���OPj`N`Z�F�7����endstream
+x��RkTSW�����RI�zX%2yj	 b,��{CnIH@��TeY�F�<EE����J-�
+S�ia�q��U�5�����̯YsΟ�������M�1D��P��ar� X*�p؀<��-����!r�@�VkՀ���B�
+!�O��`,C�#i*x�'I| ��8���@*'T�������S 0�g�Z
�M����Lς!&��
� �F8
A)�IMT�
�[�f�Ke�x&)
+xMɤR$��j=�`%��#���������C�j�Z�f���S��5�Z�;�dh	R�qt:5~+N
+C�V3=+!�jD!B��0`pV2�+��Hf(���H�P��R�΄�p��+!�������$1Q޿�T2R��D�>�?�S1珘4	Gt ��d�9$���N�Ӛ�Q!h��|���z
+9Dd�@P�
XG*f1Q� �ҙ\��p����
K
gfN�o
.`�M���$�קa:c0�<�{�/��ع"*�8���������)�`�rS�m�t����y��c��̅�#[;�o;e�c���\Ǜ~��?��y���q�ґ�oX���O=-�1d�m��fG7z�~٬��ᤔ����>��qϲؚ����g�gw���ׯ���WQG�f�޺��I^���~��א�P)%��̚�p�?�_�x�Uc�����?s}m����I��h˥v7L�/��:�@'�s }�%�L�Z&����zl�	�|��a�hi���:{��.�0��#)�-
��Č.8V風]������
m�[5
��BkCT�KzC׿��Ѵ��.u���%;g>M~���#�����a�~bF����,/�az�j��G�\��=B���خ�{�@N˘�n��<����K�/����t�����=Ib�� ���@գ]j5঄'������}���Bu�k]��dsshh����X�`�|�ׅ~s�DI�h��e�أ+~�:��›_t\�s����O�1榑#>��쇶,H��|���������T}�o�I��탢sQ�ҏ�F�n����=&hxı��9�T����/�^��-���6\�{L8G��Je�	�g[�P��7dq�~��痔��'�ȺC5�ݛ>��rю
��@�!��4�����0�����#т�;f��c?"�r��?���
����[��:+�
lu�w���
j��Թ� 7�� y����,u�^��5�d���ïNV�Ʋ򬽫N�xkƪ��l��z�͌;3Ǟ��[��^�7V�oWF�����=��w�2R��˙R��M�lo�|e�^�5/���l�S�.����'�/�_�66m�����DB�٪:�_w���l��Ϗ�wؽ�[��J�5.����/���y);��B�]�X�2q�kۄ������\�K������bU��DZ�`�,�@�~;e��ai}��;8�T9%�s[f-ܹ�g��˲d�_�8�/Ȋ=������b
��*�L�'�
�y���{�!�K�ĝ5������V�H��t�n����u��k�
+�H�ֺlx/��p��5'��%���ǩˈ��O-w�V�Z�	�1>
+k]�
�GZ�ǵ}M.���|QYP��]#���������1�F�D{��9��|V@�,|��n����&|�]j
p삸5�ZQ;�/-�,zr1CN���ͳl|�y���Z7�����'
+(԰'0�O���ߌ�endstream
 endobj
 1166 0 obj <<
 /Type /Font
@@ -5409,14 +5391,14 @@ endobj
 /FirstChar 60
 /LastChar 62
 /Widths 1350 0 R
-/BaseFont /FQSFCW+CMMI10
+/BaseFont /MAGIUQ+CMMI10
 /FontDescriptor 1164 0 R
 >> endobj
 1164 0 obj <<
 /Ascent 694
 /CapHeight 683
 /Descent -194
-/FontName /FQSFCW+CMMI10
+/FontName /MAGIUQ+CMMI10
 /ItalicAngle -14.04
 /StemV 72
 /XHeight 431
@@ -5436,7 +5418,7 @@ endobj
 /Length1 1608
 /Length2 6751
 /Length3 532
-/Length 7596      
+/Length 7597      
 /Filter /FlateDecode
 >>
 stream
@@ -5445,30 +5427,32 @@ x
 �RRRD���;
 fg�
p��r������;`�����I4�
��p�‘N�P��|�0�P�-��<���pi�4�(�0p�����@C�
�H��
#����7XJh�5��n�A��P��!>��C�o�
04�e������`�3�7��-�!'�&��&vf�Dc�`�	��j���O��5�wm4�&@��dB�`��-�����D1�0���a~ײ� 0������
�
 ���3���>
-jg����h�
�
�����O�����	���4�O�?9�0h(�V�(|S���mC	�^-�-��qv�G���3 ��;�}C��D��
�-��sS��?SY�?'�@�����y�w��]��v���������p��������n^4@�����r�ap����DS�_����fJ�)���r���07(��
�l��73��7A@�(8
����
�@1��Ō�a���C���" g~#�ނ� Su#-޿���nT��;���>t���1���nO~���_DH��	��D���M�?@�ٺ��
��i!������/��o0j0�{O@k�f����;�P7����7-�����P�L43��:$�$a�h�u
�>io�t9�V���-A��$�.I>�(
����w��r�\��Y�i��s�$@w3�ظ۲��s|��]���%M�6����Y�5z��u���*��q��`�'�/�K�/Ճ�;���ԍ�UXe�[���~�pv�vw}j9�ݶJϛM�.�K���"�^�ܤ��M0��$�5�̈́Kd~���zQ`�AXY���.�֠��=5ϭ�|�������K4d�C<�a�~��m�m�a�������ڵ�w}��=4s����
-���D��>?O���;\I��Xf=$��-p6\�����
�R�
�G	h�Q?���X���U���>���>rW�C�#9.P�%լ�Ǥ�ޘ���?�����3C��%��M�(w��<:rə\a:��]�������cRd#_�P��xu
-VJ�y��ӥ���:s�&�b�WI�����L������M)��9�cF���>��(Ї�v;)s,7��NC����mR�Y�믕�����om�O�*����b�(='���<O�t�� !ѮX.uO�c�}���Q�ݫ;`��0���:4[)���9�=F+���~V[��#3	�{_w��&>%���Z���[e�7'�L��Q`R�n�}3���p�TF���B�O��l��(�|�tFV̤�E1�I|:w�����P�ԠhE�BkM��J�J8a�P˧۪��E�iK��`�)��녣�{�6F��|	8eϊ���.�0�����[_�M��7Bq�@�ޱ�G��ˣZRw>2Mơ�$(���L֖Q.Q"�NB6����3,��Oj���P�g��\�%=�ǯ'�(�\)k�,��*=�^uDX�ܐyp:@C�%>Hw�sv�<T�T��zw�������g�0�fi9k�#[M6���~I���YC'ezkD�Y-_>D�QhЎ���Ώ�
-��i� ��˯�m��}&�q>�����?\K>�gp�z��	te�9|��_�h��X��P8�	"H>I,�y��VF2G�zJ3�
-������m3���&R��5����`��/ScF��o�<��IK�2�f��#2:=2��J��Yn�*��:j��lo�J�>�
q.�|X�-0�d�,��SA�+�H��N���ӌ���3U
-��k8�XOf��Lrٌm�X?�O.+%`�N]m�/(]�H8R�#
ZJ��x}ʲ~��宓wp�uQ?1�ZU���xNF��IJw����-��2�1��n8d�-��c�<,v޸$��V\��`�-h\,�,+�5pƧu�=e�F����<h6V�jxPX@���-
q9��)gܖ+>�Z�^L��&�]��=u�Q<�����J����D�Y�t���S=��wd�,j�<���%s�K�E+ӻo���moc2uD�{��Y|��4ع����Ph2̏\y��t�1<�	�s���������g2'oʨ�>�4Ѵ7)E�,������Eٓ��=��(�8��꾸S:X������~й��������Pg�qFN�3�8?
e��*�=yUbYjY&�
-M((7���uk�ݝ�|~'Ņ����K����cԸ��"UE���,���c��Arj�c7F
��p�!�b�
^����v�ň��7�3�1����n ��l��Їx��e�z4� ��#���l<���E}W�'�ux��fSZ��P;��b�E��
�T4��W���;%�tn�G�t�%�D�}�ǸY�u~,ѓo��+PȤ���YU�C�) 
��/uЁl{���嶯rt̍�1�+�+#K�T��'X9�M{
��W`r=}?�Q�\?;��H,� ��%�B
Kc��vc��?@�b�0O��-y
}�����%-;q�DeT�w#3�$�buP���.I`ikvUxO"Qa�I������L}��H
�n�	�@Q͊��M�☮�z�-c���R�Eoؙt���'7��R�6tO�����9���/� �q`��?��Wf�W�:$���R׵K���ӛ�AsrQ��xwkzJrS��q"r��ތ����M������zZ(v���E?�Ţ���ؤV�p�j�T��{�(v]i� �iG�H�⎒怿�"��S�F�6�PM
+4�q�,JvJ�6=���rȪO�9�rY"�u��_>�7b�X/��$��v���>�;Y�Ű�+�К�@�|�#x�e+�nj�g�5m���^�.�E�V[R��Z
-�0
$���{�Dl�5�u.
lQ"��1�WO�6i$הH��V�}^��+�۵�R|��W̞�.�l�RT���ו�^���_���Q1���j�&�/�pe�G�&h������
ݥ�NjW&���t'�o:�ɫ�L�8tİ�4���lTI/\��2�<�*�;�7��:Uz �&��mĻ�x��`T)�5-
�(���)�[��f�U��ƙZ�H�u�u�U�4�Kk!���b�"-8�Io�+
�K�?��S]m�����7w�,����x8��j&j��_��!4�|&x��#o'�XL�r�<��=;�)h�x�beS"�G}Zh#�rV��e����%<E>�-�H���L荒����;�=ׅ����w{�fՊ�s��k�5W"��X��洗-�K��P�v���{�Zt�I����z縦Vc%�W������>�z̏�R6�V'��$ྚ���O9�IK�X�bw���9��
��O9��-q�.|��J�5��$e�"�hl�wN���"i6�C�N� ��~Q�Z{�8��S��\%��LܽB{혪{^
��S6w�
-�K��V\Jr���n�.�����3`E����'[��\�.E��
J�$�ܲ�zK� 4����� m�;2�\�uʘ�&S���������lQKK��;|cf�ѯl��g������/�����M�ʪ�:E�"��5��Š��_�������<���۹��Z�`�<D��|҄�-�u���}��
�9.�Uy�ZB��ه��(��[��3x�|�F��^�>/�y"ϳ�Z>���'��7q���'�A�Q5��beV��YƯx	H�r2'���~����l�F4��R���������\�?s�D�N��$e��[�(UQ�� ���ݞW��p�5E��'7�x�D�"���Q]A��jN?�}\ۻ�ۨX $����*D�\J���Y<LI�[�>悝�K��V��b�=Ug����L�n�4�]�>���u�zj핫�^=s�6�Yv��M:G�!
�U:��-��J_�.NJ?�wr�JxvQI
-"Ч�`|�W#�o��2�С�a�cϝz�S9���X(�s��є3��֣�~���	��푙���r��&-�mQ�r
-&�����fԋ�R�����/�\|E�a��������)EԫY��۝s���Uĵ�*���}�p'8���*u�.�gvƽ3��yiw�ɖ�������4�v�/�((Ѭ�g�����泠3�Bݿ���"��a�:E��6���>���s��O��B�:=.%	�Cʿ�tY�(���e���e�&���35n:�wSk��m�<�"x��ɕ
-E?��y�x�` j$d�}V]`
[�?�z�_�.��C���v�x��k7�V��6u��U��erI����q��ݔ�9�?�=��ό�-�{m�4<¡������q*q��:���/S+��{�}P~T$k�#w�+k��Ū�W6����LT�~�n�=������͎�X�.
�����͇�UY��0��ՂU�Q�n��7]�f%#n]Ye/������SU�t��7
M��{��ݞi�z��')�� n���1*&�R��R�_H�߽�'�8�Q���Eg���#b��Lz�k�#&�6��MvB?�@#���˄![>=�wo��o��&�4��)�����1�L6��햘nj}���	��c�2�[<�/���8�͵���F�5�4��Q{�z��_ז��K��Z�E�4����-���٥�W��N�L7�>'�,��|���3��ٖQSF9N!�b�|XH.�f0
-��4Q��D�S�~+�y١���_0��EOmU%�H�Ds���9��Ÿ=:�(�4k��O
8���	���ҫ�k؟o/=��O��+�H�-�;��!�gV����_Pl�Ԡ
q��cGk[f/Gw�W�~�?�H��2{,�6v]�jK��(�kRf��e����ݛ���BX
-��ʓ�_c�gaJ�0˛J2lb��O���>�^>@K:[�I�0,�)q�!��1?��::�����xs��ICA��� 3&��p$Y@�L����K���T���	��~p���rMzگ%�6������ce~��*Jžu�Y[�FvW|�/a�ai����Y�����uK��[��g[�9_��0�}�M�m���-���<\��K����1�m�k�Fᦺ�1�{�f�}�j،��e��q(���$�*��.�w�
[,�/;�t��r�.N콠�پ��
E��[~;anu+y��㩉kD����Q�xK~椽�걾L_��~b̧π(���%"���mֺm�R�s�,�cfz��1�~�����u����7�z�u�ًl�s��`��>�o'�zo����M��k4���҆�+�Sؕ�%��6bF��?a%+��5�B���ht72Z��y�7's	+jsWEPY)�<]�pzl�W%�Mj$�'Sfi�Od�W1�K���}��C	���݇�AL3�	����5����,�o����Fץ���#�A���_��*����<l+�N
��tV�@ı�mnA΃''��[�����5k9�
-�9���R}�wݎ�q}9�sh��@ͬ������ܷ�v�/����7K���\/$D?$	�֩�NWy�pw��������D���]�~<
&��\��'�vAd&4�2��9x��M��C�pX�˅�
-�%�mK�
-���8m�����x1h���DfTF�������Cl��+��#~R	$W1�\5�!��*n&�o��ç�)���+���f����s(�aW+�iw�cf;��=���v�Է��u/��Mm.��4%2��m뷨<6�D��y�g,�q��-7��E��+���X����Y�٘�b6�t#�	�O��KS����4���D4U��L����#z�V��Y�1�
���WZE�E.��_G��=��l��U��?�]�h^��N>ъ�V~$F�b��fQD}J	��	��������¥_���K"!q]K�қ�ݕ�<F�� }��`
�K�!������/�f��I
#3
4��:x�<��92&�t�9�Lކ�r��] m}M��ke�d�H�����;�Mk��]�e6{4�O�2;�&�&�N:��`����X^����!��ؠa�f������ʚ+�\�lG�k_@�^wAir�!�~��{�Ĝ�w��u����{��U����s_bt�d%�}'7A�u���q`1Y��5���䒘�1ʷ,3x�5<i[-��m��P1dm�H�V��f�+i�i�sQ5�CŁո����9	��[m��G��o÷�@�ƥ�&�<4��Zo��=%s`�
��[��q�c ����Cy>���A�Q=C
G�ͩ��&:�)|�+)eeG쭱�GGxp�"�����
�ic����YF�}��Y���#WK����_���i(�-����������k�������1"���-�51�kJp�to_b�;xO����1�^߇��dd�(w�r�����8�;�z���Y�o�4%�?��k���3��)KS�����,�a���B)7rW�c���[U��8�
-��N�?�$��L�v�Z�ޚ2[3��Z�Q�i�q2a#�k̔��S�w����L�g]�|�=����Gd��9�B�8TN.R���}���߈�1�����A8:��z�ձFA�q|�I@���X����s:;�B��f�
-AQ�lj8	�)��a���yᛶ��8�@��ܼo�XN��VU���`�����7^��r��1vx��|e�@��ՇI!Ԫ�C�)
V���3�kZ��D�BcnҮ3���ׯ݈�S�~\�����|,g_1�����8�^DH(}�d�)�Գ���[�3*�ڀ���J|3Lm��x�<ʪY/��
-�F�����ȅ��5*�.���5�w�Z~�&s`��p�I��Bl\"����]�X�\-���B{�2I��+�.�<u︊�@�NK�(��p�f)�C�PW+\�y0^���ꥩ�L��:sK��ʽ��~��"ã�T-������=-�Z�������^��W�S�H�� x�1���tq�ݝ��P���n�Q�i��n�ʶVX��11q��.���օx�{�*YM��æ�bl��w�-QOk���_�c7�GK��T���n��>�M�S��ҟ�|�{٣>׾
-�,��N��B�h��M��
-{�ԱP���$^�N��2�	���
;����7��)�����,�!�S�j�f�����ae��q�0�`$�L��fX�cW~�v�\j��D�n�g�n����
-������rE�����C�o4��`�h��Q��#�S2I�쯈�����g��?
-��T��K��sr&�gы[9�ҽ�X.Wދ5���/_�Ή��Wj!Y��@��n�oz�"K�ɍh�fċ����
���[K�[�����#V�FKi�s#��g\Dޓ����=b;�ш�by�w� TS�E;r��?W)�z���L#Wt�=�}r]�L;���t�F��\�8��
����#.:$����Vb�"�Z��_���?��`8��A:Z����`�~endstream
+jg����h�
�
�����O�����	���4�O�?9�0h(�V�(|S���mC	�^-�-��qv�G���3 ��;�}C��D��
�-��sS��?SY�?'�@�����y�w��]��v���������p��������n^4@�����r�ap����DS�_����fJ�)���r���07(��
�l��73��7A@�(8
����
�@1��Ō�a���C���" g~#�ނ����z�x�����2�Qc��tC���EB�i��PVF�
<��"~!���&$����7��
�e�ZcP07������Z����,˿��!�H��=
a�������w�B�(��ߴ��ϒC�nP0��$,萘��)�}�5�������[i�>˷���$U��4H�jP���}b��rU�g����ْ��d�b�n˺;��Q�w�_�*�4i�4�so\g�\\����
C#��<���"(���ܾl.Y�TN��x��VDS7�WaQ�eoms�~�y���������v�*=oz4!��.)G��tzs�B�W69��Β���6.�����E��ae
x�s�Z�����<���;�C���'/ѐ��Y����I�V�~�R��j����]����	�;��(�\.M����<U�+�p%�c���@�o���p����J	c4�%�m\D�87c�O�W��f��z��]�m��|@E�T�
+��{c*>o�d?�s��
c�x�6���YX����%gr��GLw�W�pV�/:�I��|C
���}(X)Q�gf�kbO��+r��՛̋m_%-��#3
�7��G7���b��62L���@����̱���:

�8�2ԷI�f���VN��"4��	L?ժ�*Ns�a �������GP��<�����D�b��=5�y�y�GD
v����'���>J��la�d�/������<Z �E�Ym�Gc��$��}�]v���,�[�3h��o��ߜ�j0��G�IѺE�Q��ª�=S��j
+a?�"�=;������Y1��a�\'���E2�_�rBebP��y<�55J+qD*ᄑC-�n���]�y,%�
ԧ����������$��=+�:��<L�,Jd�zo}�7���ō	z���/�jI�}�|�4����lfc{0Y[F�y�D�`;	ٸ.���R�ϰH
+>��:�B���r������䣠s��i��r��dx�a�rCV���
]�� Iܕ�١�P5P%>���E�/�?g�����h����l5�xާ�%�
+Rrd
���aAf�|��G�A;�R:?+�C�݂��.�v���� ���ܯF���p-m�P������$Е�h��~)���cE�C�' � �$
���]�Z���)͌j(H�;KDldv`��͠����H
SJ���c�uTf�L�)>�9{r�`�'-M�0��7B����P��*d�g�9��O���9�)*��pĹ��a���(�����_O��\"U#;�ҿN3vl���|T)D<���c=�-g��2�e3��c�D>������:at���D�t�"]�H��h)�G���)�V��ږ�N�9���E�ĈjiTyf^�9����e���F��"�T ���ᐭ�T��]��y��p6[qy�3����q�4�����֥���9J{`z��dX}��A-`
-��4��Pff��q[���j5{1���v������)G�H:�3s+�o�S,_	g��iv��N�8ߑղ���`S���.��L�5&��������oga���`��~B��0?r偞ӽ��&ε's,�rf4s'�c`��l��)�¯���D�ޤ��D�7L�eO����WtG���DC���N�`y
+|�
+8T��>�A�*�^��3�fhC���9����d���\�<�U��e�e��*4���Jj�/֭Yvw�r����"�/1^xx6"�Q�J�T9o�,�.���sɩ��I�xH\5�•���Ux�o^TN���#VH{���x���AԎo�r<l�����BⅧj�q����.��#�����ʧ�]e����'�Mi�VB @�dΊ�
hS�8fW\Yt0\c�tӹ�1���=�f};���DO�)�.�@!���vfU
���<{���A�푮Η۾��17F��8����,AS�p�`�6�5Z_������GyRpix���#����_zg��5,��/Jۍ	7����<�;��5�mB�&������Q�ލ������@(�{�$�E��a�Uu�=�D�!'�*o�.܇3�m�#��Y' E5+*f7�c�v�E��a��K��agұS��j�D��nKQ��=y�z�rt栦־<�pƁ)&� ^�i��^yG�<�H�7K]�.�~OoNd���E���ݭu�)�M�Ɖ�ͪz3*��W#4e۳��_�Ih�ؑ���PD��rR`�Zi����{R�k쭢�u�
�t2��"Ml�;J������O�?�ۤC55��pƥ�(�)A(��p��!�>���Qd��ס��߈�b�`�M���K`�5{d�H�d���/�ă�Bk
+���౗�\��
��״m�,zi��=[mI�jk)<�4��wo�1�q�t�-�4�E���C.�,^=�ڤ�H\S"M�Z]�y�'��o�K�=Z�_1{��x��JQN�_W�{I��ٶG�lrJ���d��t�Õ]}<��QK �fS�7t�>�;u�]�bDҝ�N��T'��2}��m��Ӵ߾�Q%�pUN�`��xx$�Kޔ���T�ě����:�㽞�1P��״P����ާ��n��g�ɏV�3gj�"A`��[8ԑZT���.���"ˋ����&�q�.a�_�Zx��c�Nu���g���вHn�f��i��ë���~)���8��QV�@���c1q��&������ንM���i���Y��������D��#�^3�����U����\�3�wv���U+�K��O�=�\���b-��v��^�,�B��}��I�kѹ�&I�W0��Z��t^�FG�������1?�>H�[]������j�?<�?q��'e,�cE��������7��?�@��ĹW���v+��,��M�̣�]^�9�f���ٸs�:e��'C�Ej�y��;N}6s��2�1q�
+��c��y5`j8N��q#(t.�[q)�M��
����,J΀5J�ןl��r!��.6(!�r˦�-�����n�_��}��D�tr]�)cr�L��G3��6~�
D--�N����aG�����^�˻��G�sn.p7mB(�����P����N�
++���s����J�����n�v�k}�%����I2��׉���#|�8��Vu�-�k	�3gzn���oo�~��U�M^{��L|�<��k��3�����ū_��IG�H狕Y�.�g��% 	�ɜ��^��J�$��=TH�4�He^"�[`
+��S�7�p%�Ph����9�ꓔ=zn�TE�ւpr�w{^a��}��f���L��	�s��;x�Fu�f�9e��qm�o�b��̺�{���r)��Vf�0%�n��v�.�"[e��[�a�T�q&bn2
�
Sd��w)��*��ꩵW�^ jx�̭�Pf���7��s�T0V�����*}�g�|+���Y�m|�+��E%)�@�b��}_�@.�q��,C�v��=w��N�SXD�b�Lρ�GS��oRX�v���c/$�Gf^�k��
+���d�Eu�)�dK�bƛQ/.K
������s��fL�
+O�[>`��Q�fiXWow��b�W��X���!Ý�|���m����������qXZ$[�+��ڗҰۥ����D�N�}f�V��ς�P�Su�־[j�Hχ�Q��t\~�L�wB�M�R0<Qv�
+	����$\)��e٣8n�Y?���t���Ը���M��z;��̊\t�=:'W�)��z��y���� �u��YuY�ul���k��|1��ᓶ�e��ï�(Z�_j��	�Wq[��%q���'Ǚ�?tS��������N?3RܶX0�)����~қ�SƩ������k�L�d���A�Q��a���E^��;\ٌf'3Q������H�wB"7;b��4|/Ȟ�7�We���`��WV��F���O�t-蚕�t�ueq��8c"�;�OU͋ҥ��4�~�]{xw{��F�
r��(���ݪbcĨ���K��J�,d|!�}�
+�,l�G���E�ʏ�Eblȃ2�5����|\��6Y�	�\$��J"�/�l���ܽ�K�Is�L�'Ҡ��8���T3�*�[b������'�f��g�n��(֧��7�JBu���x/SD�!륎~][RK�/��j�+��Dr�h�Gg��_�K;�j0��z��ij�����x�.f[FM�8���-�a!����(|��@D]�f�N���8��e�6F�+~��~��G=�U��#
��n����_�z�訣�����?�<
+��'�:N`J��Z�a��8�\k?Q�^��"A��<�0��,P�Ye�Kn~A�=S����}l�ul���	_�����"EzT��p��um��-5���I�
4��swo��
+ai(�3(O�~��K��)��,of(ɰ!��R@�?��c��z�-�l�'�°���I�D�����o��H�.�{�͵�&}��[�����Ñd
�3%�k�^,��S)��'8�����5�i���d2,n��s��q�5��(	{�!gme�]񱾄]�/8���+fGg��g��-�Vnm�m��|�h���6��1�K����p�/m,��r��<��a����,��k���y�a3���GǡL:��t������8l�$��T���ˉ�8����f�N>�g3\l�턹Mԭ�}z��&��k��Dy�-��������2m|�����1�>��n��X��mX�aJY�}�L���z���z�b:׽��ߔ���
f/��e����T�g��0�)nb�6y���v`SpJr��NQ`WΗ�RڈQl��|���P��֐��V ����h�O�ߜ�%���]Ae�\�t�f��E^���6��@�L��E>�_��.	��S�Yo%�NOw21�'4J:���p��O�g���v"�]��޿�@~I�5�Z��^�f�򰭄;5�3�YQdž��9���~n���~�r׬�<*��l�7K���u;r����Ρ
�5�r^f����ֻs��ڹO���V�,iN6r����$tsX�*;]�]�݁���㦇c�}ڪve��4���s�r�0����@�Ԣ�D�e��s4�/L�)�aI/F,�(x��s�9,*�O7�1��
+Go����J�E�QEAN��o��_�u�x3H3��I%�\�4r���~�����٫���4��H~����.ΡP�]�4G���9��l��TO�{��R�ޫ�U��7����ҔȰ"���ߢ�|ؼS�;�Q������ܨ��]�����b���g�^dc�����ҍ`&4>�/M��F���Ċ��|T
�3����[�*g����7�f_iu�`�~��|²�VUZ�_� w��y��;:�D+�[���Y��E�a(���b$��&P��[w�c���~�
+V.�L��u-�bHovW���W������p.���Z㫞'���q��&<���������Ș���h�x3y�{ȭx>ty���5
 (ή�m��#Ux�G���6I���w�����x?��쬚���;q�$z�>����wcyŎ�r��+gd`��m��vߣR+k�Hsm���}
A{}��ɩ�\��&��s��Y��	t@�bWd�Ij�STq욾��}��}�����)���Ɓ�ld�z�����KbJ�(߲��)��m��
+ж�>BŐ��#5Z%�o��]���E�`�V�vҗ�$�o��vej�
�6e����4���jk�-0��́���n�_�͎���2;���b�?5F�5�7��ʻ�輧�u���U������E���0~��N6����?�d���FdeG��\-]?^j~�Ӗ�����s�b0࿃�&ow����RԶ�BcĈD^�8���K�)��ҽ}����=�;,'�ǔ{}����!��E�I�g���d�<�I��f���Ҕ|�0����zj�,v�,M����w�Ӳ�%.����]M܎�;w�nU���+0��:1�d��"21ۅk!zk�l�DD�k�Fѧ��Ʉ���1S��Oq��ˢ2e�u-��4�"�����4a�{�xP9�H�R���#�|#��,v2S����V�����&
m#`b�J���� ���Q+EI���$8�<ꇡ���o����e�r�c8�&[U�>T���f��x���=�������-��ͫW&�P�^Y�4X�z��
h�j�G
+��I���/.^�v#�N�q�J�K��Y��}�������{!�����4R�N�_Bo	TΨ<k�K*��0��4��(�f�HZ+��Ύʾ#Ζר ��no�TX0�-k�A�́�3��'M��q�p���v
[`�s�������$�֮pS�LX��Խ�*��:-ɢP��Ñ���EC]�pe��xa������3���-Q:X*�;����bS�����jOh��@\j-��>~��{Y�_MNA"yZ��Żƈ��!�}vwRC%fB@��G����Qc(�Za}6���1޻���[���U�d5�{�
+v���
+�ͶD=�-z��ݸY,��S-��Ӻ���@6WptL�ZJ:�]�e�b�\�*(R��;1�3���W4�
+*��R�B��w�x�:�&ˬ3$��K6����/�����RZ��H��N)�-��JZ
+ ��*ƍ���9�8c�2�a]�]���Ur�a����m�9��&*�F�/b3��fr*ݾ9�0��%�azcD�z��N�$�粿"�G'[DL�Uf�(p^R�
+/Q��ə�E/n��J�6c�L\y/Ԙ0��|�:'�_��dAe��UO�鹊,�&7��/~���.Co-�Gn��C�JR�X)-�yύ,��9pyO:�f��M�PF#���ߡ�PMY�ȁRB�\����o�3�\�)�p��ue2A�0.�>��sE>r���N7�h�kv����Cd؛RZ��X�j�[��#���O��Pk�h�zN��d�dendstream
 endobj
 982 0 obj <<
 /Type /Font
@@ -5477,14 +5461,14 @@ endobj
 /FirstChar 36
 /LastChar 121
 /Widths 1351 0 R
-/BaseFont /TSWFRI+NimbusSanL-Bold
+/BaseFont /DOHFNV+NimbusSanL-Bold
 /FontDescriptor 980 0 R
 >> endobj
 980 0 obj <<
 /Ascent 722
 /CapHeight 722
 /Descent -217
-/FontName /TSWFRI+NimbusSanL-Bold
+/FontName /DOHFNV+NimbusSanL-Bold
 /ItalicAngle 0
 /StemV 141
 /XHeight 532
@@ -5508,7 +5492,7 @@ x
 ��B����!�	�Aܝ`	�A
�$M�������W�����8{Ϲ�\{ͽΨ��(v��<������J
�`���H=���.��p������a('����3����(�Q����;@�
B@)�����������)
sv�
��((�	�rO)�ڸ;C]Pz�p�
 х"]�6P���~e�����٣\�Fܼ�|�F�$%%
���d�P$���q?��:���d��P��@�����ق� 0ԟr
\�(\JPn��cH[
(J��~�J.�g���x<S�!�6�Ey��7GWO���ma.��J���
\`n�P5��
 ������AQQ�0P(��
�^6��R�{á�B`����
-؂��P�-����{@
(�;���'��OH�٠�P��m���=���\�B��f@
 P�s�kdq��W'��k���Acm=�*��k�W����$����_XB��S�%E�]�_^�Ӈ�P�_��[R��� ��r�}�gIP�7
\�17��k��`6P׿[�(
+؂��P�-����{@
(�;���'��OH�٠�P��m���=���\�B��f@
 P�s�kdq��W'��k���A�������k�W����$����_XB��S�%E�]�_^�Ӈ�P�_��[R��� ��r�}�gIP�7
\�17��k��`6P׿[�(
 �������R�����9�ݝ��r��v��@4q#�#�s��^�{�����QC��`6�.vN��	�T�yA! �����O�!}�P�+��K��
 ��ӷ��8�@��������@��R���s�������C۸#����A���sn�_ ���[�u��sx�vU+O�ɿ=��W���;�^���F��c�H��DZ�"h�^��S="�^)N��QR�]�!y8�j4݁@����1��	��.)�&�ͷg��G,&��>��E�R2^���i?�g�(���ޝ喤�	9�Vu
 Бz�y�C������4uͩn��tpI^�N�bf�O�P4�s�
@@ -5540,7 +5524,7 @@ QL
 +o�=(n��n�꽎��,�Y���|�{|�c�pQ'c7�Ҭ��zZ��tg����E�v��!��C�K�;��>]�
 ���zp�sB�����Ѭ�&����*=�Ʀ(�I�X�Rw����*�����V�Jl�fF}�ˍ.G$=�"���_dm-n��e�ul}h���E��G|d#±���Ռ�������f��W4��Е(Y�q}Gk�w�u^�I_�ry*p��t
7AN	gN����7��
 _���։��:�0h"�Qo�����'�,E@����jĀ"p.a����{��g���(g��pX���o
-�&+����[%B�YZ�J�4���A�&�����3�/��J�ŭL׈�8��r?�.�B�u����u��뷧�@u�Q����5�tΥ������"K�"�az���$&��%����#�y����x����+xS��"���L=�#�x�{��.^7���|��������Na�9��U��<�F'�ZB��K�-��BE�~l�Q�TJ�3��DYr<TϜy5Yq8��8gme�
�Ц�q�sR������7���Udn�� s ���'���kQ�������#Zy�gU?���y;��W�<���v+�3�W%F���T�Y߅�Ȭ
��ag/��q�0��r��(I	�R���~��i�9���ў�}~\��o�q������������|l�����B��v�*�p/sL�(��r7���	�n1~;<���C�%�o3�<��
‰Ki�7`�@�0��yTU�8���7��o�����_�Z�E?'i�D~[���`2Z�6y��ws�~���ᛎ�w�<����n1����EIɐGr��02G�ПH��֏	�R�m)Hz]���w����g�|��r��n�x��Qk��*%6�^CR���ՠT�I�Ǎ�Z���zG��O���1J%���/3��7z�Z�H��6��VTv��a�n ��dE�CJŐkR����o�&5�k٧�H�fӶF4��������q��(Wg0��
E�\����3!Ӧendstream
+�&+����[%B�YZ�J�4���A�&�����3�/��J�ŭL׈�8��r?�.�B�u����u��뷧�@u�Q����5�tΥ������"K�"�az���$&��%����#�y����x����+xS��"���L=�#�x�{��.^7���|��������Na�9��U��<�F'�ZB��K�-��BE�~l�Q�TJ�3��DYr<TϜy5Yq8��8gme�
�Ц�q�sR������7���Udn�� s ���'���kQ�������#Zy�gU?���y;��W�<���v+�3�W%F���T�Y߅�Ȭ
��ag/��q�0��r��(I	�R���~��i�9���ў�}~\��o�q������������|l�����B��v�*�p/sL�(��r7���	�n1~;<���C�%�o3�<��
‰Ki�7`�@�0��yTU�8���7��o�����_�Z�E?'i�D~[���`2Z�6y��ws�~���ᛎ�w�<����n1����EIɐGr��02G�ПH��֏	�R�m)Hz]���w����g�|��r��n�x��Qk��*%6�^CR���ՠT�I�Ǎ�Z���zG��O���1J%���/3��7z�Z�H��6��VTv��a�n ��dE�CJŐkR����o�&5�k٧�H�fӶF4��������q��(Wg0��
E�\������ӝendstream
 endobj
 802 0 obj <<
 /Type /Font
@@ -5549,14 +5533,14 @@ endobj
 /FirstChar 2
 /LastChar 151
 /Widths 1352 0 R
-/BaseFont /XOQSPH+NimbusSanL-Regu
+/BaseFont /PNUUAQ+NimbusSanL-Regu
 /FontDescriptor 800 0 R
 >> endobj
 800 0 obj <<
 /Ascent 712
 /CapHeight 712
 /Descent -213
-/FontName /XOQSPH+NimbusSanL-Regu
+/FontName /PNUUAQ+NimbusSanL-Regu
 /ItalicAngle 0
 /StemV 85
 /XHeight 523
@@ -5576,33 +5560,30 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-x��WgP�붦�H�ޅ�
��A�W
���$$���^�
)*�Ez�
-"]�t�H�"����3��_��_wnf����Y�Y�Yߚ	����aQG�1"�²]���Z
(������`P� ��RAA�(�
-�@d
f0@��Dddd��*�
-���
�114������/��ן�
u������c��kG#�q��0@EO��������	@���0����!��!�{
-��!�`��ЂX.%4@#! (�
�	� Aw
H��Fc�
P4�
�c�=� P8������;!$
-��p�bX2}���HU_U��<1�@̯�h( 챖`��WI�1,
��p4����e
��h$腍�%C����pCC�ep��8Q`���`�u�:
�T=��y��F���GP�$��a���pb�_â�GD����!���!��
��kfx�I�8����"0ؐ�;�;��s"�$����������K����Vw��t�.�
�c��[
x��g�����]�0���wC3���"�;��
bۡw�J" "*(��5�������#��v���	A��pV��
�:	�
3v�����/�����;V�ߙi�������R;c/$��a�t�~�(+#<
>�"
Q)i���0@ZJ��_D�M#��Y�AA=
�‚��"��߿N��F�!��f����c���_0�
�ª���������C ���'H.�)=3SE���Nղ�]�7YXk�2?����(Sj{Q*X7,{��kb������v:O[*d'���6oG>�<w��j��u!YƶY���LJ�,$�MW��Z\\�5�$���{�p�=?���I��V󔶙������6w���1O�@_oO�>A�f��O���ܯ�qG�>gV�0)���TP�$�JR��!{�.��6+n�{D9Z�
-�HM�Z�&T��Ի�گ�|�ùH
���U	�w�^~��w��TS��~l�|m��s^�T��
2^2��';�,��i����8�c��;;���t)t%��2Iv9ޜ|qANzLb���ʦ9i�,v�*�:Ԝ��fՁ@�8s�f��f�����O9ݢ�ԟ#A�W����%�J�'WN_*�T�ˮ̛?�ΞU�7V�)�r�H��g��3_��ߪ�<nv*�g4��H�I*r����V!�4�|8�����Y���],����#� [���uZe{�0�8Uݏ��%#,��Z�߭8d��II�5�����h{&H�����ꄋ�e��4�N|l������19!��S��)�C����{f�k`��y�-D��F���Z�!��ʆ�q[�Q�'66�����Z*t,"N���)t���s"�R�:���g�䡴G�*h�� �t*$�3n�$ʘ�u�&0��Js_h1�z����+��:�~����誧%=�K�m��K�ub��͊1���S4R�m
��\��m{������ge��ɼ��7�7����K3��'y�����-1؇u��.{֫��z�$QN<����dhkT��~ew�&E>I�ݬ�R�tǡr������}/ҵ�@�1ϹQˇ��Lb��R��A�nȚ�55�M� ��=�IYy��g|����/�F8��JmM�w�T�=S����Xأ���Ջ�C2X.��䷆܌��B�Bl���ʛ�z�O��<_�z]�i~�:�/9|U����1���a!�b.�>$����<xw��Y��u���B���gj.�T�}V
-�s��'���e
-��j�T��+��7"��O	m�lA�2*�Z� 4�,���^>��fi�
i����6����\��@����e��[�V�Y�
-�~s��Ω��䘤�;�K��fb�>��x��|���5�0�9�����������
-y%�\֯�5���e՛�E��%X؞��tᐧY�Q�uV���2�4e����hJia��6[G���;��0}H��3d6�r9�3:`�H �����h~���%`�ӵa�8"N�Kw��E��w�|�2{�����Jڜ�9�ښ��|J9��mj�cpM�!�׷��hr'ntk>a;:�|�K��*M/x���[#�<g{�ʓ���:*��� �%)�Z)� TlƣV�J�dk�BE��Q#}YOkG#��]�ybz2)�8N&��$�����e���u�X�V�"��x.��W���f_�h�{M[LN�ӫ�%�0�J�j7Ӽ^K�J��s��|��Z�i1U��|	�Tѧ�'
y���bX�XE��s�4QaL��8��何/+�@\bZ�RQ������,��+���K�P`E�,��]״�8Б�l {����9�;�KJEkV�$���5s��ȹeY���Z�/��[��ގ�Q��7Nj!�i����D[�|�o���y���`前x���}.M�Zs�Vgc��>�v�&ΏIw��	u�!e
�I\)t�Ss<u_"�|n�q�Vn4��X7�7�%�M|����ќ�% l�^0��E�L�I�G��x�W���v�)]�T���\���}�(i�2[�|,���wE5�������zƄA���@����ٹ/$>�y��V�u��u���m��œ�s2r�y���7�
�˳$t�F�mB�p钄���a?����"\d?)���K㈵9)n<�z�U���^�/0m�nՙ#(� ��0���W�w��v4���4��iP����ap
-#�xr�>C�]�K�pP݅qNIOu���W�C��2tX���!+�5��Iv�|e�7�C����}h�W����"]xN2R̮%d�m��ղU}O.
���Q���	����ws ��3��	s�}�f_,�[�<7�W�(�y�F�ٽJ�)����ţ�%|�TA��"��c�
�c�Z�R<���^N畋x����{gc�G�$��(���S�~�GB����
w8�a�e��%m���3�-b?Q�㩗2��W��xos
L��]�,[Mbh��@F&�1�=�g����r��49|�1����+��-�`�|��qfH�+�6��H��M���5!��w|zz_��L}'�D��L�e�Al2���E��4��[����>�}+[�K7�����>��(��`cWߔz�� �d^���B�y���y�Ȕ?U����G�'��D0�|��Q�~���^��qVA��A	�
�c��3&"��
.R[q��i���c���ѭ?�}x�	�����=�].L�WV�� �fn!;&�_����~����J��SWD�E��R|�;&z7Z^�}���S>A�YW��9/��
-����
-.h����+�GU�M�d�$Y������@���H���x�|�y����
GV3O��}>;l�^Tu�����?��U����!�C�ިo�M�]_D���	��\-q�X�j�4ʪ[���J�zx�d}����'�u �mQh.�G$Z��I�
-ٮ+}����`�KT�Qh�����QDn�@�Uv��
�j
�@T|��z�_�����j.jY$]�~�}vV���x_U����
x��5�T�{歚3(���d��o�3tA����ٞ�r�w̶t��/u-��Ό���׾>#]
����v��%���Q���vu
'��
-�<�V��4���a�$4.x8��
BSP��x������JQ����7�3�����
)���O{F^j�[Pߜud�c�ŵu��F	?6E6k}�͏S���f�)�hhZ
��ίF�I�Ł��#a,�k�1�t�*��qʒBp%v2f�N�=��hS ����W�	Gd���.c��Z*H�BC��	N\�cq
-�&�e}S�
-�Y/;����8��M�r�,Nys<�d{�$ƈ
7�g�0�����\���
�j+�Tp�&{[��\��9��"��`��r�v�_���7���툗���x�a�����b]�.�x��Ez\]S�$�oZzq
-��_��mgU���c\��Nɷ�%bsG�]�!��e1JE"����ˡȍBkn�T|�f������<\ʋ���.�x#ϛqsƆ��I)_�T�;ʯ�r��ؼ|9�R��&�r��YG�
-.lo&64����ǟ�Yd�>����ʐ82���r37t�O��S�^K{=����;#r耦Ӓ����7��^4Q�
)�LXr�7*v��M�3z/6_|�O��\�yY
�և$
-AlJ�&�$)�=W��…��U}I�J��^U�'���=&�7���B?ޣ,|
~�(q�٠��%_����x��0��%�����B��/K�����ODߑ@�w�"I�丝�/-Ā��ꨝ�MgU���0;4=vqX����p���;{���s~�ǹ[�}r��[�5���s�.ѓ�Đ���.S-��OM�)�*�o.����)��G���cC.�p�p]�|<��{Or��te�qe�
q��0yf�,��~J��)<
�+8t���sb�6�Xֈ<�F�4S��d�[{��b��7�il;��;I��_�U�JK�oV�X�~P���?)�"#��W���
8=#��s�༧�誂�96�#&6f���n�?�t�����S���un�`^������_-Њcu��j�i��\fl#��z�4y��9�,om�hd�,|A�ݹ�
o탢�gv%���0RF������Ӿp�V�B�V@�
�"k��b��U�4�N��
�n��q�E^���e�3�]��Z���wRfD퟿t�����_D�k!9.�*z�m���{D���xz��v�B����)�R����o�۩��aj�F��K%-��Fa��q%Y#"������@�e��
-�qf�b��G?vCo�[
ᡃ����������垴��;�WC#$#}ר�5F��eJ�:�K^�:�)F{�N�m���⿔M5�9Rq9�:)1H6���fѫ5А>�ie f&h[
-�+��� |�H5O�v��q���Ò��HG�`��!o�?��1[E�;� Ѣ���^��q�j��8e_P�DF��>M��X�e��qJ@�K]�~-��w��^�$C�}j�kz�	t�c?�?�Q54[f��+�N�؋�XZ�\����%5/R�=�KWW��>�iͳ6њ:�1�
�Q������V��j7�'��
���[�YثN�PfV-m����Ǽ��
t�eL��ԵX�K�
��['Z��w=�ɿn�@Fԧy����
�Y�\����0R�(��p��Y�:���JPƐ���R���v7*��׍�=@��t���瘚?��:K���j	맛w�(��~��JV>���8J,bx�.W�N�)ɵ��N��%0�B��E���ɺ����z�0����Ɛg������5��(}�b^:����-Q�"λ�~�����-B����.���A�1��e���ײ�����Q���q���-c@/����l�f>9�n���r�&�B�U>KN��G?W���"D�Q�V��ϩ���u�i�bZ���nϒ_��.A�y{���L�
��K*��.)�R�v�]3��t���m^��s�r�%�>�A�*����Rp��}���]�-_^�%��G���7���#˱�6T��5���
s���9//��'�G�D���I{h�QY
-(ۼ�6�gb�N��e�V�w�.e��6*6Z�Ѵ�'r�p��~6}�X�G�J	�}5e�Z9��� �3&58��	VGh�}�uj��G�z�z�-�1�J�R��(j�,'T8�Bfs�s��e �Hdo�/D0�|S���R�W�<�7n6FH��\ی/
�ړj��'�k�Z�>_��kL/��nZH�]i�ڠ�s�@����3���v�u��g0�����q�̡����\�������b����]7~1��#W�ʺ�L��;_���%t.��
-��rS�	mD�r�ώp�Ü@xk![�`
����6�=z��=��9��-��]=�u�X$�v�I��0�F|�~�A\�%x�E�K��(}YR�����nb}�*�D���N�NJ�pcK@���6�2��6���Q��G��#�K���v�R}��b�:ک"dFॣ��v*��Z
-���|�Kbu�{�n��u…0��>������S���֫-{��rQ�_�3�.�MW�bk�B�v��:e���4�T,���,a��"ڞ�������yG��d	����#�i&J�lO�����rG?ގq6\5� M�*�Ϲ�ᧅ�⛷V�bd�X��4����-�l���䐚ND��<A�dR��;��	�C�m���{��*)�w�'���*\>x
�W|
-�4v_yF����R��@��6�4��'�m��w�����wX^ʩ�M<�����#��#r����@*׈�g�k�dU͘�xO����Y�O
F@V2޺7�t(:?��ŷj}�<��'����"�0�Kyq�W�d{�b��a�S���3�ec%s�Z�$��(�3��[�䚽��!��� �� \�(g��B:��endstream
+x��WgP�붦�t�w! E@z/�4
�^B ����{�ޑ��{Q���  ҥIW�4)��>���u��u�f&��}���U����ps�
+*����8FPTHD�u�uEk#��U0��-
+��$�ܪ(E�Հ���A@11����,	7@��DA�0����|w���e����z���p��
C �!p���h�0�
���=������1h@��sŖ<�� p4�`�@
` �UZ˥�
h$źA<@�/�	A9C�h�3�أ�p�
+�\�����!~'�D!��XK��@c� �
`����#O��+6��
;�%
r�U�oK�E1@(
�@<0�b�B`(	zbccɐ(��4\�P��_�
� �@A��4X�_���N�?UD"a�����������HDŰ1All{(�D�װh��Q�?����?17�w�n��>l@0��!v$�:6$���Ne�����
��#�G������F������ߩ��`:@g���d�-�<��3�_����?|��P������)�L������P��c%������������v���1A��pV��
�:���
3r�����/�����;V�ߙ�=~l�/�v�oK=�`�<���1�F��q�ţ���xJ�Ťe2"iQ��7��_gm �X������~�:=��:���CƎ�?.~� W
+���7[�����x@@$ӟ �`Ǵ�tLCN�;5��vQ��da���|�
+D�_Z��l��Ee�Pݰ��[ω-��/�W���a�m)��<V�[|�T�<M����V���ۦ�޻-\3�1Y]z�o`Upq��p�8�h�����[�?-�1��)(��]3euՋ�m�č�c�ޞ�}��/,ϟs˻]#��wy΢dn\����>0DEj��<�9�M�4�M�}VB?��j��
V��HC�Hi9�{��_���k�h�?�>�
���e�ϩ�:ý�������|~)P+"r>r��;�,��}����ⴎ
(���8�Wӥؕ�J�,��pc���ae��J>��U������3N�U���,=�����&���*�?�u�
+R~��]%�動`�+��^M8~�d`VC/��l��<˨�o��S��Z�>#n��c`�`�Y�eq�*.�TOo-��6�/�R�$���^!�8�ro8�����&yԺ�m����c�@چ�u:;�P�X5��j!%#��QZ�߭�g��IK�5����5�fQ�����>�fc�43	B��ۥ���cJ��)�T|��!܉Ju��=3��7H
+�<���}���I-ې�^ze�츍ר"�Sskk�O2ÍM-�������d���]�9QN5�Lm/������0U��f�r5�;��.�*�iݽ	L����R���65��5ܒ����ߠ�;��YIO�RS���b��Ưij�L.�����Զ����@���۞�~'1qv�CY����o+���M�-��Ў��I�}��g`O�f��p���ă�ji��9I��̲{��6����_�^�IVH�[u3�E�T=ݱ���fH��#wϓl��n�cn�⑇��l���f`�+�fk�Q�iS>P�s�{RNA�����y�˻�o��[�����Δ�����h�!e���t���6���a7"7�P�&�����&ƞ�S��ϗ�_Wl�ݴ
+��I
_ծ"�i��<�_Hǣ�˭N���
���vV�x�nmhm���������/U쟕���w���o��媚"T"�K)�I���CZ5[�L�ʄ1VD��}��
+�^ˇ��,M�!�7�<&�R��������u���b�y��9+���o�И9U3����z�82�L���ߚ���7�Fo�T���X�X|���a�����5�f���l�s�Hk��xs��v�C�T+W�tN*�UWf&,�;[]M�-���f��u
+��ƣ�)wCp�L�X/'zFCf"����S�b�)�_��qZkwm�6�H�E���#|���6��̑�2n�R�.��@����f���D�J^xj���\��E�$����7�<	ݚOُ-2tH�^��m>zk��joR}���]G�|�� #X�e%臈ϸ�jYJ�l
��*�8h�-�j�h��	6OLO&��&��&�ߥ����.c���]$T����:�s0����y�i��	dzv5�$+�]�����k�_�x����Rj5�çJј/!�j#z�d�o�`Y��B��(�w��ƪLIz�~���a��MHMT.
+�Sq��qz����rn�h^�x�뒚�:�
���:[8�~�s�A�j������eN�9�,+�TK��%Tu�����r}7�p��p1$�/��~p�x듏��ѫ��V�ZK4:0W����5�hu2����own���x{�_Q��R�10�ԅRG"%�}P��%����_�F㩪U��p�Y����|����9¦�3�����d9�TZ�̏{������k+�֟�78��%�5Bf���uS}��#g6�\��Q_O�Џx�@�R�@*;���y���j�Nf\�T-���
+�,�Y:'�`�Ǎ�x���<KR�y��:�
+�>Qΰ ��s��?�Y���|��x���F�ֳ�r
�%�Z�8A�i7����	���U��p��]6�a��5���]@ݧ����x%�����(]�D�.�rJz�#�<��6�U����ϗoY��}H���/s"���cX[��}@Q��Ӌt�[8IO6��]�a�W�^�=���G3*�+RJ���I|�8�mjX$I��'��g�ъcm�H@blE���Gly��+Ef�j��oPd�{7��2�0C����Uf��˦�R�t�S�γ��'�6������`�RIN�q����̽6Ə���gQ�npf�X���aK�daW�[�~���3Oz}�|���������i�����L#��"�z����존9�,ѹ���+xd��`������H�+�Խ6��H��M��A5�6L�}zz_�L}'�@��L�e�Al2���G֐�4��[��9�f�㾕+㥙�}^ۻ?��$��hm[הr��(�lV���B�q���y��D E����G���qV�0�|��Q�^���^��QVA��A	�5�ө3fVb��
n2	Y��i���cᙃ�-_�}x�1����<�]�]nL�gV���Fn!&�O����~��-�J��SWH�I��Z|�;&v'JA�}���S>A�YW��9/�.Q�c���EgF����n���*��B�V�,�Y�U�iLo�ngs�Լ��A�u�#˙g�aޟ�7�^/�9j��j����V���I��}o�7�&�6�?<JL��~����w��
J�fe�)��le�u=:\�:T�]̓�:���(6� �{q�$c�m֕?u~A0�)��$<�Q�|��0<�_0�2����j��z�9 2�M�~�o�����j0.'jY4M�~�mvV���x_M����
x��5�L�{�͚3Q(%���t��g�3t����
�ޞ�v�wȶ���/y-��ޔ���׮>=M��}�a(��%���a0���vu
��%
+�4r��?Ke7bC���%Qx\�pX)���;�"O����w�#;9���O��#o�R�b��@?�=y��Ϝ�Ƭ�#���-Wr�Hر	�Y�+_~����
o�pGC�
+�n�Th~5��KBL�
	c%[ˍ���T/���K��+հ3�>�xZ�!r�!%"s�`7x�`^D�a�q{7�RA��!8q���)4���m�IIp,tc��J�\_4	h˭3?���U���)�->ܠ����BQ���s��:(�P�����۲���,!��(S
Q��ԃ��T���oG|$��%��&�?���q�73!4*����&%��|�ҋSpv�b�؄�hl;���&���]7*�-OQ���b�����S)���GG_El<^sU��O1���#���R^�yv� ���3�L���i��d�^���p�KՄ����a��Dva���.�6�tVpas#� ���$�L;.�,�<�`.��d_V�䑾�t����#~����Z��f�f�R@4�,矌e�yH��E� ���*��5�d��`��ٴˠ�b����a
�'���m=H�0ĺ$�k"kҗҺ��sE�-\�oUїT�����ʟ���}�ˬ���qh�ǻT����]%�2T���J_;�m��A�7�6p��Sȝ�e�^�����ے�{�P$i��<�S��O��8��c�S�ɬj�SR��'���A�"�P��u=�c���v����8wʾO�r�~k��z�t��%vҘ\��e�E�@���%R���e��gWU���>x"�yl��
n�����#ʓv�inp���,�#���!p�j���b�Ej��O%{#�׿|����UN�!�ƀ.��{ꈰf�[�,rk�.^���&�M�D'il��k��Z��ͪ�ҏ�*����&�eeS��<^=����sM��t]U�;��a���L����'����r��<����j�<Y916V
+�Z�l�S��-=�v�ˌ��9��$�w7�����씅-�p8u>�}P\��ġ�ݹ�SF��C58UZ:���P>�T�ymçț>��0}�9;#}���kTr������2
‰��-�U�K�;iS���_:�N}A2/"޵��Z=��Kd����?"WL`:%�����.-s|F�ܯ%��S�v��V�z��:�RI��Q����~lIֈ��C�fn�D���tқ$3i����/����M���A��p��� �����r:�����9���ґ�k�a�O"	V�3e\����mz��q����Hrw�_ʄ�����:�\���
+&�U��˰���hɞw��2R���-聕SNX�_��'W;�R׸���IXud"�}�)��On��VQ�nj*J�(E�h���k��V;6N�X5�+̶�G0!^s����D�2Щ�R�֩_��ޝ�1����I�8������E�{�8���L�Y�ኳS�vb?V�V�+W��:�l(A͋���Ok�����vD"�7�x�&ZSf4���8��A^S�*�ڇ���8e��,���uV���7T�UK[k�a�{fѯ=kݱ���t����~���	�W��_�g���[5��i^���l`�#�#�v?��8��=�q�	�+ ��5�a�#����Ս
+h�q��Ph2�"e�=�H��Κ���Z���Ɲ#���%&R�O€��
�;��h����ǹ�c��)��g��,>��}1b�C�nD�C��J�uѩ��#H�R�� n��-�c-*�������|nF)\���J���?�zN��&'!���j�,7N�� ��h��2t���U�������Q���q���-#@/����6l�z>)�N���r��ƭ���T?KM�
+D=�o��E�.�9 �6.ğS3U�,�{^�nIb(�5Kq�G�Q��1��3�;+ ��[����J�߹{M���o�-t}<��������s���c�H�)��a"rt��|x��4ns%�����ҏ-�F�P����Df�o_s]^�3ZM��
+��'���q�Fm!�b���̎��'���Z�ޥ�t�crڰ�p�G�J��!�޽;c��*�(����b�"�rEA��g�kp��>�����5��3����	�P�r���c
+	��5�uVҔ]��pH�2����VK�B>���J["g���x��%��{�o�h��罶W �#Ӡ�O*�sm�|�W�1��R�i!9w��j�r������d��2��'��3`	�m��� 0d��)��������8���;����.z�u陀�w>ꡟK�i�+A�&b3��*�?;��s୅���
��(Z��������L�6(V��!?h��"x���N��ȥ��6��Sb,�K/�������|�@�w�#6��%����&p
+?V,�Yr&�����ε�Z���_>~B�]�w�3���Dk��N!/
�'�Sq��B��� L�+\���OD��	�@�W�,'V�K�Nq���[���=���EU~5�4��6Y͋9��|��-㘙G�i�Tp
�Y�nI�=�O����y��$IQ�{�2#\Zf*�l������r_F��qv\u�` m��Ϲ��g���7W����Y}	=5�)�:-
+��|6������Q���$2��۽��C�m���z����)�e&���l���x
�W����v_zD:���Q��D��6�7��'�n+��v��3�J�:,�?�R�&��C�QΑ|�=_z��S0�{D��5�V�f�j���ۄ�ڃg�# KY/�m������Z�>X���}��}�O�橲8�#]�=x1��(홟3LU3�dјN�R��^+E�=J��.���!�f'�o~H����

�0g ʉ����endstream
 endobj
 715 0 obj <<
 /Type /Font
@@ -5611,14 +5592,14 @@ endobj
 /FirstChar 46
 /LastChar 122
 /Widths 1353 0 R
-/BaseFont /KQTSTM+NimbusMonL-BoldObli
+/BaseFont /NXYYRQ+NimbusMonL-BoldObli
 /FontDescriptor 713 0 R
 >> endobj
 713 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /KQTSTM+NimbusMonL-BoldObli
+/FontName /NXYYRQ+NimbusMonL-BoldObli
 /ItalicAngle -12
 /StemV 103
 /XHeight 439
@@ -5639,7 +5620,7 @@ endobj
 >>
 stream
 x��weP���-�<��Npw��0���� �	���$�w���@\.�w�ާ����ݺS5S�ӫ{u�������P�`�t4�8:�����	�A��n.J��,�@k7s0�p���H:�\A�Rf�@
�� �pp����Qh��Og���+�^K]�����_��.s� /�. k�˃;��:��P��5�@��
`
�*�zo�e
���ZY���Pu{i���:�V���_����%�wk.�/\�.3�h
z	zX!�!f�lrqyy�\��f�/w��9X��,�b�r�S������{!Sutqu�pA\
/YU�d�������wn�p�z�t�p�����u59�\���s�
� ���%����7����*`8�͜-�@���߷�>
��{3��'���?k���V�(�/9-\_r[�P����V�v���n�`�@�?D�{f^�0�tt{,�V(o�]_R��g*���D�H��?"��Nܿk��^�����wj70X���e�Z2��-�P��3`3g��]�������A`��wG�_����ᷮf/�"�`�";+�_f���h�
-r��
X��_��]���9_��s�/All�4m@v�E��:X������FUOEKV���m�?��/���	
�+�����?�y$$=�,<�N^//������d�C�������3�`�����x����_'���H;X8Z��
W3˗a���7l�������������=�
�@Y^p��M�Hs�%��2��f���4h�T;v���m�W�>Ԅ�6N<�x�Bw������t]���<_*��|���m�L{������Љ�>�S܀��a���SS7.~@ �h�tF:�f�r�����`�Y���⵿j�®-8�A���������@�|�.1Sv,2��;:md�S6���V�w8�L�yLO|��ձ�mR0�x`�\y�����9�_{�O�/lqR��>R��,[�����5^_�ir�IlqO���ߙ��&ʔ���D�a}S�U�W~e5��z�x�.w�oۉ4�{�#U�pO@���6����i���0:ۦ����G���0h3\i�Nw�{��,���u�Z!�l�ppI�dp'$�߿���)O2�8���*�!|E�g�Y�.���Y��y�F��mڙ�@.A��t˺��X[Y�"˦�e� ��+���ٚ���U�w3&4|�|�
��8���Q-B��k���O�߷���uyr�2���I���6�P\1�Z�|l�a?��(a�d����!~�����,F�.�4s���OK�s��H
]h\]����T���E~����2�E2�$�Ot:�
�ۈC� �QĖ����O$�"�$:,�a8�}�s��*�v�К��b�L���]9v¦�=�
+r��
X��_��]���9_��s�/All�4m@v�E��:X������F_FKAU���m�?��/���	
�+�����?�y$$=�,<�N^//������d�C�������3�`�����x����_'���H;X8Z��
W3˗a���7l�������������=�
�@Y^p��M�Hs�%��2��f���4h�T;v���m�W�>Ԅ�6N<�x�Bw������t]���<_*��|���m�L{������Љ�>�S܀��a���SS7.~@ �h�tF:�f�r�����`�Y���⵿j�®-8�A���������@�|�.1Sv,2��;:md�S6���V�w8�L�yLO|��ձ�mR0�x`�\y�����9�_{�O�/lqR��>R��,[�����5^_�ir�IlqO���ߙ��&ʔ���D�a}S�U�W~e5��z�x�.w�oۉ4�{�#U�pO@���6����i���0:ۦ����G���0h3\i�Nw�{��,���u�Z!�l�ppI�dp'$�߿���)O2�8���*�!|E�g�Y�.���Y��y�F��mڙ�@.A��t˺��X[Y�"˦�e� ��+���ٚ���U�w3&4|�|�
��8���Q-B��k���O�߷���uyr�2���I���6�P\1�Z�|l�a?��(a�d����!~�����,F�.�4s���OK�s��H
]h\]����T���E~����2�E2�$�Ot:�
�ۈC� �QĖ����O$�"�$:,�a8�}�s��*�v�К��b�L���]9v¦�=�
 �ٝA��`a�y\�@��Y~���K㛖%��!
 ��B(ֆ��ػ����
��,��b���*w3���m�$�
 �@}�){�w���x�ˋD���#^�2j���p���[����q����R�}�Lӥ�%'!*=w�v�*����,T��ˆ<vI
�"4P��}���
@@ -5660,7 +5641,7 @@ K^{
 �V���&rG\@�2;�����pq1�n�#�����L��r�q��Y"�*
��,��0��
 �͕�,�	4[����e��d?i����b!Z�O;�,��񏒉0�*�j���p细�KL���orͥ�;�\����Yq�I��	�ih�x�6��Ŧl���}K�i��`�YKq�>��X�8%	De�)eZ=��5�8����@H���,�թ��c����S���-�ό����^�z2gt_�^)��q�;AQ3p��������v8%������n��.��$�'�����<S�e���9�V��ˠ09�������D0�tkl+����T����I��p��E�%��K_�Z�S�w�SșEU�O�cm�#��#���%�?�>MW��D���<R��v��H�JB4B1CPHxB�v?�
s���> A~X��i�Z���������`�+p솭�Y��du��:���}'F4�ɯ2���k�
�~�e���rB�A|t#�]v�=~gW��F�Ap)jK�}*3�4W`����/�兓Dz����/|�8/m�'*�~V��|s�fbr��]�ه���I:�S��g�Ԥ-�D8fv��R����@���a���
�b&%dY7����Gˣ��� �~%��H�j7ޛ׵���i�%�S<�P�l�M�����5�k�*�B���&�����ͲD ����	
���5w�S~A�}f�
`s���f����k��ڋ�I����P�;Сv�5e� Z���hҮ���`q��^kM�7�5 �X�w��4�<mc��b�<f���������F��d�=�}��������"~a��{�./�	?֐*�A/sP죙���pL�]Ձ��-a��P��;�y��te`��{�P�	nY���U&R�Q��d&�X�8��y��wvx���q�+��iD1�mz_����%�`��h"�2�u���������o&�rs�۽y:����E	�ocm�f��!���l��u�4j��K������o�z�S��b
7��ӂ�3_�e����A�Y��Xn
1����7��D,��ʨ�Ĵ2��J-��74�A���륅ZA�a�O����!&
jZnUl�yk>brfZo�t���ó���Z	F�`\�h��V4�B��>�nN�:I-�x�YP��1���׹��G����Ч�8���/ҕw�W�q�!��P�i(e�y�����lY1�j�����!�EoL]���L$��ja���U�\\
���V�@�d�@��B��� ���O��U�Y�!������Tm�	�I��`%s�x��I��1́�VǑ���x�z�jy��L�Bg���)�T0�i !I�v�F*}TL�	�n����i��p�k
��3��7s���}R�6�
�i$4`W�e�'+:�c8�vd�� }��zZ�49�Q�pw�^:�� �[��ݙ=�����,��
�=�i�X����%_t��!y���|ؘھx ��@4����1}�a��-�|3di��Vn@�!�'�û�]��_�1�&y�B�:��7U�]����Ym�"��jqLT��sU�Ǫ���Ek���Ko���;`5U��a�q��F^`��9*Ȍ���	;.}1ǃt�M��;
��qI��
��2C~eY�%�����{*����br�u���R�sX��(��.���H�":Κ%�(Z%�wڇ����|�[���~�X��*�QY��?�~�Ш��w_pO�}�j���Nױ�R��V�v3�xSq�׾��˂��b_��<1E��}PV-���FP���6Q�i�m��cÂ;1��X�_6�Mq�9�c�&��p�xy�Y�e��!jZ�vs@#��0涨l�T�o
�S� ��D�\�j�R͊�n;y:Wa����ž^��� ��
&3�}����:�%�
�E򱹩Oݠ�C��腭JQ}�yd����&�.Gp�]���I�46~m ],�D��']���F�tL͚�E
}�"�6�����{���j�r�2'C�ڶ$'��]��A�2�3�t�S����p|�V�W#V�����t���=,MS��/��9?-7I��t3�s��HK=�'Ct�z�C�0�hTp!����G�����x�3�2{��x�H���N�SW��U/�<F����O�߸�=��X��u����ǟCH
�8!/�}�b�N�L���V�y��a��E�f3w#�k�u	�72zaDE����SX�9�x�7
�A�;"�%O,G�es����2gy�co:)��R$P�4���|g��4�����
 ,�I�0��vI�B�qN�^	Ų�*[�3�Q��V婁�6*%`�"���oβ����n�`��Q$���I]��w�Z���*�m���ň
-U��%۸T?�x��h�K�d��������:������ңw��-����D6��	>QuO}��*�ڥ�&v�]ɚ��U�^�M%f��+��S��Ϫs�]̙�
�4"�	�?�'%����9���}��q�]�]k�8xE�k��eEJ4�����Bۜ!¿E,~�TS`�$螺��)��X�w��}��g�������m�Z��π��w�e��6���@M�S�7nDA�ُg�u{\�zo�iC&�R�V��dA�
W"M���X]2P���.�Y��Y.oi����U��kZl�!�9(1��d�aw�ɾ ��Q1���9�Dv2@&*����A���OX��fή��f�v(�x�bmendstream
+U��%۸T?�x��h�K�d��������:������ңw��-����D6��	>QuO}��*�ڥ�&v�]ɚ��U�^�M%f��+��S��Ϫs�]̙�
�4"�	�?�'%����9���}��q�]�]k�8xE�k��eEJ4�����Bۜ!¿E,~�TS`�$螺��)��X�w��}��g�������m�Z��π��w�e��6���@M�S�7nDA�ُg�u{\�zo�iC&�R�V��dA�
W"M���X]2P���.�Y��Y.oi����U��kZl�!�9(1��d�aw�ɾ ��Q1���9�Dv2@&*����A���OX��fή��f�v(���bYendstream
 endobj
 707 0 obj <<
 /Type /Font
@@ -5669,14 +5650,14 @@ endobj
 /FirstChar 40
 /LastChar 122
 /Widths 1354 0 R
-/BaseFont /PYOUGV+NimbusMonL-ReguObli
+/BaseFont /ZFUKPF+NimbusMonL-ReguObli
 /FontDescriptor 705 0 R
 >> endobj
 705 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /PYOUGV+NimbusMonL-ReguObli
+/FontName /ZFUKPF+NimbusMonL-ReguObli
 /ItalicAngle -12
 /StemV 43
 /XHeight 426
@@ -5698,7 +5679,7 @@ endobj
 stream
 x���UT�]�%��kቻ;���N�Z���;����;��Z�����t�������y�ω�#N�8�Y���XQ�^����L��΅��������hdccd
 ���W��5�5���8����D�\�xf�Q3����� b�����t
P�堦���O�?.c�G�F:-�~���;ؚٹ����T13�X�
́6fE-)y	���@��������jl4
�M��ͨ
��N�[L��L��l͙�/��3���`f�f�nb��Dp0s�:;�}�
NFv.{�bڙظ��S�_����
-rp���a��K�h���l�tp
�ͪ(*�ou�X�����؛��4�7q�gK�����E]��v�3w�r�
L��6Fs�%sp��Wg���V@p2�0r2�1sv�K������>
���l<�m�/���
��lfc����7�����@;8�FE������ovSW��~�9��AT����"�L��l<�f�p���.S���Tf����A����[����j�������_��]ml�l����; �璱�߼�l�6�'���a�oE�i�\���B�����l\L���Ł�f��@K�����^�ˮfgj�d�3����	�gfb�/��%������dfg�_��+ӿ�g���PR����Uz���e����o�'�E����?�i�ٛ���>aa{w�=3������
dap����r����?�rF.N@w��_����������3�7�gvT\��L�����M\����������}���73s73�[�eo�l����R��72%�3��>�PڨZT�_c����]i�^��4����|��q(Ms4ևeCٛjvU��CJ�_��E��I{Ȩ_��q��u�$�����~�7���_�E0���s�D�O������
��$�!��	����9E���#�����p�
d�!mn,9�D�(�\<
m�
+rp���a��K�h���l�tp
�ͪ(*�ou�X�����؛��4�7q�gK�����E]��v�3w�r�
L��6Fs�%sp��Wg���V@p2�0r2�1sv�K������>
���l<�m�/���
��lfc����7�����@;8�FE������ovSW��~�9��AT����"�L��l<�f�p���.S���Tf����A����[����j�������_��]ml�l����; �璱�߼�l�6�'���a�oE�i�\���B�����l\L���Ł�f��@K�����^�ˮfgj�d�3����	�gfb�/��%������dfg�_��+ӿ�gQ�W�����Uz���e����o�'�E����?�i�ٛ���>aa{w�=3������
dap����r����?�rF.N@w��_����������3�7�gvT\��L�����M\����������}���73s73�[�eo�l����R��72%�3��>�PڨZT�_c����]i�^��4����|��q(Ms4ևeCٛjvU��CJ�_��E��I{Ȩ_��q��u�$�����~�7���_�E0���s�D�O������
��$�!��	����9E���#�����p�
d�!mn,9�D�(�\<
m�
 ��V���^Nc_��iܐ�槕Q�ъ�+���P�Y
���Z#����6S��S7C�0��D�X>�O�ƶa�l�J���Ҋuw����h���7n-	�}������[�w� g�����נ�����ۭ�IZR
� �Y�u#1��t,����CMMW�M���Ӗ$�I�]��}}���(+�X{���H�=s]Ԑ��<���b57U
�Ct��# �@
�KC�F���5�0�#�OX�g�FC'<q��� z0��VK�oZA���3�J%��Z�(�T]Z0
 ��ʩ�t��N�����u�T��4F�䂙ϸ��:�0��z2.�8���"�@b��:�(o`ԿkM.Z�#�2GY�
nplw��m݆�f[8�")�-�>���"���,��6�#�VE��4� �T�	�����X}׹�F;�yhȱ��x�!:�<�?-p�y�>sd�aEG2��iħ��_,�:���I�
 �����.���^�!Oz�(~�@��ʨJ�	�(�)I�ɒ!�[��7O�0	�(��/��#?��tss��w�gWW��;�
@@ -5770,7 +5751,7 @@ Pпܠ
 �jD�G�@�=��0V�23q�8@R��Sx����Q�k>֘Iۻ��n�@���+7��	#xA&�#A�����
k���I�!]i���A!��5�JN�w�O�	�v��ґ*��*,�פQ*�=��^���P���툘�f��U�{��������R����	a�p"�[�����k=�_���6�g]�s��V��/h_���4J#gB�ą����:��y��~�髩W-�uu������^��N[pa*'���+Z�X���ක�}��J~NZ_?�}�i�xA�����Z�6���u�a���DAE����kd'���2�؇�
 V��2��u=���"��
�}��Rp�G0�|�����v���#�i�j3�T��(3Z��]��6$�H�.�2r�"��.Q}�[�(~�a��|�g7L���i	G�zB�������y,<ri5��<�Q��"�@X1p�J9���{5�XO�!��D��-���{��|���|�Ȕ�;��U�FrE���>����%���.�c�G�3*ٺr��.��S�Z����i�����"�8׊�[�o��i��tB!N�Ma3_#�֑3?z25Q��%Tb�����S�\	��`�D�����"�һK$��� W�P-$�"ta�5�.��i�"2a ��Eg|�����O-,�'�Ƥ�p|�̔��7r����������!�v����0�B�y\�q�XkʀX��;my��(~a��{�|�ob���֭�x�=���` �罦(h
��85]��C����U�u���4]}+7�� ډ-���O���}KHE�r�
�b۟�wO0t��o��uZ�R�t�q��.��8M�ƽ7���8m
[lC)��پX<�����7�rL�IQ��RоR>�O���zMЃ�:� �P�k��wS�RnB���<9Ų|<�{_�+�>�zZL��S�6v�I
 �?0
-t��t�q���?p�?��'Lľ�\�m�����>��endstream
+t��t�q���?p�?��'Lľ�\�m�����6��endstream
 endobj
 638 0 obj <<
 /Type /Font
@@ -5779,14 +5760,14 @@ endobj
 /FirstChar 40
 /LastChar 90
 /Widths 1355 0 R
-/BaseFont /IKWPAS+URWPalladioL-Roma-Slant_167
+/BaseFont /DCPNPJ+URWPalladioL-Roma-Slant_167
 /FontDescriptor 636 0 R
 >> endobj
 636 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /IKWPAS+URWPalladioL-Roma-Slant_167
+/FontName /DCPNPJ+URWPalladioL-Roma-Slant_167
 /ItalicAngle -9
 /StemV 84
 /XHeight 469
@@ -5811,7 +5792,7 @@ x
 �k䀣�u9��lŌ���
�)@h`e�����QD��=A��j5e
::����0���ߝN s[��W����
���/���F �l
����Q��Z�
 �jI5�$��hd
��bl
2
ȁL��N@���#�������)�Ҝ�b	;
�N�@��m@w��?.z�=������r�;�:�큳dkb�b���v3��w��a���컝����#���7�w1��t�0r�'��`g�7����埒������l�u8ݝ��e���쭍<���f��
'���2�8͍M��NNa�b�ӝ���Todoo���v����@�N@k3F8ֿ9M���6��1�3(Ҷfv��M]����
 t�W������$�L�l�=�@38&;�)
��g*3����� ����-��߉�_5�_���y���.��
-F6����
c��s���b�l@������
�7�������6ۚ�������F���h��lb
03��ۣ��lM��� [�_-��F3��Z�L�l�i:ǿ]@[�����<���$�$#�)B�_o�E}�������_b��y;����CD������``��pr���X|�7����ky#gG�;@�o��,�*������/0�&v��L������������&.�����Y�[���5�@�;�ne�΄/�2=+ù;ohBL���b(ľ�jq��]�_z�6O��[]c�$��/��?���2�#=X�Tݩ��2��B�
�v.��@&�2ČS�h��y�-HmNf���	%e��7(��v6G��G2�B�{$_���8��&0���?��IǏT��C���_{���r�`)�\!)��r��ժ�"h3�&���N�ͻ����8��Y��6���|.�o�	U��픆H\ά={�fz���w��(;Inj��1$�.]d������c!�-��H�F����ǀ;��=�|�.ہE�e	���Px�NV?�W��Ɛx�5VB��u%G�����Ne�/G��Ƭ�v^8	�%1���1KP�q��A�?���Q�!��6�$�qs/��A{��O�з���x~X�v����Y�aWtM=#���&���@�Ы�2
�+��~YqWR�c��67H�������7�������0���_���F?�ڊ����?B��65�����
+F6����
c��s���b�l@������
�7�������6ۚ�������F���h��lb
03��ۣ��lM��� [�_-��F3��Z�L�l�i:ǿ]@[�����<���$.��*�I�_o�E}�������_b��y;����CD������``��pr���X|�7����ky#gG�;@�o��,�*������/0�&v��L������������&.�����Y�[���5�@�;�ne�΄/�2=+ù;ohBL���b(ľ�jq��]�_z�6O��[]c�$��/��?���2�#=X�Tݩ��2��B�
�v.��@&�2ČS�h��y�-HmNf���	%e��7(��v6G��G2�B�{$_���8��&0���?��IǏT��C���_{���r�`)�\!)��r��ժ�"h3�&���N�ͻ����8��Y��6���|.�o�	U��픆H\ά={�fz���w��(;Inj��1$�.]d������c!�-��H�F����ǀ;��=�|�.ہE�e	���Px�NV?�W��Ɛx�5VB��u%G�����Ne�/G��Ƭ�v^8	�%1���1KP�q��A�?���Q�!��6�$�qs/��A{��O�з���x~X�v����Y�aWtM=#���&���@�Ы�2
�+��~YqWR�c��67H�������7�������0���_���F?�ڊ����?B��65�����
 �ݡ$�6;�� �S�F���9Lq��#7���A�Oy���k��0\���)�ڊ�P���_�����+WX��4�qW%�3A	pǂy�Nј�h�F�����H�Q�v�;�0p�]�t�~xd,���x��6m$��b��a���a�Q���ZCE{�͸V>$zytg�C� ���~^�Z΢�'�4v̢��Q(�����E$9�>R��vJr��!V��Q�-��
�]k��#L�)N[
 Y'L
 Ml%�:Tid���!���|�=����})��Hz��Q��)k{U�����T�•�h�-���yX3�II����B��#
@@ -5856,7 +5837,7 @@ S
 �--�T��?�שּׁ~Ig.�s#IR�1�d�0s��l��)w܏�C�5Z�D��A|aK]��Q�)�э�ۥf�-6w��n�ԑ�Z����e��KQ��!q�l���;��`����j�"�Fd�(��%Х����:�K��֐���j?�0GL��/����s�mt�7@F.�v�\�`�_��@��+߭'9/���Q��;*��~��\݂���
"@�w�>���9s�K��e��p���uqz��-/����yCO�V�u�n���LȘ�m�]��a���FP��Յ��7�wź�%=����m�Uŧ���Ԇ��Yne[�Bcڣ�����AB�N��Rֵ`0��֬��x���\e ���&���ix�>*�>:��_/P-B�
�57#Ck�ym��KO�=��[-9o${���Q�Uߛ��Q����iy��	� `��P��{EԦ+���o}��C�C=���q�u�b����@T``��ݼ�8ԕz�ӓ�n��OJ��O�5�)!?ax}q�,�c��Hb��ǭ�7?��[~����
Qf�d�;i	|�PjPJ���n9�w���|��+��ԘKd���K��^�s|�S�@�?�݊�e��֍��C��70c5��5��ir�:��XJ&d8݉��:ͨ�]���W"�&�3K��/ͽ��1�5�#b�f��7�$�#ב�_�f�f�ś-��=�{�q�/ �sTD�������_��PH��V��
�Ũ��{�� 
�4Ӡ�}K�bٓ��'�+Ӭ;=A���Zq<�_6�VsL{��?$�\�Y
1XHB��8���D�)ń����Ab ����7�ȂF8�h�[��w���s�|H{��6k��gKE��U�?�
����o�mHl8�bƩD���8p]��z�#y\�J���@y�Ńe�YIi1������=����N0Vn#Φ�{q�pX�d����u����tD�뚽�&�4N�8�&\u�f��O�_�b�8�b0p��k��wȍJ������$��k'o	g�Ƚ���N�|:�Հ��2�,��X@���@���<; aQ�*��m�'
�
 ���h����;f&���tYPX�(�ї��*�R�͋MI.riAۏ�eBapX,&L��F�qO�i/z�-J�َX!|���{/��l��2�L��$��y�r���tA3�����MT�˹#��_��C��%3(�BN�fMݱd[�0i�����e�n��,2����>Q~E�l�чd��K
 �	�X��	�S�M�kh_v.�Z�X�Y��~d�Z��q�z3�=p��*S�ᣍ.rY�8xz��m:���fkl��3V�y�ݪ"|pA�q+K����5���X��3�S�K�8�Xg�y6V�O���n�|@a������\1-��$j���Y�6I���Q����.���!�"	���#k��@n���.MV5�ҞpɾT	�L$*jsK��kU3P"���ǂ�\e,Ѷ��Ue�ATI�
��#DR���f���D�4��;��"_u��+E�8崕�.
a�M�eə�m��b�B�_S���,�5�L(�����l�O���,��V"��e��ŗ��~,���������gq8��Z���}�/�'la��S�q�t���^H��Nw��taES<hpFE��u�F,p?��8*��z"��>���lf���~,��Ni`��ύgC�@2|���>�6.�W��>��ؓM�+�
$g;���G�ޗ�
�E׮ڧqkER���c{��Z��Zd;_P��t���/QO�I��g����%E:)�7��zz��t�Z��
-�9���N�ө޶Gn����,���:�5�=�x�=Z����Q�Gc]q��_������'�(�DZ���J���I�'�_��:��HjD�l��,�q�`G���\�@�������ܪ�X��Q<�i8��|#�����O(m�m�8�7�r�j�"T�y�
Z�|A��Pq��
[���3V�l�
�
V�lb��.۞F
�o�J�����d�&�f�ic���+w�zH�_e��?���w�*����b�_��O�iϑ+nR�L�y�T�}�����#k=|���?���n�:��;]���P�2��	�x���4�L�G�F��v2����$����!���[�9�}�hH�8E7�����];#t��;ڍ�
Q�ɝT�BK�hH˜�}3�.F�Q8)IO�������
�?
`b
4rt��1r�����dyendstream
+�9���N�ө޶Gn����,���:�5�=�x�=Z����Q�Gc]q��_������'�(�DZ���J���I�'�_��:��HjD�l��,�q�`G���\�@�������ܪ�X��Q<�i8��|#�����O(m�m�8�7�r�j�"T�y�
Z�|A��Pq��
[���3V�l�
�
V�lb��.۞F
�o�J�����d�&�f�ic���+w�zH�_e��?���w�*����b�_��O�iϑ+nR�L�y�T�}�����#k=|���?���n�:��;]���P�2��	�x���4�L�G�F��v2����$����!���[�9�}�hH�8E7�����];#t��;ڍ�
Q�ɝT�BK�hH˜�}3�.F�Q8)IO�������
�?
`b
4rt��1r���`d�endstream
 endobj
 631 0 obj <<
 /Type /Font
@@ -5865,14 +5846,14 @@ endobj
 /FirstChar 34
 /LastChar 125
 /Widths 1356 0 R
-/BaseFont /IQJBXB+NimbusMonL-Bold
+/BaseFont /EGSTMX+NimbusMonL-Bold
 /FontDescriptor 629 0 R
 >> endobj
 629 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /IQJBXB+NimbusMonL-Bold
+/FontName /EGSTMX+NimbusMonL-Bold
 /ItalicAngle 0
 /StemV 101
 /XHeight 439
@@ -5894,7 +5875,7 @@ endobj
 stream
 xڬ�c�f��%��Y�'UiVڶm?i۶]i�Ҷmۨ�U�����_�s������c�kƌ���؛�XA�N���(fg�L�D�����1rq�����S���Y��Ʌ���v�"��@.�:� 403�899��
�v��f��JU%u*����0�����;�,�l
�������m���!��7*�gs ����WД�P�˩ā�@GCk������1@��h����9����ٚX�S��_,A'�!��hl�w��h���`t��pr���p�9�:�큳���������v�"d�h�7���/����������3�oV��t67t�'���_7���o�����?%���������	�tw�'�`b�dom��7�_0{G��pq��5�/�G�����5���/�_���_u���
���=����_Q������ڔ���oNc翹�,l��I[S;��&.����
 t�W�(����$M�l�=&@S89;�)
��w*������ ����-����?5���������b.��r�6����
c�
�s�X:���
m,�=��3P�o��8�Ά�!hk�WFz�-��,܁&
-���SC뿝��]���hma��迚	�cbd��������?�g��hk�����/��*"���4�y��+J���*����Rd�L���!!;w���H�����7!���!ۿ`��k-k��h���[2#ӿ
+���SC뿝��]���hma��迚	�cbd��������?�g��hk�����/�ʒBBB�4�y��+J���*����Rd�L���!!;w���H�����7!���!ۿ`��k-k��h���[2#ӿ
 ���t�F�����YQv6�5�;^����������:����
:�4�[[�3��L�Lw�������e�/mP)*���K��0x�	�o���l�X:��8���=ڋeMѓ
 ����!��+@����N�;�A�1�\=��zQfB��Q��ޤ��^�;�t�G��?T����dO�H��?��0;QA�j�ο'��y�깅�;ģɉ�%�v�@��ǯ�Z�A�ބ�w�~�I�����GN�Ki#�`��n�.����ϓ$�(�zX��u3?�#�4�9����B.��ӄ?�7kE4�	]O8�vC���UkSM�ڇ��02��YZ��uH�H7�R�$�j�D"$m|/���K|ZT7��蝳�9�1��u����@�v�y��Vh�x+20%3�t�%7!AZ|����{�ڏG�P�����
_����X���"���'y���
��o)8[�̗3	!�,�	�h!k<L��l�8�}�-��4��4�e�nv���@��+��Z�F�h�������??jb��S�cj��F�א���yx㰢�B;^��tlY���H�� �޴ǭ^���=�D��bx:3p�=�c��#�],�qGĮ�k�
 �H�f�Ж���������	ӓ�|#9�$�|S��W�mMQ$TY�ZQ^��P�LR`�!T��|ބl�lFO���S�gc8FR����S?߰���l8DN�ޝ�l����y���4ۭ�L��K	����4|Eu��ﴀ�fI]]���ܫί1�����Дym�N�ːzn*�	�\8^	M�B9x�j�g�c�9N�zMG�es]Ý
�k�ǥ@B��|p���
@@ -5966,7 +5947,7 @@ d
 �M�b�����@o�1�%Hy.�y�?.��rn���T��p�Z[��4��ɏ�H�y��#I�H���g�1�rw�eB��?�ɾj��o�[�V���3PTc�=,r�?s0��)�:K�+�b�J�'(g�c?8Ⱦ<χ��ų���氅SvU'�N������m�iG�D���Q� 
�V|Q�i��-(�P�1W��s+�A�rl�xHԆD�# ���Z���V���
.u�&̺�E�	V��|���Ko��N69]�?%����:��GI
��m��i�
y�Y�^\���㿾�ޫ�`Q�|��i��<{�Ds���ѩ�6�&`��WJܓ	�+�W|S#3L�+uۭ�`D��dh��Vd��+�{�"o�� �x���$������\D`�}��c��͆\�Z.�[ۆ��]D�D1��DSM���C�:-��٦��hj9
 [�J�G)��D�U��QG^D:���!5�ޫ������A�X��H'��_�g9�Ô�M2b�+ih'��Cg�P8���F
 e�'�7�d��c��h�0�ݔ}tw�ֲ���6qj%�y?x�`*O�z����mD����g���|[w��P0���3ij�naT���rļ��[�D��	����
-bi}j2�s ���o����Ha�)y�c�H��i��6a�1����Rm8 �8�%���N��	���"@��9c��}�1�������endstream
+bi}j2�s ���o����Ha�)y�c�H��i��6a�1����Rm8 �8�%���N��	���"@��9c��}�1���챧{endstream
 endobj
 628 0 obj <<
 /Type /Font
@@ -5975,14 +5956,14 @@ endobj
 /FirstChar 33
 /LastChar 125
 /Widths 1357 0 R
-/BaseFont /YTDMMS+NimbusMonL-Regu
+/BaseFont /SIBBBC+NimbusMonL-Regu
 /FontDescriptor 626 0 R
 >> endobj
 626 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /YTDMMS+NimbusMonL-Regu
+/FontName /SIBBBC+NimbusMonL-Regu
 /ItalicAngle 0
 /StemV 41
 /XHeight 426
@@ -6004,7 +5985,7 @@ endobj
 stream
 xڬzSx�]�e�Tlc�v%�ض��ضmۨ�m�b�b�6����ӧ��}�}.�~�5ǜcb����xɉ��M쌀bv����L\U%uCkkC;zIgCk�_3,9��#�����V���P�D��3''',9@��������@�������?-���<���daf����
 ����
�:���T
��@���5 ,��))'��S�m���Pp1��0�Xm���S;G���c;[�Zsb��%�08��-��
ݍ���@t{�������g��������������.&���nj������z�����)�99;;Z�;�fU�w������v���L�z�����ҿ��4QgC['�3����\F@������������-�U������V@p�:�X�������g:��'��������_�v���_5X8;
�M`�Y��4v�������"ikj`f������?0W��D�Ϟ��[�������h
-�(g��7%���Me��>��$�o��E��?q��F��!��=���Z���Z���� ��1�?������nhca�������W�4s�6t����m��*B����o�����;�D����`jh�wV���ښ�-l�5��8
��LL�S1�0���g�l����&����2��xF
uY���^����_��U<쁀��D]���-�a�sx�3s0
�Y�������;���%㿈��s-k��h��fb`bb������t�������?;F������&�_�`cGǿ�����m�?����@�;�ve�Θ;�2=+ù+ohBD���|(��W�Jq��]�_z�6g��{MC��g�ǟS��})���^LkʞT�e
�)u_!�E�A ��/��3�h���--v&���	E%���PS��0WO�������d�����i�q�ȍ ��E�gI�O���G��{n ���hs㾑s�B PD�;���k���V6�8mN����v������䴓[�{[��^�j��
���'�E��3�%��K$c���^55`wz���]���{�Fx9].
�n1[Em�QBϕ[���ض�3M����v��V�\���*2mjV���pz/�]6r
w��R��I%Po�pc�75��'��h��W7JUϳ`K�$��s�<�7:^��X��}��?G�;�D�<b�8�4���B5[s����|���S,U=449x7|���1��	�
!<��>�c|y��G�CK��?e��!Aʐ�c�V�nPW�6H��Q9+�hh8�Sf��0g������h7F(͡7�ؽ�a�Z�/�y�I�1���ʮkZ��R������N�NN�n��T7%��'��7i"�
+�(g��7%���Me��>��$�o��E��?q��F��!��=���Z���Z���� ��1�?������nhca�������W�4s�6t����m��*B����o�����;�D����`jh�wV���ښ�-l�5��8
��LL�S1�0���g�l����&����2��xF-a5AQ���^����_��U<쁀��D]���-�a�sx�3s0
�Y�������;���%㿈��s-k��h��fb`bb������t�������?;F������&�_�`cGǿ�����m�?����@�;�ve�Θ;�2=+ù+ohBD���|(��W�Jq��]�_z�6g��{MC��g�ǟS��})���^LkʞT�e
�)u_!�E�A ��/��3�h���--v&���	E%���PS��0WO�������d�����i�q�ȍ ��E�gI�O���G��{n ���hs㾑s�B PD�;���k���V6�8mN����v������䴓[�{[��^�j��
���'�E��3�%��K$c���^55`wz���]���{�Fx9].
�n1[Em�QBϕ[���ض�3M����v��V�\���*2mjV���pz/�]6r
w��R��I%Po�pc�75��'��h��W7JUϳ`K�$��s�<�7:^��X��}��?G�;�D�<b�8�4���B5[s����|���S,U=449x7|���1��	�
!<��>�c|y��G�CK��?e��!Aʐ�c�V�nPW�6H��Q9+�hh8�Sf��0g������h7F(͡7�ؽ�a�Z�/�y�I�1���ʮkZ��R������N�NN�n��T7%��'��7i"�
 Hk��x�ΙsT�ܺ�F�$_2���������҆����j%��vk�ʜ�%�d` ;�S�d�/��]��S�����Ka��
����#&[K^��+�UT�dak����fUX�u��5�J�CL8K�R�<�öwm.�L˂�&�wLC��a!~6]�e�kZ77�?��,�����0a�%��
 
 \P3�ة��%��Q��sy1*�����3�W���;7 K�y�m�Z�h\H�������|���_�D��!)?�o��r$q0>����O�<X)
@@ -6087,7 +6068,7 @@ lş
 @���o_U�;���e?Z*���O��ͦcZ�6z�*�2FFioPd�]�U���Nr���֛��s�_̀�����?�
,�)}�����ͮQ�~�8�_��?DR>��b{m㔿/�H��,ۻMEr2���g�(��w��Ӥ,D�J.pW�?W؃�'H�McՋ~[5
j�i� "����b�N�����`����ə�e�ԓ�먄l�y���w�����~�J!�A=�Ð�8�� N1&��8#v�:�Q����0
RۤT(���t„�$�bwF�߮
7)�Z�����X�;d�Q��C�sN�ڑ!jC��#�X����_��
 �mK1����
�:��<f:��V.sF���N�����EQ�g���u�,��vz�!�uS,�#\���6KѯA�I�)�SX1�~��<& �;�]z�)ZP=�N�кg�)Q���}�>՘z_#�*��s,b��o&��]���Ҭ�{����x�Z��\�.��q�5�]�_�
�~wX~��U�"bg�%̗��bٶ�¾V�3a��$����!�L;ENL��[��(�z�����
:\�o������d��n�j�P�n���{:}*PDv�w*[�@9��pR��͋�E�(oh~���hk充Dۖ�[���o֙ziU�ɉ�-��k^M���,��f���x��GS6����>�+5Xە��f��m��׮�v*��p	��,��W��{+"��V�ŗi���6�,Y��S�l�����H���ٶ�;��:Jb���c�2��'
��dn������Jz]�^kS�v�Ƥ>f��Q̒�飺��N���%�A��i�O��o�/�vٟHMp�d�.�8yи��<���T������]��Y�z�0�YJ��V�����/=�W"��:C衁��^+�sZ���q�vO�$�i��V�q${z�x�ʫQ�c��r�Q�Uz��F`�4�jþ1g�\xE�	��ɘ�Eլ��~*U;�٠�ɛ
 �0a����[��r��%�\q��]�����|O-F�kދ��'�Q�.��Tq�������)R�c�����D�V����5y�L�R�w
O��ͳ���Ʋ��x��uj2a��	d�M�a�x��]&e9�};��q�m��ʳ� $j��V�_y��6�W3���R��ѹc�Es�N1}�Nj�Ǟ�c�!\��1��,,���\XM������Dʟ&�~9F=�'KJk��YG�����s�z֏��c��Xn���KNT�E}ͮ��jYMr5���N��ge���
���Ҡ����3�1�vyp��j6�}�I_�i�E�
�q�'� ���+��b2��R���~U�ci�e��Pz�k!���2o���v)�!>�ZJ���Gj]��W�H:���Y��M������q�mu�O#/3K����iEp��3䇁�O@�0��5!�ь�
�8���;*Ub�S����q�2,�#h=�Mx'��RO���B!�<�q	��87�3�
B$�:��z�OE:�P�%��kĴ{@������
-����i<��i��?�l��endstream
+����i<��i��?o���endstream
 endobj
 622 0 obj <<
 /Type /Font
@@ -6096,14 +6077,14 @@ endobj
 /FirstChar 2
 /LastChar 151
 /Widths 1358 0 R
-/BaseFont /XDWPTM+URWPalladioL-Ital
+/BaseFont /ZCVAEP+URWPalladioL-Ital
 /FontDescriptor 620 0 R
 >> endobj
 620 0 obj <<
 /Ascent 722
 /CapHeight 693
 /Descent -261
-/FontName /XDWPTM+URWPalladioL-Ital
+/FontName /ZCVAEP+URWPalladioL-Ital
 /ItalicAngle -9.5
 /StemV 78
 /XHeight 482
@@ -6119,19 +6100,18 @@ endobj
 /Length1 862
 /Length2 1251
 /Length3 532
-/Length 1861      
+/Length 1860      
 /Filter /FlateDecode
 >>
 stream
 x��UkTgn�J�+ŀ��
-�2�@	�,��K�Ʉ�LP.(��`P�r��RZ/��b���� 7��	V����z�ҟ����̟y����������L�>'6� B1
$�4���� H@"gf����@b���� �$	@*@��Q�4��pF�"Q^0WX8�(��0�cAB�sa
փ�
�ŃőD����W�oX�0��A��c�� 8�'đ1��[�ْ��T��0S�f���F��H�
sp$�Ɯ�7L�l�"��= �b�����C?��I�0
-�#l�������a6O"X�2���r�a�����e�'r�Ia6�'fq
��K8,d���ŷd�����uu�z3�%�	��}�a0@~�^��w5�ʓ�d"�bB�}��b�τ,���-�(��NVQ�h�	ٰ���cQ���%M�AP��XAk���,>�Z��x�]&�)��D�`
-�`>��3l�^�;��!��e�
�Pq��G�#�h� ��b?����5�߄,	��B�����[sx��`X
-�p���!)$�:�"��s��������Rݫ��W��c��P�z��KG��W���
-��Y'u���_N��^��VT�Om"���#�dk^Y��2��N|�4�5��|�m{����6��l�йƹ�n퍖�',M7����x>r�q���ڸ��;Y��1�x�K����4
�>�p"
-+����*�Q}��z��&��T��g�>�ҙ�X���o�i�癩e�|婅k2�_�-O��$e��m4v3j{h�}����C�Q0y�z�őZ���G��S^�47��>/�Bjr��<�
-��~��~|F��S���˵���@�]w{�3_jyth�Q�%Wfe���c$��MG�������|��W@
.�ry���2<x�ZE�T�egd�偗���kE%�D%��i�G���]�}�x��X�$#M/7�j�#��WY6o����Ԝ���t�5��YQz
-Y�8��9�=��������B#�ps^R�g�3���y��2�̎�-	c��d����VS�qm�ŮR�C�H�b���L��S���*��i�A�����[��͍�J=��鋸�?&��XB�1�rhB��=7�np���L�Y�P]flB��K�	��9���v�'�ց��\�S��㲎���05t=�e��j���Bfw�Dh�?+��V#���pM��{&?ԾT�=rrǏj����ۚ}������7��<𬃮��Q�?tg��/������<e}�K��������P�d����7�W�DB�Dk��"[���I���c���2��e��,�i��Ԟ���*�GUM�=u�)����0订�c�<�y�2^�0YY�O�����8��s���/'I���kԵJ��|�U)S�%Z���2�ڇ<�dsV�tJ��k3
H���o�cg���R��u㾊�h{��Fg��:O~�Ӽ�7��1���p�����j�J}�(�vOP1F�+L;��ǮBeJ�|Ė��k���1�}Z��0��2�B�Mf�t�qq�BI%@�6\�.��$�^6��O��&>-Jh�g�uIrrr<䗣ș�K�b�V�r|qO�%Q�8ʨ��!���S�v���sN�/����VEk����t)�m]�e�n�5�2�tUK�o��iAv�)$��Kל�ِ����wl�7\�m������Ú��f�z
ڎOeӜ�3�����L~�:�j�m���}-����#�:��}c�L�ڥ)��Sw�w����|�8��9���F��\kuRy,�#���;(�����q���Vp��!����
�'`W7��
����H��_endstream
+�2�@	�&X4�;*(R���LP�
+A@0�P�TZ)�`��b���Y#BAn�\u�
�إ?w�ٙ?�>���3����Y�y��l$vEDHi����A��D2����!	�$0
A�.�  ;�(d�
g
� a�(�˓V.�-��F�,H�C,�z� 
�����$���ga����0
��8�|���|����)� ��̖���"`T���0��
�E6"Dl��#y �^0��ajysW�@�
	�/��'��o�0L*�Q�aèh��^2���R�r�)�|]��
�#�m�K_�ʗ�l/���8�@/Ⰸ��
+ߢ}�>��n6o�HzA|�d_d�߫k�}����e@�H&��{�}.��a�E\�B� �"q�	�**
|�
�sL"�	���9p�0V� ��(K��&Y`�*@
+�2���)�B,Xs�۾������p}``+T,�ļE���1�,�@q��؏��=��@=�oB�Ea�d�lb�9|ld0,�Y��.���[�T���;?|D�y�Z���n��㳏�R�y�q%%#E��'�P��,�S���t������/^M-,�ό�6�}�	��U�m,G�����Q��Gg�ݲ�gjKl��9��q�|��@��zk����z.h��
���c�DMl������ݘ^x�k����<�<�r"�J�az�=��!{n�gZc��i�y����2�tj�q�o�´�wSFӋ�����5�2���Q$�P�2�v7����>����j�!��K�]qi�ƨ-���_*��7j퍥1/ʠ����]O�¿��>��~������g%u
+ݮ:Pǽ���:�Z�w��y
��(	?4f��ugwɣ8�zF�}�X�K��\_k�7
�F�1�w:�X~u�se�jq��q��Z�Q��fG'�@=�~8;�9�L5��^��q�8�J���Z���rE���v�*3�@i&���9gtg2�ҽ=���j�n�M�|����(V���6�)~�O��<��r`�fR<�K��Y�ll	_�w���צ��]�f*�춛���:yIY��ɔs�0;�����C?E[�k!��dM���,�=Wy�:U���{��C"pΨ<�M��)��mPǡ=(�᱙G�Gͼ��=��W�t����&�|FW�xh�?+�S��^�ઞ��vM|�{9�g�Զ�4ki�w���A���ox�q�y;�0�п���k^����W{�{�q�5�~�������y�n)�)�����[��T�ч��7F��7�,�$�m���3�쀒\��?j<#YW�V�+�k璃��a�=e姴9���u��i��$����_c��I����"�I�z�U�"3)�cT&ON봼���6�9` ���fP�VI�4�Tǝ}��vqf/�&sl^3�L�v���6��?�{��ݦ��yyώkE'+�
+��5
��+Ԛ�&a�����QbmA�_=v����"6�
^o(�q �����������W	V�o3*��W���W�-CE����H�����ᆄk������p���Niv}N|���J9�I	R��b�W�/ꎾ,�ZG��V���k����5�w��)u�Q7��h�^#����#�-�5�ͷG�C��t���V���A�!��4�i�u	�YvZ�XW�VC�5Y&�IA>�q���pf�����d���x�)T>�F�7��#����#��6�kk����L�q3�m�%�QM����E8�#��1�d��3Z}�
+���e1���:;4����X��V����:�'����?|p�o�?���!T�!4�/��gendstream
 endobj
 612 0 obj <<
 /Type /Font
@@ -6140,14 +6120,14 @@ endobj
 /FirstChar 13
 /LastChar 110
 /Widths 1360 0 R
-/BaseFont /FHPWHM+CMSY10
+/BaseFont /AKTMYL+CMSY10
 /FontDescriptor 610 0 R
 >> endobj
 610 0 obj <<
 /Ascent 750
 /CapHeight 683
 /Descent -194
-/FontName /FHPWHM+CMSY10
+/FontName /AKTMYL+CMSY10
 /ItalicAngle -14.035
 /StemV 85
 /XHeight 431
@@ -6171,7 +6151,7 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xڬ�c��]�%\]��.۶m۶m۶m��v�m���}�ܹ��̯��G����8;v�>'�z2��@N������X��Ɖ�������*�oe�odn+E�`k��kf�"&t0�w2���w2��
��

zvvv(b�����������/9%%�Y�	
�����NGsS��c+[;kc������
Nf�s+c�������(�LTF jlc�o�s6�27H��8�LlV������S�#�_,~G�>�������6c7Cc�\T;cksGǿ�sG�������8��m����!��nb�/!;ۿ�}��l�
����	��O'3}�r;��ulM�F�:�Sҿ��0�N��6�'c7�r���������f�`�/
gGs��b@p06�w0�2vt������W����z};;+�w���?9�;9[��@�3��i��7���
�?GE���@O�v#g����;�� ���_�F�6V�#c(Z[��)
d�w*��������O�"��?q��F��%��{��;����������9cR������omn������A��#����6�堣���������������D��o���+�;X������V������O�������3������s�+ѿ�i��edd(����o��_흔���R��H����?(�nOjz5��+�@`gb��?d�������N�nͿe���[�����J������sZ��m����i��m����W���ߢ�s��Q76v36�Z�ck�d����T��;<)����d8خ�Q����ƶ�7-l��R�6��i���}����@��p�͊�7��*Ǜ���q�����0�V�6�\5��zQjT��N�pwR^A��w���
���܏ȥ��ד��ajC,jBR]��9I��������P�-X�
6eN�ObNPX�H?�l^
�
+xڬ�c��]�%\]��.۶m۶m۶m��v�m���}�ܹ��̯��G����8;v�>'�z2��@N������X��Ɖ�������*�oe�odn+E�`k��kf�"&t0�w2���w2��
��

zvvv(b�����������/9%%�Y�	
�����NGsS��c+[;kc������
Nf�s+c�������(�LTF jlc�o�s6�27H��8�LlV������S�#�_,~G�>�������6c7Cc�\T;cksGǿ�sG�������8��m����!��nb�/!;ۿ�}��l�
����	��O'3}�r;��ulM�F�:�Sҿ��0�N��6�'c7�r���������f�`�/
gGs��b@p06�w0�2vt������W����z};;+�w���?9�;9[��@�3��i��7���
�?GE���@O�v#g����;�� ���_�F�6V�#c(Z[��)
d�w*��������O�"��?q��F��%��{��;����������9cR������omn������A��#����6�堣���������������D��o���+�;X������V������O�������3������s�+ѿ�i�D�$de)����o��_흔���R��H����?(�nOjz5��+�@`gb��?d�������N�nͿe���[�����J������sZ��m����i��m����W���ߢ�s��Q76v36�Z�ck�d����T��;<)����d8خ�Q����ƶ�7-l��R�6��i���}����@��p�͊�7��*Ǜ���q�����0�V�6�\5��zQjT��N�pwR^A��w���
���܏ȥ��ד��ajC,jBR]��9I��������P�-X�
6eN�ObNPX�H?�l^
�
 �V���^MV��O	Y'������ߑ��+�1.��L�/�}j���^N�I-�����Y�Л��'����6��M�7��o��1�m��'=Uf�1K�w;9<�~��
 ��|��#W����"*�>�w����5�� zѷ����_?F#�h�zݕ��������뾬	��Daܔ��֖x���3�	4v�_P���?2ք���γ��;�,f'+@��V��y��Ɂv(�މ���7Gf� q�}-W)��/�^�e�����k��*(|���Ɛ)��d��P>�,U���D�"w("Z��Q�D�xy�.Մ�0��.��'�6h¬N������&2�S
W���]*�N���=�׵�!ƒ�Y�� N�50�3��fEp�%��Z���j��k�\}�ʀ}�}͒P��s}�#U7�H�
����k����F���<�iβ��t�.4N?�7�{�v�A�1�Ѱ�)��D7��j��S,�8���I�����(�!�Z�&N|�,~E�� K�J�s/)#QcH���۝#��Kn��p���!=��X�������u�\&�
 5@Uc„7VC���Nx��a���ݻT��E	uFB�j5̘򻖅P����M{�o��	��e�`����ͰU����Ƀ�����
Le�rػ�#���J�쏗�U>���!+�x��p�|m��-Z�
@@ -6282,7 +6262,7 @@ D
 ��eI?�1k�����N���U~^����s���Ҥ�O��2N�#,��>������U�Q�?c"x�	�Km������A��|���X��鰭���DSZM�*,���^X䢨���xp{M�܎	]�2b
�h7�����k�<���.�`�Lˆ��lv �w§��;�w�xS(��N�51����K�|�RJ���7�����䠆��!��+�����[�u;r+��K��0��&-�_�RK��߸��^�&6b]A�d�2��4����:ӿ}��bR�ߩ;a��^�}����k�D�"<��}�]H����04(8�\�/���K��c���������\S��Y]�/��v�� 9x�D>b��^V�e������;Y��Q��o����[w��
5�]v�:Y�V����3k�Ҙ���qY6��D=ןv���i�_X�&�w���x��k?��j�c�@��:ػ�%���q���5%�)��M�7��e��0��!0��rW�b�o� �)mJ�
Hy�I*�r��"��
$X��
P[�@�(��<��sx`!�"L��4���f�L��}j!%��޿}��s(3ǩ�m���Ѓ�����"�k���	�� �#�ڡ��
�ɑ�kge8�ێGN�� �_��A��]�+�V��4}���:��5��d?����x�,�q��+������Q�����lQ?:�O��pi�%v�E`���aB�
 i��^jm�3����O3Ҥ�/v�+����E����CD��+ō2��3�W�-C�R*ݤ���9�d<�[����9�xu���i$�E�yZ�
 �t0�=�&A�_�39�M�䮩�����gF��@1Bz�*���.
-4:o��g��t2+,d�@w�/-���k���l�*��!�|�3����������c��7�lS��/����	�����������-��^r
�endstream
+4:o��g��t2+,d�@w�/-���k���l�*��!�|�3����������c��7�lS��/����	�����������-��'�
�endstream
 endobj
 604 0 obj <<
 /Type /Font
@@ -6291,14 +6271,14 @@ endobj
 /FirstChar 2
 /LastChar 216
 /Widths 1361 0 R
-/BaseFont /QLANNN+URWPalladioL-Roma
+/BaseFont /PFLJOO+URWPalladioL-Roma
 /FontDescriptor 602 0 R
 >> endobj
 602 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /QLANNN+URWPalladioL-Roma
+/FontName /PFLJOO+URWPalladioL-Roma
 /ItalicAngle 0
 /StemV 84
 /XHeight 469
@@ -6319,7 +6299,7 @@ endobj
 >>
 stream
 xڬzc�e߳eٶ�m�˶m۶mWuٶm�6���.����4�f>ͼ'����+W�ʽ�ވCF��L'hbod*fo�B�D��
PURW0��14������1
�5����	;��X�ۉ��r�MM"��ff@��������@�������,���<���w��������������_���ʦ�S����)@X^ASRN@).�
-7�3u2�
(��Xd,�M�M�f�N�[���L,�)͙�/��3���`jl�w������?.Z���������w��3������o\�
�v�6�&��k7��!'���}��]���,\�*���OC�r;[�u���F����Sҿ|a�z]-�
.�.��22�X:;�z�������_4\�-����
-�����������/�_���_u���
l<����_Q�������ƌ���oNc����-�`�I;3{��M\���f���Q�33TI����xLL�`��]��P���L�?'�����#�����'���;������C�����ښ�k�?����K��6���������Hu���C�t1��A;�b0�3����Y����D����`fh�K���ڙ�:�Xڙ�U�_��112�7�������?mg�7������W�g��S�V��?o��)�U�E���/��D���?��	�{��ؘ
t,�L�_>\,l�����b��������@�o�w�S��?����o0�v��&�̊��������O�?ncW'�������-�?��tSSSc��U{c�����.��y��"ڃ�L���eM*Ņ
��}��\Uu��ͳ�_�+�>���O��1l(��Lo
+7�3u2�
(��Xd,�M�M�f�N�[���L,�)͙�/��3���`jl�w������?.Z���������w��3������o\�
�v�6�&��k7��!'���}��]���,\�*���OC�r;[�u���F����Sҿ|a�z]-�
.�.��22�X:;�z�������_4\�-����
-�����������/�_���_u���
l<����_Q�������ƌ���oNc����-�`�I;3{��M\���f���Q�33TI����xLL�`��]��P���L�?'�����#�����'���;������C�����ښ�k�?����K��6���������Hu���C�t1��A;�b0�3����Y����D����`fh�K���ڙ�:�Xڙ�U�_��112�7�������?mg�7������W�gPWT���?o��)�U�E���/��D���?��	�{��ؘ
t,�L�_>\,l�����b��������@�o�w�S��?����o0�v��&�̊��������O�?ncW'�������-�?��tSSSc��U{c�����.��y��"ڃ�L���eM*Ņ
��}��\Uu��ͳ�_�+�>���O��1l(��Lo
 �|I�
 �wȻ8hN����3/�c�o�e�����N���J? �g�X��n�P����>; ��7ƣw#5����$O>��L1<16:�w>p�K�M��O���˯�Z)Z�L~ӑm�{��*��RƢ)�0=��g�\"nsY�{s�?��iE�vY���9��Η�5{���r=Fa����BL���J|��u�áq��x&��2�r&G-H.��"]pY������&�JtfR��E�N�����	x'Yӟ6t�����c7��#��J�5��+c��:v{y)��4��������V,��3�
 "+0Tj�kə����yF�6m��
�{� �ټ���b��B�}��n�E�t��tqx�xͤ�"�������#���h�<��&1��t��I0Õ�T�YR0�C���Ɂz�g�ڢ�!�9d�n
����g0.��c�	��h��Zd�{yz�J����I�\�\����
@@ -6426,7 +6406,7 @@ L
 6_m�q'2~��=aF���М�?�	�Z�._|;l[�OX��J�+QG�i�ZɏP&Yyf2
�<�
�r�G�75���3��#z�FF⨾��F4�N��5�c��6P���e�	��k��u_K���L�*���0MH�Cr�T>�㇟x
 F��R�B_!�i�N�%$h�]t�������s���=n��<�����Y����QK���gF==�3���sC�G��!Y�
W�a�Š	+��Y�]�h��!{�#i���"����4bw�Z�X�2&��.�l=b,	�,�l<a�r�7�')�͋RQ�.)�2�.�я
��r�u��)R�\-C�"
 �{0���eh饑@�s����V>��A��G��5W0!��B�V\��6���ߥ�����;RЭ$��v(�@�ICM��v��_��/#	�
 ���������2�6�w��{0��+/6A3C�X	���?
����<ۈUë�"��R2��6�O�i�Ʒ:+t��;��fn��
-�0�jT���q�]����'DY�
�.g���¨�;AJҴ��ͭ[��H�aA@�� ?�J�A�tI�%[ح$ҍ�"ɾs��?���S;sc7G{c[��
���endstream
+�0�jT���q�]����'DY�
�.g���¨�;AJҴ��ͭ[��H�aA@�� ?�J�A�tI�%[ح$ҍ�"ɾs��?���S;sc7G{c[��

��endstream
 endobj
 601 0 obj <<
 /Type /Font
@@ -6435,14 +6415,14 @@ endobj
 /FirstChar 2
 /LastChar 151
 /Widths 1362 0 R
-/BaseFont /INPKTB+URWPalladioL-Bold
+/BaseFont /WEGQVN+URWPalladioL-Bold
 /FontDescriptor 599 0 R
 >> endobj
 599 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /INPKTB+URWPalladioL-Bold
+/FontName /WEGQVN+URWPalladioL-Bold
 /ItalicAngle 0
 /StemV 123
 /XHeight 471
@@ -6506,7 +6486,7 @@ endobj
 /Type /Pages
 /Count 6
 /Parent 1364 0 R
-/Kids [988 0 R 993 0 R 1002 0 R 1007 0 R 1015 0 R 1022 0 R]
+/Kids [988 0 R 993 0 R 1001 0 R 1007 0 R 1015 0 R 1022 0 R]
 >> endobj
 1035 0 obj <<
 /Type /Pages
@@ -7631,7 +7611,7 @@ endobj
 /Count -4
 >> endobj
 1368 0 obj <<
-/Names [(Access_Control_Lists) 1185 0 R (Bv9ARM.ch01) 617 0 R (Bv9ARM.ch02) 671 0 R (Bv9ARM.ch03) 686 0 R (Bv9ARM.ch04) 734 0 R (Bv9ARM.ch05) 819 0 R (Bv9ARM.ch06) 831 0 R (Bv9ARM.ch07) 1184 0 R (Bv9ARM.ch08) 1203 0 R (Bv9ARM.ch09) 1218 0 R (Configuration_File_Grammar) 855 0 R (DNSSEC) 787 0 R (Doc-Start) 598 0 R (Setting_TTLs) 1152 0 R (access_control) 970 0 R (acl) 863 0 R (address_match_lists) 836 0 R (admin_tools) 708 0 R (appendix.A) 558 0 R (bibliography) 1234 0 R (boolean_options) 740 0 R (builtin) 1031 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 514 0 R (chapter.8) 538 0 R (cite.RFC1034) 1244 0 R (cite.RFC1035) 1246 0 R (cite.RFC1101) 1302 0 R (cite.RFC1123) 1304 0 R (cite.RFC1183) 1286 0 R (cite.RFC1464) 1322 0 R (cite.RFC1535) 1273 0 R (cite.RFC1536) 1275 0 R (cite.RFC1537) 1312 0 R (cite.RFC1591) 1306 0 R (cite.RFC1706) 1288 0 R (cite.RFC1712) 1336 0 R (cite.RFC1713) 1324 0 R (cite.RFC1794) 1326 0 R (cite.RFC1876) 1290 0 R (cite.RFC1886) 1265 0 R (cite.RFC1912) 1314 0 R (cite.RFC1982) 1277 0 R (cite.RFC1995) 1251 0 R (cite.RFC1996) 1253 0 R (cite.RFC2010) 1316 0 R (cite.RFC2052) 1292 0 R (cite.RFC2065) 1267 0 R (cite.RFC2136) 1255 0 R (cite.RFC2137) 1269 0 R (cite.RFC2163) 1294 0 R (cite.RFC2168) 1296 0 R (cite.RFC2181) 1257 0 R (cite.RFC2219) 1318 0 R (cite.RFC2230) 1298 0 R (cite.RFC2240) 1328 0 R (cite.RFC2308) 1259 0 R (cite.RFC2317) 1308 0 R (cite.RFC2345) 1330 0 R (cite.RFC2352) 1332 0 R (cite.RFC2845) 1261 0 R (cite.RFC974) 1248 0 R (cite.id2492151) 1345 0 R (configuration_file_elements) 832 0 R (controls_statement_definition_and_usage) 722 0 R (diagnostic_tools) 659 0 R (dynamic_update) 738 0 R (dynamic_update_policies) 779 0 R (dynamic_update_security) 974 0 R (historical_dns_information) 1225 0 R (id2465952) 643 0 R (id2466044) 619 0 R (id2466730) 623 0 R (id2466739) 624 0 R (id2466914) 639 0 R (id2467034) 618 0 R (id2467398) 641 0 R (id2467418) 642 0 R (id2467436) 996 0 R (id2467452) 997 0 R (id2467554) 999 0 R (id2467742) 646 0 R (id2467817) 653 0 R (id2467840) 656 0 R (id2467861) 657 0 R (id2467880) 658 0 R (id2467977) 664 0 R (id2468009) 665 0 R (id2468035) 666 0 R (id2468135) 672 0 R (id2468160) 673 0 R (id2468170) 674 0 R (id2468184) 675 0 R (id2468193) 681 0 R (id2468224) 688 0 R (id2468240) 689 0 R (id2468330) 694 0 R (id2468346) 695 0 R (id2468613) 698 0 R (id2468618) 699 0 R (id2469880) 727 0 R (id2469892) 728 0 R (id2470305) 749 0 R (id2470322) 750 0 R (id2470869) 766 0 R (id2470885) 767 0 R (id2470919) 768 0 R (id2470935) 774 0 R (id2470944) 775 0 R (id2470983) 776 0 R (id2471035) 777 0 R (id2471147) 784 0 R (id2471161) 785 0 R (id2471210) 786 0 R (id2471413) 792 0 R (id2471480) 793 0 R (id2471623) 794 0 R (id2471692) 810 0 R (id2471819) 812 0 R (id2471840) 813 0 R (id2471940) 820 0 R (id2472078) 833 0 R (id2472779) 841 0 R (id2472806) 842 0 R (id2472968) 847 0 R (id2472983) 848 0 R (id2473012) 849 0 R (id2473089) 856 0 R (id2473658) 862 0 R (id2473700) 864 0 R (id2473827) 866 0 R (id2474104) 874 0 R (id2474121) 875 0 R (id2474144) 876 0 R (id2474167) 877 0 R (id2474238) 886 0 R (id2474433) 887 0 R (id2474553) 888 0 R (id2475111) 903 0 R (id2475571) 909 0 R (id2475643) 910 0 R (id2475774) 918 0 R (id2475818) 919 0 R (id2475833) 920 0 R (id2477449) 940 0 R (id2478728) 962 0 R (id2478778) 964 0 R (id2478957) 973 0 R (id2479114) 979 0 R (id2482003) 1005 0 R (id2482477) 1019 0 R (id2482944) 1033 0 R (id2483640) 1048 0 R (id2483690) 1049 0 R (id2483774) 1055 0 R (id2484992) 1068 0 R (id2484998) 1069 0 R (id2485002) 1070 0 R (id2485236) 1077 0 R (id2485403) 1078 0 R (id2486371) 1115 0 R (id2486530) 1117 0 R (id2486548) 1118 0 R (id2486569) 1121 0 R (id2486777) 1127 0 R (id2487428) 1133 0 R (id2487537) 1135 0 R (id2487558) 1141 0 R (id2487915) 1143 0 R (id2488030) 1145 0 R (id2488049) 1146 0 R (id2488354) 1153 0 R (id2488528) 1155 0 R (id2488541) 1156 0 R (id2488633) 1158 0 R (id2488652) 1159 0 R (id2488708) 1167 0 R (id2488771) 1168 0 R (id2488802) 1169 0 R (id2488862) 1174 0 R (id2489260) 1196 0 R (id2489336) 1197 0 R (id2489394) 1198 0 R (id2489601) 1204 0 R (id2489606) 1205 0 R (id2489618) 1206 0 R (id2489635) 1207 0 R (id2489833) 1219 0 R (id2489838) 1220 0 R (id2489972) 1226 0 R (id2490352) 1228 0 R (id2490628) 1240 0 R (id2490630) 1242 0 R (id2490638) 1247 0 R (id2490730) 1243 0 R (id2490754) 1245 0 R (id2490791) 1256 0 R (id2490817) 1258 0 R (id2490842) 1250 0 R (id2490867) 1252 0 R (id2490890) 1254 0 R (id2490946) 1260 0 R (id2491006) 1263 0 R (id2491021) 1264 0 R (id2491060) 1266 0 R (id2491099) 1268 0 R (id2491127) 1271 0 R (id2491136) 1272 0 R (id2491161) 1274 0 R (id2491228) 1276 0 R (id2491265) 1284 0 R (id2491270) 1285 0 R (id2491328) 1287 0 R (id2491365) 1295 0 R (id2491400) 1289 0 R (id2491454) 1291 0 R (id2491494) 1293 0 R (id2491521) 1297 0 R (id2491547) 1300 0 R (id2491555) 1301 0 R (id2491580) 1303 0 R (id2491604) 1305 0 R (id2491625) 1307 0 R (id2491740) 1310 0 R (id2491748) 1311 0 R (id2491773) 1313 0 R (id2491800) 1315 0 R (id2491836) 1317 0 R (id2491876) 1320 0 R (id2491896) 1321 0 R (id2491918) 1323 0 R (id2491943) 1325 0 R (id2491968) 1327 0 R (id2491990) 1329 0 R (id2492036) 1331 0 R (id2492060) 1334 0 R (id2492067) 1335 0 R (id2492139) 1342 0 R (id2492149) 1344 0 R (id2492151) 1346 0 R (incremental_zone_transfers) 746 0 R (internet_drafts) 1341 0 R (ipv6addresses) 814 0 R (journal) 739 0 R (lwresd) 821 0 R (notify) 735 0 R (options) 929 0 R (page.1) 597 0 R (page.10) 693 0 R (page.11) 704 0 R (page.12) 712 0 R (page.13) 719 0 R (page.14) 726 0 R (page.15) 733 0 R (page.16) 745 0 R (page.17) 755 0 R (page.18) 760 0 R (page.19) 764 0 R (page.2) 609 0 R (page.20) 773 0 R (page.21) 783 0 R (page.22) 791 0 R (page.23) 799 0 R (page.24) 809 0 R (page.25) 818 0 R (page.26) 826 0 R (page.27) 830 0 R (page.28) 840 0 R (page.29) 846 0 R (page.3) 616 0 R (page.30) 854 0 R (page.31) 861 0 R (page.32) 871 0 R (page.33) 885 0 R (page.34) 892 0 R (page.35) 896 0 R (page.36) 902 0 R (page.37) 908 0 R (page.38) 917 0 R (page.39) 924 0 R (page.4) 635 0 R (page.40) 928 0 R (page.41) 933 0 R (page.42) 939 0 R (page.43) 945 0 R (page.44) 955 0 R (page.45) 961 0 R (page.46) 969 0 R (page.47) 978 0 R (page.48) 986 0 R (page.49) 990 0 R (page.5) 652 0 R (page.50) 995 0 R (page.51) 1004 0 R (page.52) 1009 0 R (page.53) 1017 0 R (page.54) 1024 0 R (page.55) 1030 0 R (page.56) 1040 0 R (page.57) 1045 0 R (page.58) 1054 0 R (page.59) 1059 0 R (page.6) 663 0 R (page.60) 1063 0 R (page.61) 1067 0 R (page.62) 1076 0 R (page.63) 1088 0 R (page.64) 1098 0 R (page.65) 1114 0 R (page.66) 1126 0 R (page.67) 1132 0 R (page.68) 1140 0 R (page.69) 1151 0 R (page.7) 670 0 R (page.70) 1163 0 R (page.71) 1173 0 R (page.72) 1179 0 R (page.73) 1183 0 R (page.74) 1192 0 R (page.75) 1202 0 R (page.76) 1213 0 R (page.77) 1217 0 R (page.78) 1224 0 R (page.79) 1233 0 R (page.8) 680 0 R (page.80) 1282 0 R (page.81) 1340 0 R (page.9) 685 0 R (proposed_standards) 751 0 R (rfcs) 648 0 R (rndc) 881 0 R (rrset_ordering) 700 0 R (sample_configuration) 687 0 R (section*.1) 1239 0 R (section*.10) 1333 0 R (section*.11) 1343 0 R (section*.2) 1241 0 R (section*.3) 1249 0 R (section*.4) 1262 0 R (section*.5) 1270 0 R (section*.6) 1283 0 R (section*.7) 1299 0 R (section*.8) 1309 0 R (section*.9) 1319 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 466 0 R (section.7.1) 518 0 R (section.7.2) 522 0 R (section.7.3) 534 0 R (section.8.1) 542 0 R (section.8.2) 550 0 R (section.8.3) 554 0 R (section.A.1) 562 0 R (section.A.2) 570 0 R (section.A.3) 578 0 R (server_statement_definition_and_usage) 951 0 R (server_statement_grammar) 1041 0 R (statsfile) 935 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 326 0 R (subsection.6.2.12) 330 0 R (subsection.6.2.13) 334 0 R (subsection.6.2.14) 338 0 R (subsection.6.2.15) 342 0 R (subsection.6.2.16) 346 0 R (subsection.6.2.17) 418 0 R (subsection.6.2.18) 422 0 R (subsection.6.2.19) 426 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 430 0 R (subsection.6.2.21) 434 0 R (subsection.6.2.22) 438 0 R (subsection.6.2.23) 442 0 R (subsection.6.2.24) 446 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 470 0 R (subsection.6.3.2) 482 0 R (subsection.6.3.3) 486 0 R (subsection.6.3.4) 490 0 R (subsection.6.3.5) 494 0 R (subsection.6.3.6) 510 0 R (subsection.7.2.1) 526 0 R (subsection.7.2.2) 530 0 R (subsection.8.1.1) 546 0 R (subsection.A.1.1) 566 0 R (subsection.A.2.1) 574 0 R (subsection.A.3.1) 582 0 R (subsection.A.3.2) 586 0 R (subsection.A.3.3) 590 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.16.1) 350 0 R (subsubsection.6.2.16.10) 386 0 R (subsubsection.6.2.16.11) 390 0 R (subsubsection.6.2.16.12) 394 0 R (subsubsection.6.2.16.13) 398 0 R (subsubsection.6.2.16.14) 402 0 R (subsubsection.6.2.16.15) 406 0 R (subsubsection.6.2.16.16) 410 0 R (subsubsection.6.2.16.17) 414 0 R (subsubsection.6.2.16.2) 354 0 R (subsubsection.6.2.16.3) 358 0 R (subsubsection.6.2.16.4) 362 0 R (subsubsection.6.2.16.5) 366 0 R (subsubsection.6.2.16.6) 370 0 R (subsubsection.6.2.16.7) 374 0 R (subsubsection.6.2.16.8) 378 0 R (subsubsection.6.2.16.9) 382 0 R (subsubsection.6.2.24.1) 450 0 R (subsubsection.6.2.24.2) 454 0 R (subsubsection.6.2.24.3) 458 0 R (subsubsection.6.2.24.4) 462 0 R (subsubsection.6.3.1.1) 474 0 R (subsubsection.6.3.1.2) 478 0 R (subsubsection.6.3.5.1) 498 0 R (subsubsection.6.3.5.2) 502 0 R (subsubsection.6.3.5.3) 506 0 R (table.1.1) 625 0 R (table.1.2) 640 0 R (table.3.1) 696 0 R (table.3.2) 729 0 R (table.6.1) 834 0 R (table.6.10) 1122 0 R (table.6.11) 1128 0 R (table.6.12) 1134 0 R (table.6.13) 1142 0 R (table.6.14) 1144 0 R (table.6.15) 1147 0 R (table.6.16) 1154 0 R (table.6.17) 1157 0 R (table.6.18) 1175 0 R (table.6.2) 857 0 R (table.6.3) 865 0 R (table.6.4) 904 0 R (table.6.5) 941 0 R (table.6.6) 1020 0 R (table.6.7) 1034 0 R (table.6.8) 1071 0 R (table.6.9) 1116 0 R (table.A.1) 1227 0 R (table.A.2) 1229 0 R (the_category_phrase) 898 0 R (the_sortlist_statement) 1011 0 R (topology) 1010 0 R (tsig) 765 0 R (tuning) 1025 0 R (types_of_resource_records_and_when_to_use_them) 647 0 R (view_statement_grammar) 1036 0 R (zone_statement_grammar) 965 0 R (zone_transfers) 741 0 R]
+/Names [(Access_Control_Lists) 1185 0 R (Bv9ARM.ch01) 617 0 R (Bv9ARM.ch02) 671 0 R (Bv9ARM.ch03) 686 0 R (Bv9ARM.ch04) 734 0 R (Bv9ARM.ch05) 819 0 R (Bv9ARM.ch06) 831 0 R (Bv9ARM.ch07) 1184 0 R (Bv9ARM.ch08) 1203 0 R (Bv9ARM.ch09) 1218 0 R (Configuration_File_Grammar) 855 0 R (DNSSEC) 787 0 R (Doc-Start) 598 0 R (Setting_TTLs) 1152 0 R (access_control) 970 0 R (acl) 863 0 R (address_match_lists) 836 0 R (admin_tools) 708 0 R (appendix.A) 558 0 R (bibliography) 1234 0 R (boolean_options) 740 0 R (builtin) 1031 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 514 0 R (chapter.8) 538 0 R (cite.RFC1034) 1244 0 R (cite.RFC1035) 1246 0 R (cite.RFC1101) 1302 0 R (cite.RFC1123) 1304 0 R (cite.RFC1183) 1286 0 R (cite.RFC1464) 1322 0 R (cite.RFC1535) 1273 0 R (cite.RFC1536) 1275 0 R (cite.RFC1537) 1312 0 R (cite.RFC1591) 1306 0 R (cite.RFC1706) 1288 0 R (cite.RFC1712) 1336 0 R (cite.RFC1713) 1324 0 R (cite.RFC1794) 1326 0 R (cite.RFC1876) 1290 0 R (cite.RFC1886) 1265 0 R (cite.RFC1912) 1314 0 R (cite.RFC1982) 1277 0 R (cite.RFC1995) 1251 0 R (cite.RFC1996) 1253 0 R (cite.RFC2010) 1316 0 R (cite.RFC2052) 1292 0 R (cite.RFC2065) 1267 0 R (cite.RFC2136) 1255 0 R (cite.RFC2137) 1269 0 R (cite.RFC2163) 1294 0 R (cite.RFC2168) 1296 0 R (cite.RFC2181) 1257 0 R (cite.RFC2219) 1318 0 R (cite.RFC2230) 1298 0 R (cite.RFC2240) 1328 0 R (cite.RFC2308) 1259 0 R (cite.RFC2317) 1308 0 R (cite.RFC2345) 1330 0 R (cite.RFC2352) 1332 0 R (cite.RFC2845) 1261 0 R (cite.RFC974) 1248 0 R (cite.id2492088) 1345 0 R (configuration_file_elements) 832 0 R (controls_statement_definition_and_usage) 722 0 R (diagnostic_tools) 659 0 R (dynamic_update) 738 0 R (dynamic_update_policies) 779 0 R (dynamic_update_security) 974 0 R (historical_dns_information) 1225 0 R (id2465952) 643 0 R (id2466044) 619 0 R (id2466730) 623 0 R (id2466739) 624 0 R (id2466914) 639 0 R (id2467034) 618 0 R (id2467398) 641 0 R (id2467418) 642 0 R (id2467442) 996 0 R (id2467458) 997 0 R (id2467559) 999 0 R (id2467742) 646 0 R (id2467817) 653 0 R (id2467840) 656 0 R (id2467861) 657 0 R (id2467880) 658 0 R (id2467977) 664 0 R (id2468009) 665 0 R (id2468035) 666 0 R (id2468135) 672 0 R (id2468160) 673 0 R (id2468170) 674 0 R (id2468184) 675 0 R (id2468193) 681 0 R (id2468224) 688 0 R (id2468240) 689 0 R (id2468330) 694 0 R (id2468346) 695 0 R (id2468613) 698 0 R (id2468618) 699 0 R (id2469880) 727 0 R (id2469892) 728 0 R (id2470305) 749 0 R (id2470322) 750 0 R (id2470869) 766 0 R (id2470885) 767 0 R (id2470919) 768 0 R (id2470935) 774 0 R (id2470944) 775 0 R (id2470983) 776 0 R (id2471035) 777 0 R (id2471147) 784 0 R (id2471161) 785 0 R (id2471210) 786 0 R (id2471413) 792 0 R (id2471480) 793 0 R (id2471623) 794 0 R (id2471692) 810 0 R (id2471819) 812 0 R (id2471840) 813 0 R (id2471940) 820 0 R (id2472078) 833 0 R (id2472779) 841 0 R (id2472806) 842 0 R (id2472968) 847 0 R (id2472983) 848 0 R (id2473012) 849 0 R (id2473089) 856 0 R (id2473658) 862 0 R (id2473700) 864 0 R (id2473827) 866 0 R (id2474104) 874 0 R (id2474121) 875 0 R (id2474144) 876 0 R (id2474167) 877 0 R (id2474238) 886 0 R (id2474433) 887 0 R (id2474553) 888 0 R (id2475111) 903 0 R (id2475571) 909 0 R (id2475643) 910 0 R (id2475774) 918 0 R (id2475818) 919 0 R (id2475833) 920 0 R (id2477449) 940 0 R (id2478728) 962 0 R (id2478778) 964 0 R (id2478957) 973 0 R (id2479114) 979 0 R (id2482008) 1005 0 R (id2482414) 1019 0 R (id2482881) 1033 0 R (id2483577) 1048 0 R (id2483627) 1049 0 R (id2483712) 1055 0 R (id2484997) 1068 0 R (id2485003) 1069 0 R (id2485008) 1070 0 R (id2485309) 1077 0 R (id2485477) 1078 0 R (id2486444) 1115 0 R (id2486603) 1117 0 R (id2486621) 1118 0 R (id2486643) 1121 0 R (id2486782) 1127 0 R (id2487433) 1133 0 R (id2487542) 1135 0 R (id2487563) 1141 0 R (id2487921) 1143 0 R (id2488036) 1145 0 R (id2488054) 1146 0 R (id2488359) 1153 0 R (id2488465) 1155 0 R (id2488478) 1156 0 R (id2488570) 1158 0 R (id2488589) 1159 0 R (id2488645) 1167 0 R (id2488708) 1168 0 R (id2488739) 1169 0 R (id2488800) 1174 0 R (id2489197) 1196 0 R (id2489410) 1197 0 R (id2489467) 1198 0 R (id2489606) 1204 0 R (id2489611) 1205 0 R (id2489623) 1206 0 R (id2489640) 1207 0 R (id2489702) 1219 0 R (id2489707) 1220 0 R (id2490045) 1226 0 R (id2490357) 1228 0 R (id2490633) 1240 0 R (id2490635) 1242 0 R (id2490644) 1247 0 R (id2490667) 1243 0 R (id2490691) 1245 0 R (id2490728) 1256 0 R (id2490754) 1258 0 R (id2490779) 1250 0 R (id2490804) 1252 0 R (id2490827) 1254 0 R (id2490883) 1260 0 R (id2490944) 1263 0 R (id2490958) 1264 0 R (id2490997) 1266 0 R (id2491036) 1268 0 R (id2491064) 1271 0 R (id2491073) 1272 0 R (id2491098) 1274 0 R (id2491165) 1276 0 R (id2491202) 1284 0 R (id2491207) 1285 0 R (id2491265) 1287 0 R (id2491302) 1295 0 R (id2491337) 1289 0 R (id2491392) 1291 0 R (id2491431) 1293 0 R (id2491458) 1297 0 R (id2491484) 1300 0 R (id2491492) 1301 0 R (id2491517) 1303 0 R (id2491541) 1305 0 R (id2491562) 1307 0 R (id2491677) 1310 0 R (id2491685) 1311 0 R (id2491710) 1313 0 R (id2491737) 1315 0 R (id2491773) 1317 0 R (id2491813) 1320 0 R (id2491833) 1321 0 R (id2491856) 1323 0 R (id2491880) 1325 0 R (id2491905) 1327 0 R (id2491927) 1329 0 R (id2491973) 1331 0 R (id2491997) 1334 0 R (id2492004) 1335 0 R (id2492076) 1342 0 R (id2492086) 1344 0 R (id2492088) 1346 0 R (incremental_zone_transfers) 746 0 R (internet_drafts) 1341 0 R (ipv6addresses) 814 0 R (journal) 739 0 R (lwresd) 821 0 R (notify) 735 0 R (options) 929 0 R (page.1) 597 0 R (page.10) 693 0 R (page.11) 704 0 R (page.12) 712 0 R (page.13) 719 0 R (page.14) 726 0 R (page.15) 733 0 R (page.16) 745 0 R (page.17) 755 0 R (page.18) 760 0 R (page.19) 764 0 R (page.2) 609 0 R (page.20) 773 0 R (page.21) 783 0 R (page.22) 791 0 R (page.23) 799 0 R (page.24) 809 0 R (page.25) 818 0 R (page.26) 826 0 R (page.27) 830 0 R (page.28) 840 0 R (page.29) 846 0 R (page.3) 616 0 R (page.30) 854 0 R (page.31) 861 0 R (page.32) 871 0 R (page.33) 885 0 R (page.34) 892 0 R (page.35) 896 0 R (page.36) 902 0 R (page.37) 908 0 R (page.38) 917 0 R (page.39) 924 0 R (page.4) 635 0 R (page.40) 928 0 R (page.41) 933 0 R (page.42) 939 0 R (page.43) 945 0 R (page.44) 955 0 R (page.45) 961 0 R (page.46) 969 0 R (page.47) 978 0 R (page.48) 986 0 R (page.49) 990 0 R (page.5) 652 0 R (page.50) 995 0 R (page.51) 1003 0 R (page.52) 1009 0 R (page.53) 1017 0 R (page.54) 1024 0 R (page.55) 1030 0 R (page.56) 1040 0 R (page.57) 1045 0 R (page.58) 1054 0 R (page.59) 1059 0 R (page.6) 663 0 R (page.60) 1063 0 R (page.61) 1067 0 R (page.62) 1076 0 R (page.63) 1088 0 R (page.64) 1098 0 R (page.65) 1114 0 R (page.66) 1126 0 R (page.67) 1132 0 R (page.68) 1140 0 R (page.69) 1151 0 R (page.7) 670 0 R (page.70) 1163 0 R (page.71) 1173 0 R (page.72) 1179 0 R (page.73) 1183 0 R (page.74) 1192 0 R (page.75) 1202 0 R (page.76) 1213 0 R (page.77) 1217 0 R (page.78) 1224 0 R (page.79) 1233 0 R (page.8) 680 0 R (page.80) 1282 0 R (page.81) 1340 0 R (page.9) 685 0 R (proposed_standards) 751 0 R (rfcs) 648 0 R (rndc) 881 0 R (rrset_ordering) 700 0 R (sample_configuration) 687 0 R (section*.1) 1239 0 R (section*.10) 1333 0 R (section*.11) 1343 0 R (section*.2) 1241 0 R (section*.3) 1249 0 R (section*.4) 1262 0 R (section*.5) 1270 0 R (section*.6) 1283 0 R (section*.7) 1299 0 R (section*.8) 1309 0 R (section*.9) 1319 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 466 0 R (section.7.1) 518 0 R (section.7.2) 522 0 R (section.7.3) 534 0 R (section.8.1) 542 0 R (section.8.2) 550 0 R (section.8.3) 554 0 R (section.A.1) 562 0 R (section.A.2) 570 0 R (section.A.3) 578 0 R (server_statement_definition_and_usage) 951 0 R (server_statement_grammar) 1041 0 R (statsfile) 935 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 326 0 R (subsection.6.2.12) 330 0 R (subsection.6.2.13) 334 0 R (subsection.6.2.14) 338 0 R (subsection.6.2.15) 342 0 R (subsection.6.2.16) 346 0 R (subsection.6.2.17) 418 0 R (subsection.6.2.18) 422 0 R (subsection.6.2.19) 426 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 430 0 R (subsection.6.2.21) 434 0 R (subsection.6.2.22) 438 0 R (subsection.6.2.23) 442 0 R (subsection.6.2.24) 446 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 470 0 R (subsection.6.3.2) 482 0 R (subsection.6.3.3) 486 0 R (subsection.6.3.4) 490 0 R (subsection.6.3.5) 494 0 R (subsection.6.3.6) 510 0 R (subsection.7.2.1) 526 0 R (subsection.7.2.2) 530 0 R (subsection.8.1.1) 546 0 R (subsection.A.1.1) 566 0 R (subsection.A.2.1) 574 0 R (subsection.A.3.1) 582 0 R (subsection.A.3.2) 586 0 R (subsection.A.3.3) 590 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.16.1) 350 0 R (subsubsection.6.2.16.10) 386 0 R (subsubsection.6.2.16.11) 390 0 R (subsubsection.6.2.16.12) 394 0 R (subsubsection.6.2.16.13) 398 0 R (subsubsection.6.2.16.14) 402 0 R (subsubsection.6.2.16.15) 406 0 R (subsubsection.6.2.16.16) 410 0 R (subsubsection.6.2.16.17) 414 0 R (subsubsection.6.2.16.2) 354 0 R (subsubsection.6.2.16.3) 358 0 R (subsubsection.6.2.16.4) 362 0 R (subsubsection.6.2.16.5) 366 0 R (subsubsection.6.2.16.6) 370 0 R (subsubsection.6.2.16.7) 374 0 R (subsubsection.6.2.16.8) 378 0 R (subsubsection.6.2.16.9) 382 0 R (subsubsection.6.2.24.1) 450 0 R (subsubsection.6.2.24.2) 454 0 R (subsubsection.6.2.24.3) 458 0 R (subsubsection.6.2.24.4) 462 0 R (subsubsection.6.3.1.1) 474 0 R (subsubsection.6.3.1.2) 478 0 R (subsubsection.6.3.5.1) 498 0 R (subsubsection.6.3.5.2) 502 0 R (subsubsection.6.3.5.3) 506 0 R (table.1.1) 625 0 R (table.1.2) 640 0 R (table.3.1) 696 0 R (table.3.2) 729 0 R (table.6.1) 834 0 R (table.6.10) 1122 0 R (table.6.11) 1128 0 R (table.6.12) 1134 0 R (table.6.13) 1142 0 R (table.6.14) 1144 0 R (table.6.15) 1147 0 R (table.6.16) 1154 0 R (table.6.17) 1157 0 R (table.6.18) 1175 0 R (table.6.2) 857 0 R (table.6.3) 865 0 R (table.6.4) 904 0 R (table.6.5) 941 0 R (table.6.6) 1020 0 R (table.6.7) 1034 0 R (table.6.8) 1071 0 R (table.6.9) 1116 0 R (table.A.1) 1227 0 R (table.A.2) 1229 0 R (the_category_phrase) 898 0 R (the_sortlist_statement) 1011 0 R (topology) 1010 0 R (tsig) 765 0 R (tuning) 1025 0 R (types_of_resource_records_and_when_to_use_them) 647 0 R (view_statement_grammar) 1036 0 R (zone_statement_grammar) 965 0 R (zone_transfers) 741 0 R]
 /Limits [(Access_Control_Lists) (zone_transfers)]
 >> endobj
 1369 0 obj <<
@@ -7650,7 +7630,7 @@ endobj
 >> endobj
 1372 0 obj <<
 /Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords()
-/CreationDate (D:20080403035022Z)
+/CreationDate (D:20080527222349Z)
 /PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)
 >> endobj
 xref
@@ -7662,591 +7642,591 @@ xref
 0000000000 00000 f 
 0000000009 00000 n 
 0000018969 00000 n 
-0000491464 00000 n 
+0000491721 00000 n 
 0000000054 00000 n 
 0000000086 00000 n 
 0000019093 00000 n 
-0000491392 00000 n 
+0000491649 00000 n 
 0000000133 00000 n 
 0000000173 00000 n 
 0000019218 00000 n 
-0000491306 00000 n 
+0000491563 00000 n 
 0000000221 00000 n 
 0000000273 00000 n 
 0000019343 00000 n 
-0000491220 00000 n 
+0000491477 00000 n 
 0000000321 00000 n 
 0000000377 00000 n 
 0000023633 00000 n 
-0000491110 00000 n 
+0000491367 00000 n 
 0000000425 00000 n 
 0000000478 00000 n 
 0000023758 00000 n 
-0000491036 00000 n 
+0000491293 00000 n 
 0000000531 00000 n 
 0000000572 00000 n 
 0000023883 00000 n 
-0000490949 00000 n 
+0000491206 00000 n 
 0000000625 00000 n 
 0000000674 00000 n 
 0000024008 00000 n 
-0000490862 00000 n 
+0000491119 00000 n 
 0000000727 00000 n 
 0000000757 00000 n 
 0000028318 00000 n 
-0000490738 00000 n 
+0000490995 00000 n 
 0000000810 00000 n 
 0000000861 00000 n 
 0000028443 00000 n 
-0000490664 00000 n 
+0000490921 00000 n 
 0000000919 00000 n 
 0000000964 00000 n 
 0000028568 00000 n 
-0000490577 00000 n 
+0000490834 00000 n 
 0000001022 00000 n 
 0000001062 00000 n 
 0000028693 00000 n 
-0000490503 00000 n 
+0000490760 00000 n 
 0000001120 00000 n 
 0000001162 00000 n 
 0000031606 00000 n 
-0000490379 00000 n 
+0000490636 00000 n 
 0000001215 00000 n 
 0000001260 00000 n 
 0000031731 00000 n 
-0000490318 00000 n 
+0000490575 00000 n 
 0000001318 00000 n 
 0000001355 00000 n 
 0000031856 00000 n 
-0000490244 00000 n 
+0000490501 00000 n 
 0000001408 00000 n 
 0000001463 00000 n 
 0000034244 00000 n 
-0000490119 00000 n 
+0000490376 00000 n 
 0000001509 00000 n 
 0000001556 00000 n 
 0000034369 00000 n 
-0000490045 00000 n 
+0000490302 00000 n 
 0000001604 00000 n 
 0000001648 00000 n 
 0000034494 00000 n 
-0000489958 00000 n 
+0000490215 00000 n 
 0000001696 00000 n 
 0000001735 00000 n 
 0000034617 00000 n 
-0000489871 00000 n 
+0000490128 00000 n 
 0000001783 00000 n 
 0000001825 00000 n 
 0000034741 00000 n 
-0000489784 00000 n 
+0000490041 00000 n 
 0000001873 00000 n 
 0000001936 00000 n 
 0000035777 00000 n 
-0000489710 00000 n 
+0000489967 00000 n 
 0000001984 00000 n 
 0000002034 00000 n 
 0000037455 00000 n 
-0000489582 00000 n 
+0000489839 00000 n 
 0000002080 00000 n 
 0000002126 00000 n 
 0000037579 00000 n 
-0000489469 00000 n 
+0000489726 00000 n 
 0000002174 00000 n 
 0000002218 00000 n 
 0000037704 00000 n 
-0000489393 00000 n 
+0000489650 00000 n 
 0000002271 00000 n 
 0000002323 00000 n 
 0000037829 00000 n 
-0000489316 00000 n 
+0000489573 00000 n 
 0000002377 00000 n 
 0000002436 00000 n 
 0000040461 00000 n 
-0000489225 00000 n 
+0000489482 00000 n 
 0000002485 00000 n 
 0000002523 00000 n 
 0000040712 00000 n 
-0000489108 00000 n 
+0000489365 00000 n 
 0000002572 00000 n 
 0000002618 00000 n 
 0000040838 00000 n 
-0000488990 00000 n 
+0000489247 00000 n 
 0000002672 00000 n 
 0000002739 00000 n 
 0000044023 00000 n 
-0000488911 00000 n 
+0000489168 00000 n 
 0000002798 00000 n 
 0000002842 00000 n 
 0000044149 00000 n 
-0000488832 00000 n 
+0000489089 00000 n 
 0000002901 00000 n 
 0000002949 00000 n 
 0000054288 00000 n 
-0000488753 00000 n 
+0000489010 00000 n 
 0000003003 00000 n 
 0000003036 00000 n 
 0000057561 00000 n 
-0000488621 00000 n 
+0000488878 00000 n 
 0000003083 00000 n 
 0000003126 00000 n 
 0000057687 00000 n 
-0000488542 00000 n 
+0000488799 00000 n 
 0000003175 00000 n 
 0000003205 00000 n 
 0000057813 00000 n 
-0000488410 00000 n 
+0000488667 00000 n 
 0000003254 00000 n 
 0000003292 00000 n 
 0000057938 00000 n 
-0000488345 00000 n 
+0000488602 00000 n 
 0000003346 00000 n 
 0000003388 00000 n 
 0000062257 00000 n 
-0000488252 00000 n 
+0000488509 00000 n 
 0000003437 00000 n 
 0000003496 00000 n 
 0000062383 00000 n 
-0000488120 00000 n 
+0000488377 00000 n 
 0000003545 00000 n 
 0000003578 00000 n 
 0000062509 00000 n 
-0000488055 00000 n 
+0000488312 00000 n 
 0000003632 00000 n 
 0000003681 00000 n 
 0000069370 00000 n 
-0000487923 00000 n 
+0000488180 00000 n 
 0000003730 00000 n 
 0000003758 00000 n 
 0000069496 00000 n 
-0000487805 00000 n 
+0000488062 00000 n 
 0000003812 00000 n 
 0000003881 00000 n 
 0000069621 00000 n 
-0000487726 00000 n 
+0000487983 00000 n 
 0000003940 00000 n 
 0000003988 00000 n 
 0000069747 00000 n 
-0000487647 00000 n 
+0000487904 00000 n 
 0000004047 00000 n 
 0000004092 00000 n 
 0000072749 00000 n 
-0000487554 00000 n 
+0000487811 00000 n 
 0000004146 00000 n 
 0000004214 00000 n 
 0000072875 00000 n 
-0000487461 00000 n 
+0000487718 00000 n 
 0000004268 00000 n 
 0000004338 00000 n 
 0000073001 00000 n 
-0000487368 00000 n 
+0000487625 00000 n 
 0000004392 00000 n 
 0000004455 00000 n 
 0000073127 00000 n 
-0000487275 00000 n 
+0000487532 00000 n 
 0000004509 00000 n 
 0000004564 00000 n 
 0000076860 00000 n 
-0000487196 00000 n 
+0000487453 00000 n 
 0000004618 00000 n 
 0000004650 00000 n 
 0000076986 00000 n 
-0000487103 00000 n 
+0000487360 00000 n 
 0000004699 00000 n 
 0000004727 00000 n 
 0000077111 00000 n 
-0000487010 00000 n 
+0000487267 00000 n 
 0000004776 00000 n 
 0000004808 00000 n 
 0000077237 00000 n 
-0000486878 00000 n 
+0000487135 00000 n 
 0000004857 00000 n 
 0000004887 00000 n 
 0000080688 00000 n 
-0000486799 00000 n 
+0000487056 00000 n 
 0000004941 00000 n 
 0000004982 00000 n 
 0000080813 00000 n 
-0000486706 00000 n 
+0000486963 00000 n 
 0000005036 00000 n 
 0000005078 00000 n 
 0000080939 00000 n 
-0000486627 00000 n 
+0000486884 00000 n 
 0000005132 00000 n 
 0000005177 00000 n 
 0000088379 00000 n 
-0000486509 00000 n 
+0000486766 00000 n 
 0000005226 00000 n 
 0000005272 00000 n 
 0000088505 00000 n 
-0000486430 00000 n 
+0000486687 00000 n 
 0000005326 00000 n 
 0000005386 00000 n 
 0000088631 00000 n 
-0000486351 00000 n 
+0000486608 00000 n 
 0000005440 00000 n 
 0000005509 00000 n 
 0000091066 00000 n 
-0000486218 00000 n 
+0000486475 00000 n 
 0000005556 00000 n 
 0000005609 00000 n 
 0000091192 00000 n 
-0000486139 00000 n 
+0000486396 00000 n 
 0000005658 00000 n 
 0000005714 00000 n 
 0000091318 00000 n 
-0000486060 00000 n 
+0000486317 00000 n 
 0000005763 00000 n 
 0000005812 00000 n 
 0000095439 00000 n 
-0000485927 00000 n 
+0000486184 00000 n 
 0000005859 00000 n 
 0000005911 00000 n 
 0000095565 00000 n 
-0000485809 00000 n 
+0000486066 00000 n 
 0000005960 00000 n 
 0000006011 00000 n 
 0000099709 00000 n 
-0000485691 00000 n 
+0000485948 00000 n 
 0000006065 00000 n 
 0000006110 00000 n 
 0000099834 00000 n 
-0000485612 00000 n 
+0000485869 00000 n 
 0000006169 00000 n 
 0000006203 00000 n 
 0000099959 00000 n 
-0000485533 00000 n 
+0000485790 00000 n 
 0000006262 00000 n 
 0000006310 00000 n 
 0000103241 00000 n 
-0000485415 00000 n 
+0000485672 00000 n 
 0000006364 00000 n 
 0000006404 00000 n 
 0000103367 00000 n 
-0000485336 00000 n 
+0000485593 00000 n 
 0000006463 00000 n 
 0000006497 00000 n 
 0000103493 00000 n 
-0000485257 00000 n 
+0000485514 00000 n 
 0000006556 00000 n 
 0000006604 00000 n 
 0000107219 00000 n 
-0000485124 00000 n 
+0000485381 00000 n 
 0000006653 00000 n 
 0000006703 00000 n 
 0000111057 00000 n 
-0000485045 00000 n 
+0000485302 00000 n 
 0000006757 00000 n 
 0000006804 00000 n 
 0000111183 00000 n 
-0000484952 00000 n 
+0000485209 00000 n 
 0000006858 00000 n 
 0000006918 00000 n 
 0000111433 00000 n 
-0000484859 00000 n 
+0000485116 00000 n 
 0000006972 00000 n 
 0000007024 00000 n 
 0000111559 00000 n 
-0000484766 00000 n 
+0000485023 00000 n 
 0000007078 00000 n 
 0000007143 00000 n 
 0000116189 00000 n 
-0000484673 00000 n 
+0000484930 00000 n 
 0000007197 00000 n 
 0000007248 00000 n 
 0000116315 00000 n 
-0000484580 00000 n 
+0000484837 00000 n 
 0000007302 00000 n 
 0000007366 00000 n 
 0000116441 00000 n 
-0000484487 00000 n 
+0000484744 00000 n 
 0000007420 00000 n 
 0000007467 00000 n 
 0000116567 00000 n 
-0000484394 00000 n 
+0000484651 00000 n 
 0000007521 00000 n 
 0000007581 00000 n 
 0000119509 00000 n 
-0000484301 00000 n 
+0000484558 00000 n 
 0000007635 00000 n 
 0000007686 00000 n 
 0000119635 00000 n 
-0000484169 00000 n 
+0000484426 00000 n 
 0000007741 00000 n 
 0000007806 00000 n 
 0000119761 00000 n 
-0000484090 00000 n 
+0000484347 00000 n 
 0000007866 00000 n 
 0000007913 00000 n 
 0000130170 00000 n 
-0000484011 00000 n 
+0000484268 00000 n 
 0000007973 00000 n 
 0000008021 00000 n 
 0000133886 00000 n 
-0000483918 00000 n 
+0000484175 00000 n 
 0000008076 00000 n 
 0000008126 00000 n 
 0000134012 00000 n 
-0000483825 00000 n 
+0000484082 00000 n 
 0000008181 00000 n 
 0000008244 00000 n 
 0000135742 00000 n 
-0000483732 00000 n 
+0000483989 00000 n 
 0000008299 00000 n 
 0000008351 00000 n 
 0000135868 00000 n 
-0000483639 00000 n 
+0000483896 00000 n 
 0000008406 00000 n 
 0000008471 00000 n 
 0000135994 00000 n 
-0000483546 00000 n 
+0000483803 00000 n 
 0000008526 00000 n 
 0000008578 00000 n 
 0000141175 00000 n 
-0000483413 00000 n 
+0000483670 00000 n 
 0000008633 00000 n 
 0000008698 00000 n 
 0000145209 00000 n 
-0000483334 00000 n 
+0000483591 00000 n 
 0000008758 00000 n 
 0000008802 00000 n 
 0000162726 00000 n 
-0000483241 00000 n 
+0000483498 00000 n 
 0000008862 00000 n 
 0000008901 00000 n 
 0000162852 00000 n 
-0000483148 00000 n 
+0000483405 00000 n 
 0000008961 00000 n 
 0000009008 00000 n 
 0000166993 00000 n 
-0000483055 00000 n 
+0000483312 00000 n 
 0000009068 00000 n 
 0000009111 00000 n 
 0000167119 00000 n 
-0000482962 00000 n 
+0000483219 00000 n 
 0000009171 00000 n 
 0000009210 00000 n 
-0000170214 00000 n 
-0000482869 00000 n 
+0000170296 00000 n 
+0000483126 00000 n 
 0000009270 00000 n 
 0000009312 00000 n 
-0000173956 00000 n 
-0000482776 00000 n 
+0000173827 00000 n 
+0000483033 00000 n 
 0000009372 00000 n 
 0000009415 00000 n 
-0000181576 00000 n 
-0000482683 00000 n 
+0000181413 00000 n 
+0000482940 00000 n 
 0000009475 00000 n 
 0000009522 00000 n 
-0000181702 00000 n 
-0000482590 00000 n 
+0000181539 00000 n 
+0000482847 00000 n 
 0000009582 00000 n 
 0000009643 00000 n 
-0000181828 00000 n 
-0000482497 00000 n 
+0000181665 00000 n 
+0000482754 00000 n 
 0000009704 00000 n 
 0000009756 00000 n 
-0000185325 00000 n 
-0000482404 00000 n 
+0000185582 00000 n 
+0000482661 00000 n 
 0000009817 00000 n 
 0000009870 00000 n 
-0000189658 00000 n 
-0000482311 00000 n 
+0000189915 00000 n 
+0000482568 00000 n 
 0000009931 00000 n 
 0000009969 00000 n 
-0000189787 00000 n 
-0000482218 00000 n 
+0000190044 00000 n 
+0000482475 00000 n 
 0000010030 00000 n 
 0000010082 00000 n 
-0000192689 00000 n 
-0000482125 00000 n 
+0000192946 00000 n 
+0000482382 00000 n 
 0000010143 00000 n 
 0000010187 00000 n 
-0000196435 00000 n 
-0000482032 00000 n 
+0000196692 00000 n 
+0000482289 00000 n 
 0000010248 00000 n 
 0000010284 00000 n 
-0000200400 00000 n 
-0000481939 00000 n 
+0000200657 00000 n 
+0000482196 00000 n 
 0000010345 00000 n 
 0000010408 00000 n 
-0000200529 00000 n 
-0000481860 00000 n 
+0000200786 00000 n 
+0000482117 00000 n 
 0000010469 00000 n 
 0000010518 00000 n 
-0000204050 00000 n 
-0000481767 00000 n 
+0000204307 00000 n 
+0000482024 00000 n 
 0000010573 00000 n 
 0000010624 00000 n 
-0000204177 00000 n 
-0000481674 00000 n 
+0000204434 00000 n 
+0000481931 00000 n 
 0000010679 00000 n 
 0000010743 00000 n 
-0000208304 00000 n 
-0000481581 00000 n 
+0000208561 00000 n 
+0000481838 00000 n 
 0000010798 00000 n 
 0000010855 00000 n 
-0000208431 00000 n 
-0000481488 00000 n 
+0000208688 00000 n 
+0000481745 00000 n 
 0000010910 00000 n 
 0000010980 00000 n 
-0000208559 00000 n 
-0000481395 00000 n 
+0000208816 00000 n 
+0000481652 00000 n 
 0000011035 00000 n 
 0000011084 00000 n 
-0000211978 00000 n 
-0000481302 00000 n 
+0000212235 00000 n 
+0000481559 00000 n 
 0000011139 00000 n 
 0000011201 00000 n 
-0000213555 00000 n 
-0000481209 00000 n 
+0000213812 00000 n 
+0000481466 00000 n 
 0000011256 00000 n 
 0000011305 00000 n 
-0000218410 00000 n 
-0000481091 00000 n 
+0000218667 00000 n 
+0000481348 00000 n 
 0000011360 00000 n 
 0000011422 00000 n 
-0000218539 00000 n 
-0000481012 00000 n 
+0000218796 00000 n 
+0000481269 00000 n 
 0000011482 00000 n 
 0000011521 00000 n 
-0000223490 00000 n 
-0000480919 00000 n 
+0000223747 00000 n 
+0000481176 00000 n 
 0000011581 00000 n 
 0000011615 00000 n 
-0000223619 00000 n 
-0000480826 00000 n 
+0000223876 00000 n 
+0000481083 00000 n 
 0000011675 00000 n 
 0000011716 00000 n 
-0000233806 00000 n 
-0000480747 00000 n 
+0000234063 00000 n 
+0000481004 00000 n 
 0000011776 00000 n 
 0000011828 00000 n 
-0000237977 00000 n 
-0000480629 00000 n 
+0000238234 00000 n 
+0000480886 00000 n 
 0000011877 00000 n 
 0000011910 00000 n 
-0000238106 00000 n 
-0000480511 00000 n 
+0000238363 00000 n 
+0000480768 00000 n 
 0000011964 00000 n 
 0000012036 00000 n 
-0000238234 00000 n 
-0000480432 00000 n 
+0000238491 00000 n 
+0000480689 00000 n 
 0000012095 00000 n 
 0000012139 00000 n 
-0000245968 00000 n 
-0000480353 00000 n 
+0000246225 00000 n 
+0000480610 00000 n 
 0000012198 00000 n 
 0000012251 00000 n 
-0000249552 00000 n 
-0000480260 00000 n 
+0000249809 00000 n 
+0000480517 00000 n 
 0000012305 00000 n 
 0000012355 00000 n 
-0000252912 00000 n 
-0000480167 00000 n 
+0000253169 00000 n 
+0000480424 00000 n 
 0000012409 00000 n 
 0000012447 00000 n 
-0000253170 00000 n 
-0000480074 00000 n 
+0000253427 00000 n 
+0000480331 00000 n 
 0000012501 00000 n 
 0000012550 00000 n 
-0000253428 00000 n 
-0000479942 00000 n 
+0000253685 00000 n 
+0000480199 00000 n 
 0000012604 00000 n 
 0000012656 00000 n 
-0000253557 00000 n 
-0000479863 00000 n 
+0000253814 00000 n 
+0000480120 00000 n 
 0000012715 00000 n 
 0000012767 00000 n 
-0000256438 00000 n 
-0000479770 00000 n 
+0000256695 00000 n 
+0000480027 00000 n 
 0000012826 00000 n 
 0000012879 00000 n 
-0000256567 00000 n 
-0000479691 00000 n 
+0000256824 00000 n 
+0000479948 00000 n 
 0000012938 00000 n 
 0000012987 00000 n 
-0000256696 00000 n 
-0000479612 00000 n 
+0000256953 00000 n 
+0000479869 00000 n 
 0000013041 00000 n 
 0000013121 00000 n 
-0000262565 00000 n 
-0000479479 00000 n 
+0000262822 00000 n 
+0000479736 00000 n 
 0000013168 00000 n 
 0000013220 00000 n 
-0000262694 00000 n 
-0000479400 00000 n 
+0000262951 00000 n 
+0000479657 00000 n 
 0000013269 00000 n 
 0000013313 00000 n 
-0000266427 00000 n 
-0000479268 00000 n 
+0000266684 00000 n 
+0000479525 00000 n 
 0000013362 00000 n 
 0000013424 00000 n 
-0000266556 00000 n 
-0000479189 00000 n 
+0000266813 00000 n 
+0000479446 00000 n 
 0000013478 00000 n 
 0000013526 00000 n 
-0000266685 00000 n 
-0000479110 00000 n 
+0000266942 00000 n 
+0000479367 00000 n 
 0000013580 00000 n 
 0000013631 00000 n 
-0000266814 00000 n 
-0000479031 00000 n 
+0000267071 00000 n 
+0000479288 00000 n 
 0000013680 00000 n 
 0000013727 00000 n 
-0000269731 00000 n 
-0000478898 00000 n 
+0000269988 00000 n 
+0000479155 00000 n 
 0000013774 00000 n 
 0000013811 00000 n 
-0000269860 00000 n 
-0000478780 00000 n 
+0000270117 00000 n 
+0000479037 00000 n 
 0000013860 00000 n 
 0000013899 00000 n 
-0000269989 00000 n 
-0000478715 00000 n 
+0000270246 00000 n 
+0000478972 00000 n 
 0000013953 00000 n 
 0000014031 00000 n 
-0000270118 00000 n 
-0000478622 00000 n 
+0000270375 00000 n 
+0000478879 00000 n 
 0000014080 00000 n 
 0000014147 00000 n 
-0000270247 00000 n 
-0000478543 00000 n 
+0000270504 00000 n 
+0000478800 00000 n 
 0000014196 00000 n 
 0000014241 00000 n 
-0000273741 00000 n 
-0000478424 00000 n 
+0000273998 00000 n 
+0000478681 00000 n 
 0000014289 00000 n 
 0000014321 00000 n 
-0000273870 00000 n 
-0000478306 00000 n 
+0000274127 00000 n 
+0000478563 00000 n 
 0000014370 00000 n 
 0000014409 00000 n 
-0000273999 00000 n 
-0000478241 00000 n 
+0000274256 00000 n 
+0000478498 00000 n 
 0000014463 00000 n 
 0000014524 00000 n 
-0000277498 00000 n 
-0000478109 00000 n 
+0000277755 00000 n 
+0000478366 00000 n 
 0000014573 00000 n 
 0000014630 00000 n 
-0000277627 00000 n 
-0000478044 00000 n 
+0000277884 00000 n 
+0000478301 00000 n 
 0000014684 00000 n 
 0000014733 00000 n 
-0000281814 00000 n 
-0000477926 00000 n 
+0000282071 00000 n 
+0000478183 00000 n 
 0000014782 00000 n 
 0000014844 00000 n 
-0000281943 00000 n 
-0000477847 00000 n 
+0000282200 00000 n 
+0000478104 00000 n 
 0000014898 00000 n 
 0000014953 00000 n 
-0000292558 00000 n 
-0000477754 00000 n 
+0000292815 00000 n 
+0000478011 00000 n 
 0000015007 00000 n 
 0000015048 00000 n 
-0000292687 00000 n 
-0000477675 00000 n 
+0000292944 00000 n 
+0000477932 00000 n 
 0000015102 00000 n 
 0000015154 00000 n 
 0000015507 00000 n 
@@ -8254,20 +8234,20 @@ xref
 0000015207 00000 n 
 0000015629 00000 n 
 0000015692 00000 n 
-0000474516 00000 n 
-0000448852 00000 n 
-0000474342 00000 n 
-0000447664 00000 n 
-0000421504 00000 n 
-0000447490 00000 n 
-0000475521 00000 n 
+0000474773 00000 n 
+0000449109 00000 n 
+0000474599 00000 n 
+0000447921 00000 n 
+0000421761 00000 n 
+0000447747 00000 n 
+0000475778 00000 n 
 0000016419 00000 n 
 0000016234 00000 n 
 0000015840 00000 n 
 0000016356 00000 n 
-0000420819 00000 n 
-0000418674 00000 n 
-0000420655 00000 n 
+0000421076 00000 n 
+0000418932 00000 n 
+0000420912 00000 n 
 0000019594 00000 n 
 0000018784 00000 n 
 0000016504 00000 n 
@@ -8275,25 +8255,25 @@ xref
 0000019030 00000 n 
 0000019155 00000 n 
 0000019280 00000 n 
-0000417820 00000 n 
-0000397462 00000 n 
-0000417646 00000 n 
+0000418078 00000 n 
+0000397720 00000 n 
+0000417904 00000 n 
 0000019405 00000 n 
 0000019468 00000 n 
 0000019531 00000 n 
-0000396513 00000 n 
-0000376761 00000 n 
-0000396340 00000 n 
-0000376034 00000 n 
-0000359650 00000 n 
-0000375861 00000 n 
+0000396771 00000 n 
+0000377019 00000 n 
+0000396598 00000 n 
+0000376292 00000 n 
+0000359908 00000 n 
+0000376119 00000 n 
 0000024132 00000 n 
 0000022950 00000 n 
 0000019718 00000 n 
 0000023444 00000 n 
-0000359115 00000 n 
-0000342198 00000 n 
-0000358931 00000 n 
+0000359373 00000 n 
+0000342456 00000 n 
+0000359189 00000 n 
 0000023507 00000 n 
 0000023570 00000 n 
 0000023695 00000 n 
@@ -8302,8 +8282,8 @@ xref
 0000023100 00000 n 
 0000023293 00000 n 
 0000024070 00000 n 
-0000238170 00000 n 
-0000282007 00000 n 
+0000238427 00000 n 
+0000282264 00000 n 
 0000028818 00000 n 
 0000027783 00000 n 
 0000024256 00000 n 
@@ -8331,7 +8311,7 @@ xref
 0000034556 00000 n 
 0000034678 00000 n 
 0000034803 00000 n 
-0000475639 00000 n 
+0000475896 00000 n 
 0000035902 00000 n 
 0000035592 00000 n 
 0000034951 00000 n 
@@ -8355,28 +8335,28 @@ xref
 0000040239 00000 n 
 0000040775 00000 n 
 0000040901 00000 n 
-0000192753 00000 n 
+0000193010 00000 n 
 0000044275 00000 n 
 0000043838 00000 n 
 0000041075 00000 n 
 0000043960 00000 n 
-0000341671 00000 n 
-0000332362 00000 n 
-0000341494 00000 n 
+0000341929 00000 n 
+0000332620 00000 n 
+0000341752 00000 n 
 0000044212 00000 n 
 0000047975 00000 n 
 0000047790 00000 n 
 0000044399 00000 n 
 0000047912 00000 n 
-0000331919 00000 n 
-0000325120 00000 n 
-0000331742 00000 n 
+0000332177 00000 n 
+0000325378 00000 n 
+0000332000 00000 n 
 0000052340 00000 n 
 0000051949 00000 n 
 0000048138 00000 n 
 0000052277 00000 n 
 0000052091 00000 n 
-0000475757 00000 n 
+0000476014 00000 n 
 0000111622 00000 n 
 0000054540 00000 n 
 0000054103 00000 n 
@@ -8396,7 +8376,7 @@ xref
 0000057875 00000 n 
 0000058001 00000 n 
 0000145272 00000 n 
-0000174019 00000 n 
+0000173890 00000 n 
 0000062635 00000 n 
 0000061718 00000 n 
 0000058162 00000 n 
@@ -8406,7 +8386,7 @@ xref
 0000062033 00000 n 
 0000062446 00000 n 
 0000062572 00000 n 
-0000282786 00000 n 
+0000283043 00000 n 
 0000065550 00000 n 
 0000065178 00000 n 
 0000062785 00000 n 
@@ -8424,7 +8404,7 @@ xref
 0000069559 00000 n 
 0000069684 00000 n 
 0000069810 00000 n 
-0000475875 00000 n 
+0000476132 00000 n 
 0000073253 00000 n 
 0000072376 00000 n 
 0000070010 00000 n 
@@ -8434,7 +8414,7 @@ xref
 0000073064 00000 n 
 0000073190 00000 n 
 0000072518 00000 n 
-0000233870 00000 n 
+0000234127 00000 n 
 0000077362 00000 n 
 0000076675 00000 n 
 0000073390 00000 n 
@@ -8455,9 +8435,9 @@ xref
 0000083942 00000 n 
 0000081187 00000 n 
 0000085700 00000 n 
-0000324285 00000 n 
-0000315425 00000 n 
-0000324113 00000 n 
+0000324543 00000 n 
+0000315683 00000 n 
+0000324371 00000 n 
 0000085532 00000 n 
 0000085589 00000 n 
 0000085678 00000 n 
@@ -8469,7 +8449,7 @@ xref
 0000088157 00000 n 
 0000088568 00000 n 
 0000088694 00000 n 
-0000277691 00000 n 
+0000277948 00000 n 
 0000091444 00000 n 
 0000090881 00000 n 
 0000088881 00000 n 
@@ -8477,7 +8457,7 @@ xref
 0000091129 00000 n 
 0000091255 00000 n 
 0000091381 00000 n 
-0000475993 00000 n 
+0000476250 00000 n 
 0000091876 00000 n 
 0000091691 00000 n 
 0000091542 00000 n 
@@ -8522,7 +8502,7 @@ xref
 0000111307 00000 n 
 0000111370 00000 n 
 0000111496 00000 n 
-0000476111 00000 n 
+0000476368 00000 n 
 0000116693 00000 n 
 0000115127 00000 n 
 0000111796 00000 n 
@@ -8536,7 +8516,7 @@ xref
 0000115609 00000 n 
 0000115760 00000 n 
 0000115944 00000 n 
-0000293201 00000 n 
+0000293458 00000 n 
 0000119887 00000 n 
 0000119324 00000 n 
 0000116830 00000 n 
@@ -8568,7 +8548,7 @@ xref
 0000134075 00000 n 
 0000133520 00000 n 
 0000133671 00000 n 
-0000476229 00000 n 
+0000476486 00000 n 
 0000136120 00000 n 
 0000135557 00000 n 
 0000134249 00000 n 
@@ -8590,7 +8570,7 @@ xref
 0000141425 00000 n 
 0000145146 00000 n 
 0000144991 00000 n 
-0000200593 00000 n 
+0000200850 00000 n 
 0000149374 00000 n 
 0000149063 00000 n 
 0000145458 00000 n 
@@ -8605,8 +8585,8 @@ xref
 0000153392 00000 n 
 0000153548 00000 n 
 0000153730 00000 n 
-0000476347 00000 n 
-0000204241 00000 n 
+0000476604 00000 n 
+0000204498 00000 n 
 0000158684 00000 n 
 0000158103 00000 n 
 0000154129 00000 n 
@@ -8620,7 +8600,7 @@ xref
 0000162789 00000 n 
 0000162495 00000 n 
 0000162915 00000 n 
-0000213619 00000 n 
+0000213876 00000 n 
 0000167245 00000 n 
 0000166445 00000 n 
 0000163102 00000 n 
@@ -8629,412 +8609,412 @@ xref
 0000166595 00000 n 
 0000166760 00000 n 
 0000167182 00000 n 
-0000266877 00000 n 
-0000170339 00000 n 
-0000170029 00000 n 
+0000267134 00000 n 
+0000170422 00000 n 
+0000170111 00000 n 
 0000167369 00000 n 
-0000170151 00000 n 
-0000170276 00000 n 
-0000314899 00000 n 
-0000307009 00000 n 
-0000314726 00000 n 
-0000174082 00000 n 
-0000173771 00000 n 
-0000170504 00000 n 
-0000173893 00000 n 
-0000177641 00000 n 
-0000177456 00000 n 
-0000174221 00000 n 
-0000177578 00000 n 
-0000476465 00000 n 
-0000181954 00000 n 
-0000181036 00000 n 
-0000177806 00000 n 
-0000181513 00000 n 
-0000181639 00000 n 
-0000181765 00000 n 
-0000181187 00000 n 
-0000181891 00000 n 
-0000181360 00000 n 
-0000185454 00000 n 
-0000185135 00000 n 
-0000182106 00000 n 
-0000185260 00000 n 
-0000185389 00000 n 
-0000189915 00000 n 
-0000189121 00000 n 
-0000185607 00000 n 
-0000189593 00000 n 
-0000189722 00000 n 
+0000170233 00000 n 
+0000170359 00000 n 
+0000315157 00000 n 
+0000307266 00000 n 
+0000314984 00000 n 
+0000173953 00000 n 
+0000173642 00000 n 
+0000170587 00000 n 
+0000173764 00000 n 
+0000177876 00000 n 
+0000177691 00000 n 
+0000174105 00000 n 
+0000177813 00000 n 
+0000476722 00000 n 
+0000181791 00000 n 
+0000181035 00000 n 
+0000178041 00000 n 
+0000181350 00000 n 
+0000181476 00000 n 
+0000181602 00000 n 
+0000181177 00000 n 
+0000181728 00000 n 
+0000185711 00000 n 
+0000185216 00000 n 
+0000181943 00000 n 
+0000185517 00000 n 
+0000185362 00000 n 
+0000185646 00000 n 
+0000190172 00000 n 
+0000189378 00000 n 
+0000185864 00000 n 
 0000189850 00000 n 
-0000189276 00000 n 
-0000189438 00000 n 
-0000192947 00000 n 
-0000192309 00000 n 
-0000190081 00000 n 
-0000192624 00000 n 
-0000192455 00000 n 
-0000192817 00000 n 
-0000192882 00000 n 
-0000196563 00000 n 
-0000196062 00000 n 
-0000193059 00000 n 
-0000196370 00000 n 
-0000196499 00000 n 
-0000196208 00000 n 
-0000200787 00000 n 
-0000200020 00000 n 
-0000196742 00000 n 
-0000200335 00000 n 
-0000200464 00000 n 
-0000200167 00000 n 
-0000200657 00000 n 
-0000200722 00000 n 
-0000476587 00000 n 
+0000189979 00000 n 
+0000190107 00000 n 
+0000189533 00000 n 
+0000189695 00000 n 
+0000193204 00000 n 
+0000192566 00000 n 
+0000190338 00000 n 
+0000192881 00000 n 
+0000192712 00000 n 
+0000193074 00000 n 
+0000193139 00000 n 
+0000196820 00000 n 
+0000196319 00000 n 
+0000193316 00000 n 
+0000196627 00000 n 
+0000196756 00000 n 
+0000196465 00000 n 
+0000201044 00000 n 
+0000200277 00000 n 
+0000196999 00000 n 
+0000200592 00000 n 
+0000200721 00000 n 
+0000200424 00000 n 
+0000200914 00000 n 
+0000200979 00000 n 
+0000476844 00000 n 
+0000208880 00000 n 
+0000204561 00000 n 
+0000204116 00000 n 
+0000201156 00000 n 
+0000204242 00000 n 
+0000204371 00000 n 
+0000208945 00000 n 
+0000207865 00000 n 
+0000204673 00000 n 
+0000208496 00000 n 
+0000208030 00000 n 
+0000208181 00000 n 
 0000208623 00000 n 
-0000204304 00000 n 
-0000203859 00000 n 
-0000200899 00000 n 
-0000203985 00000 n 
-0000204114 00000 n 
-0000208688 00000 n 
-0000207608 00000 n 
-0000204416 00000 n 
-0000208239 00000 n 
-0000207773 00000 n 
-0000207924 00000 n 
-0000208366 00000 n 
-0000208494 00000 n 
-0000208085 00000 n 
-0000212106 00000 n 
-0000211787 00000 n 
-0000208800 00000 n 
-0000211913 00000 n 
-0000212042 00000 n 
-0000213683 00000 n 
-0000213364 00000 n 
-0000212218 00000 n 
-0000213490 00000 n 
-0000215059 00000 n 
-0000214868 00000 n 
-0000213795 00000 n 
-0000214994 00000 n 
-0000218796 00000 n 
-0000218219 00000 n 
-0000215158 00000 n 
-0000218345 00000 n 
-0000218474 00000 n 
-0000218603 00000 n 
-0000218668 00000 n 
-0000218733 00000 n 
-0000476712 00000 n 
-0000223748 00000 n 
-0000222246 00000 n 
-0000218908 00000 n 
-0000223425 00000 n 
-0000223554 00000 n 
-0000223683 00000 n 
-0000222438 00000 n 
-0000222600 00000 n 
-0000222762 00000 n 
-0000222924 00000 n 
-0000223095 00000 n 
-0000223265 00000 n 
-0000228568 00000 n 
-0000227339 00000 n 
-0000223860 00000 n 
-0000228503 00000 n 
-0000227531 00000 n 
-0000227694 00000 n 
-0000227856 00000 n 
-0000228018 00000 n 
-0000228178 00000 n 
-0000228340 00000 n 
-0000233934 00000 n 
-0000231575 00000 n 
-0000228693 00000 n 
-0000233741 00000 n 
-0000231821 00000 n 
-0000231974 00000 n 
-0000232136 00000 n 
-0000232298 00000 n 
-0000232460 00000 n 
-0000232622 00000 n 
-0000232784 00000 n 
-0000232946 00000 n 
-0000233108 00000 n 
-0000233262 00000 n 
-0000233423 00000 n 
-0000233578 00000 n 
-0000238491 00000 n 
-0000237294 00000 n 
-0000234059 00000 n 
-0000237782 00000 n 
-0000237847 00000 n 
-0000237912 00000 n 
-0000238041 00000 n 
+0000208751 00000 n 
+0000208342 00000 n 
+0000212363 00000 n 
+0000212044 00000 n 
+0000209057 00000 n 
+0000212170 00000 n 
+0000212299 00000 n 
+0000213940 00000 n 
+0000213621 00000 n 
+0000212475 00000 n 
+0000213747 00000 n 
+0000215316 00000 n 
+0000215125 00000 n 
+0000214052 00000 n 
+0000215251 00000 n 
+0000219053 00000 n 
+0000218476 00000 n 
+0000215415 00000 n 
+0000218602 00000 n 
+0000218731 00000 n 
+0000218860 00000 n 
+0000218925 00000 n 
+0000218990 00000 n 
+0000476969 00000 n 
+0000224005 00000 n 
+0000222503 00000 n 
+0000219165 00000 n 
+0000223682 00000 n 
+0000223811 00000 n 
+0000223940 00000 n 
+0000222695 00000 n 
+0000222857 00000 n 
+0000223019 00000 n 
+0000223181 00000 n 
+0000223352 00000 n 
+0000223522 00000 n 
+0000228825 00000 n 
+0000227596 00000 n 
+0000224117 00000 n 
+0000228760 00000 n 
+0000227788 00000 n 
+0000227951 00000 n 
+0000228113 00000 n 
+0000228275 00000 n 
+0000228435 00000 n 
+0000228597 00000 n 
+0000234191 00000 n 
+0000231832 00000 n 
+0000228950 00000 n 
+0000233998 00000 n 
+0000232078 00000 n 
+0000232231 00000 n 
+0000232393 00000 n 
+0000232555 00000 n 
+0000232717 00000 n 
+0000232879 00000 n 
+0000233041 00000 n 
+0000233203 00000 n 
+0000233365 00000 n 
+0000233519 00000 n 
+0000233680 00000 n 
+0000233835 00000 n 
+0000238748 00000 n 
+0000237551 00000 n 
+0000234316 00000 n 
+0000238039 00000 n 
+0000238104 00000 n 
+0000238169 00000 n 
 0000238298 00000 n 
-0000237450 00000 n 
-0000237620 00000 n 
-0000238363 00000 n 
-0000238427 00000 n 
-0000242086 00000 n 
-0000241765 00000 n 
-0000238616 00000 n 
-0000241891 00000 n 
-0000241956 00000 n 
-0000242021 00000 n 
-0000246097 00000 n 
-0000245647 00000 n 
-0000242185 00000 n 
-0000245773 00000 n 
-0000245838 00000 n 
-0000245903 00000 n 
-0000246032 00000 n 
-0000476837 00000 n 
-0000249811 00000 n 
-0000249101 00000 n 
-0000246222 00000 n 
-0000249227 00000 n 
-0000249292 00000 n 
-0000249357 00000 n 
-0000249422 00000 n 
-0000249487 00000 n 
-0000249616 00000 n 
-0000249681 00000 n 
-0000249746 00000 n 
-0000253684 00000 n 
-0000252721 00000 n 
-0000249936 00000 n 
-0000252847 00000 n 
-0000252976 00000 n 
-0000253041 00000 n 
-0000253106 00000 n 
-0000253234 00000 n 
+0000238555 00000 n 
+0000237707 00000 n 
+0000237877 00000 n 
+0000238620 00000 n 
+0000238684 00000 n 
+0000242343 00000 n 
+0000242022 00000 n 
+0000238873 00000 n 
+0000242148 00000 n 
+0000242213 00000 n 
+0000242278 00000 n 
+0000246354 00000 n 
+0000245904 00000 n 
+0000242442 00000 n 
+0000246030 00000 n 
+0000246095 00000 n 
+0000246160 00000 n 
+0000246289 00000 n 
+0000477094 00000 n 
+0000250068 00000 n 
+0000249358 00000 n 
+0000246479 00000 n 
+0000249484 00000 n 
+0000249549 00000 n 
+0000249614 00000 n 
+0000249679 00000 n 
+0000249744 00000 n 
+0000249873 00000 n 
+0000249938 00000 n 
+0000250003 00000 n 
+0000253941 00000 n 
+0000252978 00000 n 
+0000250193 00000 n 
+0000253104 00000 n 
+0000253233 00000 n 
 0000253298 00000 n 
 0000253363 00000 n 
-0000253492 00000 n 
+0000253491 00000 n 
+0000253555 00000 n 
 0000253620 00000 n 
-0000256825 00000 n 
-0000256247 00000 n 
-0000253876 00000 n 
-0000256373 00000 n 
-0000306654 00000 n 
-0000304656 00000 n 
-0000306489 00000 n 
-0000256502 00000 n 
-0000256631 00000 n 
-0000256760 00000 n 
-0000259788 00000 n 
-0000259467 00000 n 
-0000257018 00000 n 
-0000259593 00000 n 
-0000259658 00000 n 
-0000259723 00000 n 
-0000260241 00000 n 
-0000260050 00000 n 
-0000259900 00000 n 
-0000260176 00000 n 
-0000262822 00000 n 
-0000261914 00000 n 
-0000260283 00000 n 
-0000262500 00000 n 
-0000262629 00000 n 
-0000262758 00000 n 
-0000262070 00000 n 
-0000262285 00000 n 
-0000476962 00000 n 
-0000266941 00000 n 
-0000266236 00000 n 
-0000262948 00000 n 
-0000266362 00000 n 
-0000304335 00000 n 
-0000295122 00000 n 
-0000304149 00000 n 
-0000266491 00000 n 
-0000266620 00000 n 
-0000266749 00000 n 
-0000270375 00000 n 
-0000269149 00000 n 
-0000267106 00000 n 
-0000269666 00000 n 
-0000269795 00000 n 
-0000269924 00000 n 
-0000270053 00000 n 
-0000270182 00000 n 
-0000270311 00000 n 
-0000269305 00000 n 
-0000269477 00000 n 
-0000270829 00000 n 
-0000270638 00000 n 
-0000270488 00000 n 
-0000270764 00000 n 
-0000274128 00000 n 
-0000273550 00000 n 
-0000270871 00000 n 
-0000273676 00000 n 
-0000273805 00000 n 
-0000273934 00000 n 
-0000274063 00000 n 
-0000278014 00000 n 
-0000277307 00000 n 
-0000274214 00000 n 
-0000277433 00000 n 
-0000277562 00000 n 
-0000277755 00000 n 
-0000277820 00000 n 
-0000277884 00000 n 
-0000277949 00000 n 
-0000284668 00000 n 
-0000280868 00000 n 
-0000278140 00000 n 
-0000281749 00000 n 
-0000281878 00000 n 
-0000281042 00000 n 
-0000281221 00000 n 
-0000281398 00000 n 
-0000281573 00000 n 
-0000282071 00000 n 
-0000282136 00000 n 
-0000282201 00000 n 
-0000282266 00000 n 
-0000282331 00000 n 
-0000282396 00000 n 
-0000282461 00000 n 
-0000282526 00000 n 
-0000282591 00000 n 
-0000282656 00000 n 
-0000282721 00000 n 
-0000282850 00000 n 
-0000282915 00000 n 
-0000282980 00000 n 
-0000283045 00000 n 
-0000283110 00000 n 
-0000283175 00000 n 
-0000283240 00000 n 
-0000283305 00000 n 
-0000283370 00000 n 
-0000283435 00000 n 
-0000283500 00000 n 
-0000283565 00000 n 
-0000283630 00000 n 
-0000283695 00000 n 
-0000283760 00000 n 
-0000283825 00000 n 
-0000283890 00000 n 
-0000283955 00000 n 
-0000284020 00000 n 
-0000284085 00000 n 
-0000284150 00000 n 
-0000284215 00000 n 
-0000284280 00000 n 
-0000284345 00000 n 
-0000284410 00000 n 
-0000284475 00000 n 
-0000284540 00000 n 
-0000284604 00000 n 
-0000477087 00000 n 
-0000291179 00000 n 
-0000287484 00000 n 
-0000284820 00000 n 
-0000287610 00000 n 
-0000287675 00000 n 
-0000287740 00000 n 
-0000287805 00000 n 
-0000287870 00000 n 
-0000287935 00000 n 
-0000288000 00000 n 
-0000288065 00000 n 
-0000288129 00000 n 
-0000288194 00000 n 
-0000288259 00000 n 
-0000288324 00000 n 
-0000288389 00000 n 
-0000288454 00000 n 
-0000288519 00000 n 
-0000288584 00000 n 
-0000288648 00000 n 
-0000288713 00000 n 
-0000288778 00000 n 
-0000288843 00000 n 
-0000288908 00000 n 
-0000288973 00000 n 
-0000289038 00000 n 
-0000289103 00000 n 
-0000289168 00000 n 
-0000289233 00000 n 
-0000289298 00000 n 
-0000289363 00000 n 
-0000289428 00000 n 
-0000289493 00000 n 
-0000289558 00000 n 
-0000289623 00000 n 
-0000289688 00000 n 
-0000289753 00000 n 
-0000289818 00000 n 
-0000289883 00000 n 
-0000289948 00000 n 
-0000290013 00000 n 
-0000290078 00000 n 
-0000290143 00000 n 
-0000290208 00000 n 
-0000290273 00000 n 
-0000290338 00000 n 
-0000290403 00000 n 
-0000290468 00000 n 
-0000290533 00000 n 
-0000290598 00000 n 
-0000290663 00000 n 
-0000290728 00000 n 
-0000290793 00000 n 
-0000290858 00000 n 
-0000290923 00000 n 
-0000290987 00000 n 
-0000291051 00000 n 
+0000253749 00000 n 
+0000253877 00000 n 
+0000257082 00000 n 
+0000256504 00000 n 
+0000254133 00000 n 
+0000256630 00000 n 
+0000306911 00000 n 
+0000304913 00000 n 
+0000306746 00000 n 
+0000256759 00000 n 
+0000256888 00000 n 
+0000257017 00000 n 
+0000260045 00000 n 
+0000259724 00000 n 
+0000257275 00000 n 
+0000259850 00000 n 
+0000259915 00000 n 
+0000259980 00000 n 
+0000260498 00000 n 
+0000260307 00000 n 
+0000260157 00000 n 
+0000260433 00000 n 
+0000263079 00000 n 
+0000262171 00000 n 
+0000260540 00000 n 
+0000262757 00000 n 
+0000262886 00000 n 
+0000263015 00000 n 
+0000262327 00000 n 
+0000262542 00000 n 
+0000477219 00000 n 
+0000267198 00000 n 
+0000266493 00000 n 
+0000263205 00000 n 
+0000266619 00000 n 
+0000304592 00000 n 
+0000295379 00000 n 
+0000304406 00000 n 
+0000266748 00000 n 
+0000266877 00000 n 
+0000267006 00000 n 
+0000270632 00000 n 
+0000269406 00000 n 
+0000267363 00000 n 
+0000269923 00000 n 
+0000270052 00000 n 
+0000270181 00000 n 
+0000270310 00000 n 
+0000270439 00000 n 
+0000270568 00000 n 
+0000269562 00000 n 
+0000269734 00000 n 
+0000271086 00000 n 
+0000270895 00000 n 
+0000270745 00000 n 
+0000271021 00000 n 
+0000274385 00000 n 
+0000273807 00000 n 
+0000271128 00000 n 
+0000273933 00000 n 
+0000274062 00000 n 
+0000274191 00000 n 
+0000274320 00000 n 
+0000278271 00000 n 
+0000277564 00000 n 
+0000274471 00000 n 
+0000277690 00000 n 
+0000277819 00000 n 
+0000278012 00000 n 
+0000278077 00000 n 
+0000278141 00000 n 
+0000278206 00000 n 
+0000284925 00000 n 
+0000281125 00000 n 
+0000278397 00000 n 
+0000282006 00000 n 
+0000282135 00000 n 
+0000281299 00000 n 
+0000281478 00000 n 
+0000281655 00000 n 
+0000281830 00000 n 
+0000282328 00000 n 
+0000282393 00000 n 
+0000282458 00000 n 
+0000282523 00000 n 
+0000282588 00000 n 
+0000282653 00000 n 
+0000282718 00000 n 
+0000282783 00000 n 
+0000282848 00000 n 
+0000282913 00000 n 
+0000282978 00000 n 
+0000283107 00000 n 
+0000283172 00000 n 
+0000283237 00000 n 
+0000283302 00000 n 
+0000283367 00000 n 
+0000283432 00000 n 
+0000283497 00000 n 
+0000283562 00000 n 
+0000283627 00000 n 
+0000283692 00000 n 
+0000283757 00000 n 
+0000283822 00000 n 
+0000283887 00000 n 
+0000283952 00000 n 
+0000284017 00000 n 
+0000284082 00000 n 
+0000284147 00000 n 
+0000284212 00000 n 
+0000284277 00000 n 
+0000284342 00000 n 
+0000284407 00000 n 
+0000284472 00000 n 
+0000284537 00000 n 
+0000284602 00000 n 
+0000284667 00000 n 
+0000284732 00000 n 
+0000284797 00000 n 
+0000284861 00000 n 
+0000477344 00000 n 
+0000291436 00000 n 
+0000287741 00000 n 
+0000285077 00000 n 
+0000287867 00000 n 
+0000287932 00000 n 
+0000287997 00000 n 
+0000288062 00000 n 
+0000288127 00000 n 
+0000288192 00000 n 
+0000288257 00000 n 
+0000288322 00000 n 
+0000288386 00000 n 
+0000288451 00000 n 
+0000288516 00000 n 
+0000288581 00000 n 
+0000288646 00000 n 
+0000288711 00000 n 
+0000288776 00000 n 
+0000288841 00000 n 
+0000288905 00000 n 
+0000288970 00000 n 
+0000289035 00000 n 
+0000289100 00000 n 
+0000289165 00000 n 
+0000289230 00000 n 
+0000289295 00000 n 
+0000289360 00000 n 
+0000289425 00000 n 
+0000289490 00000 n 
+0000289555 00000 n 
+0000289620 00000 n 
+0000289685 00000 n 
+0000289750 00000 n 
+0000289815 00000 n 
+0000289880 00000 n 
+0000289945 00000 n 
+0000290010 00000 n 
+0000290075 00000 n 
+0000290140 00000 n 
+0000290205 00000 n 
+0000290270 00000 n 
+0000290335 00000 n 
+0000290400 00000 n 
+0000290465 00000 n 
+0000290530 00000 n 
+0000290595 00000 n 
+0000290660 00000 n 
+0000290725 00000 n 
+0000290790 00000 n 
+0000290855 00000 n 
+0000290920 00000 n 
+0000290985 00000 n 
+0000291050 00000 n 
 0000291115 00000 n 
-0000293076 00000 n 
-0000292367 00000 n 
-0000291291 00000 n 
-0000292493 00000 n 
-0000292622 00000 n 
-0000292751 00000 n 
-0000292816 00000 n 
-0000292881 00000 n 
-0000292946 00000 n 
-0000293011 00000 n 
-0000293233 00000 n 
-0000304577 00000 n 
-0000306901 00000 n 
-0000306870 00000 n 
-0000315174 00000 n 
-0000324690 00000 n 
-0000332161 00000 n 
-0000341957 00000 n 
-0000359455 00000 n 
-0000376442 00000 n 
-0000397081 00000 n 
-0000418224 00000 n 
-0000421306 00000 n 
-0000421076 00000 n 
-0000448225 00000 n 
-0000475035 00000 n 
-0000477185 00000 n 
-0000477305 00000 n 
-0000477428 00000 n 
-0000477517 00000 n 
-0000477599 00000 n 
-0000491574 00000 n 
-0000503622 00000 n 
-0000503663 00000 n 
-0000503703 00000 n 
-0000503837 00000 n 
+0000291180 00000 n 
+0000291244 00000 n 
+0000291308 00000 n 
+0000291372 00000 n 
+0000293333 00000 n 
+0000292624 00000 n 
+0000291548 00000 n 
+0000292750 00000 n 
+0000292879 00000 n 
+0000293008 00000 n 
+0000293073 00000 n 
+0000293138 00000 n 
+0000293203 00000 n 
+0000293268 00000 n 
+0000293490 00000 n 
+0000304834 00000 n 
+0000307158 00000 n 
+0000307127 00000 n 
+0000315432 00000 n 
+0000324948 00000 n 
+0000332419 00000 n 
+0000342215 00000 n 
+0000359713 00000 n 
+0000376700 00000 n 
+0000397339 00000 n 
+0000418482 00000 n 
+0000421563 00000 n 
+0000421333 00000 n 
+0000448482 00000 n 
+0000475292 00000 n 
+0000477442 00000 n 
+0000477562 00000 n 
+0000477685 00000 n 
+0000477774 00000 n 
+0000477856 00000 n 
+0000491831 00000 n 
+0000503879 00000 n 
+0000503920 00000 n 
+0000503960 00000 n 
+0000504094 00000 n 
 trailer
 <<
 /Size 1373
 /Root 1371 0 R
 /Info 1372 0 R
-/ID [<B146BB689FDC064660D3C5269A4887DD> <B146BB689FDC064660D3C5269A4887DD>]
+/ID [<01CCFD1E5FBF13DF94A8F939D2FB9838> <01CCFD1E5FBF13DF94A8F939D2FB9838>]
 >>
 startxref
-504095
+504352
 %%EOF
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt
deleted file mode 100644
index c8db70916f..0000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-DNSEXT                                                         D. Blacka
-Internet-Draft                                            VeriSign, Inc.
-Intended status: Standards Track                           April 7, 2006
-Expires: October 9, 2006
-
-
-                           DNSSEC Experiments
-                draft-ietf-dnsext-dnssec-experiments-03
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on October 9, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006                [Page 1]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-Abstract
-
-   This document describes a methodology for deploying alternate, non-
-   backwards-compatible, DNSSEC methodologies in an experimental fashion
-   without disrupting the deployment of standard DNSSEC.
-
-
-Table of Contents
-
-   1.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
-   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Experiments  . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   4.  Method . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   5.  Defining an Experiment . . . . . . . . . . . . . . . . . . . .  8
-   6.  Considerations . . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 13
-     10.2.  Informative References  . . . . . . . . . . . . . . . . . 13
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006                [Page 2]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-1.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [5]) and the DNS security extensions ([2], [3], and [4] is assumed.
-
-   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].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006                [Page 3]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-2.  Overview
-
-   Historically, experimentation with DNSSEC alternatives has been a
-   problematic endeavor.  There has typically been a desire to both
-   introduce non-backwards-compatible changes to DNSSEC and to try these
-   changes on real zones in the public DNS.  This creates a problem when
-   the change to DNSSEC would make all or part of the zone using those
-   changes appear bogus (bad) or otherwise broken to existing security-
-   aware resolvers.
-
-   This document describes a standard methodology for setting up DNSSEC
-   experiments.  This methodology addresses the issue of co-existence
-   with standard DNSSEC and DNS by using unknown algorithm identifiers
-   to hide the experimental DNSSEC protocol modifications from standard
-   security-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006                [Page 4]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-3.  Experiments
-
-   When discussing DNSSEC experiments, it is necessary to classify these
-   experiments into two broad categories:
-
-   Backwards-Compatible:  describes experimental changes that, while not
-      strictly adhering to the DNSSEC standard, are nonetheless
-      interoperable with clients and servers that do implement the
-      DNSSEC standard.
-
-   Non-Backwards-Compatible:  describes experiments that would cause a
-      standard security-aware resolver to (incorrectly) determine that
-      all or part of a zone is bogus, or to otherwise not interoperate
-      with standard DNSSEC clients and servers.
-
-   Not included in these terms are experiments with the core DNS
-   protocol itself.
-
-   The methodology described in this document is not necessary for
-   backwards-compatible experiments, although it certainly may be used
-   if desired.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006                [Page 5]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-4.  Method
-
-   The core of the methodology is the use of strictly unknown algorithm
-   identifiers when signing the experimental zone, and more importantly,
-   having only unknown algorithm identifiers in the DS records for the
-   delegation to the zone at the parent.
-
-   This technique works because of the way DNSSEC-compliant validators
-   are expected to work in the presence of a DS set with only unknown
-   algorithm identifiers.  From [4], Section 5.2:
-
-      If the validator does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver has no supported
-      authentication path leading from the parent to the child.  The
-      resolver should treat this case as it would the case of an
-      authenticated NSEC RRset proving that no DS RRset exists, as
-      described above.
-
-   And further:
-
-      If the resolver does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver will not be able to
-      verify the authentication path to the child zone.  In this case,
-      the resolver SHOULD treat the child zone as if it were unsigned.
-
-   While this behavior isn't strictly mandatory (as marked by MUST), it
-   is likely that a validator would implement this behavior, or, more to
-   the point, it would handle this situation in a safe way (see below
-   (Section 6).)
-
-   Because we are talking about experiments, it is RECOMMENDED that
-   private algorithm numbers be used (see [3], appendix A.1.1.  Note
-   that secure handling of private algorithms requires special handing
-   by the validator logic.  See [6] for further details.)  Normally,
-   instead of actually inventing new signing algorithms, the recommended
-   path is to create alternate algorithm identifiers that are aliases
-   for the existing, known algorithms.  While, strictly speaking, it is
-   only necessary to create an alternate identifier for the mandatory
-   algorithms, it is suggested that all optional defined algorithms be
-   aliased as well.
-
-   It is RECOMMENDED that for a particular DNSSEC experiment, a
-   particular domain name base is chosen for all new algorithms, then
-   the algorithm number (or name) is prepended to it.  For example, for
-   experiment A, the base name of "dnssec-experiment-a.example.com" is
-   chosen.  Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
-   defined to be "3.dnssec-experiment-a.example.com" and
-   "5.dnssec-experiment-a.example.com".  However, any unique identifier
-
-
-
-Blacka                   Expires October 9, 2006                [Page 6]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-   will suffice.
-
-   Using this method, resolvers (or, more specifically, DNSSEC
-   validators) essentially indicate their ability to understand the
-   DNSSEC experiment's semantics by understanding what the new algorithm
-   identifiers signify.
-
-   This method creates two classes of security-aware servers and
-   resolvers: servers and resolvers that are aware of the experiment
-   (and thus recognize the experiment's algorithm identifiers and
-   experimental semantics), and servers and resolvers that are unaware
-   of the experiment.
-
-   This method also precludes any zone from being both in an experiment
-   and in a classic DNSSEC island of security.  That is, a zone is
-   either in an experiment and only experimentally validatable, or it is
-   not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006                [Page 7]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-5.  Defining an Experiment
-
-   The DNSSEC experiment MUST define the particular set of (previously
-   unknown) algorithm identifiers that identify the experiment, and
-   define what each unknown algorithm identifier means.  Typically,
-   unless the experiment is actually experimenting with a new DNSSEC
-   algorithm, this will be a mapping of private algorithm identifiers to
-   existing, known algorithms.
-
-   Normally the experiment will choose a DNS name as the algorithm
-   identifier base.  This DNS name SHOULD be under the control of the
-   authors of the experiment.  Then the experiment will define a mapping
-   between known mandatory and optional algorithms into this private
-   algorithm identifier space.  Alternately, the experiment MAY use the
-   OID private algorithm space instead (using algorithm number 254), or
-   MAY choose non-private algorithm numbers, although this would require
-   an IANA allocation.
-
-   For example, an experiment might specify in its description the DNS
-   name "dnssec-experiment-a.example.com" as the base name, and declare
-   that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
-   algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
-   alias of DNSSEC algorithm 5 (RSASHA1).
-
-   Resolvers MUST only recognize the experiment's semantics when present
-   in a zone signed by one or more of these algorithm identifiers.  This
-   is necessary to isolate the semantics of one experiment from any
-   others that the resolver might understand.
-
-   In general, resolvers involved in the experiment are expected to
-   understand both standard DNSSEC and the defined experimental DNSSEC
-   protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006                [Page 8]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-6.  Considerations
-
-   There are a number of considerations with using this methodology.
-
-   1.  Under some circumstances, it may be that the experiment will not
-       be sufficiently masked by this technique and may cause resolution
-       problem for resolvers not aware of the experiment.  For instance,
-       the resolver may look at a non-validatable response and conclude
-       that the response is bogus, either due to local policy or
-       implementation details.  This is not expected to be a common
-       case, however.
-
-   2.  It will not be possible for security-aware resolvers unaware of
-       the experiment to build a chain of trust through an experimental
-       zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006                [Page 9]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-7.  Use in Non-Experiments
-
-   This general methodology MAY be used for non-backwards compatible
-   DNSSEC protocol changes that start out as or become standards.  In
-   this case:
-
-   o  The protocol change SHOULD use public IANA allocated algorithm
-      identifiers instead of private algorithm identifiers.  This will
-      help identify the protocol change as a standard, rather than an
-      experiment.
-
-   o  Resolvers MAY recognize the protocol change in zones not signed
-      (or not solely signed) using the new algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006               [Page 10]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-8.  Security Considerations
-
-   Zones using this methodology will be considered insecure by all
-   resolvers except those aware of the experiment.  It is not generally
-   possible to create a secure delegation from an experimental zone that
-   will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006               [Page 11]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-9.  IANA Considerations
-
-   This document has no IANA actions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006               [Page 12]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-10.  References
-
-10.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-10.2.  Informative References
-
-   [5]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [6]  Austein, R. and S. Weiler, "Clarifications and Implementation
-        Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
-        (work in progress), January 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006               [Page 13]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-Author's Address
-
-   David Blacka
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: davidb@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                   Expires October 9, 2006               [Page 14]
-
-Internet-Draft             DNSSEC Experiments                 April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Blacka                   Expires October 9, 2006               [Page 15]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
deleted file mode 100644
index 7503c66ab3..0000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-Network Working Group                                          S. Weiler
-Internet-Draft                                               SPARTA, Inc
-Updates: 4034, 4035 (if approved)                               J. Ihren
-Expires: July 24, 2006                                     Autonomica AB
-                                                        January 20, 2006
-
-
-       Minimally Covering NSEC Records and DNSSEC On-line Signing
-               draft-ietf-dnsext-dnssec-online-signing-02
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 24, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how to construct DNSSEC NSEC resource records
-   that cover a smaller range of names than called for by RFC4034.  By
-   generating and signing these records on demand, authoritative name
-   servers can effectively stop the disclosure of zone contents
-   otherwise made possible by walking the chain of NSEC records in a
-   signed zone.
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 1]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Changes from ietf-01 to ietf-02
-
-   Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
-   and NSEC bits set, to be consistent with DNSSECbis -- previous text
-   said SHOULD.
-
-   Made the applicability statement a little less oppressive.
-
-Changes from ietf-00 to ietf-01
-
-   Added an applicability statement, making reference to ongoing work on
-   NSEC3.
-
-   Added the phrase "epsilon functions", which has been commonly used to
-   describe the technique and already appeared in the header of each
-   page, in place of "increment and decrement functions".  Also added an
-   explanatory sentence.
-
-   Corrected references from 4034 section 6.2 to section 6.1.
-
-   Fixed an out-of-date reference to [-bis] and other typos.
-
-   Replaced IANA Considerations text.
-
-   Escaped close parentheses in examples.
-
-   Added some more acknowledgements.
-
-Changes from weiler-01 to ietf-00
-
-   Inserted RFC numbers for 4033, 4034, and 4035.
-
-   Specified contents of bitmap field in synthesized NSEC RR's, pointing
-   out that this relaxes a constraint in 4035.  Added 4035 to the
-   Updates header.
-
-Changes from weiler-00 to weiler-01
-
-   Clarified that this updates RFC4034 by relaxing requirements on the
-   next name field.
-
-   Added examples covering wildcard names.
-
-   In the 'better functions' section, reiterated that perfect functions
-   aren't needed.
-
-   Added a reference to RFC 2119.
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 2]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Table of Contents
-
-   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
-   2.  Applicability of This Technique  . . . . . . . . . . . . . . .  4
-   3.  Minimally Covering NSEC Records  . . . . . . . . . . . . . . .  5
-   4.  Better Epsilon Functions . . . . . . . . . . . . . . . . . . .  6
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  8
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 3]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-1.  Introduction and Terminology
-
-   With DNSSEC [1], an NSEC record lists the next instantiated name in
-   its zone, proving that no names exist in the "span" between the
-   NSEC's owner name and the name in the "next name" field.  In this
-   document, an NSEC record is said to "cover" the names between its
-   owner name and next name.
-
-   Through repeated queries that return NSEC records, it is possible to
-   retrieve all of the names in the zone, a process commonly called
-   "walking" the zone.  Some zone owners have policies forbidding zone
-   transfers by arbitrary clients; this side-effect of the NSEC
-   architecture subverts those policies.
-
-   This document presents a way to prevent zone walking by constructing
-   NSEC records that cover fewer names.  These records can make zone
-   walking take approximately as many queries as simply asking for all
-   possible names in a zone, making zone walking impractical.  Some of
-   these records must be created and signed on demand, which requires
-   on-line private keys.  Anyone contemplating use of this technique is
-   strongly encouraged to review the discussion of the risks of on-line
-   signing in Section 6.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [4].
-
-
-2.  Applicability of This Technique
-
-   The technique presented here may be useful to a zone owner that wants
-   to use DNSSEC, is concerned about exposure of its zone contents via
-   zone walking, and is willing to bear the costs of on-line signing.
-
-   As discussed in Section 6, on-line signing has several security
-   risks, including an increased likelihood of private keys being
-   disclosed and an increased risk of denial of service attack.  Anyone
-   contemplating use of this technique is strongly encouraged to review
-   the discussion of the risks of on-line signing in Section 6.
-
-   Furthermore, at the time this document was published, the DNSEXT
-   working group was actively working on a mechanism to prevent zone
-   walking that does not require on-line signing (tentatively called
-   NSEC3).  The new mechanism is likely to expose slightly more
-   information about the zone than this technique (e.g. the number of
-   instantiated names), but it may be preferable to this technique.
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 4]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-3.  Minimally Covering NSEC Records
-
-   This mechanism involves changes to NSEC records for instantiated
-   names, which can still be generated and signed in advance, as well as
-   the on-demand generation and signing of new NSEC records whenever a
-   name must be proven not to exist.
-
-   In the 'next name' field of instantiated names' NSEC records, rather
-   than list the next instantiated name in the zone, list any name that
-   falls lexically after the NSEC's owner name and before the next
-   instantiated name in the zone, according to the ordering function in
-   RFC4034 [2] section 6.1.  This relaxes the requirement in section
-   4.1.1 of RFC4034 that the 'next name' field contains the next owner
-   name in the zone.  This change is expected to be fully compatible
-   with all existing DNSSEC validators.  These NSEC records are returned
-   whenever proving something specifically about the owner name (e.g.
-   that no resource records of a given type appear at that name).
-
-   Whenever an NSEC record is needed to prove the non-existence of a
-   name, a new NSEC record is dynamically produced and signed.  The new
-   NSEC record has an owner name lexically before the QNAME but
-   lexically following any existing name and a 'next name' lexically
-   following the QNAME but before any existing name.
-
-   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
-   bits set and SHOULD NOT have any other bits set.  This relaxes the
-   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
-   names that did not exist before the zone was signed.
-
-   The functions to generate the lexically following and proceeding
-   names need not be perfect nor consistent, but the generated NSEC
-   records must not cover any existing names.  Furthermore, this
-   technique works best when the generated NSEC records cover as few
-   names as possible.  In this document, the functions that generate the
-   nearby names are called 'epsilon' functions, a reference to the
-   mathematical convention of using the greek letter epsilon to
-   represent small deviations.
-
-   An NSEC record denying the existence of a wildcard may be generated
-   in the same way.  Since the NSEC record covering a non-existent
-   wildcard is likely to be used in response to many queries,
-   authoritative name servers using the techniques described here may
-   want to pregenerate or cache that record and its corresponding RRSIG.
-
-   For example, a query for an A record at the non-instantiated name
-   example.com might produce the following two NSEC records, the first
-   denying the existence of the name example.com and the second denying
-   the existence of a wildcard:
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 5]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-             exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
-
-             \).com 3600 IN NSEC +.com ( RRSIG NSEC )
-
-   Before answering a query with these records, an authoritative server
-   must test for the existence of names between these endpoints.  If the
-   generated NSEC would cover existing names (e.g. exampldd.com or
-   *bizarre.example.com), a better epsilon function may be used or the
-   covered name closest to the QNAME could be used as the NSEC owner
-   name or next name, as appropriate.  If an existing name is used as
-   the NSEC owner name, that name's real NSEC record MUST be returned.
-   Using the same example, assuming an exampldd.com delegation exists,
-   this record might be returned from the parent:
-
-             exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
-
-   Like every authoritative record in the zone, each generated NSEC
-   record MUST have corresponding RRSIGs generated using each algorithm
-   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
-   described in RFC4035 [3] section 2.2.  To minimize the number of
-   signatures that must be generated, a zone may wish to limit the
-   number of algorithms in its DNSKEY RRset.
-
-
-4.  Better Epsilon Functions
-
-   Section 6.1 of RFC4034 defines a strict ordering of DNS names.
-   Working backwards from that definition, it should be possible to
-   define epsilon functions that generate the immediately following and
-   preceding names, respectively.  This document does not define such
-   functions.  Instead, this section presents functions that come
-   reasonably close to the perfect ones.  As described above, an
-   authoritative server should still ensure than no generated NSEC
-   covers any existing name.
-
-   To increment a name, add a leading label with a single null (zero-
-   value) octet.
-
-   To decrement a name, decrement the last character of the leftmost
-   label, then fill that label to a length of 63 octets with octets of
-   value 255.  To decrement a null (zero-value) octet, remove the octet
-   -- if an empty label is left, remove the label.  Defining this
-   function numerically: fill the left-most label to its maximum length
-   with zeros (numeric, not ASCII zeros) and subtract one.
-
-   In response to a query for the non-existent name foo.example.com,
-   these functions produce NSEC records of:
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 6]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
-
-     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
-
-   The first of these NSEC RRs proves that no exact match for
-   foo.example.com exists, and the second proves that there is no
-   wildcard in example.com.
-
-   Both of these functions are imperfect: they don't take into account
-   constraints on number of labels in a name nor total length of a name.
-   As noted in the previous section, though, this technique does not
-   depend on the use of perfect epsilon functions: it is sufficient to
-   test whether any instantiated names fall into the span covered by the
-   generated NSEC and, if so, substitute those instantiated owner names
-   for the NSEC owner name or next name, as appropriate.
-
-
-5.  IANA Considerations
-
-   This document specifies no IANA Actions.
-
-
-6.  Security Considerations
-
-   This approach requires on-demand generation of RRSIG records.  This
-   creates several new vulnerabilities.
-
-   First, on-demand signing requires that a zone's authoritative servers
-   have access to its private keys.  Storing private keys on well-known
-   internet-accessible servers may make them more vulnerable to
-   unintended disclosure.
-
-   Second, since generation of digital signatures tends to be
-   computationally demanding, the requirement for on-demand signing
-   makes authoritative servers vulnerable to a denial of service attack.
-
-   Lastly, if the epsilon functions are predictable, on-demand signing
-   may enable a chosen-plaintext attack on a zone's private keys.  Zones
-   using this approach should attempt to use cryptographic algorithms
-   that are resistant to chosen-plaintext attacks.  It's worth noting
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 7]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-   that while DNSSEC has a "mandatory to implement" algorithm, that is a
-   requirement on resolvers and validators -- there is no requirement
-   that a zone be signed with any given algorithm.
-
-   The success of using minimally covering NSEC record to prevent zone
-   walking depends greatly on the quality of the epsilon functions
-   chosen.  An increment function that chooses a name obviously derived
-   from the next instantiated name may be easily reverse engineered,
-   destroying the value of this technique.  An increment function that
-   always returns a name close to the next instantiated name is likewise
-   a poor choice.  Good choices of epsilon functions are the ones that
-   produce the immediately following and preceding names, respectively,
-   though zone administrators may wish to use less perfect functions
-   that return more human-friendly names than the functions described in
-   Section 4 above.
-
-   Another obvious but misguided concern is the danger from synthesized
-   NSEC records being replayed.  It's possible for an attacker to replay
-   an old but still validly signed NSEC record after a new name has been
-   added in the span covered by that NSEC, incorrectly proving that
-   there is no record at that name.  This danger exists with DNSSEC as
-   defined in [3].  The techniques described here actually decrease the
-   danger, since the span covered by any NSEC record is smaller than
-   before.  Choosing better epsilon functions will further reduce this
-   danger.
-
-7.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-
-Appendix A.  Acknowledgments
-
-   Many individuals contributed to this design.  They include, in
-   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 8]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
-   Jakob Schlyter, Bill Manning, and Joao Damas.
-
-   In addition, the editors would like to thank Ed Lewis, Scott Rose,
-   and David Blacka for their careful review of the document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 9]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Authors' Addresses
-
-   Samuel Weiler
-   SPARTA, Inc
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   Email: weiler@tislabs.com
-
-
-   Johan Ihren
-   Autonomica AB
-   Bellmansgatan 30
-   Stockholm  SE-118 47
-   Sweden
-
-   Email: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                [Page 10]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                [Page 11]
-
diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
deleted file mode 100644
index 2460cb619b..0000000000
--- a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-Network Working Group                                        W. Hardaker
-Internet-Draft                                                    Sparta
-Expires: August 25, 2006                               February 21, 2006
-
-
- Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
-                   draft-ietf-dnsext-ds-sha256-05.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 25, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document specifies how to use the SHA-256 digest type in DNS
-   Delegation Signer (DS) Resource Records (RRs).  DS records, when
-   stored in a parent zone, point to key signing DNSKEY key(s) in a
-   child zone.
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 1]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Implementing the SHA-256 algorithm for DS record support  . . . 3
-     2.1.  DS record field values  . . . . . . . . . . . . . . . . . . 3
-     2.2.  DS Record with SHA-256 Wire Format  . . . . . . . . . . . . 3
-     2.3.  Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
-   3.  Implementation Requirements . . . . . . . . . . . . . . . . . . 4
-   4.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-     6.1.  Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
-     6.2.  SHA-1 vs SHA-256 Considerations for DS Records  . . . . . . 6
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 2]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-1.  Introduction
-
-   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
-   zones to distribute a cryptographic digest of a child's Key Signing
-   Key (KSK) DNSKEY RR.  The DS RRset is signed by at least one of the
-   parent zone's private zone data signing keys for each algorithm in
-   use by the parent.  Each signature is published in an RRSIG resource
-   record, owned by the same domain as the DS RRset and with a type
-   covered of DS.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Implementing the SHA-256 algorithm for DS record support
-
-   This document specifies that the digest type code [XXX: To be
-   assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
-   [SHA256CODE] for use within DS records.  The results of the digest
-   algorithm MUST NOT be truncated and the entire 32 byte digest result
-   is to be published in the DS record.
-
-2.1.  DS record field values
-
-   Using the SHA-256 digest algorithm within a DS record will make use
-   of the following DS-record fields:
-
-   Digest type: [XXX: To be assigned by IANA; likely 2]
-
-   Digest: A SHA-256 bit digest value calculated by using the following
-      formula ("|" denotes concatenation).  The resulting value is not
-      truncated and the entire 32 byte result is to used in the
-      resulting DS record and related calculations.
-
-        digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
-
-      where DNSKEY RDATA is defined by [RFC4034] as:
-
-        DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
-
-   The Key Tag field and Algorithm fields remain unchanged by this
-   document and are specified in the [RFC4034] specification.
-
-2.2.  DS Record with SHA-256 Wire Format
-
-   The resulting on-the-wire format for the resulting DS record will be
-   [XXX: IANA assignment should replace the 2 below]:
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 3]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |           Key Tag             |  Algorithm    | DigestType=2  |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                                                               /
-      /            Digest  (length for SHA-256 is 32 bytes)           /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-2.3.  Example DS Record Using SHA-256
-
-   The following is an example DNSKEY and matching DS record.  This
-   DNSKEY record comes from the example DNSKEY/DS records found in
-   section 5.4 of [RFC4034].
-
-   The DNSKEY record:
-
-   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
-                                                fwJr1AYtsmx3TGkJaNXVbfi/
-                                                2pHm822aJ5iI9BMzNXxeYCmZ
-                                                DRD99WYwYqUSdjMmmAphXdvx
-                                                egXd/M5+X7OrzKBaMbCVdFLU
-                                                Uh6DhweJBjEVv5f2wwjM9Xzc
-                                                nOf+EPbtG9DMBmADjFDc2w/r
-                                                ljwvFw==
-                                                ) ;  key id = 60485
-
-   The resulting DS record covering the above DNSKEY record using a SHA-
-   256 digest: [RFC Editor: please replace XXX with the assigned digest
-   type (likely 2):]
-
-   dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
-                                                CEB1E3E0614B93C4F9E99B83
-                                                83F6A1E4469DA50A )
-
-
-3.  Implementation Requirements
-
-   Implementations MUST support the use of the SHA-256 algorithm in DS
-   RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
-   digests if DS RRs with SHA-256 digests are present in the DS RRset.
-
-
-4.  Deployment Considerations
-
-   If a validator does not support the SHA-256 digest type and no other
-   DS RR exists in a zone's DS RRset with a supported digest type, then
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 4]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-   the validator has no supported authentication path leading from the
-   parent to the child.  The resolver should treat this case as it would
-   the case of an authenticated NSEC RRset proving that no DS RRset
-   exists, as described in [RFC4035], section 5.2.
-
-   Because zone administrators can not control the deployment speed of
-   support for SHA-256 in validators that may be referencing any of
-   their zones, zone operators should consider deploying both SHA-1 and
-   SHA-256 based DS records.  This should be done for every DNSKEY for
-   which DS records are being generated.  Whether to make use of both
-   digest types and for how long is a policy decision that extends
-   beyond the scope of this document.
-
-
-5.  IANA Considerations
-
-   Only one IANA action is required by this document:
-
-   The Digest Type to be used for supporting SHA-256 within DS records
-   needs to be assigned by IANA.  This document requests that the Digest
-   Type value of 2 be assigned to the SHA-256 digest algorithm.
-
-   At the time of this writing, the current digest types assigned for
-   use in DS records are as follows:
-
-      VALUE     Digest Type          Status
-        0       Reserved                -
-        1       SHA-1                MANDATORY
-        2       SHA-256              MANDATORY
-      3-255    Unassigned               -
-
-
-6.  Security Considerations
-
-6.1.  Potential Digest Type Downgrade Attacks
-
-   A downgrade attack from a stronger digest type to a weaker one is
-   possible if all of the following are true:
-
-   o  A zone includes multiple DS records for a given child's DNSKEY,
-      each of which use a different digest type.
-
-   o  A validator accepts a weaker digest even if a stronger one is
-      present but invalid.
-
-   For example, if the following conditions are all true:
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 5]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-   o  Both SHA-1 and SHA-256 based digests are published in DS records
-      within a parent zone for a given child zone's DNSKEY.
-
-   o  The DS record with the SHA-1 digest matches the digest computed
-      using the child zone's DNSKEY.
-
-   o  The DS record with the SHA-256 digest fails to match the digest
-      computed using the child zone's DNSKEY.
-
-   Then if the validator accepts the above situation as secure then this
-   can be used as a downgrade attack since the stronger SHA-256 digest
-   is ignored.
-
-6.2.  SHA-1 vs SHA-256 Considerations for DS Records
-
-   Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
-   implementations allow for it.  SHA-256 is widely believed to be more
-   resilient to attack than SHA-1, and confidence in SHA-1's strength is
-   being eroded by recently-announced attacks.  Regardless of whether or
-   not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
-   time of this writing) that SHA-256 is the better choice for use in DS
-   records.
-
-   At the time of this publication, the SHA-256 digest algorithm is
-   considered sufficiently strong for the immediate future.  It is also
-   considered sufficient for use in DNSSEC DS RRs for the immediate
-   future.  However, future published attacks may weaken the usability
-   of this algorithm within the DS RRs.  It is beyond the scope of this
-   document to speculate extensively on the cryptographic strength of
-   the SHA-256 digest algorithm.
-
-   Likewise, it is also beyond the scope of this document to specify
-   whether or for how long SHA-1 based DS records should be
-   simultaneously published alongside SHA-256 based DS records.
-
-
-7.  Acknowledgments
-
-   This document is a minor extension to the existing DNSSEC documents
-   and those authors are gratefully appreciated for the hard work that
-   went into the base documents.
-
-   The following people contributed to portions of this document in some
-   fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
-   Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
-   Weiler.
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 6]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [SHA256]   National Institute of Standards and Technology, "Secure
-              Hash Algorithm. NIST FIPS 180-2", August 2002.
-
-8.2.  Informative References
-
-   [SHA256CODE]
-              Eastlake, D., "US Secure Hash Algorithms (SHA)",
-              June 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 7]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-Author's Address
-
-   Wes Hardaker
-   Sparta
-   P.O. Box 382
-   Davis, CA  95617
-   US
-
-   Email: hardaker@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 8]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 9]
-
diff --git a/doc/draft/draft-ietf-dnsext-mdns-46.txt b/doc/draft/draft-ietf-dnsext-mdns-46.txt
deleted file mode 100644
index 63d0b23af6..0000000000
--- a/doc/draft/draft-ietf-dnsext-mdns-46.txt
+++ /dev/null
@@ -1,1801 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group                                       Bernard Aboba
-INTERNET-DRAFT                                               Dave Thaler
-Category: Standards Track                                   Levon Esibov
-<draft-ietf-dnsext-mdns-46.txt>                    Microsoft Corporation
-16 April 2006
-
-              Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on October 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2006.
-
-Abstract
-
-   The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
-   name resolution in scenarios in which conventional DNS name
-   resolution is not possible.  LLMNR supports all current and future
-   DNS formats, types and classes, while operating on a separate port
-   from DNS, and with a distinct resolver cache.  Since LLMNR only
-   operates on the local link, it cannot be considered a substitute for
-   DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 1]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-Table of Contents
-
-1.     Introduction ..........................................    3
-   1.1       Requirements ....................................    4
-   1.2       Terminology .....................................    4
-2.     Name Resolution Using LLMNR ...........................    4
-   2.1       LLMNR Packet Format .............................    5
-   2.2       Sender Behavior .................................    8
-   2.3       Responder Behavior ..............................    8
-   2.4       Unicast Queries and Responses ...................   11
-   2.5       Off-link Detection ..............................   11
-   2.6       Responder Responsibilities ......................   12
-   2.7       Retransmission and Jitter .......................   13
-   2.8       DNS TTL .........................................   14
-   2.9       Use of the Authority and Additional Sections ....   14
-3.     Usage model ...........................................   15
-   3.1       LLMNR Configuration .............................   16
-4.     Conflict Resolution ...................................   18
-   4.1       Uniqueness Verification .........................   18
-   4.2       Conflict Detection and Defense ..................   19
-   4.3       Considerations for Multiple Interfaces ..........   20
-   4.4       API issues ......................................   22
-5.     Security Considerations ...............................   22
-   5.1       Denial of Service ...............................   22
-   5.2       Spoofing ...............,........................   23
-   5.3       Authentication ..................................   24
-   5.4       Cache and Port Separation .......................   24
-6.     IANA considerations ...................................   25
-7.     Constants .............................................   25
-8.     References ............................................   26
-   8.1       Normative References ............................   26
-   8.2       Informative References ..........................   26
-Acknowledgments ..............................................   28
-Authors' Addresses ...........................................   28
-Intellectual Property Statement ..............................   29
-Disclaimer of Validity .......................................   29
-Copyright Statement ..........................................   29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 2]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-1.  Introduction
-
-   This document discusses Link Local Multicast Name Resolution (LLMNR),
-   which is based on the DNS packet format and supports all current and
-   future DNS formats, types and classes.  LLMNR operates on a separate
-   port from the Domain Name System (DNS), with a distinct resolver
-   cache.
-
-   Since LLMNR only operates on the local link, it cannot be considered
-   a substitute for DNS.  Link-scope multicast addresses are used to
-   prevent propagation of LLMNR traffic across routers, potentially
-   flooding the network.  LLMNR queries can also be sent to a unicast
-   address, as described in Section 2.4.
-
-   Propagation of LLMNR packets on the local link is considered
-   sufficient to enable name resolution in small networks.  In such
-   networks, if a network has a gateway, then typically the network is
-   able to provide DNS server configuration.  Configuration issues are
-   discussed in Section 3.1.
-
-   In the future, it may be desirable to consider use of multicast name
-   resolution with multicast scopes beyond the link-scope.  This could
-   occur if LLMNR deployment is successful, the need arises for
-   multicast name resolution beyond the link-scope, or multicast routing
-   becomes ubiquitous.  For example, expanded support for multicast name
-   resolution might be required for mobile ad-hoc networks.
-
-   Once we have experience in LLMNR deployment in terms of
-   administrative issues, usability and impact on the network, it will
-   be possible to reevaluate which multicast scopes are appropriate for
-   use with multicast name resolution.  IPv4 administratively scoped
-   multicast usage is specified in "Administratively Scoped IP
-   Multicast" [RFC2365].
-
-   Service discovery in general, as well as discovery of DNS servers
-   using LLMNR in particular, is outside of the scope of this document,
-   as is name resolution over non-multicast capable media.
-
-1.1.  Requirements
-
-   In this document, several words are used to signify the requirements
-   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
-   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
-   and "OPTIONAL" in this document are to be interpreted as described in
-   [RFC2119].
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 3]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-1.2.  Terminology
-
-   This document assumes familiarity with DNS terminology defined in
-   [RFC1035].  Other terminology used in this document includes:
-
-Routable Address
-     An address other than a Link-Local address.  This includes globally
-     routable addresses, as well as private addresses.
-
-Reachable
-     An LLMNR responder considers one of its addresses reachable over a
-     link if it will respond to an ARP or Neighbor Discovery query for
-     that address received on that link.
-
-Responder
-     A host that listens to LLMNR queries, and responds to those for
-     which it is authoritative.
-
-Sender
-     A host that sends an LLMNR query.
-
-UNIQUE
-     There are some scenarios when multiple responders may respond to
-     the same query.  There are other scenarios when only one responder
-     may respond to a query.  Names for which only a single responder is
-     anticipated are referred to as UNIQUE.  Name uniqueness is
-     configured on the responder, and therefore uniqueness verification
-     is the responder's responsibility.
-
-2.  Name Resolution Using LLMNR
-
-   LLMNR queries are sent to and received on port 5355.  The IPv4 link-
-   scope multicast address a given responder listens to, and to which a
-   sender sends queries, is 224.0.0.252.  The IPv6 link-scope multicast
-   address a given responder listens to, and to which a sender sends all
-   queries, is FF02:0:0:0:0:0:1:3.
-
-   Typically a host is configured as both an LLMNR sender and a
-   responder.  A host MAY be configured as a sender, but not a
-   responder.  However, a host configured as a responder MUST act as a
-   sender, if only to verify the uniqueness of names as described in
-   Section 4.  This document does not specify how names are chosen or
-   configured.  This may occur via any mechanism, including DHCPv4
-   [RFC2131] or DHCPv6 [RFC3315].
-
-   A typical sequence of events for LLMNR usage is as follows:
-
-   [a]  An LLMNR sender sends an LLMNR query to the link-scope
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 4]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-        multicast address(es), unless a unicast query is indicated,
-        as specified in Section 2.4.
-
-   [b]  A responder responds to this query only if it is authoritative
-        for the name in the query.  A responder responds to a
-        multicast query by sending a unicast UDP response to the sender.
-        Unicast queries are responded to as indicated in Section 2.4.
-
-   [c]  Upon reception of the response, the sender processes it.
-
-   The sections that follow provide further details on sender and
-   responder behavior.
-
-2.1.  LLMNR Packet Format
-
-   LLMNR is based on the DNS packet format defined in [RFC1035] Section
-   4 for both queries and responses.  LLMNR implementations SHOULD send
-   UDP queries and responses only as large as are known to be
-   permissible without causing fragmentation.  When in doubt a maximum
-   packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
-   accept UDP queries and responses as large as the smaller of the link
-   MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
-   octets for the header, VLAN tag and CRC).
-
-2.1.1.  LLMNR Header Format
-
-   LLMNR queries and responses utilize the DNS header format defined in
-   [RFC1035] with exceptions noted below:
-
-                                   1  1  1  1  1  1
-     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                      ID                       |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |QR|   Opcode  | C|TC| T| Z| Z| Z| Z|   RCODE   |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    QDCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ANCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    NSCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ARCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 5]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-ID   A 16 bit identifier assigned by the program that generates any kind
-     of query.  This identifier is copied from the query to the response
-     and can be used by the sender to match responses to outstanding
-     queries. The ID field in a query SHOULD be set to a pseudo-random
-     value.  For advice on generation of pseudo-random values, please
-     consult [RFC1750].
-
-QR   Query/Response.  A one bit field, which if set indicates that the
-     message is an LLMNR response; if clear then the message is an LLMNR
-     query.
-
-OPCODE
-     A four bit field that specifies the kind of query in this message.
-     This value is set by the originator of a query and copied into the
-     response.  This specification defines the behavior of standard
-     queries and responses (opcode value of zero).  Future
-     specifications may define the use of other opcodes with LLMNR.
-     LLMNR senders and responders MUST support standard queries (opcode
-     value of zero).  LLMNR queries with unsupported OPCODE values MUST
-     be silently discarded by responders.
-
-C    Conflict.  When set within a request, the 'C'onflict bit indicates
-     that a sender has received multiple LLMNR responses to this query.
-     In an LLMNR response, if the name is considered UNIQUE, then the
-     'C' bit is clear, otherwise it is set.  LLMNR senders do not
-     retransmit queries with the 'C' bit set.  Responders MUST NOT
-     respond to LLMNR queries with the 'C' bit set, but may start the
-     uniqueness verification process, as described in Section 4.2.
-
-TC   TrunCation - specifies that this message was truncated due to
-     length greater than that permitted on the transmission channel.
-     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
-     by an LLMNR responder.  If the TC bit is set in an LLMNR response,
-     then the sender SHOULD resend the LLMNR query over TCP using the
-     unicast address of the responder as the destination address.  If
-     the sender receives a response to the TCP query, then it SHOULD
-     discard the UDP response with the TC bit set.  See  [RFC2181] and
-     Section 2.4 of this specification for further discussion of the TC
-     bit.
-
-T    Tentative.  The 'T'entative bit is set in a response if the
-     responder is authoritative for the name, but has not yet verified
-     the uniqueness of the name.  A responder MUST ignore the 'T' bit in
-     a query, if set.  A response with the 'T' bit set is silently
-     discarded by the sender, except if it is a uniqueness query, in
-     which case a conflict has been detected and a responder MUST
-     resolve the conflict as described in Section 4.1.
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 6]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-Z    Reserved for future use.  Implementations of this specification
-     MUST set these bits to zero in both queries and responses.  If
-     these bits are set in a LLMNR query or response, implementations of
-     this specification MUST ignore them.  Since reserved bits could
-     conceivably be used for different purposes than in DNS,
-     implementors are advised not to enable processing of these bits in
-     an LLMNR implementation starting from a DNS code base.
-
-RCODE
-     Response code -- this 4 bit field is set as part of LLMNR
-     responses.  In an LLMNR query, the sender MUST set RCODE to zero;
-     the responder ignores the RCODE and assumes it to be zero.  The
-     response to a multicast LLMNR query MUST have RCODE set to zero.  A
-     sender MUST silently discard an LLMNR response with a non-zero
-     RCODE sent in response to a multicast query.
-
-     If an LLMNR responder is authoritative for the name in a multicast
-     query, but an error is encountered, the responder SHOULD send an
-     LLMNR response with an RCODE of zero, no RRs in the answer section,
-     and the TC bit set.  This will cause the query to be resent using
-     TCP, and allow the inclusion of a non-zero RCODE in the response to
-     the TCP query.  Responding with the TC bit set is preferable to not
-     sending a response, since it enables errors to be diagnosed.  This
-     may be required, for example, when an LLMNR query includes a TSIG
-     RR in the additional section, and the responder encounters a
-     problem that requires returning a non-zero RCODE.  TSIG error
-     conditions defined in [RFC2845] include a TSIG RR in an
-     unacceptable position (RCODE=1) or a TSIG RR which does not
-     validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)).
-
-     Since LLMNR responders only respond to LLMNR queries for names for
-     which they are authoritative, LLMNR responders MUST NOT respond
-     with an RCODE of 3; instead, they should not respond at all.
-
-     LLMNR implementations MUST support EDNS0 [RFC2671] and extended
-     RCODE values.
-
-QDCOUNT
-     An unsigned 16 bit integer specifying the number of entries in the
-     question section.  A sender MUST place only one question into the
-     question section of an LLMNR query.  LLMNR responders MUST silently
-     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
-     MUST silently discard LLMNR responses with QDCOUNT not equal to
-     one.
-
-ANCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the answer section.  LLMNR responders MUST silently
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 7]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-     discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
-     An unsigned 16 bit integer specifying the number of name server
-     resource records in the authority records section.  Authority
-     record section processing is described in Section 2.9.  LLMNR
-     responders MUST silently discard LLMNR queries with NSCOUNT not
-     equal to zero.
-
-ARCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the additional records section.  Additional record
-     section processing is described in Section 2.9.
-
-2.2.  Sender Behavior
-
-   A sender MAY send an LLMNR query for any legal resource record  type
-   (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
-   As described in Section 2.4, a sender MAY also send a unicast query.
-
-   The sender MUST anticipate receiving no replies to some LLMNR
-   queries, in the event that no responders are available within the
-   link-scope.  If no response is received, a resolver treats it as a
-   response that the name does not exist (RCODE=3 is returned).  A
-   sender can handle duplicate responses by discarding responses with a
-   source IP address and ID field that duplicate a response already
-   received.
-
-   When multiple valid LLMNR responses are received with the 'C' bit
-   set, they SHOULD be concatenated and treated in the same manner that
-   multiple RRs received from the same DNS server would be.  However,
-   responses with the 'C' bit set SHOULD NOT be concatenated with
-   responses with the 'C' bit clear; instead, only the responses with
-   the 'C' bit set SHOULD be returned.  If valid LLMNR response(s) are
-   received along with error response(s), then the error responses are
-   silently discarded.
-
-   Since the responder may order the RRs in the response so as to
-   indicate preference, the sender SHOULD preserve ordering in the
-   response to the querying application.
-
-2.3.  Responder Behavior
-
-   An LLMNR response MUST be sent to the sender via unicast.
-
-   Upon configuring an IP address, responders typically will synthesize
-   corresponding A, AAAA and PTR RRs so as to be able to respond to
-   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 8]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   responder has another RR in addition to the SOA RR;  the SOA RR MUST
-   NOT be the only RR that a responder has.  However, in general whether
-   RRs are manually or automatically created is an implementation
-   decision.
-
-   For example, a host configured to have computer name "host1" and to
-   be a member of the "example.com" domain, and with IPv4 address
-   192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
-   authoritative for the following records:
-
-   host1. IN A 192.0.2.1
-          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   host1.example.com. IN A 192.0.2.1
-          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   1.2.0.192.in-addr.arpa. IN PTR host1.
-          IN PTR host1.example.com.
-
-   6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
-   ip6.arpa IN PTR host1.  (line split for formatting reasons)
-            IN PTR host1.example.com.
-
-   An LLMNR responder might be further manually configured with the name
-   of a local mail server with an MX RR included in the "host1." and
-   "host1.example.com." records.
-
-   In responding to queries:
-
-[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
-     address(es) defined in Section 2, and on TCP port 5355 on the
-     unicast address(es) that could be set as the source address(es)
-     when the responder responds to the LLMNR query.
-
-[b]  Responders MUST direct responses to the port from which the query
-     was sent.  When queries are received via TCP this is an inherent
-     part of the transport protocol.  For queries received by UDP the
-     responder MUST take note of the source port and use that as the
-     destination port in the response.  Responses MUST always be sent
-     from the port to which they were directed.
-
-[c]  Responders MUST respond to LLMNR queries for names and addresses
-     they are authoritative for.  This applies to both forward and
-     reverse lookups, with the exception of queries with the 'C' bit
-     set, which do not elicit a response.
-
-[d]  Responders MUST NOT respond to LLMNR queries for names they are not
-     authoritative for.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 9]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-[e]  Responders MUST NOT respond using data from the LLMNR or DNS
-     resolver cache.
-
-[f]  If a DNS server is running on a host that supports LLMNR, the DNS
-     server MUST respond to LLMNR queries only for the RRSets relating
-     to the host on which the server is running, but MUST NOT respond
-     for other records for which the server is authoritative.  DNS
-     servers also MUST NOT send LLMNR queries in order to resolve DNS
-     queries.
-
-[g]  If a responder is authoritative for a name, it MUST respond with
-     RCODE=0 and an empty answer section, if the type of query does not
-     match a RR that the responder has.
-
-   As an example, a host configured to respond to LLMNR queries for the
-   name "foo.example.com."  is authoritative for the name
-   "foo.example.com.".  On receiving an LLMNR query for an A RR with the
-   name "foo.example.com." the host authoritatively responds with A
-   RR(s) that contain IP address(es) in the RDATA of the resource
-   record.  If the responder has a AAAA RR, but no A RR, and an A RR
-   query is received, the responder would respond with RCODE=0 and an
-   empty answer section.
-
-   In conventional DNS terminology a DNS server authoritative for a zone
-   is authoritative for all the domain names under the zone apex except
-   for the branches delegated into separate zones.  Contrary to
-   conventional DNS terminology, an LLMNR responder is authoritative
-   only for the zone apex.
-
-   For example the host "foo.example.com." is not authoritative for the
-   name "child.foo.example.com." unless the host is configured with
-   multiple names, including "foo.example.com."  and
-   "child.foo.example.com.".  As a result, "foo.example.com." cannot
-   reply to an LLMNR query for "child.foo.example.com." with RCODE=3
-   (authoritative name error).  The purpose of limiting the name
-   authority scope of a responder is to prevent complications that could
-   be caused by coexistence of two or more hosts with the names
-   representing child and parent (or grandparent) nodes in the DNS tree,
-   for example, "foo.example.com." and "child.foo.example.com.".
-
-   Without the restriction on authority an LLMNR query for an A resource
-   record for the name "child.foo.example.com." would result in two
-   authoritative responses: RCODE=3 (authoritative name error) received
-   from "foo.example.com.", and a requested A record - from
-   "child.foo.example.com.".  To prevent this ambiguity, LLMNR enabled
-   hosts could perform a dynamic update of the parent (or grandparent)
-   zone with a delegation to a child zone;  for example a host
-   "child.foo.example.com." could send a dynamic update for the NS and
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 10]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   glue A record to "foo.example.com.".  However, this approach
-   significantly complicates implementation of LLMNR and would not be
-   acceptable for lightweight hosts.
-
-2.4.  Unicast Queries and Responses
-
-   Unicast queries SHOULD be sent when:
-
-   [a] A sender repeats a query after it received a response
-       with the TC bit set to the previous LLMNR multicast query, or
-
-   [b] The sender queries for a PTR RR of a fully formed IP address
-       within the "in-addr.arpa" or "ip6.arpa" zones.
-
-   Unicast LLMNR queries MUST be done using TCP and the responses MUST
-   be sent using the same TCP connection as the query.  Senders MUST
-   support sending TCP queries, and responders MUST support listening
-   for TCP queries. If the sender of a TCP query receives a response to
-   that query not using TCP, the response MUST be silently discarded.
-
-   Unicast UDP queries MUST be silently discarded.
-
-   A unicast PTR RR query for an off-link address will not elicit a
-   response, but instead an ICMP TTL or Hop Limit exceeded message will
-   be received.  An implementation receiving an ICMP message in response
-   to a TCP connection setup attempt can return immediately, treating
-   this as a response that no such name exists (RCODE=3 is returned).
-   An implementation that cannot process ICMP messages MAY send
-   multicast UDP queries for PTR RRs.  Since TCP implementations will
-   not retransmit prior to RTOmin, a considerable period will elapse
-   before TCP retransmits multiple times, resulting in a long timeout
-   for TCP PTR RR queries sent to an off-link destination.
-
-2.5.  "Off link" Detection
-
-   A sender MUST select a source address for LLMNR queries that is
-   assigned on the interface on which the query is sent.  The
-   destination address of an LLMNR query MUST be a link-scope multicast
-   address or a unicast address.
-
-   A responder MUST select a source address for responses that is
-   assigned on the interface on which the query was received.  The
-   destination address of an LLMNR response MUST be a unicast address.
-
-   On receiving an LLMNR query, the responder MUST check whether it was
-   sent to a LLMNR multicast addresses defined in Section 2.  If it was
-   sent to another multicast address, then the query MUST be silently
-   discarded.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 11]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
-   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
-   field in the IPv6 header and the TTL field in the IPv4 header of the
-   response to one (1).  The responder SHOULD set the TTL or Hop Limit
-   settings on the TCP listen socket to one (1) so that SYN-ACK packets
-   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
-   prevents an incoming connection from off-link since the sender will
-   not receive a SYN-ACK from the responder.
-
-   For UDP queries and responses, the Hop Limit field in the IPv6 header
-   and the TTL field in the IPV4 header MAY be set to any value.
-   However, it is RECOMMENDED that the value 255 be used for
-   compatibility with early implementations of [RFC3927].
-
-   Implementation note:
-
-      In the sockets API for IPv4 [POSIX], the IP_TTL and
-      IP_MULTICAST_TTL socket options are used to set the TTL of
-      outgoing unicast and multicast packets. The IP_RECVTTL socket
-      option is available on some platforms to retrieve the IPv4 TTL of
-      received packets with recvmsg().  [RFC2292] specifies similar
-      options for setting and retrieving the IPv6 Hop Limit.
-
-2.6.  Responder Responsibilities
-
-   It is the responsibility of the responder to ensure that RRs returned
-   in LLMNR responses MUST only include values that are valid on the
-   local interface, such as IPv4 or IPv6 addresses valid on the local
-   link or names defended using the mechanism described in Section 4.
-   IPv4 Link-Local addresses are defined in [RFC3927].  IPv6 Link-Local
-   addresses are defined in [RFC2373].  In particular:
-
-   [a] If a link-scope IPv6 address is returned in a AAAA RR,
-       that address MUST be valid on the local link over which
-       LLMNR is used.
-
-   [b] If an IPv4 address is returned, it MUST be reachable
-       through the link over which LLMNR is used.
-
-   [c] If a name is returned (for example in a CNAME, MX
-       or SRV RR), the name MUST be resolvable on the local
-       link over which LLMNR is used.
-
-   Where multiple addresses represent valid responses to a query, the
-   order in which the addresses are returned is as follows:
-
-   [d] If the source address of the query is a link-scope address,
-       then the responder SHOULD include a link-scope address first
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 12]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-       in the response, if available.
-
-   [e] If the source address of the query is a routable address,
-       then the responder MUST include a routable address first
-       in the response, if available.
-
-2.7.  Retransmission and Jitter
-
-   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
-   when to retransmit an LLMNR query.  An LLMNR sender SHOULD either
-   estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
-   high initial timeout.  Suggested constants are described in Section
-   7.
-
-   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
-   then a sender SHOULD repeat the transmission of the query in order to
-   assure that it was received by a host capable of responding to it.
-   An LLMNR query SHOULD NOT be sent more than three times.
-
-   Where LLMNR queries are sent using TCP, retransmission is handled by
-   the transport layer.  Queries with the 'C' bit set MUST be sent using
-   multicast UDP and MUST NOT be retransmitted.
-
-   An LLMNR sender cannot know in advance if a query sent using
-   multicast will receive no response, one response, or more than one
-   response.  An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
-   has been received, or if it is necessary to collect all potential
-   responses, such as if a uniqueness verification query is being made.
-   Otherwise an LLMNR sender SHOULD consider a multicast query answered
-   after the first response is received, if that response has the 'C'
-   bit clear.
-
-   However, if the first response has the 'C' bit set, then the sender
-   SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect
-   all possible responses.  When multiple valid answers are received,
-   they may first be concatenated, and then treated in the same manner
-   that multiple RRs received from the same DNS server would.  A unicast
-   query sender considers the query answered after the first response is
-   received.
-
-   Since it is possible for a response with the 'C' bit clear to be
-   followed by a response with the 'C' bit set, an LLMNR sender SHOULD
-   be prepared to process additional responses for the purposes of
-   conflict detection, even after it has considered a query answered.
-
-   In order to avoid synchronization, the transmission of each LLMNR
-   query and response SHOULD delayed by a time randomly selected from
-   the interval 0 to JITTER_INTERVAL.  This delay MAY be avoided by
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 13]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   responders responding with names which they have previously
-   determined to be UNIQUE (see Section 4 for details).
-
-2.8.  DNS TTL
-
-   The responder should insert a pre-configured TTL value in the records
-   returned in an LLMNR response.  A default value of 30 seconds is
-   RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc
-   networks), the TTL value may need to be reduced.
-
-   Due to the TTL minimalization necessary when caching an RRset, all
-   TTLs in an RRset MUST be set to the same value.
-
-2.9.  Use of the Authority and Additional Sections
-
-   Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
-   concept of delegation.  In LLMNR, the NS resource record type may be
-   stored and queried for like any other type, but it has no special
-   delegation semantics as it does in the DNS.  Responders MAY have NS
-   records associated with the names for which they are authoritative,
-   but they SHOULD NOT include these NS records in the authority
-   sections of responses.
-
-   Responders SHOULD insert an SOA record into the authority section of
-   a negative response, to facilitate negative caching as specified in
-   [RFC2308]. The TTL of this record is set from the minimum of the
-   MINIMUM field of the SOA record and the TTL of the SOA itself, and
-   indicates how long a resolver may cache the negative answer.  The
-   owner name of the SOA record (MNAME) MUST be set to the query name.
-   The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
-   by senders.  Negative responses without SOA records SHOULD NOT be
-   cached.
-
-   In LLMNR, the additional section is primarily intended for use by
-   EDNS0, TSIG and SIG(0).  As a result, unless the 'C' bit is set,
-   senders MAY only include pseudo RR-types in the additional section of
-   a query; unless the 'C' bit is set, responders MUST ignore the
-   additional section of queries containing other RR types.
-
-   In queries where the 'C' bit is set, the sender SHOULD include the
-   conflicting RRs in the additional section.  Since conflict
-   notifications are advisory, responders SHOULD log information from
-   the additional section, but otherwise MUST ignore the additional
-   section.
-
-   Senders MUST NOT cache RRs from the authority or additional section
-   of a response as answers, though they may be used for other purposes
-   such as negative caching.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 14]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-3.  Usage Model
-
-   LLMNR is a peer-to-peer name resolution protocol that is not intended
-   as a replacement for DNS; rather, it enables name resolution in
-   scenarios in which conventional DNS name resolution is not possible.
-   This includes situations in which hosts are not configured with the
-   address of a DNS server; where the DNS server is unavailable or
-   unreachable; where there is no DNS server authoritative for the name
-   of a host, or where the authoritative DNS server does not have the
-   desired RRs.
-
-   By default, an LLMNR sender SHOULD send LLMNR queries only for
-   single-label names.  In order to reduce unnecessary DNS queries, stub
-   resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS
-   queries for single-label names.  An LLMNR sender SHOULD NOT be
-   enabled to send a query for any name, except where security
-   mechanisms (described in Section 5.3) can be utilized.
-
-   Regardless of whether security mechanisms can be utilized, LLMNR
-   queries SHOULD NOT be sent unless one of the following conditions are
-   met:
-
-   [1] No manual or automatic DNS configuration has been performed.
-       If DNS server address(es) have been configured, a
-       host SHOULD attempt to reach DNS servers over all protocols
-       on which DNS server address(es) are configured, prior to sending
-       LLMNR queries.  For dual stack hosts configured with DNS server
-       address(es) for one protocol but not another, this implies that
-       DNS queries SHOULD be sent over the protocol configured with
-       a DNS server, prior to sending LLMNR queries.
-
-   [2] All attempts to resolve the name via DNS on all interfaces
-       have failed after exhausting the searchlist.  This can occur
-       because DNS servers did not respond, or because they
-       responded to DNS queries with RCODE=3 (Authoritative Name
-       Error) or RCODE=0, and an empty answer section.  Where a
-       single resolver call generates DNS queries for A and AAAA RRs,
-       an implementation MAY choose not to send LLMNR queries if any
-       of the DNS queries is successful.  An LLMNR query SHOULD only
-       be sent for the originally requested name;  a searchlist
-       is not used to form additional LLMNR queries.
-
-   Since LLMNR is a secondary name resolution mechanism, its usage is in
-   part determined by the behavior of DNS implementations.  In general,
-   robust DNS resolver implementations are more likely to avoid
-   unnecessary LLMNR queries.
-
-   As noted in [DNSPerf], even when DNS servers are configured, a
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 15]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   significant fraction of DNS queries do not receive a response, or
-   result in negative responses due to missing inverse mappings or NS
-   records that point to nonexistent or inappropriate hosts.  This has
-   the potential to result in a large number of unnecessary LLMNR
-   queries.
-
-   [RFC1536] describes common DNS implementation errors and fixes.  If
-   the proposed fixes are implemented, unnecessary LLMNR queries will be
-   reduced substantially, and so implementation of [RFC1536] is
-   recommended.
-
-   For example, [RFC1536] Section 1 describes issues with retransmission
-   and recommends implementation of a retransmission policy based on
-   round trip estimates, with exponential back-off.  [RFC1536] Section 4
-   describes issues with failover, and recommends that resolvers try
-   another server when they don't receive a response to a query.  These
-   policies are likely to avoid unnecessary LLMNR queries.
-
-   [RFC1536] Section 3 describes zero answer bugs, which if addressed
-   will also reduce unnecessary LLMNR queries.
-
-   [RFC1536] Section 6 describes name error bugs and recommended
-   searchlist processing that will reduce unnecessary RCODE=3
-   (authoritative name) errors, thereby also reducing unnecessary LLMNR
-   queries.
-
-   If error responses are received from both DNS and LLMNR, then the
-   lowest RCODE value should be returned.  For example, if either DNS or
-   LLMNR receives a response with RCODE=0, then this should returned to
-   the caller.
-
-3.1.  LLMNR Configuration
-
-   LLMNR usage MAY be configured manually or automatically on a per
-   interface basis.  By default, LLMNR responders SHOULD be enabled on
-   all interfaces, at all times.  Enabling LLMNR for use in situations
-   where a DNS server has been configured will result in a change in
-   default behavior without a simultaneous update to configuration
-   information.  Where this is considered undesirable, LLMNR SHOULD NOT
-   be enabled by default, so that hosts will neither listen on the link-
-   scope multicast address, nor will they send queries to that address.
-
-   Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
-   possible for a dual stack host to be configured with the address of a
-   DNS server over IPv4, while remaining unconfigured with a DNS server
-   suitable for use over IPv6.
-
-   In these situations, a dual stack host will send AAAA queries to the
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 16]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   configured DNS server over IPv4.  However, an IPv6-only host
-   unconfigured with a DNS server suitable for use over IPv6 will be
-   unable to resolve names using DNS.  Automatic IPv6 DNS configuration
-   mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
-   deployed, and not all DNS servers support IPv6.  Therefore lack of
-   IPv6 DNS configuration may be a common problem in the short term, and
-   LLMNR may prove useful in enabling link-local name resolution over
-   IPv6.
-
-   Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
-   IPv6-only hosts may not be configured with a DNS server.  Where there
-   is no DNS server authoritative for the name of a host or the
-   authoritative DNS server does not support dynamic client update over
-   IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
-   be able to do DNS dynamic update, and other hosts will not be able to
-   resolve its name.
-
-   For example, if the configured DNS server responds to a AAAA RR query
-   sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
-   RCODE=0 and an empty answer section, then a AAAA RR query sent using
-   LLMNR over IPv6 may be successful in resolving the name of an
-   IPv6-only host on the local link.
-
-   Similarly, if a DHCPv4 server is available providing DNS server
-   configuration, and DNS server(s) exist which are authoritative for
-   the A RRs of local hosts and support either dynamic client update
-   over IPv4 or DHCPv4-based dynamic update, then the names of local
-   IPv4 hosts can be resolved over IPv4 without LLMNR.  However,  if no
-   DNS server is authoritative for the names of local hosts, or the
-   authoritative DNS server(s) do not support dynamic update, then LLMNR
-   enables linklocal name resolution over IPv4.
-
-   Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-   configure LLMNR on an interface.  The LLMNR Enable Option, described
-   in [LLMNREnable], can be used to explicitly enable or disable use of
-   LLMNR on an interface.  The LLMNR Enable Option does not determine
-   whether or in which order DNS itself is used for name resolution.
-   The order in which various name resolution mechanisms should be used
-   can be specified using the Name Service Search Option (NSSO) for DHCP
-   [RFC2937], using the LLMNR Enable Option code carried in the NSSO
-   data.
-
-   It is possible that DNS configuration mechanisms will go in and out
-   of service.  In these circumstances, it is possible for hosts within
-   an administrative domain to be inconsistent in their DNS
-   configuration.
-
-   For example, where DHCP is used for configuring DNS servers, one or
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 17]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   more DHCP servers can fail.  As a result, hosts configured prior to
-   the outage will be configured with a DNS server, while hosts
-   configured after the outage will not.  Alternatively, it is possible
-   for the DNS configuration mechanism to continue functioning while
-   configured DNS servers fail.
-
-   An outage in the DNS configuration mechanism may result in hosts
-   continuing to use LLMNR even once the outage is repaired.  Since
-   LLMNR only enables linklocal name resolution, this represents a
-   degradation in capabilities.  As a result, hosts without a configured
-   DNS server may wish to periodically attempt to obtain DNS
-   configuration if permitted by the configuration mechanism in use.  In
-   the absence of other guidance, a default retry interval of one (1)
-   minute is RECOMMENDED.
-
-4.  Conflict Resolution
-
-   By default, a responder SHOULD be configured to behave as though its
-   name is UNIQUE on each interface on which LLMNR is enabled.  However,
-   it is also possible to configure multiple responders to be
-   authoritative for the same name.  For example, multiple responders
-   MAY respond to a query for an A or AAAA type record for a cluster
-   name (assigned to multiple hosts in the cluster).
-
-   To detect duplicate use of a name, an administrator can use a name
-   resolution utility which employs LLMNR and lists both responses and
-   responders.  This would allow an administrator to diagnose behavior
-   and potentially to intervene and reconfigure LLMNR responders who
-   should not be configured to respond to the same name.
-
-4.1.  Uniqueness Verification
-
-   Prior to sending an LLMNR response with the 'T' bit clear, a
-   responder configured with a UNIQUE name MUST verify that there is no
-   other host within the scope of LLMNR query propagation that is
-   authoritative for the same name on that interface.
-
-   Once a responder has verified that its name is UNIQUE, if it receives
-   an LLMNR query for that name, with the 'C' bit clear, it MUST
-   respond, with the 'T' bit clear. Prior to verifying that its name is
-   UNIQUE, a responder MUST set the 'T' bit in responses.
-
-   Uniqueness verification is carried out when the host:
-
-     - starts up or is rebooted
-     - wakes from sleep (if the network interface was inactive
-       during sleep)
-     - is configured to respond to LLMNR queries on an interface
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 18]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-       enabled for transmission and reception of IP traffic
-     - is configured to respond to LLMNR queries using additional
-       UNIQUE resource records
-     - verifies the acquisition of a new IP address and configuration
-       on an interface
-
-   To verify uniqueness, a responder MUST send an LLMNR query with the
-   'C' bit clear, over all protocols on which it responds to LLMNR
-   queries (IPv4 and/or IPv6).  It is RECOMMENDED that responders verify
-   uniqueness of a name by sending a query for the name with type='ANY'.
-
-   If no response is received, the sender retransmits the query, as
-   specified in Section 2.7.  If a response is received, the sender MUST
-   check if the source address matches the address of any of its
-   interfaces; if so, then the response is not considered a conflict,
-   since it originates from the sender.  To avoid triggering conflict
-   detection, a responder that detects that it is connected to the same
-   link on multiple interfaces SHOULD set the 'C' bit in responses.
-
-   If a response is received with the 'T' bit clear, the responder MUST
-   NOT use the name in response to LLMNR queries received over any
-   protocol (IPv4 or IPv6).  If a response is received with the 'T' bit
-   set, the responder MUST check if the source IP address in the
-   response, interpreted as an unsigned integer, is less than the source
-   IP address in the query.  If so, the responder MUST NOT use the name
-   in response to LLMNR queries received over any protocol (IPv4 or
-   IPv6).  For the purpose of uniqueness verification, the contents of
-   the answer section in a response is irrelevant.
-
-   Periodically carrying out uniqueness verification in an attempt to
-   detect name conflicts is not necessary, wastes network bandwidth, and
-   may actually be detrimental.  For example, if network links are
-   joined only briefly, and are separated again before any new
-   communication is initiated, temporary conflicts are benign and no
-   forced reconfiguration is required.  LLMNR responders SHOULD NOT
-   periodically attempt uniqueness verification.
-
-4.2.  Conflict Detection and Defense
-
-   Hosts on disjoint network links may configure the same name for use
-   with LLMNR.  If these separate network links are later joined or
-   bridged together, then there may be multiple hosts which are now on
-   the same link, trying to use the same name.
-
-   In order to enable ongoing detection of name conflicts, when an LLMNR
-   sender receives multiple LLMNR responses to a query, it MUST check if
-   the 'C' bit is clear in any of the responses.  If so, the sender
-   SHOULD send another query for the same name, type and class, this
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 19]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   time with the 'C' bit set, with the potentially conflicting resource
-   records included in the additional section.
-
-   Queries with the 'C' bit set are considered advisory and responders
-   MUST verify the existence of a conflict before acting on it.  A
-   responder receiving a query with the 'C' bit set MUST NOT respond.
-
-   If the query is for a UNIQUE name, then the responder MUST send its
-   own query for the same name, type and class, with the 'C' bit clear.
-   If a response is received, the sender MUST check if the source
-   address matches the address of any of its interfaces; if so, then the
-   response is not considered a conflict, since it originates from the
-   sender.  To avoid triggering conflict detection, a responder that
-   detects that it is connected to the same link on multiple interfaces
-   SHOULD set the 'C' bit in responses.
-
-   An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
-   log them.  Upon detecting a conflict, an LLMNR responder MUST
-   immediately stop using the conflicting name in response to LLMNR
-   queries received over any supported protocol, if the source IP
-   address in the response, interpreted as an unsigned integer, is less
-   than the source IP address in the uniqueness verification query.
-
-   After stopping the use of a name, the responder MAY elect to
-   configure a new name.  However, since name reconfiguration may be
-   disruptive, this is not required, and a responder may have been
-   configured to respond to multiple names so that alternative names may
-   already be available.  A host that has stopped the use of a name may
-   attempt uniqueness verification again after the expiration of the TTL
-   of the conflicting response.
-
-4.3.  Considerations for Multiple Interfaces
-
-   A multi-homed host may elect to configure LLMNR on only one of its
-   active interfaces.  In many situations this will be adequate.
-   However, should a host need to configure LLMNR on more than one of
-   its active interfaces, there are some additional precautions it MUST
-   take.  Implementers who are not planning to support LLMNR on multiple
-   interfaces simultaneously may skip this section.
-
-   Where a host is configured to issue LLMNR queries on more than one
-   interface, each interface maintains its own independent LLMNR
-   resolver cache, containing the responses to LLMNR queries.
-
-   A multi-homed host checks the uniqueness of UNIQUE records as
-   described in Section 4.  The situation is illustrated in figure 1.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 20]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-        ----------  ----------
-         |      |    |      |
-        [A]    [myhost]   [myhost]
-
-      Figure 1.  Link-scope name conflict
-
-   In this situation, the multi-homed myhost will probe for, and defend,
-   its host name on both interfaces.  A conflict will be detected on one
-   interface, but not the other.  The multi-homed myhost will not be
-   able to respond with a host RR for "myhost" on the interface on the
-   right (see Figure 1).  The multi-homed host may, however, be
-   configured to use the "myhost" name on the interface on the left.
-
-   Since names are only unique per-link, hosts on different links could
-   be using the same name.  If an LLMNR client sends requests over
-   multiple interfaces, and receives replies from more than one, the
-   result returned to the client is defined by the implementation.  The
-   situation is illustrated in figure 2.
-
-        ----------  ----------
-         |      |    |     |
-        [A]    [myhost]   [A]
-
-
-      Figure 2.  Off-segment name conflict
-
-   If host myhost is configured to use LLMNR on both interfaces, it will
-   send LLMNR queries on both interfaces.  When host myhost sends a
-   query for the host RR for name "A" it will receive a response from
-   hosts on both interfaces.
-
-   Host myhost cannot distinguish between the situation shown in Figure
-   2, and that shown in Figure 3 where no conflict exists.
-
-                [A]
-               |   |
-           -----   -----
-               |   |
-              [myhost]
-
-      Figure 3.  Multiple paths to same host
-
-   This illustrates that the proposed name conflict resolution mechanism
-   does not support detection or resolution of conflicts between hosts
-   on different links.  This problem can also occur with DNS when a
-   multi-homed host is connected to two different networks with
-   separated name spaces.  It is not the intent of this document to
-   address the issue of uniqueness of names within DNS.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 21]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-4.4.  API Issues
-
-   [RFC2553] provides an API which can partially solve the name
-   ambiguity problem for applications written to use this API, since the
-   sockaddr_in6 structure exposes the scope within which each scoped
-   address exists, and this structure can be used for both IPv4 (using
-   v4-mapped IPv6 addresses) and IPv6 addresses.
-
-   Following the example in Figure 2, an application on 'myhost' issues
-   the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
-   ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both
-   interfaces and the resolver library will return a list containing
-   multiple addrinfo structures, each with an associated sockaddr_in6
-   structure.  This list will thus contain the IPv4 and IPv6 addresses
-   of both hosts responding to the name 'A'.  Link-local addresses will
-   have a sin6_scope_id value that disambiguates which interface is used
-   to reach the address.  Of course, to the application, Figures 2 and 3
-   are still indistinguishable, but this API allows the application to
-   communicate successfully with any address in the list.
-
-5.  Security Considerations
-
-   LLMNR is a peer-to-peer name resolution protocol designed for use on
-   the local link.  While LLMNR limits the vulnerability of responders
-   to off-link senders, it is possible for an off-link responder to
-   reach a sender.
-
-   In scenarios such as public "hotspots" attackers can be present on
-   the same link.  These threats are most serious in wireless networks
-   such as 802.11, since attackers on a wired network will require
-   physical access to the network, while wireless attackers may mount
-   attacks from a distance.  Link-layer security such as [IEEE-802.11i]
-   can be of assistance against these threats if it is available.
-
-   This section details security measures available to mitigate threats
-   from on and off-link attackers.
-
-5.1.  Denial of Service
-
-   Attackers may take advantage of LLMNR conflict detection by
-   allocating the same name, denying service to other LLMNR responders
-   and possibly allowing an attacker to receive packets destined for
-   other hosts.  By logging conflicts, LLMNR responders can provide
-   forensic evidence of these attacks.
-
-   An attacker may spoof LLMNR queries from a victim's address in order
-   to mount a denial of service attack.  Responders setting the IPv6 Hop
-   Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 22]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   response may be able to reach the victim across the Internet.
-
-   While LLMNR responders only respond to queries for which they are
-   authoritative and LLMNR does not provide wildcard query support, an
-   LLMNR response may be larger than the query, and an attacker can
-   generate multiple responses to a query for a name used by multiple
-   responders.  A sender may protect itself against unsolicited
-   responses by silently discarding them as rapidly as possible.
-
-5.2.  Spoofing
-
-   LLMNR is designed to prevent reception of queries sent by an off-link
-   attacker.  LLMNR requires that responders receiving UDP queries check
-   that they are sent to a link-scope multicast address.  However, it is
-   possible that some routers may not properly implement link-scope
-   multicast, or that link-scope multicast addresses may leak into the
-   multicast routing system.  To prevent successful setup of TCP
-   connections by an off-link sender, responders receiving a TCP SYN
-   reply with a TCP SYN-ACK with TTL set to one (1).
-
-   While it is difficult for an off-link attacker to send an LLMNR query
-   to a responder,  it is possible for an off-link attacker to spoof a
-   response to a query (such as an A or AAAA query for a popular
-   Internet host), and by using a TTL or Hop Limit field larger than one
-   (1), for the forged response to reach the LLMNR sender.  Since the
-   forged response will only be accepted if it contains a matching ID
-   field, choosing a pseudo-random ID field within queries provides some
-   protection against off-link responders.
-
-   Since LLMNR queries can be sent when DNS server(s) do not respond, an
-   attacker can execute a denial of service attack on the DNS server(s)
-   and then poison the LLMNR cache by responding to an LLMNR query with
-   incorrect information.  As noted in "Threat Analysis of the Domain
-   Name System (DNS)" [RFC3833] these threats also exist with DNS, since
-   DNS response spoofing tools are available that can allow an attacker
-   to respond to a query more quickly than a distant DNS server.
-   However, while switched networks or link layer security may make it
-   difficult for an on-link attacker to snoop unicast DNS queries,
-   multicast LLMNR queries are propagated to all hosts on the link,
-   making it possible for an on-link attacker to spoof LLMNR responses
-   without having to guess the value of the ID field in the query.
-
-   Since LLMNR queries are sent and responded to on the local-link, an
-   attacker will need to respond more quickly to provide its own
-   response prior to arrival of the response from a legitimate
-   responder.   If an LLMNR query is sent for an off-link host, spoofing
-   a response in a timely way is not difficult, since a legitimate
-   response will never be received.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 23]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   This vulnerability can be reduced by limiting use of LLMNR to
-   resolution of single-label names as described in Section 3, or by
-   implementation of authentication (see Section 5.3).
-
-5.3.  Authentication
-
-   LLMNR is a peer-to-peer name resolution protocol, and as a result,
-   it is often deployed in situations where no trust model can be
-   assumed.  Where a pre-arranged security configuration is possible,
-   the following security mechanisms may be used:
-
-[a]  LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
-     [RFC2931] security mechanisms.  "DNS Name Service based on Secure
-     Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
-     the use of TSIG to secure LLMNR, based on group keys.  While group
-     keys can be used to demonstrate membership in a group, they do not
-     protect against forgery by an attacker that is a member of the
-     group.
-
-[b]  IPsec ESP with a null-transform MAY be used to authenticate unicast
-     LLMNR queries and responses or LLMNR responses to multicast
-     queries.  In a small network without a certificate authority, this
-     can be most easily accomplished through configuration of a group
-     pre-shared key for trusted hosts.  As with TSIG, this does not
-     protect against forgery by an attacker with access to the group
-     pre-shared key.
-
-[c]  LLMNR implementations MAY support DNSSEC [RFC4033].  In order to
-     support DNSSEC, LLMNR implementations MAY be configured with trust
-     anchors, or they MAY make use of keys obtained from DNS queries.
-     Since LLMNR does not support "delegated trust" (CD or AD bits),
-     LLMNR implementations cannot make use of DNSSEC unless they are
-     DNSSEC-aware and support validation.  Unlike approaches [a] or [b],
-     DNSSEC permits a responder to demonstrate ownership of a name, not
-     just membership within a trusted group.  As a result, it enables
-     protection against forgery.
-
-5.4.  Cache and Port Separation
-
-   In order to prevent responses to LLMNR queries from polluting the DNS
-   cache, LLMNR implementations MUST use a distinct, isolated cache for
-   LLMNR on each interface.  The use of separate caches is most
-   effective when LLMNR is used as a name resolution mechanism of last
-   resort, since this minimizes the opportunities for poisoning the
-   LLMNR cache, and decreases reliance on it.
-
-   LLMNR operates on a separate port from DNS, reducing the likelihood
-   that a DNS server will unintentionally respond to an LLMNR query.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 24]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-   If LLMNR is given higher priority than DNS among the enabled name
-   resolution mechanisms, a denial of service attack on the DNS server
-   would not be necessary in order to poison the LLMNR cache, since
-   LLMNR queries would be sent even when the DNS server is available.
-   In addition, the LLMNR cache, once poisoned, would take precedence
-   over the DNS cache, eliminating the benefits of cache separation.  As
-   a result, LLMNR SHOULD NOT be used as a primary name resolution
-   mechanism.
-
-6.  IANA Considerations
-
-   LLMNR requires allocation of port 5355 for both TCP and UDP.
-
-   LLMNR requires allocation of link-scope multicast IPv4 address
-   224.0.0.252, as well as link-scope multicast IPv6 address
-   FF02:0:0:0:0:0:1:3.
-
-   This specification creates two new name spaces:  the LLMNR namespace
-   and the reserved bits in the LLMNR header.  The reserved bits in the
-   LLMNR header are allocated by IETF Consensus, in accordance with BCP
-   26 [RFC2434].
-
-   In order to to avoid creating any new administrative procedures,
-   administration of the LLMNR namespace will piggyback on the
-   administration of the DNS namespace.
-
-   The rights to use a fully qualified domain name (FQDN) within LLMNR
-   are obtained coincident with acquiring the rights to use that name
-   within DNS.  Those wishing to use a FQDN within LLMNR should first
-   acquire the rights to use the corresponding FQDN within DNS.  Using a
-   FQDN within LLMNR without ownership of the corresponding name in DNS
-   creates the possibility of conflict and therefore is discouraged.
-
-   LLMNR responders may self-allocate a name within the single-label
-   name space, first defined in [RFC1001].  Since single-label names are
-   not unique, no registration process is required.
-
-7.  Constants
-
-   The following timing constants are used in this protocol; they are
-   not intended to be user configurable.
-
-      JITTER_INTERVAL      100 ms
-      LLMNR_TIMEOUT        1 second (if set statically on all interfaces)
-                           100 ms (IEEE 802 media, including IEEE 802.11)
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 25]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-8.  References
-
-8.1.  Normative References
-
-[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS
-          Service on a TCP/UDP Transport: Concepts and Methods", RFC
-          1001, March 1987.
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
-          Specification", RFC 1035, November 1987.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-          Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
-          Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-          RFC 2308, March 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
-          Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
-          Considerations Section in RFCs", BCP 26, RFC 2434, October
-          1998.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
-          August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-          "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-          2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
-          (SIG(0)s)", RFC 2931, September 2000.
-
-8.2.  Informative References
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
-          Caching", IEEE/ACM Transactions on Networking, Volume 10,
-          Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
-          unicast addresses to communicate with recursive DNS servers",
-          Internet draft (work in progress), draft-ietf-ipv6-dns-
-          discovery-07.txt, October 2002.
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 26]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-[IEEE-802.11i]
-          Institute of Electrical and Electronics Engineers, "Supplement
-          to Standard for Telecommunications and Information Exchange
-          Between Systems - LAN/MAN Specific Requirements - Part 11:
-          Wireless LAN Medium Access Control (MAC) and Physical Layer
-          (PHY) Specifications: Specification for Enhanced Security",
-          IEEE 802.11i, July 2004.
-
-[LLMNREnable]
-          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
-          in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
-          Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
-          Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
-          2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --
-          Portable Operating System Interface (POSIX). Open Group
-          Technical Standard: Base Specifications, Issue 6, December
-          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
-          Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-          Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-          March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
-          RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
-          2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
-          Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
-          2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
-          IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-          System (DNS)", RFC 3833, August 2004.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 27]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
-          of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-          "DNS Security Introduction and Requirement", RFC 4033, March
-          2005.
-
-Acknowledgments
-
-   This work builds upon original work done on multicast DNS by Bill
-   Manning and Bill Woodcock.  Bill Manning's work was funded under
-   DARPA grant #F30602-99-1-0523.  The authors gratefully acknowledge
-   their contribution to the current specification.  Constructive input
-   has also been received from Mark Andrews, Rob Austein, Randy Bush,
-   Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
-   Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
-   Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
-   Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
-   St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
-   Bernard Aboba
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 706 6605
-   EMail: bernarda@microsoft.com
-
-   Dave Thaler
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 703 8835
-   EMail: dthaler@microsoft.com
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   EMail: levone@microsoft.com
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 28]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 29]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                    16 April 2006
-
-
-Open Issues
-
-   Open issues with this specification are tracked on the following web
-   site:
-
-   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 30]
-
-
-
diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/draft/draft-ietf-dnsext-nsid-01.txt
deleted file mode 100644
index 90d1a0609d..0000000000
--- a/doc/draft/draft-ietf-dnsext-nsid-01.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-Network Working Group                                         R. Austein
-Internet-Draft                                                       ISC
-Expires: July 15, 2006                                  January 11, 2006
-
-
-                DNS Name Server Identifier Option (NSID)
-                       draft-ietf-dnsext-nsid-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.  While existing ad-hoc
-   mechanism allow an operator to send follow-up queries when it is
-   necessary to debug such a configuration, the only completely reliable
-   way to obtain the identity of the name server which responded is to
-   have the name server include this information in the response itself.
-   This note defines a protocol extension to support this functionality.
-
-
-
-Austein                   Expires July 15, 2006                 [Page 1]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  4
-     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
-     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  5
-   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  6
-     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  8
-     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  8
-     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 2]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-1.  Introduction
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.
-
-   Existing ad-hoc mechanisms allow an operator to send follow-up
-   queries when it is necessary to debug such a configuration, but there
-   are situations in which this is not a totally satisfactory solution,
-   since anycast routing may have changed, or the server pool in
-   question may be behind some kind of extremely dynamic load balancing
-   hardware.  Thus, while these ad-hoc mechanisms are certainly better
-   than nothing (and have the advantage of already being deployed), a
-   better solution seems desirable.
-
-   Given that a DNS query is an idempotent operation with no retained
-   state, it would appear that the only completely reliable way to
-   obtain the identity of the name server which responded to a
-   particular query is to have that name server include identifying
-   information in the response itself.  This note defines a protocol
-   enhancement to achieve this.
-
-1.1.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 3]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-2.  Protocol
-
-   This note uses an EDNS [RFC2671] option to signal the resolver's
-   desire for information identifying the name server and to hold the
-   name server's response, if any.
-
-2.1.  Resolver Behavior
-
-   A resolver signals its desire for information identifying a name
-   server by sending an empty NSID option (Section 2.3) in an EDNS OPT
-   pseudo-RR in the query message.
-
-   The resolver MUST NOT include any NSID payload data in the query
-   message.
-
-   The semantics of an NSID request are not transitive.  That is: the
-   presence of an NSID option in a query is a request that the name
-   server which receives the query identify itself.  If the name server
-   side of a recursive name server receives an NSID request, the client
-   is asking the recursive name server to identify itself; if the
-   resolver side of the recursive name server wishes to receive
-   identifying information, it is free to add NSID requests in its own
-   queries, but that is a separate matter.
-
-2.2.  Name Server Behavior
-
-   A name server which understands the NSID option and chooses to honor
-   a particular NSID request responds by including identifying
-   information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
-   in the response message.
-
-   The name server MUST ignore any NSID payload data that might be
-   present in the query message.
-
-   The NSID option is not transitive.  A name server MUST NOT send an
-   NSID option back to a resolver which did not request it.  In
-   particular, while a recursive name server may choose to add an NSID
-   option when sending a query, this has no effect on the presence or
-   absence of the NSID option in the recursive name server's response to
-   the original client.
-
-   As stated in Section 2.1, this mechanism is not restricted to
-   authoritative name servers; the semantics are intended to be equally
-   applicable to recursive name servers.
-
-2.3.  The NSID Option
-
-   The OPTION-CODE for the NSID option is [TBD].
-
-
-
-Austein                   Expires July 15, 2006                 [Page 4]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   The OPTION-DATA for the NSID option is an opaque byte string the
-   semantics of which are deliberately left outside the protocol.  See
-   Section 3.1 for discussion.
-
-2.4.  Presentation Format
-
-   User interfaces MUST read and write the content of the NSID option as
-   a sequence of hexadecimal digits, two digits per payload octet.
-
-   The NSID payload is binary data.  Any comparison between NSID
-   payloads MUST be a comparison of the raw binary data.  Copy
-   operations MUST NOT assume that the raw NSID payload is null-
-   terminated.  Any resemblance between raw NSID payload data and any
-   form of text is purely a convenience, and does not change the
-   underlying nature of the payload data.
-
-   See Section 3.3 for discussion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 5]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-3.  Discussion
-
-   This section discusses certain aspects of the protocol and explains
-   considerations that led to the chosen design.
-
-3.1.  The NSID Payload
-
-   The syntax and semantics of the content of the NSID option is
-   deliberately left outside the scope of this specification.  This
-   section describe some of the kinds of data that server administrators
-   might choose to provide as the content of the NSID option, and
-   explains the reasoning behind choosing a simple opaque byte string.
-
-   There are several possibilities for the payload of the NSID option:
-
-   o  It could be the "real" name of the specific name server within the
-      name server pool.
-
-   o  It could be the "real" IP address (IPv4 or IPv6) of the name
-      server within the name server pool.
-
-   o  It could be some sort of pseudo-random number generated in a
-      predictable fashion somehow using the server's IP address or name
-      as a seed value.
-
-   o  It could be some sort of probabilisticly unique identifier
-      initially derived from some sort of random number generator then
-      preserved across reboots of the name server.
-
-   o  It could be some sort of dynamicly generated identifier so that
-      only the name server operator could tell whether or not any two
-      queries had been answered by the same server.
-
-   o  It could be a blob of signed data, with a corresponding key which
-      might (or might not) be available via DNS lookups.
-
-   o  It could be a blob of encrypted data, the key for which could be
-      restricted to parties with a need to know (in the opinion of the
-      server operator).
-
-   o  It could be an arbitrary string of octets chosen at the discretion
-      of the name server operator.
-
-   Each of these options has advantages and disadvantages:
-
-   o  Using the "real" name is simple, but the name server may not have
-      a "real" name.
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 6]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   o  Using the "real" address is also simple, and the name server
-      almost certainly does have at least one non-anycast IP address for
-      maintenance operations, but the operator of the name server may
-      not be willing to divulge its non-anycast address.
-
-   o  Given that one common reason for using anycast DNS techniques is
-      an attempt to harden a critical name server against denial of
-      service attacks, some name server operators are likely to want an
-      identifier other than the "real" name or "real" address of the
-      name server instance.
-
-   o  Using a hash or pseudo-random number can provide a fixed length
-      value that the resolver can use to tell two name servers apart
-      without necessarily being able to tell where either one of them
-      "really" is, but makes debugging more difficult if one happens to
-      be in a friendly open environment.  Furthermore, hashing might not
-      add much value, since a hash based on an IPv4 address still only
-      involves a 32-bit search space, and DNS names used for servers
-      that operators might have to debug at 4am tend not to be very
-      random.
-
-   o  Probabilisticly unique identifiers have similar properties to
-      hashed identifiers, but (given a sufficiently good random number
-      generator) are immune to the search space issues.  However, the
-      strength of this approach is also its weakness: there is no
-      algorithmic transformation by which even the server operator can
-      associate name server instances with identifiers while debugging,
-      which might be annoying.  This approach also requires the name
-      server instance to preserve the probabilisticly unique identifier
-      across reboots, but this does not appear to be a serious
-      restriction, since authoritative nameservers almost always have
-      some form of nonvolatile storage in any case, and in the rare case
-      of a name server that does not have any way to store such an
-      identifier, nothing terrible will happen if the name server just
-      generates a new identifier every time it reboots.
-
-   o  Using an arbitrary octet string gives name server operators yet
-      another thing to configure, or mis-configure, or forget to
-      configure.  Having all the nodes in an anycast name server
-      constellation identify themselves as "My Name Server" would not be
-      particularly useful.
-
-   Given all of the issues listed above, there does not appear to be a
-   single solution that will meet all needs.  Section 2.3 therefore
-   defines the NSID payload to be an opaque byte string and leaves the
-   choice up to the implementor and name server operator.  The following
-   guidelines may be useful to implementors and server operators:
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 7]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   o  Operators for whom divulging the unicast address is an issue could
-      use the raw binary representation of a probabilisticly unique
-      random number.  This should probably be the default implementation
-      behavior.
-
-   o  Operators for whom divulging the unicast address is not an issue
-      could just use the raw binary representation of a unicast address
-      for simplicity.  This should only be done via an explicit
-      configuration choice by the operator.
-
-   o  Operators who really need or want the ability to set the NSID
-      payload to an arbitrary value could do so, but this should only be
-      done via an explicit configuration choice by the operator.
-
-   This approach appears to provide enough information for useful
-   debugging without unintentionally leaking the maintenance addresses
-   of anycast name servers to nogoodniks, while also allowing name
-   server operators who do not find such leakage threatening to provide
-   more information at their own discretion.
-
-3.2.  NSID Is Not Transitive
-
-   As specified in Section 2.1 and Section 2.2, the NSID option is not
-   transitive.  This is strictly a hop-by-hop mechanism.
-
-   Most of the discussion of name server identification to date has
-   focused on identifying authoritative name servers, since the best
-   known cases of anycast name servers are a subset of the name servers
-   for the root zone.  However, given that anycast DNS techniques are
-   also applicable to recursive name servers, the mechanism may also be
-   useful with recursive name servers.  The hop-by-hop semantics support
-   this.
-
-   While there might be some utility in having a transitive variant of
-   this mechanism (so that, for example, a stub resolver could ask a
-   recursive server to tell it which authoritative name server provided
-   a particular answer to the recursive name server), the semantics of
-   such a variant would be more complicated, and are left for future
-   work.
-
-3.3.  User Interface Issues
-
-   Given the range of possible payload contents described in
-   Section 3.1, it is not possible to define a single presentation
-   format for the NSID payload that is efficient, convenient,
-   unambiguous, and aesthetically pleasing.  In particular, while it is
-   tempting to use a presentation format that uses some form of textual
-   strings, attempting to support this would significantly complicate
-
-
-
-Austein                   Expires July 15, 2006                 [Page 8]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   what's intended to be a very simple debugging mechanism.
-
-   In some cases the content of the NSID payload may be binary data
-   meaningful only to the name server operator, and may not be
-   meaningful to the user or application, but the user or application
-   must be able to capture the entire content anyway in order for it to
-   be useful.  Thus, the presentation format must support arbitrary
-   binary data.
-
-   In cases where the name server operator derives the NSID payload from
-   textual data, a textual form such as US-ASCII or UTF-8 strings might
-   at first glance seem easier for a user to deal with.  There are,
-   however, a number of complex issues involving internationalized text
-   which, if fully addressed here, would require a set of rules
-   significantly longer than the rest of this specification.  See
-   [RFC2277] for an overview of some of these issues.
-
-   It is much more important for the NSID payload data to be passed
-   unambiguously from server administrator to user and back again than
-   it is for the payload data data to be pretty while in transit.  In
-   particular, it's critical that it be straightforward for a user to
-   cut and paste an exact copy of the NSID payload output by a debugging
-   tool into other formats such as email messages or web forms without
-   distortion.  Hexadecimal strings, while ugly, are also robust.
-
-3.4.  Truncation
-
-   In some cases, adding the NSID option to a response message may
-   trigger message truncation.  This specification does not change the
-   rules for DNS message truncation in any way, but implementors will
-   need to pay attention to this issue.
-
-   Including the NSID option in a response is always optional, so this
-   specification never requires name servers to truncate response
-   messages.
-
-   By definition, a resolver that requests NSID responses also supports
-   EDNS, so a resolver that requests NSID responses can also use the
-   "sender's UDP payload size" field of the OPT pseudo-RR to signal a
-   receive buffer size large enough to make truncation unlikely.
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 9]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-4.  IANA Considerations
-
-   This mechanism requires allocation of one ENDS option code for the
-   NSID option (Section 2.3).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 10]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-5.  Security Considerations
-
-   This document describes a channel signaling mechanism, intended
-   primarily for debugging.  Channel signaling mechanisms are outside
-   the scope of DNSSEC per se.  Applications that require integrity
-   protection for the data being signaled will need to use a channel
-   security mechanism such as TSIG [RFC2845].
-
-   Section 3.1 discusses a number of different kinds of information that
-   a name server operator might choose to provide as the value of the
-   NSID option.  Some of these kinds of information are security
-   sensitive in some environments.  This specification deliberately
-   leaves the syntax and semantics of the NSID option content up to the
-   implementation and the name server operator.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 11]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-6.  Acknowledgements
-
-   Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
-   Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
-   Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
-   Suzanne Woolf.  Apologies to anyone inadvertently omitted from the
-   above list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 12]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, BCP 14, March 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-7.2.  Informative References
-
-   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
-              Languages", RFC 2277, BCP 18, January 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 13]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-Author's Address
-
-   Rob Austein
-   ISC
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   Email: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 14]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 15]
-
diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt
deleted file mode 100644
index e169da8681..0000000000
--- a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt
+++ /dev/null
@@ -1,464 +0,0 @@
-
-INTERNET-DRAFT                                DSA Information in the DNS
-OBSOLETES: RFC 2536                               Donald E. Eastlake 3rd
-                                                   Motorola Laboratories
-Expires: September 2006                                       March 2006
-
-
-            DSA Keying and Signature Information in the DNS
-            --- ------ --- --------- ----------- -- --- ---
-               <draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
-                         Donald E. Eastlake 3rd
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS extensions working group mailing list
-   <namedroppers@ops.ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
-   The standard method of encoding US Government Digital Signature
-   Algorithm keying and signature information for use in the Domain Name
-   System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. DSA Keying Information..................................3
-      3. DSA Signature Information...............................4
-      4. Performance Considerations..............................4
-      5. Security Considerations.................................5
-      6. IANA Considerations.....................................5
-      Copyright, Disclaimer, and Additional IPR Provisions.......5
-
-      Normative References.......................................7
-      Informative References.....................................7
-
-      Author's Address...........................................8
-      Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information [RFC 1034, 1035]. The DNS has been extended to
-   include digital signatures and cryptographic keys as described in
-   [RFC 4033, 4034, 4035] and additional work is underway which would
-   require the storage of keying and signature information in the DNS.
-
-   This document describes how to encode US Government Digital Signature
-   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
-   US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
-   When DSA public keys are stored in the DNS, the structure of the
-   relevant part of the RDATA part of the RR being used is the fields
-   listed below in the order given.
-
-   The period of key validity is not included in this data but is
-   indicated separately, for example by an RR such as RRSIG which signs
-   and authenticates the RR containing the keying information.
-
-        Field     Size
-        -----     ----
-         T         1  octet
-         Q        20  octets
-         P        64 + T*8  octets
-         G        64 + T*8  octets
-         Y        64 + T*8  octets
-
-   As described in [FIPS 186-2] and [Schneier], T is a key size
-   parameter chosen such that 0 <= T <= 8.  (The meaning if the T octet
-   is greater than 8 is reserved and the remainder of the data may have
-   a different format in that case.)  Q is a prime number selected at
-   key generation time such that 2**159 < Q < 2**160. Thus Q is always
-   20 octets long and, as with all other fields, is stored in "big-
-   endian" network order.  P, G, and Y are calculated as directed by the
-   [FIPS 186-2] key generation algorithm [Schneier].  P is in the range
-   2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long.  G
-   and Y are quantities modulo P and so can be up to the same length as
-   P and are allocated fixed size fields with the same number of octets
-   as P.
-
-   During the key generation process, a random number X must be
-   generated such that 1 <= X <= Q-1.  X is the private key and is used
-   in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-        Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
-   The portion of the RDATA area used for US Digital Signature Algorithm
-   signature information is shown below with fields in the order they
-   are listed and the contents of each multi-octet field in "big-endian"
-   network order.
-
-        Field     Size
-        -----     ----
-         T         1 octet
-         R        20 octets
-         S        20 octets
-
-   First, the data signed must be determined.  Then the following steps
-   are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
-   specified in the public key [Schneier]:
-
-        hash = SHA-1 ( data )
-
-        Generate a random K such that 0 < K < Q.
-
-        R = ( G**K mod P ) mod Q
-
-        S = ( K**(-1) * (hash + X*R) ) mod Q
-
-   For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
-   3174].
-
-   Since Q is 160 bits long, R and S can not be larger than 20 octets,
-   which is the space allocated.
-
-   T is copied from the public key.  It is not logically necessary in
-   the SIG but is present so that values of T > 8 can more conveniently
-   be used as an escape for extended versions of DSA or other algorithms
-   as later standardized.
-
-
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA [RFC
-   3110] and DSA.  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower than
-   RSA when the RSA public exponent is chosen to be small, as is
-   recommended for some applications.
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC 2671] to make larger transfers more efficient, it
-   is still advisable at this time to make reasonable efforts to
-   minimize the size of RR sets containing keying and/or signature
-   inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
-   Keys retrieved from the DNS should not be trusted unless (1) they
-   have been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
-   current DSA standard may limit the security of DSA.  For particular
-   applications, implementors are encouraged to consider the range of
-   available algorithms and key sizes.
-
-   DSA assumes the ability to frequently generate high quality random
-   numbers.  See [random] for guidance.  DSA is designed so that if
-   biased rather than random numbers are used, high bandwidth covert
-   channels are possible.  See [Schneier] and more recent research.  The
-   leakage of an entire DSA private key in only two DSA signatures has
-   been demonstrated.  DSA provides security only if trusted
-   implementations, including trusted random number generation, are
-   used.
-
-
-
-6. IANA Considerations
-
-   Allocation of meaning to values of the T parameter that are not
-   defined herein (i.e., > 8 ) requires an IETF standards actions.  It
-   is intended that values unallocated herein be used to cover future
-   extensions of the DSS standard.
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
-   Copyright (C) The Internet Society (2006).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except
-   as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Normative References
-
-   [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
-   Signature Standard, 27 January 2000.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-
-
-Informative References
-
-   [RFC 1034] - "Domain names - concepts and facilities", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 1035] - "Domain names - implementation and specification", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
-   1999.
-
-   [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
-   (DNS)", D.  Eastlake 3rd. May 2001.
-
-   [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
-   Jones, September 2001.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-   "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [Schneier] - "Applied Cryptography Second Edition: protocols,
-   algorithms, and source code in C" (second edition), Bruce Schneier,
-   1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Labortories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554(w)
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in September 2006.
-
-   Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt
deleted file mode 100644
index f6e8588e8c..0000000000
--- a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt
+++ /dev/null
@@ -1,580 +0,0 @@
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539                               Donald E. Eastlake 3rd
-                                                   Motorola Laboratories
-Expires: September 2006                                       March 2006
-
-
-
-
-        Storage of Diffie-Hellman Keying Information in the DNS
-        ------- -- -------------- ------ ----------- -- --- ---
-               <draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
-
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS extensions working group mailing list
-   <namedroppers@ops.ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   The standard method for encoding Diffie-Hellman keys in the Domain
-   Name System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
-   Part of the format for Diffie-Hellman keys and the description
-   thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
-   and Hemma Prafullchandra.  In addition, the following persons
-   provided useful comments that were incorporated into the predecessor
-   of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
-          Status of This Document....................................1
-      Abstract...................................................1
-
-      Acknowledgements...........................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      1.1 About This Document....................................3
-      1.2 About Diffie-Hellman...................................3
-      2. Encoding Diffie-Hellman Keying Information..............4
-      3. Performance Considerations..............................5
-      4. IANA Considerations.....................................5
-      5. Security Considerations.................................5
-      Copyright, Disclaimer, and Additional IPR Provisions.......5
-
-      Normative References.......................................7
-      Informative Refences.......................................7
-
-      Author's Address...........................................8
-      Expiration and File Name...................................8
-
-      Appendix A: Well known prime/generator pairs...............9
-      A.1. Well-Known Group 1:  A 768 bit prime..................9
-      A.2. Well-Known Group 2:  A 1024 bit prime.................9
-      A.3. Well-Known Group 3:  A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   similar information [RFC 1034, 1035]. The DNS has been extended to
-   include digital signatures and cryptographic keys as described in
-   [RFC 4033, 4034, 4035] and additonal work is underway which would use
-   the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
-   This document describes how to store Diffie-Hellman keys in the DNS.
-   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
-   [Schneier, RFC 2631].
-
-   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 About Diffie-Hellman
-
-   Diffie-Hellman requires two parties to interact to derive keying
-   information which can then be used for authentication.  Thus Diffie-
-   Hellman is inherently a key agreement algorithm. As a result, no
-   format is defined for Diffie-Hellman "signature information".  For
-   example, assume that two parties have local secrets "i" and "j".
-   Assume they each respectively calculate X and Y as follows:
-
-        X = g**i ( mod p )
-
-        Y = g**j ( mod p )
-
-   They exchange these quantities and then each calculates a Z as
-   follows:
-
-        Zi = Y**i ( mod p )
-
-        Zj = X**j ( mod p )
-
-   Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
-   secret between the two parties that an adversary who does not know i
-   or j will not be able to learn from the exchanged messages (unless
-   the adversary can derive i or j by performing a discrete logarithm
-   mod p which is hard for strong p and g).
-
-   The private key for each party is their secret i (or j).  The public
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-   key is the pair p and g, which is the same for both parties, and
-   their individual X (or Y).
-
-   For further information about Diffie-Hellman and precautions to take
-   in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
-   When Diffie-Hellman keys appear within the RDATA portion of a RR,
-   they are encoded as shown below.
-
-   The period of key validity is not included in this data but is
-   indicated separately, for example by an RR such as RRSIG which signs
-   and authenticates the RR containing the keying information.
-
-                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |           KEY flags           |    protocol   |  algorithm=2  |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |     prime length (or flag)    |  prime (p) (or special)       /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /  prime (p)  (variable length) |       generator length        |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       | generator (g) (variable length)                               |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |     public value length       | public value (variable length)/
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /  public value (g^i mod p)    (variable length)                |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Prime length is the length of the Diffie-Hellman prime (p) in bytes
-   if it is 16 or greater.  Prime contains the binary representation of
-   the Diffie-Hellman prime with most significant byte first (i.e., in
-   network order). If "prime length" field is 1 or 2, then the "prime"
-   field is actually an unsigned index into a table of 65,536
-   prime/generator pairs and the generator length SHOULD be zero.  See
-   Appedix A for defined table entries and Section 4 for information on
-   allocating additional table entries.  The meaning of a zero or 3
-   through 15 value for "prime length" is reserved.
-
-   Generator length is the length of the generator (g) in bytes.
-   Generator is the binary representation of generator with most
-   significant byte first.  PublicValueLen is the Length of the Public
-   Value (g**i (mod p)) in bytes.  PublicValue is the binary
-   representation of the DH public value with most significant byte
-   first.
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC 2671] to make larger transfers more efficient. But
-   it is still advisable at this time to make reasonable efforts to
-   minimize the size of RR sets containing keying information consistent
-   with adequate security.
-
-
-
-4. IANA Considerations
-
-   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
-   an IETF consensus as defined in [RFC 2434].
-
-   Well known prime/generator pairs number 0x0000 through 0x07FF can
-   only be assigned by an IETF standards action. [RFC 2539], the
-   Proposed Standard predecessor of this document, assigned 0x0001
-   through 0x0002. This document additionally assigns 0x0003.  Pairs
-   number 0s0800 through 0xBFFF can be assigned based on RFC
-   documentation. Pairs number 0xC000 through 0xFFFF are available for
-   private use and are not centrally coordinated. Use of such private
-   pairs outside of a closed environment may result in conflicts and/or
-   security failures.
-
-
-
-5. Security Considerations
-
-   Keying information retrieved from the DNS should not be trusted
-   unless (1) it has been securely obtained from a secure resolver or
-   independently verified by the user and (2) this secure resolver and
-   secure obtainment or independent verification conform to security
-   policies acceptable to the user.  As with all cryptographic
-   algorithms, evaluating the necessary strength of the key is important
-   and dependent on security policy.
-
-   In addition, the usual Diffie-Hellman key strength considerations
-   apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
-   SHOULD be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
-   Copyright (C) The Internet Society (2006).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except
-   as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Normative References
-
-   [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
-   in RFCs", T.  Narten, H. Alvestrand, October 1998.
-
-   [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
-   1999.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-
-
-Informative Refences
-
-   [RFC 1034] - "Domain names - concepts and facilities", P.
-   Mockapetris, November 1987.
-
-   [RFC 1035] - "Domain names - implementation and specification", P.
-   Mockapetris, November 1987.
-
-   [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
-   System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
-   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
-   1999.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
-   Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
-   and Sons.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in September 2006.
-
-   Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
-   These numbers are copied from the IPSEC effort where the derivation
-   of these values is more fully explained and additional information is
-   available.  Richard Schroeppel performed all the mathematical and
-   computational work for this appendix.
-
-
-
-A.1. Well-Known Group 1:  A 768 bit prime
-
-   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
-   decimal value is
-          155251809230070893513091813125848175563133404943451431320235
-          119490296623994910210725866945387659164244291000768028886422
-          915080371891804634263272761303128298374438082089019628850917
-          0691316593175367469551763119843371637221007210577919
-
-   Prime modulus: Length (32 bit words): 24, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2:  A 1024 bit prime
-
-   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
-   Its decimal value is
-         179769313486231590770839156793787453197860296048756011706444
-         423684197180216158519368947833795864925541502180565485980503
-         646440548199239100050792877003355816639229553136239076508735
-         759914822574862575007425302077447712589550957937778424442426
-         617334727629299387668709205606050270810842907692932019128194
-         467627007
-
-   Prime modulus:  Length (32 bit words): 32, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
-            FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3:  A 1536 bit prime
-
-   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804 }.
-   Its decimal value is
-            241031242692103258855207602219756607485695054850245994265411
-            694195810883168261222889009385826134161467322714147790401219
-            650364895705058263194273070680500922306273474534107340669624
-            601458936165977404102716924945320037872943417032584377865919
-            814376319377685986952408894019557734611984354530154704374720
-            774996976375008430892633929555996888245787241299381012913029
-            459299994792636526405928464720973038494721168143446471443848
-            8520940127459844288859336526896320919633919
-
-   Prime modulus Length (32 bit words): 48, Data (hex):
-              FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-              29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-              EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-              E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-              EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
-              C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
-              83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-              670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words):  1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 10]
-
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt
deleted file mode 100644
index 02852591ec..0000000000
--- a/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt
+++ /dev/null
@@ -1,729 +0,0 @@
-
-
-
-Network Working Group                                         M. StJohns
-Internet-Draft                                             Nominum, Inc.
-Intended status: Informational                         November 29, 2006
-Expires: June 2, 2007
-
-
-               Automated Updates of DNSSEC Trust Anchors
-                draft-ietf-dnsext-trustupdate-timers-05
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on June 2, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a means for automated, authenticated and
-   authorized updating of DNSSEC "trust anchors".  The method provides
-   protection against N-1 key compromises of N keys in the trust point
-   key set.  Based on the trust established by the presence of a current
-   anchor, other anchors may be added at the same place in the
-   hierarchy, and, ultimately, supplant the existing anchor(s).
-
-   This mechanism will require changes to resolver management behavior
-
-
-
-StJohns                   Expires June 2, 2007                  [Page 1]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-   (but not resolver resolution behavior), and the addition of a single
-   flag bit to the DNSKEY record.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Compliance Nomenclature  . . . . . . . . . . . . . . . . .  3
-   2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  4
-     2.1.  Revocation . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  Add Hold-Down  . . . . . . . . . . . . . . . . . . . . . .  5
-     2.3.  Active Refresh . . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  Resolver Parameters  . . . . . . . . . . . . . . . . . . .  6
-       2.4.1.  Add Hold-Down Time . . . . . . . . . . . . . . . . . .  6
-       2.4.2.  Remove Hold-Down Time  . . . . . . . . . . . . . . . .  6
-       2.4.3.  Minimum Trust Anchors per Trust Point  . . . . . . . .  6
-   3.  Changes to DNSKEY RDATA Wire Format  . . . . . . . . . . . . .  6
-   4.  State Table  . . . . . . . . . . . . . . . . . . . . . . . . .  6
-     4.1.  Events . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     4.2.  States . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   5.  Trust Point Deletion . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Scenarios - Informative  . . . . . . . . . . . . . . . . . . .  9
-     6.1.  Adding a Trust Anchor  . . . . . . . . . . . . . . . . . .  9
-     6.2.  Deleting a Trust Anchor  . . . . . . . . . . . . . . . . .  9
-     6.3.  Key Roll-Over  . . . . . . . . . . . . . . . . . . . . . . 10
-     6.4.  Active Key Compromised . . . . . . . . . . . . . . . . . . 10
-     6.5.  Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
-     6.6.  Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-     8.1.  Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
-     8.2.  Multiple Key Compromise  . . . . . . . . . . . . . . . . . 11
-     8.3.  Dynamic Updates  . . . . . . . . . . . . . . . . . . . . . 11
-   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 12
-   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                   Expires June 2, 2007                  [Page 2]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-1.  Introduction
-
-   As part of the reality of fielding DNSSEC (Domain Name System
-   Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
-   come to the realization that there will not be one signed name space,
-   but rather islands of signed name space each originating from
-   specific points (i.e. 'trust points') in the DNS tree.  Each of those
-   islands will be identified by the trust point name, and validated by
-   at least one associated public key.  For the purpose of this document
-   we'll call the association of that name and a particular key a 'trust
-   anchor'.  A particular trust point can have more than one key
-   designated as a trust anchor.
-
-   For a DNSSEC-aware resolver to validate information in a DNSSEC
-   protected branch of the hierarchy, it must have knowledge of a trust
-   anchor applicable to that branch.  It may also have more than one
-   trust anchor for any given trust point.  Under current rules, a chain
-   of trust for DNSSEC-protected data that chains its way back to ANY
-   known trust anchor is considered 'secure'.
-
-   Because of the probable balkanization of the DNSSEC tree due to
-   signing voids at key locations, a resolver may need to know literally
-   thousands of trust anchors to perform its duties. (e.g.  Consider an
-   unsigned ".COM".)  Requiring the owner of the resolver to manually
-   manage this many relationships is problematic.  It's even more
-   problematic when considering the eventual requirement for key
-   replacement/update for a given trust anchor.  The mechanism described
-   herein won't help with the initial configuration of the trust anchors
-   in the resolvers, but should make trust point key replacement/
-   rollover more viable.
-
-   As mentioned above, this document describes a mechanism whereby a
-   resolver can update the trust anchors for a given trust point, mainly
-   without human intervention at the resolver.  There are some corner
-   cases discussed (e.g. multiple key compromise) that may require
-   manual intervention, but they should be few and far between.  This
-   document DOES NOT discuss the general problem of the initial
-   configuration of trust anchors for the resolver.
-
-1.1.  Compliance Nomenclature
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, [RFC2119].
-
-
-
-
-
-
-
-StJohns                   Expires June 2, 2007                  [Page 3]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-2.  Theory of Operation
-
-   The general concept of this mechanism is that existing trust anchors
-   can be used to authenticate new trust anchors at the same point in
-   the DNS hierarchy.  When a zone operator adds a new SEP key (i.e. a
-   DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section
-   2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
-   validated by an existing trust anchor, then the resolver can add the
-   new key to its valid set of trust anchors for that trust point.
-
-   There are some issues with this approach which need to be mitigated.
-   For example, a compromise of one of the existing keys could allow an
-   attacker to add their own 'valid' data.  This implies a need for a
-   method to revoke an existing key regardless of whether or not that
-   key is compromised.  As another example, assuming a single key
-   compromise, we need to prevent an attacker from adding a new key and
-   revoking all the other old keys.
-
-2.1.  Revocation
-
-   Assume two trust anchor keys A and B. Assume that B has been
-   compromised.  Without a specific revocation bit, B could invalidate A
-   simply by sending out a signed trust point key set which didn't
-   contain A. To fix this, we add a mechanism which requires knowledge
-   of the private key of a DNSKEY to revoke that DNSKEY.
-
-   A key is considered revoked when the resolver sees the key in a self-
-   signed RRSet and the key has the REVOKE bit (see Section 7 below) set
-   to '1'.  Once the resolver sees the REVOKE bit, it MUST NOT use this
-   key as a trust anchor or for any other purposes except validating the
-   RRSIG it signed over the DNSKEY RRSet specifically for the purpose of
-   validating the revocation.  Unlike the 'Add' operation below,
-   revocation is immediate and permanent upon receipt of a valid
-   revocation at the resolver.
-
-   A self-signed RRSet is a DNSKEY RRSet which contains the specific
-   DNSKEY and for which there is a corresponding validated RRSIG record.
-   It's not a special DNSKEY RRSet, just a way of describing the
-   validation requirements for that RRSet.
-
-   N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
-   than one without the bit set.  This affects the matching of a DNSKEY
-   to DS records in the parent, or the fingerprint stored at a resolver
-   used to configure a trust point.
-
-   In the given example, the attacker could revoke B because it has
-   knowledge of B's private key, but could not revoke A.
-
-
-
-
-StJohns                   Expires June 2, 2007                  [Page 4]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-2.2.  Add Hold-Down
-
-   Assume two trust point keys A and B. Assume that B has been
-   compromised.  An attacker could generate and add a new trust anchor
-   key - C (by adding C to the DNSKEY RRSet and signing it with B), and
-   then invalidate the compromised key.  This would result in both the
-   attacker and owner being able to sign data in the zone and have it
-   accepted as valid by resolvers.
-
-   To mitigate but not completely solve this problem, we add a hold-down
-   time to the addition of the trust anchor.  When the resolver sees a
-   new SEP key in a validated trust point DNSKEY RRSet, the resolver
-   starts an acceptance timer, and remembers all the keys that validated
-   the RRSet.  If the resolver ever sees the DNSKEY RRSet without the
-   new key but validly signed, it stops the acceptance process for that
-   key and resets the acceptance timer.  If all of the keys which were
-   originally used to validate this key are revoked prior to the timer
-   expiring, the resolver stops the acceptance process and resets the
-   timer.
-
-   Once the timer expires, the new key will be added as a trust anchor
-   the next time the validated RRSet with the new key is seen at the
-   resolver.  The resolver MUST NOT treat the new key as a trust anchor
-   until the hold down time expires AND it has retrieved and validated a
-   DNSKEY RRSet after the hold down time which contains the new key.
-
-   N.B.: Once the resolver has accepted a key as a trust anchor, the key
-   MUST be considered a valid trust anchor by that resolver until
-   explictly revoked as described above.
-
-   In the given example, the zone owner can recover from a compromise by
-   revoking B and adding a new key D and signing the DNSKEY RRSet with
-   both A and B.
-
-   The reason this does not completely solve the problem has to do with
-   the distributed nature of DNS.  The resolver only knows what it sees.
-   A determined attacker who holds one compromised key could keep a
-   single resolver from realizing that key had been compromised by
-   intercepting 'real' data from the originating zone and substituting
-   their own (e.g. using the example, signed only by B).  This is no
-   worse than the current situation assuming a compromised key.
-
-2.3.  Active Refresh
-
-   A resolver which has been configured for automatic update of keys
-   from a particular trust point MUST query that trust point (e.g. do a
-   lookup for the DNSKEY RRSet and related RRSIG records) no less often
-   than the lesser of 15 days or half the original TTL for the DNSKEY
-
-
-
-StJohns                   Expires June 2, 2007                  [Page 5]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-   RRSet or half the RRSIG expiration interval and no more often than
-   once per hour.  The expiration interval is the amount of time from
-   when the RRSIG was last retrieved until the expiration time in the
-   RRSIG.
-
-   If the query fails, the resolver MUST repeat the query until
-   satisfied no more often than once an hour and no less often than the
-   lesser of 1 day or 10% of the original TTL or 10% of the original
-   expiration interval.  I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
-   origTTL, .1 * expireInterval)).
-
-2.4.  Resolver Parameters
-
-2.4.1.  Add Hold-Down Time
-
-   The add hold-down time is 30 days or the expiration time of the
-   original TTL of the first trust point DNSKEY RRSet which contained
-   the new key, whichever is greater.  This ensures that at least two
-   validated DNSKEY RRSets which contain the new key MUST be seen by the
-   resolver prior to the key's acceptance.
-
-2.4.2.  Remove Hold-Down Time
-
-   The remove hold-down time is 30 days.  This parameter is solely a key
-   management database bookeeping parameter.  Failure to remove
-   information about the state of defunct keys from the database will
-   not adversely impact the security of this protocol, but may end up
-   with a database cluttered with obsolete key information.
-
-2.4.3.  Minimum Trust Anchors per Trust Point
-
-   A compliant resolver MUST be able to manage at least five SEP keys
-   per trust point.
-
-
-3.  Changes to DNSKEY RDATA Wire Format
-
-   Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE'
-   flag.  If this bit is set to '1', AND the resolver sees an
-   RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
-   consider this key permanently invalid for all purposes except for
-   validating the revocation.
-
-
-4.  State Table
-
-   The most important thing to understand is the resolver's view of any
-   key at a trust point.  The following state table describes that view
-
-
-
-StJohns                   Expires June 2, 2007                  [Page 6]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-   at various points in the key's lifetime.  The table is a normative
-   part of this specification.  The initial state of the key is 'Start'.
-   The resolver's view of the state of the key changes as various events
-   occur.
-
-   This is the state of a trust point key as seen from the resolver.
-   The column on the left indicates the current state.  The header at
-   the top shows the next state.  The intersection of the two shows the
-   event that will cause the state to transition from the current state
-   to the next.
-
-
-                             NEXT STATE
-           --------------------------------------------------
-    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
-   ----------------------------------------------------------
-   Start   |       |NewKey  |       |       |       |       |
-   ----------------------------------------------------------
-   AddPend |KeyRem |        |AddTime|       |       |
-   ----------------------------------------------------------
-   Valid   |       |        |       |KeyRem |Revbit |       |
-   ----------------------------------------------------------
-   Missing |       |        |KeyPres|       |Revbit |       |
-   ----------------------------------------------------------
-   Revoked |       |        |       |       |       |RemTime|
-   ----------------------------------------------------------
-   Removed |       |        |       |       |       |       |
-   ----------------------------------------------------------
-
-
-                                State Table
-
-4.1.  Events
-   NewKey  The resolver sees a valid DNSKEY RRSet with a new SEP key.
-      That key will become a new trust anchor for the named trust point
-      after it's been present in the RRSet for at least 'add time'.
-   KeyPres  The key has returned to the valid DNSKEY RRSet.
-   KeyRem  The resolver sees a valid DNSKEY RRSet that does not contain
-      this key.
-   AddTime  The key has been in every valid DNSKEY RRSet seen for at
-      least the 'add time'.
-   RemTime  A revoked key has been missing from the trust point DNSKEY
-      RRSet for sufficient time to be removed from the trust set.
-   RevBit  The key has appeared in the trust anchor DNSKEY RRSet with
-      its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
-      signed by this key.
-
-
-
-
-
-StJohns                   Expires June 2, 2007                  [Page 7]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-4.2.  States
-   Start  The key doesn't yet exist as a trust anchor at the resolver.
-      It may or may not exist at the zone server, but either hasn't yet
-      been seen at the resolver or was seen but was absent from the last
-      DNSKEY RRSet (e.g.  KeyRem event).
-   AddPend  The key has been seen at the resolver, has its 'SEP' bit
-      set, and has been included in a validated DNSKEY RRSet.  There is
-      a hold-down time for the key before it can be used as a trust
-      anchor.
-   Valid  The key has been seen at the resolver and has been included in
-      all validated DNSKEY RRSets from the time it was first seen up
-      through the hold-down time.  It is now valid for verifying RRSets
-      that arrive after the hold down time.  Clarification: The DNSKEY
-      RRSet does not need to be continuously present at the resolver
-      (e.g. its TTL might expire).  If the RRSet is seen, and is
-      validated (i.e. verifies against an existing trust anchor), this
-      key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
-   Missing  This is an abnormal state.  The key remains as a valid trust
-      point key, but was not seen at the resolver in the last validated
-      DNSKEY RRSet.  This is an abnormal state because the zone operator
-      should be using the REVOKE bit prior to removal.
-   Revoked  This is the state a key moves to once the resolver sees an
-      RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
-      this key with its REVOKE bit set to '1'.  Once in this state, this
-      key MUST permanently be considered invalid as a trust anchor.
-   Removed  After a fairly long hold-down time, information about this
-      key may be purged from the resolver.  A key in the removed state
-      MUST NOT be considered a valid trust anchor.  (Note: this state is
-      more or less equivalent to the "Start" state, except that it's bad
-      practice to re-introduce previously used keys - think of this as
-      the holding state for all the old keys for which the resolver no
-      longer needs to track state.)
-
-
-5.  Trust Point Deletion
-
-   A trust point which has all of its trust anchors revoked is
-   considered deleted and is treated as if the trust point was never
-   configured.  If there are no superior configured trust points, data
-   at and below the deleted trust point are considered insecure by the
-   resolver.  If there ARE superior configured trust points, data at and
-   below the deleted trust point are evaluated with respect to the
-   superior trust point(s).
-
-   Alternately, a trust point which is subordinate to another configured
-   trust point MAY be deleted by a resolver after 180 days where such
-   subordinate trust point validly chains to a superior trust point.
-   The decision to delete the subordinate trust anchor is a local
-
-
-
-StJohns                   Expires June 2, 2007                  [Page 8]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-   configuration decision.  Once the subordinate trust point is deleted,
-   validation of the subordinate zone is dependent on validating the
-   chain of trust to the superior trust point.
-
-
-6.  Scenarios - Informative
-
-   The suggested model for operation is to have one active key and one
-   stand-by key at each trust point.  The active key will be used to
-   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
-   RRSet, but the resolver will accept it as a trust anchor if/when it
-   sees the signature on the trust point DNSKEY RRSet.
-
-   Since the stand-by key is not in active signing use, the associated
-   private key may (and should) be provided with additional protections
-   not normally available to a key that must be used frequently.  E.g.
-   locked in a safe, split among many parties, etc.  Notionally, the
-   stand-by key should be less subject to compromise than an active key,
-   but that will be dependent on operational concerns not addressed
-   here.
-
-6.1.  Adding a Trust Anchor
-
-   Assume an existing trust anchor key 'A'.
-   1.  Generate a new key pair.
-   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
-       Key bits.
-   3.  Add the DNSKEY to the RRSet.
-   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
-       'A'.
-   5.  Wait a while (i.e. for various resolvers timers to go off and for
-       them to retrieve the new DNSKEY RRSet and signatures).
-   6.  The new trust anchor will be populated at the resolvers on the
-       schedule described by the state table and update algorithm - see
-       Section 2 above
-
-6.2.  Deleting a Trust Anchor
-
-   Assume existing trust anchors 'A' and 'B' and that you want to revoke
-   and delete 'A'.
-   1.  Set the revocation bit on key 'A'.
-   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.
-   'A' is now revoked.  The operator should include the revoked 'A' in
-   the RRSet for at least the remove hold-down time, but then may remove
-   it from the DNSKEY RRSet.
-
-
-
-
-
-
-StJohns                   Expires June 2, 2007                  [Page 9]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-6.3.  Key Roll-Over
-
-   Assume existing keys A and B. 'A' is actively in use (i.e. has been
-   signing the DNSKEY RRSet.)  'B' was the stand-by key. (i.e. has been
-   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
-   used to sign the RRSet.)
-   1.  Generate a new key pair 'C'.
-   2.  Add 'C' to the DNSKEY RRSet.
-   3.  Set the revocation bit on key 'A'.
-   4.  Sign the RRSet with 'A' and 'B'.
-   'A' is now revoked, 'B' is now the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  The operator should include
-   the revoked 'A' in the RRSet for at least the remove hold-down time,
-   but may then remove it from the DNSKEY RRSet.
-
-6.4.  Active Key Compromised
-
-   This is the same as the mechanism for Key Roll-Over (Section 6.3)
-   above assuming 'A' is the active key.
-
-6.5.  Stand-by Key Compromised
-
-   Using the same assumptions and naming conventions as Key Roll-Over
-   (Section 6.3) above:
-   1.  Generate a new key pair 'C'.
-   2.  Add 'C' to the DNSKEY RRSet.
-   3.  Set the revocation bit on key 'B'.
-   4.  Sign the RRSet with 'A' and 'B'.
-   'B' is now revoked, 'A' remains the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  'B' should continue to be
-   included in the RRSet for the remove hold-down time.
-
-6.6.  Trust Point Deletion
-
-   To delete a trust point which is subordinate to another configured
-   trust point (e.g. example.com to .com) requires some juggling of the
-   data.  The specific process is:
-   1.  Generate a new DNSKEY and DS record and provide the DS record to
-       the parent along with DS records for the old keys
-   2.  Once the parent has published the DSs, add the new DNSKEY to the
-       RRSet and revoke ALL of the old keys at the same time while
-       signing the DNSKEY RRSet with all of the old and new keys.
-   3.  After 30 days stop publishing the old, revoked keys and remove
-       any corresponding DS records in the parent.
-   Revoking the old trust point keys at the same time as adding new keys
-   that chain to a superior trust prevents the resolver from adding the
-   new keys as trust anchors.  Adding DS records for the old keys avoids
-   a race condition where either the subordinate zone becomes unsecure
-
-
-
-StJohns                   Expires June 2, 2007                 [Page 10]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-   (because the trust point was deleted) or becomes bogus (because it
-   didn't chain to the superior zone).
-
-
-7.  IANA Considerations
-
-   The IANA will need to assign a bit in the DNSKEY flags field (see
-   section 4.3 of [RFC3755]) for the REVOKE bit.  There are no other
-   IANA actions required.
-
-
-8.  Security Considerations
-
-   In addition to the following sections, see also Theory of Operation
-   above and especially Section 2.2 for related discussions.
-
-8.1.  Key Ownership vs Acceptance Policy
-
-   The reader should note that, while the zone owner is responsible for
-   creating and distributing keys, it's wholly the decision of the
-   resolver owner as to whether to accept such keys for the
-   authentication of the zone information.  This implies the decision to
-   update trust anchor keys based on trust for a current trust anchor
-   key is also the resolver owner's decision.
-
-   The resolver owner (and resolver implementers) MAY choose to permit
-   or prevent key status updates based on this mechanism for specific
-   trust points.  If they choose to prevent the automated updates, they
-   will need to establish a mechanism for manual or other out-of-band
-   updates outside the scope of this document.
-
-8.2.  Multiple Key Compromise
-
-   This scheme permits recovery as long as at least one valid trust
-   anchor key remains uncompromised.  E.g. if there are three keys, you
-   can recover if two of them are compromised.  The zone owner should
-   determine their own level of comfort with respect to the number of
-   active valid trust anchors in a zone and should be prepared to
-   implement recovery procedures once they detect a compromise.  A
-   manual or other out-of-band update of all resolvers will be required
-   if all trust anchor keys at a trust point are compromised.
-
-8.3.  Dynamic Updates
-
-   Allowing a resolver to update its trust anchor set based on in-band
-   key information is potentially less secure than a manual process.
-   However, given the nature of the DNS, the number of resolvers that
-   would require update if a trust anchor key were compromised, and the
-
-
-
-StJohns                   Expires June 2, 2007                 [Page 11]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-   lack of a standard management framework for DNS, this approach is no
-   worse than the existing situation.
-
-
-9.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-Editorial Comments
-
-   [msj2]  msj: To be assigned.
-
-
-Author's Address
-
-   Michael StJohns
-   Nominum, Inc.
-   2385 Bay Road
-   Redwood City, CA  94063
-   USA
-
-   Phone: +1-301-528-4729
-   Email: Mike.StJohns@nominum.com
-   URI:   www.nominum.com
-
-
-
-
-
-
-
-
-
-
-
-StJohns                   Expires June 2, 2007                 [Page 12]
-
-Internet-Draft             trustanchor-update              November 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-StJohns                   Expires June 2, 2007                 [Page 13]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
deleted file mode 100644
index 9cf88a5831..0000000000
--- a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
+++ /dev/null
@@ -1,1063 +0,0 @@
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-DNSEXT Working Group                                          E. Lewis
-INTERNET DRAFT                                                 NeuStar
-Expiration Date: July 9, 2006                          January 9, 2006
-Updates RFC 1034, RFC 2672
-
-                              The Role of Wildcards
-                            in the Domain Name System
-                      draft-ietf-dnsext-wcard-clarify-10.txt
-
-Status of this Memo
-
-      By submitting this Internet-Draft, each author represents that
-      any applicable patent or other IPR claims of which he or she is
-      aware have been or will be disclosed, and any of which he or she
-      becomes aware will be disclosed, in accordance with Section 6 of
-      BCP 79.
-
-      Internet-Drafts are working documents of the Internet Engineering
-      Task Force (IETF), its areas, and its working groups.  Note that
-      other groups may also distribute working documents as Internet-
-      Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of six
-      months and may be updated, replaced, or obsoleted by other
-      documents at any time.  It is inappropriate to use Internet-Drafts
-      as reference material or to cite them other than as "work in
-      progress."
-
-      The list of current Internet-Drafts can be accessed at
-        http://www.ietf.org/ietf/1id-abstracts.txt
-
-      The list of Internet-Draft Shadow Directories can be accessed at
-        http://www.ietf.org/shadow.html
-
-      This Internet-Draft will expire on July 9, 2006.
-
-Copyright Notice
-
-      Copyright (C) The Internet Society (2006).
-
-Abstract
-
-      This is an update to the wildcard definition of RFC 1034.  The
-      interaction with wildcards and CNAME is changed, an error
-      condition removed, and the words defining some concepts central
-      to wildcards are changed.  The overall goal is not to change
-      wildcards, but to refine the definition of RFC 1034.
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  1]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-Table of Contents
-
-1.    Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  3
-1 1   Motivation                                                     3
-1 2   The Original Definition                                        3
-1 3   Roadmap to This Document                                       4
-1 3 1 New Terms                                                      4
-1.3.2 Changed Text                                                   5
-1.3.3 Considerations with Special Types                              5
-1.4   Standards Terminology                                          5
-2.    Wildcard Syntax   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  6
-2.1   Identifying a Wildcard                                         6
-2.1.1 Wild Card Domain Name and Asterisk Label                       6
-2.1.2 Asterisks and Other Characters                                 6
-2.1.3 Non-terminal Wild Card Domain Names                            6
-2.2   Existence Rules                                                7
-2.2.1 An Example                                                     7
-2.2.2 Empty Non-terminals                                            9
-2.2.3 Yet Another Definition of Existence                           10
-2.3   When is a Wild Card Domain Name Not Special                   10
-3.    Impact of a Wild Card Domain Name On a Response .  .  .  .  . 10
-3.1   Step 2                                                        10
-3.2   Step 3                                                        11
-3.3   Part 'c'                                                      11
-3.3.1 Closest Encloser and the Source of Synthesis                  12
-3.3.2 Closest Encloser and Source of Synthesis Examples             12
-3.3.3 Type Matching                                                 13
-4.    Considerations with Special Types   .  .  .  .  .  .  .  .  . 13
-4.1   SOA RRSet at a Wild Card Domain Name                          13
-4.2   NS RRSet at a Wild Card Domain Name                           14
-4.2.1 Discarded Notions                                             14
-4.3   CNAME RRSet at a Wild Card Domain Name                        15
-4.4   DNAME RRSet at a Wild Card Domain Name                        15
-4.5   SRV RRSet at a Wild Card Domain Name                          16
-4.6   DS RRSet at a Wild Card Domain Name                           16
-4.7   NSEC RRSet at a Wild Card Domain Name                         17
-4.8   RRSIG at a Wild Card Domain Name                              17
-4.9   Empty Non-terminal Wild Card Domain Name                      17
-5.    Security Considerations .  .  .  .  .  .  .  .  .  .  .  .  . 17
-6.    IANA Considerations     .  .  .  .  .  .  .  .  .  .  .  .  . 17
-7.    References              .  .  .  .  .  .  .  .  .  .  .  .  . 17
-8.    Editor                  .  .  .  .  .  .  .  .  .  .  .  .  . 18
-9.    Others Contributing to the Document    .  .  .  .  .  .  .  . 18
-10.   Trailing Boilerplate    .  .  .  .  .  .  .  .  .  .  .  .  . 19
-
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  2]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-1. Introduction
-
-      In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
-      synthesis of answers from special resource records called
-      wildcards.  The definition in RFC 1034 is incomplete and has
-      proven to be confusing.  This document describes the wildcard
-      synthesis by adding to the discussion and making limited
-      modifications.  Modifications are made to close inconsistencies
-      that have led to interoperability issues.  This description
-      does not expand the service intended by the original definition.
-
-      Staying within the spirit and style of the original documents,
-      this document avoids specifying rules for DNS implementations
-      regarding wildcards.  The intention is to only describe what is
-      needed for interoperability, not restrict implementation choices.
-      In addition, consideration is given to minimize any backwards
-      compatibility issues with implementations that comply with RFC
-      1034's definition.
-
-      This document is focused on the concept of wildcards as defined
-      in RFC 1034.  Nothing is implied regarding alternative means of
-      synthesizing resource record sets, nor are alternatives discussed.
-
-1.1 Motivation
-
-      Many DNS implementations diverge, in different ways, from the
-      original definition of wildcards.  Although there is clearly a
-      need to clarify the original documents in light of this alone,
-      the impetus for this document lay in the engineering of the DNS
-      security extensions [RFC4033].  With an unclear definition of
-      wildcards the design of authenticated denial became entangled.
-
-      This document is intended to limit its changes, documenting only
-      those based on implementation experience, and to remain as close
-      to the original document as possible.  To reinforce that this
-      document is meant to clarify and adjust and not redefine wildcards,
-      relevant sections of RFC 1034 are repeated verbatim to facilitate
-      comparison of the old and new text.
-
-1.2 The Original Definition
-
-      The definition of the wildcard concept is comprised by the
-      documentation of the algorithm by which a name server prepares
-      a response (in RFC 1034's section 4.3.2) and the way in which
-      a resource record (set) is identified as being a source of
-      synthetic data (section 4.3.3).
-
-      This is the definition of the term "wildcard" as it appears in
-      RFC 1034, section 4.3.3.
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  3]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-# In the previous algorithm, special treatment was given to RRs with
-# owner names starting with the label "*".  Such RRs are called
-# wildcards. Wildcard RRs can be thought of as instructions for
-# synthesizing RRs.  When the appropriate conditions are met, the name
-# server creates RRs with an owner name equal to the query name and
-# contents taken from the wildcard RRs.
-
-      This passage follows the algorithm in which the term wildcard
-      is first used.   In this definition, wildcard refers to resource
-      records.  In other usage, wildcard has referred to domain names,
-      and it has been used to describe the operational practice of
-      relying on wildcards to generate answers.  It is clear from this
-      that there is a need to define clear and unambiguous terminology
-      in the process of discussing wildcards.
-
-      The mention of the use of wildcards in the preparation of a
-      response is contained in step 3c of RFC 1034's section 4.3.2
-      entitled "Algorithm."  Note that "wildcard" does not appear in
-      the algorithm, instead references are made to the "*" label.
-      The portion of the algorithm relating to wildcards is
-      deconstructed in detail in section 3 of this document, this is
-      the beginning of the relevant portion of the "Algorithm."
-
-#    c. If at some label, a match is impossible (i.e., the
-#       corresponding label does not exist), look to see if [...]
-#       the "*" label exists.
-
-      The scope of this document is the RFC 1034 definition of
-      wildcards and the implications of updates to those documents,
-      such as DNSSEC.  Alternate schemes for synthesizing answers are
-      not considered.  (Note that there is no reference listed.  No
-      document is known to describe any alternate schemes, although
-      there has been some mention of them in mailing lists.)
-
-1.3 Roadmap to This Document
-
-      This document accomplishes these three items.
-      o Defines new terms
-      o Makes minor changes to avoid conflicting concepts
-      o Describes the actions of certain resource records as wildcards
-
-1.3.1 New Terms
-
-      To help in discussing what resource records are wildcards, two
-      terms will be defined - "asterisk label" and "wild card domain
-      name".  These are defined in section 2.1.1.
-
-      To assist in clarifying the role of wildcards in the name server
-      algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
-      encloser" are defined.  These definitions are in section 3.3.2.
-      "Label match" is defined in section 3.2.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  4]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      The new terms are used to make discussions of wildcards clearer.
-      Terminology doesn't directly have an impact on implementations.
-
-1.3.2 Changed Text
-
-      The definition of "existence" is changed superficially.  This
-      change will not be apparent to implementations; it is needed to
-      make descriptions more precise.  The change appears in section
-      2.2.3.
-
-      RFC 1034, section 4.3.3., seems to prohibit having two asterisk
-      labels in a wildcard owner name.  With this document the
-      restriction is removed entirely.  This change and its implications
-      are in section 2.1.3.
-
-      The actions when a source of synthesis owns a CNAME RR are
-      changed to mirror the actions if an exact match name owns a
-      CNAME RR.  This is an addition to the words in RFC 1034,
-      section 4.3.2, step 3, part c.  The discussion of this is in
-      section 3.3.3.
-
-      Only the latter change represents an impact to implementations.
-      The definition of existence is not a protocol impact.  The change
-      to the restriction on names is unlikely to have an impact, as
-      RFC 1034 contained no specification on when and how to enforce the
-      restriction.
-
-1.3.3 Considerations with Special Types
-
-      This document describes semantics of wildcard RRSets for
-      "interesting" types as well as empty non-terminal wildcards.
-      Understanding these situations in the context of wildcards has
-      been clouded because these types incur special processing if
-      they are the result of an exact match.  This discussion is in
-      section 4.
-
-      These discussions do not have an implementation impact, they cover
-      existing knowledge of the types, but to a greater level of detail.
-
-1.4 Standards Terminology
-
-      This document does not use terms as defined in "Key words for use
-      in RFCs to Indicate Requirement Levels." [RFC2119]
-
-      Quotations of RFC 1034 are denoted by a '#' in the leftmost
-      column.  References to section "4.3.2" are assumed to refer
-      to RFC 1034's section 4.3.2, simply titled "Algorithm."
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  5]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-2. Wildcard Syntax
-
-      The syntax of a wildcard is the same as any other DNS resource
-      record, across all classes and types.  The only significant
-      feature is the owner name.
-
-      Because wildcards are encoded as resource records with special
-      names, they are included in zone transfers and incremental zone
-      transfers[RFC1995] just as non-wildcard resource records are.
-      This feature has been under appreciated until discussions on
-      alternative approaches to wildcards appeared on mailing lists.
-
-2.1 Identifying a Wildcard
-
-      To provide a more accurate description of wildcards, the
-      definition has to start with a discussion of the domain names
-      that appear as owners.  Two new terms are needed, "Asterisk
-      Label" and "Wild Card Domain Name."
-
-2.1.1 Wild Card Domain Name and Asterisk Label
-
-      A "wild card domain name" is defined by having its initial
-      (i.e., left-most or least significant) label be, in binary format:
-
-           0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
-      The first octet is the normal label type and length for a 1 octet
-      long label, the second octet is the ASCII representation [RFC20]
-      for the '*' character.
-
-      A descriptive name of a label equaling that value is an "asterisk
-      label."
-
-      RFC 1034's definition of wildcard would be "a resource record
-      owned by a wild card domain name."
-
-2.1.2 Asterisks and Other Characters
-
-      No label values other than that in section 2.1.1 are asterisk
-      labels, hence names beginning with other labels are never wild
-      card domain names.  Labels such as 'the*' and '**' are not
-      asterisk labels so these labels do not start wild card domain
-      names.
-
-2.1.3 Non-terminal Wild Card Domain Names
-
-      In section 4.3.3, the following is stated:
-
-# ..........................  The owner name of the wildcard RRs is of
-# the form "*.<anydomain>", where <anydomain> is any domain name.
-# <anydomain> should not contain other * labels......................
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  6]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      The restriction is now removed.  The original documentation of it
-      is incomplete and the restriction does not serve any purpose
-      given years of operational experience.
-
-      There are three possible reasons for putting the restriction in
-      place, but none of the three has held up over time.  One is
-      that the restriction meant that there would never be subdomains
-      of wild card domain names, but the restriciton as stated still
-      permits "example.*.example." for instance.  Another is that
-      wild card domain names are not intended to be empty non-terminals,
-      but this situation does not disrupt the algorithm in 4.3.2.
-      Finally, "nested" wild card domain names are not ambiguous once
-      the concept of the closest encloser had been documented.
-
-      A wild card domain name can have subdomains.  There is no need
-      to inspect the subdomains to see if there is another asterisk
-      label in any subdomain.
-
-      A wild card domain name can be an empty non-terminal.  (See the
-      upcoming sections on empty non-terminals.)  In this case, any
-      lookup encountering it will terminate as would any empty
-      non-terminal match.
-
-2.2 Existence Rules
-
-      The notion that a domain name 'exists' is mentioned in the
-      definition of wildcards.  In section 4.3.3 of RFC 1034:
-
-# Wildcard RRs do not apply:
-#
-...
-#   - When the query name or a name between the wildcard domain and
-#     the query name is know[n] to exist.  For example, if a wildcard
-
-      "Existence" is therefore an important concept in the understanding
-      of wildcards.  Unfortunately, the definition of what exists, in RFC
-      1034, is unclear.  So, in sections 2.2.2. and 2.2.3, another look is
-      taken at the definition of existence.
-
-2.2.1 An Example
-
-      To illustrate what is meant by existence consider this complete
-      zone:
-
-
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  7]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-        $ORIGIN example.
-        example.                 3600 IN  SOA   <SOA RDATA>
-        example.                 3600     NS    ns.example.com.
-        example.                 3600     NS    ns.example.net.
-        *.example.               3600     TXT   "this is a wild card"
-        *.example.               3600     MX    10 host1.example.
-        sub.*.example.           3600     TXT   "this is not a wild card"
-        host1.example.           3600     A     192.0.4.1
-        _ssh._tcp.host1.example. 3600     SRV  <SRV RDATA>
-        _ssh._tcp.host2.example. 3600     SRV  <SRV RDATA>
-        subdel.example.          3600     NS   ns.example.com.
-        subdel.example.          3600     NS   ns.example.net.
-
-      A look at the domain names in a tree structure is helpful:
-
-                                    |
-                    -------------example------------
-                   /           /         \          \
-                  /           /           \          \
-                 /           /             \          \
-                *          host1          host2      subdel
-                |            |             |
-                |            |             |
-               sub         _tcp          _tcp
-                             |             |
-                             |             |
-                           _ssh          _ssh
-
-      The following responses would be synthesized from one of the
-      wildcards in the zone:
-
-          QNAME=host3.example. QTYPE=MX, QCLASS=IN
-               the answer will be a "host3.example. IN MX ..."
-
-          QNAME=host3.example. QTYPE=A, QCLASS=IN
-               the answer will reflect "no error, but no data"
-               because there is no A RR set at '*.example.'
-
-          QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
-               the answer will be "foo.bar.example. IN TXT ..."
-               because bar.example. does not exist, but the wildcard
-               does.
-
-      The following responses would not be synthesized from any of the
-      wildcards in the zone:
-
-          QNAME=host1.example., QTYPE=MX, QCLASS=IN
-               because host1.example. exists
-
-          QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
-               because sub.*.example. exists
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  8]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-          QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
-               because _tcp.host1.example. exists (without data)
-
-          QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
-               because subdel.example. exists (and is a zone cut)
-
-          QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
-               because *.example. exists
-
-      The final example highlights one common misconception about
-      wildcards.  A wildcard "blocks itself" in the sense that a
-      wildcard does not match its own subdomains.  I.e. "*.example."
-      does not match all names in the "example." zone, it fails to
-      match the names below "*.example." To cover names under
-      "*.example.", another wild card domain name is needed -
-      "*.*.example." - which covers all but it's own subdomains.
-
-2.2.2 Empty Non-terminals
-
-      Empty non-terminals [RFC2136, Section 7.16] are domain names
-      that own no resource records but have subdomains that do.  In
-      section 2.2.1, "_tcp.host1.example." is an example of a empty
-      non-terminal name.  Empty non-terminals are introduced by this
-      text in section 3.1 of RFC 1034:
-
-# The domain name space is a tree structure.  Each node and leaf on
-# the tree corresponds to a resource set (which may be empty).  The
-# domain system makes no distinctions between the uses of the
-# interior nodes and leaves, and this memo uses the term "node" to
-# refer to both.
-
-      The parenthesized "which may be empty" specifies that empty non-
-      terminals are explicitly recognized, and that empty non-terminals
-      "exist."
-
-      Pedantically reading the above paragraph can lead to an
-      interpretation that all possible domains exist - up to the
-      suggested limit of 255 octets for a domain name [RFC1035].
-      For example, www.example. may have an A RR, and as far as is
-      practically concerned, is a leaf of the domain tree.  But the
-      definition can be taken to mean that sub.www.example. also
-      exists, albeit with no data.  By extension, all possible domains
-      exist, from the root on down.
-
-      As RFC 1034 also defines "an authoritative name error indicating
-      that the name does not exist" in section 4.3.1, so this apparently
-      is not the intent of the original definition, justifying the
-      need for an updated definition in the next section.
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  9]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-2.2.3 Yet Another Definition of Existence
-
-      RFC1034's wording is fixed by the following paragraph:
-
-      The domain name space is a tree structure.  Nodes in the tree
-      either own at least one RRSet and/or have descendants that
-      collectively own at least one RRSet.  A node may exist with no
-      RRSets only if it has descendents that do, this node is an empty
-      non-terminal.
-
-      A node with no descendants is a leaf node.  Empty leaf nodes do
-      not exist.
-
-      Note that at a zone boundary, the domain name owns data,
-      including the NS RR set.  In the delegating zone, the NS RR
-      set is not authoritative, but that is of no consequence here.
-      The domain name owns data, therefore, it exists.
-
-2.3 When is a Wild Card Domain Name Not Special
-
-      When a wild card domain name appears in a message's query section,
-      no special processing occurs.  An asterisk label in a query name
-      only matches a single, corresponding asterisk label in the
-      existing zone tree when the 4.3.2 algorithm is being followed.
-
-      When a wild card domain name appears in the resource data of a
-      record, no special processing occurs.  An asterisk label in that
-      context literally means just an asterisk.
-
-3. Impact of a Wild Card Domain Name On a Response
-
-      RFC 1034's description of how wildcards impact response
-      generation is in its section 4.3.2.  That passage contains the
-      algorithm followed by a server in constructing a response.
-      Within that algorithm, step 3, part 'c' defines the behavior of
-      the wildcard.
-
-      The algorithm in section 4.3.2. is not intended to be pseudo-code,
-      i.e., its steps are not intended to be followed in strict order.
-      The "algorithm" is a suggested means of implementing the
-      requirements.  As such, in step 3, parts a, b, and c, do not have
-      to be implemented in that order, provided that the result of the
-      implemented code is compliant with the protocol's specification.
-
-3.1 Step 2
-
-      Step 2 of section 4.3.2 reads:
-
-#   2. Search the available zones for the zone which is the nearest
-#      ancestor to QNAME.  If such a zone is found, go to step 3,
-#      otherwise step 4.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 10]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      In this step, the most appropriate zone for the response is
-      chosen.  The significance of this step is that it means all of
-      step 3 is being performed within one zone.  This has significance
-      when considering whether or not an SOA RR can be ever be used for
-      synthesis.
-
-3.2 Step 3
-
-      Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
-      But the beginning of the step is important and needs explanation.
-
-#   3. Start matching down, label by label, in the zone.  The
-#      matching process can terminate several ways:
-
-      The word 'matching' refers to label matching.  The concept
-      is based in the view of the zone as the tree of existing names.
-      The query name is considered to be an ordered sequence of
-      labels - as if the name were a path from the root to the owner
-      of the desired data.  (Which it is - 3rd paragraph of RFC 1034,
-      section 3.1.)
-
-      The process of label matching a query name ends in exactly one of
-      three choices, the parts 'a', 'b', and 'c'.  Either the name is
-      found, the name is below a cut point, or the name is not found.
-
-      Once one of the parts is chosen, the other parts are not
-      considered.  (E.g., do not execute part 'c' and then change
-      the execution path to finish in part 'b'.)  The process of label
-      matching is also done independent of the query type (QTYPE).
-
-      Parts 'a' and 'b' are not an issue for this clarification as they
-      do not relate to record synthesis.  Part 'a' is an exact match
-      that results in an answer, part 'b' is a referral.
-
-3.3 Part 'c'
-
-      The context of part 'c' is that the process of label matching the
-      labels of the query name has resulted in a situation in which
-      there is no corresponding label in the tree.  It is as if the
-      lookup has "fallen off the tree."
-
-#     c. If at some label, a match is impossible (i.e., the
-#        corresponding label does not exist), look to see if [...]
-#        the "*" label exists.
-
-      To help describe the process of looking 'to see if [...] the "*"
-      label exists' a term has been coined to describe the last domain
-      (node) matched.  The term is "closest encloser."
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 11]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-3.3.1 Closest Encloser and the Source of Synthesis
-
-      The closest encloser is the node in the zone's tree of existing
-      domain names that has the most labels matching the query name
-      (consecutively, counting from the root label downward). Each match
-      is a "label match" and the order of the labels is the same.
-
-      The closest encloser is, by definition, an existing name in the
-      zone.  The closest encloser might be an empty non-terminal or even
-      be a wild card domain name itself.  In no circumstances is the
-      closest encloser to be used to synthesize records for the current
-      query.
-
-      The source of synthesis is defined in the context of a query
-      process as that wild card domain name immediately descending
-      from the closest encloser, provided that this wild card domain
-      name exists.  "Immediately descending" means that the source
-      of synthesis has a name of the form:
-            <asterisk label>.<closest encloser>.
-      A source of synthesis does not guarantee having a RRSet to use
-      for synthesis.  The source of synthesis could be an empty
-      non-terminal.
-
-      If the source of synthesis does not exist (not on the domain
-      tree), there will be no wildcard synthesis.  There is no search
-      for an alternate.
-
-      The important concept is that for any given lookup process, there
-      is at most one place at which wildcard synthetic records can be
-      obtained.  If the source of synthesis does not exist, the lookup
-      terminates, the lookup does not look for other wildcard records.
-
-3.3.2 Closest Encloser and Source of Synthesis Examples
-
-      To illustrate, using the example zone in section 2.2.1 of this
-      document, the following chart shows QNAMEs and the closest
-      enclosers.
-
-      QNAME                       Closest Encloser    Source of Synthesis
-      host3.example.              example.            *.example.
-      _telnet._tcp.host1.example. _tcp.host1.example. no source
-      _telnet._tcp.host2.example. host2.example.      no source
-      _telnet._tcp.host3.example. example.            *.example.
-      _chat._udp.host3.example.   example.            *.example.
-      foobar.*.example.           *.example.          no source
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 12]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-3.3.3 Type Matching
-
-       RFC 1034 concludes part 'c' with this:
-
-#            If the "*" label does not exist, check whether the name
-#            we are looking for is the original QNAME in the query
-#            or a name we have followed due to a CNAME.  If the name
-#            is original, set an authoritative name error in the
-#            response and exit.  Otherwise just exit.
-#
-#            If the "*" label does exist, match RRs at that node
-#            against QTYPE.  If any match, copy them into the answer
-#            section, but set the owner of the RR to be QNAME, and
-#            not the node with the "*" label.  Go to step 6.
-
-      The final paragraph covers the role of the QTYPE in the lookup
-      process.
-
-      Based on implementation feedback and similarities between step
-      'a' and step 'c' a change to this passage has been made.
-
-      The change is to add the following text to step 'c' prior to the
-      instructions to "go to step 6":
-
-               If the data at the source of synthesis is a CNAME, and
-               QTYPE doesn't match CNAME, copy the CNAME RR into the
-               answer section of the response changing the owner name
-               to the QNAME, change QNAME to the canonical name in the
-               CNAME RR, and go back to step 1.
-
-      This is essentially the same text in step a covering the
-      processing of CNAME RRSets.
-
-4. Considerations with Special Types
-
-      Sections 2 and 3 of this document discuss wildcard synthesis
-      with respect to names in the domain tree and ignore the impact
-      of types.  In this section, the implication of wildcards of
-      specific types are discussed.  The types covered are those
-      that have proven to be the most difficult to understand.  The
-      types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
-      "none," i.e., empty non-terminal wild card domain names.
-
-4.1 SOA RRSet at a Wild Card Domain Name
-
-      A wild card domain name owning an SOA RRSet means that the
-      domain is at the root of the zone (apex).  The domain can not
-      be a source of synthesis because that is, by definition, a
-      descendent node (of the closest encloser) and a zone apex is
-      at the top of the zone.
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 13]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      Although a wild card domain name owning an SOA RRSet can never
-      be a source of synthesis, there is no reason to forbid the
-      ownership of an SOA RRSet.
-
-      E.g., given this zone:
-             $ORIGIN *.example.
-             @                 3600 IN  SOA   <SOA RDATA>
-                               3600     NS    ns1.example.com.
-                               3600     NS    ns1.example.net.
-             www               3600     TXT   "the www txt record"
-
-      A query for www.*.example.'s TXT record would still find the
-      "the www txt record" answer.  The asterisk label only becomes
-      significant when section 4.3.2, step 3 part 'c' is in effect.
-
-      Of course, there would need to be a delegation in the parent
-      zone, "example." for this to work too.  This is covered in the
-      next section.
-
-4.2 NS RRSet at a Wild Card Domain Name
-
-      With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
-      in place, the semantics of a wild card domain name owning an
-      NS RRSet has come to be poorly defined.  The dilemma relates to
-      a conflict between the rules for synthesis in part 'c' and the
-      fact that the resulting synthesis generates a record for which
-      the zone is not authoritative.  In a DNSSEC signed zone, the
-      mechanics of signature management (generation and inclusion
-      in a message) have become unclear.
-
-      Salient points of the working group discussion on this topic is
-      summarized in section 4.2.1.
-
-      As a result of these discussion, there is no definition given for
-      wild card domain names owning an NS RRSet.  The semantics are
-      left undefined until there is a clear need to have a set defined,
-      and until there is a clear direction to proceed.  Operationally,
-      inclusion of wild card NS RRSets in a zone is discouraged, but
-      not barred.
-
-4.2.1 Discarded Notions
-
-      Prior to DNSSEC, a wild card domain name owning a NS RRSet
-      appeared to be workable, and there are some instances in which
-      it is found in deployments using implementations that support
-      this.  Continuing to allow this in the specification is not
-      tenable with DNSSEC.  The reason is that the synthesis of the
-      NS RRSet is being done in a zone that has delegated away the
-      responsibility for the name.  This "unauthorized" synthesis is
-      not a problem for the base DNS protocol, but DNSSEC, in affirming
-      the authorization model for DNS exposes the problem.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 14]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      Outright banning of wildcards of type NS is also untenable as
-      the DNS protocol does not define how to handle "illegal" data.
-      Implementations may choose not to load a zone, but there is no
-      protocol definition.  The lack of the definition is complicated
-      by having to cover dynamic update [RFC 2136], zone transfers,
-      as well as loading at the master server.  The case of a client
-      (resolver, caching server) getting a wildcard of type NS in
-      a reply would also have to be considered.
-
-      Given the daunting challenge of a complete definition of how to
-      ban such records, dealing with existing implementations that
-      permit the records today is a further complication.  There are
-      uses of wild card domain name owning NS RRSets.
-
-      One compromise proposed would have redefined wildcards of type
-      NS to not be used in synthesis, this compromise fell apart
-      because it would have required significant edits to the DNSSEC
-      signing and validation work.  (Again, DNSSEC catches
-      unauthorized data.)
-
-      With no clear consensus forming on the solution to this dilemma,
-      and the realization that wildcards of type NS are a rarity in
-      operations, the best course of action is to leave this open-ended
-      until "it matters."
-
-4.3 CNAME RRSet at a Wild Card Domain Name
-
-      The issue of a CNAME RRSet owned by a wild card domain name has
-      prompted a suggested change to the last paragraph of step 3c of
-      the algorithm in 4.3.2.  The changed text appears in section
-      3.3.3 of this document.
-
-4.4 DNAME RRSet at a Wild Card Domain Name
-
-      Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
-      represents a threat to the coherency of the DNS and is to be
-      avoided or outright rejected.  Such a DNAME RRSet represents
-      non-deterministic synthesis of rules fed to different caches.
-      As caches are fed the different rules (in an unpredictable
-      manner) the caches will cease to be coherent.  ("As caches
-      are fed" refers to the storage in a cache of records obtained
-      in responses by recursive or iterative servers.)
-
-      For example, assume one cache, responding to a recursive
-      request, obtains the record:
-         "a.b.example. DNAME foo.bar.example.net."
-      and another cache obtains:
-         "b.example.  DNAME foo.bar.example.net."
-      both generated from the record:
-         "*.example. DNAME foo.bar.example.net."
-      by an authoritative server.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 15]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      The DNAME specification is not clear on whether DNAME records
-      in a cache are used to rewrite queries.  In some interpretations,
-      the rewrite occurs, in some, it is not.  Allowing for the
-      occurrence of rewriting, queries for "sub.a.b.example. A" may
-      be rewritten as "sub.foo.bar.tld. A" by the former caching
-      server and may be rewritten as "sub.a.foo.bar.tld. A" by the
-      latter.  Coherency is lost, an operational nightmare ensues.
-
-      Another justification for banning or avoiding wildcard DNAME
-      records is the observation that such a record could synthesize
-      a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
-      There is a restriction in the DNAME definition that no domain
-      exist below a DNAME-owning domain, hence, the wildcard DNAME
-      is not to be permitted.
-
-4.5 SRV RRSet at a Wild Card Domain Name
-
-      The definition of the SRV RRset is RFC 2782 [RFC2782].  In the
-      definition of the record, there is some confusion over the term
-      "Name."  The definition reads as follows:
-
-# The format of the SRV RR
-...
-#    _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-...
-#  Name
-#   The domain this RR refers to.  The SRV RR is unique in that the
-#   name one searches for is not this name; the example near the end
-#   shows this clearly.
-
-      Do not confuse the definition "Name" with the owner name.  I.e.,
-      once removing the _Service and _Proto labels from the owner name
-      of the SRV RRSet, what remains could be a wild card domain name
-      but this is immaterial to the SRV RRSet.
-
-      E.g.,  If an SRV record is:
-         _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
-
-      *.example is a wild card domain name and although it is the Name
-      of the SRV RR, it is not the owner (domain name).  The owner
-      domain name is "_foo._udp.*.example." which is not a wild card
-      domain name.
-
-      The confusion is likely based on the mixture of the specification
-      of the SRV RR and the description of a "use case."
-
-4.6 DS RRSet at a Wild Card Domain Name
-
-      A DS RRSet owned by a wild card domain name is meaningless and
-      harmless.  This statement is made in the context that an NS RRSet
-      at a wild card domain name is undefined.  At a non-delegation
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 16]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      point, a DS RRSet has no value (no corresponding DNSKEY RRSet
-      will be used in DNSSEC validation).  If there is a synthesized
-      DS RRSet, it alone will not be very useful as it exists in the
-      context of a delegation point.
-
-4.7 NSEC RRSet at a Wild Card Domain Name
-
-      Wild card domain names in DNSSEC signed zones will have an NSEC
-      RRSet.  Synthesis of these records will only occur when the
-      query exactly matches the record.  Synthesized NSEC RR's will not
-      be harmful as they will never be used in negative caching or to
-      generate a negative response.  [RFC2308]
-
-4.8 RRSIG at a Wild Card Domain Name
-
-      RRSIG records will be present at a wild card domain name in a
-      signed zone, and will be synthesized along with data sought in a
-      query.  The fact that the owner name is synthesized is not a
-      problem as the label count in the RRSIG will instruct the
-      verifying code to ignore it.
-
-4.9 Empty Non-terminal Wild Card Domain Name
-
-      If a source of synthesis is an empty non-terminal, then the
-      response will be one of no error in the return code and no RRSet
-      in the answer section.
-
-5. Security Considerations
-
-      This document is refining the specifications to make it more
-      likely that security can be added to DNS.  No functional
-      additions are being made, just refining what is considered
-      proper to allow the DNS, security of the DNS, and extending
-      the DNS to be more predictable.
-
-6. IANA Considerations
-
-       None.
-
-7. References
-
-      Normative References
-
-      [RFC20]   ASCII Format for Network Interchange, V.G. Cerf,
-                Oct-16-1969
-
-      [RFC1034] Domain Names - Concepts and Facilities,
-                P.V. Mockapetris, Nov-01-1987
-
-      [RFC1035] Domain Names - Implementation and Specification, P.V
-                Mockapetris, Nov-01-1987
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 17]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
-
-      [RFC2119] Key Words for Use in RFCs to Indicate Requirement
-                Levels, S Bradner, March 1997
-
-      [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
-                M. Andrews, March 1998
-
-      [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
-                August 1999.
-
-      [RFC2782] A DNS RR for specifying the location of services (DNS
-                SRV), A. Gulbrandsen, et.al., February 2000
-
-      [RFC4033] DNS Security Introduction and Requirements, R. Arends,
-                et.al., March 2005
-
-      [RFC4034] Resource Records for the DNS Security Extensions,
-                R. Arends, et.al., March 2005
-
-      [RFC4035] Protocol Modifications for the DNS Security Extensions,
-                R. Arends, et.al., March 2005
-
-      Informative References
-
-      [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
-                P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
-                April 1997
-
-8. Editor
-
-           Name:         Edward Lewis
-           Affiliation:  NeuStar
-           Address:      46000 Center Oak Plaza, Sterling, VA, 20166, US
-           Phone:        +1-571-434-5468
-           Email:        ed.lewis@neustar.biz
-
-      Comments on this document can be sent to the editor or the mailing
-      list for the DNSEXT WG, namedroppers@ops.ietf.org.
-
-9. Others Contributing to the Document
-
-      This document represents the work of a large working group.  The
-      editor merely recorded the collective wisdom of the working group.
-
-
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 17]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-10. Trailing Boilerplate
-
-      Copyright (C) The Internet Society (2006).
-
-      This document is subject to the rights, licenses and restrictions
-      contained in BCP 78, and except as set forth therein, the authors
-      retain all their rights.
-
-      This document and the information contained herein are provided
-      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
-      HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
-      SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
-      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
-      ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
-      INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-      MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-      The IETF takes no position regarding the validity or scope of
-      any Intellectual Property Rights or other rights that might
-      be claimed to pertain to the implementation or use of the
-      technology described in this document or the extent to which
-      any license under such rights might or might not be available;
-      nor does it represent that it has made any independent effort
-      to identify any such rights.  Information on the procedures
-      with respect to rights in RFC documents can be found in BCP 78
-      and BCP 79.
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the
-      use of such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR
-      repository at http://www.ietf.org/ipr.  The IETF invites any
-      interested party to bring to its attention any copyrights,
-      patents or patent applications, or other proprietary rights
-      that may cover technology that may be required to implement
-      this standard.  Please address the information to the IETF at
-      ietf-ipr@ietf.org.
-
-Acknowledgement
-
-      Funding for the RFC Editor function is currently provided by the
-      Internet Society.
-
-Expiration
-
-      This document expires on or about July 9, 2006.
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 19]
diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
deleted file mode 100644
index 0855ba358c..0000000000
--- a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-
-DNS Operations                                                 M. Larson
-Internet-Draft                                                 P. Barber
-Expires: August 14, 2006                                        VeriSign
-                                                       February 10, 2006
-
-
-                  Observed DNS Resolution Misbehavior
-                    draft-ietf-dnsop-bad-dns-res-05
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 14, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo describes DNS iterative resolver behavior that results in a
-   significant query volume sent to the root and top-level domain (TLD)
-   name servers.  We offer implementation advice to iterative resolver
-   developers to alleviate these unnecessary queries.  The
-   recommendations made in this document are a direct byproduct of
-   observation and analysis of abnormal query traffic patterns seen at
-   two of the thirteen root name servers and all thirteen com/net TLD
-   name servers.
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 1]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  A note about terminology in this memo  . . . . . . . . . .  3
-   2.  Observed iterative resolver misbehavior  . . . . . . . . . . .  5
-     2.1.  Aggressive requerying for delegation information . . . . .  5
-       2.1.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  6
-     2.2.  Repeated queries to lame servers . . . . . . . . . . . . .  7
-       2.2.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  7
-     2.3.  Inability to follow multiple levels of indirection . . . .  8
-       2.3.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  9
-     2.4.  Aggressive retransmission when fetching glue . . . . . . .  9
-       2.4.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 10
-     2.5.  Aggressive retransmission behind firewalls . . . . . . . . 10
-       2.5.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 11
-     2.6.  Misconfigured NS records . . . . . . . . . . . . . . . . . 11
-       2.6.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 12
-     2.7.  Name server records with zero TTL  . . . . . . . . . . . . 12
-       2.7.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 13
-     2.8.  Unnecessary dynamic update messages  . . . . . . . . . . . 13
-       2.8.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
-     2.9.  Queries for domain names resembling IPv4 addresses . . . . 14
-       2.9.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
-     2.10. Misdirected recursive queries  . . . . . . . . . . . . . . 15
-       2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
-     2.11. Suboptimal name server selection algorithm . . . . . . . . 15
-       2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
-   3.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
-   4.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 19
-   6.  Internationalization considerations  . . . . . . . . . . . . . 20
-   7.  Informative References . . . . . . . . . . . . . . . . . . . . 20
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
-   Intellectual Property and Copyright Statements . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 2]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-1.  Introduction
-
-   Observation of query traffic received by two root name servers and
-   the thirteen com/net TLD name servers has revealed that a large
-   proportion of the total traffic often consists of "requeries".  A
-   requery is the same question (<QNAME, QTYPE, QCLASS>) asked
-   repeatedly at an unexpectedly high rate.  We have observed requeries
-   from both a single IP address and multiple IP addresses (i.e., the
-   same query received simultaneously from multiple IP addresses).
-
-   By analyzing requery events we have found that the cause of the
-   duplicate traffic is almost always a deficient iterative resolver,
-   stub resolver or application implementation combined with an
-   operational anomaly.  The implementation deficiencies we have
-   identified to date include well-intentioned recovery attempts gone
-   awry, insufficient caching of failures, early abort when multiple
-   levels of indirection must be followed, and aggressive retry by stub
-   resolvers or applications.  Anomalies that we have seen trigger
-   requery events include lame delegations, unusual glue records, and
-   anything that makes all authoritative name servers for a zone
-   unreachable (DoS attacks, crashes, maintenance, routing failures,
-   congestion, etc.).
-
-   In the following sections, we provide a detailed explanation of the
-   observed behavior and recommend changes that will reduce the requery
-   rate.  None of the changes recommended affects the core DNS protocol
-   specification; instead, this document consists of guidelines to
-   implementors of iterative resolvers.
-
-1.1.  A note about terminology in this memo
-
-   To recast an old saying about standards, the nice thing about DNS
-   terms is that there are so many of them to choose from.  Writing or
-   talking about DNS can be difficult and cause confusion resulting from
-   a lack of agreed-upon terms for its various components.  Further
-   complicating matters are implementations that combine multiple roles
-   into one piece of software, which makes naming the result
-   problematic.  An example is the entity that accepts recursive
-   queries, issues iterative queries as necessary to resolve the initial
-   recursive query, caches responses it receives, and which is also able
-   to answer questions about certain zones authoritatively.  This entity
-   is an iterative resolver combined with an authoritative name server
-   and is often called a "recursive name server" or a "caching name
-   server".
-
-   This memo is concerned principally with the behavior of iterative
-   resolvers, which are typically found as part of a recursive name
-   server.  This memo uses the more precise term "iterative resolver",
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 3]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   because the focus is usually on that component.  In instances where
-   the name server role of this entity requires mentioning, this memo
-   uses the term "recursive name server".  As an example of the
-   difference, the name server component of a recursive name server
-   receives DNS queries and the iterative resolver component sends
-   queries.
-
-   The advent of IPv6 requires mentioning AAAA records as well as A
-   records when discussing glue.  To avoid continuous repetition and
-   qualification, this memo uses the general term "address record" to
-   encompass both A and AAAA records when a particular situation is
-   relevant to both types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 4]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-2.  Observed iterative resolver misbehavior
-
-2.1.  Aggressive requerying for delegation information
-
-   There can be times when every name server in a zone's NS RRset is
-   unreachable (e.g., during a network outage), unavailable (e.g., the
-   name server process is not running on the server host) or
-   misconfigured (e.g., the name server is not authoritative for the
-   given zone, also known as "lame").  Consider an iterative resolver
-   that attempts to resolve a query for a domain name in such a zone and
-   discovers that none of the zone's name servers can provide an answer.
-   We have observed a recursive name server implementation whose
-   iterative resolver then verifies the zone's NS RRset in its cache by
-   querying for the zone's delegation information: it sends a query for
-   the zone's NS RRset to one of the parent zone's name servers.  (Note
-   that queries with QTYPE=NS are not required by the standard
-   resolution algorithm described in section 4.3.2 of RFC 1034 [2].
-   These NS queries represent this implementation's addition to that
-   algorithm.)
-
-   For example, suppose that "example.com" has the following NS RRset:
-
-     example.com.   IN   NS   ns1.example.com.
-     example.com.   IN   NS   ns2.example.com.
-
-   Upon receipt of a query for "www.example.com" and assuming that
-   neither "ns1.example.com" nor "ns2.example.com" can provide an
-   answer, this iterative resolver implementation immediately queries a
-   "com" zone name server for the "example.com" NS RRset to verify it
-   has the proper delegation information.  This implementation performs
-   this query to a zone's parent zone for each recursive query it
-   receives that fails because of a completely unresponsive set of name
-   servers for the target zone.  Consider the effect when a popular zone
-   experiences a catastrophic failure of all its name servers: now every
-   recursive query for domain names in that zone sent to this recursive
-   name server implementation results in a query to the failed zone's
-   parent name servers.  On one occasion when several dozen popular
-   zones became unreachable, the query load on the com/net name servers
-   increased by 50%.
-
-   We believe this verification query is not reasonable.  Consider the
-   circumstances: When an iterative resolver is resolving a query for a
-   domain name in a zone it has not previously searched, it uses the
-   list of name servers in the referral from the target zone's parent.
-   If on its first attempt to search the target zone, none of the name
-   servers in the referral is reachable, a verification query to the
-   parent would be pointless: this query to the parent would come so
-   quickly on the heels of the referral that it would be almost certain
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 5]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   to contain the same list of name servers.  The chance of discovering
-   any new information is slim.
-
-   The other possibility is that the iterative resolver successfully
-   contacts one of the target zone's name servers and then caches the NS
-   RRset from the authority section of a response, the proper behavior
-   according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
-   the target zone is more trustworthy than delegation information from
-   the parent zone.  If, while processing a subsequent recursive query,
-   the iterative resolver discovers that none of the name servers
-   specified in the cached NS RRset is available or authoritative,
-   querying the parent would be wrong.  An NS RRset from the parent zone
-   would now be less trustworthy than data already in the cache.
-
-   For this query of the parent zone to be useful, the target zone's
-   entire set of name servers would have to change AND the former set of
-   name servers would have to be deconfigured or decommissioned AND the
-   delegation information in the parent zone would have to be updated
-   with the new set of name servers, all within the TTL of the target
-   zone's NS RRset.  We believe this scenario is uncommon:
-   administrative best practices dictate that changes to a zone's set of
-   name servers happen gradually when at all possible, with servers
-   removed from the NS RRset left authoritative for the zone as long as
-   possible.  The scenarios that we can envision that would benefit from
-   the parent requery behavior do not outweigh its damaging effects.
-
-   This section should not be understood to claim that all queries to a
-   zone's parent are bad.  In some cases, such queries are not only
-   reasonable but required.  Consider the situation when required
-   information, such as the address of a name server (i.e., the address
-   record corresponding to the RDATA of an NS record), has timed out of
-   an iterative resolver's cache before the corresponding NS record.  If
-   the name of the name server is below the apex of the zone, then the
-   name server's address record is only available as glue in the parent
-   zone.  For example, consider this NS record:
-
-     example.com.        IN   NS   ns.example.com.
-
-   If a cache has this NS record but not the address record for
-   "ns.example.com", it is unable to contact the "example.com" zone
-   directly and must query the "com" zone to obtain the address record.
-   Note, however, that such a query would not have QTYPE=NS according to
-   the standard resolution algorithm.
-
-2.1.1.  Recommendation
-
-   An iterative resolver MUST NOT send a query for the NS RRset of a
-   non-responsive zone to any of the name servers for that zone's parent
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 6]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   zone.  For the purposes of this injunction, a non-responsive zone is
-   defined as a zone for which every name server listed in the zone's NS
-   RRset:
-
-   1.  is not authoritative for the zone (i.e., lame), or,
-
-   2.  returns a server failure response (RCODE=2), or,
-
-   3.  is dead or unreachable according to section 7.2 of RFC 2308 [4].
-
-2.2.  Repeated queries to lame servers
-
-   Section 2.1 describes a catastrophic failure: when every name server
-   for a zone is unable to provide an answer for one reason or another.
-   A more common occurrence is when a subset of a zone's name servers
-   are unavailable or misconfigured.  Different failure modes have
-   different expected durations.  Some symptoms indicate problems that
-   are potentially transient; for example, various types of ICMP
-   unreachable messages because a name server process is not running or
-   a host or network is unreachable, or a complete lack of a response to
-   a query.  Such responses could be the result of a host rebooting or
-   temporary outages; these events don't necessarily require any human
-   intervention and can be reasonably expected to be temporary.
-
-   Other symptoms clearly indicate a condition requiring human
-   intervention, such as lame server: if a name server is misconfigured
-   and not authoritative for a zone delegated to it, it is reasonable to
-   assume that this condition has potential to last longer than
-   unreachability or unresponsiveness.  Consequently, repeated queries
-   to known lame servers are not useful.  In this case of a condition
-   with potential to persist for a long time, a better practice would be
-   to maintain a list of known lame servers and avoid querying them
-   repeatedly in a short interval.
-
-   It should also be noted, however, that some authoritative name server
-   implementations appear to be lame only for queries of certain types
-   as described in RFC 4074 [5].  In this case, it makes sense to retry
-   the "lame" servers for other types of queries, particularly when all
-   known authoritative name servers appear to be "lame".
-
-2.2.1.  Recommendation
-
-   Iterative resolvers SHOULD cache name servers that they discover are
-   not authoritative for zones delegated to them (i.e. lame servers).
-   If this caching is performed, lame servers MUST be cached against the
-   specific query tuple <zone name, class, server IP address>.  Zone
-   name can be derived from the owner name of the NS record that was
-   referenced to query the name server that was discovered to be lame.
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 7]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   Implementations that perform lame server caching MUST refrain from
-   sending queries to known lame servers based on a time interval from
-   when the server is discovered to be lame.  A minimum interval of
-   thirty minutes is RECOMMENDED.
-
-   An exception to this recommendation occurs if all name servers for a
-   zone are marked lame.  In that case, the iterative resolver SHOULD
-   temporarily ignore the servers' lameness status and query one or more
-   servers.  This behavior is a workaround for the type-specific
-   lameness issue described in the previous section.
-
-   Implementors should take care not to make lame server avoidance logic
-   overly broad: note that a name server could be lame for a parent zone
-   but not a child zone, e.g., lame for "example.com" but properly
-   authoritative for "sub.example.com".  Therefore a name server should
-   not be automatically considered lame for subzones.  In the case
-   above, even if a name server is known to be lame for "example.com",
-   it should be queried for QNAMEs at or below "sub.example.com" if an
-   NS record indicates it should be authoritative for that zone.
-
-2.3.  Inability to follow multiple levels of indirection
-
-   Some iterative resolver implementations are unable to follow
-   sufficient levels of indirection.  For example, consider the
-   following delegations:
-
-     foo.example.        IN   NS   ns1.example.com.
-     foo.example.        IN   NS   ns2.example.com.
-
-     example.com.        IN   NS   ns1.test.example.net.
-     example.com.        IN   NS   ns2.test.example.net.
-
-     test.example.net.   IN   NS   ns1.test.example.net.
-     test.example.net.   IN   NS   ns2.test.example.net.
-
-   An iterative resolver resolving the name "www.foo.example" must
-   follow two levels of indirection, first obtaining address records for
-   "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
-   address records for "ns1.example.com" or "ns2.example.com" in order
-   to query those name servers for the address records of
-   "www.foo.example".  While this situation may appear contrived, we
-   have seen multiple similar occurrences and expect more as new generic
-   top-level domains (gTLDs) become active.  We anticipate many zones in
-   new gTLDs will use name servers in existing gTLDs, increasing the
-   number of delegations using out-of-zone name servers.
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 8]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-2.3.1.  Recommendation
-
-   Clearly constructing a delegation that relies on multiple levels of
-   indirection is not a good administrative practice.  However, the
-   practice is widespread enough to require that iterative resolvers be
-   able to cope with it.  Iterative resolvers SHOULD be able to handle
-   arbitrary levels of indirection resulting from out-of-zone name
-   servers.  Iterative resolvers SHOULD implement a level-of-effort
-   counter to avoid loops or otherwise performing too much work in
-   resolving pathological cases.
-
-   A best practice that avoids this entire issue of indirection is to
-   name one or more of a zone's name servers in the zone itself.  For
-   example, if the zone is named "example.com", consider naming some of
-   the name servers "ns{1,2,...}.example.com" (or similar).
-
-2.4.  Aggressive retransmission when fetching glue
-
-   When an authoritative name server responds with a referral, it
-   includes NS records in the authority section of the response.
-   According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
-   server should also "put whatever addresses are available into the
-   additional section, using glue RRs if the addresses are not available
-   from authoritative data or the cache."  Some name server
-   implementations take this address inclusion a step further with a
-   feature called "glue fetching".  A name server that implements glue
-   fetching attempts to include address records for every NS record in
-   the authority section.  If necessary, the name server issues multiple
-   queries of its own to obtain any missing address records.
-
-   Problems with glue fetching can arise in the context of
-   "authoritative-only" name servers, which only serve authoritative
-   data and ignore requests for recursion.  Such an entity will not
-   normally generate any queries of its own.  Instead it answers non-
-   recursive queries from iterative resolvers looking for information in
-   zones it serves.  With glue fetching enabled, however, an
-   authoritative server invokes an iterative resolver to look up an
-   unknown address record to complete the additional section of a
-   response.
-
-   We have observed situations where the iterative resolver of a glue-
-   fetching name server can send queries that reach other name servers,
-   but is apparently prevented from receiving the responses.  For
-   example, perhaps the name server is authoritative-only and therefore
-   its administrators expect it to receive only queries and not
-   responses.  Perhaps unaware of glue fetching and presuming that the
-   name server's iterative resolver will generate no queries, its
-   administrators place the name server behind a network device that
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 9]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   prevents it from receiving responses.  If this is the case, all glue-
-   fetching queries will go answered.
-
-   We have observed name server implementations whose iterative
-   resolvers retry excessively when glue-fetching queries are
-   unanswered.  A single com/net name server has received hundreds of
-   queries per second from a single such source.  Judging from the
-   specific queries received and based on additional analysis, we
-   believe these queries result from overly aggressive glue fetching.
-
-2.4.1.  Recommendation
-
-   Implementers whose name servers support glue fetching SHOULD take
-   care to avoid sending queries at excessive rates.  Implementations
-   SHOULD support throttling logic to detect when queries are sent but
-   no responses are received.
-
-2.5.  Aggressive retransmission behind firewalls
-
-   A common occurrence and one of the largest sources of repeated
-   queries at the com/net and root name servers appears to result from
-   resolvers behind misconfigured firewalls.  In this situation, an
-   iterative resolver is apparently allowed to send queries through a
-   firewall to other name servers, but not receive the responses.  The
-   result is more queries than necessary because of retransmission, all
-   of which are useless because the responses are never received.  Just
-   as with the glue-fetching scenario described in Section 2.4, the
-   queries are sometimes sent at excessive rates.  To make matters
-   worse, sometimes the responses, sent in reply to legitimate queries,
-   trigger an alarm on the originator's intrusion detection system.  We
-   are frequently contacted by administrators responding to such alarms
-   who believe our name servers are attacking their systems.
-
-   Not only do some resolvers in this situation retransmit queries at an
-   excessive rate, but they continue to do so for days or even weeks.
-   This scenario could result from an organization with multiple
-   recursive name servers, only a subset of whose iterative resolvers'
-   traffic is improperly filtered in this manner.  Stub resolvers in the
-   organization could be configured to query multiple recursive name
-   servers.  Consider the case where a stub resolver queries a filtered
-   recursive name server first.  The iterative resolver of this
-   recursive name server sends one or more queries whose replies are
-   filtered, so it can't respond to the stub resolver, which times out.
-   Then the stub resolver retransmits to a recursive name server that is
-   able to provide an answer.  Since resolution ultimately succeeds the
-   underlying problem might not be recognized or corrected.  A popular
-   stub resolver implementation has a very aggressive retransmission
-   schedule, including simultaneous queries to multiple recursive name
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 10]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   servers, which could explain how such a situation could persist
-   without being detected.
-
-2.5.1.  Recommendation
-
-   The most obvious recommendation is that administrators SHOULD take
-   care not to place iterative resolvers behind a firewall that allows
-   queries to pass through but not the resulting replies.
-
-   Iterative resolvers SHOULD take care to avoid sending queries at
-   excessive rates.  Implementations SHOULD support throttling logic to
-   detect when queries are sent but no responses are received.
-
-2.6.  Misconfigured NS records
-
-   Sometimes a zone administrator forgets to add the trailing dot on the
-   domain names in the RDATA of a zone's NS records.  Consider this
-   fragment of the zone file for "example.com":
-
-     $ORIGIN example.com.
-     example.com.      3600   IN   NS   ns1.example.com  ; Note missing
-     example.com.      3600   IN   NS   ns2.example.com  ; trailing dots
-
-   The zone's authoritative servers will parse the NS RDATA as
-   "ns1.example.com.example.com" and "ns2.example.com.example.com" and
-   return NS records with this incorrect RDATA in responses, including
-   typically the authority section of every response containing records
-   from the "example.com" zone.
-
-   Now consider a typical sequence of queries.  An iterative resolver
-   attempting to resolve address records for "www.example.com" with no
-   cached information for this zone will query a "com" authoritative
-   server.  The "com" server responds with a referral to the
-   "example.com" zone, consisting of NS records with valid RDATA and
-   associated glue records.  (This example assumes that the
-   "example.com" zone delegation information is correct in the "com"
-   zone.)  The iterative resolver caches the NS RRset from the "com"
-   server and follows the referral by querying one of the "example.com"
-   authoritative servers.  This server responds with the
-   "www.example.com" address record in the answer section and,
-   typically, the "example.com" NS records in the authority section and,
-   if space in the message remains, glue address records in the
-   additional section.  According to Section 5.4 of RFC 2181 [3], NS
-   records in the authority section of an authoritative answer are more
-   trustworthy than NS records from the authority section of a non-
-   authoritative answer.  Thus the "example.com" NS RRset just received
-   from the "example.com" authoritative server overrides the
-   "example.com" NS RRset received moments ago from the "com"
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 11]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   authoritative server.
-
-   But the "example.com" zone contains the erroneous NS RRset as shown
-   in the example above.  Subsequent queries for names in "example.com"
-   will cause the iterative resolver to attempt to use the incorrect NS
-   records and so it will try to resolve the nonexistent names
-   "ns1.example.com.example.com" and "ns2.example.com.example.com".  In
-   this example, since all of the zone's name servers are named in the
-   zone itself (i.e., "ns1.example.com.example.com" and
-   "ns2.example.com.example.com" both end in "example.com") and all are
-   bogus, the iterative resolver cannot reach any "example.com" name
-   servers.  Therefore attempts to resolve these names result in address
-   record queries to the "com" authoritative servers.  Queries for such
-   obviously bogus glue address records occur frequently at the com/net
-   name servers.
-
-2.6.1.  Recommendation
-
-   An authoritative server can detect this situation.  A trailing dot
-   missing from an NS record's RDATA always results by definition in a
-   name server name that exists somewhere under the apex of the zone the
-   NS record appears in.  Note that further levels of delegation are
-   possible, so a missing trailing dot could inadvertently create a name
-   server name that actually exists in a subzone.
-
-   An authoritative name server SHOULD issue a warning when one of a
-   zone's NS records references a name server below the zone's apex when
-   a corresponding address record does not exist in the zone AND there
-   are no delegated subzones where the address record could exist.
-
-2.7.  Name server records with zero TTL
-
-   Sometimes a popular com/net subdomain's zone is configured with a TTL
-   of zero on the zone's NS records, which prohibits these records from
-   being cached and will result in a higher query volume to the zone's
-   authoritative servers.  The zone's administrator should understand
-   the consequences of such a configuration and provision resources
-   accordingly.  A zero TTL on the zone's NS RRset, however, carries
-   additional consequences beyond the zone itself: if an iterative
-   resolver cannot cache a zone's NS records because of a zero TTL, it
-   will be forced to query that zone's parent's name servers each time
-   it resolves a name in the zone.  The com/net authoritative servers do
-   see an increased query load when a popular com/net subdomain's zone
-   is configured with a TTL of zero on the zone's NS records.
-
-   A zero TTL on an RRset expected to change frequently is extreme but
-   permissible.  A zone's NS RRset is a special case, however, because
-   changes to it must be coordinated with the zone's parent.  In most
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 12]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   zone parent/child relationships we are aware of, there is typically
-   some delay involved in effecting changes.  Further, changes to the
-   set of a zone's authoritative name servers (and therefore to the
-   zone's NS RRset) are typically relatively rare: providing reliable
-   authoritative service requires a reasonably stable set of servers.
-   Therefore an extremely low or zero TTL on a zone's NS RRset rarely
-   makes sense, except in anticipation of an upcoming change.  In this
-   case, when the zone's administrator has planned a change and does not
-   want iterative resolvers throughout the Internet to cache the NS
-   RRset for a long period of time, a low TTL is reasonable.
-
-2.7.1.  Recommendation
-
-   Because of the additional load placed on a zone's parent's
-   authoritative servers resulting from a zero TTL on a zone's NS RRset,
-   under such circumstances authoritative name servers SHOULD issue a
-   warning when loading a zone.
-
-2.8.  Unnecessary dynamic update messages
-
-   The UPDATE message specified in RFC 2136 [6] allows an authorized
-   agent to update a zone's data on an authoritative name server using a
-   DNS message sent over the network.  Consider the case of an agent
-   desiring to add a particular resource record.  Because of zone cuts,
-   the agent does not necessarily know the proper zone to which the
-   record should be added.  The dynamic update process requires that the
-   agent determine the appropriate zone so the UPDATE message can be
-   sent to one of the zone's authoritative servers (typically the
-   primary master as specified in the zone's SOA MNAME field).
-
-   The appropriate zone to update is the closest enclosing zone, which
-   cannot be determined only by inspecting the domain name of the record
-   to be updated, since zone cuts can occur anywhere.  One way to
-   determine the closest enclosing zone entails walking up the name
-   space tree by sending repeated UPDATE messages until success.  For
-   example, consider an agent attempting to add an address record with
-   the name "foo.bar.example.com".  The agent could first attempt to
-   update the "foo.bar.example.com" zone.  If the attempt failed, the
-   update could be directed to the "bar.example.com" zone, then the
-   "example.com" zone, then the "com" zone, and finally the root zone.
-
-   A popular dynamic agent follows this algorithm.  The result is many
-   UPDATE messages received by the root name servers, the com/net
-   authoritative servers, and presumably other TLD authoritative
-   servers.  A valid question is why the algorithm proceeds to send
-   updates all the way to TLD and root name servers.  This behavior is
-   not entirely unreasonable: in enterprise DNS architectures with an
-   "internal root" design, there could conceivably be private, non-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 13]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   public TLD or root zones that would be the appropriate targets for a
-   dynamic update.
-
-   A significant deficiency with this algorithm is that knowledge of a
-   given UPDATE message's failure is not helpful in directing future
-   UPDATE messages to the appropriate servers.  A better algorithm would
-   be to find the closest enclosing zone by walking up the name space
-   with queries for SOA or NS rather than "probing" with UPDATE
-   messages.  Once the appropriate zone is found, an UPDATE message can
-   be sent.  In addition, the results of these queries can be cached to
-   aid in determining closest enclosing zones for future updates.  Once
-   the closest enclosing zone is determined with this method, the update
-   will either succeed or fail and there is no need to send further
-   updates to higher-level zones.  The important point is that walking
-   up the tree with queries yields cacheable information, whereas
-   walking up the tree by sending UPDATE messages does not.
-
-2.8.1.  Recommendation
-
-   Dynamic update agents SHOULD send SOA or NS queries to progressively
-   higher-level names to find the closest enclosing zone for a given
-   name to update.  Only after the appropriate zone is found should the
-   client send an UPDATE message to one of the zone's authoritative
-   servers.  Update clients SHOULD NOT "probe" using UPDATE messages by
-   walking up the tree to progressively higher-level zones.
-
-2.9.  Queries for domain names resembling IPv4 addresses
-
-   The root name servers receive a significant number of A record
-   queries where the QNAME looks like an IPv4 address.  The source of
-   these queries is unknown.  It could be attributed to situations where
-   a user believes an application will accept either a domain name or an
-   IP address in a given configuration option.  The user enters an IP
-   address, but the application assumes any input is a domain name and
-   attempts to resolve it, resulting in an A record lookup.  There could
-   also be applications that produce such queries in a misguided attempt
-   to reverse map IP addresses.
-
-   These queries result in Name Error (RCODE=3) responses.  An iterative
-   resolver can negatively cache such responses, but each response
-   requires a separate cache entry, i.e., a negative cache entry for the
-   domain name "192.0.2.1" does not prevent a subsequent query for the
-   domain name "192.0.2.2".
-
-2.9.1.  Recommendation
-
-   It would be desirable for the root name servers not to have to answer
-   these queries: they unnecessarily consume CPU resources and network
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 14]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   bandwidth.  A possible solution is to delegate these numeric TLDs
-   from the root zone to a separate set of servers to absorb the
-   traffic.  The "black hole servers" used by the AS 112 Project [8],
-   which are currently delegated the in-addr.arpa zones corresponding to
-   RFC 1918 [7] private use address space, would be a possible choice to
-   receive these delegations.  Of course, the proper and usual root zone
-   change procedures would have to be followed to make such a change to
-   the root zone.
-
-2.10.  Misdirected recursive queries
-
-   The root name servers receive a significant number of recursive
-   queries (i.e., queries with the RD bit set in the header).  Since
-   none of the root servers offers recursion, the servers' response in
-   such a situation ignores the request for recursion and the response
-   probably does not contain the data the querier anticipated.  Some of
-   these queries result from users configuring stub resolvers to query a
-   root server.  (This situation is not hypothetical: we have received
-   complaints from users when this configuration does not work as
-   hoped.)  Of course, users should not direct stub resolvers to use
-   name servers that do not offer recursion, but we are not aware of any
-   stub resolver implementation that offers any feedback to the user
-   when so configured, aside from simply "not working".
-
-2.10.1.  Recommendation
-
-   When the IP address of a name server that supposedly offers recursion
-   is configured in a stub resolver using an interactive user interface,
-   the resolver could send a test query to verify that the server indeed
-   supports recursion (i.e., verify that the response has the RA bit set
-   in the header).  The user could be immediately notified if the server
-   is non-recursive.
-
-   The stub resolver could also report an error, either through a user
-   interface or in a log file, if the queried server does not support
-   recursion.  Error reporting SHOULD be throttled to avoid a
-   notification or log message for every response from a non-recursive
-   server.
-
-2.11.  Suboptimal name server selection algorithm
-
-   An entire document could be devoted to the topic of problems with
-   different implementations of the recursive resolution algorithm.  The
-   entire process of recursion is woefully under specified, requiring
-   each implementor to design an algorithm.  Sometimes implementors make
-   poor design choices that could be avoided if a suggested algorithm
-   and best practices were documented, but that is a topic for another
-   document.
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 15]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   Some deficiencies cause significant operational impact and are
-   therefore worth mentioning here.  One of these is name server
-   selection by an iterative resolver.  When an iterative resolver wants
-   to contact one of a zone's authoritative name servers, how does it
-   choose from the NS records listed in the zone's NS RRset?  If the
-   selection mechanism is suboptimal, queries are not spread evenly
-   among a zone's authoritative servers.  The details of the selection
-   mechanism are up to the implementor, but we offer some suggestions.
-
-2.11.1.  Recommendation
-
-   This list is not conclusive, but reflects the changes that would
-   produce the most impact in terms of reducing disproportionate query
-   load among a zone's authoritative servers.  I.e., these changes would
-   help spread the query load evenly.
-
-   o  Do not make assumptions based on NS RRset order: all NS RRs SHOULD
-      be treated equally.  (In the case of the "com" zone, for example,
-      most of the root servers return the NS record for "a.gtld-
-      servers.net" first in the authority section of referrals.
-      Apparently as a result, this server receives disproportionately
-      more traffic than the other 12 authoritative servers for "com".)
-
-   o  Use all NS records in an RRset.  (For example, we are aware of
-      implementations that hard-coded information for a subset of the
-      root servers.)
-
-   o  Maintain state and favor the best-performing of a zone's
-      authoritative servers.  A good definition of performance is
-      response time.  Non-responsive servers can be penalized with an
-      extremely high response time.
-
-   o  Do not lock onto the best-performing of a zone's name servers.  An
-      iterative resolver SHOULD periodically check the performance of
-      all of a zone's name servers to adjust its determination of the
-      best-performing one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 16]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-3.  Acknowledgments
-
-   The authors would like to thank the following people for their
-   comments that improved this document: Andras Salamon, Dave Meyer,
-   Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
-   Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein.  We
-   apologize if we have omitted anyone; any oversight was unintentional.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 17]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-4.  IANA considerations
-
-   There are no new IANA considerations introduced by this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 18]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-5.  Security considerations
-
-   The iterative resolver misbehavior discussed in this document exposes
-   the root and TLD name servers to increased risk of both intentional
-   and unintentional denial of service attacks.
-
-   We believe that implementation of the recommendations offered in this
-   document will reduce the amount of unnecessary traffic seen at root
-   and TLD name servers, thus reducing the opportunity for an attacker
-   to use such queries to his or her advantage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 19]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-6.  Internationalization considerations
-
-   There are no new internationalization considerations introduced by
-   this memo.
-
-7.  Informative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Mockapetris, P., "Domain names - concepts and facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [3]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-        RFC 2181, July 1997.
-
-   [4]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-        RFC 2308, March 1998.
-
-   [5]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
-        Queries for IPv6 Addresses", RFC 4074, May 2005.
-
-   [6]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
-        Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-        April 1997.
-
-   [7]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
-        Lear, "Address Allocation for Private Internets", BCP 5,
-        RFC 1918, February 1996.
-
-   [8]  <http://www.as112.net>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 20]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-Authors' Addresses
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   Email: mlarson@verisign.com
-
-
-   Piet Barber
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   Email: pbarber@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 21]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 22]
-
diff --git a/doc/draft/draft-ietf-dnsop-respsize-06.txt b/doc/draft/draft-ietf-dnsop-respsize-06.txt
deleted file mode 100644
index b041925afb..0000000000
--- a/doc/draft/draft-ietf-dnsop-respsize-06.txt
+++ /dev/null
@@ -1,640 +0,0 @@
-
-
-
-
-
-
-   DNSOP Working Group                                     Paul Vixie, ISC
-   INTERNET-DRAFT                                         Akira Kato, WIDE
-   <draft-ietf-dnsop-respsize-06.txt>                          August 2006
-
-                      DNS Referral Response Size Issues
-
-   Status of this Memo
-      By submitting this Internet-Draft, each author represents that any
-      applicable patent or other IPR claims of which he or she is aware
-      have been or will be disclosed, and any of which he or she becomes
-      aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-      Internet-Drafts are working documents of the Internet Engineering
-      Task Force (IETF), its areas, and its working groups.  Note that
-      other groups may also distribute working documents as Internet-
-      Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of six months
-      and may be updated, replaced, or obsoleted by other documents at any
-      time.  It is inappropriate to use Internet-Drafts as reference
-      material or to cite them other than as "work in progress."
-
-      The list of current Internet-Drafts can be accessed at
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-      The list of Internet-Draft Shadow Directories can be accessed at
-      http://www.ietf.org/shadow.html.
-
-   Copyright Notice
-
-      Copyright (C) The Internet Society (2006).  All Rights Reserved.
-
-
-
-
-                                    Abstract
-
-      With a mandated default minimum maximum message size of 512 octets,
-      the DNS protocol presents some special problems for zones wishing to
-      expose a moderate or high number of authority servers (NS RRs).  This
-      document explains the operational issues caused by, or related to
-      this response size limit, and suggests ways to optimize the use of
-      this limited space.  Guidance is offered to DNS server implementors
-      and to DNS zone operators.
-
-
-
-
-   Expires January 2007                                            [Page 1]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   1 - Introduction and Overview
-
-   1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
-   octets.  Even though this limitation was due to the required minimum IP
-   reassembly limit for IPv4, it became a hard DNS protocol limit and is
-   not implicitly relaxed by changes in transport, for example to IPv6.
-
-   1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
-   larger responses by mutual agreement of the requester and responder.
-   The 512 octet message size limit will remain in practical effect until
-   there is widespread deployment of EDNS0 in DNS resolvers on the
-   Internet.
-
-   1.3. Since DNS responses include a copy of the request, the space
-   available for response data is somewhat less than the full 512 octets.
-   Negative responses are quite small, but for positive and delegation
-   responses, every octet must be carefully and sparingly allocated.  This
-   document specifically addresses delegation response sizes.
-
-   2 - Delegation Details
-
-   2.1. RELEVANT PROTOCOL ELEMENTS
-
-   2.1.1. A delegation response will include the following elements:
-
-      Header Section: fixed length (12 octets)
-      Question Section: original query (name, class, type)
-      Answer Section: empty, or a CNAME/DNAME chain
-      Authority Section: NS RRset (nameserver names)
-      Additional Section: A and AAAA RRsets (nameserver addresses)
-
-   2.1.2. If the total response size exceeds 512 octets, and if the data
-   that does not fit was "required", then the TC bit will be set
-   (indicating truncation).  This will usually cause the requester to retry
-   using TCP, depending on what information was desired and what
-   information was omitted.  For example, truncation in the authority
-   section is of no interest to a stub resolver who only plans to consume
-   the answer section.  If a retry using TCP is needed, the total cost of
-   the transaction is much higher.  See [RFC1123 6.1.3.2] for details on
-   the requirement that UDP be attempted before falling back to TCP.
-
-   2.1.3. RRsets are never sent partially unless TC bit set to indicate
-   truncation.  When TC bit is set, the final apparent RRset in the final
-   non-empty section must be considered "possibly damaged" (see [RFC1035
-   6.2], [RFC2181 9]).
-
-
-
-   Expires January 2007                                            [Page 2]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   2.1.4. With or without truncation, the glue present in the additional
-   data section should be considered "possibly incomplete", and requesters
-   should be prepared to re-query for any damaged or missing RRsets.  Note
-   that truncation of the additional data section might not be signalled
-   via the TC bit since additional data is often optional (see discussion
-   in [RFC4472 B]).
-
-   2.1.5. DNS label compression allows a domain name to be instantiated
-   only once per DNS message, and then referenced with a two-octet
-   "pointer" from other locations in that same DNS message (see [RFC1035
-   4.1.4]).  If all nameserver names in a message share a common parent
-   (for example, all ending in ".ROOT-SERVERS.NET"), then more space will
-   be available for incompressable data (such as nameserver addresses).
-
-   2.1.6. The query name can be as long as 255 octets of network data.  In
-   this worst case scenario, the question section will be 259 octets in
-   size, which would leave only 240 octets for the authority and additional
-   sections (after deducting 12 octets for the fixed length header.)
-
-   2.2. ADVICE TO ZONE OWNERS
-
-   2.2.1. Average and maximum question section sizes can be predicted by
-   the zone owner, since they will know what names actually exist, and can
-   measure which ones are queried for most often.  Note that if the zone
-   contains any wildcards, it is possible for maximum length queries to
-   require positive responses, but that it is reasonable to expect
-   truncation and TCP retry in that case.  For cost and performance
-   reasons, the majority of requests should be satisfied without truncation
-   or TCP retry.
-
-   2.2.2. Some queries to non-existing names can be large, but this is not
-   a problem because negative responses need not contain any answer,
-   authority or additional records.  See [RFC2308 2.1] for more information
-   about the format of negative responses.
-
-   2.2.3. The minimum useful number of name servers is two, for redundancy
-   (see [RFC1034 4.1]).  A zone's name servers should be reachable by all
-   IP transport protocols (e.g., IPv4 and IPv6) in common use.
-
-   2.2.4. The best case is no truncation at all.  This is because many
-   requesters will retry using TCP immediately, or will automatically re-
-   query for RRsets that are possibly truncated, without considering
-   whether the omitted data was actually necessary.
-
-
-
-
-
-   Expires January 2007                                            [Page 3]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   2.3. ADVICE TO SERVER IMPLEMENTORS
-
-   2.3.1. In case of multi-homed name servers, it is advantageous to
-   include an address record from each of several name servers before
-   including several address records for any one name server.  If address
-   records for more than one transport (for example, A and AAAA) are
-   available, then it is advantageous to include records of both types
-   early on, before the message is full.
-
-   2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
-   class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
-   Each A RR will require 16 octets, and each AAAA RR will require 28
-   octets.
-
-   2.3.3. While DNS distinguishes between necessary and optional resource
-   records, this distinction is according to protocol elements necessary to
-   signify facts, and takes no official notice of protocol content
-   necessary to ensure correct operation.  For example, a nameserver name
-   that is in or below the zone cut being described by a delegation is
-   "necessary content," since there is no way to reach that zone unless the
-   parent zone's delegation includes "glue records" describing that name
-   server's addresses.
-
-   2.3.4. It is also necessary to distinguish between "explicit truncation"
-   where a message could not contain enough records to convey its intended
-   meaning, and so the TC bit has been set, and "silent truncation", where
-   the message was not large enough to contain some records which were "not
-   required", and so the TC bit was not set.
-
-   2.3.5. A delegation response should prioritize glue records as follows.
-
-   first
-      All glue RRsets for one name server whose name is in or below the
-      zone being delegated, or which has multiple address RRsets (currently
-      A and AAAA), or preferably both;
-
-   second
-      Alternate between adding all glue RRsets for any name servers whose
-      names are in or below the zone being delegated, and all glue RRsets
-      for any name servers who have multiple address RRsets (currently A
-      and AAAA);
-
-   thence
-      All other glue RRsets, in any order.
-
-
-
-
-   Expires January 2007                                            [Page 4]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   Whenever there are multiple candidates for a position in this priority
-   scheme, one should be chosen on a round-robin or fully random basis.
-
-   The goal of this priority scheme is to offer "necessary" glue first,
-   avoiding silent truncation for this glue if possible.
-
-   2.3.6. If any "necessary content" is silently truncated, then it is
-   advisable that the TC bit be set in order to force a TCP retry, rather
-   than have the zone be unreachable.  Note that a parent server's proper
-   response to a query for in-child glue or below-child glue is a referral
-   rather than an answer, and that this referral MUST be able to contain
-   the in-child or below-child glue, and that in outlying cases, only EDNS
-   or TCP will be large enough to contain that data.
-
-   3 - Analysis
-
-   3.1. An instrumented protocol trace of a best case delegation response
-   follows.  Note that 13 servers are named, and 13 addresses are given.
-   This query was artificially designed to exactly reach the 512 octet
-   limit.
-
-      ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
-      ;; QUERY SECTION:
-      ;;  [23456789.123456789.123456789.\
-           123456789.123456789.123456789.com A IN]        ;; @80
-
-      ;; AUTHORITY SECTION:
-      com.                 86400 NS  E.GTLD-SERVERS.NET.  ;; @112
-      com.                 86400 NS  F.GTLD-SERVERS.NET.  ;; @128
-      com.                 86400 NS  G.GTLD-SERVERS.NET.  ;; @144
-      com.                 86400 NS  H.GTLD-SERVERS.NET.  ;; @160
-      com.                 86400 NS  I.GTLD-SERVERS.NET.  ;; @176
-      com.                 86400 NS  J.GTLD-SERVERS.NET.  ;; @192
-      com.                 86400 NS  K.GTLD-SERVERS.NET.  ;; @208
-      com.                 86400 NS  L.GTLD-SERVERS.NET.  ;; @224
-      com.                 86400 NS  M.GTLD-SERVERS.NET.  ;; @240
-      com.                 86400 NS  A.GTLD-SERVERS.NET.  ;; @256
-      com.                 86400 NS  B.GTLD-SERVERS.NET.  ;; @272
-      com.                 86400 NS  C.GTLD-SERVERS.NET.  ;; @288
-      com.                 86400 NS  D.GTLD-SERVERS.NET.  ;; @304
-
-
-
-
-
-
-
-
-   Expires January 2007                                            [Page 5]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-      ;; ADDITIONAL SECTION:
-      A.GTLD-SERVERS.NET.  86400 A   192.5.6.30           ;; @320
-      B.GTLD-SERVERS.NET.  86400 A   192.33.14.30         ;; @336
-      C.GTLD-SERVERS.NET.  86400 A   192.26.92.30         ;; @352
-      D.GTLD-SERVERS.NET.  86400 A   192.31.80.30         ;; @368
-      E.GTLD-SERVERS.NET.  86400 A   192.12.94.30         ;; @384
-      F.GTLD-SERVERS.NET.  86400 A   192.35.51.30         ;; @400
-      G.GTLD-SERVERS.NET.  86400 A   192.42.93.30         ;; @416
-      H.GTLD-SERVERS.NET.  86400 A   192.54.112.30        ;; @432
-      I.GTLD-SERVERS.NET.  86400 A   192.43.172.30        ;; @448
-      J.GTLD-SERVERS.NET.  86400 A   192.48.79.30         ;; @464
-      K.GTLD-SERVERS.NET.  86400 A   192.52.178.30        ;; @480
-      L.GTLD-SERVERS.NET.  86400 A   192.41.162.30        ;; @496
-      M.GTLD-SERVERS.NET.  86400 A   192.55.83.30         ;; @512
-
-      ;; MSG SIZE  sent: 80  rcvd: 512
-
-   3.2. For longer query names, the number of address records supplied will
-   be lower.  Furthermore, it is only by using a common parent name (which
-   is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
-   fit, due to the use of DNS compression pointers in the last 12
-   occurances of the parent domain name.  The following output from a
-   response simulator demonstrates these properties.
-
-      % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
-      a.dns.br requires 10 bytes
-      b.dns.br requires 4 bytes
-      c.dns.br requires 4 bytes
-      d.dns.br requires 4 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 3 (yellow)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
-      For average size query (64 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 4 (green)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-
-
-
-
-
-
-
-
-
-   Expires January 2007                                            [Page 6]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-      % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
-      ns-ext.isc.org requires 16 bytes
-      ns.psg.com requires 12 bytes
-      ns.ripe.net requires 13 bytes
-      ns.eu.int requires 11 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 3 (yellow)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
-      For average size query (64 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 4 (green)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-   (Note: The response simulator program is shown in Section 5.)
-
-   Here we use the term "green" if all address records could fit, or
-   "yellow" if two or more could fit, or "orange" if only one could fit, or
-   "red" if no address record could fit.  It's clear that without a common
-   parent for nameserver names, much space would be lost.  For these
-   examples we use an average/common name size of 15 octets, befitting our
-   assumption of GTLD-SERVERS.NET as our common parent name.
-
-   We're assuming a medium query name size of 64 since that is the typical
-   size seen in trace data at the time of this writing.  If
-   Internationalized Domain Name (IDN) or any other technology which
-   results in larger query names be deployed significantly in advance of
-   EDNS, then new measurements and new estimates will have to be made.
-
-   4 - Conclusions
-
-   4.1. The current practice of giving all nameserver names a common parent
-   (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
-   responses and allows for more nameservers to be enumerated than would
-   otherwise be possible, since the common parent domain name only appears
-   once in a DNS message and is referred to via "compression pointers"
-   thereafter.
-
-   4.2. If all nameserver names for a zone share a common parent, then it
-   is operationally advisable to make all servers for the zone thus served
-   also be authoritative for the zone of that common parent.  For example,
-   the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
-   for the ROOT-SERVERS.NET.  This is to ensure that the zone's servers
-   always have the zone's nameservers' glue available when delegating, and
-
-
-
-   Expires January 2007                                            [Page 7]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   will be able to respond with answers rather than referrals if a
-   requester who wants that glue comes back asking for it.  In this case
-   the name server will likely be a "stealth server" -- authoritative but
-   unadvertised in the glue zone's NS RRset.  See [RFC1996 2] for more
-   information about stealth servers.
-
-   4.3. Thirteen (13) is the effective maximum number of nameserver names
-   usable traditional (non-extended) DNS, assuming a common parent domain
-   name, and given that implicit referral response truncation is
-   undesirable in the average case.
-
-   4.4. Multi-homing of name servers within a protocol family is
-   inadvisable since the necessary glue RRsets (A or AAAA) are atomically
-   indivisible, and will be larger than a single resource record.  Larger
-   RRsets are more likely to lead to or encounter truncation.
-
-   4.5. Multi-homing of name servers across protocol families is less
-   likely to lead to or encounter truncation, partly because multiprotocol
-   clients are more likely to speak EDNS which can use a larger response
-   size limit, and partly because the resource records (A and AAAA) are in
-   different RRsets and are therefore divisible from each other.
-
-   4.6. Name server names which are at or below the zone they serve are
-   more sensitive to referral response truncation, and glue records for
-   them should be considered "less optional" than other glue records, in
-   the assembly of referral responses.
-
-   4.7. If a zone is served by thirteen (13) name servers having a common
-   parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
-   single address record in some protocol family (e.g., an A RR), then all
-   thirteen name servers or any subset thereof could multi-home in a second
-   protocol family by adding a second address record (e.g., an AAAA RR)
-   without reducing the reachability of the zone thus served.
-
-   5 - Source Code
-
-   #!/usr/bin/perl
-   #
-   # SYNOPSIS
-   #    repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
-   #        if all queries are assumed to have a same zone suffix,
-   #     such as "jp" in JP TLD servers, specify it in -z option
-   #
-   use strict;
-   use Getopt::Std;
-
-
-
-   Expires January 2007                                            [Page 8]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   my ($sz_msg) = (512);
-   my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
-   my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
-   my (%namedb, $name, $nssect, %opts, $optz);
-   my $n_ns = 0;
-
-   getopt('z', %opts);
-   if (defined($opts{'z'})) {
-       server_name_len($opts{'z'}); # just register it
-   }
-
-   foreach $name (@ARGV) {
-       my $len;
-       $n_ns++;
-       $len = server_name_len($name);
-       print "$name requires $len bytes\n";
-       $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
-               +  $sz_rdlen + $len;
-   }
-   print "# of NS: $n_ns\n";
-   arsect(255, $nssect, $n_ns, "maximum");
-   arsect(64, $nssect, $n_ns, "average");
-
-   sub server_name_len {
-       my ($name) = @_;
-       my (@labels, $len, $n, $suffix);
-
-       $name =~ tr/A-Z/a-z/;
-       @labels = split(/\./, $name);
-       $len = length(join('.', @labels)) + 2;
-       for ($n = 0; $#labels >= 0; $n++, shift @labels) {
-           $suffix = join('.', @labels);
-           return length($name) - length($suffix) + $sz_ptr
-               if (defined($namedb{$suffix}));
-           $namedb{$suffix} = 1;
-       }
-       return $len;
-   }
-
-   sub arsect {
-       my ($sz_query, $nssect, $n_ns, $cond) = @_;
-       my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
-       $ansect = $sz_query + 1 + $sz_type + $sz_class;
-       $space = $sz_msg - $sz_header - $ansect - $nssect;
-       $n_a = atmost(int($space / $sz_rr_a), $n_ns);
-
-
-
-   Expires January 2007                                            [Page 9]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-       $n_a_aaaa = atmost(int($space
-                              / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
-       $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
-                              / $sz_rr_aaaa), $n_ns);
-       printf "For %s size query (%d byte):\n", $cond, $sz_query;
-       printf "    only A is considered:        ";
-       printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
-       printf "    A and AAAA are considered:   ";
-       printf "# of A+AAAA is %d (%s)\n",
-              $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
-       printf "    preferred-glue A is assumed: ";
-       printf "# of A is %d, # of AAAA is %d (%s)\n",
-           $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
-   }
-
-   sub judge {
-       my ($n, $n_ns) = @_;
-       return "green" if ($n >= $n_ns);
-       return "yellow" if ($n >= 2);
-       return "orange" if ($n == 1);
-       return "red";
-   }
-
-   sub atmost {
-       my ($a, $b) = @_;
-       return 0 if ($a < 0);
-       return $b if ($a > $b);
-       return $a;
-   }
-
-   6 - Security Considerations
-
-   The recommendations contained in this document have no known security
-   implications.
-
-   7 - IANA Considerations
-
-   This document does not call for changes or additions to any IANA
-   registry.
-
-   8 - Acknowledgement
-
-   The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
-   for their valuable comments and suggestions.
-
-
-
-
-   Expires January 2007                                           [Page 10]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   This work was supported by the US National Science Foundation (research
-   grant SCI-0427144) and DNS-OARC.
-
-   9 - References
-
-   [RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
-      RFC1034, November 1987.
-
-   [RFC1035] Mockapetris, P.V., "Domain names - Implementation and
-      Specification", RFC1035, November 1987.
-
-   [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
-      Application and Support", RFC1123, October 1989.
-
-   [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
-      Changes (DNS NOTIFY)", RFC1996, August 1996.
-
-   [RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
-      RFC2181, July 1997.
-
-   [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-      RFC2308, March 1998.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
-      August 1999.
-
-   [RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
-      and Issues with IPV6 DNS", April 2006.
-
-   10 - Authors' Addresses
-
-   Paul Vixie
-      Internet Systems Consortium, Inc.
-      950 Charter Street
-      Redwood City, CA 94063
-      +1 650 423 1301
-      vixie@isc.org
-
-   Akira Kato
-      University of Tokyo, Information Technology Center
-      2-11-16 Yayoi Bunkyo
-      Tokyo 113-8658, JAPAN
-      +81 3 5841 2750
-      kato@wide.ad.jp
-
-
-
-
-   Expires January 2007                                           [Page 11]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors retain
-   all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
-   IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-   Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in this
-   document or the extent to which any license under such rights might or
-   might not be available; nor does it represent that it has made any
-   independent effort to identify any such rights.  Information on the
-   procedures with respect to rights in RFC documents can be found in BCP
-   78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an attempt
-   made to obtain a general license or permission for the use of such
-   proprietary rights by implementers or users of this specification can be
-   obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary rights
-   that may cover technology that may be required to implement this
-   standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-   Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-   Expires January 2007                                           [Page 12]
-
-
diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt
deleted file mode 100644
index c6ec7e42a5..0000000000
--- a/doc/draft/draft-ietf-dnsop-serverid-06.txt
+++ /dev/null
@@ -1,618 +0,0 @@
-
-
-
-
-Network Working Group                                           S. Woolf
-Internet-Draft                         Internet Systems Consortium, Inc.
-Expires: September 6, 2006                                     D. Conrad
-                                                           Nominum, Inc.
-                                                           March 5, 2006
-
-
-    Requirements for a Mechanism Identifying a Name Server Instance
-                      draft-ietf-dnsop-serverid-06
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 6, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.  A standardized mechanism to
-   determine the identity of a name server responding to a particular
-   query would be useful, particularly as a diagnostic aid for
-   administrators.  Existing ad hoc mechanisms for addressing this need
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 1]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-   have some shortcomings, not the least of which is the lack of prior
-   analysis of exactly how such a mechanism should be designed and
-   deployed.  This document describes the existing convention used in
-   some widely deployed implementations of the DNS protocol, including
-   advantages and disadvantages, and discusses some attributes of an
-   improved mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 2]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-1.  Introduction and Rationale
-
-   Identifying which name server is responding to queries is often
-   useful, particularly in attempting to diagnose name server
-   difficulties.  This is most obviously useful for authoritative
-   nameservers in the attempt to diagnose the source or prevalence of
-   inaccurate data, but can also conceivably be useful for caching
-   resolvers in similar and other situations.  Furthermore, the ability
-   to identify which server is responding to a query has become more
-   useful as DNS has become more critical to more Internet users, and as
-   network and server deployment topologies have become more complex.
-
-   The traditional means for determining which of several possible
-   servers is answering a query has traditionally been based on the use
-   of the server's IP address as a unique identifier.  However, the
-   modern Internet has seen the deployment of various load balancing,
-   fault-tolerance, or attack-resistance schemes such as shared use of
-   unicast IP addresses as documented in [RFC3258].  An unfortunate side
-   effect of these schemes has been to make the use of IP addresses as
-   identifiers somewhat problematic.  Specifically, a dedicated DNS
-   query may not go to the same server as answered a previous query,
-   even though sent to the same IP address.  Non-DNS methods such as
-   ICMP ping, TCP connections, or non-DNS UDP packets (such as those
-   generated by tools like "traceroute"), etc., may well be even less
-   certain to reach the same server as the one which receives the DNS
-   queries.
-
-   There is a well-known and frequently-used technique for determining
-   an identity for a nameserver more specific than the possibly-non-
-   unique "server that answered the query I sent to IP address XXX".
-   The widespread use of the existing convention suggests a need for a
-   documented, interoperable means of querying the identity of a
-   nameserver that may be part of an anycast or load-balancing cluster.
-   At the same time, however, it also has some drawbacks that argue
-   against standardizing it as it's been practiced so far.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 3]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-2.  Existing Conventions
-
-   For some time, the commonly deployed Berkeley Internet Name Domain
-   implementation of the DNS protocol suite from the Internet Systems
-   Consortium [BIND] has supported a way of identifying a particular
-   server via the use of a standards-compliant, if somewhat unusual, DNS
-   query.  Specifically, a query to a recent BIND server for a TXT
-   resource record in class 3 (CHAOS) for the domain name
-   "HOSTNAME.BIND." will return a string that can be configured by the
-   name server administrator to provide a unique identifier for the
-   responding server.  (The value defaults to the result of a
-   gethostname() call).  This mechanism, which is an extension of the
-   BIND convention of using CHAOS class TXT RR queries to sub-domains of
-   the "BIND." domain for version information, has been copied by
-   several name server vendors.
-
-   A refinement to the BIND-based mechanism, which dropped the
-   implementation-specific string, replaces ".BIND" with ".SERVER".
-   Thus the query string to learn the unique name of a server may be
-   queried as "ID.SERVER".
-
-   (For reference, the other well-known name used by recent versions of
-   BIND within the CHAOS class "BIND." domain is "VERSION.BIND."  A
-   query for a CHAOS TXT RR for this name will return an
-   administratively defined string which defaults to the version of the
-   server responding.  This is, however, not generally implemented by
-   other vendors.)
-
-2.1.  Advantages
-
-   There are several valuable attributes to this mechanism, which
-   account for its usefulness.
-
-   1.  The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is
-       within the DNS protocol itself.  An identification mechanism that
-       relies on the DNS protocol is more likely to be successful
-       (although not guaranteed) in going to the same system as a
-       "normal" DNS query.
-
-   2.  Since the identity information is requested and returned within
-       the DNS protocol, it doesn't require allowing any other query
-       mechanism to the server, such as holes in firewalls for
-       otherwise-unallowed ICMP Echo requests.  Thus it is likely to
-       reach the same server over a path subject to the same routing,
-       resource, and security policy as the query, without any special
-       exceptions to site security policy.
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 4]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-   3.  It is simple to configure.  An administrator can easily turn on
-       this feature and control the results of the relevant query.
-
-   4.  It allows the administrator complete control of what information
-       is given out in the response, minimizing passive leakage of
-       implementation or configuration details.  Such details are often
-       considered sensitive by infrastructure operators.
-
-   5.  Hypothetically, since it's an ordinary DNS record and the
-       relevant DNSSEC RRs are class independent, the id.server response
-       RR could be signed, which has the advantages described in
-       [RFC4033].
-
-2.2.  Disadvantages
-
-   At the same time, there are some serious drawbacks to the CHAOS/TXT
-   query mechanism that argue against standardizing it as it currently
-   operates.
-
-   1.  It requires an additional query to correlate between the answer
-       to a DNS query under normal conditions and the supposed identity
-       of the server receiving the query.  There are a number of
-       situations in which this simply isn't reliable.
-
-   2.  It reserves an entire class in the DNS (CHAOS) for what amounts
-       to one zone.  While CHAOS class is defined in [RFC1034] and
-       [RFC1035], it's not clear that supporting it solely for this
-       purpose is a good use of the namespace or of implementation
-       effort.
-
-   3.  The initial and still common form, using .BIND, is implementation
-       specific.  BIND is one DNS implementation.  At the time of this
-       writing, it is probably the most prevalent for authoritative
-       servers.  This does not justify standardizing on its ad hoc
-       solution to a problem shared across many operators and
-       implementors.  Meanwhile, the proposed refinement changes the
-       string but preserves the ad hoc CHAOS/TXT mechanism.
-
-   4.  There is no convention or shared understanding of what
-       information an answer to such a query for a server identity could
-       or should include, including a possible encoding or
-       authentication mechanism.
-
-   The first of the listed disadvantages may be technically the most
-   serious.  It argues for an attempt to design a good answer to the
-   problem that "I need to know what nameserver is answering my
-   queries", not simply a convenient one.
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 5]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-2.3.  Characteristics of an Implementation Neutral Convention
-
-   The discussion above of advantages and disadvantages to the
-   HOSTNAME.BIND mechanism suggest some requirements for a better
-   solution to the server identification problem.  These are summarized
-   here as guidelines for any effort to provide appropriate protocol
-   extensions:
-
-   1.  The mechanism adopted must be in-band for the DNS protocol.  That
-       is, it needs to allow the query for the server's identifying
-       information to be part of a normal, operational query.  It should
-       also permit a separate, dedicated query for the server's
-       identifying information.  But it should preserve the ability of
-       the CHAOS/TXT query-based mechanism to work through firewalls and
-       in other situations where only DNS can be relied upon to reach
-       the server of interest.
-
-   2.  The new mechanism should not require dedicated namespaces or
-       other reserved values outside of the existing protocol mechanisms
-       for these, i.e. the OPT pseudo-RR.  In particular, it should not
-       propagate the existing drawback of requiring support for a CLASS
-       and top level domain in the authoritative server (or the querying
-       tool) to be useful.
-
-   3.  Support for the identification functionality should be easy to
-       implement and easy to enable.  It must be easy to disable and
-       should lend itself to access controls on who can query for it.
-
-   4.  It should be possible to return a unique identifier for a server
-       without requiring the exposure of information that may be non-
-       public and considered sensitive by the operator, such as a
-       hostname or unicast IP address maintained for administrative
-       purposes.
-
-   5.  It should be possible to authenticate the received data by some
-       mechanism analogous to those provided by DNSSEC.  In this
-       context, the need could be met by including encryption options in
-       the specification of a new mechanism.
-
-   6.  The identification mechanism should not be implementation-
-       specific.
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 6]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-3.  IANA Considerations
-
-   This document proposes no specific IANA action.  Protocol extensions,
-   if any, to meet the requirements described are out of scope for this
-   document.  A proposed extension, specified and adopted by normal IETF
-   process, is described in [NSID], including relevant IANA action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 7]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-4.  Security Considerations
-
-   Providing identifying information as to which server is responding to
-   a particular query from a particular location in the Internet can be
-   seen as information leakage and thus a security risk.  This motivates
-   the suggestion above that a new mechanism for server identification
-   allow the administrator to disable the functionality altogether or
-   partially restrict availability of the data.  It also suggests that
-   the serverid data should not be readily correlated with a hostname or
-   unicast IP address that may be considered private to the nameserver
-   operator's management infrastructure.
-
-   Propagation of protocol or service meta-data can sometimes expose the
-   application to denial of service or other attack.  As DNS is a
-   critically important infrastructure service for the production
-   Internet, extra care needs to be taken against this risk for
-   designers, implementors, and operators of a new mechanism for server
-   identification.
-
-   Both authentication and confidentiality of serverid data are
-   potentially of interest to administrators-- that is, operators may
-   wish to make serverid data available and reliable to themselves and
-   their chosen associates only.  This would imply both an ability to
-   authenticate it to themselves and keep it private from arbitrary
-   other parties.  This led to Characteristics 4 and 5 of an improved
-   solution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 8]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-5.  Acknowledgements
-
-   The technique for host identification documented here was initially
-   implemented by Paul Vixie of the Internet Software Consortium in the
-   Berkeley Internet Name Daemon package.  Comments and questions on
-   earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
-   Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
-   ICANN Root Server System Advisory Committee.  The newest version
-   takes a significantly different direction from previous versions,
-   owing to discussion among contributors to the DNSOP working group and
-   others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
-   Weiler, and Rob Austein.
-
-6.  References
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-        RFC 1034, STD 0013, November 1987.
-
-   [2]  Mockapetris, P., "Domain Names - Implementation and
-        Specification", RFC 1035, STD 0013, November 1987.
-
-   [3]  Hardie, T., "Distributing Authoritative Name Servers via Shared
-        Unicast Addresses", RFC 3258, April 2002.
-
-   [4]  ISC, "BIND 9 Configuration Reference".
-
-   [5]  Austein, S., "DNS Name Server Identifier Option (NSID)",
-        Internet Drafts http://www.ietf.org/internet-drafts/
-        draft-ietf-dnsext-nsid-01.txt, January 2006.
-
-   [6]  Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 9]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-Authors' Addresses
-
-   Suzanne Woolf
-   Internet Systems Consortium, Inc.
-   950 Charter Street
-   Redwood City, CA  94063
-   US
-
-   Phone: +1 650 423-1333
-   Email: woolf@isc.org
-   URI:   http://www.isc.org/
-
-
-   David Conrad
-   Nominum, Inc.
-   2385 Bay Road
-   Redwood City, CA  94063
-   US
-
-   Phone: +1 1 650 381 6003
-   Email: david.conrad@nominum.com
-   URI:   http://www.nominum.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006              [Page 10]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006              [Page 11]
-
-
diff --git a/lib/dns/api b/lib/dns/api
index 520c3c3a52..1b3fb8d5a2 100644
--- a/lib/dns/api
+++ b/lib/dns/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 24
-LIBREVISION = 2
-LIBAGE = 2
+LIBINTERFACE = 25
+LIBREVISION = 0
+LIBAGE = 0
diff --git a/lib/dns/dispatch.c b/lib/dns/dispatch.c
index 869fd7bba0..207432d5f3 100644
--- a/lib/dns/dispatch.c
+++ b/lib/dns/dispatch.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dispatch.c,v 1.101.2.6.2.21 2007/08/28 07:19:13 tbox Exp $ */
+/* $Id: dispatch.c,v 1.101.2.6.2.21.4.1 2008/05/22 21:11:15 each Exp $ */
 
 #include <config.h>
 
@@ -27,6 +27,7 @@
 #include <isc/mem.h>
 #include <isc/mutex.h>
 #include <isc/print.h>
+#include <isc/random.h>
 #include <isc/string.h>
 #include <isc/task.h>
 #include <isc/time.h>
@@ -43,25 +44,22 @@
 
 typedef ISC_LIST(dns_dispentry_t)	dns_displist_t;
 
-typedef struct dns_nsid {
-	isc_uint16_t	nsid_state;
-	isc_uint16_t	*nsid_vtable;
-	isc_uint16_t	*nsid_pool;
-	isc_uint16_t	nsid_a1, nsid_a2, nsid_a3;
-	isc_uint16_t	nsid_c1, nsid_c2, nsid_c3;
-	isc_uint16_t	nsid_state2;
-	isc_boolean_t	nsid_usepool;
-} dns_nsid_t;
-
 typedef struct dns_qid {
 	unsigned int	magic;
 	unsigned int	qid_nbuckets;	/* hash table size */
 	unsigned int	qid_increment;	/* id increment on collision */
 	isc_mutex_t	lock;
-	dns_nsid_t	nsid;
 	dns_displist_t	*qid_table;	/* the table itself */
 } dns_qid_t;
 
+/* ARC4 Random generator state */
+typedef struct arc4ctx {
+	isc_uint8_t	i;
+	isc_uint8_t	j;
+	isc_uint8_t	s[256];
+	int		count;
+} arc4ctx_t;
+
 struct dns_dispatchmgr {
 	/* Unlocked. */
 	unsigned int			magic;
@@ -74,6 +72,10 @@ struct dns_dispatchmgr {
 	unsigned int			state;
 	ISC_LIST(dns_dispatch_t)	list;
 
+	/* Locked by arc4_lock. */
+	isc_mutex_t			arc4_lock;
+	arc4ctx_t			arc4ctx;    /*%< ARC4 context for QID */
+
 	/* locked by buffer lock */
 	dns_qid_t			*qid;
 	isc_mutex_t			buffer_lock;
@@ -100,6 +102,7 @@ struct dns_dispentry {
 	unsigned int			magic;
 	dns_dispatch_t		       *disp;
 	dns_messageid_t			id;
+	in_port_t			port;
 	unsigned int			bucket;
 	isc_sockaddr_t			host;
 	isc_task_t		       *task;
@@ -119,6 +122,7 @@ struct dns_dispatch {
 	isc_task_t	       *task;		/* internal task */
 	isc_socket_t	       *socket;		/* isc socket attached to */
 	isc_sockaddr_t		local;		/* local address */
+	in_port_t		localport;	/* local UDP port */
 	unsigned int		maxrequests;	/* max requests */
 	isc_event_t	       *ctlevent;
 
@@ -161,14 +165,14 @@ struct dns_dispatch {
  * Statics.
  */
 static dns_dispentry_t *bucket_search(dns_qid_t *, isc_sockaddr_t *,
-				      dns_messageid_t, unsigned int);
+				      dns_messageid_t, in_port_t, unsigned int);
 static isc_boolean_t destroy_disp_ok(dns_dispatch_t *);
 static void destroy_disp(isc_task_t *task, isc_event_t *event);
 static void udp_recv(isc_task_t *, isc_event_t *);
 static void tcp_recv(isc_task_t *, isc_event_t *);
 static void startrecv(dns_dispatch_t *);
-static dns_messageid_t dns_randomid(dns_nsid_t *);
-static isc_uint32_t dns_hash(dns_qid_t *, isc_sockaddr_t *, dns_messageid_t);
+static isc_uint32_t dns_hash(dns_qid_t *, isc_sockaddr_t *, dns_messageid_t,
+			     in_port_t);
 static void free_buffer(dns_dispatch_t *disp, void *buf, unsigned int len);
 static void *allocate_udp_buffer(dns_dispatch_t *disp);
 static inline void free_event(dns_dispatch_t *disp, dns_dispatchevent_t *ev);
@@ -188,12 +192,8 @@ static isc_result_t dispatch_createudp(dns_dispatchmgr_t *mgr,
 static isc_boolean_t destroy_mgr_ok(dns_dispatchmgr_t *mgr);
 static void destroy_mgr(dns_dispatchmgr_t **mgrp);
 static isc_result_t qid_allocate(dns_dispatchmgr_t *mgr, unsigned int buckets,
-				 unsigned int increment, isc_boolean_t usepool,
-				 dns_qid_t **qidp);
+				 unsigned int increment, dns_qid_t **qidp);
 static void qid_destroy(isc_mem_t *mctx, dns_qid_t **qidp);
-static isc_uint16_t nsid_next(dns_nsid_t *nsid);
-static isc_result_t nsid_init(isc_mem_t *mctx, dns_nsid_t *nsid, isc_boolean_t usepool);
-static void nsid_destroy(isc_mem_t *mctx, dns_nsid_t *nsid);
 
 #define LVL(x) ISC_LOG_DEBUG(x)
 
@@ -274,26 +274,152 @@ request_log(dns_dispatch_t *disp, dns_dispentry_t *resp,
 }
 
 /*
- * Return an unpredictable message ID.
+ * ARC4 random number generator obtained from OpenBSD
  */
-static dns_messageid_t
-dns_randomid(dns_nsid_t *nsid) {
-	isc_uint32_t id;
+static void
+dispatch_arc4init(arc4ctx_t *actx) {
+	int n;
+	for (n = 0; n < 256; n++)
+		actx->s[n] = n;
+	actx->i = 0;
+	actx->j = 0;
+	actx->count = 0;
+}
 
-	id = nsid_next(nsid);
+static void
+dispatch_arc4addrandom(arc4ctx_t *actx, unsigned char *dat, int datlen) {
+	int n;
+	isc_uint8_t si;
 
-	return ((dns_messageid_t)id);
+	actx->i--;
+	for (n = 0; n < 256; n++) {
+		actx->i = (actx->i + 1);
+		si = actx->s[actx->i];
+		actx->j = (actx->j + si + dat[n % datlen]);
+		actx->s[actx->i] = actx->s[actx->j];
+		actx->s[actx->j] = si;
+	}
+	actx->j = actx->i;
+}
+
+static inline isc_uint8_t
+dispatch_arc4get8(arc4ctx_t *actx) {
+	isc_uint8_t si, sj;
+
+	actx->i = (actx->i + 1);
+	si = actx->s[actx->i];
+	actx->j = (actx->j + si);
+	sj = actx->s[actx->j];
+	actx->s[actx->i] = sj;
+	actx->s[actx->j] = si;
+
+	return (actx->s[(si + sj) & 0xff]);
+}
+
+static inline isc_uint16_t
+dispatch_arc4get16(arc4ctx_t *actx) {
+	isc_uint16_t val;
+
+	val = dispatch_arc4get8(actx) << 8;
+	val |= dispatch_arc4get8(actx);
+
+	return (val);
+}
+
+static void
+dispatch_arc4stir(dns_dispatchmgr_t *mgr) {
+	int i;
+	union {
+		unsigned char rnd[128];
+		isc_uint32_t rnd32[32];
+	} rnd;
+	isc_result_t result;
+
+	if (mgr->entropy != NULL) {
+		/*
+		 * We accept any quality of random data to avoid blocking.
+		 */
+		result = isc_entropy_getdata(mgr->entropy, rnd.rnd,
+					     sizeof(rnd), NULL, 0);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+	} else {
+		for (i = 0; i < 32; i++)
+			isc_random_get(&rnd.rnd32[i]);
+	}
+	dispatch_arc4addrandom(&mgr->arc4ctx, rnd.rnd, sizeof(rnd.rnd));
+
+	/*
+	 * Discard early keystream, as per recommendations in:
+	 * http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps
+	 */
+	for (i = 0; i < 256; i++)
+		(void)dispatch_arc4get8(&mgr->arc4ctx);
+
+	/*
+	 * Derived from OpenBSD's implementation.  The rationale is not clear,
+	 * but should be conservative enough in safety, and reasonably large
+	 * for efficiency.
+	 */
+	mgr->arc4ctx.count = 1600000;
+}
+
+static isc_uint16_t
+dispatch_arc4random(dns_dispatchmgr_t *mgr) {
+	isc_uint16_t result;
+
+	LOCK(&mgr->arc4_lock);
+	mgr->arc4ctx.count -= sizeof(isc_uint16_t);
+	if (mgr->arc4ctx.count <= 0)
+		dispatch_arc4stir(mgr);
+	result = dispatch_arc4get16(&mgr->arc4ctx);
+	UNLOCK(&mgr->arc4_lock);
+	return (result);
+}
+
+static isc_uint16_t
+dispatch_arc4uniformrandom(dns_dispatchmgr_t *mgr, isc_uint16_t upper_bound) {
+	isc_uint16_t min, r;
+	/* The caller must hold the manager lock. */
+
+	if (upper_bound < 2)
+		return (0);
+
+	/*
+	 * Ensure the range of random numbers [min, 0xffff] be a multiple of
+	 * upper_bound and contain at least a half of the 16 bit range.
+	 */
+
+	if (upper_bound > 0x8000)
+		min = 1 + ~upper_bound; /* 0x8000 - upper_bound */
+	else
+		min = (isc_uint16_t)(0x10000 % (isc_uint32_t)upper_bound);
+
+	/*
+	 * This could theoretically loop forever but each retry has
+	 * p > 0.5 (worst case, usually far better) of selecting a
+	 * number inside the range we need, so it should rarely need
+	 * to re-roll.
+	 */
+	for (;;) {
+		r = dispatch_arc4random(mgr);
+		if (r >= min)
+			break;
+	}
+
+	return (r % upper_bound);
 }
 
 /*
  * Return a hash of the destination and message id.
  */
 static isc_uint32_t
-dns_hash(dns_qid_t *qid, isc_sockaddr_t *dest, dns_messageid_t id) {
+dns_hash(dns_qid_t *qid, isc_sockaddr_t *dest, dns_messageid_t id,
+	 in_port_t port)
+{
 	unsigned int ret;
 
 	ret = isc_sockaddr_hash(dest, ISC_TRUE);
-	ret ^= id;
+	ret ^= (id << 16) | port;
 	ret %= qid->qid_nbuckets;
 
 	INSIST(ret < qid->qid_nbuckets);
@@ -410,7 +536,7 @@ destroy_disp(isc_task_t *task, isc_event_t *event) {
  */
 static dns_dispentry_t *
 bucket_search(dns_qid_t *qid, isc_sockaddr_t *dest, dns_messageid_t id,
-	      unsigned int bucket)
+	      in_port_t port, unsigned int bucket)
 {
 	dns_dispentry_t *res;
 
@@ -419,8 +545,10 @@ bucket_search(dns_qid_t *qid, isc_sockaddr_t *dest, dns_messageid_t id,
 	res = ISC_LIST_HEAD(qid->qid_table[bucket]);
 
 	while (res != NULL) {
-		if ((res->id == id) && isc_sockaddr_equal(dest, &res->host))
+		if ((res->id == id) && isc_sockaddr_equal(dest, &res->host) &&
+		    res->port == port) {
 			return (res);
+		}
 		res = ISC_LIST_NEXT(res, link);
 	}
 
@@ -622,13 +750,10 @@ udp_recv(isc_task_t *task, isc_event_t *ev_in) {
 		goto restart;
 	}
 
-	dns_dispatch_hash(&ev->timestamp, sizeof(&ev->timestamp));
-	dns_dispatch_hash(ev->region.base, ev->region.length);
-
 	/* response */
-	bucket = dns_hash(qid, &ev->address, id);
+	bucket = dns_hash(qid, &ev->address, id, disp->localport);
 	LOCK(&qid->lock);
-	resp = bucket_search(qid, &ev->address, id, bucket);
+	resp = bucket_search(qid, &ev->address, id, disp->localport, bucket);
 	dispatch_log(disp, LVL(90),
 		     "search for response in bucket %d: %s",
 		     bucket, (resp == NULL ? "not found" : "found"));
@@ -859,14 +984,13 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) {
 		goto restart;
 	}
 
-	dns_dispatch_hash(tcpmsg->buffer.base, tcpmsg->buffer.length);
-
 	/*
 	 * Response.
 	 */
-	bucket = dns_hash(qid, &tcpmsg->address, id);
+	bucket = dns_hash(qid, &tcpmsg->address, id, disp->localport);
 	LOCK(&qid->lock);
-	resp = bucket_search(qid, &tcpmsg->address, id, bucket);
+	resp = bucket_search(qid, &tcpmsg->address, id, disp->localport,
+			     bucket);
 	dispatch_log(disp, LVL(90),
 		     "search for response in bucket %d: %s",
 		     bucket, (resp == NULL ? "not found" : "found"));
@@ -1015,6 +1139,8 @@ destroy_mgr(dns_dispatchmgr_t **mgrp) {
 	DESTROYLOCK(&mgr->lock);
 	mgr->state = 0;
 
+	DESTROYLOCK(&mgr->arc4_lock);
+
 	isc_mempool_destroy(&mgr->epool);
 	isc_mempool_destroy(&mgr->rpool);
 	isc_mempool_destroy(&mgr->dpool);
@@ -1093,10 +1219,14 @@ dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
 	if (result != ISC_R_SUCCESS)
 		goto deallocate;
 
-	result = isc_mutex_init(&mgr->buffer_lock);
+	result = isc_mutex_init(&mgr->arc4_lock);
 	if (result != ISC_R_SUCCESS)
 		goto kill_lock;
 
+	result = isc_mutex_init(&mgr->buffer_lock);
+	if (result != ISC_R_SUCCESS)
+		goto kill_arc4_lock;
+
 	result = isc_mutex_init(&mgr->pool_lock);
 	if (result != ISC_R_SUCCESS)
 		goto kill_buffer_lock;
@@ -1147,6 +1277,8 @@ dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
 	if (entropy != NULL)
 		isc_entropy_attach(entropy, &mgr->entropy);
 
+	dispatch_arc4init(&mgr->arc4ctx);
+
 	*mgrp = mgr;
 	return (ISC_R_SUCCESS);
 
@@ -1158,6 +1290,8 @@ dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
 	DESTROYLOCK(&mgr->pool_lock);
  kill_buffer_lock:
 	DESTROYLOCK(&mgr->buffer_lock);
+ kill_arc4_lock:
+	DESTROYLOCK(&mgr->arc4_lock);
  kill_lock:
 	DESTROYLOCK(&mgr->lock);
  deallocate:
@@ -1245,7 +1379,7 @@ dns_dispatchmgr_setudp(dns_dispatchmgr_t *mgr,
 	isc_mempool_setmaxalloc(mgr->bpool, maxbuffers);
 	isc_mempool_associatelock(mgr->bpool, &mgr->pool_lock);
 
-	result = qid_allocate(mgr, buckets, increment, ISC_TRUE, &mgr->qid);
+	result = qid_allocate(mgr, buckets, increment, &mgr->qid);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup;
 
@@ -1284,20 +1418,27 @@ dns_dispatchmgr_destroy(dns_dispatchmgr_t **mgrp) {
 }
 
 static isc_boolean_t
-blacklisted(dns_dispatchmgr_t *mgr, isc_socket_t *sock) {
+blacklisted(dns_dispatchmgr_t *mgr, isc_socket_t *sock,
+	    isc_sockaddr_t *sockaddrp)
+{
 	isc_sockaddr_t sockaddr;
 	isc_result_t result;
 
+	REQUIRE(sock != NULL || sockaddrp != NULL);
+
 	if (mgr->portlist == NULL)
 		return (ISC_FALSE);
 
-	result = isc_socket_getsockname(sock, &sockaddr);
-	if (result != ISC_R_SUCCESS)
-		return (ISC_FALSE);
+	if (sock != NULL) {
+		sockaddrp = &sockaddr;
+		result = isc_socket_getsockname(sock, sockaddrp);
+		if (result != ISC_R_SUCCESS)
+			return (ISC_FALSE);
+	}
 
 	if (mgr->portlist != NULL &&
-	    dns_portlist_match(mgr->portlist, isc_sockaddr_pf(&sockaddr),
-			       isc_sockaddr_getport(&sockaddr)))
+	    dns_portlist_match(mgr->portlist, isc_sockaddr_pf(sockaddrp),
+			       isc_sockaddr_getport(sockaddrp)))
 		return (ISC_TRUE);
 	return (ISC_FALSE);
 }
@@ -1318,7 +1459,7 @@ local_addr_match(dns_dispatch_t *disp, isc_sockaddr_t *addr) {
 	if (disp->mgr->portlist != NULL &&
 	    isc_sockaddr_getport(addr) == 0 &&
 	    isc_sockaddr_getport(&disp->local) == 0 &&
-	    blacklisted(disp->mgr, disp->socket))
+	    blacklisted(disp->mgr, disp->socket, NULL))
 		return (ISC_FALSE);
 
 	/*
@@ -1391,7 +1532,7 @@ dispatch_find(dns_dispatchmgr_t *mgr, isc_sockaddr_t *local,
 
 static isc_result_t
 qid_allocate(dns_dispatchmgr_t *mgr, unsigned int buckets,
-	     unsigned int increment, isc_boolean_t usepool, dns_qid_t **qidp)
+	     unsigned int increment, dns_qid_t **qidp)
 {
 	dns_qid_t *qid;
 	unsigned int i;
@@ -1412,16 +1553,8 @@ qid_allocate(dns_dispatchmgr_t *mgr, unsigned int buckets,
 		return (ISC_R_NOMEMORY);
 	}
 
-	if (nsid_init(mgr->mctx, &qid->nsid, usepool) != ISC_R_SUCCESS) {
-		isc_mem_put(mgr->mctx, qid->qid_table,
-			    buckets * sizeof(dns_displist_t));
-		isc_mem_put(mgr->mctx, qid, sizeof(*qid));
-		return (ISC_R_NOMEMORY);
-	}
-
 	if (isc_mutex_init(&qid->lock) != ISC_R_SUCCESS) {
 		UNEXPECTED_ERROR(__FILE__, __LINE__, "isc_mutex_init failed");
-		nsid_destroy(mgr->mctx, &qid->nsid);
 		isc_mem_put(mgr->mctx, qid->qid_table,
 			    buckets * sizeof(dns_displist_t));
 		isc_mem_put(mgr->mctx, qid, sizeof(*qid));
@@ -1449,7 +1582,6 @@ qid_destroy(isc_mem_t *mctx, dns_qid_t **qidp) {
 
 	*qidp = NULL;
 	qid->magic = 0;
-	nsid_destroy(mctx, &qid->nsid);
 	isc_mem_put(mctx, qid->qid_table,
 		    qid->qid_nbuckets * sizeof(dns_displist_t));
 	DESTROYLOCK(&qid->lock);
@@ -1486,6 +1618,7 @@ dispatch_allocate(dns_dispatchmgr_t *mgr, unsigned int maxrequests,
 	disp->refcount = 1;
 	disp->recv_pending = 0;
 	memset(&disp->local, 0, sizeof(disp->local));
+	disp->localport = 0;
 	disp->shutting_down = 0;
 	disp->shutdown_out = 0;
 	disp->connected = 0;
@@ -1593,7 +1726,7 @@ dns_dispatch_createtcp(dns_dispatchmgr_t *mgr, isc_socket_t *sock,
 		return (result);
 	}
 
-	result = qid_allocate(mgr, buckets, increment, ISC_FALSE, &disp->qid);
+	result = qid_allocate(mgr, buckets, increment, &disp->qid);
 	if (result != ISC_R_SUCCESS)
 		goto deallocate_dispatch;
 
@@ -1660,7 +1793,7 @@ dns_dispatch_getudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
 		    dns_dispatch_t **dispp)
 {
 	isc_result_t result;
-	dns_dispatch_t *disp;
+	dns_dispatch_t *disp = NULL;
 
 	REQUIRE(VALID_DISPATCHMGR(mgr));
 	REQUIRE(sockmgr != NULL);
@@ -1680,6 +1813,11 @@ dns_dispatch_getudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
 
 	LOCK(&mgr->lock);
 
+	if ((attributes & DNS_DISPATCHATTR_RANDOMPORT) != 0) {
+		REQUIRE(isc_sockaddr_getport(localaddr) == 0);
+		goto createudp;
+	}
+
 	/*
 	 * First, see if we have a dispatcher that matches.
 	 */
@@ -1708,6 +1846,7 @@ dns_dispatch_getudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
 		return (ISC_R_SUCCESS);
 	}
 
+ createudp:
 	/*
 	 * Nope, create one.
 	 */
@@ -1743,7 +1882,9 @@ dispatch_createudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
 	dns_dispatch_t *disp;
 	isc_socket_t *sock = NULL;
 	isc_socket_t *held[DNS_DISPATCH_HELD];
-	unsigned int i = 0, j = 0;
+	unsigned int i = 0, j = 0, k = 0;
+	isc_sockaddr_t localaddr_bound;
+	in_port_t localport = 0;
 
 	/*
 	 * dispatch_allocate() checks mgr for us.
@@ -1759,11 +1900,34 @@ dispatch_createudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
 	 * from returning the same port to us too quickly.
 	 */
 	memset(held, 0, sizeof(held));
+	localaddr_bound = *localaddr;
  getsocket:
-	result = create_socket(sockmgr, localaddr, &sock);
+	if ((attributes & DNS_DISPATCHATTR_RANDOMPORT) != 0) {
+		in_port_t prt;
+
+		/* XXX: should the range be configurable? */
+		prt = 1024 + dispatch_arc4uniformrandom(mgr, 65535 - 1023);
+		isc_sockaddr_setport(&localaddr_bound, prt);
+		if (blacklisted(mgr, NULL, &localaddr_bound)) {
+			if (++k == 1024)
+				attributes &= ~DNS_DISPATCHATTR_RANDOMPORT;
+			goto getsocket;
+		}
+		result = create_socket(sockmgr, &localaddr_bound, &sock);
+		if (result == ISC_R_ADDRINUSE) {
+			if (++k == 1024)
+				attributes &= ~DNS_DISPATCHATTR_RANDOMPORT;
+			goto getsocket;
+		}
+		localport = prt;
+	} else
+		result = create_socket(sockmgr, localaddr, &sock);
 	if (result != ISC_R_SUCCESS)
 		goto deallocate_dispatch;
-	if (isc_sockaddr_getport(localaddr) == 0 && blacklisted(mgr, sock)) {
+	if ((attributes & DNS_DISPATCHATTR_RANDOMPORT) == 0 &&
+	    isc_sockaddr_getport(localaddr) == 0 &&
+	    blacklisted(mgr, sock, NULL))
+	{
 		if (held[i] != NULL)
 			isc_socket_detach(&held[i]);
 		held[i++] = sock;
@@ -1784,6 +1948,7 @@ dispatch_createudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
 	disp->socktype = isc_sockettype_udp;
 	disp->socket = sock;
 	disp->local = *localaddr;
+	disp->localport = localport;
 
 	disp->task = NULL;
 	result = isc_task_create(taskmgr, 0, &disp->task);
@@ -1916,19 +2081,20 @@ dns_dispatch_addresponse(dns_dispatch_t *disp, isc_sockaddr_t *dest,
 	/*
 	 * Try somewhat hard to find an unique ID.
 	 */
+	id = (dns_messageid_t)dispatch_arc4random(disp->mgr);
 	qid = DNS_QID(disp);
 	LOCK(&qid->lock);
-	id = dns_randomid(&qid->nsid);
-	bucket = dns_hash(qid, dest, id);
+	bucket = dns_hash(qid, dest, id, disp->localport);
 	ok = ISC_FALSE;
 	for (i = 0; i < 64; i++) {
-		if (bucket_search(qid, dest, id, bucket) == NULL) {
+		if (bucket_search(qid, dest, id, disp->localport, bucket) ==
+		    NULL) {
 			ok = ISC_TRUE;
 			break;
 		}
 		id += qid->qid_increment;
 		id &= 0x0000ffff;
-		bucket = dns_hash(qid, dest, id);
+		bucket = dns_hash(qid, dest, id, disp->localport);
 	}
 
 	if (!ok) {
@@ -1950,6 +2116,7 @@ dns_dispatch_addresponse(dns_dispatch_t *disp, isc_sockaddr_t *dest,
 	isc_task_attach(task, &res->task);
 	res->disp = disp;
 	res->id = id;
+	res->port = disp->localport;
 	res->bucket = bucket;
 	res->host = *dest;
 	res->action = action;
@@ -2261,409 +2428,3 @@ dns_dispatchmgr_dump(dns_dispatchmgr_t *mgr) {
 	}
 }
 #endif
-
-/*
- * Allow the user to pick one of two ID randomization algorithms.
- *
- * The first algorithm is an adaptation of the sequence shuffling
- * algorithm discovered by Carter Bays and S. D. Durham [ACM Trans. Math.
- * Software 2 (1976), 59-64], as documented as Algorithm B in Chapter
- * 3.2.2 in Volume 2 of Knuth's "The Art of Computer Programming".  We use
- * a randomly selected linear congruential random number generator with a
- * modulus of 2^16, whose increment is a randomly picked odd number, and
- * whose multiplier is picked from a set which meets the following
- * criteria:
- *     Is of the form 8*n+5, which ensures "high potency" according to
- *     principle iii in the summary chapter 3.6.  This form also has a
- *     gcd(a-1,m) of 4 which is good according to principle iv.
- *
- *     Is between 0.01 and 0.99 times the modulus as specified by
- *     principle iv.
- *
- *     Passes the spectral test "with flying colors" (ut >= 1) in
- *     dimensions 2 through 6 as calculated by Algorithm S in Chapter
- *     3.3.4 and the ratings calculated by formula 35 in section E.
- *
- *     Of the multipliers that pass this test, pick the set that is
- *     best according to the theoretical bounds of the serial
- *     correlation test.  This was calculated using a simplified
- *     version of Knuth's Theorem K in Chapter 3.3.3.
- *
- * These criteria may not be important for this use, but we might as well
- * pick from the best generators since there are so many possible ones and
- * we don't have that many random bits to do the picking.
- *
- * We use a modulus of 2^16 instead of something bigger so that we will
- * tend to cycle through all the possible IDs before repeating any,
- * however the shuffling will perturb this somewhat.  Theoretically there
- * is no minimimum interval between two uses of the same ID, but in
- * practice it seems to be >64000.
- *
- * Our adaptatation  of Algorithm B mixes the hash state which has
- * captured various random events into the shuffler to perturb the
- * sequence.
- *
- * One disadvantage of this algorithm is that if the generator parameters
- * were to be guessed, it would be possible to mount a limited brute force
- * attack on the ID space since the IDs are only shuffled within a limited
- * range.
- *
- * The second algorithm uses the same random number generator to populate
- * a pool of 65536 IDs.  The hash state is used to pick an ID from a window
- * of 4096 IDs in this pool, then the chosen ID is swapped with the ID
- * at the beginning of the window and the window position is advanced.
- * This means that the interval between uses of the ID will be no less
- * than 65536-4096.  The ID sequence in the pool will become more random
- * over time.
- *
- * For both algorithms, two more linear congruential random number generators
- * are selected.  The ID from the first part of algorithm is used to seed
- * the first of these generators, and its output is used to seed the second.
- * The strategy is use these generators as 1 to 1 hashes to obfuscate the
- * properties of the generator used in the first part of either algorithm.
- *
- * The first algorithm may be suitable for use in a client resolver since
- * its memory requirements are fairly low and it's pretty random out of
- * the box.  It is somewhat succeptible to a limited brute force attack,
- * so the second algorithm is probably preferable for a longer running
- * program that issues a large number of queries and has time to randomize
- * the pool.
- */
-
-#define NSID_SHUFFLE_TABLE_SIZE 100 /* Suggested by Knuth */
-/*
- * Pick one of the next 4096 IDs in the pool.
- * There is a tradeoff here between randomness and how often and ID is reused.
- */
-#define NSID_LOOKAHEAD 4096     /* Must be a power of 2 */
-#define NSID_SHUFFLE_ONLY 1     /* algorithm 1 */
-#define NSID_USE_POOL 2         /* algorithm 2 */
-#define NSID_HASHSHIFT       3
-#define NSID_HASHROTATE(v) \
-        (((v) << NSID_HASHSHIFT) | ((v) >> ((sizeof(v) * 8) - NSID_HASHSHIFT)))
-
-static isc_uint32_t	nsid_hash_state;
-
-/*
- * Keep a running hash of various bits of data that we'll use to
- * stir the ID pool or perturb the ID generator
- */
-static void
-nsid_hash(void *data, size_t len) {
-	unsigned char *p = data;
-	/*
-	 * Hash function similar to the one we use for hashing names.
-	 * We don't fold case or toss the upper bit here, though.
-	 * This hash doesn't do much interesting when fed binary zeros,
-	 * so there may be a better hash function.
-	 * This function doesn't need to be very strong since we're
-	 * only using it to stir the pool, but it should be reasonably
-	 * fast.
-	 */
-	/*
-	 * We don't care about locking access to nsid_hash_state.
-	 * In fact races make the result even more non deteministic.
-	 */
-	while (len-- > 0U) {
-		nsid_hash_state = NSID_HASHROTATE(nsid_hash_state);
-		nsid_hash_state += *p++;
-	}
-}
-
-/*
- * Table of good linear congruential multipliers for modulus 2^16
- * in order of increasing serial correlation bounds (so trim from
- * the end).
- */
-static const isc_uint16_t nsid_multiplier_table[] = {
-	17565, 25013, 11733, 19877, 23989, 23997, 24997, 25421,
-	26781, 27413, 35901, 35917, 35973, 36229, 38317, 38437,
-	39941, 40493, 41853, 46317, 50581, 51429, 53453, 53805,
-	11317, 11789, 12045, 12413, 14277, 14821, 14917, 18989,
-	19821, 23005, 23533, 23573, 23693, 27549, 27709, 28461,
-	29365, 35605, 37693, 37757, 38309, 41285, 45261, 47061,
-	47269, 48133, 48597, 50277, 50717, 50757, 50805, 51341,
-	51413, 51581, 51597, 53445, 11493, 14229, 20365, 20653,
-	23485, 25541, 27429, 29421, 30173, 35445, 35653, 36789,
-	36797, 37109, 37157, 37669, 38661, 39773, 40397, 41837,
-	41877, 45293, 47277, 47845, 49853, 51085, 51349, 54085,
-	56933,  8877,  8973,  9885, 11365, 11813, 13581, 13589,
-	13613, 14109, 14317, 15765, 15789, 16925, 17069, 17205,
-	17621, 17941, 19077, 19381, 20245, 22845, 23733, 24869,
-	25453, 27213, 28381, 28965, 29245, 29997, 30733, 30901,
-	34877, 35485, 35613, 36133, 36661, 36917, 38597, 40285,
-	40693, 41413, 41541, 41637, 42053, 42349, 45245, 45469,
-	46493, 48205, 48613, 50861, 51861, 52877, 53933, 54397,
-	55669, 56453, 56965, 58021,  7757,  7781,  8333,  9661,
-	12229, 14373, 14453, 17549, 18141, 19085, 20773, 23701,
-	24205, 24333, 25261, 25317, 27181, 30117, 30477, 34757,
-	34885, 35565, 35885, 36541, 37957, 39733, 39813, 41157,
-	41893, 42317, 46621, 48117, 48181, 49525, 55261, 55389,
-	56845,  7045,  7749,  7965,  8469,  9133,  9549,  9789,
-	10173, 11181, 11285, 12253, 13453, 13533, 13757, 14477,
-	15053, 16901, 17213, 17269, 17525, 17629, 18605, 19013,
-	19829, 19933, 20069, 20093, 23261, 23333, 24949, 25309,
-	27613, 28453, 28709, 29301, 29541, 34165, 34413, 37301,
-	37773, 38045, 38405, 41077, 41781, 41925, 42717, 44437,
-	44525, 44613, 45933, 45941, 47077, 50077, 50893, 52117,
-	 5293, 55069, 55989, 58125, 59205,  6869, 14685, 15453,
-	16821, 17045, 17613, 18437, 21029, 22773, 22909, 25445,
-	25757, 26541, 30709, 30909, 31093, 31149, 37069, 37725,
-	37925, 38949, 39637, 39701, 40765, 40861, 42965, 44813,
-	45077, 45733, 47045, 50093, 52861, 52957, 54181, 56325,
-	56365, 56381, 56877, 57013,  5741, 58101, 58669,  8613,
-	10045, 10261, 10653, 10733, 11461, 12261, 14069, 15877,
-	17757, 21165, 23885, 24701, 26429, 26645, 27925, 28765,
-	29197, 30189, 31293, 39781, 39909, 40365, 41229, 41453,
-	41653, 42165, 42365, 47421, 48029, 48085, 52773,  5573,
-	57037, 57637, 58341, 58357, 58901,  6357,  7789,  9093,
-	10125, 10709, 10765, 11957, 12469, 13437, 13509, 14773,
-	15437, 15773, 17813, 18829, 19565, 20237, 23461, 23685,
-	23725, 23941, 24877, 25461, 26405, 29509, 30285, 35181,
-	37229, 37893, 38565, 40293, 44189, 44581, 45701, 47381,
-	47589, 48557,  4941, 51069,  5165, 52797, 53149,  5341,
-	56301, 56765, 58581, 59493, 59677,  6085,  6349,  8293,
-	 8501,  8517, 11597, 11709, 12589, 12693, 13517, 14909,
-	17397, 18085, 21101, 21269, 22717, 25237, 25661, 29189,
-	30101, 31397, 33933, 34213, 34661, 35533, 36493, 37309,
-	40037,  4189, 42909, 44309, 44357, 44389,  4541, 45461,
-	46445, 48237, 54149, 55301, 55853, 56621, 56717, 56901,
-	 5813, 58437, 12493, 15365, 15989, 17829, 18229, 19341,
-	21013, 21357, 22925, 24885, 26053, 27581, 28221, 28485,
-	30605, 30613, 30789, 35437, 36285, 37189,  3941, 41797,
-	 4269, 42901, 43293, 44645, 45221, 46893,  4893, 50301,
-	50325,  5189, 52109, 53517, 54053, 54485,  5525, 55949,
-	56973, 59069, 59421, 60733, 61253,  6421,  6701,  6709,
-	 7101,  8669, 15797, 19221, 19837, 20133, 20957, 21293,
-	21461, 22461, 29085, 29861, 30869, 34973, 36469, 37565,
-	38125, 38829, 39469, 40061, 40117, 44093, 47429, 48341,
-	50597, 51757,  5541, 57629, 58405, 59621, 59693, 59701,
-	61837,  7061, 10421, 11949, 15405, 20861, 25397, 25509,
-	25893, 26037, 28629, 28869, 29605, 30213, 34205, 35637,
-	36365, 37285,  3773, 39117,  4021, 41061, 42653, 44509,
-	 4461, 44829,  4725,  5125, 52269, 56469, 59085,  5917,
-	60973,  8349, 17725, 18637, 19773, 20293, 21453, 22533,
-	24285, 26333, 26997, 31501, 34541, 34805, 37509, 38477,
-	41333, 44125, 46285, 46997, 47637, 48173,  4925, 50253,
-	50381, 50917, 51205, 51325, 52165, 52229,  5253,  5269,
-	53509, 56253, 56341,  5821, 58373, 60301, 61653, 61973,
-	62373,  8397, 11981, 14341, 14509, 15077, 22261, 22429,
-	24261, 28165, 28685, 30661, 34021, 34445, 39149,  3917,
-	43013, 43317, 44053, 44101,  4533, 49541, 49981,  5277,
-	54477, 56357, 57261, 57765, 58573, 59061, 60197, 61197,
-	62189,  7725,  8477,  9565, 10229, 11437, 14613, 14709,
-	16813, 20029, 20677, 31445,  3165, 31957,  3229, 33541,
-	36645,  3805, 38973,  3965,  4029, 44293, 44557, 46245,
-	48917,  4909, 51749, 53709, 55733, 56445,  5925,  6093,
-	61053, 62637,  8661,  9109, 10821, 11389, 13813, 14325,
-	15501, 16149, 18845, 22669, 26437, 29869, 31837, 33709,
-	33973, 34173,  3677,  3877,  3981, 39885, 42117,  4421,
-	44221, 44245, 44693, 46157, 47309,  5005, 51461, 52037,
-	55333, 55693, 56277, 58949,  6205, 62141, 62469,  6293,
-	10101, 12509, 14029, 17997, 20469, 21149, 25221, 27109,
-	 2773,  2877, 29405, 31493, 31645,  4077, 42005, 42077,
-	42469, 42501, 44013, 48653, 49349,  4997, 50101, 55405,
-	56957, 58037, 59429, 60749, 61797, 62381, 62837,  6605,
-	10541, 23981, 24533,  2701, 27333, 27341, 31197, 33805,
-	 3621, 37381,  3749,  3829, 38533, 42613, 44381, 45901,
-	48517, 51269, 57725, 59461, 60045, 62029, 13805, 14013,
-	15461, 16069, 16157, 18573,  2309, 23501, 28645,  3077,
-	31541, 36357, 36877,  3789, 39429, 39805, 47685, 47949,
-	49413,  5485, 56757, 57549, 57805, 58317, 59549, 62213,
-	62613, 62853, 62933,  8909, 12941, 16677, 20333, 21541,
-	24429, 26077, 26421,  2885, 31269, 33381,  3661, 40925,
-	42925, 45173,  4525,  4709, 53133, 55941, 57413, 57797,
-	62125, 62237, 62733,  6773, 12317, 13197, 16533, 16933,
-	18245,  2213,  2477, 29757, 33293, 35517, 40133, 40749,
-	 4661, 49941, 62757,  7853,  8149,  8573, 11029, 13421,
-	21549, 22709, 22725, 24629,  2469, 26125,  2669, 34253,
-	36709, 41013, 45597, 46637, 52285, 52333, 54685, 59013,
-	60997, 61189, 61981, 62605, 62821,  7077,  7525,  8781,
-	10861, 15277,  2205, 22077, 28517, 28949, 32109, 33493,
-	 4661, 49941, 62757,  7853,  8149,  8573, 11029, 13421,
-	21549, 22709, 22725, 24629,  2469, 26125,  2669, 34253,
-	36709, 41013, 45597, 46637, 52285, 52333, 54685, 59013,
-	60997, 61189, 61981, 62605, 62821,  7077,  7525,  8781,
-	10861, 15277,  2205, 22077, 28517, 28949, 32109, 33493,
-	 3685, 39197, 39869, 42621, 44997, 48565,  5221, 57381,
-	61749, 62317, 63245, 63381, 23149,  2549, 28661, 31653,
-	33885, 36341, 37053, 39517, 42805, 45853, 48997, 59349,
-	60053, 62509, 63069,  6525,  1893, 20181,  2365, 24893,
-	27397, 31357, 32277, 33357, 34437, 36677, 37661, 43469,
-	43917, 50997, 53869,  5653, 13221, 16741, 17893,  2157,
-	28653, 31789, 35301, 35821, 61613, 62245, 12405, 14517,
-	17453, 18421,  3149,  3205, 40341,  4109, 43941, 46869,
-	48837, 50621, 57405, 60509, 62877,  8157, 12933, 12957,
-	16501, 19533,  3461, 36829, 52357, 58189, 58293, 63053,
-	17109,  1933, 32157, 37701, 59005, 61621, 13029, 15085,
-	16493, 32317, 35093,  5061, 51557, 62221, 20765, 24613,
-	 2629, 30861, 33197, 33749, 35365, 37933, 40317, 48045,
-	56229, 61157, 63797,  7917, 17965,  1917,  1973, 20301,
-	 2253, 33157, 58629, 59861, 61085, 63909,  8141,  9221,
-	14757,  1581, 21637, 26557, 33869, 34285, 35733, 40933,
-	42517, 43501, 53653, 61885, 63805,  7141, 21653, 54973,
-	31189, 60061, 60341, 63357, 16045,  2053, 26069, 33997,
-	43901, 54565, 63837,  8949, 17909, 18693, 32349, 33125,
-	37293, 48821, 49053, 51309, 64037,  7117,  1445, 20405,
-	23085, 26269, 26293, 27349, 32381, 33141, 34525, 36461,
-	37581, 43525,  4357, 43877,  5069, 55197, 63965,  9845,
-	12093,  2197,  2229, 32165, 33469, 40981, 42397,  8749,
-	10853,  1453, 18069, 21693, 30573, 36261, 37421, 42533
-};
-
-#define NSID_MULT_TABLE_SIZE \
-        ((sizeof nsid_multiplier_table)/(sizeof nsid_multiplier_table[0]))
-#define NSID_RANGE_MASK (NSID_LOOKAHEAD - 1)
-#define NSID_POOL_MASK 0xFFFF /* used to wrap the pool index */
-#define NSID_SHUFFLE_ONLY 1
-#define NSID_USE_POOL 2
-
-static isc_uint16_t
-nsid_next(dns_nsid_t *nsid) {
-        isc_uint16_t id, compressed_hash;
-	isc_uint16_t j;
-
-        compressed_hash = ((nsid_hash_state >> 16) ^
-			   (nsid_hash_state)) & 0xFFFF;
-
-	if (nsid->nsid_usepool) {
-	        isc_uint16_t pick;
-
-                pick = compressed_hash & NSID_RANGE_MASK;
-		pick = (nsid->nsid_state + pick) & NSID_POOL_MASK;
-                id = nsid->nsid_pool[pick];
-                if (pick != 0) {
-                        /* Swap two IDs to stir the pool */
-                        nsid->nsid_pool[pick] =
-                                nsid->nsid_pool[nsid->nsid_state];
-                        nsid->nsid_pool[nsid->nsid_state] = id;
-                }
-
-                /* increment the base pointer into the pool */
-                if (nsid->nsid_state == 65535)
-                        nsid->nsid_state = 0;
-                else
-                        nsid->nsid_state++;
-	} else {
-		/*
-		 * This is the original Algorithm B
-		 * j = ((u_long) NSID_SHUFFLE_TABLE_SIZE * nsid_state2) >> 16;
-		 *
-		 * We'll perturb it with some random stuff  ...
-		 */
-		j = ((isc_uint32_t) NSID_SHUFFLE_TABLE_SIZE *
-		     (nsid->nsid_state2 ^ compressed_hash)) >> 16;
-		nsid->nsid_state2 = id = nsid->nsid_vtable[j];
-		nsid->nsid_state = (((isc_uint32_t) nsid->nsid_a1 * nsid->nsid_state) +
-				      nsid->nsid_c1) & 0xFFFF;
-		nsid->nsid_vtable[j] = nsid->nsid_state;
-	}
-
-        /* Now lets obfuscate ... */
-        id = (((isc_uint32_t) nsid->nsid_a2 * id) + nsid->nsid_c2) & 0xFFFF;
-        id = (((isc_uint32_t) nsid->nsid_a3 * id) + nsid->nsid_c3) & 0xFFFF;
-
-        return (id);
-}
-
-static isc_result_t
-nsid_init(isc_mem_t *mctx, dns_nsid_t *nsid, isc_boolean_t usepool) {
-        isc_time_t now;
-        pid_t mypid;
-        isc_uint16_t a1ndx, a2ndx, a3ndx, c1ndx, c2ndx, c3ndx;
-        int i;
-
-	isc_time_now(&now);
-        mypid = getpid();
-
-        /* Initialize the state */
-	memset(nsid, 0, sizeof(*nsid));
-        nsid_hash(&now, sizeof now);
-        nsid_hash(&mypid, sizeof mypid);
-
-        /*
-         * Select our random number generators and initial seed.
-         * We could really use more random bits at this point,
-         * but we'll try to make a silk purse out of a sows ear ...
-         */
-        /* generator 1 */
-        a1ndx = ((isc_uint32_t) NSID_MULT_TABLE_SIZE *
-                 (nsid_hash_state & 0xFFFF)) >> 16;
-        nsid->nsid_a1 = nsid_multiplier_table[a1ndx];
-        c1ndx = (nsid_hash_state >> 9) & 0x7FFF;
-        nsid->nsid_c1 = 2 * c1ndx + 1;
-
-        /* generator 2, distinct from 1 */
-        a2ndx = ((isc_uint32_t) (NSID_MULT_TABLE_SIZE - 1) *
-                 ((nsid_hash_state >> 10) & 0xFFFF)) >> 16;
-        if (a2ndx >= a1ndx)
-                a2ndx++;
-        nsid->nsid_a2 = nsid_multiplier_table[a2ndx];
-        c2ndx = nsid_hash_state % 32767;
-        if (c2ndx >= c1ndx)
-                c2ndx++;
-        nsid->nsid_c2 = 2*c2ndx + 1;
-
-        /* generator 3, distinct from 1 and 2 */
-        a3ndx = ((isc_uint32_t) (NSID_MULT_TABLE_SIZE - 2) *
-                 ((nsid_hash_state >> 20) & 0xFFFF)) >> 16;
-        if (a3ndx >= a1ndx || a3ndx >= a2ndx)
-                a3ndx++;
-        if (a3ndx >= a1ndx && a3ndx >= a2ndx)
-                a3ndx++;
-        nsid->nsid_a3 = nsid_multiplier_table[a3ndx];
-        c3ndx = nsid_hash_state % 32766;
-        if (c3ndx >= c1ndx || c3ndx >= c2ndx)
-                c3ndx++;
-        if (c3ndx >= c1ndx && c3ndx >= c2ndx)
-                c3ndx++;
-        nsid->nsid_c3 = 2*c3ndx + 1;
-
-        nsid->nsid_state =
-		((nsid_hash_state >> 16) ^ (nsid_hash_state)) & 0xFFFF;
-
-	nsid->nsid_usepool = usepool;
-	if (nsid->nsid_usepool) {
-                nsid->nsid_pool = isc_mem_get(mctx, 0x10000 * sizeof(isc_uint16_t));
-		if (nsid->nsid_pool == NULL)
-			return (ISC_R_NOMEMORY);
-                for (i = 0; ; i++) {
-                        nsid->nsid_pool[i] = nsid->nsid_state;
-                        nsid->nsid_state =
-				 (((u_long) nsid->nsid_a1 * nsid->nsid_state) +
-				   nsid->nsid_c1) & 0xFFFF;
-                        if (i == 0xFFFF)
-                                break;
-                }
-	} else {
-		nsid->nsid_vtable = isc_mem_get(mctx, NSID_SHUFFLE_TABLE_SIZE *
-						(sizeof(isc_uint16_t)) );
-		if (nsid->nsid_vtable == NULL)
-			return (ISC_R_NOMEMORY);
-
-		for (i = 0; i < NSID_SHUFFLE_TABLE_SIZE; i++) {
-			nsid->nsid_vtable[i] = nsid->nsid_state;
-			nsid->nsid_state =
-				   (((isc_uint32_t) nsid->nsid_a1 * nsid->nsid_state) +
-					 nsid->nsid_c1) & 0xFFFF;
-		}
-		nsid->nsid_state2 = nsid->nsid_state;
-	} 
-	return (ISC_R_SUCCESS);
-}
-
-static void
-nsid_destroy(isc_mem_t *mctx, dns_nsid_t *nsid) {
-	if (nsid->nsid_usepool)
-		isc_mem_put(mctx, nsid->nsid_pool,
-			    0x10000 * sizeof(isc_uint16_t));
-	else
-		isc_mem_put(mctx, nsid->nsid_vtable,
-			    NSID_SHUFFLE_TABLE_SIZE * (sizeof(isc_uint16_t)) );
-	memset(nsid, 0, sizeof(*nsid));
-}
-
-void
-dns_dispatch_hash(void *data, size_t len) {
-	nsid_hash(data, len);
-}
diff --git a/lib/dns/include/dns/dispatch.h b/lib/dns/include/dns/dispatch.h
index 29dd7f8063..806ab880f3 100644
--- a/lib/dns/include/dns/dispatch.h
+++ b/lib/dns/include/dns/dispatch.h
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dispatch.h,v 1.45.2.2.4.5 2007/08/28 07:19:14 tbox Exp $ */
+/* $Id: dispatch.h,v 1.45.2.2.4.5.4.1 2008/05/22 21:11:16 each Exp $ */
 
 #ifndef DNS_DISPATCH_H
 #define DNS_DISPATCH_H 1
@@ -112,6 +112,9 @@ struct dns_dispatchevent {
  * _MAKEQUERY
  *	The dispatcher can be used to issue queries to other servers, and
  *	accept replies from them.
+ *
+ * _RANDOMPORT
+ *	Allocate UDP port randomly.
  */
 #define DNS_DISPATCHATTR_PRIVATE	0x00000001U
 #define DNS_DISPATCHATTR_TCP		0x00000002U
@@ -121,6 +124,7 @@ struct dns_dispatchevent {
 #define DNS_DISPATCHATTR_NOLISTEN	0x00000020U
 #define DNS_DISPATCHATTR_MAKEQUERY	0x00000040U
 #define DNS_DISPATCHATTR_CONNECTED	0x00000080U
+#define DNS_DISPATCHATTR_RANDOMPORT	0x00000100U
 
 isc_result_t
 dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
@@ -437,13 +441,6 @@ dns_dispatch_importrecv(dns_dispatch_t *disp, isc_event_t *event);
  * 	event != NULL
  */
 
-void
-dns_dispatch_hash(void *data, size_t len);
-/*%<
- * Feed 'data' to the dispatch query id generator where 'len' is the size
- * of 'data'.
- */
-
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_DISPATCH_H */
diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c
index 16d22e08b3..93f10f5dd3 100644
--- a/lib/dns/resolver.c
+++ b/lib/dns/resolver.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.c,v 1.218.2.18.4.77 2008/01/17 23:45:27 tbox Exp $ */
+/* $Id: resolver.c,v 1.218.2.18.4.77.2.1 2008/05/22 21:11:15 each Exp $ */
 
 #include <config.h>
 
@@ -1070,17 +1070,50 @@ fctx_query(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
 		 * A dispatch will be created once the connect succeeds.
 		 */
 	} else {
+		isc_sockaddr_t localaddr;
+		unsigned int attrs, attrmask;
+		dns_dispatch_t *disp_base;
+
+		attrs = 0;
+		attrs |= DNS_DISPATCHATTR_UDP;
+		attrs |= DNS_DISPATCHATTR_RANDOMPORT;
+
+		attrmask = 0;
+		attrmask |= DNS_DISPATCHATTR_UDP;
+		attrmask |= DNS_DISPATCHATTR_TCP;
+		attrmask |= DNS_DISPATCHATTR_IPV4;
+		attrmask |= DNS_DISPATCHATTR_IPV6;
+
 		switch (isc_sockaddr_pf(&addrinfo->sockaddr)) {
-		case PF_INET:
-			dns_dispatch_attach(res->dispatchv4, &query->dispatch);
+		case AF_INET:
+			disp_base = res->dispatchv4;
+			attrs |= DNS_DISPATCHATTR_IPV4;
 			break;
-		case PF_INET6:
-			dns_dispatch_attach(res->dispatchv6, &query->dispatch);
+		case AF_INET6:
+			disp_base = res->dispatchv6;
+			attrs |= DNS_DISPATCHATTR_IPV6;
 			break;
 		default:
 			result = ISC_R_NOTIMPLEMENTED;
 			goto cleanup_query;
 		}
+
+		result = dns_dispatch_getlocaladdress(disp_base, &localaddr);
+		if (result != ISC_R_SUCCESS)
+			goto cleanup_query;
+		if (isc_sockaddr_getport(&localaddr) == 0) {
+			result = dns_dispatch_getudp(res->dispatchmgr,
+						     res->socketmgr,
+						     res->taskmgr,
+						     &localaddr,
+						     4096, 1000, 32768,
+						     16411, 16433,
+						     attrs, attrmask,
+						     &query->dispatch);
+			if (result != ISC_R_SUCCESS)
+				goto cleanup_query;
+		} else
+			dns_dispatch_attach(disp_base, &query->dispatch);
 		/*
 		 * We should always have a valid dispatcher here.  If we
 		 * don't support a protocol family, then its dispatcher
diff --git a/lib/dns/win32/libdns.def b/lib/dns/win32/libdns.def
index 8f97bee918..7f577d7816 100644
--- a/lib/dns/win32/libdns.def
+++ b/lib/dns/win32/libdns.def
@@ -121,10 +121,8 @@ dns_decompress_init
 dns_decompress_invalidate
 dns_decompress_setmethods
 dns_decompress_type
-dns_dispatch_hash
 dns_rdatacallbacks_init
 dns_rdatacallbacks_init_stdio
-
 dns_difftuple_create
 dns_difftuple_free
 dns_difftuple_copy
diff --git a/version b/version
index 4327c9e433..6853a8a6bf 100644
--- a/version
+++ b/version
@@ -1,4 +1,4 @@
-# $Id: version,v 1.26.2.17.2.31 2008/04/03 00:22:17 each Exp $
+# $Id: version,v 1.26.2.17.2.31.4.1 2008/05/22 21:11:13 each Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -6,5 +6,5 @@
 MAJORVER=9
 MINORVER=3
 PATCHVER=5
-RELEASETYPE=
-RELEASEVER=
+RELEASETYPE=-P
+RELEASEVER=1