From e6787144c0a7f2ccb1b75e05abbd390f0fd225cd Mon Sep 17 00:00:00 2001 From: Doug Barton Date: Sun, 7 Feb 2010 22:14:10 +0000 Subject: Vendor import of BIND 9.4-ESV --- CHANGES | 288 +- COPYRIGHT | 4 +- FAQ | 30 +- FAQ.xml | 33 +- Makefile.in | 17 +- README | 35 +- README.idnkit | 8 +- acconfig.h | 14 +- bin/check/check-tool.c | 7 +- bin/check/named-checkconf.8 | 4 +- bin/check/named-checkconf.c | 32 +- bin/check/named-checkconf.html | 4 +- bin/check/named-checkzone.8 | 10 +- bin/check/named-checkzone.c | 18 +- bin/check/named-checkzone.docbook | 7 +- bin/check/named-checkzone.html | 18 +- bin/dig/dig.1 | 12 +- bin/dig/dig.c | 42 +- bin/dig/dig.docbook | 31 +- bin/dig/dig.html | 42 +- bin/dig/dighost.c | 198 +- bin/dig/host.1 | 12 +- bin/dig/host.c | 40 +- bin/dig/host.docbook | 9 +- bin/dig/host.html | 18 +- bin/dig/include/dig/dig.h | 30 +- bin/dig/nslookup.1 | 4 +- bin/dig/nslookup.c | 47 +- bin/dig/nslookup.html | 4 +- bin/dnssec/dnssec-keygen.8 | 4 +- bin/dnssec/dnssec-keygen.html | 4 +- bin/dnssec/dnssec-signzone.8 | 4 +- bin/dnssec/dnssec-signzone.c | 72 +- bin/dnssec/dnssec-signzone.html | 4 +- bin/named/client.c | 8 +- bin/named/control.c | 12 +- bin/named/include/named/client.h | 14 +- bin/named/include/named/log.h | 7 +- bin/named/include/named/lwdclient.h | 8 +- bin/named/include/named/notify.h | 8 +- bin/named/include/named/server.h | 11 +- bin/named/interfacemgr.c | 6 +- bin/named/log.c | 9 +- bin/named/lwresd.8 | 10 +- bin/named/lwresd.docbook | 7 +- bin/named/lwresd.html | 18 +- bin/named/main.c | 14 +- bin/named/named.8 | 4 +- bin/named/named.conf.5 | 4 +- bin/named/named.conf.html | 4 +- bin/named/named.html | 4 +- bin/named/query.c | 192 +- bin/named/server.c | 194 +- bin/named/unix/os.c | 22 +- bin/named/update.c | 242 +- bin/named/xfrout.c | 78 +- bin/nsupdate/nsupdate.1 | 10 +- bin/nsupdate/nsupdate.c | 7 +- bin/nsupdate/nsupdate.docbook | 7 +- bin/nsupdate/nsupdate.html | 20 +- bin/rndc/include/rndc/os.h | 8 +- bin/rndc/rndc-confgen.8 | 4 +- bin/rndc/rndc-confgen.html | 4 +- bin/rndc/rndc.8 | 4 +- bin/rndc/rndc.c | 8 +- bin/rndc/rndc.conf.5 | 4 +- bin/rndc/rndc.conf.html | 4 +- bin/rndc/rndc.html | 4 +- config.guess | 2 +- config.h.in | 20 +- configure.in | 158 +- doc/arm/Bv9ARM-book.xml | 534 +- doc/arm/Bv9ARM.ch01.html | 70 +- doc/arm/Bv9ARM.ch02.html | 26 +- doc/arm/Bv9ARM.ch03.html | 46 +- doc/arm/Bv9ARM.ch04.html | 88 +- doc/arm/Bv9ARM.ch05.html | 10 +- doc/arm/Bv9ARM.ch06.html | 593 +- doc/arm/Bv9ARM.ch07.html | 34 +- doc/arm/Bv9ARM.ch08.html | 22 +- doc/arm/Bv9ARM.ch09.html | 192 +- doc/arm/Bv9ARM.ch10.html | 6 +- doc/arm/Bv9ARM.html | 150 +- doc/arm/Bv9ARM.pdf | 12719 ++++++++++--------- doc/arm/Makefile.in | 8 +- doc/arm/man.dig.html | 42 +- doc/arm/man.dnssec-keygen.html | 18 +- doc/arm/man.dnssec-signzone.html | 16 +- doc/arm/man.host.html | 18 +- doc/arm/man.named-checkconf.html | 16 +- doc/arm/man.named-checkzone.html | 18 +- doc/arm/man.named.html | 20 +- doc/arm/man.rndc-confgen.html | 16 +- doc/arm/man.rndc.conf.html | 16 +- doc/arm/man.rndc.html | 16 +- doc/draft/draft-baba-dnsext-acl-reqts-01.txt | 336 - doc/draft/draft-daigle-napstr-04.txt | 1232 -- doc/draft/draft-danisch-dns-rr-smtp-03.txt | 1960 --- doc/draft/draft-dnsext-opcode-discover-02.txt | 241 - doc/draft/draft-durand-dnsop-dynreverse-00.txt | 240 - ...draft-ietf-6man-text-addr-representation-01.txt | 785 ++ doc/draft/draft-ietf-behave-dns64-01.txt | 1624 +++ doc/draft/draft-ietf-dnsext-2929bis-01.txt | 928 -- doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt | 393 - doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt | 1579 +++ doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt | 674 - doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt | 1397 -- .../draft-ietf-dnsext-dns-tcp-requirements-02.txt | 448 + ...t-ietf-dnsext-dnssec-2535typecode-change-06.txt | 442 - .../draft-ietf-dnsext-dnssec-bis-updates-01.txt | 616 - .../draft-ietf-dnsext-dnssec-bis-updates-09.txt | 672 + .../draft-ietf-dnsext-dnssec-experiments-01.txt | 784 -- doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt | 448 + .../draft-ietf-dnsext-dnssec-online-signing-02.txt | 616 - doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt | 896 -- .../draft-ietf-dnsext-dnssec-rsasha256-00.txt | 392 - doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt | 839 -- doc/draft/draft-ietf-dnsext-ds-sha256-05.txt | 504 - ...draft-ietf-dnsext-keyrr-key-signing-flag-12.txt | 560 - doc/draft/draft-ietf-dnsext-mdns-43.txt | 1740 --- doc/draft/draft-ietf-dnsext-nsec3-04.txt | 2352 ---- doc/draft/draft-ietf-dnsext-nsid-01.txt | 840 -- doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt | 464 - doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt | 840 -- doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt | 580 - .../draft-ietf-dnsext-rfc2671bis-edns0-02.txt | 616 + .../draft-ietf-dnsext-rfc2672bis-dname-18.txt | 953 ++ doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt | 395 + ...-dnsext-signed-nonexistence-requirements-01.txt | 755 -- .../draft-ietf-dnsext-tkey-renewal-mode-05.txt | 1292 -- .../draft-ietf-dnsext-trustupdate-threshold-00.txt | 1501 --- .../draft-ietf-dnsext-trustupdate-timers-02.txt | 730 -- .../draft-ietf-dnsext-tsig-md5-deprecated-03.txt | 336 + doc/draft/draft-ietf-dnsext-tsig-sha-06.txt | 522 - doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt | 1063 -- .../draft-ietf-dnsop-default-local-zones-09.txt | 729 ++ ...-ietf-dnsop-dnssec-operational-practices-08.txt | 2016 --- .../draft-ietf-dnsop-ipv6-dns-configuration-06.txt | 1848 --- doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt | 1682 --- ...aft-ietf-dnsop-ipv6-transport-guidelines-01.txt | 300 - ...aft-ietf-dnsop-key-rollover-requirements-02.txt | 389 - ...t-ietf-dnsop-name-server-management-reqs-02.txt | 952 ++ doc/draft/draft-ietf-dnsop-respsize-02.txt | 480 - doc/draft/draft-ietf-dnsop-respsize-06.txt | 640 + doc/draft/draft-ietf-dnsop-serverid-06.txt | 618 - doc/draft/draft-ietf-enum-e164-gstn-np-05.txt | 1588 --- doc/draft/draft-ietf-ipv6-node-requirements-08.txt | 1200 -- doc/draft/draft-ietf-secsh-dns-05.txt | 614 - .../draft-ihren-dnsext-threshold-validation-00.txt | 519 - .../draft-park-ipv6-extensions-dns-pnp-00.txt | 1830 --- doc/misc/Makefile.in | 16 +- doc/rfc/index | 21 + doc/rfc/rfc1912.txt | 899 ++ doc/rfc/rfc3755.txt | 507 + doc/rfc/rfc4294.txt | 1123 ++ doc/rfc/rfc4339.txt | 1459 +++ doc/rfc/rfc4471.txt | 1291 ++ doc/rfc/rfc4472.txt | 1627 +++ doc/rfc/rfc4509.txt | 395 + doc/rfc/rfc4635.txt | 451 + doc/rfc/rfc4697.txt | 1011 ++ doc/rfc/rfc4892.txt | 451 + doc/rfc/rfc4955.txt | 395 + doc/rfc/rfc4956.txt | 955 ++ doc/rfc/rfc5001.txt | 619 + doc/rfc/rfc5011.txt | 787 ++ doc/rfc/rfc5205.txt | 955 ++ doc/rfc/rfc5452.txt | 1011 ++ doc/rfc/rfc5507.txt | 1011 ++ doc/rfc/rfc5625.txt | 675 + doc/rfc/rfc5702.txt | 563 + lib/bind/configure.in | 6 +- lib/bind9/api | 2 +- lib/bind9/check.c | 25 +- lib/bind9/include/bind9/getaddresses.h | 10 +- lib/dns/adb.c | 33 +- lib/dns/cache.c | 8 +- lib/dns/db.c | 18 +- lib/dns/diff.c | 12 +- lib/dns/dispatch.c | 29 +- lib/dns/dlz.c | 10 +- lib/dns/dnssec.c | 39 +- lib/dns/dst_api.c | 37 +- lib/dns/dst_parse.c | 8 +- lib/dns/gen-unix.h | 8 +- lib/dns/include/dns/Makefile.in | 10 +- lib/dns/include/dns/acl.h | 13 +- lib/dns/include/dns/compress.h | 10 +- lib/dns/include/dns/db.h | 14 +- lib/dns/include/dns/diff.h | 12 +- lib/dns/include/dns/dlz.h | 14 +- lib/dns/include/dns/journal.h | 12 +- lib/dns/include/dns/log.h | 8 +- lib/dns/include/dns/lookup.h | 10 +- lib/dns/include/dns/message.h | 20 +- lib/dns/include/dns/name.h | 20 +- lib/dns/include/dns/peer.h | 12 +- lib/dns/include/dns/rbt.h | 38 +- lib/dns/include/dns/rdata.h | 15 +- lib/dns/include/dns/rdataset.h | 12 +- lib/dns/include/dns/request.h | 16 +- lib/dns/include/dns/resolver.h | 27 +- lib/dns/include/dns/sdb.h | 10 +- lib/dns/include/dns/sdlz.h | 10 +- lib/dns/include/dns/tkey.h | 8 +- lib/dns/include/dns/types.h | 28 +- lib/dns/include/dns/validator.h | 8 +- lib/dns/include/dns/view.h | 26 +- lib/dns/include/dns/xfrin.h | 10 +- lib/dns/include/dns/zone.h | 41 +- lib/dns/journal.c | 14 +- lib/dns/master.c | 6 +- lib/dns/masterdump.c | 6 +- lib/dns/message.c | 8 +- lib/dns/nsec.c | 10 +- lib/dns/openssl_link.c | 16 +- lib/dns/openssldsa_link.c | 10 +- lib/dns/opensslrsa_link.c | 10 +- lib/dns/rbt.c | 10 +- lib/dns/rbtdb.c | 46 +- lib/dns/rdata.c | 28 +- lib/dns/rdata/generic/ipseckey_45.c | 23 +- lib/dns/rdata/generic/loc_29.c | 13 +- lib/dns/rdata/generic/soa_6.c | 35 +- lib/dns/rdata/in_1/wks_11.c | 10 +- lib/dns/rdataset.c | 16 +- lib/dns/rdataslab.c | 14 +- lib/dns/request.c | 8 +- lib/dns/resolver.c | 601 +- lib/dns/sdb.c | 13 +- lib/dns/sdlz.c | 19 +- lib/dns/time.c | 8 +- lib/dns/validator.c | 59 +- lib/dns/zone.c | 76 +- lib/isc/Makefile.in | 6 +- lib/isc/alpha/include/isc/atomic.h | 42 +- lib/isc/api | 6 +- lib/isc/entropy.c | 10 +- lib/isc/ia64/include/isc/atomic.h | 24 +- lib/isc/include/isc/entropy.h | 22 +- lib/isc/include/isc/file.h | 10 +- lib/isc/include/isc/fsaccess.h | 16 +- lib/isc/include/isc/hash.h | 10 +- lib/isc/include/isc/heap.h | 8 +- lib/isc/include/isc/log.h | 27 +- lib/isc/include/isc/mem.h | 21 +- lib/isc/include/isc/netaddr.h | 10 +- lib/isc/include/isc/netscope.h | 8 +- lib/isc/include/isc/platform.h.in | 7 +- lib/isc/include/isc/portset.h | 8 +- lib/isc/include/isc/random.h | 8 +- lib/isc/include/isc/ratelimiter.h | 12 +- lib/isc/include/isc/serial.h | 10 +- lib/isc/include/isc/sockaddr.h | 8 +- lib/isc/include/isc/socket.h | 6 +- lib/isc/include/isc/symtab.h | 8 +- lib/isc/include/isc/task.h | 16 +- lib/isc/inet_aton.c | 14 +- lib/isc/inet_ntop.c | 13 +- lib/isc/log.c | 29 +- lib/isc/mem.c | 46 +- lib/isc/random.c | 29 +- lib/isc/rwlock.c | 26 +- lib/isc/sha2.c | 36 +- lib/isc/timer.c | 11 +- lib/isc/unix/dir.c | 14 +- lib/isc/unix/entropy.c | 29 +- lib/isc/unix/file.c | 21 +- lib/isc/unix/ifiter_getifaddrs.c | 6 +- lib/isc/unix/ifiter_ioctl.c | 32 +- lib/isc/unix/include/isc/net.h | 5 +- lib/isc/unix/include/isc/offset.h | 7 +- lib/isc/unix/include/isc/strerror.h | 8 +- lib/isc/unix/include/isc/time.h | 10 +- lib/isc/unix/resource.c | 10 +- lib/isc/unix/socket.c | 80 +- lib/isc/unix/strerror.c | 10 +- lib/isc/x86_32/include/isc/atomic.h | 17 +- lib/isccfg/include/isccfg/log.h | 8 +- lib/isccfg/include/isccfg/namedconf.h | 8 +- lib/lwres/api | 2 +- lib/lwres/context.c | 30 +- lib/lwres/context_p.h | 8 +- lib/lwres/getaddrinfo.c | 54 +- lib/lwres/getipnode.c | 82 +- lib/lwres/include/lwres/context.h | 13 +- lib/lwres/include/lwres/netdb.h.in | 8 +- lib/lwres/lwconfig.c | 31 +- lib/lwres/man/lwres.3 | 4 +- lib/lwres/man/lwres.html | 4 +- lib/lwres/man/lwres_buffer.3 | 4 +- lib/lwres/man/lwres_buffer.html | 4 +- lib/lwres/man/lwres_config.3 | 4 +- lib/lwres/man/lwres_config.html | 4 +- lib/lwres/man/lwres_context.3 | 4 +- lib/lwres/man/lwres_context.html | 4 +- lib/lwres/man/lwres_gabn.3 | 4 +- lib/lwres/man/lwres_gabn.html | 4 +- lib/lwres/man/lwres_gai_strerror.3 | 4 +- lib/lwres/man/lwres_gai_strerror.html | 4 +- lib/lwres/man/lwres_getaddrinfo.3 | 4 +- lib/lwres/man/lwres_getaddrinfo.html | 4 +- lib/lwres/man/lwres_gethostent.3 | 4 +- lib/lwres/man/lwres_gethostent.html | 4 +- lib/lwres/man/lwres_getipnode.3 | 4 +- lib/lwres/man/lwres_getipnode.html | 4 +- lib/lwres/man/lwres_getnameinfo.3 | 4 +- lib/lwres/man/lwres_getnameinfo.html | 4 +- lib/lwres/man/lwres_getrrsetbyname.3 | 4 +- lib/lwres/man/lwres_getrrsetbyname.html | 4 +- lib/lwres/man/lwres_gnba.3 | 4 +- lib/lwres/man/lwres_gnba.html | 4 +- lib/lwres/man/lwres_hstrerror.3 | 4 +- lib/lwres/man/lwres_hstrerror.html | 4 +- lib/lwres/man/lwres_inetntop.3 | 4 +- lib/lwres/man/lwres_inetntop.html | 4 +- lib/lwres/man/lwres_noop.3 | 4 +- lib/lwres/man/lwres_noop.html | 4 +- lib/lwres/man/lwres_packet.3 | 4 +- lib/lwres/man/lwres_packet.html | 4 +- lib/lwres/man/lwres_resutil.3 | 4 +- lib/lwres/man/lwres_resutil.html | 4 +- libtool.m4 | 1928 ++- ltmain.sh | 1332 +- make/rules.in | 5 +- version | 8 +- 326 files changed, 39577 insertions(+), 48692 deletions(-) delete mode 100644 doc/draft/draft-baba-dnsext-acl-reqts-01.txt delete mode 100644 doc/draft/draft-daigle-napstr-04.txt delete mode 100644 doc/draft/draft-danisch-dns-rr-smtp-03.txt delete mode 100644 doc/draft/draft-dnsext-opcode-discover-02.txt delete mode 100644 doc/draft/draft-durand-dnsop-dynreverse-00.txt create mode 100644 doc/draft/draft-ietf-6man-text-addr-representation-01.txt create mode 100644 doc/draft/draft-ietf-behave-dns64-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-2929bis-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt create mode 100644 doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-dns-tcp-requirements-02.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt delete mode 100644 doc/draft/draft-ietf-dnsext-ds-sha256-05.txt delete mode 100644 doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt delete mode 100644 doc/draft/draft-ietf-dnsext-mdns-43.txt delete mode 100644 doc/draft/draft-ietf-dnsext-nsec3-04.txt delete mode 100644 doc/draft/draft-ietf-dnsext-nsid-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt delete mode 100644 doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt delete mode 100644 doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt delete mode 100644 doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt delete mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt delete mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt delete mode 100644 doc/draft/draft-ietf-dnsext-tsig-sha-06.txt delete mode 100644 doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt create mode 100644 doc/draft/draft-ietf-dnsop-default-local-zones-09.txt delete mode 100644 doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt delete mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt delete mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt delete mode 100644 doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt delete mode 100644 doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt create mode 100644 doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt delete mode 100644 doc/draft/draft-ietf-dnsop-respsize-02.txt create mode 100644 doc/draft/draft-ietf-dnsop-respsize-06.txt delete mode 100644 doc/draft/draft-ietf-dnsop-serverid-06.txt delete mode 100644 doc/draft/draft-ietf-enum-e164-gstn-np-05.txt delete mode 100644 doc/draft/draft-ietf-ipv6-node-requirements-08.txt delete mode 100644 doc/draft/draft-ietf-secsh-dns-05.txt delete mode 100644 doc/draft/draft-ihren-dnsext-threshold-validation-00.txt delete mode 100644 doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt create mode 100644 doc/rfc/rfc1912.txt create mode 100644 doc/rfc/rfc3755.txt create mode 100644 doc/rfc/rfc4294.txt create mode 100644 doc/rfc/rfc4339.txt create mode 100644 doc/rfc/rfc4471.txt create mode 100644 doc/rfc/rfc4472.txt create mode 100644 doc/rfc/rfc4509.txt create mode 100644 doc/rfc/rfc4635.txt create mode 100644 doc/rfc/rfc4697.txt create mode 100644 doc/rfc/rfc4892.txt create mode 100644 doc/rfc/rfc4955.txt create mode 100644 doc/rfc/rfc4956.txt create mode 100644 doc/rfc/rfc5001.txt create mode 100644 doc/rfc/rfc5011.txt create mode 100644 doc/rfc/rfc5205.txt create mode 100644 doc/rfc/rfc5452.txt create mode 100644 doc/rfc/rfc5507.txt create mode 100644 doc/rfc/rfc5625.txt create mode 100644 doc/rfc/rfc5702.txt diff --git a/CHANGES b/CHANGES index 7f7978bf7b6c..fbc9bfd7cd54 100644 --- a/CHANGES +++ b/CHANGES @@ -1,28 +1,295 @@ - --- 9.4.3-P4 released --- + --- 9.4-ESV released --- + +2831. [security] Do not attempt to validate or cache + out-of-bailiwick data returned with a secure + answer; it must be re-fetched from its original + source and validated in that context. [RT #20819] + +2828. [security] Cached CNAME or DNAME RR could be returned to clients + without DNSSEC validation. [RT #20737] + +2827. [security] Bogus NXDOMAIN could be cached as if valid. [RT #20712] + +2797. [bug] Don't decrement the dispatch manager's maxbuffers. + [RT #20613] + +2790. [bug] Handle DS queries to stub zones. [RT #20440] 2772. [security] When validating, track whether pending data was from the additional section or not and only return it if validates as secure. [RT #20438] - --- 9.4.3-P3 released --- + --- 9.4-ESVb1 released --- + +2698. [cleanup] configure --enable-libbind is deprecated. [RT #20090] + +2697. [port] win32: ensure that S_IFMT, S_IFDIR, S_IFCHR and + S_IFREG are defined after including . + [RT #20309] + +2690. [bug] win32: fix isc_thread_key_getspecific() prototype. + [RT #20315] + +2689. [bug] Correctly handle snprintf result. [RT #20306] + +2688. [bug] Use INTERFACE_F_POINTTOPOINT, not IFF_POINTOPOINT, + to decide to fetch the destination address. [RT #20305] + +2681. [bug] IPSECKEY RR of gateway type 3 was not correctly + decoded. [RT #20269] + +2672. [bug] Don't enable searching in 'host' when doing reverse + lookups. [RT #20218] + +2525. [experimental] New logging category "query-errors" to provide detailed + internal information about query failures, especially + about server failures. (backported as a special + exception to the general policy) [RT #19027] + +2670. [bug] Unexpected connect failures failed to log enough + information to be useful. [RT #20205] + +2649. [bug] Set the domain for forward only zones. [RT #19944] + +2648. [port] win32: isc_time_seconds() was broken. [RT #19900] + +2646. [bug] Incorrect cleanup on error in socket.c. [RT #19987] + +2642. [bug] nsupdate could dump core on solaris when reading + improperly formatted key files. [RT #20015] 2640. [security] A specially crafted update packet will cause named to exit. [RT #20000] - --- 9.4.3-P2 released --- +2637. [func] Rationalize dnssec-signzone's signwithkey() calling. + [RT #19959] + +2635. [bug] isc_inet_ntop() incorrectly handled 0.0/16 addresses. + [RT #19716] + +2633. [bug] Handle 15 bit rand() functions. [RT #19783] + +2632. [func] util/kit.sh: warn if documentation appears to be out of + date. [RT #19922] + +2623. [bug] Named started seaches for DS non-optimally. [RT #19915] + +2621. [doc] Made copyright boilterplate consistent. [RT #19833] + +2920. [bug] Delay thawing the zone until the reload of it has + completed successfully. [RT #19750] + +2618. [bug] The sdb and sdlz db_interator_seek() methods could + loop infinitely. [RT #19847] + +2617. [bug] ifconfig.sh failed to emit an error message when + run from the wrong location. [RT #19375] + +2616. [bug] 'host' used the nameservers from resolv.conf even + when a explicit nameserver was specified. [RT #19852] + +2615. [bug] "__attribute__((unused))" was in the wrong place + for ia64 gcc builds. [RT #19854] + +2614. [port] win32: 'named -v' should automatically be executed + in the foreground. [RT #19844] + +2610. [port] sunos: Change #2363 was not complete. [RT #19796] + +2606. [bug] "delegation-only" was not being accepted in + delegation-only type zones. [RT #19717] + +2605. [bug] Accept DS responses from delegation only zones. + [RT # 19296] + +2603. [port] win32: handle .exe extension of named-checkzone and + named-comilezone argv[0] names under windows. + [RT #19767] + +2602. [port] win32: fix debugging command line build of libisccfg. + [RT #19767] + +2599. [bug] Address rapid memory growth when validation fails. + [RT #19654] + +2595. [bug] Fix unknown extended rcodes in dig. [RT #19625] + +2592. [bug] Treat "any" as a type in nsupdate. [RT #19455] + +2591. [bug] named could die when processing a update in + removed_orphaned_ds(). [RT #19507] + +2589. [bug] dns_db_unregister() failed to clear '*dbimp'. + [RT #19626] + +2586. [bug] Missing cleanup of SIG rdataset in searching a DLZ DB + or SDB. [RT #19577] + +2584. [bug] alpha: gcc optimization could break atomic operations. + [RT #19227] + +2583. [port] netbsd: provide a control to not add the compile + date to the version string, -DNO_VERSION_DATE. + +2582. [bug] Don't emit warning log message when we attempt to + remove non-existant journal. [RT #19516] + +2581. [contrib] dlz/mysql set MYSQL_OPT_RECONNECT option on connection. + Requires MySQL 5.0.19 or later. [RT #19084] 2579. [bug] DNSSEC lookaside validation failed to handle unknown algorithms. [RT #19479] - --- 9.4.3-P1 released --- +2573. [bug] Replacing a non-CNAME record with a CNAME record in a + single transaction in a signed zone failed. [RT #19397] + +2568. [bug] Report when the write to indicate a otherwise + successful start fails. [RT #19360] + +2567. [bug] dst__privstruct_writefile() could miss write errors. + write_public_key() could miss write errors. + [RT #19360] + +2564. [bug] Only take EDNS fallback steps when processing timeouts. + [RT #19405] + +2563. [bug] Dig could leak a socket causing it to wait forever + to exit. [RT #19359] + +2562. [doc] ARM: miscellaneous improvements, reorganization, + and some new content. + +2561. [doc] Add isc-config.sh(1) man page. [RT #16378] + +2557. [cleanup] PCI compliance: + * new libisc log module file + * isc_dir_chroot() now also changes the working + directory to "/". + * additional INSISTs + * additional logging when files can't be removed. + +2553. [bug] Reference leak on DNSSEC validation errors. [RT #19291] + +2552. [bug] zero-no-soa-ttl-cache was not being honoured. + [RT #19340] + +2551. [bug] Potential Reference leak on return. [RT #19341] + +2550. [bug] Check --with-openssl= finds . + [RT #19343] + +2549. [port] linux: define NR_OPEN if not currently defined. + [RT #19344] + +2547. [bug] openssl_link.c:mem_realloc() could reference an + out-of-range area of the source buffer. New public + function isc_mem_reallocate() was introduced to address + this bug. [RT #19313] + +2545. [doc] ARM: Legal hostname checking (check-names) is + for SRV RDATA too. [RT #19304] + +2544. [cleanup] Removed unused structure members in adb.c. [RT #19225] + +2542. [doc] Update the description of dig +adflag. [RT #19290] + +2539. [security] Update the interaction between recursion, allow-query, + allow-query-cache and allow-recursion. [RT #19198] + +2536. [cleanup] Silence some warnings when -Werror=format-security is + specified. [RT #19083] + +2535. [bug] dig +showsearch and +trace interacted badly. [RT #19091] + +2532. [bug] dig: check the question section of the response to + see if it matches the asked question. [RT #18495] + +2531. [bug] Change #2207 was incomplete. [RT #19098] + +2529. [cleanup] Upgrade libtool to silence complaints from recent + version of autoconf. [RT #18657] + +2528. [cleanup] Silence spurious configure warning about + --datarootdir [RT #19096] + +2527. [bug] named could reuse cache on reload with + enabling/disabling validation. [RT #19119] + +2523. [bug] Random type rdata freed by dns_nsec_typepresent(). + [RT #19112] 2522. [security] Handle -1 from DSA_do_verify(). +2521. [bug] Improve epoll cross compilation support. [RT #19047] + +2519. [bug] dig/host with -4 or -6 didn't work if more than two + nameserver addresses of the excluded address family + preceded in resolv.conf. [RT #19081] + +2517. [bug] dig +trace with -4 or -6 failed when it chose a + nameserver address of the excluded address type. + [RT #18843] + +2516. [bug] glue sort for responses was performed even when not + needed. [RT #19039] + +2514. [bug] dig/host failed with -4 or -6 when resolv.conf contains + a nameserver of the excluded address family. + [RT #18848] + +2511. [cleanup] dns_rdata_tofmttext() add const to linebreak. + [RT #18885] + +2510. [bug] "dig +sigchase" could trigger REQUIRE failures. + [RT #19033] + +2509. [bug] Specifying a fixed query source port was broken. + [RT #19051] + +2506. [port] solaris: Check at configure time if + hack_shutup_pthreadonceinit is needed. [RT #19037] + +2505. [port] Treat amd64 similarly to x86_64 when determining + atomic operation support. [RT #19031] + +2504. [bug] Address race condition in the socket code. [RT #18899] + +2503. [port] linux: improve compatibility with Linux Standard + Base. [RT #18793] + +2500. [contrib] contrib/sdb/pgsql/zonetodb.c called non-existent + function. [RT #18582] + +2499. [port] solaris: lib/lwres/getaddrinfo.c namespace clash. + [RT #18837] + 2498. [bug] Removed a bogus function argument used with ISC_SOCKET_USE_POLLWATCH: it could cause compiler warning or crash named with the debug 1 level of logging. [RT #18917] +2495. [bug] Tighten RRSIG checks. [RT #18795] + +2494. [bug] dns/sdlz.h and dns/dlz.h were not being installed. + [RT #18826] + +2487. [bug] Give TCP connections longer to complete. [RT #18675] + +2485. [bug] Change update's the handling of obscured RRSIG + records. Not all orphand DS records were being + removed. [RT #18828] + +2479. [bug] xfrout:covers was not properly initalized. [RT #18801] + +2478. [bug] 'addresses' could be used uninitalized in + configure_forward(). [RT #18800] + +2476. [doc] ARM: improve documentation for max-journal-size and + ixfr-from-differences. [RT #15909] [RT #18541] + +2400. [bug] Log if kqueue()/epoll_create()/open(/dev/poll) fails. + [RT #18297] + --- 9.4.3 released --- 2490. [port] aix: work around a kernel bug where IPV6_RECVPKTINFO @@ -38,7 +305,7 @@ 2473. [port] linux: raise the limit on open files to the possible maximum value before spawning threads; 'files' - specified in named.conf doesn't seem to work with + specified in named.conf doesn't seem to work with threads as expected. [RT #18784] 2472. [port] linux: check the number of available cpu's before @@ -61,10 +328,11 @@ 2465. [bug] Adb's handling of lame addresses was different for IPv4 and IPv6. [RT #18738] -2463. [port] linux: POSIX doesn't include the IPv6 Advanced Socket +2463. [port] linux: POSIX doesn't include the IPv6 Advanced Socket API and glibc hides parts of the IPv6 Advanced Socket API as a result. This is stupid as it breaks how the - two halves (Basic and Advanced) of the IPv6 Socket API were designed to be used but we have to live with it. + two halves (Basic and Advanced) of the IPv6 Socket API + were designed to be used but we have to live with it. Define _GNU_SOURCE to pull in the IPv6 Advanced Socket API. [RT #18388] @@ -170,6 +438,10 @@ for select(). To enable this, set ISC_SOCKET_MAXSOCKETS at compilation time. [RT #18433] + Note: with changes #2469 and #2421 above, there is no + need to tweak ISC_SOCKET_MAXSOCKETS at compilation time + any more. + 2410. [bug] Correctly delete m_versionInfo. [RT #18432] 2408. [bug] A duplicate TCP dispatch event could be sent, which @@ -241,7 +513,7 @@ 2380. [bug] dns_view_find() was not returning NXDOMAIN/NXRRSET proofs which, in turn, caused validation failures for insecure zones immediately below a secure zone - the server was authoritative for. [RT #18112] + the server was authoritative for. [RT #18112] 2379. [contrib] queryperf/gen-data-queryperf.py: removed redundant TLDs and supported RRs with TTLs [RT #17972] diff --git a/COPYRIGHT b/COPYRIGHT index 8d6a0cef1378..a41439ebbf43 100644 --- a/COPYRIGHT +++ b/COPYRIGHT @@ -1,4 +1,4 @@ -Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC") Copyright (C) 1996-2003 Internet Software Consortium. Permission to use, copy, modify, and/or distribute this software for any @@ -13,7 +13,7 @@ LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -$Id: COPYRIGHT,v 1.9.18.5 2008/01/02 23:46:02 tbox Exp $ +$Id: COPYRIGHT,v 1.9.18.7 2010/01/07 23:46:07 tbox Exp $ Portions Copyright (C) 1996-2001 Nominum, Inc. diff --git a/FAQ b/FAQ index 2c333bef3b24..a2d1686c4eb5 100644 --- a/FAQ +++ b/FAQ @@ -1,6 +1,6 @@ Frequently Asked Questions about BIND 9 -Copyright © 2004-2008 Internet Systems Consortium, Inc. ("ISC") +Copyright © 2004-2009 Internet Systems Consortium, Inc. ("ISC") Copyright © 2000-2003 Internet Software Consortium. @@ -153,24 +153,29 @@ A: BIND 9.3 and later: Use TSIG to select the appropriate view. Master 10.0.1.1: key "external" { - algorithm hmac-md5; - secret "xxxxxxxx"; + algorithm hmac-sha256; + secret "xxxxxxxxxxxxxxxxxxxxxxxx"; }; view "internal" { - match-clients { !key external; 10.0.1/24; }; + match-clients { !key external; // reject message ment for the + // external view. + 10.0.1/24; }; // accept from these addresses. ... }; view "external" { match-clients { key external; any; }; - server 10.0.1.2 { keys external; }; + server 10.0.1.2 { keys external; }; // tag messages from the + // external view to the + // other servers for the + // view. recursion no; ... }; Slave 10.0.1.2: key "external" { - algorithm hmac-md5; - secret "xxxxxxxx"; + algorithm hmac-sha256; + secret "xxxxxxxxxxxxxxxxxxxxxxxx"; }; view "internal" { match-clients { !key external; 10.0.1/24; }; @@ -220,13 +225,13 @@ A: You choose one view to be master and the second a slave and transfer Master 10.0.1.1: key "external" { - algorithm hmac-md5; - secret "xxxxxxxx"; + algorithm hmac-sha256; + secret "xxxxxxxxxxxxxxxxxxxxxxxx"; }; key "mykey" { - algorithm hmac-md5; - secret "yyyyyyyy"; + algorithm hmac-sha256; + secret "yyyyyyyyyyyyyyyyyyyyyyyy"; }; view "internal" { @@ -600,7 +605,7 @@ Q: Why do queries for NSEC3 records fail to return the NSEC3 record? A: NSEC3 records are strictly meta data and can only be returned in the authority section. This is done so that signing the zone using NSEC3 - records does not bring names into existance that do not exist in the + records does not bring names into existence that do not exist in the unsigned version of the zone. 5. Operating-System Specific Questions @@ -825,7 +830,6 @@ A: /dev/random is not configured. Use rndcontrol(8) to tell the kernel to use certain interrupts as a source of random events. You can make this permanent by setting rand_irqs in /etc/rc.conf. - /etc/rc.conf rand_irqs="3 14 15" See also . diff --git a/FAQ.xml b/FAQ.xml index b624d06d5341..08aa4e7f70ec 100644 --- a/FAQ.xml +++ b/FAQ.xml @@ -1,7 +1,7 @@ - +
Frequently Asked Questions about BIND 9 @@ -28,6 +28,7 @@ 2006 2007 2008 + 2009 Internet Systems Consortium, Inc. ("ISC") @@ -318,24 +319,29 @@ Slave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias) Master 10.0.1.1: key "external" { - algorithm hmac-md5; - secret "xxxxxxxx"; + algorithm hmac-sha256; + secret "xxxxxxxxxxxxxxxxxxxxxxxx"; }; view "internal" { - match-clients { !key external; 10.0.1/24; }; + match-clients { !key external; // reject message ment for the + // external view. + 10.0.1/24; }; // accept from these addresses. ... }; view "external" { match-clients { key external; any; }; - server 10.0.1.2 { keys external; }; + server 10.0.1.2 { keys external; }; // tag messages from the + // external view to the + // other servers for the + // view. recursion no; ... }; Slave 10.0.1.2: key "external" { - algorithm hmac-md5; - secret "xxxxxxxx"; + algorithm hmac-sha256; + secret "xxxxxxxxxxxxxxxxxxxxxxxx"; }; view "internal" { match-clients { !key external; 10.0.1/24; }; @@ -423,13 +429,13 @@ named-checkzone example.com tmp Master 10.0.1.1: key "external" { - algorithm hmac-md5; - secret "xxxxxxxx"; + algorithm hmac-sha256; + secret "xxxxxxxxxxxxxxxxxxxxxxxx"; }; key "mykey" { - algorithm hmac-md5; - secret "yyyyyyyy"; + algorithm hmac-sha256; + secret "yyyyyyyyyyyyyyyyyyyyyyyy"; }; view "internal" { @@ -1067,7 +1073,7 @@ empty: NSEC3 records are strictly meta data and can only be returned in the authority section. This is done so that signing the zone using NSEC3 records does not bring names - into existance that do not exist in the unsigned version + into existence that do not exist in the unsigned version of the zone. @@ -1470,7 +1476,6 @@ options { -/etc/rc.conf rand_irqs="3 14 15" diff --git a/Makefile.in b/Makefile.in index 9ff0f6493292..7e029eb41dc7 100644 --- a/Makefile.in +++ b/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004-2007, 2009 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 1998-2002 Internet Software Consortium. # # Permission to use, copy, modify, and/or distribute this software for any @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: Makefile.in,v 1.43.18.6 2007/09/03 23:46:21 tbox Exp $ +# $Id: Makefile.in,v 1.43.18.8 2009/02/20 23:46:01 tbox Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -24,6 +24,12 @@ top_srcdir = @top_srcdir@ SUBDIRS = make lib bin doc @LIBBIND@ TARGETS = +MANPAGES = isc-config.sh.1 + +HTMLPAGES = isc-config.sh.html + +MANOBJS = ${MANPAGES} ${HTMLPAGES} + @BIND9_MAKE_RULES@ distclean:: @@ -43,12 +49,19 @@ distclean:: maintainer-clean:: rm -f configure +docclean manclean maintainer-clean:: + rm -f ${MANOBJS} + +doc man:: ${MANOBJS} + installdirs: $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${bindir} \ ${DESTDIR}${localstatedir}/run ${DESTDIR}${sysconfdir} + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man1 install:: isc-config.sh installdirs ${INSTALL_SCRIPT} isc-config.sh ${DESTDIR}${bindir} + ${INSTALL_DATA} ${srcdir}/isc-config.sh.1 ${DESTDIR}${mandir}/man1 tags: rm -f TAGS diff --git a/README b/README index 0a0bc9e86f6d..1b584fd6e913 100644 --- a/README +++ b/README @@ -27,8 +27,8 @@ BIND 9 - Improved Portability Architecture - BIND version 9 development has been underwritten by the following - organizations: + BIND version 9 development has been under written by the following + organisations: Sun Microsystems, Inc. Hewlett Packard @@ -42,6 +42,16 @@ BIND 9 Stichting NLnet - NLnet Foundation Nominum, Inc. +BIND 9.4-ESV (Extended Support Version) + + BIND 9.4-ESV is the Extended Support Version of BIND 9.4 + and incorporates the final maintenance release fixing bugs + in BIND 9.4.3. + + BIND 9.4-ESV will be supported until December 31, 2010, at + which time you will need to upgrade to the current release + of BIND. + BIND 9.4.3 BIND 9.4.3 is a maintenance release, fixing bugs in 9.4.2. @@ -67,7 +77,7 @@ BIND 9.4.0 Implemented "additional section caching" (or "acache"), an internal cache framework for additional section content to improve response performance. Several configuration options - were provided to control the behavior. + were provided to control the behaviour. New notify type 'master-only'. Enable notify for master zones only. @@ -76,13 +86,14 @@ BIND 9.4.0 rndc now allows addresses to be set in the server clauses. - New option "allow-query-cache". This lets allow-query be - used to specify the default zone access level rather than - having to have every zone override the global value. - allow-query-cache can be set at both the options and view - levels. If allow-query-cache is not set then allow-recursion - is used if set, otherwise allow-query is used if set, otherwise - the default (localhost; localnets;) is used. + New option "allow-query-cache". This lets "allow-query" + be used to specify the default zone access level rather + than having to have every zone override the global value. + "allow-query-cache" can be set at both the options and view + levels. If "allow-query-cache" is not set then "allow-recursion" + is used if set, otherwise "allow-query" is used if set + unless "recursion no;" is set in which case "none;" is used, + otherwise the default (localhost; localnets;) is used. rndc: the source address can now be specified. @@ -150,12 +161,12 @@ BIND 9.4.0 options for dnssec-signzone specify the input and output formats. - dnssec-signzone can now randomize signature end times + dnssec-signzone can now randomise signature end times (dnssec-signzone -j jitter). Add support for CH A record. - Add additional zone data consistancy checks. named-checkzone + Add additional zone data consistency checks. named-checkzone has extended checking of NS, MX and SRV record and the hosts they reference. named has extended post zone load checks. New zone options: check-mx and integrity-check. diff --git a/README.idnkit b/README.idnkit index 316f8793bc6b..47477d8f906a 100644 --- a/README.idnkit +++ b/README.idnkit @@ -55,7 +55,7 @@ at least specify `--with-idn' option to enable IDN support. `--with-libiconv' assumes that your C compiler has `-R' option, and that the option adds the specified run-time path - to an exacutable binary. If `-R' option of your compiler has + to an executable binary. If `-R' option of your compiler has different meaning, or your compiler lacks the option, you should use `--with-iconv' option instead. Binary command without run-time path information might be unexecutable. @@ -68,7 +68,7 @@ at least specify `--with-idn' option to enable IDN support. specified, `--with-iconv' is prior to `--with-libiconv'. --with-iconv=ICONV_LIBSPEC - If your libc doens't provide iconv(), you need to specify the + If your libc doesn't provide iconv(), you need to specify the library containing iconv() with this option. `ICONV_LIBSPEC' is the argument(s) to `cc' or `ld' to link the library, for example, `--with-iconv="-L/usr/local/lib -liconv"'. @@ -82,7 +82,7 @@ at least specify `--with-idn' option to enable IDN support. this option is not specified, `-L${PREFIX}/lib -lidnkit' is assumed, where ${PREFIX} is the installation prefix specified with `--with-idn' option above. You may need to use this - option to specify extra argments, for example, + option to specify extra arguments, for example, `--with-idnlib="-L/usr/local/lib -R/usr/local/lib -lidnkit"'. Please consult `README' for other configuration options. @@ -109,4 +109,4 @@ about idnkit and this patch. Bug reports and comments on this kit should be sent to mdnkit-bugs@nic.ad.jp and idn-cmt@nic.ad.jp, respectively. -; $Id: README.idnkit,v 1.2.2.2 2005/09/12 02:12:08 marka Exp $ +; $Id: README.idnkit,v 1.2.2.3 2009/01/19 00:36:25 marka Exp $ diff --git a/acconfig.h b/acconfig.h index e8f7d52c0578..ab8b5e9fe450 100644 --- a/acconfig.h +++ b/acconfig.h @@ -1,8 +1,8 @@ /* - * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005, 2008 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: acconfig.h,v 1.44.18.5 2005/04/29 00:15:20 marka Exp $ */ +/* $Id: acconfig.h,v 1.44.18.7 2008/12/01 23:45:56 tbox Exp $ */ /*! \file */ @@ -25,9 +25,6 @@ ***/ @TOP@ -/** define to `int' if doesn't define. */ -#undef ssize_t - /** define on DEC OSF to enable 4.4BSD style sa_len support */ #undef _SOCKADDR_LEN @@ -61,9 +58,6 @@ /** define if you have the NET_RT_IFLIST sysctl variable and sys/sysctl.h */ #undef HAVE_IFLIST_SYSCTL -/** define if chroot() is available */ -#undef HAVE_CHROOT - /** define if tzset() is available */ #undef HAVE_TZSET @@ -115,7 +109,7 @@ int sigwait(const unsigned int *set, int *sig); * The silly continuation line is to keep configure from * commenting out the #undef. */ - + #undef \ va_start #define va_start(ap, last) \ diff --git a/bin/check/check-tool.c b/bin/check/check-tool.c index 2136a63a7588..fe48ff3345a7 100644 --- a/bin/check/check-tool.c +++ b/bin/check/check-tool.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2002 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check-tool.c,v 1.10.18.20 2008/10/24 01:43:17 tbox Exp $ */ +/* $Id: check-tool.c,v 1.10.18.23 2009/09/24 21:38:50 jinmei Exp $ */ /*! \file */ @@ -105,6 +105,7 @@ static isc_logcategory_t categories[] = { { "queries", 0 }, { "unmatched", 0 }, { "update-security", 0 }, + { "query-errors", 0 }, { NULL, 0 } }; @@ -156,7 +157,7 @@ checkns(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner, cur->ai_next != NULL) cur = cur->ai_next; if (cur != NULL && cur->ai_canonname != NULL && - strcasecmp(ai->ai_canonname, namebuf) != 0) { + strcasecmp(cur->ai_canonname, namebuf) != 0) { dns_zone_log(zone, ISC_LOG_ERROR, "%s/NS '%s' (out of zone) " "is a CNAME (illegal)", diff --git a/bin/check/named-checkconf.8 b/bin/check/named-checkconf.8 index 364e6b977101..c3f8596fd6b2 100644 --- a/bin/check/named-checkconf.8 +++ b/bin/check/named-checkconf.8 @@ -1,7 +1,7 @@ .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2002 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named-checkconf.8,v 1.16.18.13 2007/06/20 02:26:58 marka Exp $ +.\" $Id: named-checkconf.8,v 1.16.18.14 2009/07/11 01:31:43 tbox Exp $ .\" .hy 0 .ad l diff --git a/bin/check/named-checkconf.c b/bin/check/named-checkconf.c index 96efd794661c..0b6391cb8f7b 100644 --- a/bin/check/named-checkconf.c +++ b/bin/check/named-checkconf.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2007, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named-checkconf.c,v 1.28.18.16 2007/11/26 23:46:18 tbox Exp $ */ +/* $Id: named-checkconf.c,v 1.28.18.18 2009/02/16 23:46:03 tbox Exp $ */ /*! \file */ @@ -59,9 +59,9 @@ isc_log_t *logc = NULL; /*% usage */ static void usage(void) { - fprintf(stderr, "usage: named-checkconf [-j] [-v] [-z] [-t directory] " + fprintf(stderr, "usage: named-checkconf [-j] [-v] [-z] [-t directory] " "[named.conf]\n"); - exit(1); + exit(1); } /*% directory callback */ @@ -171,9 +171,9 @@ configure_zone(const char *vclass, const char *view, zname = cfg_obj_asstring(cfg_tuple_get(zconfig, "name")); classobj = cfg_tuple_get(zconfig, "class"); - if (!cfg_obj_isstring(classobj)) - zclass = vclass; - else + if (!cfg_obj_isstring(classobj)) + zclass = vclass; + else zclass = cfg_obj_asstring(classobj); zoptions = cfg_tuple_get(zconfig, "options"); @@ -192,9 +192,9 @@ configure_zone(const char *vclass, const char *view, return (ISC_R_FAILURE); if (strcasecmp(cfg_obj_asstring(typeobj), "master") != 0) return (ISC_R_SUCCESS); - cfg_map_get(zoptions, "database", &dbobj); - if (dbobj != NULL) - return (ISC_R_SUCCESS); + cfg_map_get(zoptions, "database", &dbobj); + if (dbobj != NULL) + return (ISC_R_SUCCESS); cfg_map_get(zoptions, "file", &fileobj); if (fileobj == NULL) return (ISC_R_FAILURE); @@ -285,8 +285,8 @@ configure_zone(const char *vclass, const char *view, } else INSIST(0); } else { - zone_options |= DNS_ZONEOPT_CHECKNAMES; - zone_options |= DNS_ZONEOPT_CHECKNAMESFAIL; + zone_options |= DNS_ZONEOPT_CHECKNAMES; + zone_options |= DNS_ZONEOPT_CHECKNAMESFAIL; } masterformat = dns_masterformat_text; @@ -397,7 +397,7 @@ main(int argc, char **argv) { int exit_status = 0; isc_entropy_t *ectx = NULL; isc_boolean_t load_zones = ISC_FALSE; - + while ((c = isc_commandline_parse(argc, argv, "djt:vz")) != EOF) { switch (c) { case 'd': @@ -415,12 +415,6 @@ main(int argc, char **argv) { isc_result_totext(result)); exit(1); } - result = isc_dir_chdir("/"); - if (result != ISC_R_SUCCESS) { - fprintf(stderr, "isc_dir_chdir: %s\n", - isc_result_totext(result)); - exit(1); - } break; case 'v': diff --git a/bin/check/named-checkconf.html b/bin/check/named-checkconf.html index 910df0d16090..74c716fde57c 100644 --- a/bin/check/named-checkconf.html +++ b/bin/check/named-checkconf.html @@ -2,7 +2,7 @@ - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC") - Copyright (C) 2000-2002 Internet Software Consortium. - - - Permission to use, copy, modify, and distribute this software for any + - Permission to use, copy, modify, and/or distribute this software for any - purpose with or without fee is hereby granted, provided that the above - copyright notice and this permission notice appear in all copies. - @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> - + diff --git a/bin/check/named-checkzone.8 b/bin/check/named-checkzone.8 index bd538ac6c5d9..f1ba60eb282f 100644 --- a/bin/check/named-checkzone.8 +++ b/bin/check/named-checkzone.8 @@ -1,7 +1,7 @@ -.\" Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2004-2007, 2009 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2002 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named-checkzone.8,v 1.18.18.23 2007/06/20 02:26:58 marka Exp $ +.\" $Id: named-checkzone.8,v 1.18.18.25 2009/07/11 01:31:43 tbox Exp $ .\" .hy 0 .ad l @@ -77,7 +77,7 @@ When loading the zone file read the journal if it exists. .PP \-c \fIclass\fR .RS 4 -Specify the class of the zone. If not specified "IN" is assumed. +Specify the class of the zone. If not specified, "IN" is assumed. .RE .PP \-i \fImode\fR @@ -263,7 +263,7 @@ BIND 9 Administrator Reference Manual. .PP Internet Systems Consortium .SH "COPYRIGHT" -Copyright \(co 2004\-2007 Internet Systems Consortium, Inc. ("ISC") +Copyright \(co 2004\-2007, 2009 Internet Systems Consortium, Inc. ("ISC") .br Copyright \(co 2000\-2002 Internet Software Consortium. .br diff --git a/bin/check/named-checkzone.c b/bin/check/named-checkzone.c index f16053bcbb11..77444856c7a4 100644 --- a/bin/check/named-checkzone.c +++ b/bin/check/named-checkzone.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named-checkzone.c,v 1.29.18.21 2008/10/24 01:43:17 tbox Exp $ */ +/* $Id: named-checkzone.c,v 1.29.18.24 2009/05/29 02:19:20 marka Exp $ */ /*! \file */ @@ -122,9 +122,13 @@ main(int argc, char **argv) { */ if (strncmp(prog_name, "lt-", 3) == 0) prog_name += 3; - if (strcmp(prog_name, "named-checkzone") == 0) + +#define PROGCMP(X) \ + (strcasecmp(prog_name, X) == 0 || strcasecmp(prog_name, X ".exe") == 0) + + if (PROGCMP("named-checkzone")) progmode = progmode_check; - else if (strcmp(prog_name, "named-compilezone") == 0) + else if (PROGCMP("named-compilezone")) progmode = progmode_compile; else INSIST(0); @@ -265,12 +269,6 @@ main(int argc, char **argv) { isc_result_totext(result)); exit(1); } - result = isc_dir_chdir("/"); - if (result != ISC_R_SUCCESS) { - fprintf(stderr, "isc_dir_chdir: %s\n", - isc_result_totext(result)); - exit(1); - } break; case 's': diff --git a/bin/check/named-checkzone.docbook b/bin/check/named-checkzone.docbook index 11b85ef373ae..5153a82f1ee4 100644 --- a/bin/check/named-checkzone.docbook +++ b/bin/check/named-checkzone.docbook @@ -2,7 +2,7 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> - + June 13, 2000 @@ -36,6 +36,7 @@ 2005 2006 2007 + 2009 Internet Systems Consortium, Inc. ("ISC") @@ -168,7 +169,7 @@ -c class - Specify the class of the zone. If not specified "IN" is assumed. + Specify the class of the zone. If not specified, "IN" is assumed. diff --git a/bin/check/named-checkzone.html b/bin/check/named-checkzone.html index 0e1015d30c12..2114b59f3ccd 100644 --- a/bin/check/named-checkzone.html +++ b/bin/check/named-checkzone.html @@ -1,8 +1,8 @@ - + @@ -33,7 +33,7 @@

named-compilezone [-d] [-j] [-q] [-v] [-c class] [-C mode] [-f format] [-F format] [-i mode] [-k mode] [-m mode] [-n mode] [-o filename] [-s style] [-t directory] [-w directory] [-D] [-W mode] {zonename} {filename}

-

DESCRIPTION

+

DESCRIPTION

named-checkzone checks the syntax and integrity of a zone file. It performs the same checks as named does when loading a @@ -53,7 +53,7 @@

-

OPTIONS

+

OPTIONS

-d

@@ -74,7 +74,7 @@

-c class

- Specify the class of the zone. If not specified "IN" is assumed. + Specify the class of the zone. If not specified, "IN" is assumed.

-i mode
@@ -233,14 +233,14 @@
-

RETURN VALUES

+

RETURN VALUES

named-checkzone returns an exit status of 1 if errors were detected and 0 otherwise.

-

SEE ALSO

+

SEE ALSO

named(8), named-checkconf(8), RFC 1035, @@ -248,7 +248,7 @@

-

AUTHOR

+

AUTHOR

Internet Systems Consortium

diff --git a/bin/dig/dig.1 b/bin/dig/dig.1 index c9df21eaf4b0..24fe44231cbf 100644 --- a/bin/dig/dig.1 +++ b/bin/dig/dig.1 @@ -1,7 +1,7 @@ -.\" Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2003 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: dig.1,v 1.23.18.24 2008/10/14 01:30:11 tbox Exp $ +.\" $Id: dig.1,v 1.23.18.27 2009/07/11 01:31:43 tbox Exp $ .\" .hy 0 .ad l @@ -291,7 +291,7 @@ A synonym for .PP \fB+[no]adflag\fR .RS 4 -Set [do not set] the AD (authentic data) bit in the query. The AD bit currently has a standard meaning only in responses, not in queries, but the ability to set the bit in the query is provided for completeness. +Set [do not set] the AD (authentic data) bit in the query. This requests the server to return whether all of the answer and authority sections have all been validated as secure according to the security policy of the server. AD=1 indicates that all records have been validated as secure and the answer is not from a OPT\-OUT range. AD=0 indicate that some part of the answer was insecure or not validated. .RE .PP \fB+[no]cdflag\fR @@ -480,7 +480,7 @@ Chase DNSSEC signature chains. Requires dig be compiled with \-DDIG_SIGCHASE. Specifies a file containing trusted keys to be used with \fB+sigchase\fR. Each DNSKEY record must be on its own line. .sp -If not specified +If not specified, \fBdig\fR will look for \fI/etc/trusted\-key.key\fR @@ -557,7 +557,7 @@ RFC1035. .PP There are probably too many query options. .SH "COPYRIGHT" -Copyright \(co 2004\-2008 Internet Systems Consortium, Inc. ("ISC") +Copyright \(co 2004\-2009 Internet Systems Consortium, Inc. ("ISC") .br Copyright \(co 2000\-2003 Internet Software Consortium. .br diff --git a/bin/dig/dig.c b/bin/dig/dig.c index 5cde9c430e60..4cc40c394231 100644 --- a/bin/dig/dig.c +++ b/bin/dig/dig.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dig.c,v 1.186.18.33 2008/10/15 02:19:18 marka Exp $ */ +/* $Id: dig.c,v 1.186.18.37 2009/05/06 10:21:00 fdupont Exp $ */ /*! \file */ @@ -111,6 +111,24 @@ static const char * const rcodetext[] = { "BADVERS" }; +/*% safe rcodetext[] */ +static char * +rcode_totext(dns_rcode_t rcode) +{ + static char buf[sizeof("?65535")]; + union { + const char *consttext; + char *deconsttext; + } totext; + + if (rcode >= (sizeof(rcodetext)/sizeof(rcodetext[0]))) { + snprintf(buf, sizeof(buf), "?%u", rcode); + totext.deconsttext = buf; + } else + totext.consttext = rcodetext[rcode]; + return totext.deconsttext; +} + /*% print usage */ static void print_usage(FILE *fp) { @@ -468,7 +486,8 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { if (headers) { printf(";; ->>HEADER<<- opcode: %s, status: %s, " "id: %u\n", - opcodetext[msg->opcode], rcodetext[msg->rcode], + opcodetext[msg->opcode], + rcode_totext(msg->rcode), msg->id); printf(";; flags:"); if ((msg->flags & DNS_MESSAGEFLAG_QR) != 0) @@ -800,7 +819,9 @@ plus_option(char *option, isc_boolean_t is_batchfile, switch (cmd[1]) { case 'e': /* defname */ FULLCHECK("defname"); - usesearch = state; + if (!lookup->trace) { + usesearch = state; + } break; case 'n': /* dnssec */ FULLCHECK("dnssec"); @@ -842,7 +863,7 @@ plus_option(char *option, isc_boolean_t is_batchfile, lookup->identify = state; break; case 'g': /* ignore */ - default: /* Inherets default for compatibility */ + default: /* Inherits default for compatibility */ FULLCHECK("ignore"); lookup->ignore = ISC_TRUE; } @@ -928,7 +949,9 @@ plus_option(char *option, isc_boolean_t is_batchfile, switch (cmd[1]) { case 'e': /* search */ FULLCHECK("search"); - usesearch = state; + if (!lookup->trace) { + usesearch = state; + } break; case 'h': if (cmd[2] != 'o') @@ -949,8 +972,10 @@ plus_option(char *option, isc_boolean_t is_batchfile, break; case 'w': /* showsearch */ FULLCHECK("showsearch"); - showsearch = state; - usesearch = state; + if (!lookup->trace) { + showsearch = state; + usesearch = state; + } break; default: goto invalid_option; @@ -1009,6 +1034,7 @@ plus_option(char *option, isc_boolean_t is_batchfile, lookup->section_additional = ISC_FALSE; lookup->section_authority = ISC_TRUE; lookup->section_question = ISC_FALSE; + usesearch = ISC_FALSE; } break; case 'i': /* tries */ diff --git a/bin/dig/dig.docbook b/bin/dig/dig.docbook index 92be18050cf0..17bf0d809ac6 100644 --- a/bin/dig/dig.docbook +++ b/bin/dig/dig.docbook @@ -2,7 +2,7 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> - + @@ -43,6 +43,7 @@ 2006 2007 2008 + 2009 Internet Systems Consortium, Inc. ("ISC") @@ -449,17 +450,19 @@ - - - Set [do not set] the AD (authentic data) bit in the query. The - AD bit - currently has a standard meaning only in responses, not in - queries, - but the ability to set the bit in the query is provided for - completeness. - - - + + + Set [do not set] the AD (authentic data) bit in the + query. This requests the server to return whether + all of the answer and authority sections have all + been validated as secure according to the security + policy of the server. AD=1 indicates that all records + have been validated as secure and the answer is not + from a OPT-OUT range. AD=0 indicate that some part + of the answer was insecure or not validated. + + + @@ -816,7 +819,7 @@ on its own line. - If not specified dig will look for + If not specified, dig will look for /etc/trusted-key.key then trusted-key.key in the current directory. diff --git a/bin/dig/dig.html b/bin/dig/dig.html index a8c459447f12..ab94bf1e96e7 100644 --- a/bin/dig/dig.html +++ b/bin/dig/dig.html @@ -1,8 +1,8 @@ - + @@ -34,7 +34,7 @@

dig [global-queryopt...] [query...]

-

DESCRIPTION

+

DESCRIPTION

dig (domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and @@ -80,7 +80,7 @@

-

SIMPLE USAGE

+

SIMPLE USAGE

A typical invocation of dig looks like:

@@ -126,7 +126,7 @@

-

OPTIONS

+

OPTIONS

The -b option sets the source IP address of the query to address. This must be a valid @@ -230,7 +230,7 @@

-

QUERY OPTIONS

+

QUERY OPTIONS

dig provides a number of query options which affect the way in which lookups are made and the results displayed. Some of @@ -308,13 +308,15 @@

+[no]adflag

- Set [do not set] the AD (authentic data) bit in the query. The - AD bit - currently has a standard meaning only in responses, not in - queries, - but the ability to set the bit in the query is provided for - completeness. -

+ Set [do not set] the AD (authentic data) bit in the + query. This requests the server to return whether + all of the answer and authority sections have all + been validated as secure according to the security + policy of the server. AD=1 indicates that all records + have been validated as secure and the answer is not + from a OPT-OUT range. AD=0 indicate that some part + of the answer was insecure or not validated. +

+[no]cdflag

Set [do not set] the CD (checking disabled) bit in the query. @@ -529,7 +531,7 @@ on its own line.

- If not specified dig will look for + If not specified, dig will look for /etc/trusted-key.key then trusted-key.key in the current directory.

@@ -549,7 +551,7 @@

-

MULTIPLE QUERIES

+

MULTIPLE QUERIES

The BIND 9 implementation of dig supports @@ -595,7 +597,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr

-

IDN SUPPORT

+

IDN SUPPORT

If dig has been built with IDN (internationalized domain name) support, it can accept and display non-ASCII domain names. @@ -609,14 +611,14 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr

-

FILES

+

FILES

/etc/resolv.conf

${HOME}/.digrc

-

SEE ALSO

+

SEE ALSO

host(1), named(8), dnssec-keygen(8), @@ -624,7 +626,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr

-

BUGS

+

BUGS

There are probably too many query options.

diff --git a/bin/dig/dighost.c b/bin/dig/dighost.c index 8736c0cc75c5..a06c90a3db90 100644 --- a/bin/dig/dighost.c +++ b/bin/dig/dighost.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dighost.c,v 1.259.18.49 2008/07/23 23:33:02 marka Exp $ */ +/* $Id: dighost.c,v 1.259.18.58 2009/06/24 03:44:52 marka Exp $ */ /*! \file * \note @@ -583,6 +583,11 @@ copy_server_list(lwres_conf_t *confdata, dig_serverlist_t *dest) { for (i = 0; i < confdata->nsnext; i++) { af = addr2af(confdata->nameservers[i].family); + if (af == AF_INET && !have_ipv4) + continue; + if (af == AF_INET6 && !have_ipv6) + continue; + lwres_net_ntop(af, confdata->nameservers[i].address, tmp, sizeof(tmp)); newsrv = make_server(tmp, tmp); @@ -770,7 +775,7 @@ make_empty_lookup(void) { * the query list, since it will be regenerated by the setup_lookup() * function, nor does it queue up the new lookup for processing. * Caution: If you don't clone the servers, you MUST clone the server - * list seperately from somewhere else, or construct it by hand. + * list separately from somewhere else, or construct it by hand. */ dig_lookup_t * clone_lookup(dig_lookup_t *lookold, isc_boolean_t servers) { @@ -1004,10 +1009,18 @@ void setup_system(void) { dig_searchlist_t *domain = NULL; lwres_result_t lwresult; + unsigned int lwresflags; debug("setup_system()"); - lwresult = lwres_context_create(&lwctx, mctx, mem_alloc, mem_free, 1); + lwresflags = LWRES_CONTEXT_SERVERMODE; + if (have_ipv4) + lwresflags |= LWRES_CONTEXT_USEIPV4; + if (have_ipv6) + lwresflags |= LWRES_CONTEXT_USEIPV6; + + lwresult = lwres_context_create(&lwctx, mctx, mem_alloc, mem_free, + lwresflags); if (lwresult != LWRES_R_SUCCESS) fatal("lwres_context_create failed"); @@ -1033,8 +1046,12 @@ setup_system(void) { debug("ndots is %d.", ndots); } + /* If user doesn't specify server use nameservers from resolv.conf. */ + if (ISC_LIST_EMPTY(server_list)) + copy_server_list(lwconf, &server_list); + /* If we don't find a nameserver fall back to localhost */ - if (lwconf->nsnext == 0) { + if (ISC_LIST_EMPTY(server_list)) { if (have_ipv4) { lwresult = add_nameserver(lwconf, "127.0.0.1", AF_INET); if (lwresult != ISC_R_SUCCESS) @@ -1045,10 +1062,9 @@ setup_system(void) { if (lwresult != ISC_R_SUCCESS) fatal("add_nameserver failed"); } - } - if (ISC_LIST_EMPTY(server_list)) copy_server_list(lwconf, &server_list); + } #ifdef WITH_IDN initialize_idn(); @@ -1387,7 +1403,7 @@ start_lookup(void) { key_name) == ISC_TRUE) trustedkey = tk_list.key[i]; /* - * Verifier que la temp est bien la plus basse + * Verify temp is really the lowest * WARNING */ } @@ -2174,6 +2190,21 @@ bringup_timer(dig_query_t *query, unsigned int default_timeout) { check_result(result, "isc_timer_create"); } +static void +force_timeout(dig_lookup_t *l, dig_query_t *query) { + isc_event_t *event; + + event = isc_event_allocate(mctx, query, ISC_TIMEREVENT_IDLE, + connect_timeout, l, + sizeof(isc_event_t)); + if (event == NULL) { + fatal("isc_event_allocate: %s", + isc_result_totext(ISC_R_NOMEMORY)); + } + isc_task_send(global_task, &event); +} + + static void connect_done(isc_task_t *task, isc_event_t *event); @@ -2193,7 +2224,16 @@ send_tcp_connect(dig_query_t *query) { l = query->lookup; query->waiting_connect = ISC_TRUE; query->lookup->current_query = query; - get_address(query->servname, port, &query->sockaddr); + result = get_address(query->servname, port, &query->sockaddr); + if (result == ISC_R_NOTFOUND) { + /* + * This servname doesn't have an address. Try the next server + * by triggering an immediate 'timeout' (we lie, but the effect + * is the same). + */ + force_timeout(l, query); + return; + } if (specified_source && (isc_sockaddr_pf(&query->sockaddr) != @@ -2266,7 +2306,12 @@ send_udp(dig_query_t *query) { if (!query->recv_made) { /* XXX Check the sense of this, need assertion? */ query->waiting_connect = ISC_FALSE; - get_address(query->servname, port, &query->sockaddr); + result = get_address(query->servname, port, &query->sockaddr); + if (result == ISC_R_NOTFOUND) { + /* This servname doesn't have an address. */ + force_timeout(l, query); + return; + } result = isc_socket_create(socketmgr, isc_sockaddr_pf(&query->sockaddr), @@ -2337,8 +2382,14 @@ connect_timeout(isc_task_t *task, isc_event_t *event) { cq = query->lookup->current_query; if (!l->tcp_mode) send_udp(ISC_LIST_NEXT(cq, link)); - else + else { + isc_socket_cancel(query->sock, NULL, + ISC_SOCKCANCEL_ALL); + isc_socket_detach(&query->sock); + sockcount--; + debug("sockcount=%d", sockcount); send_tcp_connect(ISC_LIST_NEXT(cq, link)); + } UNLOCK_LOOKUP; return; } @@ -2892,18 +2943,8 @@ recv_done(isc_task_t *task, isc_event_t *event) { if (result == ISC_R_SUCCESS && (msgflags & DNS_MESSAGEFLAG_QR) == 0) printf(";; Warning: query response not set\n"); - if (!match) { - isc_buffer_invalidate(&query->recvbuf); - isc_buffer_init(&query->recvbuf, query->recvspace, COMMSIZE); - ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, link); - result = isc_socket_recvv(query->sock, &query->recvlist, 1, - global_task, recv_done, query); - check_result(result, "isc_socket_recvv"); - recvcount++; - isc_event_free(&event); - UNLOCK_LOOKUP; - return; - } + if (!match) + goto udp_mismatch; result = dns_message_create(mctx, DNS_MESSAGE_INTENTPARSE, &msg); check_result(result, "dns_message_create"); @@ -2958,6 +2999,52 @@ recv_done(isc_task_t *task, isc_event_t *event) { UNLOCK_LOOKUP; return; } + if (msg->counts[DNS_SECTION_QUESTION] != 0) { + match = ISC_TRUE; + for (result = dns_message_firstname(msg, DNS_SECTION_QUESTION); + result == ISC_R_SUCCESS && match; + result = dns_message_nextname(msg, DNS_SECTION_QUESTION)) { + dns_name_t *name = NULL; + dns_rdataset_t *rdataset; + + dns_message_currentname(msg, DNS_SECTION_QUESTION, + &name); + for (rdataset = ISC_LIST_HEAD(name->list); + rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) { + if (l->rdtype != rdataset->type || + l->rdclass != rdataset->rdclass || + !dns_name_equal(l->name, name)) { + char namestr[DNS_NAME_FORMATSIZE]; + char typebuf[DNS_RDATATYPE_FORMATSIZE]; + char classbuf[DNS_RDATACLASS_FORMATSIZE]; + dns_name_format(name, namestr, + sizeof(namestr)); + dns_rdatatype_format(rdataset->type, + typebuf, + sizeof(typebuf)); + dns_rdataclass_format(rdataset->rdclass, + classbuf, + sizeof(classbuf)); + printf(";; Question section mismatch: " + "got %s/%s/%s\n", + namestr, typebuf, classbuf); + match = ISC_FALSE; + } + } + } + if (!match) { + dns_message_destroy(&msg); + if (l->tcp_mode) { + isc_event_free(&event); + clear_query(query); + check_next_lookup(l); + UNLOCK_LOOKUP; + return; + } else + goto udp_mismatch; + } + } if ((msg->flags & DNS_MESSAGEFLAG_TC) != 0 && !l->ignore && !l->tcp_mode) { printf(";; Truncated, retrying in TCP mode.\n"); @@ -3212,6 +3299,19 @@ recv_done(isc_task_t *task, isc_event_t *event) { } isc_event_free(&event); UNLOCK_LOOKUP; + return; + + udp_mismatch: + isc_buffer_invalidate(&query->recvbuf); + isc_buffer_init(&query->recvbuf, query->recvspace, COMMSIZE); + ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, link); + result = isc_socket_recvv(query->sock, &query->recvlist, 1, + global_task, recv_done, query); + check_result(result, "isc_socket_recvv"); + recvcount++; + isc_event_free(&event); + UNLOCK_LOOKUP; + return; } /*% @@ -3219,7 +3319,7 @@ recv_done(isc_task_t *task, isc_event_t *event) { * used in looking up server names, etc... and needs to use system-supplied * routines, since they may be using a non-DNS system for these lookups. */ -void +isc_result_t get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr) { int count; isc_result_t result; @@ -3228,9 +3328,11 @@ get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr) { result = bind9_getaddresses(host, port, sockaddr, 1, &count); isc_app_unblock(); if (result != ISC_R_SUCCESS) - fatal("couldn't get address for '%s': %s", - host, isc_result_totext(result)); + return (result); + INSIST(count == 1); + + return (ISC_R_SUCCESS); } /*% @@ -3284,7 +3386,7 @@ cancel_all(void) { isc_timer_detach(¤t_lookup->timer); q = ISC_LIST_HEAD(current_lookup->q); while (q != NULL) { - debug("cancelling query %p, belonging to %p", + debug("canceling query %p, belonging to %p", q, current_lookup); nq = ISC_LIST_NEXT(q, link); if (q->sock != NULL) { @@ -3600,7 +3702,7 @@ dns_rdataset_t * search_type(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) { dns_rdataset_t *rdataset; dns_rdata_sig_t siginfo; - dns_rdata_t sigrdata; + dns_rdata_t sigrdata = DNS_RDATA_INIT; isc_result_t result; for (rdataset = ISC_LIST_HEAD(name->list); rdataset != NULL; @@ -3610,7 +3712,6 @@ search_type(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) { return (rdataset); } else if ((type == dns_rdatatype_rrsig) && (rdataset->type == dns_rdatatype_rrsig)) { - dns_rdata_init(&sigrdata); result = dns_rdataset_first(rdataset); check_result(result, "empty rdataset"); dns_rdataset_current(rdataset, &sigrdata); @@ -4133,7 +4234,7 @@ isc_result_t grandfather_pb_test(dns_name_t *zone_name, dns_rdataset_t *sigrdataset) { isc_result_t result; - dns_rdata_t sigrdata; + dns_rdata_t sigrdata = DNS_RDATA_INIT; dns_rdata_sig_t siginfo; result = dns_rdataset_first(sigrdataset); @@ -4153,6 +4254,7 @@ grandfather_pb_test(dns_name_t *zone_name, dns_rdataset_t *sigrdataset) } dns_rdata_freestruct(&siginfo); + dns_rdata_reset(&sigrdata); } while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS); @@ -4239,7 +4341,7 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset, isc_mem_t *mctx) { isc_result_t result; - dns_rdata_t rdata; + dns_rdata_t rdata = DNS_RDATA_INIT; dst_key_t *trustedKey = NULL; dst_key_t *dnsseckey = NULL; int i; @@ -4249,7 +4351,6 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset, result = dns_rdataset_first(rdataset); check_result(result, "empty rdataset"); - dns_rdata_init(&rdata); do { dns_rdataset_current(rdataset, &rdata); @@ -4299,7 +4400,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset, isc_mem_t *mctx) { isc_result_t result; - dns_rdata_t keyrdata; + dns_rdata_t keyrdata = DNS_RDATA_INIT; dst_key_t *dnsseckey = NULL; result = dns_rdataset_first(keyrdataset); @@ -4322,6 +4423,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset, return (ISC_R_SUCCESS); } dst_key_free(&dnsseckey); + dns_rdata_reset(&keyrdata); } while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS); dns_rdata_reset(&keyrdata); @@ -4335,7 +4437,7 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset, isc_mem_t *mctx) { isc_result_t result; - dns_rdata_t sigrdata; + dns_rdata_t sigrdata = DNS_RDATA_INIT; dns_rdata_sig_t siginfo; result = dns_rdataset_first(sigrdataset); @@ -4373,6 +4475,7 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset, } } dns_rdata_freestruct(&siginfo); + dns_rdata_reset(&sigrdata); } while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS); @@ -4387,25 +4490,23 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, dns_rdataset_t *dsrdataset, isc_mem_t *mctx) { isc_result_t result; - dns_rdata_t keyrdata; - dns_rdata_t newdsrdata; - dns_rdata_t dsrdata; + dns_rdata_t keyrdata = DNS_RDATA_INIT; + dns_rdata_t newdsrdata = DNS_RDATA_INIT; + dns_rdata_t dsrdata = DNS_RDATA_INIT; dns_rdata_ds_t dsinfo; dst_key_t *dnsseckey = NULL; unsigned char dsbuf[DNS_DS_BUFFERSIZE]; result = dns_rdataset_first(dsrdataset); check_result(result, "empty DSset dataset"); - dns_rdata_init(&dsrdata); do { dns_rdataset_current(dsrdataset, &dsrdata); result = dns_rdata_tostruct(&dsrdata, &dsinfo, NULL); - check_result(result, "dns_rdata_tostruct for DS"); + check_result(result, "dns_rdata_tostruct for DS"); result = dns_rdataset_first(keyrdataset); check_result(result, "empty KEY dataset"); - dns_rdata_init(&keyrdata); do { dns_rdataset_current(keyrdataset, &keyrdata); @@ -4420,7 +4521,6 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, * id of DNSKEY referenced by the DS */ if (dsinfo.key_tag == dst_key_id(dnsseckey)) { - dns_rdata_init(&newdsrdata); result = dns_ds_buildrdata(name, &keyrdata, dsinfo.digest_type, @@ -4468,14 +4568,16 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, dns_rdata_reset(&newdsrdata); } dst_key_free(&dnsseckey); + dns_rdata_reset(&keyrdata); dnsseckey = NULL; } while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS); - dns_rdata_reset(&keyrdata); + dns_rdata_reset(&dsrdata); } while (dns_rdataset_next(chase_dsrdataset) == ISC_R_SUCCESS); -#if 0 - dns_rdata_reset(&dsrdata); WARNING -#endif + + dns_rdata_reset(&keyrdata); + dns_rdata_reset(&newdsrdata); + dns_rdata_reset(&dsrdata); return (ISC_R_NOTFOUND); } @@ -4868,7 +4970,7 @@ getneededrr(dns_message_t *msg) { isc_result_t result; dns_name_t *name = NULL; - dns_rdata_t sigrdata; + dns_rdata_t sigrdata = DNS_RDATA_INIT; dns_rdata_sig_t siginfo; isc_boolean_t true = ISC_TRUE; @@ -4922,7 +5024,6 @@ getneededrr(dns_message_t *msg) /* first find the DNSKEY name */ result = dns_rdataset_first(chase_sigrdataset); check_result(result, "empty RRSIG dataset"); - dns_rdata_init(&sigrdata); dns_rdataset_current(chase_sigrdataset, &sigrdata); result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL); check_result(result, "sigrdata tostruct siginfo"); @@ -5300,6 +5401,7 @@ prove_nx_domain(dns_message_t *msg, } dns_rdata_freestruct(&nsecstruct); + dns_rdata_reset(&nsec); } } while (dns_message_nextname(msg, DNS_SECTION_AUTHORITY) == ISC_R_SUCCESS); @@ -5367,7 +5469,7 @@ prove_nx(dns_message_t *msg, dns_name_t *name, dns_rdataclass_t class, isc_result_t ret; dns_rdataset_t *nsecset = NULL; - printf("We want to prove the non-existance of a type of rdata %d" + printf("We want to prove the non-existence of a type of rdata %d" " or of the zone: \n", type); if ((ret = dns_message_firstname(msg, DNS_SECTION_AUTHORITY)) diff --git a/bin/dig/host.1 b/bin/dig/host.1 index 9993c0eac8da..dfceb5e34243 100644 --- a/bin/dig/host.1 +++ b/bin/dig/host.1 @@ -1,7 +1,7 @@ -.\" Copyright (C) 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2004, 2005, 2007-2009 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2002 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: host.1,v 1.14.18.16 2008/04/06 01:31:04 tbox Exp $ +.\" $Id: host.1,v 1.14.18.18 2009/07/11 01:31:44 tbox Exp $ .\" .hy 0 .ad l @@ -132,7 +132,7 @@ option enables \fBhost\fR to mimic the behavior of a name server by making non\-recursive queries and expecting to receive answers to those queries that are usually referrals to other name servers. .PP -By default +By default, \fBhost\fR uses UDP when making queries. The \fB\-T\fR @@ -154,7 +154,7 @@ option is used to select the query type. \fItype\fR can be any recognized query type: CNAME, NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, \fBhost\fR -automatically selects an appropriate query type. By default it looks for A, AAAA, and MX records, but if the +automatically selects an appropriate query type. By default, it looks for A, AAAA, and MX records, but if the \fB\-C\fR option was given, queries will be made for SOA records, and if \fIname\fR @@ -213,7 +213,7 @@ runs. \fBdig\fR(1), \fBnamed\fR(8). .SH "COPYRIGHT" -Copyright \(co 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC") +Copyright \(co 2004, 2005, 2007\-2009 Internet Systems Consortium, Inc. ("ISC") .br Copyright \(co 2000\-2002 Internet Software Consortium. .br diff --git a/bin/dig/host.c b/bin/dig/host.c index 33025d5307e5..fbe36a4029d4 100644 --- a/bin/dig/host.c +++ b/bin/dig/host.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2007, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: host.c,v 1.94.18.19 2007/08/28 07:19:55 tbox Exp $ */ +/* $Id: host.c,v 1.94.18.22 2009/09/08 23:29:03 marka Exp $ */ /*! \file */ @@ -124,6 +124,23 @@ struct rtype rtypes[] = { { 0, NULL } }; +static char * +rcode_totext(dns_rcode_t rcode) +{ + static char buf[sizeof("?65535")]; + union { + const char *consttext; + char *deconsttext; + } totext; + + if (rcode >= (sizeof(rcodetext)/sizeof(rcodetext[0]))) { + snprintf(buf, sizeof(buf), "?%u", rcode); + totext.deconsttext = buf; + } else + totext.consttext = rcodetext[rcode]; + return totext.deconsttext; +} + static void show_usage(void) { fputs( @@ -270,10 +287,10 @@ printsection(dns_message_t *msg, dns_section_t sectionid, if (query->lookup->rdtype == dns_rdatatype_axfr && !((!list_addresses && (list_type == dns_rdatatype_any || - rdataset->type == list_type)) || + rdataset->type == list_type)) || (list_addresses && (rdataset->type == dns_rdatatype_a || - rdataset->type == dns_rdatatype_aaaa || + rdataset->type == dns_rdatatype_aaaa || rdataset->type == dns_rdatatype_ns || rdataset->type == dns_rdatatype_ptr)))) continue; @@ -377,7 +394,7 @@ chase_cnamechain(dns_message_t *msg, dns_name_t *qname) { dns_rdata_t rdata = DNS_RDATA_INIT; unsigned int i = msg->counts[DNS_SECTION_ANSWER]; - while (i-- > 0) { + while (i-- > 0) { rdataset = NULL; result = dns_message_findname(msg, DNS_SECTION_ANSWER, qname, dns_rdatatype_cname, 0, NULL, @@ -429,7 +446,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { printf("Host %s not found: %d(%s)\n", (msg->rcode != dns_rcode_nxdomain) ? namestr : query->lookup->textname, msg->rcode, - rcodetext[msg->rcode]); + rcode_totext(msg->rcode)); return (ISC_R_SUCCESS); } @@ -451,7 +468,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { sizeof(lookup->textname)); lookup->textname[sizeof(lookup->textname)-1] = 0; lookup->rdtype = dns_rdatatype_aaaa; - lookup->rdtypeset = ISC_TRUE; + lookup->rdtypeset = ISC_TRUE; lookup->origin = NULL; lookup->retries = tries; ISC_LIST_APPEND(lookup_list, lookup, link); @@ -462,7 +479,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { sizeof(lookup->textname)); lookup->textname[sizeof(lookup->textname)-1] = 0; lookup->rdtype = dns_rdatatype_mx; - lookup->rdtypeset = ISC_TRUE; + lookup->rdtypeset = ISC_TRUE; lookup->origin = NULL; lookup->retries = tries; ISC_LIST_APPEND(lookup_list, lookup, link); @@ -471,7 +488,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { if (!short_form) { printf(";; ->>HEADER<<- opcode: %s, status: %s, id: %u\n", - opcodetext[msg->opcode], rcodetext[msg->rcode], + opcodetext[msg->opcode], rcode_totext(msg->rcode), msg->id); printf(";; flags: "); if ((msg->flags & DNS_MESSAGEFLAG_QR) != 0) { @@ -821,11 +838,10 @@ parse_args(isc_boolean_t is_batchfile, int argc, char **argv) { } else { strncpy(lookup->textname, hostname, sizeof(lookup->textname)); lookup->textname[sizeof(lookup->textname)-1]=0; + usesearch = ISC_TRUE; } lookup->new_search = ISC_TRUE; ISC_LIST_APPEND(lookup_list, lookup, link); - - usesearch = ISC_TRUE; } int @@ -837,7 +853,7 @@ main(int argc, char **argv) { ISC_LIST_INIT(lookup_list); ISC_LIST_INIT(server_list); ISC_LIST_INIT(search_list); - + fatalexit = 1; #ifdef WITH_IDN idnoptions = IDN_ASCCHECK; diff --git a/bin/dig/host.docbook b/bin/dig/host.docbook index 2c0ad3d7962f..e5a745b9520a 100644 --- a/bin/dig/host.docbook +++ b/bin/dig/host.docbook @@ -2,7 +2,7 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> - + @@ -42,6 +42,7 @@ 2005 2007 2008 + 2009 Internet Systems Consortium, Inc. ("ISC") @@ -180,7 +181,7 @@ - By default host uses UDP when making + By default, host uses UDP when making queries. The option makes it use a TCP connection when querying the name server. TCP will be automatically selected for queries that @@ -200,7 +201,7 @@ NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, host automatically selects an appropriate query - type. By default it looks for A, AAAA, and MX records, but if the + type. By default, it looks for A, AAAA, and MX records, but if the option was given, queries will be made for SOA records, and if name is a dotted-decimal IPv4 diff --git a/bin/dig/host.html b/bin/dig/host.html index 88cd830f033b..b3862a24d5dd 100644 --- a/bin/dig/host.html +++ b/bin/dig/host.html @@ -1,8 +1,8 @@ - + @@ -32,7 +32,7 @@

host [-aCdlnrsTwv] [-c class] [-N ndots] [-R number] [-t type] [-W wait] [-m flag] [-4] [-6] {name} [server]

-

DESCRIPTION

+

DESCRIPTION

host is a simple utility for performing DNS lookups. It is normally used to convert names to IP addresses and vice versa. @@ -130,7 +130,7 @@ referrals to other name servers.

- By default host uses UDP when making + By default, host uses UDP when making queries. The -T option makes it use a TCP connection when querying the name server. TCP will be automatically selected for queries that @@ -148,7 +148,7 @@ NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, host automatically selects an appropriate query - type. By default it looks for A, AAAA, and MX records, but if the + type. By default, it looks for A, AAAA, and MX records, but if the -C option was given, queries will be made for SOA records, and if name is a dotted-decimal IPv4 @@ -184,7 +184,7 @@

-

IDN SUPPORT

+

IDN SUPPORT

If host has been built with IDN (internationalized domain name) support, it can accept and display non-ASCII domain names. @@ -198,12 +198,12 @@

-

FILES

+

FILES

/etc/resolv.conf

-

SEE ALSO

+

SEE ALSO

dig(1), named(8).

diff --git a/bin/dig/include/dig/dig.h b/bin/dig/include/dig/dig.h index 02ae4d22bc50..ad504cbc35ff 100644 --- a/bin/dig/include/dig/dig.h +++ b/bin/dig/include/dig/dig.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dig.h,v 1.82.18.23 2007/08/28 07:19:55 tbox Exp $ */ +/* $Id: dig.h,v 1.82.18.25 2008/12/16 23:46:02 tbox Exp $ */ #ifndef DIG_H #define DIG_H @@ -102,7 +102,7 @@ typedef struct dig_searchlist dig_searchlist_t; /*% The dig_lookup structure */ struct dig_lookup { isc_boolean_t - pending, /*%< Pending a successful answer */ + pending, /*%< Pending a successful answer */ waiting_connect, doing_xfr, ns_search_only, /*%< dig +nssearch, host -C */ @@ -133,23 +133,23 @@ struct dig_lookup { #ifdef DIG_SIGCHASE isc_boolean_t sigchase; #if DIG_SIGCHASE_TD - isc_boolean_t do_topdown, - trace_root_sigchase, - rdtype_sigchaseset, - rdclass_sigchaseset; + isc_boolean_t do_topdown, + trace_root_sigchase, + rdtype_sigchaseset, + rdclass_sigchaseset; /* Name we are going to validate RRset */ - char textnamesigchase[MXNAME]; + char textnamesigchase[MXNAME]; #endif #endif - + char textname[MXNAME]; /*% Name we're going to be looking up */ char cmdline[MXNAME]; dns_rdatatype_t rdtype; dns_rdatatype_t qrdtype; #if DIG_SIGCHASE_TD - dns_rdatatype_t rdtype_sigchase; - dns_rdatatype_t qrdtype_sigchase; - dns_rdataclass_t rdclass_sigchase; + dns_rdatatype_t rdtype_sigchase; + dns_rdatatype_t qrdtype_sigchase; + dns_rdataclass_t rdclass_sigchase; #endif dns_rdataclass_t rdclass; isc_boolean_t rdtypeset; @@ -231,7 +231,7 @@ struct dig_searchlist { }; #ifdef DIG_SIGCHASE struct dig_message { - dns_message_t *msg; + dns_message_t *msg; ISC_LINK(dig_message_t) link; }; #endif @@ -249,7 +249,7 @@ extern dig_searchlistlist_t search_list; extern unsigned int extrabytes; extern isc_boolean_t check_ra, have_ipv4, have_ipv6, specified_source, - usesearch, showsearch, qr; + usesearch, showsearch, qr; extern in_port_t port; extern unsigned int timeout; extern isc_mem_t *mctx; @@ -284,7 +284,7 @@ extern int idnoptions; /* * Routines in dighost.c. */ -void +isc_result_t get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr); isc_result_t diff --git a/bin/dig/nslookup.1 b/bin/dig/nslookup.1 index a453c2fd23a2..882638e0cffc 100644 --- a/bin/dig/nslookup.1 +++ b/bin/dig/nslookup.1 @@ -1,6 +1,6 @@ .\" Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -12,7 +12,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: nslookup.1,v 1.1.10.14 2007/05/16 06:11:27 marka Exp $ +.\" $Id: nslookup.1,v 1.1.10.15 2009/07/11 01:31:44 tbox Exp $ .\" .hy 0 .ad l diff --git a/bin/dig/nslookup.c b/bin/dig/nslookup.c index 3327c6e9429a..01f53471d44b 100644 --- a/bin/dig/nslookup.c +++ b/bin/dig/nslookup.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: nslookup.c,v 1.101.18.15 2007/08/28 07:19:55 tbox Exp $ */ +/* $Id: nslookup.c,v 1.101.18.20 2009/05/06 23:45:59 tbox Exp $ */ #include @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -129,6 +130,23 @@ static const char *rtypetext[] = { static void flush_lookup_list(void); static void getinput(isc_task_t *task, isc_event_t *event); +static char * +rcode_totext(dns_rcode_t rcode) +{ + static char buf[sizeof("?65535")]; + union { + const char *consttext; + char *deconsttext; + } totext; + + if (rcode >= (sizeof(rcodetext)/sizeof(rcodetext[0]))) { + snprintf(buf, sizeof(buf), "?%u", rcode); + totext.deconsttext = buf; + } else + totext.consttext = rcodetext[rcode]; + return totext.deconsttext; +} + void dighost_shutdown(void) { isc_event_t *event = global_event; @@ -385,14 +403,14 @@ trying(char *frm, dig_lookup_t *lookup) { isc_result_t printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { - char servtext[ISC_SOCKADDR_FORMATSIZE]; + char servtext[ISC_SOCKADDR_FORMATSIZE]; debug("printmessage()"); isc_sockaddr_format(&query->sockaddr, servtext, sizeof(servtext)); printf("Server:\t\t%s\n", query->userarg); printf("Address:\t%s\n", servtext); - + puts(""); if (!short_form) { @@ -412,7 +430,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) { nametext, sizeof(nametext)); printf("** server can't find %s: %s\n", (msg->rcode != dns_rcode_nxdomain) ? nametext : - query->lookup->textname, rcodetext[msg->rcode]); + query->lookup->textname, rcode_totext(msg->rcode)); debug("returning with rcode == 0"); return (ISC_R_SUCCESS); } @@ -441,13 +459,16 @@ show_settings(isc_boolean_t full, isc_boolean_t serv_only) { dig_server_t *srv; isc_sockaddr_t sockaddr; dig_searchlist_t *listent; + isc_result_t result; srv = ISC_LIST_HEAD(server_list); while (srv != NULL) { char sockstr[ISC_SOCKADDR_FORMATSIZE]; - get_address(srv->servername, port, &sockaddr); + result = get_address(srv->servername, port, &sockaddr); + check_result(result, "get_address"); + isc_sockaddr_format(&sockaddr, sockstr, sizeof(sockstr)); printf("Default server: %s\nAddress: %s\n", srv->userarg, sockstr); @@ -505,7 +526,7 @@ testclass(char *typetext) { tr.base = typetext; tr.length = strlen(typetext); result = dns_rdataclass_fromtext(&rdclass, &tr); - if (result == ISC_R_SUCCESS) + if (result == ISC_R_SUCCESS) return (ISC_TRUE); else { printf("unknown query class: %s\n", typetext); @@ -603,7 +624,7 @@ setoption(char *opt) { set_timeout(&opt[8]); } else if (strncasecmp(opt, "t=", 2) == 0) { set_timeout(&opt[2]); - } else if (strncasecmp(opt, "rec", 3) == 0) { + } else if (strncasecmp(opt, "rec", 3) == 0) { recurse = ISC_TRUE; } else if (strncasecmp(opt, "norec", 5) == 0) { recurse = ISC_FALSE; @@ -611,21 +632,21 @@ setoption(char *opt) { set_tries(&opt[6]); } else if (strncasecmp(opt, "ret=", 4) == 0) { set_tries(&opt[4]); - } else if (strncasecmp(opt, "def", 3) == 0) { + } else if (strncasecmp(opt, "def", 3) == 0) { usesearch = ISC_TRUE; } else if (strncasecmp(opt, "nodef", 5) == 0) { usesearch = ISC_FALSE; - } else if (strncasecmp(opt, "vc", 3) == 0) { + } else if (strncasecmp(opt, "vc", 3) == 0) { tcpmode = ISC_TRUE; } else if (strncasecmp(opt, "novc", 5) == 0) { tcpmode = ISC_FALSE; - } else if (strncasecmp(opt, "deb", 3) == 0) { + } else if (strncasecmp(opt, "deb", 3) == 0) { short_form = ISC_FALSE; showsearch = ISC_TRUE; } else if (strncasecmp(opt, "nodeb", 5) == 0) { short_form = ISC_TRUE; showsearch = ISC_FALSE; - } else if (strncasecmp(opt, "d2", 2) == 0) { + } else if (strncasecmp(opt, "d2", 2) == 0) { debugging = ISC_TRUE; } else if (strncasecmp(opt, "nod2", 4) == 0) { debugging = ISC_FALSE; @@ -640,7 +661,7 @@ setoption(char *opt) { } else if (strncasecmp(opt, "nofail", 3) == 0) { nofail=ISC_TRUE; } else { - printf("*** Invalid option: %s\n", opt); + printf("*** Invalid option: %s\n", opt); } } diff --git a/bin/dig/nslookup.html b/bin/dig/nslookup.html index 46ae43cc1e52..a8c4fb59f0ba 100644 --- a/bin/dig/nslookup.html +++ b/bin/dig/nslookup.html @@ -1,7 +1,7 @@ - + diff --git a/bin/dnssec/dnssec-keygen.8 b/bin/dnssec/dnssec-keygen.8 index e667ba9b08e6..5e6df6a9fb80 100644 --- a/bin/dnssec/dnssec-keygen.8 +++ b/bin/dnssec/dnssec-keygen.8 @@ -1,7 +1,7 @@ .\" Copyright (C) 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2003 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: dnssec-keygen.8,v 1.23.18.16 2008/10/16 01:29:40 tbox Exp $ +.\" $Id: dnssec-keygen.8,v 1.23.18.17 2009/07/11 01:31:44 tbox Exp $ .\" .hy 0 .ad l diff --git a/bin/dnssec/dnssec-keygen.html b/bin/dnssec/dnssec-keygen.html index e0b0bfe059aa..d2944cafe476 100644 --- a/bin/dnssec/dnssec-keygen.html +++ b/bin/dnssec/dnssec-keygen.html @@ -2,7 +2,7 @@ - Copyright (C) 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC") - Copyright (C) 2000-2003 Internet Software Consortium. - - - Permission to use, copy, modify, and distribute this software for any + - Permission to use, copy, modify, and/or distribute this software for any - purpose with or without fee is hereby granted, provided that the above - copyright notice and this permission notice appear in all copies. - @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> - + diff --git a/bin/dnssec/dnssec-signzone.8 b/bin/dnssec/dnssec-signzone.8 index 680960ae8928..3e53ca099f13 100644 --- a/bin/dnssec/dnssec-signzone.8 +++ b/bin/dnssec/dnssec-signzone.8 @@ -1,7 +1,7 @@ .\" Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2003 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: dnssec-signzone.8,v 1.28.18.19 2008/10/16 01:29:40 tbox Exp $ +.\" $Id: dnssec-signzone.8,v 1.28.18.20 2009/07/11 01:31:44 tbox Exp $ .\" .hy 0 .ad l diff --git a/bin/dnssec/dnssec-signzone.c b/bin/dnssec/dnssec-signzone.c index 9b4916910440..e46e6107edb0 100644 --- a/bin/dnssec/dnssec-signzone.c +++ b/bin/dnssec/dnssec-signzone.c @@ -1,5 +1,5 @@ /* - * Portions Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Portions Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Portions Copyright (C) 1999-2003 Internet Software Consortium. * Portions Copyright (C) 1995-2000 by Network Associates, Inc. * @@ -16,7 +16,7 @@ * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dnssec-signzone.c,v 1.177.18.26 2008/06/02 23:46:01 tbox Exp $ */ +/* $Id: dnssec-signzone.c,v 1.177.18.29 2009/07/21 06:44:32 tbox Exp $ */ /*! \file */ @@ -194,16 +194,30 @@ newkeystruct(dst_key_t *dstkey, isc_boolean_t signwithkey) { return (key); } +/*% + * Sign the given RRset with given key, and add the signature record to the + * given tuple. + */ + static void -signwithkey(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdata_t *rdata, - dst_key_t *key, isc_buffer_t *b) +signwithkey(dns_name_t *name, dns_rdataset_t *rdataset, dst_key_t *key, + dns_ttl_t ttl, dns_diff_t *add, const char *logmsg) { isc_result_t result; isc_stdtime_t jendtime; + char keystr[KEY_FORMATSIZE]; + dns_rdata_t trdata = DNS_RDATA_INIT; + unsigned char array[BUFSIZE]; + isc_buffer_t b; + dns_difftuple_t *tuple; + + key_format(key, keystr, sizeof(keystr)); + vbprintf(1, "\t%s %s\n", logmsg, keystr); jendtime = (jitter != 0) ? isc_random_jitter(endtime, jitter) : endtime; + isc_buffer_init(&b, array, sizeof(array)); result = dns_dnssec_sign(name, rdataset, key, &starttime, &jendtime, - mctx, b, rdata); + mctx, &b, &trdata); isc_entropy_stopcallbacksources(ectx); if (result != ISC_R_SUCCESS) { char keystr[KEY_FORMATSIZE]; @@ -215,7 +229,7 @@ signwithkey(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdata_t *rdata, if (tryverify) { result = dns_dnssec_verify(name, rdataset, key, - ISC_TRUE, mctx, rdata); + ISC_TRUE, mctx, &trdata); if (result == ISC_R_SUCCESS) { vbprintf(3, "\tsignature verified\n"); INCSTAT(nverified); @@ -224,6 +238,12 @@ signwithkey(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdata_t *rdata, INCSTAT(nverifyfailed); } } + + tuple = NULL; + result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, name, ttl, &trdata, + &tuple); + check_result(result, "dns_difftuple_create"); + dns_diff_append(add, &tuple); } static inline isc_boolean_t @@ -482,24 +502,11 @@ signset(dns_diff_t *del, dns_diff_t *add, dns_dbnode_t *node, dns_name_t *name, } if (resign) { - isc_buffer_t b; - dns_rdata_t trdata = DNS_RDATA_INIT; - unsigned char array[BUFSIZE]; - char keystr[KEY_FORMATSIZE]; - INSIST(!keep); - key_format(key->key, keystr, sizeof(keystr)); - vbprintf(1, "\tresigning with dnskey %s\n", keystr); - isc_buffer_init(&b, array, sizeof(array)); - signwithkey(name, set, &trdata, key->key, &b); + signwithkey(name, set, key->key, ttl, add, + "resigning with dnskey"); nowsignedby[key->position] = ISC_TRUE; - tuple = NULL; - result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, - name, ttl, &trdata, - &tuple); - check_result(result, "dns_difftuple_create"); - dns_diff_append(add, &tuple); } dns_rdata_reset(&sigrdata); @@ -517,11 +524,6 @@ signset(dns_diff_t *del, dns_diff_t *add, dns_dbnode_t *node, dns_name_t *name, key != NULL; key = ISC_LIST_NEXT(key, link)) { - isc_buffer_t b; - dns_rdata_t trdata; - unsigned char array[BUFSIZE]; - char keystr[KEY_FORMATSIZE]; - if (nowsignedby[key->position]) continue; @@ -533,16 +535,8 @@ signset(dns_diff_t *del, dns_diff_t *add, dns_dbnode_t *node, dns_name_t *name, dns_name_equal(name, gorigin)))) continue; - key_format(key->key, keystr, sizeof(keystr)); - vbprintf(1, "\tsigning with dnskey %s\n", keystr); - dns_rdata_init(&trdata); - isc_buffer_init(&b, array, sizeof(array)); - signwithkey(name, set, &trdata, key->key, &b); - tuple = NULL; - result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, name, - ttl, &trdata, &tuple); - check_result(result, "dns_difftuple_create"); - dns_diff_append(add, &tuple); + signwithkey(name, set, key->key, ttl, add, + "signing with dnskey"); } isc_mem_put(mctx, wassignedby, arraysize * sizeof(isc_boolean_t)); @@ -2106,6 +2100,9 @@ main(int argc, char *argv[]) { fatal("cannot load dnskey %s: %s", argv[i], isc_result_totext(result)); + if (!dns_name_equal(gorigin, dst_key_name(newkey))) + fatal("key %s not at origin\n", argv[i]); + key = ISC_LIST_HEAD(keylist); while (key != NULL) { dst_key_t *dkey = key->key; @@ -2143,6 +2140,9 @@ main(int argc, char *argv[]) { fatal("cannot load dnskey %s: %s", dskeyfile[i], isc_result_totext(result)); + if (!dns_name_equal(gorigin, dst_key_name(newkey))) + fatal("key %s not at origin\n", dskeyfile[i]); + key = ISC_LIST_HEAD(keylist); while (key != NULL) { dst_key_t *dkey = key->key; diff --git a/bin/dnssec/dnssec-signzone.html b/bin/dnssec/dnssec-signzone.html index 18d851d1fcd3..201fcaa01969 100644 --- a/bin/dnssec/dnssec-signzone.html +++ b/bin/dnssec/dnssec-signzone.html @@ -2,7 +2,7 @@ - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") - Copyright (C) 2000-2003 Internet Software Consortium. - - - Permission to use, copy, modify, and distribute this software for any + - Permission to use, copy, modify, and/or distribute this software for any - purpose with or without fee is hereby granted, provided that the above - copyright notice and this permission notice appear in all copies. - @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> - + diff --git a/bin/named/client.c b/bin/named/client.c index 03cfdb6a714e..0692621c069d 100644 --- a/bin/named/client.c +++ b/bin/named/client.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: client.c,v 1.219.18.31 2008/05/22 23:46:03 tbox Exp $ */ +/* $Id: client.c,v 1.219.18.33 2009/01/19 23:46:14 tbox Exp $ */ #include @@ -1218,7 +1218,7 @@ allowed(isc_netaddr_t *addr, dns_name_t *signer, dns_acl_t *acl) { * delivered to 'myview'. * * We run this unlocked as both the view list and the interface list - * are updated when the approprite task has exclusivity. + * are updated when the appropriate task has exclusivity. */ isc_boolean_t ns_client_isself(dns_view_t *myview, dns_tsigkey_t *mykey, @@ -2115,7 +2115,7 @@ client_newconn(isc_task_t *task, isc_event_t *event) { * Let a new client take our place immediately, before * we wait for a request packet. If we don't, * telnetting to port 53 (once per CPU) will - * deny service to legititmate TCP clients. + * deny service to legitimate TCP clients. */ result = isc_quota_attach(&ns_g_server->tcpquota, &client->tcpquota); diff --git a/bin/named/control.c b/bin/named/control.c index 3f2d52e946be..740c89f79679 100644 --- a/bin/named/control.c +++ b/bin/named/control.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2007, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: control.c,v 1.20.10.10 2007/09/13 23:46:26 tbox Exp $ */ +/* $Id: control.c,v 1.20.10.12 2009/07/11 23:46:06 tbox Exp $ */ /*! \file */ @@ -56,7 +56,7 @@ command_compare(const char *text, const char *command) { /*% * This function is called to process the incoming command - * when a control channel message is received. + * when a control channel message is received. */ isc_result_t ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) { @@ -159,10 +159,12 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) { } else if (command_compare(command, NS_COMMAND_STATUS)) { result = ns_server_status(ns_g_server, text); } else if (command_compare(command, NS_COMMAND_FREEZE)) { - result = ns_server_freeze(ns_g_server, ISC_TRUE, command); + result = ns_server_freeze(ns_g_server, ISC_TRUE, command, + text); } else if (command_compare(command, NS_COMMAND_UNFREEZE) || command_compare(command, NS_COMMAND_THAW)) { - result = ns_server_freeze(ns_g_server, ISC_FALSE, command); + result = ns_server_freeze(ns_g_server, ISC_FALSE, command, + text); } else if (command_compare(command, NS_COMMAND_RECURSING)) { result = ns_server_dumprecursing(ns_g_server); } else if (command_compare(command, NS_COMMAND_TIMERPOKE)) { diff --git a/bin/named/include/named/client.h b/bin/named/include/named/client.h index 0cf7985e919b..fe5553ae3f4e 100644 --- a/bin/named/include/named/client.h +++ b/bin/named/include/named/client.h @@ -1,8 +1,8 @@ /* - * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2006, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: client.h,v 1.69.18.9 2006/06/06 00:11:41 marka Exp $ */ +/* $Id: client.h,v 1.69.18.11 2009/01/19 23:46:14 tbox Exp $ */ #ifndef NAMED_CLIENT_H #define NAMED_CLIENT_H 1 @@ -24,7 +24,7 @@ ***** Module Info *****/ -/*! \file +/*! \file * \brief * This module defines two objects, ns_client_t and ns_clientmgr_t. * @@ -155,7 +155,7 @@ struct ns_client { #define NS_CLIENT_VALID(c) ISC_MAGIC_VALID(c, NS_CLIENT_MAGIC) #define NS_CLIENTATTR_TCP 0x01 -#define NS_CLIENTATTR_RA 0x02 /*%< Client gets recusive service */ +#define NS_CLIENTATTR_RA 0x02 /*%< Client gets recursive service */ #define NS_CLIENTATTR_PKTINFO 0x04 /*%< pktinfo is valid */ #define NS_CLIENTATTR_MULTICAST 0x08 /*%< recv'd from multicast */ #define NS_CLIENTATTR_WANTDNSSEC 0x10 /*%< include dnssec records */ @@ -352,8 +352,8 @@ ns_client_qnamereplace(ns_client_t *client, dns_name_t *name); isc_boolean_t ns_client_isself(dns_view_t *myview, dns_tsigkey_t *mykey, - isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr, - dns_rdataclass_t rdclass, void *arg); + isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr, + dns_rdataclass_t rdclass, void *arg); /*% * Isself callback. */ diff --git a/bin/named/include/named/log.h b/bin/named/include/named/log.h index 6d6e648d95bd..566a29b073f7 100644 --- a/bin/named/include/named/log.h +++ b/bin/named/include/named/log.h @@ -1,8 +1,8 @@ /* - * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: log.h,v 1.21.18.2 2005/04/29 00:15:35 marka Exp $ */ +/* $Id: log.h,v 1.21.18.4 2009/09/24 23:46:06 tbox Exp $ */ #ifndef NAMED_LOG_H #define NAMED_LOG_H 1 @@ -36,6 +36,7 @@ #define NS_LOGCATEGORY_QUERIES (&ns_g_categories[4]) #define NS_LOGCATEGORY_UNMATCHED (&ns_g_categories[5]) #define NS_LOGCATEGORY_UPDATE_SECURITY (&ns_g_categories[6]) +#define NS_LOGCATEGORY_QUERY_EERRORS (&ns_g_categories[7]) /* * Backwards compatibility. diff --git a/bin/named/include/named/lwdclient.h b/bin/named/include/named/lwdclient.h index 591b86c7b3dd..cd0aa9b567f3 100644 --- a/bin/named/include/named/lwdclient.h +++ b/bin/named/include/named/lwdclient.h @@ -1,8 +1,8 @@ /* - * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: lwdclient.h,v 1.14.18.2 2005/04/29 00:15:36 marka Exp $ */ +/* $Id: lwdclient.h,v 1.14.18.4 2009/01/19 23:46:14 tbox Exp $ */ #ifndef NAMED_LWDCLIENT_H #define NAMED_LWDCLIENT_H 1 @@ -39,7 +39,7 @@ #define LWRD_SHUTDOWN (LWRD_EVENTCLASS + 0x0001) -/*% Lighweight Resolver Daemon Client */ +/*% Lightweight Resolver Daemon Client */ struct ns_lwdclient { isc_sockaddr_t address; /*%< where to reply */ struct in6_pktinfo pktinfo; diff --git a/bin/named/include/named/notify.h b/bin/named/include/named/notify.h index 106d70c447f7..e1248110a66b 100644 --- a/bin/named/include/named/notify.h +++ b/bin/named/include/named/notify.h @@ -1,8 +1,8 @@ /* - * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: notify.h,v 1.10.18.2 2005/04/29 00:15:37 marka Exp $ */ +/* $Id: notify.h,v 1.10.18.4 2009/01/19 23:46:14 tbox Exp $ */ #ifndef NAMED_NOTIFY_H #define NAMED_NOTIFY_H 1 @@ -41,7 +41,7 @@ void ns_notify_start(ns_client_t *client); /*%< - * Examines the incoming message to determine apporiate zone. + * Examines the incoming message to determine appropriate zone. * Returns FORMERR if there is not exactly one question. * Returns REFUSED if we do not serve the listed zone. * Pass the message to the zone module for processing diff --git a/bin/named/include/named/server.h b/bin/named/include/named/server.h index 54d1dae17167..7b46977eb109 100644 --- a/bin/named/include/named/server.h +++ b/bin/named/include/named/server.h @@ -1,8 +1,8 @@ /* - * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2006, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.h,v 1.73.18.8 2006/03/09 23:46:20 marka Exp $ */ +/* $Id: server.h,v 1.73.18.10 2009/07/11 23:46:06 tbox Exp $ */ #ifndef NAMED_SERVER_H #define NAMED_SERVER_H 1 @@ -62,7 +62,7 @@ struct ns_server { isc_boolean_t server_usehostname; char * server_id; /*%< User-specified server id */ - /*% + /*% * Current ACL environment. This defines the * current values of the localhost and localnets * ACLs. @@ -207,7 +207,8 @@ ns_server_status(ns_server_t *server, isc_buffer_t *text); * Enable or disable updates for a zone. */ isc_result_t -ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args); +ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args, + isc_buffer_t *text); /*% * Dump the current recursive queries. diff --git a/bin/named/interfacemgr.c b/bin/named/interfacemgr.c index 08d33d9912c5..a5fd53ea1162 100644 --- a/bin/named/interfacemgr.c +++ b/bin/named/interfacemgr.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2006, 2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2006, 2008, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: interfacemgr.c,v 1.76.18.11 2008/07/23 23:33:02 marka Exp $ */ +/* $Id: interfacemgr.c,v 1.76.18.13 2009/01/19 23:46:14 tbox Exp $ */ /*! \file */ @@ -522,7 +522,7 @@ setup_locals(ns_interfacemgr_t *mgr, isc_interface_t *interface) { result = isc_netaddr_masktoprefixlen(&interface->netmask, &prefixlen); - /* Non contigious netmasks not allowed by IPv6 arch. */ + /* Non contiguous netmasks not allowed by IPv6 arch. */ if (result != ISC_R_SUCCESS && family == AF_INET6) return (result); diff --git a/bin/named/log.c b/bin/named/log.c index af75baba1733..1bc6bef66f36 100644 --- a/bin/named/log.c +++ b/bin/named/log.c @@ -1,8 +1,8 @@ /* - * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2006, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: log.c,v 1.37.18.6 2006/06/09 00:54:08 marka Exp $ */ +/* $Id: log.c,v 1.37.18.9 2009/09/24 21:38:50 jinmei Exp $ */ /*! \file */ @@ -44,6 +44,7 @@ static isc_logcategory_t categories[] = { { "queries", 0 }, { "unmatched", 0 }, { "update-security", 0 }, + { "query-errors", 0 }, { NULL, 0 } }; @@ -120,7 +121,7 @@ ns_log_setdefaultchannels(isc_logconfig_t *lcfg) { /* * By default, the logging library makes "default_debug" log to * stderr. In BIND, we want to override this and log to named.run - * instead, unless the the -g option was given. + * instead, unless the -g option was given. */ if (! ns_g_logstderr) { destination.file.stream = NULL; diff --git a/bin/named/lwresd.8 b/bin/named/lwresd.8 index 827edcd65737..ab17033680b9 100644 --- a/bin/named/lwresd.8 +++ b/bin/named/lwresd.8 @@ -1,7 +1,7 @@ -.\" Copyright (C) 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2004, 2005, 2007-2009 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000, 2001 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: lwresd.8,v 1.15.18.13 2008/10/17 01:29:23 tbox Exp $ +.\" $Id: lwresd.8,v 1.15.18.15 2009/07/11 01:31:44 tbox Exp $ .\" .hy 0 .ad l @@ -42,7 +42,7 @@ is the daemon providing name lookup services to clients that use the BIND 9 ligh \fBlwresd\fR listens for resolver queries on a UDP port on the IPv4 loopback interface, 127.0.0.1. This means that \fBlwresd\fR -can only be used by processes running on the local machine. By default UDP port number 921 is used for lightweight resolver requests and responses. +can only be used by processes running on the local machine. By default, UDP port number 921 is used for lightweight resolver requests and responses. .PP Incoming lightweight resolver requests are decoded by the server which then resolves them using the DNS protocol. When the DNS lookup completes, \fBlwresd\fR @@ -217,7 +217,7 @@ The default process\-id file. .PP Internet Systems Consortium .SH "COPYRIGHT" -Copyright \(co 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC") +Copyright \(co 2004, 2005, 2007\-2009 Internet Systems Consortium, Inc. ("ISC") .br Copyright \(co 2000, 2001 Internet Software Consortium. .br diff --git a/bin/named/lwresd.docbook b/bin/named/lwresd.docbook index 6dd2c40adf61..e9f73d3184e4 100644 --- a/bin/named/lwresd.docbook +++ b/bin/named/lwresd.docbook @@ -2,7 +2,7 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> - + June 30, 2000 @@ -41,6 +41,7 @@ 2005 2007 2008 + 2009 Internet Systems Consortium, Inc. ("ISC") @@ -87,7 +88,7 @@ listens for resolver queries on a UDP port on the IPv4 loopback interface, 127.0.0.1. This means that lwresd can only be used by - processes running on the local machine. By default UDP port + processes running on the local machine. By default, UDP port number 921 is used for lightweight resolver requests and responses. diff --git a/bin/named/lwresd.html b/bin/named/lwresd.html index 463e6b0ee3cf..6e90486ffc96 100644 --- a/bin/named/lwresd.html +++ b/bin/named/lwresd.html @@ -1,8 +1,8 @@ - + @@ -32,7 +32,7 @@

lwresd [-c config-file] [-C config-file] [-d debug-level] [-f] [-g] [-i pid-file] [-m flag] [-n #cpus] [-P port] [-p port] [-s] [-t directory] [-u user] [-v] [-4] [-6]

-

DESCRIPTION

+

DESCRIPTION

lwresd is the daemon providing name lookup services to clients that use the BIND 9 lightweight resolver @@ -44,7 +44,7 @@ listens for resolver queries on a UDP port on the IPv4 loopback interface, 127.0.0.1. This means that lwresd can only be used by - processes running on the local machine. By default UDP port + processes running on the local machine. By default, UDP port number 921 is used for lightweight resolver requests and responses.

@@ -67,7 +67,7 @@

-

OPTIONS

+

OPTIONS

-4

@@ -197,7 +197,7 @@

-

FILES

+

FILES

/etc/resolv.conf

@@ -210,14 +210,14 @@

-

SEE ALSO

+

SEE ALSO

named(8), lwres(3), resolver(5).

-

AUTHOR

+

AUTHOR

Internet Systems Consortium

diff --git a/bin/named/main.c b/bin/named/main.c index d8b0a3345138..2dedf8324429 100644 --- a/bin/named/main.c +++ b/bin/named/main.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2006, 2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2006, 2008, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: main.c,v 1.136.18.21 2008/10/24 01:28:08 marka Exp $ */ +/* $Id: main.c,v 1.136.18.24 2009/04/03 20:17:59 marka Exp $ */ /*! \file */ @@ -139,7 +139,7 @@ assertion_failed(const char *file, int line, isc_assertiontype_t type, if (ns_g_lctx != NULL) { /* - * Reset the assetion callback in case it is the log + * Reset the assertion callback in case it is the log * routines causing the assertion. */ isc_assertion_setcallback(NULL); @@ -719,7 +719,7 @@ setup(void) { #ifdef DLZ /* - * Registyer any DLZ drivers. + * Register any DLZ drivers. */ result = dlz_drivers_init(); if (result != ISC_R_SUCCESS) @@ -851,10 +851,10 @@ main(int argc, char *argv[]) { * strings named.core | grep "named version:" */ strlcat(version, -#ifdef __DATE__ - "named version: BIND " VERSION " (" __DATE__ ")", -#else +#if defined(NO_VERSION_DATE) || !defined(__DATE__) "named version: BIND " VERSION, +#else + "named version: BIND " VERSION " (" __DATE__ ")", #endif sizeof(version)); result = isc_file_progname(*argv, program_name, sizeof(program_name)); diff --git a/bin/named/named.8 b/bin/named/named.8 index 9487dac2e178..74ad852ff23d 100644 --- a/bin/named/named.8 +++ b/bin/named/named.8 @@ -1,7 +1,7 @@ .\" Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named.8,v 1.20.18.16 2008/09/01 02:29:00 tbox Exp $ +.\" $Id: named.8,v 1.20.18.17 2009/07/11 01:31:44 tbox Exp $ .\" .hy 0 .ad l diff --git a/bin/named/named.conf.5 b/bin/named/named.conf.5 index a2ccbe07fb33..eaf7862c94a3 100644 --- a/bin/named/named.conf.5 +++ b/bin/named/named.conf.5 @@ -1,6 +1,6 @@ .\" Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -12,7 +12,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named.conf.5,v 1.1.2.27 2008/09/05 01:32:08 tbox Exp $ +.\" $Id: named.conf.5,v 1.1.2.28 2009/07/11 01:31:45 tbox Exp $ .\" .hy 0 .ad l diff --git a/bin/named/named.conf.html b/bin/named/named.conf.html index f729988d4da1..6eb7612390d1 100644 --- a/bin/named/named.conf.html +++ b/bin/named/named.conf.html @@ -1,7 +1,7 @@ - + diff --git a/bin/named/named.html b/bin/named/named.html index ed4f16a3e218..b787cd85e0c1 100644 --- a/bin/named/named.html +++ b/bin/named/named.html @@ -2,7 +2,7 @@ - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") - Copyright (C) 2000, 2001, 2003 Internet Software Consortium. - - - Permission to use, copy, modify, and distribute this software for any + - Permission to use, copy, modify, and/or distribute this software for any - purpose with or without fee is hereby granted, provided that the above - copyright notice and this permission notice appear in all copies. - @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> - + diff --git a/bin/named/query.c b/bin/named/query.c index 3992d6e92269..363c95fa670b 100644 --- a/bin/named/query.c +++ b/bin/named/query.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: query.c,v 1.257.18.46.2.1 2009/11/19 00:25:17 marka Exp $ */ +/* $Id: query.c,v 1.257.18.53 2009/12/30 08:55:48 jinmei Exp $ */ /*! \file */ @@ -116,13 +116,16 @@ typedef struct client_additionalctx { dns_rdataset_t *rdataset; } client_additionalctx_t; -static void +static isc_result_t query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype); static isc_boolean_t validate(ns_client_t *client, dns_db_t *db, dns_name_t *name, dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset); +static inline void +log_queryerror(ns_client_t *client, isc_result_t result, int line, int level); + /*% * Increment query statistics counters. */ @@ -165,8 +168,14 @@ query_send(ns_client_t *client) { } static void -query_error(ns_client_t *client, isc_result_t result) { +query_error(ns_client_t *client, isc_result_t result, int line) { + int loglevel = ISC_LOG_DEBUG(3); + + if (result == DNS_R_SERVFAIL) + loglevel = ISC_LOG_DEBUG(1); + inc_stats(client, dns_statscounter_failure); + log_queryerror(client, result, line, loglevel); ns_client_error(client, result); } @@ -942,7 +951,7 @@ query_getdb(ns_client_t *client, dns_name_t *name, dns_rdatatype_t qtype, zonep, dbp, versionp); #endif - /* If successfull, Transfer ownership of zone. */ + /* If successful, Transfer ownership of zone. */ if (result == ISC_R_SUCCESS) { #ifdef DLZ *zonep = zone; @@ -1159,7 +1168,7 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) { goto cleanup; /* - * Don't poision caches using the bailiwick protection model. + * Don't poison caches using the bailiwick protection model. */ if (!dns_name_issubdomain(name, dns_db_origin(client->query.gluedb))) goto cleanup; @@ -1633,7 +1642,7 @@ query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) { goto cleanup; /* - * Don't poision caches using the bailiwick protection model. + * Don't poison caches using the bailiwick protection model. */ if (!dns_name_issubdomain(name, dns_db_origin(client->query.gluedb))) goto cleanup; @@ -2293,7 +2302,7 @@ mark_secure(ns_client_t *client, dns_db_t *db, dns_name_t *name, /* * Find the secure key that corresponds to rrsig. - * Note: 'keyrdataset' maintains state between sucessive calls, + * Note: 'keyrdataset' maintains state between successive calls, * there may be multiple keys with the same keyid. * Return ISC_FALSE if we have exhausted all the possible keys. */ @@ -2685,7 +2694,7 @@ query_addwildcardproof(ns_client_t *client, dns_db_t *db, node = NULL; /* - * Get the NOQNAME proof then if !ispositve + * Get the NOQNAME proof then if !ispositive * get the NOWILDCARD proof. * * DNS_DBFIND_NOWILD finds the NSEC records that covers the @@ -2864,8 +2873,12 @@ query_addnxrrsetnsec(ns_client_t *client, dns_db_t *db, static void query_resume(isc_task_t *task, isc_event_t *event) { dns_fetchevent_t *devent = (dns_fetchevent_t *)event; + dns_fetch_t *fetch; ns_client_t *client; - isc_boolean_t fetch_cancelled, client_shuttingdown; + isc_boolean_t fetch_canceled, client_shuttingdown; + isc_result_t result; + isc_logcategory_t *logcategory = NS_LOGCATEGORY_QUERY_EERRORS; + int errorloglevel; /* * Resume a query after recursion. @@ -2886,30 +2899,31 @@ query_resume(isc_task_t *task, isc_event_t *event) { */ INSIST(devent->fetch == client->query.fetch); client->query.fetch = NULL; - fetch_cancelled = ISC_FALSE; + fetch_canceled = ISC_FALSE; /* * Update client->now. */ isc_stdtime_get(&client->now); } else { /* - * This is a fetch completion event for a cancelled fetch. + * This is a fetch completion event for a canceled fetch. * Clean up and don't resume the find. */ - fetch_cancelled = ISC_TRUE; + fetch_canceled = ISC_TRUE; } UNLOCK(&client->query.fetchlock); INSIST(client->query.fetch == NULL); client->query.attributes &= ~NS_QUERYATTR_RECURSING; - dns_resolver_destroyfetch(&devent->fetch); + fetch = devent->fetch; + devent->fetch = NULL; /* * If this client is shutting down, or this transaction * has timed out, do not resume the find. */ client_shuttingdown = ns_client_shuttingdown(client); - if (fetch_cancelled || client_shuttingdown) { + if (fetch_canceled || client_shuttingdown) { if (devent->node != NULL) dns_db_detachnode(devent->db, &devent->node); if (devent->db != NULL) @@ -2918,8 +2932,8 @@ query_resume(isc_task_t *task, isc_event_t *event) { if (devent->sigrdataset != NULL) query_putrdataset(client, &devent->sigrdataset); isc_event_free(&event); - if (fetch_cancelled) - query_error(client, DNS_R_SERVFAIL); + if (fetch_canceled) + query_error(client, DNS_R_SERVFAIL, __LINE__); else query_next(client, ISC_R_CANCELED); /* @@ -2927,8 +2941,22 @@ query_resume(isc_task_t *task, isc_event_t *event) { */ ns_client_detach(&client); } else { - query_find(client, devent, 0); + result = query_find(client, devent, 0); + if (result != ISC_R_SUCCESS) { + if (result == DNS_R_SERVFAIL) + errorloglevel = ISC_LOG_DEBUG(2); + else + errorloglevel = ISC_LOG_DEBUG(4); + if (isc_log_wouldlog(ns_g_lctx, errorloglevel)) { + dns_resolver_logfetch(fetch, ns_g_lctx, + logcategory, + NS_LOGMODULE_QUERY, + errorloglevel, ISC_FALSE); + } + } } + + dns_resolver_destroyfetch(&fetch); } static isc_result_t @@ -3055,6 +3083,7 @@ query_recurse(ns_client_t *client, dns_rdatatype_t qtype, dns_name_t *qdomain, do { \ eresult = r; \ want_restart = ISC_FALSE; \ + line = __LINE__; \ } while (0) /* @@ -3294,8 +3323,7 @@ warn_rfc1918(ns_client_t *client, dns_name_t *fname, dns_rdataset_t *rdataset) { RUNTIME_CHECK(result == ISC_R_SUCCESS); dns_rdataset_current(&found, &rdata); result = dns_rdata_tostruct(&rdata, &soa, NULL); - if (result != ISC_R_SUCCESS) - return; + RUNTIME_CHECK(result == ISC_R_SUCCESS); if (dns_name_equal(&soa.origin, &prisoner) && dns_name_equal(&soa.contact, &hostmaster)) { char buf[DNS_NAME_FORMATSIZE]; @@ -3317,7 +3345,7 @@ warn_rfc1918(ns_client_t *client, dns_name_t *fname, dns_rdataset_t *rdataset) { * If 'event' is non-NULL, we are returning from recursion and 'qtype' * is ignored. Otherwise, 'qtype' is the query type. */ -static void +static isc_result_t query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) { dns_db_t *db, *zdb; @@ -3346,8 +3374,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) isc_boolean_t empty_wild; dns_rdataset_t *noqname; isc_boolean_t resuming; - dns_rdataset_t tmprdataset; - unsigned int dboptions; + int line = -1; CTRACE("query_find"); @@ -3559,49 +3586,9 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) /* * Now look for an answer in the database. */ - dboptions = client->query.dboptions; - if (sigrdataset == NULL && client->view->enablednssec) { - /* - * If the client doesn't want DNSSEC we still want to - * look for any data pending validation to save a remote - * lookup if possible. - */ - dns_rdataset_init(&tmprdataset); - sigrdataset = &tmprdataset; - dboptions |= DNS_DBFIND_PENDINGOK; - } - refind: result = dns_db_find(db, client->query.qname, version, type, - dboptions, client->now, &node, fname, - rdataset, sigrdataset); - /* - * If we have found pending data try to validate it. - * If the data does not validate as secure and we can't - * use the unvalidated data requery the database with - * pending disabled to prevent infinite looping. - */ - if (result != ISC_R_SUCCESS || !DNS_TRUST_PENDING(rdataset->trust)) - goto validation_done; - if (validate(client, db, fname, rdataset, sigrdataset)) - goto validation_done; - if (rdataset->trust != dns_trust_pending_answer || - !PENDINGOK(client->query.dboptions)) { - dns_rdataset_disassociate(rdataset); - if (sigrdataset != NULL && - dns_rdataset_isassociated(sigrdataset)) - dns_rdataset_disassociate(sigrdataset); - if (sigrdataset == &tmprdataset) - sigrdataset = NULL; - dns_db_detachnode(db, &node); - dboptions &= ~DNS_DBFIND_PENDINGOK; - goto refind; - } - validation_done: - if (sigrdataset == &tmprdataset) { - if (dns_rdataset_isassociated(sigrdataset)) - dns_rdataset_disassociate(sigrdataset); - sigrdataset = NULL; - } + client->query.dboptions, client->now, + &node, fname, rdataset, sigrdataset); resume: CTRACE("query_find: resume"); @@ -4432,7 +4419,8 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) * or if the client requested recursion and thus wanted * the complete answer, send an error response. */ - query_error(client, eresult); + INSIST(line >= 0); + query_error(client, eresult, line); } ns_client_detach(&client); } else if (!RECURSING(client)) { @@ -4449,7 +4437,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) * is in the glue sort it to the start of the additional * section. */ - if (client->message->counts[DNS_SECTION_ANSWER] == 0 && + if (ISC_LIST_EMPTY(client->message->sections[DNS_SECTION_ANSWER]) && client->message->rcode == dns_rcode_noerror && (qtype == dns_rdatatype_a || qtype == dns_rdatatype_aaaa)) answer_in_glue(client, qtype); @@ -4458,10 +4446,22 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) client->view->auth_nxdomain == ISC_TRUE) client->message->flags |= DNS_MESSAGEFLAG_AA; + /* + * If the response is somehow unexpected for the client and this + * is a result of recursion, return an error to the caller + * to indicate it may need to be logged. + */ + if (resuming && + (ISC_LIST_EMPTY(client->message->sections[DNS_SECTION_ANSWER]) || + client->message->rcode != dns_rcode_noerror)) + eresult = ISC_R_FAILURE; + query_send(client); ns_client_detach(&client); } CTRACE("query_find: done"); + + return (eresult); } static inline void @@ -4488,6 +4488,48 @@ log_query(ns_client_t *client) { (client->opt != NULL) ? "E" : ""); } +static inline void +log_queryerror(ns_client_t *client, isc_result_t result, int line, int level) { + char namebuf[DNS_NAME_FORMATSIZE]; + char typename[DNS_RDATATYPE_FORMATSIZE]; + char classname[DNS_RDATACLASS_FORMATSIZE]; + const char *namep, *typep, *classp, *sep1, *sep2; + dns_rdataset_t *rdataset; + + if (!isc_log_wouldlog(ns_g_lctx, level)) + return; + + namep = typep = classp = sep1 = sep2 = ""; + + /* + * Query errors can happen for various reasons. In some cases we cannot + * even assume the query contains a valid question section, so we should + * expect exceptional cases. + */ + if (client->query.origqname != NULL) { + dns_name_format(client->query.origqname, namebuf, + sizeof(namebuf)); + namep = namebuf; + sep1 = " for "; + + rdataset = ISC_LIST_HEAD(client->query.origqname->list); + if (rdataset != NULL) { + dns_rdataclass_format(rdataset->rdclass, classname, + sizeof(classname)); + classp = classname; + dns_rdatatype_format(rdataset->type, typename, + sizeof(typename)); + typep = typename; + sep2 = "/"; + } + } + + ns_client_log(client, NS_LOGCATEGORY_QUERY_EERRORS, NS_LOGMODULE_QUERY, + level, "query failed (%s)%s%s%s%s%s%s at %s:%d", + isc_result_totext(result), sep1, namep, sep2, + classp, sep2, typep, __FILE__, line); +} + void ns_query_start(ns_client_t *client) { isc_result_t result; @@ -4548,7 +4590,7 @@ ns_query_start(ns_client_t *client) { */ result = dns_message_firstname(message, DNS_SECTION_QUESTION); if (result != ISC_R_SUCCESS) { - query_error(client, result); + query_error(client, result, __LINE__); return; } dns_message_currentname(message, DNS_SECTION_QUESTION, @@ -4561,9 +4603,9 @@ ns_query_start(ns_client_t *client) { * There's more than one QNAME in the question * section. */ - query_error(client, DNS_R_FORMERR); + query_error(client, DNS_R_FORMERR, __LINE__); } else - query_error(client, result); + query_error(client, result, __LINE__); return; } @@ -4574,7 +4616,7 @@ ns_query_start(ns_client_t *client) { * Check for multiple question queries, since edns1 is dead. */ if (message->counts[DNS_SECTION_QUESTION] > 1) { - query_error(client, DNS_R_FORMERR); + query_error(client, DNS_R_FORMERR, __LINE__); return; } @@ -4594,7 +4636,7 @@ ns_query_start(ns_client_t *client) { return; case dns_rdatatype_maila: case dns_rdatatype_mailb: - query_error(client, DNS_R_NOTIMP); + query_error(client, DNS_R_NOTIMP, __LINE__); return; case dns_rdatatype_tkey: result = dns_tkey_processquery(client->message, @@ -4603,10 +4645,10 @@ ns_query_start(ns_client_t *client) { if (result == ISC_R_SUCCESS) query_send(client); else - query_error(client, result); + query_error(client, result, __LINE__); return; default: /* TSIG, etc. */ - query_error(client, DNS_R_FORMERR); + query_error(client, DNS_R_FORMERR, __LINE__); return; } } @@ -4667,5 +4709,5 @@ ns_query_start(ns_client_t *client) { qclient = NULL; ns_client_attach(client, &qclient); - query_find(qclient, NULL, qtype); + (void)query_find(qclient, NULL, qtype); } diff --git a/bin/named/server.c b/bin/named/server.c index 784ff94d3414..7bb2a6e0e298 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.419.18.68 2008/09/04 23:46:08 tbox Exp $ */ +/* $Id: server.c,v 1.419.18.75 2009/07/11 04:30:49 marka Exp $ */ /*! \file */ @@ -209,7 +209,7 @@ static const struct { /* Local IPv6 Unicast Addresses */ { "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA", ISC_FALSE }, { "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA", ISC_FALSE }, - /* LOCALLY ASSIGNED LOCAL ADDRES S SCOPE */ + /* LOCALLY ASSIGNED LOCAL ADDRESS SCOPE */ { "D.F.IP6.ARPA", ISC_FALSE }, { "8.E.F.IP6.ARPA", ISC_FALSE }, /* LINK LOCAL */ { "9.E.F.IP6.ARPA", ISC_FALSE }, /* LINK LOCAL */ @@ -251,9 +251,8 @@ static void end_reserved_dispatches(ns_server_t *server, isc_boolean_t all); /*% - * Configure a single view ACL at '*aclp'. Get its configuration by - * calling 'getvcacl' (for per-view configuration) and maybe 'getscacl' - * (for a global default). + * Configure a single view ACL at '*aclp'. Get its configuration from + * 'vconfig' (for per-view configuration) and maybe from 'config' */ static isc_result_t configure_view_acl(const cfg_obj_t *vconfig, const cfg_obj_t *config, @@ -902,6 +901,23 @@ check_dbtype(dns_zone_t **zonep, unsigned int dbtypec, const char **dbargv, } +static isc_boolean_t +cache_reusable(dns_view_t *originview, dns_view_t *view, + isc_boolean_t new_zero_no_soattl) +{ + if (originview->checknames != view->checknames || + dns_resolver_getzeronosoattl(originview->resolver) != + new_zero_no_soattl || + originview->acceptexpired != view->acceptexpired || + originview->enablevalidation != view->enablevalidation || + originview->maxcachettl != view->maxcachettl || + originview->maxncachettl != view->maxncachettl) { + return (ISC_FALSE); + } + + return (ISC_TRUE); +} + /* * Configure 'view' according to 'vconfig', taking defaults from 'config' * where values are missing in 'vconfig'. @@ -956,6 +972,7 @@ configure_view(dns_view_t *view, const cfg_obj_t *config, isc_boolean_t rfc1918; isc_boolean_t empty_zones_enable; const cfg_obj_t *disablelist = NULL; + isc_boolean_t zero_no_soattl; REQUIRE(DNS_VIEW_VALID(view)); @@ -1095,6 +1112,55 @@ configure_view(dns_view_t *view, const cfg_obj_t *config, } #endif + /* + * Obtain configuration parameters that affect the decision of whether + * we can reuse/share an existing cache. + */ + /* Check-names. */ + obj = NULL; + result = ns_checknames_get(maps, "response", &obj); + INSIST(result == ISC_R_SUCCESS); + + str = cfg_obj_asstring(obj); + if (strcasecmp(str, "fail") == 0) { + check |= DNS_RESOLVER_CHECKNAMES | + DNS_RESOLVER_CHECKNAMESFAIL; + view->checknames = ISC_TRUE; + } else if (strcasecmp(str, "warn") == 0) { + check |= DNS_RESOLVER_CHECKNAMES; + view->checknames = ISC_FALSE; + } else if (strcasecmp(str, "ignore") == 0) { + view->checknames = ISC_FALSE; + } else + INSIST(0); + + obj = NULL; + result = ns_config_get(maps, "zero-no-soa-ttl-cache", &obj); + INSIST(result == ISC_R_SUCCESS); + zero_no_soattl = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "dnssec-accept-expired", &obj); + INSIST(result == ISC_R_SUCCESS); + view->acceptexpired = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "dnssec-validation", &obj); + INSIST(result == ISC_R_SUCCESS); + view->enablevalidation = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "max-cache-ttl", &obj); + INSIST(result == ISC_R_SUCCESS); + view->maxcachettl = cfg_obj_asuint32(obj); + + obj = NULL; + result = ns_config_get(maps, "max-ncache-ttl", &obj); + INSIST(result == ISC_R_SUCCESS); + view->maxncachettl = cfg_obj_asuint32(obj); + if (view->maxncachettl > 7 * 24 * 3600) + view->maxncachettl = 7 * 24 * 3600; + /* * Configure the view's cache. Try to reuse an existing * cache if possible, otherwise create a new cache. @@ -1114,14 +1180,23 @@ configure_view(dns_view_t *view, const cfg_obj_t *config, if (result != ISC_R_NOTFOUND && result != ISC_R_SUCCESS) goto cleanup; if (pview != NULL) { - INSIST(pview->cache != NULL); - isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, - NS_LOGMODULE_SERVER, ISC_LOG_DEBUG(3), - "reusing existing cache"); - reused_cache = ISC_TRUE; - dns_cache_attach(pview->cache, &cache); + if (cache_reusable(pview, view, zero_no_soattl)) { + INSIST(pview->cache != NULL); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_DEBUG(3), + "reusing existing cache"); + reused_cache = ISC_TRUE; + dns_cache_attach(pview->cache, &cache); + } else { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_DEBUG(1), + "cache cannot be reused for view %s " + "due to configuration parameter mismatch", + view->name); + } dns_view_detach(&pview); - } else { + } + if (cache == NULL) { CHECK(isc_mem_create(0, 0, &cmctx)); CHECK(dns_cache_create(cmctx, ns_g_taskmgr, ns_g_timermgr, view->rdclass, "rbt", 0, NULL, &cache)); @@ -1235,11 +1310,6 @@ configure_view(dns_view_t *view, const cfg_obj_t *config, lame_ttl = 1800; dns_resolver_setlamettl(view->resolver, lame_ttl); - obj = NULL; - result = ns_config_get(maps, "zero-no-soa-ttl-cache", &obj); - INSIST(result == ISC_R_SUCCESS); - dns_resolver_setzeronosoattl(view->resolver, cfg_obj_asboolean(obj)); - /* * Set the resolver's EDNS UDP size. */ @@ -1491,10 +1561,11 @@ configure_view(dns_view_t *view, const cfg_obj_t *config, */ if (view->queryacl == NULL && view->recursionacl != NULL) dns_acl_attach(view->recursionacl, &view->queryacl); - if (view->queryacl == NULL) + if (view->queryacl == NULL && view->recursion) CHECK(configure_view_acl(vconfig, config, "allow-query", actx, ns_g_mctx, &view->queryacl)); - if (view->recursionacl == NULL && view->queryacl != NULL) + if (view->recursion && + view->recursionacl == NULL && view->queryacl != NULL) dns_acl_attach(view->queryacl, &view->recursionacl); /* @@ -1503,10 +1574,18 @@ configure_view(dns_view_t *view, const cfg_obj_t *config, if (view->recursionacl == NULL && view->recursion) CHECK(configure_view_acl(NULL, ns_g_config, "allow-recursion", actx, ns_g_mctx, &view->recursionacl)); - if (view->queryacl == NULL) - CHECK(configure_view_acl(NULL, ns_g_config, - "allow-query-cache", actx, - ns_g_mctx, &view->queryacl)); + if (view->queryacl == NULL) { + if (view->recursion) + CHECK(configure_view_acl(NULL, ns_g_config, + "allow-query-cache", actx, + ns_g_mctx, &view->queryacl)); + else { + if (view->queryacl != NULL) + dns_acl_detach(&view->queryacl); + CHECK(dns_acl_none(ns_g_mctx, &view->queryacl)); + } + + } CHECK(configure_view_acl(vconfig, config, "sortlist", actx, ns_g_mctx, &view->sortlist)); @@ -1538,16 +1617,6 @@ configure_view(dns_view_t *view, const cfg_obj_t *config, INSIST(result == ISC_R_SUCCESS); view->enablednssec = cfg_obj_asboolean(obj); - obj = NULL; - result = ns_config_get(maps, "dnssec-accept-expired", &obj); - INSIST(result == ISC_R_SUCCESS); - view->acceptexpired = cfg_obj_asboolean(obj); - - obj = NULL; - result = ns_config_get(maps, "dnssec-validation", &obj); - INSIST(result == ISC_R_SUCCESS); - view->enablevalidation = cfg_obj_asboolean(obj); - obj = NULL; result = ns_config_get(maps, "dnssec-lookaside", &obj); if (result == ISC_R_SUCCESS) { @@ -1602,18 +1671,6 @@ configure_view(dns_view_t *view, const cfg_obj_t *config, if (result == ISC_R_SUCCESS) CHECK(mustbesecure(obj, view->resolver)); - obj = NULL; - result = ns_config_get(maps, "max-cache-ttl", &obj); - INSIST(result == ISC_R_SUCCESS); - view->maxcachettl = cfg_obj_asuint32(obj); - - obj = NULL; - result = ns_config_get(maps, "max-ncache-ttl", &obj); - INSIST(result == ISC_R_SUCCESS); - view->maxncachettl = cfg_obj_asuint32(obj); - if (view->maxncachettl > 7 * 24 * 3600) - view->maxncachettl = 7 * 24 * 3600; - obj = NULL; result = ns_config_get(maps, "preferred-glue", &obj); if (result == ISC_R_SUCCESS) { @@ -1959,6 +2016,8 @@ configure_forward(const cfg_obj_t *config, dns_view_t *view, dns_name_t *origin, isc_result_t result; in_port_t port; + ISC_LIST_INIT(addresses); + /* * Determine which port to send forwarded requests to. */ @@ -1984,8 +2043,6 @@ configure_forward(const cfg_obj_t *config, dns_view_t *view, dns_name_t *origin, if (forwarders != NULL) faddresses = cfg_tuple_get(forwarders, "addresses"); - ISC_LIST_INIT(addresses); - for (element = cfg_list_first(faddresses); element != NULL; element = cfg_list_next(element)) @@ -4884,7 +4941,9 @@ ns_server_status(ns_server_t *server, isc_buffer_t *text) { * Act on a "freeze" or "thaw" command from the command channel. */ isc_result_t -ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) { +ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args, + isc_buffer_t *text) +{ isc_result_t result, tresult; dns_zone_t *zone = NULL; dns_zonetype_t type; @@ -4894,6 +4953,7 @@ ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) { char *journal; const char *vname, *sep; isc_boolean_t frozen; + const char *msg = NULL; result = zone_from_args(server, args, &zone); if (result != ISC_R_SUCCESS) @@ -4926,25 +4986,47 @@ ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) { frozen = dns_zone_getupdatedisabled(zone); if (freeze) { - if (frozen) + if (frozen) { + msg = "WARNING: The zone was already frozen.\n" + "Someone else may be editing it or " + "it may still be re-loading."; result = DNS_R_FROZEN; - if (result == ISC_R_SUCCESS) + } + if (result == ISC_R_SUCCESS) { result = dns_zone_flush(zone); + if (result != ISC_R_SUCCESS) + msg = "Flushing the zone updates to " + "disk failed."; + } if (result == ISC_R_SUCCESS) { journal = dns_zone_getjournal(zone); if (journal != NULL) (void)isc_file_remove(journal); } + if (result == ISC_R_SUCCESS) + dns_zone_setupdatedisabled(zone, freeze); } else { if (frozen) { - result = dns_zone_load(zone); - if (result == DNS_R_CONTINUE || - result == DNS_R_UPTODATE) + result = dns_zone_loadandthaw(zone); + switch (result) { + case ISC_R_SUCCESS: + case DNS_R_UPTODATE: + msg = "The zone reload and thaw was " + "successful."; + result = ISC_R_SUCCESS; + break; + case DNS_R_CONTINUE: + msg = "A zone reload and thaw was started.\n" + "Check the logs to see the result."; result = ISC_R_SUCCESS; + break; + } } } - if (result == ISC_R_SUCCESS) - dns_zone_setupdatedisabled(zone, freeze); + + if (msg != NULL && strlen(msg) < isc_buffer_availablelength(text)) + isc_buffer_putmem(text, (const unsigned char *)msg, + strlen(msg) + 1); view = dns_zone_getview(zone); if (strcmp(view->name, "_bind") == 0 || diff --git a/bin/named/unix/os.c b/bin/named/unix/os.c index ad26a8e9b0e9..c41692df2f9a 100644 --- a/bin/named/unix/os.c +++ b/bin/named/unix/os.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2006, 2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2006, 2008, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: os.c,v 1.66.18.17 2008/10/24 01:43:17 tbox Exp $ */ +/* $Id: os.c,v 1.66.18.21 2009/03/02 03:06:25 marka Exp $ */ /*! \file */ @@ -405,10 +405,12 @@ ns_os_started(void) { char buf = 0; /* - * Signal to the parent that we stated successfully. + * Signal to the parent that we started successfully. */ if (dfd[0] != -1 && dfd[1] != -1) { - write(dfd[1], &buf, 1); + if (write(dfd[1], &buf, 1) != 1) + ns_main_earlyfatal("unable to signal parent that we " + "otherwise started successfully."); close(dfd[1]); dfd[0] = dfd[1] = -1; } @@ -448,10 +450,14 @@ ns_os_chroot(const char *root) { ns_smf_chroot = 0; #endif if (root != NULL) { +#ifdef HAVE_CHROOT if (chroot(root) < 0) { isc__strerror(errno, strbuf, sizeof(strbuf)); ns_main_earlyfatal("chroot(): %s", strbuf); } +#else + ns_main_earlyfatal("chroot(): disabled"); +#endif if (chdir("/") < 0) { isc__strerror(errno, strbuf, sizeof(strbuf)); ns_main_earlyfatal("chdir(/): %s", strbuf); @@ -584,7 +590,8 @@ safe_open(const char *filename, isc_boolean_t append) { fd = open(filename, O_WRONLY|O_CREAT|O_APPEND, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH); else { - (void)unlink(filename); + if (unlink(filename) < 0 && errno != ENOENT) + return (-1); fd = open(filename, O_WRONLY|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH); } @@ -593,8 +600,11 @@ safe_open(const char *filename, isc_boolean_t append) { static void cleanup_pidfile(void) { + int n; if (pidfile != NULL) { - (void)unlink(pidfile); + n = unlink(pidfile); + if (n == -1 && errno != ENOENT) + ns_main_earlywarning("unlink '%s': failed", pidfile); free(pidfile); } pidfile = NULL; diff --git a/bin/named/update.c b/bin/named/update.c index ddb426afb202..fddebe359804 100644 --- a/bin/named/update.c +++ b/bin/named/update.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: update.c,v 1.109.18.27.4.1 2009/07/28 13:57:27 marka Exp $ */ +/* $Id: update.c,v 1.109.18.33 2009/07/28 15:57:26 marka Exp $ */ #include @@ -619,6 +619,45 @@ rrset_exists(dns_db_t *db, dns_dbversion_t *ver, RETURN_EXISTENCE_FLAG; } +/*% + * Set '*visible' to true if the RRset exists and is part of the + * visible zone. Otherwise '*visible' is set to false unless a + * error occurs. + */ +static isc_result_t +rrset_visible(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, + dns_rdatatype_t type, isc_boolean_t *visible) +{ + isc_result_t result; + dns_fixedname_t fixed; + + dns_fixedname_init(&fixed); + result = dns_db_find(db, name, ver, type, DNS_DBFIND_NOWILD, + (isc_stdtime_t) 0, NULL, + dns_fixedname_name(&fixed), NULL, NULL); + switch (result) { + case ISC_R_SUCCESS: + *visible = ISC_TRUE; + break; + /* + * Glue, obscured, deleted or replaced records. + */ + case DNS_R_DELEGATION: + case DNS_R_DNAME: + case DNS_R_CNAME: + case DNS_R_NXDOMAIN: + case DNS_R_NXRRSET: + case DNS_R_EMPTYNAME: + case DNS_R_COVERINGNSEC: + *visible = ISC_FALSE; + result = ISC_R_SUCCESS; + break; + default: + break; + } + return (result); +} + /*% * Helper function for cname_incompatible_rrset_exists. */ @@ -738,8 +777,8 @@ ssu_checkall(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, * In the RFC2136 section 3.2.5, this is the pseudocode involving * a variable called "temp", a mapping of tuples to rrsets. * - * Here, we represent the "temp" data structure as (non-minimial) "dns_diff_t" - * where each typle has op==DNS_DIFFOP_EXISTS. + * Here, we represent the "temp" data structure as (non-minimal) "dns_diff_t" + * where each tuple has op==DNS_DIFFOP_EXISTS. */ @@ -1011,6 +1050,16 @@ true_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) { return (ISC_TRUE); } +/*% + * Return true if the record is a RRSIG. + */ +static isc_boolean_t +rrsig_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) { + UNUSED(update_rr); + return ((db_rr->type == dns_rdatatype_rrsig) ? + ISC_TRUE : ISC_FALSE); +} + /*% * Return true iff the two RRs have identical rdata. */ @@ -1429,10 +1478,9 @@ uniqify_name_list(dns_diff_t *list) { return (result); } - static isc_result_t -is_glue(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, - isc_boolean_t *flag) +is_active(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, + isc_boolean_t *flag, isc_boolean_t *cut, isc_boolean_t *unsecure) { isc_result_t result; dns_fixedname_t foundname; @@ -1442,8 +1490,11 @@ is_glue(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, (isc_stdtime_t) 0, NULL, dns_fixedname_name(&foundname), NULL, NULL); - if (result == ISC_R_SUCCESS) { + if (result == ISC_R_SUCCESS || result == DNS_R_EMPTYNAME) { *flag = ISC_FALSE; + *cut = ISC_FALSE; + if (unsecure != NULL) + *unsecure = ISC_FALSE; return (ISC_R_SUCCESS); } else if (result == DNS_R_ZONECUT) { /* @@ -1451,11 +1502,36 @@ is_glue(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, * non-delegation will be omitted from the type bit map. */ *flag = ISC_FALSE; + *cut = ISC_TRUE; + if (unsecure != NULL) { + /* + * We are at the zonecut. Check to see if there + * is a DS RRset. + */ + if (dns_db_find(db, name, ver, dns_rdatatype_ds, 0, + (isc_stdtime_t) 0, NULL, + dns_fixedname_name(&foundname), + NULL, NULL) == DNS_R_NXRRSET) + *unsecure = ISC_TRUE; + else + *unsecure = ISC_FALSE; + } return (ISC_R_SUCCESS); - } else if (result == DNS_R_GLUE || result == DNS_R_DNAME) { - *flag = ISC_TRUE; + } else if (result == DNS_R_GLUE || result == DNS_R_DNAME || + result == DNS_R_DELEGATION || result == DNS_R_NXDOMAIN) { + *flag = ISC_FALSE; + *cut = ISC_FALSE; + if (unsecure != NULL) + *unsecure = ISC_FALSE; return (ISC_R_SUCCESS); } else { + /* + * Silence compiler. + */ + *flag = ISC_FALSE; + *cut = ISC_FALSE; + if (unsecure != NULL) + *unsecure = ISC_FALSE; return (result); } } @@ -1659,7 +1735,7 @@ static isc_result_t add_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, dns_rdatatype_t type, dns_diff_t *diff, dst_key_t **keys, unsigned int nkeys, - isc_mem_t *mctx, isc_stdtime_t inception, isc_stdtime_t expire, + isc_stdtime_t inception, isc_stdtime_t expire, isc_boolean_t check_ksk) { isc_result_t result; @@ -1670,6 +1746,7 @@ add_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, unsigned char data[1024]; /* XXX */ unsigned int i; isc_boolean_t added_sig = ISC_FALSE; + isc_mem_t *mctx = client->mctx; dns_rdataset_init(&rdataset); isc_buffer_init(&buffer, data, sizeof(data)); @@ -1717,9 +1794,76 @@ add_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, return (result); } +static isc_result_t +add_exposed_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, + dns_dbversion_t *ver, dns_name_t *name, isc_boolean_t cut, + dns_diff_t *diff, dst_key_t **keys, unsigned int nkeys, + isc_stdtime_t inception, isc_stdtime_t expire, + isc_boolean_t check_ksk) +{ + isc_result_t result; + dns_dbnode_t *node; + dns_rdatasetiter_t *iter; + + node = NULL; + result = dns_db_findnode(db, name, ISC_FALSE, &node); + if (result == ISC_R_NOTFOUND) + return (ISC_R_SUCCESS); + if (result != ISC_R_SUCCESS) + return (result); + + iter = NULL; + result = dns_db_allrdatasets(db, node, ver, + (isc_stdtime_t) 0, &iter); + if (result != ISC_R_SUCCESS) + goto cleanup_node; + + for (result = dns_rdatasetiter_first(iter); + result == ISC_R_SUCCESS; + result = dns_rdatasetiter_next(iter)) + { + dns_rdataset_t rdataset; + dns_rdatatype_t type; + isc_boolean_t flag; + + dns_rdataset_init(&rdataset); + dns_rdatasetiter_current(iter, &rdataset); + type = rdataset.type; + dns_rdataset_disassociate(&rdataset); + + /* + * We don't need to sign unsigned NSEC records at the cut + * as they are handled elsewhere. + */ + if ((type == dns_rdatatype_rrsig) || + (cut && type != dns_rdatatype_ds)) + continue; + result = rrset_exists(db, ver, name, dns_rdatatype_rrsig, + type, &flag); + if (result != ISC_R_SUCCESS) + goto cleanup_iterator; + if (flag) + continue;; + result = add_sigs(client, zone, db, ver, name, type, diff, + keys, nkeys, inception, expire, check_ksk); + if (result != ISC_R_SUCCESS) + goto cleanup_iterator; + } + if (result == ISC_R_NOMORE) + result = ISC_R_SUCCESS; + + cleanup_iterator: + dns_rdatasetiter_destroy(&iter); + + cleanup_node: + dns_db_detachnode(db, &node); + + return (result); +} + /*% * Update RRSIG and NSEC records affected by an update. The original - * update, including the SOA serial update but exluding the RRSIG & NSEC + * update, including the SOA serial update but excluding the RRSIG & NSEC * changes, is in "diff" and has already been applied to "newver" of "db". * The database version prior to the update is "oldver". * @@ -1751,6 +1895,7 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, dns_rdataset_t rdataset; dns_dbnode_t *node = NULL; isc_boolean_t check_ksk; + isc_boolean_t cut; dns_diff_init(client->mctx, &diffnames); dns_diff_init(client->mctx, &affected); @@ -1774,7 +1919,7 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, /* * Do we look at the KSK flag on the DNSKEY to determining which * keys sign which RRsets? First check the zone option then - * check the keys flags to make sure atleast one has a ksk set + * check the keys flags to make sure at least one has a ksk set * and one doesn't. */ check_ksk = ISC_TF((dns_zone_getoptions(zone) & @@ -1833,15 +1978,15 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, NULL, &sig_diff)); /* - * If this RRset still exists after the update, + * If this RRset is still visible after the update, * add a new signature for it. */ - CHECK(rrset_exists(db, newver, name, type, 0, &flag)); + CHECK(rrset_visible(db, newver, name, type, &flag)); if (flag) { CHECK(add_sigs(client, zone, db, newver, name, type, &sig_diff, zone_keys, - nkeys, client->mctx, inception, - expire, check_ksk)); + nkeys, inception, expire, + check_ksk)); } skip: /* Skip any other updates to the same RRset. */ @@ -1948,27 +2093,34 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, t = ISC_LIST_NEXT(t, link)) { isc_boolean_t exists; - CHECK(name_exists(db, newver, &t->name, &exists)); + dns_name_t *name = &t->name; + + CHECK(name_exists(db, newver, name, &exists)); if (! exists) continue; - CHECK(is_glue(db, newver, &t->name, &flag)); - if (flag) { + CHECK(is_active(db, newver, name, &flag, &cut, NULL)); + if (!flag) { /* * This name is obscured. Delete any * existing NSEC record. */ - CHECK(delete_if(true_p, db, newver, &t->name, + CHECK(delete_if(true_p, db, newver, name, dns_rdatatype_nsec, 0, NULL, &nsec_diff)); + CHECK(delete_if(rrsig_p, db, newver, name, + dns_rdatatype_any, 0, NULL, diff)); } else { /* * This name is not obscured. It should have a NSEC. */ - CHECK(rrset_exists(db, newver, &t->name, + CHECK(rrset_exists(db, newver, name, dns_rdatatype_nsec, 0, &flag)); if (! flag) CHECK(add_placeholder_nsec(db, newver, &t->name, diff)); + CHECK(add_exposed_sigs(client, zone, db, newver, name, + cut, diff, zone_keys, nkeys, + inception, expire, check_ksk)); } } @@ -2026,8 +2178,8 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, } else if (t->op == DNS_DIFFOP_ADD) { CHECK(add_sigs(client, zone, db, newver, &t->name, dns_rdatatype_nsec, &sig_diff, - zone_keys, nkeys, client->mctx, - inception, expire, check_ksk)); + zone_keys, nkeys, inception, expire, + check_ksk)); } else { INSIST(0); } @@ -2201,29 +2353,37 @@ ns_update_start(ns_client_t *client, isc_result_t sigresult) { static isc_result_t remove_orphaned_ds(dns_db_t *db, dns_dbversion_t *newver, dns_diff_t *diff) { isc_result_t result; - isc_boolean_t ns_exists, ds_exists; - dns_difftuple_t *t; + isc_boolean_t ns_exists; + dns_difftuple_t *tupple; + dns_diff_t temp_diff; - for (t = ISC_LIST_HEAD(diff->tuples); - t != NULL; - t = ISC_LIST_NEXT(t, link)) { - if (t->op != DNS_DIFFOP_ADD || - t->rdata.type != dns_rdatatype_ns) - continue; - CHECK(rrset_exists(db, newver, &t->name, dns_rdatatype_ns, 0, - &ns_exists)); - if (ns_exists) + dns_diff_init(diff->mctx, &temp_diff); + + for (tupple = ISC_LIST_HEAD(diff->tuples); + tupple != NULL; + tupple = ISC_LIST_NEXT(tupple, link)) { + if (!((tupple->op == DNS_DIFFOP_DEL && + tupple->rdata.type == dns_rdatatype_ns) || + (tupple->op == DNS_DIFFOP_ADD && + tupple->rdata.type == dns_rdatatype_ds))) continue; - CHECK(rrset_exists(db, newver, &t->name, dns_rdatatype_ds, 0, - &ds_exists)); - if (!ds_exists) + CHECK(rrset_exists(db, newver, &tupple->name, + dns_rdatatype_ns, 0, &ns_exists)); + if (ns_exists && + !dns_name_equal(&tupple->name, dns_db_origin(db))) continue; - CHECK(delete_if(true_p, db, newver, &t->name, - dns_rdatatype_ds, 0, NULL, diff)); + CHECK(delete_if(true_p, db, newver, &tupple->name, + dns_rdatatype_ds, 0, NULL, &temp_diff)); } - return (ISC_R_SUCCESS); + result = ISC_R_SUCCESS; failure: + for (tupple = ISC_LIST_HEAD(temp_diff.tuples); + tupple != NULL; + tupple = ISC_LIST_HEAD(temp_diff.tuples)) { + ISC_LIST_UNLINK(temp_diff.tuples, tupple, link); + dns_diff_appendminimal(diff, &tupple); + } return (result); } diff --git a/bin/named/xfrout.c b/bin/named/xfrout.c index 9fe90a2b47b9..ff19b7eecf8c 100644 --- a/bin/named/xfrout.c +++ b/bin/named/xfrout.c @@ -1,8 +1,8 @@ /* - * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2006, 2008, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: xfrout.c,v 1.115.18.8 2006/03/05 23:58:51 marka Exp $ */ +/* $Id: xfrout.c,v 1.115.18.13 2009/01/19 00:36:26 marka Exp $ */ #include @@ -51,7 +51,7 @@ #include #include -/*! \file +/*! \file * \brief * Outgoing AXFR and IXFR. */ @@ -86,7 +86,7 @@ ns_client_log(client, DNS_LOGCATEGORY_XFER_OUT, \ NS_LOGMODULE_XFER_OUT, ISC_LOG_INFO, \ "bad zone transfer request: %s (%s)", \ - msg, isc_result_totext(code)); \ + msg, isc_result_totext(code)); \ if (result != ISC_R_SUCCESS) goto failure; \ } while (0) @@ -100,12 +100,12 @@ ns_client_log(client, DNS_LOGCATEGORY_XFER_OUT, \ NS_LOGMODULE_XFER_OUT, ISC_LOG_INFO, \ "bad zone transfer request: '%s/%s': %s (%s)", \ - _buf1, _buf2, msg, isc_result_totext(code)); \ + _buf1, _buf2, msg, isc_result_totext(code)); \ if (result != ISC_R_SUCCESS) goto failure; \ } while (0) #define CHECK(op) \ - do { result = (op); \ + do { result = (op); \ if (result != ISC_R_SUCCESS) goto failure; \ } while (0) @@ -121,12 +121,12 @@ typedef struct db_rr_iterator db_rr_iterator_t; struct db_rr_iterator { isc_result_t result; dns_db_t *db; - dns_dbiterator_t *dbit; + dns_dbiterator_t *dbit; dns_dbversion_t *ver; isc_stdtime_t now; dns_dbnode_t *node; dns_fixedname_t fixedname; - dns_rdatasetiter_t *rdatasetit; + dns_rdatasetiter_t *rdatasetit; dns_rdataset_t rdataset; dns_rdata_t rdata; }; @@ -303,6 +303,11 @@ log_rr(dns_name_t *name, dns_rdata_t *rdata, isc_uint32_t ttl) { rdl.type = rdata->type; rdl.rdclass = rdata->rdclass; rdl.ttl = ttl; + if (rdata->type == dns_rdatatype_sig || + rdata->type == dns_rdatatype_rrsig) + rdl.covers = dns_rdata_covers(rdata); + else + rdl.covers = dns_rdatatype_none; ISC_LIST_INIT(rdl.rdata); ISC_LINK_INIT(&rdl, link); dns_rdataset_init(&rds); @@ -326,7 +331,7 @@ log_rr(dns_name_t *name, dns_rdata_t *rdata, isc_uint32_t ttl) { INSIST(buf.used >= 1 && ((char *) buf.base)[buf.used - 1] == '\n'); buf.used--; - + isc_log_write(XFROUT_RR_LOGARGS, "%.*s", (int)isc_buffer_usedlength(&buf), (char *)isc_buffer_base(&buf)); @@ -969,7 +974,7 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) { /* * Normal zone table does not have a match. Try the DLZ database */ - if (client->view->dlzdatabase != NULL) { + if (client->view->dlzdatabase != NULL) { result = dns_dlzallowzonexfr(client->view, question_name, &client->peeraddr, &db); @@ -1006,7 +1011,7 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) { } else { /* - * not DLZ and not in normal zone table, we are + * not DLZ and not in normal zone table, we are * not authoritative */ FAILQ(DNS_R_NOTAUTH, "non-authoritative zone", @@ -1191,7 +1196,7 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) { } /* - * Bracket the the data stream with SOAs. + * Bracket the data stream with SOAs. */ CHECK(soa_rrstream_create(mctx, db, ver, &soa_stream)); CHECK(compound_rrstream_create(mctx, &soa_stream, &data_stream, @@ -1210,26 +1215,26 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) { #ifdef DLZ if (is_dlz) - CHECK(xfrout_ctx_create(mctx, client, request->id, question_name, - reqtype, question_class, db, ver, quota, - stream, dns_message_gettsigkey(request), - tsigbuf, - 3600, - 3600, - (format == dns_many_answers) ? - ISC_TRUE : ISC_FALSE, - &xfr)); - else + CHECK(xfrout_ctx_create(mctx, client, request->id, question_name, + reqtype, question_class, db, ver, quota, + stream, dns_message_gettsigkey(request), + tsigbuf, + 3600, + 3600, + (format == dns_many_answers) ? + ISC_TRUE : ISC_FALSE, + &xfr)); + else #endif - CHECK(xfrout_ctx_create(mctx, client, request->id, question_name, - reqtype, question_class, db, ver, quota, - stream, dns_message_gettsigkey(request), - tsigbuf, - dns_zone_getmaxxfrout(zone), - dns_zone_getidleout(zone), - (format == dns_many_answers) ? - ISC_TRUE : ISC_FALSE, - &xfr)); + CHECK(xfrout_ctx_create(mctx, client, request->id, question_name, + reqtype, question_class, db, ver, quota, + stream, dns_message_gettsigkey(request), + tsigbuf, + dns_zone_getmaxxfrout(zone), + dns_zone_getidleout(zone), + (format == dns_many_answers) ? + ISC_TRUE : ISC_FALSE, + &xfr)); xfr->mnemonic = mnemonic; stream = NULL; @@ -1399,7 +1404,7 @@ failure: * * Requires: * The stream iterator is initialized and points at an RR, - * or possiby at the end of the stream (that is, the + * or possibly at the end of the stream (that is, the * _first method of the iterator has been called). */ static void @@ -1573,6 +1578,11 @@ sendstream(xfrout_ctx_t *xfr) { msgrdl->type = rdata->type; msgrdl->rdclass = rdata->rdclass; msgrdl->ttl = ttl; + if (rdata->type == dns_rdatatype_sig || + rdata->type == dns_rdatatype_rrsig) + msgrdl->covers = dns_rdata_covers(rdata); + else + msgrdl->covers = dns_rdatatype_none; ISC_LINK_INIT(msgrdl, link); ISC_LIST_INIT(msgrdl->rdata); ISC_LIST_APPEND(msgrdl->rdata, msgrdata, link); @@ -1663,7 +1673,7 @@ sendstream(xfrout_ctx_t *xfr) { * iterators before returning from the event handler. */ xfr->stream->methods->pause(xfr->stream); - + if (result == ISC_R_SUCCESS) return; diff --git a/bin/nsupdate/nsupdate.1 b/bin/nsupdate/nsupdate.1 index 454f50560f20..6613fb713371 100644 --- a/bin/nsupdate/nsupdate.1 +++ b/bin/nsupdate/nsupdate.1 @@ -1,7 +1,7 @@ -.\" Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2003 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: nsupdate.1,v 1.1.4.2 2008/09/01 02:29:00 tbox Exp $ +.\" $Id: nsupdate.1,v 1.1.4.4 2009/07/11 01:31:45 tbox Exp $ .\" .hy 0 .ad l @@ -96,7 +96,7 @@ The \fB\-k\fR may also be used to specify a SIG(0) key used to authenticate Dynamic DNS update requests. In this case, the key specified is not an HMAC\-MD5 key. .PP -By default +By default, \fBnsupdate\fR uses UDP to send update requests to the name server unless they are too large to fit in a UDP request in which case TCP will be used. The \fB\-v\fR @@ -342,7 +342,7 @@ base\-64 encoding of HMAC\-MD5 key created by .PP The TSIG key is redundantly stored in two separate files. This is a consequence of nsupdate using the DST library for its cryptographic operations, and may change in future releases. .SH "COPYRIGHT" -Copyright \(co 2004\-2008 Internet Systems Consortium, Inc. ("ISC") +Copyright \(co 2004\-2009 Internet Systems Consortium, Inc. ("ISC") .br Copyright \(co 2000\-2003 Internet Software Consortium. .br diff --git a/bin/nsupdate/nsupdate.c b/bin/nsupdate/nsupdate.c index 88749e64f957..e80ea5998200 100644 --- a/bin/nsupdate/nsupdate.c +++ b/bin/nsupdate/nsupdate.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: nsupdate.c,v 1.130.18.22 2008/01/17 23:45:58 tbox Exp $ */ +/* $Id: nsupdate.c,v 1.130.18.24 2009/04/30 23:46:03 tbox Exp $ */ /*! \file */ @@ -1328,8 +1328,9 @@ update_addordelete(char *cmdline, isc_boolean_t isdelete) { } region.base = word; region.length = strlen(word); + rdataclass = dns_rdataclass_any; result = dns_rdataclass_fromtext(&rdataclass, ®ion); - if (result == ISC_R_SUCCESS) { + if (result == ISC_R_SUCCESS && rdataclass != dns_rdataclass_any) { if (!setzoneclass(rdataclass)) { fprintf(stderr, "class mismatch: %s\n", word); goto failure; diff --git a/bin/nsupdate/nsupdate.docbook b/bin/nsupdate/nsupdate.docbook index 43fe69ad4853..d869eed3bcaa 100644 --- a/bin/nsupdate/nsupdate.docbook +++ b/bin/nsupdate/nsupdate.docbook @@ -2,7 +2,7 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> - + Jun 30, 2000 @@ -40,6 +40,7 @@ 2006 2007 2008 + 2009 Internet Systems Consortium, Inc. ("ISC") @@ -159,7 +160,7 @@ specified is not an HMAC-MD5 key. - By default + By default, nsupdate uses UDP to send update requests to the name server unless they are too large to fit in a UDP request in which case TCP will be used. diff --git a/bin/nsupdate/nsupdate.html b/bin/nsupdate/nsupdate.html index 1fe0f9c15806..a15c6d497c73 100644 --- a/bin/nsupdate/nsupdate.html +++ b/bin/nsupdate/nsupdate.html @@ -1,8 +1,8 @@ - + @@ -32,7 +32,7 @@

nsupdate [-d] [[-y [hmac:]keyname:secret] | [-k keyfile]] [-t timeout] [-u udptimeout] [-r udpretries] [-v] [filename]

-

DESCRIPTION

+

DESCRIPTION

nsupdate is used to submit Dynamic DNS Update requests as defined in RFC2136 to a name server. @@ -121,7 +121,7 @@ specified is not an HMAC-MD5 key.

- By default + By default, nsupdate uses UDP to send update requests to the name server unless they are too large to fit in a UDP request in which case TCP will be used. @@ -153,7 +153,7 @@

-

INPUT FORMAT

+

INPUT FORMAT

nsupdate reads input from filename @@ -402,7 +402,7 @@

-

EXAMPLES

+

EXAMPLES

The examples below show how nsupdate @@ -456,7 +456,7 @@

-

FILES

+

FILES

/etc/resolv.conf

@@ -475,7 +475,7 @@

-

SEE ALSO

+

SEE ALSO

RFC2136, RFC3007, RFC2104, @@ -488,7 +488,7 @@

-

BUGS

+

BUGS

The TSIG key is redundantly stored in two separate files. This is a consequence of nsupdate using the DST library diff --git a/bin/rndc/include/rndc/os.h b/bin/rndc/include/rndc/os.h index b5c1d243c1b7..aecb22d77fab 100644 --- a/bin/rndc/include/rndc/os.h +++ b/bin/rndc/include/rndc/os.h @@ -1,8 +1,8 @@ /* - * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: os.h,v 1.5.18.2 2005/04/29 00:15:41 marka Exp $ */ +/* $Id: os.h,v 1.5.18.4 2009/01/19 23:46:14 tbox Exp $ */ /*! \file */ @@ -35,7 +35,7 @@ FILE *safe_create(const char *filename); int set_user(FILE *fd, const char *user); /*%< - * Set the owner of the file refernced by 'fd' to 'user'. + * Set the owner of the file referenced by 'fd' to 'user'. * Returns: * 0 success * -1 insufficient permissions, or 'user' does not exist. diff --git a/bin/rndc/rndc-confgen.8 b/bin/rndc/rndc-confgen.8 index fe25a7b02a5c..bc5583ff90de 100644 --- a/bin/rndc/rndc-confgen.8 +++ b/bin/rndc/rndc-confgen.8 @@ -1,7 +1,7 @@ .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2001, 2003 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: rndc-confgen.8,v 1.9.18.11 2007/01/30 00:23:44 marka Exp $ +.\" $Id: rndc-confgen.8,v 1.9.18.12 2009/07/11 01:31:45 tbox Exp $ .\" .hy 0 .ad l diff --git a/bin/rndc/rndc-confgen.html b/bin/rndc/rndc-confgen.html index fd40a81d0bd9..5725aa4d78f2 100644 --- a/bin/rndc/rndc-confgen.html +++ b/bin/rndc/rndc-confgen.html @@ -2,7 +2,7 @@ - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC") - Copyright (C) 2001, 2003 Internet Software Consortium. - - - Permission to use, copy, modify, and distribute this software for any + - Permission to use, copy, modify, and/or distribute this software for any - purpose with or without fee is hereby granted, provided that the above - copyright notice and this permission notice appear in all copies. - @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> - + diff --git a/bin/rndc/rndc.8 b/bin/rndc/rndc.8 index 6858ed77cb15..d1a61b20df6a 100644 --- a/bin/rndc/rndc.8 +++ b/bin/rndc/rndc.8 @@ -1,7 +1,7 @@ .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000, 2001 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: rndc.8,v 1.26.18.16 2007/12/14 22:37:16 marka Exp $ +.\" $Id: rndc.8,v 1.26.18.17 2009/07/11 01:31:45 tbox Exp $ .\" .hy 0 .ad l diff --git a/bin/rndc/rndc.c b/bin/rndc/rndc.c index 772cc2975ca1..bce2ee54e597 100644 --- a/bin/rndc/rndc.c +++ b/bin/rndc/rndc.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2006, 2008 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2006, 2008, 2009 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rndc.c,v 1.96.18.21 2008/10/15 03:07:19 marka Exp $ */ +/* $Id: rndc.c,v 1.96.18.23 2009/01/19 23:46:14 tbox Exp $ */ /*! \file */ @@ -200,7 +200,7 @@ rndc_recvdone(isc_task_t *task, isc_event_t *event) { "* the remote server is using an older version of" " the command protocol,\n" "* this host is not authorized to connect,\n" - "* the clocks are not syncronized, or\n" + "* the clocks are not synchronized, or\n" "* the key is invalid."); if (ccmsg.result != ISC_R_SUCCESS) @@ -263,7 +263,7 @@ rndc_recvnonce(isc_task_t *task, isc_event_t *event) { "* the remote server is using an older version of" " the command protocol,\n" "* this host is not authorized to connect,\n" - "* the clocks are not syncronized, or\n" + "* the clocks are not synchronized, or\n" "* the key is invalid."); if (ccmsg.result != ISC_R_SUCCESS) diff --git a/bin/rndc/rndc.conf.5 b/bin/rndc/rndc.conf.5 index dbeb707155c6..65b95aecc1fd 100644 --- a/bin/rndc/rndc.conf.5 +++ b/bin/rndc/rndc.conf.5 @@ -1,7 +1,7 @@ .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000, 2001 Internet Software Consortium. .\" -.\" Permission to use, copy, modify, and distribute this software for any +.\" Permission to use, copy, modify, and/or distribute this software for any .\" purpose with or without fee is hereby granted, provided that the above .\" copyright notice and this permission notice appear in all copies. .\" @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: rndc.conf.5,v 1.23.18.15 2007/05/09 13:35:47 marka Exp $ +.\" $Id: rndc.conf.5,v 1.23.18.16 2009/07/11 01:31:45 tbox Exp $ .\" .hy 0 .ad l diff --git a/bin/rndc/rndc.conf.html b/bin/rndc/rndc.conf.html index d11f9df60ee1..e58160da2bc8 100644 --- a/bin/rndc/rndc.conf.html +++ b/bin/rndc/rndc.conf.html @@ -2,7 +2,7 @@ - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC") - Copyright (C) 2000, 2001 Internet Software Consortium. - - - Permission to use, copy, modify, and distribute this software for any + - Permission to use, copy, modify, and/or distribute this software for any - purpose with or without fee is hereby granted, provided that the above - copyright notice and this permission notice appear in all copies. - @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> - + diff --git a/bin/rndc/rndc.html b/bin/rndc/rndc.html index c460225cb646..22c3370abdb4 100644 --- a/bin/rndc/rndc.html +++ b/bin/rndc/rndc.html @@ -2,7 +2,7 @@ - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC") - Copyright (C) 2000, 2001 Internet Software Consortium. - - - Permission to use, copy, modify, and distribute this software for any + - Permission to use, copy, modify, and/or distribute this software for any - purpose with or without fee is hereby granted, provided that the above - copyright notice and this permission notice appear in all copies. - @@ -14,7 +14,7 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> - + diff --git a/config.guess b/config.guess index 7d0185e019ed..c79aebcb5668 100644 --- a/config.guess +++ b/config.guess @@ -141,7 +141,7 @@ UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in *:NetBSD:*:*) # NetBSD (nbsd) targets should (where applicable) match one or - # more of the tupples: *-*-netbsdelf*, *-*-netbsdaout*, + # more of the tuples: *-*-netbsdelf*, *-*-netbsdaout*, # *-*-netbsdecoff* and *-*-netbsd*. For targets that recently # switched to ELF, *-*-netbsd* would select the old # object file format. This provides both forward diff --git a/config.h.in b/config.h.in index 210a0794ddfb..0fe3aa24e401 100644 --- a/config.h.in +++ b/config.h.in @@ -1,9 +1,9 @@ /* config.h.in. Generated from configure.in by autoheader. */ /* - * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005, 2008 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * - * Permission to use, copy, modify, and distribute this software for any + * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * @@ -16,7 +16,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: config.h.in,v 1.60.18.34 2008/10/21 02:47:25 marka Exp $ */ +/* $Id: config.h.in,v 1.60.18.44 2009/10/09 06:40:37 marka Exp $ */ /*! \file */ @@ -25,9 +25,6 @@ *** it does not get installed. ***/ -/** define to `int' if doesn't define. */ -#undef ssize_t - /** define on DEC OSF to enable 4.4BSD style sa_len support */ #undef _SOCKADDR_LEN @@ -61,9 +58,6 @@ /** define if you have the NET_RT_IFLIST sysctl variable and sys/sysctl.h */ #undef HAVE_IFLIST_SYSCTL -/** define if chroot() is available */ -#undef HAVE_CHROOT - /** define if tzset() is available */ #undef HAVE_TZSET @@ -115,7 +109,7 @@ int sigwait(const unsigned int *set, int *sig); * The silly continuation line is to keep configure from * commenting out the #undef. */ - + #undef \ va_start #define va_start(ap, last) \ @@ -163,6 +157,9 @@ int sigwait(const unsigned int *set, int *sig); /* Define to 1 if you have the `capset' function. */ #undef HAVE_CAPSET +/* Define to 1 if you have the `chroot' function. */ +#undef HAVE_CHROOT + /* Define to 1 if you have the header file. */ #undef HAVE_DLFCN_H @@ -202,6 +199,9 @@ int sigwait(const unsigned int *set, int *sig); /* Define to 1 if you have the header file. */ #undef HAVE_MEMORY_H +/* Define to 1 if you have the `nanosleep' function. */ +#undef HAVE_NANOSLEEP + /* Define to 1 if you have the header file. */ #undef HAVE_NET_IF6_H diff --git a/configure.in b/configure.in index 6320b6a18b19..9aff8bf6b185 100644 --- a/configure.in +++ b/configure.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 1998-2003 Internet Software Consortium. # # Permission to use, copy, modify, and/or distribute this software for any @@ -18,18 +18,54 @@ AC_DIVERT_PUSH(1)dnl esyscmd([sed "s/^/# /" COPYRIGHT])dnl AC_DIVERT_POP()dnl -AC_REVISION($Revision: 1.355.18.85 $) +AC_REVISION($Revision: 1.355.18.98 $) AC_INIT(lib/dns/name.c) AC_PREREQ(2.59) +# +# build libbind? +# +AC_ARG_ENABLE(libbind, + [ --enable-libbind build libbind (deprecated) [[default=no]]]) + + +case "$enable_libbind" in + yes) + AC_MSG_WARN([The version of libbind included with BIND 9.4 +is no longer maintained. While '--enable-libbind' will still compile +and may work, we are no longer supporting it within the BIND +framework. Anyone planning to use libbind should download +and use the separate libbind package. Please see +https://www.isc.org/software/libbind for details. +]) + LIBBIND=lib/bind + AC_SUBST(LIBBIND) + ;; + no|'') + ;; +esac + AC_CONFIG_HEADER(config.h) AC_CONFIG_SUBDIRS(lib/bind) AC_CANONICAL_HOST AC_PROG_MAKE_SET -AC_PROG_RANLIB + +# +# GNU libtool support +# +case $build_os in +sunos*) + # Just set the maximum command line length for sunos as it otherwise + # takes a exceptionally long time to work it out. Required for libtool. + + lt_cv_sys_max_cmd_len=4096; + ;; +esac + +AC_PROG_LIBTOOL AC_PROG_INSTALL AC_PROG_LN_S @@ -41,7 +77,7 @@ AC_SUBST(CCOPT) # # Make very sure that these are the first files processed by # config.status, since we use the processed output as the input for -# AC_SUBST_FILE() subsitutions in other files. +# AC_SUBST_FILE() substitutions in other files. # AC_CONFIG_FILES([make/rules make/includes]) @@ -215,7 +251,7 @@ fi # OS dependent CC flags # case "$host" in - # OSF 5.0: recv/send are only avaliable with -D_POSIX_PII_SOCKET or + # OSF 5.0: recv/send are only available with -D_POSIX_PII_SOCKET or # -D_XOPEN_SOURCE_EXTENDED. *-dec-osf*) STD_CDEFINES="$STD_CDEFINES -D_POSIX_PII_SOCKET" @@ -355,10 +391,10 @@ AC_SUBST(ISC_PLATFORM_HAVEKQUEUE) # so we need to try running the code, not just test its existence. # AC_ARG_ENABLE(epoll, - [ --enable-epoll use Linux epoll when available [[default=yes]]], - want_epoll="$enableval", want_epoll="yes") +[ --enable-epoll use Linux epoll when available [[default=auto]]], + want_epoll="$enableval", want_epoll="auto") case $want_epoll in -yes) +auto) AC_MSG_CHECKING(epoll support) AC_TRY_RUN([ #include @@ -373,6 +409,9 @@ int main() { [AC_MSG_RESULT(no) ISC_PLATFORM_HAVEEPOLL="#undef ISC_PLATFORM_HAVEEPOLL"]) ;; +yes) + ISC_PLATFORM_HAVEEPOLL="#define ISC_PLATFORM_HAVEEPOLL 1" + ;; *) ISC_PLATFORM_HAVEEPOLL="#undef ISC_PLATFORM_HAVEEPOLL" ;; @@ -451,7 +490,7 @@ AC_C_BIGENDIAN OPENSSL_WARNING= AC_MSG_CHECKING(for OpenSSL library) AC_ARG_WITH(openssl, -[ --with-openssl[=PATH] Build with OpenSSL [yes|no|path]. +[ --with-openssl[=PATH] Build with OpenSSL [yes|no|path]. (Required for DNSSEC)], use_openssl="$withval", use_openssl="auto") @@ -496,6 +535,9 @@ case "$use_openssl" in AC_MSG_ERROR( [OpenSSL was not found in any of $openssldirs; use --with-openssl=/path]) fi + elif ! test -f "$use_openssl"/include/openssl/opensslv.h + then + AC_MSG_ERROR(["$use_openssl/include/openssl/opensslv.h" not found]) fi USE_OPENSSL='-DOPENSSL' if test "$use_openssl" = "/usr" @@ -671,7 +713,7 @@ AC_SUBST(DNS_CRYPTO_LIBS) # AC_MSG_CHECKING(for random device) AC_ARG_WITH(randomdev, -[ --with-randomdev=PATH Specify path for random device], +[ --with-randomdev=PATH Specify path for random device], use_randomdev="$withval", use_randomdev="unspec") case "$use_randomdev" in @@ -966,7 +1008,6 @@ AC_CHECK_FUNC(catgets, AC_DEFINE(HAVE_CATGETS),) # # AC_CHECK_LIB(xnet, socket, , # AC_CHECK_LIB(socket, socket) -# AC_CHECK_LIB(nsl, inet_ntoa) # ) # # Use this for now, instead: @@ -974,9 +1015,11 @@ AC_CHECK_FUNC(catgets, AC_DEFINE(HAVE_CATGETS),) case "$host" in mips-sgi-irix*) ;; + *-linux*) + ;; *) AC_CHECK_LIB(socket, socket) - AC_CHECK_LIB(nsl, inet_ntoa) + AC_CHECK_LIB(nsl, inet_addr) ;; esac @@ -995,7 +1038,7 @@ esac # AC_MSG_CHECKING(whether to use purify) AC_ARG_WITH(purify, - [ --with-purify[=PATH] use Rational purify], + [ --with-purify[=PATH] use Rational purify], use_purify="$withval", use_purify="no") case "$use_purify" in @@ -1032,19 +1075,9 @@ esac AC_SUBST(PURIFY) -# -# GNU libtool support -# -case $build_os in -sunos*) - # Just set the maximum command line length for sunos as it otherwise - # takes a exceptionally long time to work it out. Required for libtool. - lt_cv_sys_max_cmd_len=4096; - ;; -esac AC_ARG_WITH(libtool, - [ --with-libtool use GNU libtool (following indented options supported)], + [ --with-libtool use GNU libtool], use_libtool="$withval", use_libtool="no") case $use_libtool in @@ -1094,32 +1127,16 @@ AC_SUBST(LIBTOOL_MODE_LINK) AC_SUBST(LIBTOOL_ALLOW_UNDEFINED) AC_SUBST(LIBTOOL_IN_MAIN) -# -# build libbind? -# -AC_ARG_ENABLE(libbind, - [ --enable-libbind build libbind [default=no]]) - -case "$enable_libbind" in - yes) - LIBBIND=lib/bind - AC_SUBST(LIBBIND) - ;; - no|'') - ;; -esac - - # # Here begins a very long section to determine the system's networking -# capabilities. The order of the tests is signficant. +# capabilities. The order of the tests is significant. # # # IPv6 # AC_ARG_ENABLE(ipv6, - [ --enable-ipv6 use IPv6 [default=autodetect]]) + [ --enable-ipv6 use IPv6 [default=autodetect]]) case "$enable_ipv6" in yes|''|autodetect) @@ -1150,7 +1167,7 @@ AC_TRY_COMPILE([ # AC_MSG_CHECKING(for Kame IPv6 support) AC_ARG_WITH(kame, - [ --with-kame[=PATH] use Kame IPv6 [default path /usr/local/v6]], + [ --with-kame[=PATH] use Kame IPv6 [default path /usr/local/v6]], use_kame="$withval", use_kame="no") case "$use_kame" in @@ -1430,23 +1447,8 @@ main() { char a[16]; return (inet_pton(AF_INET, "1.2.3", a) == 1 ? 1 : [AC_MSG_RESULT(assuming target platform has working inet_pton) ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"]) -AC_MSG_CHECKING([for inet_aton]) -AC_TRY_LINK([ -#include -#include -#include ], - [struct in_addr in; inet_aton(0, &in); return (0);], - [AC_MSG_RESULT(yes) - ISC_PLATFORM_NEEDATON="#undef ISC_PLATFORM_NEEDATON"], - - [AC_MSG_RESULT(no) - ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_aton.$O" - ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_aton.c" - ISC_PLATFORM_NEEDATON="#define ISC_PLATFORM_NEEDATON 1"]) - AC_SUBST(ISC_PLATFORM_NEEDNTOP) AC_SUBST(ISC_PLATFORM_NEEDPTON) -AC_SUBST(ISC_PLATFORM_NEEDATON) # # Look for a 4.4BSD-style sa_len member in struct sockaddr. @@ -1754,7 +1756,7 @@ AC_SUBST(ISC_EXTRA_SRCS) # values of type isc_int64_t. This will normally be "ll", but where # the compiler treats "long long" as a alias for "long" and printf # doesn't know about "long long" use "l". Hopefully the sprintf -# will produce a inconsistant result in the later case. If the compiler +# will produce a inconsistent result in the later case. If the compiler # fails due to seeing "%lld" we fall back to "l". # # Digital Unix 4.0 (gcc?) (long long) is 64 bits as is its long. It uses @@ -1790,9 +1792,19 @@ AC_SUBST(LWRES_PLATFORM_QUADFORMAT) # # Security Stuff # -AC_CHECK_FUNC(chroot, AC_DEFINE(HAVE_CHROOT)) +# Note it is very recommended to *not* disable chroot(), +# this is only because chroot() was made obsolete by Posix. +AC_ARG_ENABLE(chroot, + [ --disable-chroot disable chroot]) +case "$enable_chroot" in + yes|'') + AC_CHECK_FUNCS(chroot) + ;; + no) + ;; +esac AC_ARG_ENABLE(linux-caps, - [ --disable-linux-caps disable linux capabilities]) + [ --disable-linux-caps disable linux capabilities]) case "$enable_linux_caps" in yes|'') AC_CHECK_HEADERS(linux/capability.h sys/capability.h) @@ -1826,7 +1838,7 @@ esac # AC_CHECK_FUNC(tzset, AC_DEFINE(HAVE_TZSET)) -AC_MSG_CHECKING(for optarg decarartion) +AC_MSG_CHECKING(for optarg declaration) AC_TRY_COMPILE([ #include ], @@ -1953,7 +1965,7 @@ case "$host" in hack_shutup_pthreadonceinit=yes ;; *-solaris2.1[[0-9]]) - hack_shutup_pthreadonceinit=yes + AC_TRY_COMPILE([ #include ], [ static pthread_once_t once_test = { PTHREAD_ONCE_INIT }; ], [hack_shutup_pthreadonceinit=yes], ) ;; esac @@ -2025,12 +2037,14 @@ yes) esac AC_SUBST(ISC_PLATFORM_HAVEIFNAMETOINDEX) +AC_CHECK_FUNCS(nanosleep) + # # Machine architecture dependent features # AC_ARG_ENABLE(atomic, - [ --enable-atomic enable machine specific atomic operations - [[default=autodetect]]], + [ --enable-atomic enable machine specific atomic operations + [[default=autodetect]]], enable_atomic="$enableval", enable_atomic="autodetect") case "$enable_atomic" in @@ -2060,7 +2074,7 @@ main() { [arch=x86_32], [arch=x86_32]) ;; - x86_64-*) + x86_64-*|amd64-*) arch=x86_64 ;; alpha*-*) @@ -2282,7 +2296,7 @@ AC_SUBST($1) # AC_MSG_CHECKING(for Docbook-XSL path) AC_ARG_WITH(docbook-xsl, -[ --with-docbook-xsl=PATH Specify path for Docbook-XSL stylesheets], +[ --with-docbook-xsl=PATH Specify path for Docbook-XSL stylesheets], docbook_path="$withval", docbook_path="auto") case "$docbook_path" in auto) @@ -2350,7 +2364,7 @@ AC_SUBST(XSLT_DB2LATEX_ADMONITIONS) # IDN support # AC_ARG_WITH(idn, - [ --with-idn[=MPREFIX] enable IDN support using idnkit [default PREFIX]], + [ --with-idn[=MPREFIX] enable IDN support using idnkit [default PREFIX]], use_idn="$withval", use_idn="no") case "$use_idn" in yes) @@ -2370,7 +2384,7 @@ esac iconvinc= iconvlib= AC_ARG_WITH(libiconv, - [ --with-libiconv[=IPREFIX] GNU libiconv are in IPREFIX [default PREFIX]], + [ --with-libiconv[=IPREFIX] GNU libiconv are in IPREFIX [default PREFIX]], use_libiconv="$withval", use_libiconv="no") case "$use_libiconv" in yes) @@ -2389,7 +2403,7 @@ no) esac AC_ARG_WITH(iconv, - [ --with-iconv[=LIBSPEC] specify iconv library [default -liconv]], + [ --with-iconv[=LIBSPEC] specify iconv library [default -liconv]], iconvlib="$withval") case "$iconvlib" in no) @@ -2401,7 +2415,7 @@ yes) esac AC_ARG_WITH(idnlib, - [ --with-idnlib=ARG specify libidnkit], + [ --with-idnlib=ARG specify libidnkit], idnlib="$withval", idnlib="no") if test "$idnlib" = yes; then AC_MSG_ERROR([You must specify ARG for --with-idnlib.]) @@ -2457,7 +2471,7 @@ AC_SUBST_FILE(BIND9_MAKE_RULES) BIND9_MAKE_RULES=$BIND9_TOP_BUILDDIR/make/rules . $srcdir/version -BIND9_VERSION="VERSION=${MAJORVER}.${MINORVER}.${PATCHVER}${RELEASETYPE}${RELEASEVER}" +BIND9_VERSION="VERSION=${MAJORVER}.${MINORVER}${PATCHVER:+.}${PATCHVER}${RELEASETYPE}${RELEASEVER}" AC_SUBST(BIND9_VERSION) AC_SUBST_FILE(LIBISC_API) diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index cdcb9d8a4108..9d05255eeaaa 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> - + BIND 9 Administrator Reference Manual @@ -29,6 +29,7 @@ 2006 2007 2008 + 2009 Internet Systems Consortium, Inc. ("ISC") @@ -74,23 +75,23 @@ Organization of This Document - In this document, Section 1 introduces - the basic DNS and BIND concepts. Section 2 + In this document, Chapter 1 introduces + the basic DNS and BIND concepts. Chapter 2 describes resource requirements for running BIND in various - environments. Information in Section 3 is + environments. Information in Chapter 3 is task-oriented in its presentation and is organized functionally, to aid in the process of installing the BIND 9 software. The task-oriented section is followed by - Section 4, which contains more advanced + Chapter 4, which contains more advanced concepts that the system administrator may need for implementing - certain options. Section 5 + certain options. Chapter 5 describes the BIND 9 lightweight - resolver. The contents of Section 6 are + resolver. The contents of Chapter 6 are organized as in a reference manual to aid in the ongoing - maintenance of the software. Section 7 addresses + maintenance of the software. Chapter 7 addresses security considerations, and - Section 8 contains troubleshooting help. The + Chapter 8 contains troubleshooting help. The main body of the document is followed by several appendices which contain useful reference information, such as a bibliography and @@ -651,7 +652,7 @@ Name Server Configuration - In this section we provide some suggested configurations along + In this chapter we provide some suggested configurations along with guidelines for their use. We suggest reasonable values for certain option settings. @@ -928,7 +929,7 @@ zone "eng.example.com" { %comment - The usual simple use of dig will take the form + The usual simple use of dig will take the form dig @server domain query-type query-class @@ -1271,8 +1272,8 @@ zone "eng.example.com" { Stop the server, making sure any recent changes made through dynamic update or IXFR are first saved to the master files of the updated zones. - If -p is specified named's process id is returned. - This allows an external process to determine when named + If is specified named's process id is returned. + This allows an external process to determine when named had completed stopping. @@ -1286,8 +1287,8 @@ zone "eng.example.com" { made through dynamic update or IXFR are not saved to the master files, but will be rolled forward from the journal files when the server is restarted. - If -p is specified named's process id is returned. - This allows an external process to determine when named + If is specified named's process id is returned. + This allows an external process to determine when named had completed halting. @@ -1356,7 +1357,7 @@ zone "eng.example.com" { recursing - Dump the list of queries named is currently recursing + Dump the list of queries named is currently recursing on. @@ -1426,7 +1427,7 @@ zone "eng.example.com" { with named. Its syntax is identical to the - key statement in named.conf. + key statement in named.conf. The keyword key is followed by a key name, which must be a valid domain name, though it need not actually be hierarchical; @@ -1599,10 +1600,10 @@ controls { - As a slave zone can also be a master to other slaves, named, + As a slave zone can also be a master to other slaves, named, by default, sends NOTIFY messages for every zone it loads. Specifying notify master-only; will - cause named to only send NOTIFY for master + cause named to only send NOTIFY for master zones that it loads. @@ -2086,7 +2087,7 @@ key host1-host2. { - The algorithm, hmac-md5, is the only one supported by BIND. + The algorithm, hmac-md5, is the only one supported by BIND. The secret is the one generated above. Since this is a secret, it is recommended that either named.conf be non-world readable, or the key directive be added to a non-world readable @@ -2146,7 +2147,7 @@ server 10.1.2.3 { be denoted key host1-host2. - An example of an allow-update directive would be: + An example of an allow-update directive would be: @@ -2235,7 +2236,7 @@ allow-update { key host1-host2. ;}; BIND 9 partially supports DNSSEC SIG(0) - transaction signatures as specified in RFC 2535 and RFC2931. + transaction signatures as specified in RFC 2535 and RFC 2931. SIG(0) uses public/private keys to authenticate messages. Access control is performed in the same manner as TSIG keys; privileges can be @@ -2448,11 +2449,11 @@ allow-update { key host1-host2. ;}; After DNSSEC gets established, a typical DNSSEC configuration - will look something like the following. It has a one or + will look something like the following. It has one or more public keys for the root. This allows answers from outside the organization to be validated. It will also have several keys for parts of the namespace the organization - controls. These are here to ensure that named is immune + controls. These are here to ensure that named is immune to compromises in the DNSSEC components of the security of parent zones. @@ -3107,7 +3108,7 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. allow-update, allow-update-forwarding, and blackhole all use address match - lists. Similarly, the listen-on option will cause the + lists. Similarly, the listen-on option will cause the server to not accept queries on any of the machine's addresses which do not match the list. @@ -3180,8 +3181,6 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. slash) and continue to the end of the physical line. They cannot be continued across multiple physical lines; to have one logical comment span multiple lines, each line must use the // pair. - - For example: @@ -3197,8 +3196,6 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. with the character # (number sign) and continue to the end of the physical line, as in C++ comments. - - For example: @@ -3688,7 +3685,7 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. logging { [ channel channel_name { - ( file path name + ( file path_name [ versions ( number | unlimited ) ] [ size size spec ] | syslog syslog_facility @@ -3922,7 +3919,7 @@ notrace. All debugging messages in the server have a debug the date and time will be logged. print-time may be specified for a syslog channel, but is usually - pointless since syslog also prints + pointless since syslog also logs the date and time. If print-category is requested, then the @@ -4168,7 +4165,7 @@ category notify { null; }; - Messages that named was unable to determine the + Messages that named was unable to determine the class of or for which there was no matching view. A one line summary is also logged to the client category. This category is best sent to a file or stderr, by @@ -4237,6 +4234,17 @@ category notify { null; }; + + + query-errors + + + + Information about queries that resulted in some + failure. + + + dispatch @@ -4277,11 +4285,11 @@ category notify { null; }; - Delegation only. Logs queries that have have - been forced to NXDOMAIN as the result of a - delegation-only zone or - a delegation-only in a - hint or stub zone declaration. + Delegation only. Logs queries that have been + forced to NXDOMAIN as the result of a + delegation-only zone or a + delegation-only in a hint + or stub zone declaration. @@ -4289,6 +4297,232 @@ category notify { null; }; + + The <command>query-errors</command> Category + + The query-errors category is + specifically intended for debugging purposes: To identify + why and how specific queries result in responses which + indicate an error. + Messages of this category are therefore only logged + with debug levels. + + + + At the debug levels of 1 or higher, each response with the + rcode of SERVFAIL is logged as follows: + + + client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880 + + + This means an error resulting in SERVFAIL was + detected at line 3880 of source file + query.c. + Log messages of this level will particularly + help identify the cause of SERVFAIL for an + authoritative server. + + + At the debug levels of 2 or higher, detailed context + information of recursive resolutions that resulted in + SERVFAIL is logged. + The log message will look like as follows: + + + + +fetch completed at resolver.c:2970 for www.example.com/A +in 30.000183: timed out/success [domain:example.com, +referral:2,restart:7,qrysent:8,timeout:5,lame:0,neterr:0, +badresp:1,adberr:0,findfail:0,valfail:0] + + + + The first part before the colon shows that a recursive + resolution for AAAA records of www.example.com completed + in 30.000183 seconds and the final result that led to the + SERVFAIL was determined at line 2970 of source file + resolver.c. + + + The following part shows the detected final result and the + latest result of DNSSEC validation. + The latter is always success when no validation attempt + is made. + In this example, this query resulted in SERVFAIL probably + because all name servers are down or unreachable, leading + to a timeout in 30 seconds. + DNSSEC validation was probably not attempted. + + + The last part enclosed in square brackets shows statistics + information collected for this particular resolution + attempt. + The domain field shows the deepest zone + that the resolver reached; + it is the zone where the error was finally detected. + The meaning of the other fields is summarized in the + following table. + + + + + + + + + + referral + + + + The number of referrals the resolver received + throughout the resolution process. + In the above example this is 2, which are most + likely com and example.com. + + + + + + restart + + + + The number of cycles that the resolver tried + remote servers at the domain + zone. + In each cycle the resolver sends one query + (possibly resending it, depending on the response) + to each known name server of + the domain zone. + + + + + + qrysent + + + + The number of queries the resolver sent at the + domain zone. + + + + + + timeout + + + + The number of timeouts since the resolver + received the last response. + + + + + + lame + + + + The number of lame servers the resolver detected + at the domain zone. + A server is detected to be lame either by an + invalid response or as a result of lookup in + BIND9's address database (ADB), where lame + servers are cached. + + + + + + neterr + + + + The number of erroneous results that the + resolver encountered in sending queries + at the domain zone. + One common case is the remote server is + unreachable and the resolver receives an ICMP + unreachable error message. + + + + + + badresp + + + + The number of unexpected responses (other than + lame) to queries sent by the + resolver at the domain zone. + + + + + + adberr + + + + Failures in finding remote server addresses + of the domain zone in the ADB. + One common case of this is that the remote + server's name does not have any address records. + + + + + + findfail + + + + Failures of resolving remote server addresses. + This is a total number of failures throughout + the resolution process. + + + + + + valfail + + + + Failures of DNSSEC validation. + Validation failures are counted throughout + the resolution process (not limited to + the domain zone), but should + only happen in domain. + + + + + + + + At the debug levels of 3 or higher, the same messages + as those at the debug 1 level are logged for other errors + than SERVFAIL. + Note that negative responses such as NXDOMAIN are not + regarded as errors here. + + + At the debug levels of 4 or higher, the same messages + as those at the debug 2 level are logged for other errors + than SERVFAIL. + Unlike the above case of level 3, messages are logged for + negative responses. + This is because any unexpected results can be difficult to + debug in the recursion case. + + @@ -4421,6 +4655,7 @@ category notify { null; }; rfc2308-type1 yes_or_no; use-id-pool yes_or_no; maintain-ixfr-base yes_or_no; + ixfr-from-differences (yes_or_no | master | slave); dnssec-enable yes_or_no; dnssec-validation yes_or_no; dnssec-lookaside domain trust-anchor domain; @@ -4689,7 +4924,7 @@ digits" + "tkey-domain". In most cases, The pathname of the file the server writes its process ID in. If not specified, the default is /var/run/named.pid. - The pid-file is used by programs that want to send signals to + The PID file is used by programs that want to send signals to the running name server. Specifying pid-file none disables the use of a PID file — no file will be written and any @@ -4778,17 +5013,45 @@ digits" + "tkey-domain". In most cases, - + root-delegation-only - Turn on enforcement of delegation-only in TLDs (top level domains) and root zones - with an optional - exclude list. + Turn on enforcement of delegation-only in TLDs + (top level domains) and root zones with an optional + exclude list. + + DS queries are expected to be made to and be answered by + delegation only zones. Such queries and responses are + treated as a exception to delegation-only processing + and are not converted to NXDOMAIN responses provided + a CNAME is not discovered at the query name. + + + If a delegation only zone server also serves a child + zone it is not always possible to determine whether + a answer comes from the delegation only zone or the + child zone. SOA NS and DNSKEY records are apex + only records and a matching response that contains + these records or DS is treated as coming from a + child zone. RRSIG records are also examined to see + if they are signed by a child zone or not. The + authority section is also examined to see if there + is evidence that the answer is from the child zone. + Answers that are determined to be from a child zone + are not converted to NXDOMAIN responses. Despite + all these checks there is still a possibility of + false negatives when a child zone is being served. + + + Similarly false positives can arise from empty nodes + (no records at the name) in the delegation only zone + when the query type is not ANY. + - Note some TLDs are not delegation only (e.g. "DE", "LV", "US" - and "MUSEUM"). + Note some TLDs are not delegation only (e.g. "DE", "LV", + "US" and "MUSEUM"). This list is not exhaustive. @@ -4824,7 +5087,7 @@ options { top of a zone. When a DNSKEY is at or below a domain specified by the deepest dnssec-lookaside, and - the normal dnssec validation + the normal DNSSEC validation has left the key untrusted, the trust-anchor will be append to the key name and a DLV record will be looked up to see if it can @@ -4842,10 +5105,10 @@ options { Specify hierarchies which must be or may not be secure (signed and validated). - If yes, then named will only accept + If yes, then named will only accept answers if they are secure. - If no, then normal dnssec validation + If no, then normal DNSSEC validation applies allowing for insecure answers to be accepted. The specified domain must be under a trusted-key or @@ -5518,9 +5781,10 @@ options { also accepts master and slave at the view and options levels which causes - ixfr-from-differences to apply to + ixfr-from-differences to be enabled for all master or slave zones respectively. + It is off by default. @@ -5531,9 +5795,9 @@ options { This should be set when you have multiple masters for a zone and the - addresses refer to different machines. If yes, named will + addresses refer to different machines. If yes, named will not log - when the serial number on the master is less than what named + when the serial number on the master is less than what named currently has. The default is no. @@ -5544,8 +5808,8 @@ options { dnssec-enable - Enable DNSSEC support in named. Unless set to yes, - named behaves as if it does not support DNSSEC. + Enable DNSSEC support in named. Unless set to yes, + named behaves as if it does not support DNSSEC. The default is yes. @@ -5555,7 +5819,7 @@ options { dnssec-validation - Enable DNSSEC validation in named. + Enable DNSSEC validation in named. Note dnssec-enable also needs to be set to yes to be effective. The default is no. @@ -5569,7 +5833,7 @@ options { Accept expired signatures when verifying DNSSEC signatures. The default is no. - Setting this option to "yes" leaves named vulnerable to replay attacks. + Setting this option to "yes" leaves named vulnerable to replay attacks. @@ -5578,7 +5842,7 @@ options { querylog - Specify whether query logging should be started when named + Specify whether query logging should be started when named starts. If querylog is not specified, then the query logging @@ -5608,9 +5872,9 @@ options { from RFC 952 and RFC 821 as modified by RFC 1123. check-names - applies to the owner names of A, AAA and MX records. - It also applies to the domain names in the RDATA of NS, SOA - and MX records. + applies to the owner names of A, AAAA and MX records. + It also applies to the domain names in the RDATA of NS, SOA, + MX, and SRV records. It also applies to the RDATA of PTR records where the owner name indicated that it is a reverse lookup of a hostname (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT). @@ -5701,7 +5965,7 @@ options { When returning authoritative negative responses to - SOA queries set the TTL of the SOA recored returned in + SOA queries set the TTL of the SOA record returned in the authority section to zero. The default is yes. @@ -5881,8 +6145,9 @@ options { from the cache. If allow-query-cache is not set then allow-recursion is used if set, otherwise allow-query - is used if set, otherwise the default - (localnets; + is used if set unless recursion no; is + set in which case none; is used, + otherwise the default (localnets; localhost;) is used. @@ -6001,7 +6266,7 @@ options { The interfaces and ports that the server will answer queries from may be specified using the listen-on option. listen-on takes - an optional port, and an address_match_list. + an optional port and an address_match_list. The server will listen on all interfaces allowed by the address match list. If a port is not specified, port 53 will be used. @@ -6228,7 +6493,12 @@ avoid-v6-udp-ports {}; zone is loaded, in addition to the servers listed in the zone's NS records. This helps to ensure that copies of the zones will - quickly converge on stealth servers. If an also-notify list + quickly converge on stealth servers. + Optionally, a port may be specified with each + also-notify address to send + the notify messages to a port other than the + default of 53. + If an also-notify list is given in a zone statement, it will override the options also-notify @@ -6457,7 +6727,7 @@ avoid-v6-udp-ports {}; to be used, you should set use-alt-transfer-source appropriately and you should not depend upon - getting a answer back to the first refresh + getting an answer back to the first refresh query. @@ -6657,7 +6927,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; - + Server Resource Limits @@ -6691,6 +6961,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; journal will be automatically removed. The default is unlimited. + This may also be set on a per-zone basis. @@ -6741,7 +7012,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; The number of file descriptors reserved for TCP, stdio, etc. This needs to be big enough to cover the number of - interfaces named listens on, tcp-clients as well as + interfaces named listens on, tcp-clients as well as to provide room for outgoing TCP queries and incoming zone transfers. The default is 512. The minimum value is 128 and the @@ -7252,14 +7523,15 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; edns-udp-size - Sets the advertised EDNS UDP buffer size in bytes. Valid - values are 512 to 4096 (values outside this range - will be silently adjusted). The default value is - 4096. The usual reason for setting edns-udp-size to - a non-default value is to get UDP answers to pass - through broken firewalls that block fragmented - packets and/or block UDP packets that are greater - than 512 bytes. + Sets the advertised EDNS UDP buffer size in bytes + to control the size of packets received. + Valid values are 512 to 4096 (values outside this range + will be silently adjusted). The default value + is 4096. The usual reason for setting + edns-udp-size to a non-default + value is to get UDP answers to pass through broken + firewalls that block fragmented packets and/or + block UDP packets that are greater than 512 bytes. @@ -7268,11 +7540,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; max-udp-size - Sets the maximum EDNS UDP message size named will + Sets the maximum EDNS UDP message size named will send in bytes. Valid values are 512 to 4096 (values outside this range will be silently adjusted). The default value is 4096. The usual reason for setting - max-udp-size to a non-default value is to get UDP + max-udp-size to a non-default value is to get UDP answers to pass through broken firewalls that block fragmented packets and/or block UDP packets that are greater than 512 bytes. @@ -7318,16 +7590,16 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; These set the initial value (minimum) and maximum number of recursive - simultanious clients for any given query + simultaneous clients for any given query (<qname,qtype,qclass>) that the server will accept - before dropping additional clients. named will attempt to + before dropping additional clients. named will attempt to self tune this value and changes will be logged. The default values are 10 and 100. This value should reflect how many queries come in for a given name in the time it takes to resolve that name. - If the number of queries exceed this value, named will + If the number of queries exceed this value, named will assume that it is dealing with a non-responsive zone and will drop additional queries. If it gets a response after dropping queries, it will raise the estimate. The @@ -7429,7 +7701,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; identify which of a group of anycast servers is actually answering your queries. Specifying server-id none; disables processing of the queries. - Specifying server-id hostname; will cause named to + Specifying server-id hostname; will cause named to use the hostname as found by the gethostname() function. The default server-id is none. @@ -7454,9 +7726,9 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; loopback address and the IPv6 unknown addresss. - Named will attempt to determine if a built in zone already exists + Named will attempt to determine if a built-in zone already exists or is active (covered by a forward-only forwarding declaration) - and will not not create a empty zone in that case. + and will not create an empty zone in that case. The current list of empty zones is: @@ -7517,7 +7789,7 @@ XXX: end of RFC1918 addresses #defined out --> The real parent servers for these zones should disable all empty zone under the parent zone they serve. For the real - root servers, this is all built in empty zones. This will + root servers, this is all built-in empty zones. This will enable them to return referrals to deeper in the tree. @@ -7547,7 +7819,7 @@ XXX: end of RFC1918 addresses #defined out --> empty-zones-enable - Enable or disable all empty zones. By default they + Enable or disable all empty zones. By default, they are enabled. @@ -7557,7 +7829,7 @@ XXX: end of RFC1918 addresses #defined out --> disable-empty-zone - Disable individual empty zones. By default none are + Disable individual empty zones. By default, none are disabled. This option can be specified multiple times. @@ -7684,7 +7956,7 @@ XXX: end of RFC1918 addresses #defined out --> The number of queries which the server attempted to - recurse but discover a existing query with the same + recurse but discover an existing query with the same IP address, port, query id, name, type and class already being processed. @@ -7697,7 +7969,7 @@ XXX: end of RFC1918 addresses #defined out --> The number of queries for which the server - discovered a excessive number of existing + discovered an excessive number of existing recursive queries for the same name, type and class and were subsequently dropped. @@ -7953,7 +8225,7 @@ XXX: end of RFC1918 addresses #defined out --> The edns-udp-size option sets the EDNS UDP size - that is advertised by named when querying the remote server. + that is advertised by named when querying the remote server. Valid values are 512 to 4096 bytes (values outside this range will be silently adjusted). This option is useful when you wish to advertises a different value to this server than the value you @@ -7963,11 +8235,11 @@ XXX: end of RFC1918 addresses #defined out --> The max-udp-size option sets the - maximum EDNS UDP message size named will send. Valid + maximum EDNS UDP message size named will send. Valid values are 512 to 4096 bytes (values outside this range will be silently adjusted). This option is useful when you know that there is a firewall that is blocking large - replies from named. + replies from named. @@ -8252,9 +8524,11 @@ view "external" { file string ; masterfile-format (text|raw) ; journal string ; + max-journal-size size_spec; forward (only|first) ; forwarders { ip_addr port ip_port ; ... }; ixfr-base string ; + ixfr-from-differences yes_or_no; ixfr-tmp-file string ; maintain-ixfr-base yes_or_no ; max-ixfr-log-size number ; @@ -8289,9 +8563,11 @@ zone zone_name class file string ; masterfile-format (text|raw) ; journal string ; + max-journal-size size_spec; forward (only|first) ; forwarders { ip_addr port ip_port ; ... }; ixfr-base string ; + ixfr-from-differences yes_or_no; ixfr-tmp-file string ; maintain-ixfr-base yes_or_no ; masters port ip_port { ( masters_list | ip_addr port ip_port key key ) ; ... }; @@ -8435,7 +8711,7 @@ zone zone_name classex/example.com where ex/ is just the first two letters of the zone name. (Most operating systems - behave very slowly if you put 100 000 files into + behave very slowly if you put 100000 files into a single directory.) @@ -8560,20 +8836,22 @@ zone zone_name class - This is used to enforce the delegation-only - status of infrastructure zones (e.g. COM, NET, ORG). - Any answer that - is received without an explicit or implicit delegation - in the authority - section will be treated as NXDOMAIN. This does not - apply to the zone - apex. This should not be applied to leaf zones. + This is used to enforce the delegation-only + status of infrastructure zones (e.g. COM, + NET, ORG). Any answer that is received + without an explicit or implicit delegation + in the authority section will be treated + as NXDOMAIN. This does not apply to the + zone apex. This should not be applied to + leaf zones. delegation-only has no - effect on answers received - from forwarders. + effect on answers received from forwarders. + + See caveats in . + @@ -8812,9 +9090,11 @@ zone zone_name class The flag only applies to hint and stub zones. If set to yes, then the zone will also be - treated as if it - is also a delegation-only type zone. + treated as if it is also a delegation-only type zone. + + See caveats in . + @@ -8881,6 +9161,16 @@ zone zone_name class + + max-journal-size + + + See the description of + max-journal-size in . + + + + max-transfer-time-in @@ -9067,6 +9357,10 @@ zone zone_name class See the description of ixfr-from-differences in . + (Note that the ixfr-from-differences + master and + slave choices are not + available at the zone level.) @@ -10250,8 +10544,6 @@ zone zone_name class - For example: @@ -10690,7 +10982,7 @@ $GENERATE 1-127 $ CNAME $.0 describes the owner name of the resource records to be created. Any single $ (dollar sign) - symbols within the lhs side + symbols within the lhs string are replaced by the iterator value. To get a $ in the output, you need to escape the @@ -10734,7 +11026,7 @@ $GENERATE 1-127 $ CNAME $.0 Specifies the time-to-live of the generated records. If not specified this will be inherited using the - normal ttl inheritance rules. + normal TTL inheritance rules. class and ttl can be @@ -10840,7 +11132,7 @@ $GENERATE 1-127 $ CNAME $.0 Access Control Lists - Access Control Lists (ACLs), are address match lists that + Access Control Lists (ACLs) are address match lists that you can set up and nickname for future use in allow-notify, allow-query, allow-recursion, blackhole, allow-transfer, @@ -10904,11 +11196,13 @@ zone "example.com" { <command>Chroot</command> and <command>Setuid</command> - On UNIX servers, it is possible to run BIND in a chrooted environment - (using the chroot() function) by specifying the "" - option. This can help improve system security by placing BIND in - a "sandbox", which will limit the damage done if a server is - compromised. + On UNIX servers, it is possible to run BIND + in a chrooted environment (using + the chroot() function) by specifying + the "" option for named. + This can help improve system security by placing + BIND in a "sandbox", which will limit + the damage done if a server is compromised. Another useful feature in the UNIX version of BIND is the @@ -10921,7 +11215,7 @@ zone "example.com" { user 202: - /usr/local/bin/named -u 202 -t /var/named + /usr/local/sbin/named -u 202 -t /var/named @@ -11187,11 +11481,9 @@ zone "example.com" { BIND architecture. - BIND version 4 is officially deprecated and BIND version - 8 development is considered maintenance-only in favor - of BIND version 9. No additional development is done - on BIND version 4 or BIND version 8 other than for - security-related patches. + BIND versions 4 and 8 are officially deprecated. + No additional development is done + on BIND version 4 or BIND version 8. BIND development work is made @@ -11554,7 +11846,7 @@ zone "example.com" { March 2005 - RFC4044 + RFC4034 R. diff --git a/doc/arm/Bv9ARM.ch01.html b/doc/arm/Bv9ARM.ch01.html index 76a4bb71ecd6..40005894c068 100644 --- a/doc/arm/Bv9ARM.ch01.html +++ b/doc/arm/Bv9ARM.ch01.html @@ -1,8 +1,8 @@ - + @@ -45,17 +45,17 @@

Table of Contents

-
Scope of Document
-
Organization of This Document
-
Conventions Used in This Document
-
The Domain Name System (DNS)
+
Scope of Document
+
Organization of This Document
+
Conventions Used in This Document
+
The Domain Name System (DNS)
-
DNS Fundamentals
-
Domains and Domain Names
-
Zones
-
Authoritative Name Servers
-
Caching Name Servers
-
Name Servers in Multiple Roles
+
DNS Fundamentals
+
Domains and Domain Names
+
Zones
+
Authoritative Name Servers
+
Caching Name Servers
+
Name Servers in Multiple Roles
@@ -71,7 +71,7 @@

-Scope of Document

+Scope of Document

The Berkeley Internet Name Domain (BIND) implements a @@ -87,25 +87,25 @@

-Organization of This Document

+Organization of This Document

- In this document, Section 1 introduces - the basic DNS and BIND concepts. Section 2 + In this document, Chapter 1 introduces + the basic DNS and BIND concepts. Chapter 2 describes resource requirements for running BIND in various - environments. Information in Section 3 is + environments. Information in Chapter 3 is task-oriented in its presentation and is organized functionally, to aid in the process of installing the BIND 9 software. The task-oriented section is followed by - Section 4, which contains more advanced + Chapter 4, which contains more advanced concepts that the system administrator may need for implementing - certain options. Section 5 + certain options. Chapter 5 describes the BIND 9 lightweight - resolver. The contents of Section 6 are + resolver. The contents of Chapter 6 are organized as in a reference manual to aid in the ongoing - maintenance of the software. Section 7 addresses + maintenance of the software. Chapter 7 addresses security considerations, and - Section 8 contains troubleshooting help. The + Chapter 8 contains troubleshooting help. The main body of the document is followed by several appendices which contain useful reference information, such as a bibliography and @@ -116,7 +116,7 @@

-Conventions Used in This Document

+Conventions Used in This Document

In this document, we use the following general typographic conventions: @@ -243,7 +243,7 @@

-The Domain Name System (DNS)

+The Domain Name System (DNS)

The purpose of this document is to explain the installation and upkeep of the BIND (Berkeley Internet @@ -253,7 +253,7 @@

-DNS Fundamentals

+DNS Fundamentals

The Domain Name System (DNS) is a hierarchical, distributed database. It stores information for mapping Internet host names to @@ -273,7 +273,7 @@

-Domains and Domain Names

+Domains and Domain Names

The data stored in the DNS is identified by domain names that are organized as a tree according to organizational or administrative boundaries. Each node of the tree, @@ -319,7 +319,7 @@

-Zones

+Zones

To properly operate a name server, it is important to understand the difference between a zone @@ -372,7 +372,7 @@

-Authoritative Name Servers

+Authoritative Name Servers

Each zone is served by at least one authoritative name server, @@ -389,7 +389,7 @@

-The Primary Master

+The Primary Master

The authoritative server where the master copy of the zone data is maintained is called the @@ -409,7 +409,7 @@

-Slave Servers

+Slave Servers

The other authoritative servers, the slave servers (also known as secondary servers) @@ -425,7 +425,7 @@

-Stealth Servers

+Stealth Servers

Usually all of the zone's authoritative servers are listed in NS records in the parent zone. These NS records constitute @@ -460,7 +460,7 @@

-Caching Name Servers

+Caching Name Servers

The resolver libraries provided by most operating systems are stub resolvers, meaning that they are not @@ -487,7 +487,7 @@

-Forwarding

+Forwarding

Even a caching name server does not necessarily perform the complete recursive lookup itself. Instead, it can @@ -514,7 +514,7 @@

-Name Servers in Multiple Roles

+Name Servers in Multiple Roles

The BIND name server can simultaneously act as diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html index f2abce42f488..91bc2c525b7a 100644 --- a/doc/arm/Bv9ARM.ch02.html +++ b/doc/arm/Bv9ARM.ch02.html @@ -1,8 +1,8 @@ - + @@ -45,16 +45,16 @@

Table of Contents

-
Hardware requirements
-
CPU Requirements
-
Memory Requirements
-
Name Server Intensive Environment Issues
-
Supported Operating Systems
+
Hardware requirements
+
CPU Requirements
+
Memory Requirements
+
Name Server Intensive Environment Issues
+
Supported Operating Systems

-Hardware requirements

+Hardware requirements

DNS hardware requirements have traditionally been quite modest. @@ -73,7 +73,7 @@

-CPU Requirements

+CPU Requirements

CPU requirements for BIND 9 range from i486-class machines @@ -84,7 +84,7 @@

-Memory Requirements

+Memory Requirements

The memory of the server has to be large enough to fit the cache and zones loaded off disk. The max-cache-size @@ -107,7 +107,7 @@

-Name Server Intensive Environment Issues

+Name Server Intensive Environment Issues

For name server intensive environments, there are two alternative configurations that may be used. The first is where clients and @@ -124,7 +124,7 @@

-Supported Operating Systems

+Supported Operating Systems

ISC BIND 9 compiles and runs on a large number of Unix-like operating systems, and on some versions of diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html index 4d39c51a8520..245ddad54cdb 100644 --- a/doc/arm/Bv9ARM.ch03.html +++ b/doc/arm/Bv9ARM.ch03.html @@ -1,8 +1,8 @@ - + @@ -47,19 +47,19 @@

Sample Configurations
-
A Caching-only Name Server
-
An Authoritative-only Name Server
+
A Caching-only Name Server
+
An Authoritative-only Name Server
-
Load Balancing
-
Name Server Operations
+
Load Balancing
+
Name Server Operations
-
Tools for Use With the Name Server Daemon
-
Signals
+
Tools for Use With the Name Server Daemon
+
Signals

- In this section we provide some suggested configurations along + In this chapter we provide some suggested configurations along with guidelines for their use. We suggest reasonable values for certain option settings.

@@ -68,7 +68,7 @@ Sample Configurations

-A Caching-only Name Server

+A Caching-only Name Server

The following sample configuration is appropriate for a caching-only name server for use by clients internal to a corporation. All @@ -95,7 +95,7 @@ zone "0.0.127.in-addr.arpa" {

-An Authoritative-only Name Server

+An Authoritative-only Name Server

This sample configuration is for an authoritative-only server that is the master server for "example.com" @@ -137,7 +137,7 @@ zone "eng.example.com" {

-Load Balancing

+Load Balancing

A primitive form of load balancing can be achieved in the DNS by using multiple records @@ -280,10 +280,10 @@ zone "eng.example.com" {

-Name Server Operations

+Name Server Operations

-Tools for Use With the Name Server Daemon

+Tools for Use With the Name Server Daemon

This section describes several indispensable diagnostic, administrative and monitoring tools available to the system @@ -315,7 +315,7 @@ zone "eng.example.com" {

dig [@server] domain [query-type] [query-class] [+query-option] [-dig-option] [%comment]

- The usual simple use of dig will take the form + The usual simple use of dig will take the form

dig @server domain query-type query-class @@ -541,8 +541,8 @@ zone "eng.example.com" { Stop the server, making sure any recent changes made through dynamic update or IXFR are first saved to the master files of the updated zones. - If -p is specified named's process id is returned. - This allows an external process to determine when named + If -p is specified named's process id is returned. + This allows an external process to determine when named had completed stopping.

halt [-p]
@@ -551,8 +551,8 @@ zone "eng.example.com" { made through dynamic update or IXFR are not saved to the master files, but will be rolled forward from the journal files when the server is restarted. - If -p is specified named's process id is returned. - This allows an external process to determine when named + If -p is specified named's process id is returned. + This allows an external process to determine when named had completed halting.

trace
@@ -586,7 +586,7 @@ zone "eng.example.com" {

recursing

- Dump the list of queries named is currently recursing + Dump the list of queries named is currently recursing on.

@@ -651,7 +651,7 @@ zone "eng.example.com" { with named. Its syntax is identical to the - key statement in named.conf. + key statement in named.conf. The keyword key is followed by a key name, which must be a valid domain name, though it need not actually be hierarchical; @@ -739,7 +739,7 @@ controls {

-Signals

+Signals

Certain UNIX signals cause the name server to take specific actions, as described in the following table. These signals can diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html index e31d85d2c33e..1aeecb4eab6c 100644 --- a/doc/arm/Bv9ARM.ch04.html +++ b/doc/arm/Bv9ARM.ch04.html @@ -1,8 +1,8 @@ - + @@ -49,29 +49,29 @@

Dynamic Update
The journal file
Incremental Zone Transfers (IXFR)
-
Split DNS
-
Example split DNS setup
+
Split DNS
+
Example split DNS setup
TSIG
-
Generate Shared Keys for Each Pair of Hosts
-
Copying the Shared Secret to Both Machines
-
Informing the Servers of the Key's Existence
-
Instructing the Server to Use the Key
-
TSIG Key Based Access Control
-
Errors
+
Generate Shared Keys for Each Pair of Hosts
+
Copying the Shared Secret to Both Machines
+
Informing the Servers of the Key's Existence
+
Instructing the Server to Use the Key
+
TSIG Key Based Access Control
+
Errors
-
TKEY
-
SIG(0)
+
TKEY
+
SIG(0)
DNSSEC
-
Generating Keys
-
Signing the Zone
-
Configuring Servers
+
Generating Keys
+
Signing the Zone
+
Configuring Servers
-
IPv6 Support in BIND 9
+
IPv6 Support in BIND 9
-
Address Lookups Using AAAA Records
-
Address to Name Lookups Using Nibble Format
+
Address Lookups Using AAAA Records
+
Address to Name Lookups Using Nibble Format
@@ -95,10 +95,10 @@

Note

- As a slave zone can also be a master to other slaves, named, + As a slave zone can also be a master to other slaves, named, by default, sends NOTIFY messages for every zone it loads. Specifying notify master-only; will - cause named to only send NOTIFY for master + cause named to only send NOTIFY for master zones that it loads.
@@ -205,7 +205,7 @@

-Split DNS

+Split DNS

Setting up different views, or visibility, of the DNS space to internal and external resolvers is usually referred to as a @@ -235,7 +235,7 @@

-Example split DNS setup

+Example split DNS setup

Let's say a company named Example, Inc. (example.com) @@ -481,7 +481,7 @@ nameserver 172.16.72.4

-Generate Shared Keys for Each Pair of Hosts

+Generate Shared Keys for Each Pair of Hosts

A shared secret is generated to be shared between host1 and host2. An arbitrary key name is chosen: "host1-host2.". The key name must @@ -489,7 +489,7 @@ nameserver 172.16.72.4

-Automatic Generation

+Automatic Generation

The following command will generate a 128-bit (16 byte) HMAC-MD5 key as described above. Longer keys are better, but shorter keys @@ -514,7 +514,7 @@ nameserver 172.16.72.4

-Manual Generation

+Manual Generation

The shared secret is simply a random sequence of bits, encoded in base-64. Most ASCII strings are valid base-64 strings (assuming @@ -529,7 +529,7 @@ nameserver 172.16.72.4

-Copying the Shared Secret to Both Machines

+Copying the Shared Secret to Both Machines

This is beyond the scope of DNS. A secure transport mechanism should be used. This could be secure FTP, ssh, telephone, etc. @@ -537,7 +537,7 @@ nameserver 172.16.72.4

-Informing the Servers of the Key's Existence

+Informing the Servers of the Key's Existence

Imagine host1 and host 2 are @@ -550,7 +550,7 @@ key host1-host2. { };

- The algorithm, hmac-md5, is the only one supported by BIND. + The algorithm, hmac-md5, is the only one supported by BIND. The secret is the one generated above. Since this is a secret, it is recommended that either named.conf be non-world readable, or the key directive be added to a non-world readable @@ -566,7 +566,7 @@ key host1-host2. {

-Instructing the Server to Use the Key

+Instructing the Server to Use the Key

Since keys are shared between two hosts only, the server must be told when keys are to be used. The following is added to the named.conf file @@ -598,7 +598,7 @@ server 10.1.2.3 {

-TSIG Key Based Access Control

+TSIG Key Based Access Control

BIND allows IP addresses and ranges to be specified in ACL @@ -609,7 +609,7 @@ server 10.1.2.3 { be denoted key host1-host2.

- An example of an allow-update directive would be: + An example of an allow-update directive would be: 

 allow-update { key host1-host2. ;};
@@ -626,7 +626,7 @@ allow-update { key host1-host2. ;};
 
 

 

-Errors

+Errors

 

           The processing of TSIG signed messages can result in
           several errors. If a signed message is sent to a non-TSIG aware
@@ -652,7 +652,7 @@ allow-update { key host1-host2. ;};
 
 

 

-TKEY

+TKEY

 
TKEY
         is a mechanism for automatically generating a shared secret
         between two hosts.  There are several "modes" of
@@ -688,10 +688,10 @@ allow-update { key host1-host2. ;};
 
 

 

-SIG(0)

+SIG(0)

 

         BIND 9 partially supports DNSSEC SIG(0)
-            transaction signatures as specified in RFC 2535 and RFC2931.
+            transaction signatures as specified in RFC 2535 and RFC 2931.
         SIG(0)
         uses public/private keys to authenticate messages.  Access control
         is performed in the same manner as TSIG keys; privileges can be
@@ -749,7 +749,7 @@ allow-update { key host1-host2. ;};
       

 

 

-Generating Keys

+Generating Keys

 

           The dnssec-keygen program is used to
           generate keys.
@@ -800,7 +800,7 @@ allow-update { key host1-host2. ;};
 
 

 

-Signing the Zone

+Signing the Zone

 

           The dnssec-signzone program is used
           to
@@ -844,7 +844,7 @@ allow-update { key host1-host2. ;};
 
 

 

-Configuring Servers

+Configuring Servers

 

           To enable named to respond appropriately
           to DNS requests from DNSSEC aware clients,
@@ -877,11 +877,11 @@ allow-update { key host1-host2. ;};
         

 

           After DNSSEC gets established, a typical DNSSEC configuration
-          will look something like the following.  It has a one or
+          will look something like the following.  It has one or
           more public keys for the root.  This allows answers from
           outside the organization to be validated.  It will also
           have several keys for parts of the namespace the organization
-          controls.  These are here to ensure that named is immune
+          controls.  These are here to ensure that named is immune
           to compromises in the DNSSEC components of the security
           of parent zones.
         

@@ -932,7 +932,7 @@ options {
 
 

 

-IPv6 Support in BIND 9

+IPv6 Support in BIND 9

 

         BIND 9 fully supports all currently
         defined forms of IPv6
@@ -971,7 +971,7 @@ options {
       

 

 

-Address Lookups Using AAAA Records

+Address Lookups Using AAAA Records

 

           The IPv6 AAAA record is a parallel to the IPv4 A record,
           and, unlike the deprecated A6 record, specifies the entire
@@ -990,7 +990,7 @@ host            3600    IN      AAAA    2001:db8::1
 
 

 

-Address to Name Lookups Using Nibble Format

+Address to Name Lookups Using Nibble Format

 

           When looking up an address in nibble format, the address
           components are simply reversed, just as in IPv4, and
diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html
index 33d1d0d195a0..20133328cc48 100644
--- a/doc/arm/Bv9ARM.ch05.html
+++ b/doc/arm/Bv9ARM.ch05.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -45,13 +45,13 @@
 

 
Table of Contents

 

-
The Lightweight Resolver Library

+
The Lightweight Resolver Library

 
Running a Resolver Daemon

 

 

 

 

-The Lightweight Resolver Library

+The Lightweight Resolver Library

 

         Traditionally applications have been linked with a stub resolver
         library that sends recursive DNS queries to a local caching name
diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html
index e2929068970d..f2098b2205c3 100644
--- a/doc/arm/Bv9ARM.ch06.html
+++ b/doc/arm/Bv9ARM.ch06.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -48,52 +48,52 @@
 
Configuration File Elements

 

 
Address Match Lists

-
Comment Syntax

+
Comment Syntax

 

 
Configuration File Grammar

 

-
acl Statement Grammar

+
acl Statement Grammar

 
acl Statement Definition and
           Usage

-
controls Statement Grammar

+
controls Statement Grammar

 
controls Statement Definition and
           Usage

-
include Statement Grammar

-
include Statement Definition and
+
include Statement Grammar

+
include Statement Definition and
           Usage

-
key Statement Grammar

-
key Statement Definition and Usage

-
logging Statement Grammar

-
logging Statement Definition and
+
key Statement Grammar

+
key Statement Definition and Usage

+
logging Statement Grammar

+
logging Statement Definition and
           Usage

-
lwres Statement Grammar

-
lwres Statement Definition and Usage

-
masters Statement Grammar

-
masters Statement Definition and
+
lwres Statement Grammar

+
lwres Statement Definition and Usage

+
masters Statement Grammar

+
masters Statement Definition and
           Usage

-
options Statement Grammar

+
options Statement Grammar

 
options Statement Definition and
           Usage

 
server Statement Grammar

 
server Statement Definition and
             Usage

-
trusted-keys Statement Grammar

-
trusted-keys Statement Definition
+
trusted-keys Statement Grammar

+
trusted-keys Statement Definition
             and Usage

 
view Statement Grammar

-
view Statement Definition and Usage

+
view Statement Definition and Usage

 
zone
             Statement Grammar

-
zone Statement Definition and Usage

+
zone Statement Definition and Usage

 

-
Zone File

+
Zone File

 

 
Types of Resource Records and When to Use Them

-
Discussion of MX Records

+
Discussion of MX Records

 
Setting TTLs

-
Inverse Mapping in IPv4

-
Other Zone File Directives

-
BIND Master File Extension: the  $GENERATE Directive

+
Inverse Mapping in IPv4

+
Other Zone File Directives

+
BIND Master File Extension: the  $GENERATE Directive

 
Additional File Formats

 

 
@@ -455,7 +455,7 @@
 Address Match Lists
 

 

-Syntax

+Syntax

 
address_match_list = address_match_list_element ;
   [ address_match_list_element; ... ]
 address_match_list_element = [ ! ] (ip_address [/length] |
@@ -464,7 +464,7 @@
 
 

 

-Definition and Usage

+Definition and Usage

 

             Address match lists are primarily used to determine access
             control for various server operations. They are also used in
@@ -520,7 +520,7 @@
             allow-update,
             allow-update-forwarding, and
             blackhole all use address match
-            lists.  Similarly, the listen-on option will cause the
+            lists.  Similarly, the listen-on option will cause the
             server to not accept queries on any of the machine's
             addresses which do not match the list.
           

@@ -542,7 +542,7 @@
 
 

 

-Comment Syntax

+Comment Syntax

 

           The BIND 9 comment syntax allows for
           comments to appear
@@ -552,7 +552,7 @@
         

 

 

-Syntax

+Syntax

 

             

 
/* This is a BIND comment as in C */

@@ -567,7 +567,7 @@
 
 

 

-Definition and Usage

+Definition and Usage

 

             Comments may appear anywhere that whitespace may appear in
             a BIND configuration file.
@@ -598,8 +598,6 @@
             slash) and continue to the end of the physical line. They cannot
             be continued across multiple physical lines; to have one logical
             comment span multiple lines, each line must use the // pair.
-          

-

             For example:
           

 

@@ -617,8 +615,6 @@
             with the character # (number sign)
             and continue to the end of the
             physical line, as in C++ comments.
-          

-

             For example:
           

 

@@ -801,7 +797,7 @@
       

 

 

-acl Statement Grammar

+acl Statement Grammar

 
acl acl-name {
     address_match_list
 };
@@ -884,7 +880,7 @@
 
 

 

-controls Statement Grammar

+controls Statement Grammar

 
controls {
    [ inet ( ip_addr | * ) [ port ip_port ] allow {  address_match_list  }
                 keys { key_list }; ]
@@ -1006,12 +1002,12 @@
 
 

 

-include Statement Grammar

+include Statement Grammar

 
include filename;

 
 

 

-include Statement Definition and
+include Statement Definition and
           Usage

 

           The include statement inserts the
@@ -1026,7 +1022,7 @@
 

 

 

-key Statement Grammar

+key Statement Grammar

 
key key_id {
     algorithm string;
     secret string;
@@ -1035,7 +1031,7 @@
 
 

 

-key Statement Definition and Usage

+key Statement Definition and Usage

 

           The key statement defines a shared
           secret key for use with TSIG (see the section called “TSIG”)
@@ -1082,10 +1078,10 @@
 
 

 

-logging Statement Grammar

+logging Statement Grammar

 
logging {
    [ channel channel_name {
-     ( file path name
+     ( file path_name
          [ versions ( number | unlimited ) ]
          [ size size spec ]
        | syslog syslog_facility
@@ -1106,7 +1102,7 @@
 
 

 

-logging Statement Definition and
+logging Statement Definition and
           Usage

 

           The logging statement configures a
@@ -1140,7 +1136,7 @@
         

 

 

-The channel Phrase

+The channel Phrase

 

             All log output goes to one or more channels;
             you can make as many of them as you want.
@@ -1302,7 +1298,7 @@ notrace. All debugging messages in the server have a debug
             the date and time will be logged. print-time may
             be specified for a syslog channel,
             but is usually
-            pointless since syslog also prints
+            pointless since syslog also logs
             the date and
             time. If print-category is
             requested, then the
@@ -1536,7 +1532,7 @@ category notify { null; };
                   
 
                     

-                      Messages that named was unable to determine the
+                      Messages that named was unable to determine the
                       class of or for which there was no matching view.
                       A one line summary is also logged to the client category.
                       This category is best sent to a file or stderr, by
@@ -1606,6 +1602,17 @@ category notify { null; };
                   
 
 
+
+                    
query-errors

+                  
+
+                    

+                      Information about queries that resulted in some
+                      failure.
+                    

+                  
+
+
 
                     
dispatch

                   
@@ -1645,21 +1652,248 @@ category notify { null; };
                   
 
                     

-                      Delegation only.  Logs queries that have have
-                      been forced to NXDOMAIN as the result of a
-                      delegation-only zone or
-                      a delegation-only in a
-                      hint or stub zone declaration.
+                      Delegation only.  Logs queries that have been
+                      forced to NXDOMAIN as the result of a
+                      delegation-only zone or a
+                      delegation-only in a hint
+                      or stub zone declaration.
                     

                   
 
 
 
 
+

+

+The query-errors Category

+

+            The query-errors category is
+            specifically intended for debugging purposes: To identify
+            why and how specific queries result in responses which
+            indicate an error.
+            Messages of this category are therefore only logged
+            with debug levels.
+          

+

+            At the debug levels of 1 or higher, each response with the
+            rcode of SERVFAIL is logged as follows:
+          

+

+            client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880
+          

+

+            This means an error resulting in SERVFAIL was
+            detected at line 3880 of source file
+            query.c.
+            Log messages of this level will particularly
+            help identify the cause of SERVFAIL for an
+            authoritative server.
+          

+

+            At the debug levels of 2 or higher, detailed context
+            information of recursive resolutions that resulted in
+            SERVFAIL is logged.
+            The log message will look like as follows:
+          

+

+
+            

+
+fetch completed at resolver.c:2970 for www.example.com/A
+in 30.000183: timed out/success [domain:example.com,
+referral:2,restart:7,qrysent:8,timeout:5,lame:0,neterr:0,
+badresp:1,adberr:0,findfail:0,valfail:0]
+            

+

+          

+

+            The first part before the colon shows that a recursive
+            resolution for AAAA records of www.example.com completed
+            in 30.000183 seconds and the final result that led to the
+            SERVFAIL was determined at line 2970 of source file
+            resolver.c.
+          

+

+            The following part shows the detected final result and the
+            latest result of DNSSEC validation.
+            The latter is always success when no validation attempt
+            is made.
+            In this example, this query resulted in SERVFAIL probably
+            because all name servers are down or unreachable, leading
+            to a timeout in 30 seconds.
+            DNSSEC validation was probably not attempted.
+          

+

+            The last part enclosed in square brackets shows statistics
+            information collected for this particular resolution
+            attempt.
+            The domain field shows the deepest zone
+            that the resolver reached;
+            it is the zone where the error was finally detected.
+            The meaning of the other fields is summarized in the
+            following table.
+          

+

++++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+





+                    
referral

+                  		
+                    

+                      The number of referrals the resolver received
+                      throughout the resolution process.
+                      In the above example this is 2, which are most
+                      likely com and example.com.
+                    

+                  

+                    
restart

+                  		
+                    

+                      The number of cycles that the resolver tried
+                      remote servers at the domain
+                      zone.
+                      In each cycle the resolver sends one query
+                      (possibly resending it, depending on the response)
+                      to each known name server of
+                      the domain zone.
+                    

+                  

+                    
qrysent

+                  		
+                    

+                      The number of queries the resolver sent at the
+                      domain zone.
+                    

+                  

+                    
timeout

+                  		
+                    

+                      The number of timeouts since the resolver
+                      received the last response.
+                    

+                  

+                    
lame

+                  		
+                    

+                      The number of lame servers the resolver detected
+                      at the domain zone.
+                      A server is detected to be lame either by an
+                      invalid response or as a result of lookup in
+                      BIND9's address database (ADB), where lame
+                      servers are cached.
+                    

+                  

+                    
neterr

+                  		
+                    

+                      The number of erroneous results that the
+                      resolver encountered in sending queries
+                      at the domain zone.
+                      One common case is the remote server is
+                      unreachable and the resolver receives an ICMP
+                      unreachable error message.
+                    

+                  

+                    
badresp

+                  		
+                    

+                      The number of unexpected responses (other than
+                      lame) to queries sent by the
+                      resolver at the domain zone.
+                    

+                  

+                    
adberr

+                  		
+                    

+                      Failures in finding remote server addresses
+                      of the domain zone in the ADB.
+                      One common case of this is that the remote
+                      server's name does not have any address records.
+                    

+                  

+                    
findfail

+                  		
+                    

+                      Failures of resolving remote server addresses.
+                      This is a total number of failures throughout
+                      the resolution process.
+                    

+                  

+                    
valfail

+                  		
+                    

+                      Failures of DNSSEC validation.
+                      Validation failures are counted throughout
+                      the resolution process (not limited to
+                      the domain zone), but should
+                      only happen in domain.
+                    

+                  

+

+            At the debug levels of 3 or higher, the same messages
+            as those at the debug 1 level are logged for other errors
+            than SERVFAIL.
+            Note that negative responses such as NXDOMAIN are not
+            regarded as errors here.
+          

+

+            At the debug levels of 4 or higher, the same messages
+            as those at the debug 2 level are logged for other errors
+            than SERVFAIL.
+            Unlike the above case of level 3, messages are logged for
+            negative responses.
+            This is because any unexpected results can be difficult to
+            debug in the recursion case.
+          

+

 
 

 

-lwres Statement Grammar

+lwres Statement Grammar

 

            This is the grammar of the lwres
           statement in the named.conf file:
@@ -1674,7 +1908,7 @@ category notify { null; };
 
 

 

-lwres Statement Definition and Usage

+lwres Statement Definition and Usage

 

           The lwres statement configures the
           name
@@ -1725,14 +1959,14 @@ category notify { null; };
 
 

 

-masters Statement Grammar

+masters Statement Grammar

 
 masters name [port ip_port] { ( masters_list | ip_addr [port ip_port] [key key] ) ; [...] };
 

 
 

 

-masters Statement Definition and
+masters Statement Definition and
           Usage

 
masters
           lists allow for a common set of masters to be easily used by
@@ -1741,7 +1975,7 @@ category notify { null; };
 

 

 

-options Statement Grammar

+options Statement Grammar

 

           This is the grammar of the options
           statement in the named.conf file:
@@ -1778,6 +2012,7 @@ category notify { null; };
     [ rfc2308-type1 yes_or_no; ]
     [ use-id-pool yes_or_no; ]
     [ maintain-ixfr-base yes_or_no; ]
+    [ ixfr-from-differences (yes_or_no | master | slave); ]
     [ dnssec-enable yes_or_no; ]
     [ dnssec-validation yes_or_no; ]
     [ dnssec-lookaside domain trust-anchor domain; ]
@@ -2001,7 +2236,7 @@ digits" + "tkey-domain". In most cases,
 

                 The pathname of the file the server writes its process ID
                 in. If not specified, the default is /var/run/named.pid.
-                The pid-file is used by programs that want to send signals to
+                The PID file is used by programs that want to send signals to
                 the running
                 name server. Specifying pid-file none disables the
                 use of a PID file — no file will be written and any
@@ -2062,16 +2297,46 @@ digits" + "tkey-domain". In most cases,
                 in the additional section of a query response.
                 The default is not to prefer any type (NONE).
               

-
root-delegation-only

+

+root-delegation-only
+

 

 

-                Turn on enforcement of delegation-only in TLDs (top level domains) and root zones
-                with an optional
+                Turn on enforcement of delegation-only in TLDs
+                (top level domains) and root zones with an optional
                 exclude list.
               

 

-                Note some TLDs are not delegation only (e.g. "DE", "LV", "US"
-                and "MUSEUM").
+                DS queries are expected to be made to and be answered by
+                delegation only zones.  Such queries and responses are
+                treated as a exception to delegation-only processing
+                and are not converted to NXDOMAIN responses provided
+                a CNAME is not discovered at the query name.
+              

+

+                If a delegation only zone server also serves a child
+                zone it is not always possible to determine whether
+                a answer comes from the delegation only zone or the
+                child zone.  SOA NS and DNSKEY records are apex
+                only records and a matching response that contains
+                these records or DS is treated as coming from a
+                child zone.  RRSIG records are also examined to see
+                if they are signed by a child zone or not.  The
+                authority section is also examined to see if there
+                is evidence that the answer is from the child zone.
+                Answers that are determined to be from a child zone
+                are not converted to NXDOMAIN responses.  Despite
+                all these checks there is still a possibility of
+                false negatives when a child zone is being served.
+              

+

+                Similarly false positives can arise from empty nodes
+                (no records at the name) in the delegation only zone
+                when the query type is not ANY.
+              

+

+                Note some TLDs are not delegation only (e.g. "DE", "LV",
+                "US" and "MUSEUM").  This list is not exhaustive.
               

 
 options {
@@ -2096,7 +2361,7 @@ options {
                 top of a zone.  When a DNSKEY is at or below a domain
                 specified by the
                 deepest dnssec-lookaside, and
-                the normal dnssec validation
+                the normal DNSSEC validation
                 has left the key untrusted, the trust-anchor will be append to
                 the key
                 name and a DLV record will be looked up to see if it can
@@ -2109,10 +2374,10 @@ options {
 

                 Specify hierarchies which must be or may not be secure (signed and
                 validated).
-                If yes, then named will only accept
+                If yes, then named will only accept
                 answers if they
                 are secure.
-                If no, then normal dnssec validation
+                If no, then normal DNSSEC validation
                 applies
                 allowing for insecure answers to be accepted.
                 The specified domain must be under a trusted-key or
@@ -2675,30 +2940,31 @@ options {
                   also accepts master and
                   slave at the view and options
                   levels which causes
-                  ixfr-from-differences to apply to
+                  ixfr-from-differences to be enabled for
                   all master or
                   slave zones respectively.
+                  It is off by default.
                 

 

 
multi-master

 

                   This should be set when you have multiple masters for a zone
                   and the
-                  addresses refer to different machines.  If yes, named will
+                  addresses refer to different machines.  If yes, named will
                   not log
-                  when the serial number on the master is less than what named
+                  when the serial number on the master is less than what named
                   currently
                   has.  The default is no.
                 

 
dnssec-enable

 

-                  Enable DNSSEC support in named.  Unless set to yes,
-                  named behaves as if it does not support DNSSEC.
+                  Enable DNSSEC support in named.  Unless set to yes,
+                  named behaves as if it does not support DNSSEC.
                   The default is yes.
                 

 
dnssec-validation

 

-                  Enable DNSSEC validation in named.
+                  Enable DNSSEC validation in named.
                   Note dnssec-enable also needs to be
                   set to yes to be effective.
                   The default is no.
@@ -2707,11 +2973,11 @@ options {
 

                   Accept expired signatures when verifying DNSSEC signatures.
                   The default is no.
-                  Setting this option to "yes" leaves named vulnerable to replay attacks.
+                  Setting this option to "yes" leaves named vulnerable to replay attacks.
                 

 
querylog

 

-                  Specify whether query logging should be started when named
+                  Specify whether query logging should be started when named
                   starts.
                   If querylog is not specified,
                   then the query logging
@@ -2737,9 +3003,9 @@ options {
                   from RFC 952 and RFC 821 as modified by RFC 1123.
                 

 
check-names
-                  applies to the owner names of A, AAA and MX records.
-                  It also applies to the domain names in the RDATA of NS, SOA
-                  and MX records.
+                  applies to the owner names of A, AAAA and MX records.
+                  It also applies to the domain names in the RDATA of NS, SOA,
+                  MX, and SRV records.
                   It also applies to the RDATA of PTR records where the owner
                   name indicated that it is a reverse lookup of a hostname
                   (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
@@ -2796,7 +3062,7 @@ options {
 
zero-no-soa-ttl

 

                   When returning authoritative negative responses to
-                  SOA queries set the TTL of the SOA recored returned in
+                  SOA queries set the TTL of the SOA record returned in
                   the authority section to zero.
                   The default is yes.
                 

@@ -2820,7 +3086,7 @@ options {
 
 

 

-Forwarding

+Forwarding

 

             The forwarding facility can be used to create a large site-wide
             cache on a few servers, reducing traffic over links to external
@@ -2864,7 +3130,7 @@ options {
 
 

 

-Dual-stack Servers

+Dual-stack Servers

 

             Dual-stack servers are used as servers of last resort to work
             around
@@ -2935,8 +3201,9 @@ options {
                   from the cache.  If allow-query-cache
                   is not set then allow-recursion
                   is used if set, otherwise allow-query
-                  is used if set, otherwise the default
-                  (localnets;
+                  is used if set unless recursion no; is
+                  set in which case none; is used,
+                  otherwise the default (localnets;
                   localhost;) is used.
                 

 
allow-recursion

@@ -3019,11 +3286,11 @@ options {
 
 

 

-Interfaces

+Interfaces

 

             The interfaces and ports that the server will answer queries
             from may be specified using the listen-on option. listen-on takes
-            an optional port, and an address_match_list.
+            an optional port and an address_match_list.
             The server will listen on all interfaces allowed by the address
             match list. If a port is not specified, port 53 will be used.
           

@@ -3228,7 +3495,12 @@ avoid-v6-udp-ports {};
                   zone is loaded, in addition to the servers listed in the
                   zone's NS records.
                   This helps to ensure that copies of the zones will
-                  quickly converge on stealth servers. If an also-notify list
+                  quickly converge on stealth servers.
+                  Optionally, a port may be specified with each
+                  also-notify address to send
+                  the notify messages to a port other than the
+                  default of 53.
+                  If an also-notify list
                   is given in a zone statement,
                   it will override
                   the options also-notify
@@ -3395,7 +3667,7 @@ avoid-v6-udp-ports {};
                   to be used, you should set
                   use-alt-transfer-source
                   appropriately and you should not depend upon
-                  getting a answer back to the first refresh
+                  getting an answer back to the first refresh
                   query.
                 
 
@@ -3447,7 +3719,7 @@ avoid-v6-udp-ports {};
 
 

 

-UDP Port Lists

+UDP Port Lists

 

             use-v4-udp-ports,
             avoid-v4-udp-ports,
@@ -3489,7 +3761,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
 

 

-Operating System Resource Limits

+Operating System Resource Limits

 

             The server's usage of many system resources can be limited.
             Scaled values are allowed when specifying resource limits.  For
@@ -3548,7 +3820,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
 

 

-Server  Resource Limits

+Server  Resource Limits

 

             The following options set limits on the server's
             resource consumption that are enforced internally by the
@@ -3571,6 +3843,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   journal
                   will be automatically removed.  The default is
                   unlimited.
+                  This may also be set on a per-zone basis.
                 

 
host-statistics-max

 

@@ -3602,7 +3875,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 

                   The number of file descriptors reserved for TCP, stdio,
                   etc.  This needs to be big enough to cover the number of
-                  interfaces named listens on, tcp-clients as well as
+                  interfaces named listens on, tcp-clients as well as
                   to provide room for outgoing TCP queries and incoming zone
                   transfers.  The default is 512.
                   The minimum value is 128 and the
@@ -3649,7 +3922,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
 

 

-Periodic Task Intervals

+Periodic Task Intervals

 

 
cleaning-interval

 

@@ -4037,22 +4310,23 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 

 
edns-udp-size

 

-                  Sets the advertised EDNS UDP buffer size in bytes.  Valid
-                  values are 512 to 4096 (values outside this range
-                  will be silently adjusted).  The default value is
-                  4096.  The usual reason for setting edns-udp-size to
-                  a non-default value is to get UDP answers to pass
-                  through broken firewalls that block fragmented
-                  packets and/or block UDP packets that are greater
-                  than 512 bytes.
+                  Sets the advertised EDNS UDP buffer size in bytes
+                  to control the size of packets received.
+                  Valid values are 512 to 4096 (values outside this range
+                  will be silently adjusted).  The default value
+                  is 4096.  The usual reason for setting
+                  edns-udp-size to a non-default
+                  value is to get UDP answers to pass through broken
+                  firewalls that block fragmented packets and/or
+                  block UDP packets that are greater than 512 bytes.
                 

 
max-udp-size

 

-                  Sets the maximum EDNS UDP message size named will
+                  Sets the maximum EDNS UDP message size named will
                   send in bytes.  Valid values are 512 to 4096 (values outside
                   this range will be silently adjusted).  The default
                   value is 4096.  The usual reason for setting
-                  max-udp-size to a non-default value is to get UDP
+                  max-udp-size to a non-default value is to get UDP
                   answers to pass through broken firewalls that
                   block fragmented packets and/or block UDP packets
                   that are greater than 512 bytes.
@@ -4090,16 +4364,16 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 

 
These set the
                   initial value (minimum) and maximum number of recursive
-                  simultanious clients for any given query
+                  simultaneous clients for any given query
                   (<qname,qtype,qclass>) that the server will accept
-                  before dropping additional clients.  named will attempt to
+                  before dropping additional clients.  named will attempt to
                   self tune this value and changes will be logged.  The
                   default values are 10 and 100.
                 

 

                   This value should reflect how many queries come in for
                   a given name in the time it takes to resolve that name.
-                  If the number of queries exceed this value, named will
+                  If the number of queries exceed this value, named will
                   assume that it is dealing with a non-responsive zone
                   and will drop additional queries.  If it gets a response
                   after dropping queries, it will raise the estimate.  The
@@ -4179,7 +4453,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   identify which of a group of anycast servers is actually
                   answering your queries.  Specifying server-id none;
                   disables processing of the queries.
-                  Specifying server-id hostname; will cause named to
+                  Specifying server-id hostname; will cause named to
                   use the hostname as found by the gethostname() function.
                   The default server-id is none.
                 

@@ -4200,9 +4474,9 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
             loopback address and the IPv6 unknown addresss.
           

 

-            Named will attempt to determine if a built in zone already exists
+            Named will attempt to determine if a built-in zone already exists
             or is active (covered by a forward-only forwarding declaration)
-            and will not not create a empty zone in that case.
+            and will not create an empty zone in that case.
           

 

             The current list of empty zones is:
@@ -4248,7 +4522,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
Note

             The real parent servers for these zones should disable all
             empty zone under the parent zone they serve.  For the real
-            root servers, this is all built in empty zones.  This will
+            root servers, this is all built-in empty zones.  This will
             enable them to return referrals to deeper in the tree.
           

 

@@ -4266,12 +4540,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 

 
empty-zones-enable

 

-                  Enable or disable all empty zones.  By default they
+                  Enable or disable all empty zones.  By default, they
                   are enabled.
                 

 
disable-empty-zone

 

-                  Disable individual empty zones.  By default none are
+                  Disable individual empty zones.  By default, none are
                   disabled.  This option can be specified multiple times.
                 

 
@@ -4396,7 +4670,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
                     

                       The number of queries which the server attempted to
-                      recurse but discover a existing query with the same
+                      recurse but discover an existing query with the same
                       IP address, port, query id, name, type and class
                       already being processed.
                     

@@ -4409,7 +4683,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
                     

                       The number of queries for which the server
-                      discovered a excessive number of existing
+                      discovered an excessive number of existing
                       recursive queries for the same name, type and
                       class and were subsequently dropped.
                     

@@ -4628,7 +4902,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           

 

             The edns-udp-size option sets the EDNS UDP size
-            that is advertised by named when querying the remote server.
+            that is advertised by named when querying the remote server.
             Valid values are 512 to 4096 bytes (values outside this range will be
             silently adjusted).  This option is useful when you wish to
             advertises a different value to this server than the value you
@@ -4637,11 +4911,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           

 

             The max-udp-size option sets the
-            maximum EDNS UDP message size named will send.  Valid
+            maximum EDNS UDP message size named will send.  Valid
             values are 512 to 4096 bytes (values outside this range will
             be silently adjusted).  This option is useful when you
             know that there is a firewall that is blocking large
-            replies from named.
+            replies from named.
           

 

             The server supports two zone transfer methods. The first, one-answer,
@@ -4719,7 +4993,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
 

 

-trusted-keys Statement Grammar

+trusted-keys Statement Grammar

 
trusted-keys {
     string number number number string ;
     [ string number number number string ; [...]]
@@ -4728,7 +5002,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
 

 

-trusted-keys Statement Definition
+trusted-keys Statement Definition
             and Usage

 

             The trusted-keys statement defines
@@ -4771,7 +5045,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 

 

 

-view Statement Definition and Usage

+view Statement Definition and Usage

 

             The view statement is a powerful
             feature
@@ -4906,9 +5180,11 @@ view "external" {
     [ file string ; ]
     [ masterfile-format (text|raw) ; ]
     [ journal string ; ]
+    [ max-journal-size size_spec; ]
     [ forward (only|first) ; ]
     [ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
     [ ixfr-base string ; ]
+    [ ixfr-from-differences yes_or_no; ]
     [ ixfr-tmp-file string ; ]
     [ maintain-ixfr-base yes_or_no ; ]
     [ max-ixfr-log-size number ; ]
@@ -4943,9 +5219,11 @@ zone zone_name [ file string ; ]
     [ masterfile-format (text|raw) ; ]
     [ journal string ; ]
+    [ max-journal-size size_spec; ]
     [ forward (only|first) ; ]
     [ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
     [ ixfr-base string ; ]
+    [ ixfr-from-differences yes_or_no; ]
     [ ixfr-tmp-file string ; ]
     [ maintain-ixfr-base yes_or_no ; ]
     [ masters [port ip_port] { ( masters_list | ip_addr [port ip_port] [key key] ) ; [...] }; ]
@@ -5023,10 +5301,10 @@ zone zone_name [
 

 

-zone Statement Definition and Usage

+zone Statement Definition and Usage

 

 

-Zone Types

+Zone Types

 
@@ -5089,7 +5367,7 @@ zone zone_name [ex/example.com where ex/ is
                         just the first two letters of the zone name. (Most
                         operating systems
-                        behave very slowly if you put 100 000 files into
+                        behave very slowly if you put 100000 files into
                         a single directory.)
                       

                     
@@ -5215,18 +5493,20 @@ zone zone_name [
                       

                         This is used to enforce the delegation-only
-                        status of infrastructure zones (e.g. COM, NET, ORG).
-                        Any answer that
-                        is received without an explicit or implicit delegation
-                        in the authority
-                        section will be treated as NXDOMAIN.  This does not
-                        apply to the zone
-                        apex.  This should not be applied to leaf zones.
+                        status of infrastructure zones (e.g. COM,
+                        NET, ORG).  Any answer that is received
+                        without an explicit or implicit delegation
+                        in the authority section will be treated
+                        as NXDOMAIN.  This does not apply to the
+                        zone apex.  This should not be applied to
+                        leaf zones.
                       

                       

                         delegation-only has no
-                        effect on answers received
-                        from forwarders.
+                        effect on answers received from forwarders.
+                      

+                      

+                        See caveats in root-delegation-only.
                       

                     
 
@@ -5235,7 +5515,7 @@ zone zone_name [
 

 

-Class

+Class

 

               The zone's name may optionally be followed by a class. If
               a class is not specified, class IN (for Internet),
@@ -5257,7 +5537,7 @@ zone zone_name [
 

 

-Zone Options

+Zone Options

 

 
allow-notify

 

@@ -5380,12 +5660,16 @@ zone zone_name [dialup in the section called “Boolean Options”.
                   

 
delegation-only

-

+

+

                     The flag only applies to hint and stub zones.  If set
                     to yes, then the zone will also be
-                    treated as if it
-                    is also a delegation-only type zone.
-                  

+                    treated as if it is also a delegation-only type zone.
+                  

+

+                    See caveats in root-delegation-only.
+                  

+
 
forward

 

                     Only meaningful if the zone has a forwarders
@@ -5424,6 +5708,11 @@ zone zone_name [.jnl" appended.
                     This is applicable to master and slave zones.
                   

+
max-journal-size

+

+                    See the description of
+                    max-journal-size in the section called “Server  Resource Limits”.
+                  

 
max-transfer-time-in

 

                     See the description of
@@ -5521,6 +5810,10 @@ zone zone_name [

                     See the description of
                     ixfr-from-differences in the section called “Boolean Options”.
+                    (Note that the ixfr-from-differences
+                    master and
+                    slave choices are not
+                    available at the zone level.)
                   

 
key-directory

 

@@ -5745,7 +6038,7 @@ zone zone_name [
 

 

-Zone File

+Zone File

 

 

 Types of Resource Records and When to Use Them

@@ -5758,7 +6051,7 @@ zone zone_name [
 

 

-Resource Records

+Resource Records

 

               A domain name identifies a node.  Each node has a set of
               resource information, which may be empty.  The set of resource
@@ -6448,7 +6741,7 @@ zone zone_name [
 

 

-Textual expression of RRs

+Textual expression of RRs

 

               RRs are represented in binary form in the packets of the DNS
               protocol, and are usually represented in highly encoded form
@@ -6651,7 +6944,7 @@ zone zone_name [
 

 

-Discussion of MX Records

+Discussion of MX Records

 

             As described above, domain servers store information as a
             series of resource records, each of which contains a particular
@@ -6685,8 +6978,6 @@ zone zone_name [
-

             For example:
           

 

 
 


@@ -6909,7 +7200,7 @@ zone zone_name [
 

 

-Inverse Mapping in IPv4

+Inverse Mapping in IPv4

 

             Reverse name resolution (that is, translation from IP address
             to name) is achieved by means of the in-addr.arpa domain
@@ -6970,7 +7261,7 @@ zone zone_name [
 

 

-Other Zone File Directives

+Other Zone File Directives

 

             The Master File Format was initially defined in RFC 1035 and
             has subsequently been extended. While the Master File Format
@@ -6985,7 +7276,7 @@ zone zone_name [
 

 

-The $ORIGIN Directive

+The $ORIGIN Directive

 

               Syntax: $ORIGIN
               domain-name
@@ -7013,7 +7304,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 
 

 

-The $INCLUDE Directive

+The $INCLUDE Directive

 

               Syntax: $INCLUDE
               filename
@@ -7049,7 +7340,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 
 

 

-The $TTL Directive

+The $TTL Directive

 

               Syntax: $TTL
               default-ttl
@@ -7068,7 +7359,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 
 

 

-BIND Master File Extension: the  $GENERATE Directive

+BIND Master File Extension: the  $GENERATE Directive

 

             Syntax: $GENERATE
             range
@@ -7128,7 +7419,7 @@ $GENERATE 1-127 $ CNAME $.0
                       describes the owner name of the resource records
                       to be created.  Any single $
                       (dollar sign)
-                      symbols within the lhs side
+                      symbols within the lhs string
                       are replaced by the iterator value.
 
                       To get a $ in the output, you need to escape the
@@ -7172,7 +7463,7 @@ $GENERATE 1-127 $ CNAME $.0
                     

                       Specifies the time-to-live of the generated records. If
                       not specified this will be inherited using the
-                      normal ttl inheritance rules.
+                      normal TTL inheritance rules.
                     

                     
class
                       and ttl can be
diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html
index 4ddbcedc9a8b..58688d2165a5 100644
--- a/doc/arm/Bv9ARM.ch07.html
+++ b/doc/arm/Bv9ARM.ch07.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -46,10 +46,10 @@
 
Table of Contents

 

 
Access Control Lists

-
Chroot and Setuid

+
Chroot and Setuid

 

-
The chroot Environment

-
Using the setuid Function

+
The chroot Environment

+
Using the setuid Function

 

 
Dynamic Update Security

 

@@ -58,7 +58,7 @@
 

 Access Control Lists

 

-          Access Control Lists (ACLs), are address match lists that
+          Access Control Lists (ACLs) are address match lists that
           you can set up and nickname for future use in allow-notify,
           allow-query, allow-recursion,
           blackhole, allow-transfer,
@@ -118,14 +118,16 @@ zone "example.com" {
 
 

 

-Chroot and Setuid
+Chroot and Setuid
 

 

-          On UNIX servers, it is possible to run BIND in a chrooted environment
-          (using the chroot() function) by specifying the "-t"
-          option. This can help improve system security by placing BIND in
-          a "sandbox", which will limit the damage done if a server is
-          compromised.
+          On UNIX servers, it is possible to run BIND
+          in a chrooted environment (using
+          the chroot() function) by specifying
+          the "-t" option for named.
+          This can help improve system security by placing
+          BIND in a "sandbox", which will limit
+          the damage done if a server is compromised.
         

 

           Another useful feature in the UNIX version of BIND is the
@@ -138,11 +140,11 @@ zone "example.com" {
           user 202:
         

 

-          /usr/local/bin/named -u 202 -t /var/named
+          /usr/local/sbin/named -u 202 -t /var/named
         

 

 

-The chroot Environment

+The chroot Environment

 

             In order for a chroot environment
             to
@@ -170,7 +172,7 @@ zone "example.com" {
 
 

 

-Using the setuid Function

+Using the setuid Function

 

             Prior to running the named daemon,
             use
diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html
index 65f8cec8d3ba..73c49412250d 100644
--- a/doc/arm/Bv9ARM.ch08.html
+++ b/doc/arm/Bv9ARM.ch08.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -45,18 +45,18 @@
 

 
Table of Contents

 

-
Common Problems

-
It's not working; how can I figure out what's wrong?

-
Incrementing and Changing the Serial Number

-
Where Can I Get Help?

+
Common Problems

+
It's not working; how can I figure out what's wrong?

+
Incrementing and Changing the Serial Number

+
Where Can I Get Help?

 

 

 

 

-Common Problems

+Common Problems

 

 

-It's not working; how can I figure out what's wrong?

+It's not working; how can I figure out what's wrong?

 

             The best solution to solving installation and
             configuration issues is to take preventative measures by setting
@@ -68,7 +68,7 @@
 
 

 

-Incrementing and Changing the Serial Number

+Incrementing and Changing the Serial Number

 

           Zone serial numbers are just numbers — they aren't
           date related.  A lot of people set them to a number that
@@ -95,7 +95,7 @@
 
 

 

-Where Can I Get Help?

+Where Can I Get Help?

 

           The Internet Systems Consortium
           (ISC) offers a wide range
diff --git a/doc/arm/Bv9ARM.ch09.html b/doc/arm/Bv9ARM.ch09.html
index 71ea617e6afb..24fbfe07d460 100644
--- a/doc/arm/Bv9ARM.ch09.html
+++ b/doc/arm/Bv9ARM.ch09.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -45,21 +45,21 @@
 

 
Table of Contents

 

-
Acknowledgments

+
Acknowledgments

 
A Brief History of the DNS and BIND

-
General DNS Reference Information

+
General DNS Reference Information

 
IPv6 addresses (AAAA)

 
Bibliography (and Suggested Reading)

 

 
Request for Comments (RFCs)

 
Internet Drafts

-
Other Documents About BIND

+
Other Documents About BIND

 

 

 

 

 

-Acknowledgments

+Acknowledgments

 

 

 A Brief History of the DNS and BIND
@@ -148,11 +148,9 @@
             BIND architecture.
           

 

-            BIND version 4 is officially deprecated and BIND version
-            8 development is considered maintenance-only in favor
-            of BIND version 9. No additional development is done
-            on BIND version 4 or BIND version 8 other than for
-            security-related patches.
+            BIND versions 4 and 8 are officially deprecated.
+            No additional development is done
+            on BIND version 4 or BIND version 8.
           

 

             BIND development work is made
@@ -164,7 +162,7 @@
 

 

 

-General DNS Reference Information

+General DNS Reference Information

 

 

 IPv6 addresses (AAAA)

@@ -252,17 +250,17 @@
           

 

 

-Bibliography

+Bibliography

 

 
Standards

 

-
[RFC974] C. Partridge. Mail Routing and the Domain System. January 1986. 

+
[RFC974] C. Partridge. Mail Routing and the Domain System. January 1986. 

 

 

-
[RFC1034] P.V. Mockapetris. Domain Names — Concepts and Facilities. November 1987. 

+
[RFC1034] P.V. Mockapetris. Domain Names — Concepts and Facilities. November 1987. 

 

 

-
[RFC1035] P. V. Mockapetris. Domain Names — Implementation and
+
[RFC1035] P. V. Mockapetris. Domain Names — Implementation and
                   Specification. November 1987. 

 

 

@@ -270,42 +268,42 @@
 

 Proposed Standards

 

-
[RFC2181] R., R. Bush Elz. Clarifications to the DNS
+
[RFC2181] R., R. Bush Elz. Clarifications to the DNS
                   Specification. July 1997. 

 

 

-
[RFC2308] M. Andrews. Negative Caching of DNS
+
[RFC2308] M. Andrews. Negative Caching of DNS
                   Queries. March 1998. 

 

 

-
[RFC1995] M. Ohta. Incremental Zone Transfer in DNS. August 1996. 

+
[RFC1995] M. Ohta. Incremental Zone Transfer in DNS. August 1996. 

 

 

-
[RFC1996] P. Vixie. A Mechanism for Prompt Notification of Zone Changes. August 1996. 

+
[RFC1996] P. Vixie. A Mechanism for Prompt Notification of Zone Changes. August 1996. 

 

 

-
[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System. April 1997. 

+
[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System. April 1997. 

 

 

-
[RFC2671] P. Vixie. Extension Mechanisms for DNS (EDNS0). August 1997. 

+
[RFC2671] P. Vixie. Extension Mechanisms for DNS (EDNS0). August 1997. 

 

 

-
[RFC2672] M. Crawford. Non-Terminal DNS Name Redirection. August 1999. 

+
[RFC2672] M. Crawford. Non-Terminal DNS Name Redirection. August 1999. 

 

 

-
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington. Secret Key Transaction Authentication for DNS (TSIG). May 2000. 

+
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington. Secret Key Transaction Authentication for DNS (TSIG). May 2000. 

 

 

-
[RFC2930] D. Eastlake, 3rd. Secret Key Establishment for DNS (TKEY RR). September 2000. 

+
[RFC2930] D. Eastlake, 3rd. Secret Key Establishment for DNS (TKEY RR). September 2000. 

 

 

-
[RFC2931] D. Eastlake, 3rd. DNS Request and Transaction Signatures (SIG(0)s). September 2000. 

+
[RFC2931] D. Eastlake, 3rd. DNS Request and Transaction Signatures (SIG(0)s). September 2000. 

 

 

-
[RFC3007] B. Wellington. Secure Domain Name System (DNS) Dynamic Update. November 2000. 

+
[RFC3007] B. Wellington. Secure Domain Name System (DNS) Dynamic Update. November 2000. 

 

 

-
[RFC3645] S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, and R. Hall. Generic Security Service Algorithm for Secret
+
[RFC3645] S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, and R. Hall. Generic Security Service Algorithm for Secret
                        Key Transaction Authentication for DNS
                        (GSS-TSIG). October 2003. 

 

@@ -314,19 +312,19 @@
 

 DNS Security Proposed Standards

 

-
[RFC3225] D. Conrad. Indicating Resolver Support of DNSSEC. December 2001. 

+
[RFC3225] D. Conrad. Indicating Resolver Support of DNSSEC. December 2001. 

 

 

-
[RFC3833] D. Atkins and R. Austein. Threat Analysis of the Domain Name System (DNS). August 2004. 

+
[RFC3833] D. Atkins and R. Austein. Threat Analysis of the Domain Name System (DNS). August 2004. 

 

 

-
[RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS Security Introduction and Requirements. March 2005. 

+
[RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS Security Introduction and Requirements. March 2005. 

 

 

-
[RFC4044] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Resource Records for the DNS Security Extensions. March 2005. 

+
[RFC4034] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Resource Records for the DNS Security Extensions. March 2005. 

 

 

-
[RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Protocol Modifications for the DNS
+
[RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Protocol Modifications for the DNS
                        Security Extensions. March 2005. 

 

 
@@ -334,146 +332,146 @@
 
Other Important RFCs About DNS
                 Implementation

 

-
[RFC1535] E. Gavron. A Security Problem and Proposed Correction With Widely
+
[RFC1535] E. Gavron. A Security Problem and Proposed Correction With Widely
                   Deployed DNS Software.. October 1993. 

 

 

-
[RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller. Common DNS Implementation
+
[RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller. Common DNS Implementation
                   Errors and Suggested Fixes. October 1993. 

 

 

-
[RFC1982] R. Elz and R. Bush. Serial Number Arithmetic. August 1996. 

+
[RFC1982] R. Elz and R. Bush. Serial Number Arithmetic. August 1996. 

 

 

-
[RFC4074] Y. Morishita and T. Jinmei. Common Misbehaviour Against DNS
+
[RFC4074] Y. Morishita and T. Jinmei. Common Misbehaviour Against DNS
                 Queries for IPv6 Addresses. May 2005. 

 

 
 

 
Resource Record Types

 

-
[RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris. New DNS RR Definitions. October 1990. 

+
[RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris. New DNS RR Definitions. October 1990. 

 

 

-
[RFC1706] B. Manning and R. Colella. DNS NSAP Resource Records. October 1994. 

+
[RFC1706] B. Manning and R. Colella. DNS NSAP Resource Records. October 1994. 

 

 

-
[RFC2168] R. Daniel and M. Mealling. Resolution of Uniform Resource Identifiers using
+
[RFC2168] R. Daniel and M. Mealling. Resolution of Uniform Resource Identifiers using
                   the Domain Name System. June 1997. 

 

 

-
[RFC1876] C. Davis, P. Vixie, T., and I. Dickinson. A Means for Expressing Location Information in the
+
[RFC1876] C. Davis, P. Vixie, T., and I. Dickinson. A Means for Expressing Location Information in the
                   Domain
                   Name System. January 1996. 

 

 

-
[RFC2052] A. Gulbrandsen and P. Vixie. A DNS RR for Specifying the
+
[RFC2052] A. Gulbrandsen and P. Vixie. A DNS RR for Specifying the
                   Location of
                   Services.. October 1996. 

 

 

-
[RFC2163] A. Allocchio. Using the Internet DNS to
+
[RFC2163] A. Allocchio. Using the Internet DNS to
                   Distribute MIXER
                   Conformant Global Address Mapping. January 1998. 

 

 

-
[RFC2230] R. Atkinson. Key Exchange Delegation Record for the DNS. October 1997. 

+
[RFC2230] R. Atkinson. Key Exchange Delegation Record for the DNS. October 1997. 

 

 

-
[RFC2536] D. Eastlake, 3rd. DSA KEYs and SIGs in the Domain Name System (DNS). March 1999. 

+
[RFC2536] D. Eastlake, 3rd. DSA KEYs and SIGs in the Domain Name System (DNS). March 1999. 

 

 

-
[RFC2537] D. Eastlake, 3rd. RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). March 1999. 

+
[RFC2537] D. Eastlake, 3rd. RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). March 1999. 

 

 

-
[RFC2538] D. Eastlake, 3rd and O. Gudmundsson. Storing Certificates in the Domain Name System (DNS). March 1999. 

+
[RFC2538] D. Eastlake, 3rd and O. Gudmundsson. Storing Certificates in the Domain Name System (DNS). March 1999. 

 

 

-
[RFC2539] D. Eastlake, 3rd. Storage of Diffie-Hellman Keys in the Domain Name System (DNS). March 1999. 

+
[RFC2539] D. Eastlake, 3rd. Storage of Diffie-Hellman Keys in the Domain Name System (DNS). March 1999. 

 

 

-
[RFC2540] D. Eastlake, 3rd. Detached Domain Name System (DNS) Information. March 1999. 

+
[RFC2540] D. Eastlake, 3rd. Detached Domain Name System (DNS) Information. March 1999. 

 

 

-
[RFC2782] A. Gulbrandsen. P. Vixie. L. Esibov. A DNS RR for specifying the location of services (DNS SRV). February 2000. 

+
[RFC2782] A. Gulbrandsen. P. Vixie. L. Esibov. A DNS RR for specifying the location of services (DNS SRV). February 2000. 

 

 

-
[RFC2915] M. Mealling. R. Daniel. The Naming Authority Pointer (NAPTR) DNS Resource Record. September 2000. 

+
[RFC2915] M. Mealling. R. Daniel. The Naming Authority Pointer (NAPTR) DNS Resource Record. September 2000. 

 

 

-
[RFC3110] D. Eastlake, 3rd. RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS). May 2001. 

+
[RFC3110] D. Eastlake, 3rd. RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS). May 2001. 

 

 

-
[RFC3123] P. Koch. A DNS RR Type for Lists of Address Prefixes (APL RR). June 2001. 

+
[RFC3123] P. Koch. A DNS RR Type for Lists of Address Prefixes (APL RR). June 2001. 

 

 

-
[RFC3596] S. Thomson, C. Huitema, V. Ksinant, and M. Souissi. DNS Extensions to support IP
+
[RFC3596] S. Thomson, C. Huitema, V. Ksinant, and M. Souissi. DNS Extensions to support IP
                   version 6. October 2003. 

 

 

-
[RFC3597] A. Gustafsson. Handling of Unknown DNS Resource Record (RR) Types. September 2003. 

+
[RFC3597] A. Gustafsson. Handling of Unknown DNS Resource Record (RR) Types. September 2003. 

 

 

 

 

 DNS and the Internet

 

-
[RFC1101] P. V. Mockapetris. DNS Encoding of Network Names
+
[RFC1101] P. V. Mockapetris. DNS Encoding of Network Names
                   and Other Types. April 1989. 

 

 

-
[RFC1123] Braden. Requirements for Internet Hosts - Application and
+
[RFC1123] Braden. Requirements for Internet Hosts - Application and
                   Support. October 1989. 

 

 

-
[RFC1591] J. Postel. Domain Name System Structure and Delegation. March 1994. 

+
[RFC1591] J. Postel. Domain Name System Structure and Delegation. March 1994. 

 

 

-
[RFC2317] H. Eidnes, G. de Groot, and P. Vixie. Classless IN-ADDR.ARPA Delegation. March 1998. 

+
[RFC2317] H. Eidnes, G. de Groot, and P. Vixie. Classless IN-ADDR.ARPA Delegation. March 1998. 

 

 

-
[RFC2826] Internet Architecture Board. IAB Technical Comment on the Unique DNS Root. May 2000. 

+
[RFC2826] Internet Architecture Board. IAB Technical Comment on the Unique DNS Root. May 2000. 

 

 

-
[RFC2929] D. Eastlake, 3rd, E. Brunner-Williams, and B. Manning. Domain Name System (DNS) IANA Considerations. September 2000. 

+
[RFC2929] D. Eastlake, 3rd, E. Brunner-Williams, and B. Manning. Domain Name System (DNS) IANA Considerations. September 2000. 

 

 

 

 

 DNS Operations

 

-
[RFC1033] M. Lottor. Domain administrators operations guide.. November 1987. 

+
[RFC1033] M. Lottor. Domain administrators operations guide.. November 1987. 

 

 

-
[RFC1537] P. Beertema. Common DNS Data File
+
[RFC1537] P. Beertema. Common DNS Data File
                   Configuration Errors. October 1993. 

 

 

-
[RFC1912] D. Barr. Common DNS Operational and
+
[RFC1912] D. Barr. Common DNS Operational and
                   Configuration Errors. February 1996. 

 

 

-
[RFC2010] B. Manning and P. Vixie. Operational Criteria for Root Name Servers.. October 1996. 

+
[RFC2010] B. Manning and P. Vixie. Operational Criteria for Root Name Servers.. October 1996. 

 

 

-
[RFC2219] M. Hamilton and R. Wright. Use of DNS Aliases for
+
[RFC2219] M. Hamilton and R. Wright. Use of DNS Aliases for
                   Network Services.. October 1997. 

 

 

 

 
Internationalized Domain Names

 

-
[RFC2825] IAB and R. Daigle. A Tangled Web: Issues of I18N, Domain Names,
+
[RFC2825] IAB and R. Daigle. A Tangled Web: Issues of I18N, Domain Names,
                        and the Other Internet protocols. May 2000. 

 

 

-
[RFC3490] P. Faltstrom, P. Hoffman, and A. Costello. Internationalizing Domain Names in Applications (IDNA). March 2003. 

+
[RFC3490] P. Faltstrom, P. Hoffman, and A. Costello. Internationalizing Domain Names in Applications (IDNA). March 2003. 

 

 

-
[RFC3491] P. Hoffman and M. Blanchet. Nameprep: A Stringprep Profile for Internationalized Domain Names. March 2003. 

+
[RFC3491] P. Hoffman and M. Blanchet. Nameprep: A Stringprep Profile for Internationalized Domain Names. March 2003. 

 

 

-
[RFC3492] A. Costello. Punycode: A Bootstring encoding of Unicode
+
[RFC3492] A. Costello. Punycode: A Bootstring encoding of Unicode
                        for Internationalized Domain Names in
                        Applications (IDNA). March 2003. 

 

@@ -489,47 +487,47 @@
                 

 

 

-
[RFC1464] R. Rosenbaum. Using the Domain Name System To Store Arbitrary String
+
[RFC1464] R. Rosenbaum. Using the Domain Name System To Store Arbitrary String
                   Attributes. May 1993. 

 

 

-
[RFC1713] A. Romao. Tools for DNS Debugging. November 1994. 

+
[RFC1713] A. Romao. Tools for DNS Debugging. November 1994. 

 

 

-
[RFC1794] T. Brisco. DNS Support for Load
+
[RFC1794] T. Brisco. DNS Support for Load
                   Balancing. April 1995. 

 

 

-
[RFC2240] O. Vaughan. A Legal Basis for Domain Name Allocation. November 1997. 

+
[RFC2240] O. Vaughan. A Legal Basis for Domain Name Allocation. November 1997. 

 

 

-
[RFC2345] J. Klensin, T. Wolf, and G. Oglesby. Domain Names and Company Name Retrieval. May 1998. 

+
[RFC2345] J. Klensin, T. Wolf, and G. Oglesby. Domain Names and Company Name Retrieval. May 1998. 

 

 

-
[RFC2352] O. Vaughan. A Convention For Using Legal Names as Domain Names. May 1998. 

+
[RFC2352] O. Vaughan. A Convention For Using Legal Names as Domain Names. May 1998. 

 

 

-
[RFC3071] J. Klensin. Reflections on the DNS, RFC 1591, and Categories of Domains. February 2001. 

+
[RFC3071] J. Klensin. Reflections on the DNS, RFC 1591, and Categories of Domains. February 2001. 

 

 

-
[RFC3258] T. Hardie. Distributing Authoritative Name Servers via
+
[RFC3258] T. Hardie. Distributing Authoritative Name Servers via
                        Shared Unicast Addresses. April 2002. 

 

 

-
[RFC3901] A. Durand and J. Ihren. DNS IPv6 Transport Operational Guidelines. September 2004. 

+
[RFC3901] A. Durand and J. Ihren. DNS IPv6 Transport Operational Guidelines. September 2004. 

 

 
 

 
Obsolete and Unimplemented Experimental RFC

 

-
[RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni. DNS Encoding of Geographical
+
[RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni. DNS Encoding of Geographical
                   Location. November 1994. 

 

 

-
[RFC2673] M. Crawford. Binary Labels in the Domain Name System. August 1999. 

+
[RFC2673] M. Crawford. Binary Labels in the Domain Name System. August 1999. 

 

 

-
[RFC2874] M. Crawford and C. Huitema. DNS Extensions to Support IPv6 Address Aggregation
+
[RFC2874] M. Crawford and C. Huitema. DNS Extensions to Support IPv6 Address Aggregation
                        and Renumbering. July 2000. 

 

 

@@ -543,39 +541,39 @@
                 

 
 

-
[RFC2065] D. Eastlake, 3rd and C. Kaufman. Domain Name System Security Extensions. January 1997. 

+
[RFC2065] D. Eastlake, 3rd and C. Kaufman. Domain Name System Security Extensions. January 1997. 

 

 

-
[RFC2137] D. Eastlake, 3rd. Secure Domain Name System Dynamic Update. April 1997. 

+
[RFC2137] D. Eastlake, 3rd. Secure Domain Name System Dynamic Update. April 1997. 

 

 

-
[RFC2535] D. Eastlake, 3rd. Domain Name System Security Extensions. March 1999. 

+
[RFC2535] D. Eastlake, 3rd. Domain Name System Security Extensions. March 1999. 

 

 

-
[RFC3008] B. Wellington. Domain Name System Security (DNSSEC)
+
[RFC3008] B. Wellington. Domain Name System Security (DNSSEC)
                        Signing Authority. November 2000. 

 

 

-
[RFC3090] E. Lewis. DNS Security Extension Clarification on Zone Status. March 2001. 

+
[RFC3090] E. Lewis. DNS Security Extension Clarification on Zone Status. March 2001. 

 

 

-
[RFC3445] D. Massey and S. Rose. Limiting the Scope of the KEY Resource Record (RR). December 2002. 

+
[RFC3445] D. Massey and S. Rose. Limiting the Scope of the KEY Resource Record (RR). December 2002. 

 

 

-
[RFC3655] B. Wellington and O. Gudmundsson. Redefinition of DNS Authenticated Data (AD) bit. November 2003. 

+
[RFC3655] B. Wellington and O. Gudmundsson. Redefinition of DNS Authenticated Data (AD) bit. November 2003. 

 

 

-
[RFC3658] O. Gudmundsson. Delegation Signer (DS) Resource Record (RR). December 2003. 

+
[RFC3658] O. Gudmundsson. Delegation Signer (DS) Resource Record (RR). December 2003. 

 

 

-
[RFC3755] S. Weiler. Legacy Resolver Compatibility for Delegation Signer (DS). May 2004. 

+
[RFC3755] S. Weiler. Legacy Resolver Compatibility for Delegation Signer (DS). May 2004. 

 

 

-
[RFC3757] O. Kolkman, J. Schlyter, and E. Lewis. Domain Name System KEY (DNSKEY) Resource Record
+
[RFC3757] O. Kolkman, J. Schlyter, and E. Lewis. Domain Name System KEY (DNSKEY) Resource Record
                       (RR) Secure Entry Point (SEP) Flag. April 2004. 

 

 

-
[RFC3845] J. Schlyter. DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. August 2004. 

+
[RFC3845] J. Schlyter. DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. August 2004. 

 

 
 
@@ -596,14 +594,14 @@
 
 

 

-Other Documents About BIND
+Other Documents About BIND
 

 

 

 

-Bibliography

+Bibliography

 

-
Paul Albitz and Cricket Liu. DNS and BIND. Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. 

+
Paul Albitz and Cricket Liu. DNS and BIND. Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. 

 

 
 
diff --git a/doc/arm/Bv9ARM.ch10.html b/doc/arm/Bv9ARM.ch10.html
index 892ab16b942a..9be4eb6191e2 100644
--- a/doc/arm/Bv9ARM.ch10.html
+++ b/doc/arm/Bv9ARM.ch10.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html
index 6de42bcee192..e37899055885 100644
--- a/doc/arm/Bv9ARM.html
+++ b/doc/arm/Bv9ARM.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -41,7 +41,7 @@
 

 

 BIND 9 Administrator Reference Manual

-
Copyright © 2004-2008 Internet Systems Consortium, Inc. ("ISC")

+
Copyright © 2004-2009 Internet Systems Consortium, Inc. ("ISC")

 
Copyright © 2000-2003 Internet Software Consortium.

 

 

@@ -51,39 +51,39 @@
 

 
1. Introduction

 

-
Scope of Document

-
Organization of This Document

-
Conventions Used in This Document

-
The Domain Name System (DNS)

+
Scope of Document

+
Organization of This Document

+
Conventions Used in This Document

+
The Domain Name System (DNS)

 

-
DNS Fundamentals

-
Domains and Domain Names

-
Zones

-
Authoritative Name Servers

-
Caching Name Servers

-
Name Servers in Multiple Roles

+
DNS Fundamentals

+
Domains and Domain Names

+
Zones

+
Authoritative Name Servers

+
Caching Name Servers

+
Name Servers in Multiple Roles

 

 

 
2. BIND Resource Requirements

 

-
Hardware requirements

-
CPU Requirements

-
Memory Requirements

-
Name Server Intensive Environment Issues

-
Supported Operating Systems

+
Hardware requirements

+
CPU Requirements

+
Memory Requirements

+
Name Server Intensive Environment Issues

+
Supported Operating Systems

 

 
3. Name Server Configuration

 

 
Sample Configurations

 

-
A Caching-only Name Server

-
An Authoritative-only Name Server

+
A Caching-only Name Server

+
An Authoritative-only Name Server

 

-
Load Balancing

-
Name Server Operations

+
Load Balancing

+
Name Server Operations

 

-
Tools for Use With the Name Server Daemon

-
Signals

+
Tools for Use With the Name Server Daemon

+
Signals

 

 

 
4. Advanced DNS Features

@@ -92,34 +92,34 @@
 
Dynamic Update

 
The journal file

 
Incremental Zone Transfers (IXFR)

-
Split DNS

-
Example split DNS setup

+
Split DNS

+
Example split DNS setup

 
TSIG

 

-
Generate Shared Keys for Each Pair of Hosts

-
Copying the Shared Secret to Both Machines

-
Informing the Servers of the Key's Existence

-
Instructing the Server to Use the Key

-
TSIG Key Based Access Control

-
Errors

+
Generate Shared Keys for Each Pair of Hosts

+
Copying the Shared Secret to Both Machines

+
Informing the Servers of the Key's Existence

+
Instructing the Server to Use the Key

+
TSIG Key Based Access Control

+
Errors

 

-
TKEY

-
SIG(0)

+
TKEY

+
SIG(0)

 
DNSSEC

 

-
Generating Keys

-
Signing the Zone

-
Configuring Servers

+
Generating Keys

+
Signing the Zone

+
Configuring Servers

 

-
IPv6 Support in BIND 9

+
IPv6 Support in BIND 9

 

-
Address Lookups Using AAAA Records

-
Address to Name Lookups Using Nibble Format

+
Address Lookups Using AAAA Records

+
Address to Name Lookups Using Nibble Format

 

 

 
5. The BIND 9 Lightweight Resolver

 

-
The Lightweight Resolver Library

+
The Lightweight Resolver Library

 
Running a Resolver Daemon

 

 
6. BIND 9 Configuration Reference

@@ -127,83 +127,83 @@
 
Configuration File Elements

 

 
Address Match Lists

-
Comment Syntax

+
Comment Syntax

 

 
Configuration File Grammar

 

-
acl Statement Grammar

+
acl Statement Grammar

 
acl Statement Definition and
           Usage

-
controls Statement Grammar

+
controls Statement Grammar

 
controls Statement Definition and
           Usage

-
include Statement Grammar

-
include Statement Definition and
+
include Statement Grammar

+
include Statement Definition and
           Usage

-
key Statement Grammar

-
key Statement Definition and Usage

-
logging Statement Grammar

-
logging Statement Definition and
+
key Statement Grammar

+
key Statement Definition and Usage

+
logging Statement Grammar

+
logging Statement Definition and
           Usage

-
lwres Statement Grammar

-
lwres Statement Definition and Usage

-
masters Statement Grammar

-
masters Statement Definition and
+
lwres Statement Grammar

+
lwres Statement Definition and Usage

+
masters Statement Grammar

+
masters Statement Definition and
           Usage

-
options Statement Grammar

+
options Statement Grammar

 
options Statement Definition and
           Usage

 
server Statement Grammar

 
server Statement Definition and
             Usage

-
trusted-keys Statement Grammar

-
trusted-keys Statement Definition
+
trusted-keys Statement Grammar

+
trusted-keys Statement Definition
             and Usage

 
view Statement Grammar

-
view Statement Definition and Usage

+
view Statement Definition and Usage

 
zone
             Statement Grammar

-
zone Statement Definition and Usage

+
zone Statement Definition and Usage

 

-
Zone File

+
Zone File

 

 
Types of Resource Records and When to Use Them

-
Discussion of MX Records

+
Discussion of MX Records

 
Setting TTLs

-
Inverse Mapping in IPv4

-
Other Zone File Directives

-
BIND Master File Extension: the  $GENERATE Directive

+
Inverse Mapping in IPv4

+
Other Zone File Directives

+
BIND Master File Extension: the  $GENERATE Directive

 
Additional File Formats

 

 
 
7. BIND 9 Security Considerations

 

 
Access Control Lists

-
Chroot and Setuid

+
Chroot and Setuid

 

-
The chroot Environment

-
Using the setuid Function

+
The chroot Environment

+
Using the setuid Function

 

 
Dynamic Update Security

 

 
8. Troubleshooting

 

-
Common Problems

-
It's not working; how can I figure out what's wrong?

-
Incrementing and Changing the Serial Number

-
Where Can I Get Help?

+
Common Problems

+
It's not working; how can I figure out what's wrong?

+
Incrementing and Changing the Serial Number

+
Where Can I Get Help?

 

 
A. Appendices

 

-
Acknowledgments

+
Acknowledgments

 
A Brief History of the DNS and BIND

-
General DNS Reference Information

+
General DNS Reference Information

 
IPv6 addresses (AAAA)

 
Bibliography (and Suggested Reading)

 

 
Request for Comments (RFCs)

 
Internet Drafts

-
Other Documents About BIND

+
Other Documents About BIND

 

 

 
I. Manual pages

diff --git a/doc/arm/Bv9ARM.pdf b/doc/arm/Bv9ARM.pdf
index 29637452ec51..12dd76c113eb 100644
--- a/doc/arm/Bv9ARM.pdf
+++ b/doc/arm/Bv9ARM.pdf
@@ -480,530 +480,536 @@ endobj
 (6.2.10.2 The category Phrase)
 endobj
 325 0 obj
-<< /S /GoTo /D (subsection.6.2.11) >>
+<< /S /GoTo /D (subsubsection.6.2.10.3) >>
 endobj
 328 0 obj
-(6.2.11 lwres Statement Grammar)
+(6.2.10.3 The query-errors Category)
 endobj
 329 0 obj
-<< /S /GoTo /D (subsection.6.2.12) >>
+<< /S /GoTo /D (subsection.6.2.11) >>
 endobj
 332 0 obj
-(6.2.12 lwres Statement Definition and Usage)
+(6.2.11 lwres Statement Grammar)
 endobj
 333 0 obj
-<< /S /GoTo /D (subsection.6.2.13) >>
+<< /S /GoTo /D (subsection.6.2.12) >>
 endobj
 336 0 obj
-(6.2.13 masters Statement Grammar)
+(6.2.12 lwres Statement Definition and Usage)
 endobj
 337 0 obj
-<< /S /GoTo /D (subsection.6.2.14) >>
+<< /S /GoTo /D (subsection.6.2.13) >>
 endobj
 340 0 obj
-(6.2.14 masters Statement Definition and Usage)
+(6.2.13 masters Statement Grammar)
 endobj
 341 0 obj
-<< /S /GoTo /D (subsection.6.2.15) >>
+<< /S /GoTo /D (subsection.6.2.14) >>
 endobj
 344 0 obj
-(6.2.15 options Statement Grammar)
+(6.2.14 masters Statement Definition and Usage)
 endobj
 345 0 obj
-<< /S /GoTo /D (subsection.6.2.16) >>
+<< /S /GoTo /D (subsection.6.2.15) >>
 endobj
 348 0 obj
-(6.2.16 options Statement Definition and Usage)
+(6.2.15 options Statement Grammar)
 endobj
 349 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.1) >>
+<< /S /GoTo /D (subsection.6.2.16) >>
 endobj
 352 0 obj
-(6.2.16.1 Boolean Options)
+(6.2.16 options Statement Definition and Usage)
 endobj
 353 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.2) >>
+<< /S /GoTo /D (subsubsection.6.2.16.1) >>
 endobj
 356 0 obj
-(6.2.16.2 Forwarding)
+(6.2.16.1 Boolean Options)
 endobj
 357 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.3) >>
+<< /S /GoTo /D (subsubsection.6.2.16.2) >>
 endobj
 360 0 obj
-(6.2.16.3 Dual-stack Servers)
+(6.2.16.2 Forwarding)
 endobj
 361 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.4) >>
+<< /S /GoTo /D (subsubsection.6.2.16.3) >>
 endobj
 364 0 obj
-(6.2.16.4 Access Control)
+(6.2.16.3 Dual-stack Servers)
 endobj
 365 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.5) >>
+<< /S /GoTo /D (subsubsection.6.2.16.4) >>
 endobj
 368 0 obj
-(6.2.16.5 Interfaces)
+(6.2.16.4 Access Control)
 endobj
 369 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.6) >>
+<< /S /GoTo /D (subsubsection.6.2.16.5) >>
 endobj
 372 0 obj
-(6.2.16.6 Query Address)
+(6.2.16.5 Interfaces)
 endobj
 373 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.7) >>
+<< /S /GoTo /D (subsubsection.6.2.16.6) >>
 endobj
 376 0 obj
-(6.2.16.7 Zone Transfers)
+(6.2.16.6 Query Address)
 endobj
 377 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.8) >>
+<< /S /GoTo /D (subsubsection.6.2.16.7) >>
 endobj
 380 0 obj
-(6.2.16.8 UDP Port Lists)
+(6.2.16.7 Zone Transfers)
 endobj
 381 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.9) >>
+<< /S /GoTo /D (subsubsection.6.2.16.8) >>
 endobj
 384 0 obj
-(6.2.16.9 Operating System Resource Limits)
+(6.2.16.8 UDP Port Lists)
 endobj
 385 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.10) >>
+<< /S /GoTo /D (subsubsection.6.2.16.9) >>
 endobj
 388 0 obj
-(6.2.16.10 Server Resource Limits)
+(6.2.16.9 Operating System Resource Limits)
 endobj
 389 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.11) >>
+<< /S /GoTo /D (subsubsection.6.2.16.10) >>
 endobj
 392 0 obj
-(6.2.16.11 Periodic Task Intervals)
+(6.2.16.10 Server Resource Limits)
 endobj
 393 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.12) >>
+<< /S /GoTo /D (subsubsection.6.2.16.11) >>
 endobj
 396 0 obj
-(6.2.16.12 Topology)
+(6.2.16.11 Periodic Task Intervals)
 endobj
 397 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.13) >>
+<< /S /GoTo /D (subsubsection.6.2.16.12) >>
 endobj
 400 0 obj
-(6.2.16.13 The sortlist Statement)
+(6.2.16.12 Topology)
 endobj
 401 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.14) >>
+<< /S /GoTo /D (subsubsection.6.2.16.13) >>
 endobj
 404 0 obj
-(6.2.16.14 RRset Ordering)
+(6.2.16.13 The sortlist Statement)
 endobj
 405 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.15) >>
+<< /S /GoTo /D (subsubsection.6.2.16.14) >>
 endobj
 408 0 obj
-(6.2.16.15 Tuning)
+(6.2.16.14 RRset Ordering)
 endobj
 409 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.16) >>
+<< /S /GoTo /D (subsubsection.6.2.16.15) >>
 endobj
 412 0 obj
-(6.2.16.16 Built-in server information zones)
+(6.2.16.15 Tuning)
 endobj
 413 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.17) >>
+<< /S /GoTo /D (subsubsection.6.2.16.16) >>
 endobj
 416 0 obj
-(6.2.16.17 Built-in Empty Zones)
+(6.2.16.16 Built-in server information zones)
 endobj
 417 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.18) >>
+<< /S /GoTo /D (subsubsection.6.2.16.17) >>
 endobj
 420 0 obj
-(6.2.16.18 The Statistics File)
+(6.2.16.17 Built-in Empty Zones)
 endobj
 421 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.19) >>
+<< /S /GoTo /D (subsubsection.6.2.16.18) >>
 endobj
 424 0 obj
-(6.2.16.19 Additional Section Caching)
+(6.2.16.18 The Statistics File)
 endobj
 425 0 obj
-<< /S /GoTo /D (subsection.6.2.17) >>
+<< /S /GoTo /D (subsubsection.6.2.16.19) >>
 endobj
 428 0 obj
-(6.2.17 server Statement Grammar)
+(6.2.16.19 Additional Section Caching)
 endobj
 429 0 obj
-<< /S /GoTo /D (subsection.6.2.18) >>
+<< /S /GoTo /D (subsection.6.2.17) >>
 endobj
 432 0 obj
-(6.2.18 server Statement Definition and Usage)
+(6.2.17 server Statement Grammar)
 endobj
 433 0 obj
-<< /S /GoTo /D (subsection.6.2.19) >>
+<< /S /GoTo /D (subsection.6.2.18) >>
 endobj
 436 0 obj
-(6.2.19 trusted-keys Statement Grammar)
+(6.2.18 server Statement Definition and Usage)
 endobj
 437 0 obj
-<< /S /GoTo /D (subsection.6.2.20) >>
+<< /S /GoTo /D (subsection.6.2.19) >>
 endobj
 440 0 obj
-(6.2.20 trusted-keys Statement Definition and Usage)
+(6.2.19 trusted-keys Statement Grammar)
 endobj
 441 0 obj
-<< /S /GoTo /D (subsection.6.2.21) >>
+<< /S /GoTo /D (subsection.6.2.20) >>
 endobj
 444 0 obj
-(6.2.21 view Statement Grammar)
+(6.2.20 trusted-keys Statement Definition and Usage)
 endobj
 445 0 obj
-<< /S /GoTo /D (subsection.6.2.22) >>
+<< /S /GoTo /D (subsection.6.2.21) >>
 endobj
 448 0 obj
-(6.2.22 view Statement Definition and Usage)
+(6.2.21 view Statement Grammar)
 endobj
 449 0 obj
-<< /S /GoTo /D (subsection.6.2.23) >>
+<< /S /GoTo /D (subsection.6.2.22) >>
 endobj
 452 0 obj
-(6.2.23 zone Statement Grammar)
+(6.2.22 view Statement Definition and Usage)
 endobj
 453 0 obj
-<< /S /GoTo /D (subsection.6.2.24) >>
+<< /S /GoTo /D (subsection.6.2.23) >>
 endobj
 456 0 obj
-(6.2.24 zone Statement Definition and Usage)
+(6.2.23 zone Statement Grammar)
 endobj
 457 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.1) >>
+<< /S /GoTo /D (subsection.6.2.24) >>
 endobj
 460 0 obj
-(6.2.24.1 Zone Types)
+(6.2.24 zone Statement Definition and Usage)
 endobj
 461 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.2) >>
+<< /S /GoTo /D (subsubsection.6.2.24.1) >>
 endobj
 464 0 obj
-(6.2.24.2 Class)
+(6.2.24.1 Zone Types)
 endobj
 465 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.3) >>
+<< /S /GoTo /D (subsubsection.6.2.24.2) >>
 endobj
 468 0 obj
-(6.2.24.3 Zone Options)
+(6.2.24.2 Class)
 endobj
 469 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.4) >>
+<< /S /GoTo /D (subsubsection.6.2.24.3) >>
 endobj
 472 0 obj
-(6.2.24.4 Dynamic Update Policies)
+(6.2.24.3 Zone Options)
 endobj
 473 0 obj
-<< /S /GoTo /D (section.6.3) >>
+<< /S /GoTo /D (subsubsection.6.2.24.4) >>
 endobj
 476 0 obj
-(6.3 Zone File)
+(6.2.24.4 Dynamic Update Policies)
 endobj
 477 0 obj
-<< /S /GoTo /D (subsection.6.3.1) >>
+<< /S /GoTo /D (section.6.3) >>
 endobj
 480 0 obj
-(6.3.1 Types of Resource Records and When to Use Them)
+(6.3 Zone File)
 endobj
 481 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.1) >>
+<< /S /GoTo /D (subsection.6.3.1) >>
 endobj
 484 0 obj
-(6.3.1.1 Resource Records)
+(6.3.1 Types of Resource Records and When to Use Them)
 endobj
 485 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.2) >>
+<< /S /GoTo /D (subsubsection.6.3.1.1) >>
 endobj
 488 0 obj
-(6.3.1.2 Textual expression of RRs)
+(6.3.1.1 Resource Records)
 endobj
 489 0 obj
-<< /S /GoTo /D (subsection.6.3.2) >>
+<< /S /GoTo /D (subsubsection.6.3.1.2) >>
 endobj
 492 0 obj
-(6.3.2 Discussion of MX Records)
+(6.3.1.2 Textual expression of RRs)
 endobj
 493 0 obj
-<< /S /GoTo /D (subsection.6.3.3) >>
+<< /S /GoTo /D (subsection.6.3.2) >>
 endobj
 496 0 obj
-(6.3.3 Setting TTLs)
+(6.3.2 Discussion of MX Records)
 endobj
 497 0 obj
-<< /S /GoTo /D (subsection.6.3.4) >>
+<< /S /GoTo /D (subsection.6.3.3) >>
 endobj
 500 0 obj
-(6.3.4 Inverse Mapping in IPv4)
+(6.3.3 Setting TTLs)
 endobj
 501 0 obj
-<< /S /GoTo /D (subsection.6.3.5) >>
+<< /S /GoTo /D (subsection.6.3.4) >>
 endobj
 504 0 obj
-(6.3.5 Other Zone File Directives)
+(6.3.4 Inverse Mapping in IPv4)
 endobj
 505 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.1) >>
+<< /S /GoTo /D (subsection.6.3.5) >>
 endobj
 508 0 obj
-(6.3.5.1 The \044ORIGIN Directive)
+(6.3.5 Other Zone File Directives)
 endobj
 509 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.2) >>
+<< /S /GoTo /D (subsubsection.6.3.5.1) >>
 endobj
 512 0 obj
-(6.3.5.2 The \044INCLUDE Directive)
+(6.3.5.1 The \044ORIGIN Directive)
 endobj
 513 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.3) >>
+<< /S /GoTo /D (subsubsection.6.3.5.2) >>
 endobj
 516 0 obj
-(6.3.5.3 The \044TTL Directive)
+(6.3.5.2 The \044INCLUDE Directive)
 endobj
 517 0 obj
-<< /S /GoTo /D (subsection.6.3.6) >>
+<< /S /GoTo /D (subsubsection.6.3.5.3) >>
 endobj
 520 0 obj
-(6.3.6 BIND Master File Extension: the \044GENERATE Directive)
+(6.3.5.3 The \044TTL Directive)
 endobj
 521 0 obj
-<< /S /GoTo /D (subsection.6.3.7) >>
+<< /S /GoTo /D (subsection.6.3.6) >>
 endobj
 524 0 obj
-(6.3.7 Additional File Formats)
+(6.3.6 BIND Master File Extension: the \044GENERATE Directive)
 endobj
 525 0 obj
-<< /S /GoTo /D (chapter.7) >>
+<< /S /GoTo /D (subsection.6.3.7) >>
 endobj
 528 0 obj
-(7 BIND 9 Security Considerations)
+(6.3.7 Additional File Formats)
 endobj
 529 0 obj
-<< /S /GoTo /D (section.7.1) >>
+<< /S /GoTo /D (chapter.7) >>
 endobj
 532 0 obj
-(7.1 Access Control Lists)
+(7 BIND 9 Security Considerations)
 endobj
 533 0 obj
-<< /S /GoTo /D (section.7.2) >>
+<< /S /GoTo /D (section.7.1) >>
 endobj
 536 0 obj
-(7.2 Chroot and Setuid)
+(7.1 Access Control Lists)
 endobj
 537 0 obj
-<< /S /GoTo /D (subsection.7.2.1) >>
+<< /S /GoTo /D (section.7.2) >>
 endobj
 540 0 obj
-(7.2.1 The chroot Environment)
+(7.2 Chroot and Setuid)
 endobj
 541 0 obj
-<< /S /GoTo /D (subsection.7.2.2) >>
+<< /S /GoTo /D (subsection.7.2.1) >>
 endobj
 544 0 obj
-(7.2.2 Using the setuid Function)
+(7.2.1 The chroot Environment)
 endobj
 545 0 obj
-<< /S /GoTo /D (section.7.3) >>
+<< /S /GoTo /D (subsection.7.2.2) >>
 endobj
 548 0 obj
-(7.3 Dynamic Update Security)
+(7.2.2 Using the setuid Function)
 endobj
 549 0 obj
-<< /S /GoTo /D (chapter.8) >>
+<< /S /GoTo /D (section.7.3) >>
 endobj
 552 0 obj
-(8 Troubleshooting)
+(7.3 Dynamic Update Security)
 endobj
 553 0 obj
-<< /S /GoTo /D (section.8.1) >>
+<< /S /GoTo /D (chapter.8) >>
 endobj
 556 0 obj
-(8.1 Common Problems)
+(8 Troubleshooting)
 endobj
 557 0 obj
-<< /S /GoTo /D (subsection.8.1.1) >>
+<< /S /GoTo /D (section.8.1) >>
 endobj
 560 0 obj
-(8.1.1 It's not working; how can I figure out what's wrong?)
+(8.1 Common Problems)
 endobj
 561 0 obj
-<< /S /GoTo /D (section.8.2) >>
+<< /S /GoTo /D (subsection.8.1.1) >>
 endobj
 564 0 obj
-(8.2 Incrementing and Changing the Serial Number)
+(8.1.1 It's not working; how can I figure out what's wrong?)
 endobj
 565 0 obj
-<< /S /GoTo /D (section.8.3) >>
+<< /S /GoTo /D (section.8.2) >>
 endobj
 568 0 obj
-(8.3 Where Can I Get Help?)
+(8.2 Incrementing and Changing the Serial Number)
 endobj
 569 0 obj
-<< /S /GoTo /D (appendix.A) >>
+<< /S /GoTo /D (section.8.3) >>
 endobj
 572 0 obj
-(A Appendices)
+(8.3 Where Can I Get Help?)
 endobj
 573 0 obj
-<< /S /GoTo /D (section.A.1) >>
+<< /S /GoTo /D (appendix.A) >>
 endobj
 576 0 obj
-(A.1 Acknowledgments)
+(A Appendices)
 endobj
 577 0 obj
-<< /S /GoTo /D (subsection.A.1.1) >>
+<< /S /GoTo /D (section.A.1) >>
 endobj
 580 0 obj
-(A.1.1 A Brief History of the DNS and BIND)
+(A.1 Acknowledgments)
 endobj
 581 0 obj
-<< /S /GoTo /D (section.A.2) >>
+<< /S /GoTo /D (subsection.A.1.1) >>
 endobj
 584 0 obj
-(A.2 General DNS Reference Information)
+(A.1.1 A Brief History of the DNS and BIND)
 endobj
 585 0 obj
-<< /S /GoTo /D (subsection.A.2.1) >>
+<< /S /GoTo /D (section.A.2) >>
 endobj
 588 0 obj
-(A.2.1 IPv6 addresses \(AAAA\))
+(A.2 General DNS Reference Information)
 endobj
 589 0 obj
-<< /S /GoTo /D (section.A.3) >>
+<< /S /GoTo /D (subsection.A.2.1) >>
 endobj
 592 0 obj
-(A.3 Bibliography \(and Suggested Reading\))
+(A.2.1 IPv6 addresses \(AAAA\))
 endobj
 593 0 obj
-<< /S /GoTo /D (subsection.A.3.1) >>
+<< /S /GoTo /D (section.A.3) >>
 endobj
 596 0 obj
-(A.3.1 Request for Comments \(RFCs\))
+(A.3 Bibliography \(and Suggested Reading\))
 endobj
 597 0 obj
-<< /S /GoTo /D (subsection.A.3.2) >>
+<< /S /GoTo /D (subsection.A.3.1) >>
 endobj
 600 0 obj
-(A.3.2 Internet Drafts)
+(A.3.1 Request for Comments \(RFCs\))
 endobj
 601 0 obj
-<< /S /GoTo /D (subsection.A.3.3) >>
+<< /S /GoTo /D (subsection.A.3.2) >>
 endobj
 604 0 obj
-(A.3.3 Other Documents About BIND)
+(A.3.2 Internet Drafts)
 endobj
 605 0 obj
-<< /S /GoTo /D (appendix.B) >>
+<< /S /GoTo /D (subsection.A.3.3) >>
 endobj
 608 0 obj
-(B Manual pages)
+(A.3.3 Other Documents About BIND)
 endobj
 609 0 obj
-<< /S /GoTo /D (section.B.1) >>
+<< /S /GoTo /D (appendix.B) >>
 endobj
 612 0 obj
-(B.1 dig)
+(B Manual pages)
 endobj
 613 0 obj
-<< /S /GoTo /D (section.B.2) >>
+<< /S /GoTo /D (section.B.1) >>
 endobj
 616 0 obj
-(B.2 host)
+(B.1 dig)
 endobj
 617 0 obj
-<< /S /GoTo /D (section.B.3) >>
+<< /S /GoTo /D (section.B.2) >>
 endobj
 620 0 obj
-(B.3 dnssec-keygen)
+(B.2 host)
 endobj
 621 0 obj
-<< /S /GoTo /D (section.B.4) >>
+<< /S /GoTo /D (section.B.3) >>
 endobj
 624 0 obj
-(B.4 dnssec-signzone)
+(B.3 dnssec-keygen)
 endobj
 625 0 obj
-<< /S /GoTo /D (section.B.5) >>
+<< /S /GoTo /D (section.B.4) >>
 endobj
 628 0 obj
-(B.5 named-checkconf)
+(B.4 dnssec-signzone)
 endobj
 629 0 obj
-<< /S /GoTo /D (section.B.6) >>
+<< /S /GoTo /D (section.B.5) >>
 endobj
 632 0 obj
-(B.6 named-checkzone)
+(B.5 named-checkconf)
 endobj
 633 0 obj
-<< /S /GoTo /D (section.B.7) >>
+<< /S /GoTo /D (section.B.6) >>
 endobj
 636 0 obj
-(B.7 named)
+(B.6 named-checkzone)
 endobj
 637 0 obj
-<< /S /GoTo /D (section.B.8) >>
+<< /S /GoTo /D (section.B.7) >>
 endobj
 640 0 obj
-(B.8 rndc)
+(B.7 named)
 endobj
 641 0 obj
-<< /S /GoTo /D (section.B.9) >>
+<< /S /GoTo /D (section.B.8) >>
 endobj
 644 0 obj
-(B.9 rndc.conf)
+(B.8 rndc)
 endobj
 645 0 obj
-<< /S /GoTo /D (section.B.10) >>
+<< /S /GoTo /D (section.B.9) >>
 endobj
 648 0 obj
-(B.10 rndc-confgen)
+(B.9 rndc.conf)
 endobj
 649 0 obj
-<< /S /GoTo /D [650 0 R  /FitH ] >>
+<< /S /GoTo /D (section.B.10) >>
+endobj
+652 0 obj
+(B.10 rndc-confgen)
+endobj
+653 0 obj
+<< /S /GoTo /D [654 0 R  /FitH ] >>
 endobj
-653 0 obj <<
+657 0 obj <<
 /Length 236       
 /Filter /FlateDecode
 >>
 stream
 xÚÁJA†ïó9¶‡M'™d2s´T¥‚Beoâai·Rp·t­ïïÔÕ*êArÉÿ‘ü	/A}È–ՓºsžŠvíèƒ
¨B)þP+!ÃlQ¡bJÕÂwìNì1úÈP©)&>áóÚÍ®˜€-A½bEM¦pæêÍÃd¾¼[L+V?ÉcºØt»~÷ršã~[÷í¶Ú~ÝNë a¤(±ø˘’å÷9·MÿÚ<ŸwYŸÝQDËr;yƒ|ê~üÁÁýhÌ–ÁbïVV_§æŒlåP}&ûÿsßC+WDendstream
 endobj
-650 0 obj <<
+654 0 obj <<
 /Type /Page
-/Contents 653 0 R
-/Resources 652 0 R
+/Contents 657 0 R
+/Resources 656 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
+/Parent 663 0 R
 >> endobj
-651 0 obj <<
+655 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
 /PTEX.FileName (./isc-logo.pdf)
 /PTEX.PageNumber 1
-/PTEX.InfoDict 660 0 R 
+/PTEX.InfoDict 664 0 R 
 /Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
 /BBox [0.00000000 0.00000000 255.00000000 149.00000000]
 /Resources <<
 /ProcSet [ /PDF /Text ]
 /ColorSpace <<
-/R15 661 0 R
-/R9 662 0 R
-/R11 663 0 R
-/R13 664 0 R
+/R15 665 0 R
+/R9 666 0 R
+/R11 667 0 R
+/R13 668 0 R
 >>/ExtGState <<
-/R17 665 0 R
-/R8 666 0 R
->>/Font << /R19 667 0 R >>
+/R17 669 0 R
+/R8 670 0 R
+>>/Font << /R19 671 0 R >>
 >>
-/Length 668 0 R
+/Length 672 0 R
 /Filter /FlateDecode
 >>
 stream
@@ -1019,7 +1025,7 @@ x
 FÑÞIca­Ç0Ú)	¹A¿+ÇÀº
¸|-Tuùa>‚s:½¯•~K“ÒÞV׋„OÒAŠI…
ɪÁr2Q“°Ø¨Á>.zÎCN’¦{Õ«'^5Mã»Åûæ¡æÔÊý¹U1z6õßvãpF)ÂÏåìÊ›C£i#]bÝLkS#ˆQÁŽv–¨Ô­«•ÇcHŸ$¬Áê³DI­ÌÑptÅ73*_åª'ŽÚ¿¢ÚòQŒ×èŒ‚,É*Ñ+ôÚ™%vŽ&u߉ xœÉ-¾kz˜ χÚ	Q´Pë3ÈZ§q¢Æ0¯ˆwMÍ?©=õ*_Ç£RïѪëƬ¡”’¢g!SeRâÅéz·ÝŠFLÚŸv
 ÏÆ狼eÇNdæÌdï"gK2cëÉ—GoOá8GëÏϦ:B
Àht[~Ðåõ—×SÒÜ£uˆQk·%È´ÔÛ†ëiATÆÌp[OU‡Ç(zßQã³* *Ñûø®á¾FÅÍ„Ï'µV‡¾;1aŠÑüËŒÜr$¿Íâ9Ë8ˆüý‚TóþÏÍ÷_oôô¢ññCÙõ"ú*~uÊqæþéïÛ{Ç"ß~±Úú"ú…bùz+·£]OZ,SÏ¥._^·§_\^þ†56g‡3^®Ç5Z©®©¹Uý¶õòÇí÷O¿½<Ó#rYëé»Ë^~¹ÁÇ<ц®5%¥Ü~ÿñsõ\êídŽ3¼4ü~èé[iþÂÈg
óžµ|¥Ïà5³m“XSô7…ÿúáò¬ä>!»Î“O÷hKYð¿þîÇÓ3/¡úôÃgë¾4EO=öï¦üì“­‡v5”ùÜþû‚ék”ùôñR”Ì¡ÌlöÅ·ß_DÍη„Rf.{úÏåYӎͧÿ^ž©í5¬?ývýüeûMüó?Òƒendstream
 endobj
-660 0 obj
+664 0 obj
 <<
 /Producer (AFPL Ghostscript 8.51)
 /CreationDate (D:20050606145621)
@@ -1029,46 +1035,46 @@ endobj
 /Author (Douglas E. Appelt)
 >>
 endobj
-661 0 obj
-[/Separation/PANTONE#201805#20C/DeviceCMYK 669 0 R]
+665 0 obj
+[/Separation/PANTONE#201805#20C/DeviceCMYK 673 0 R]
 endobj
-662 0 obj
-[/Separation/PANTONE#207506#20C/DeviceCMYK 670 0 R]
+666 0 obj
+[/Separation/PANTONE#207506#20C/DeviceCMYK 674 0 R]
 endobj
-663 0 obj
-[/Separation/PANTONE#20301#20C/DeviceCMYK 671 0 R]
+667 0 obj
+[/Separation/PANTONE#20301#20C/DeviceCMYK 675 0 R]
 endobj
-664 0 obj
-[/Separation/PANTONE#20871#20C/DeviceCMYK 672 0 R]
+668 0 obj
+[/Separation/PANTONE#20871#20C/DeviceCMYK 676 0 R]
 endobj
-665 0 obj
+669 0 obj
 <<
 /Type /ExtGState
 /SA true
 >>
 endobj
-666 0 obj
+670 0 obj
 <<
 /Type /ExtGState
 /OPM 1
 >>
 endobj
-667 0 obj
+671 0 obj
 <<
 /BaseFont /NVXWCK#2BTrajanPro-Bold
-/FontDescriptor 673 0 R
+/FontDescriptor 677 0 R
 /Type /Font
 /FirstChar 67
 /LastChar 136
 /Widths [ 800 0 0 0 0 0 452 0 0 0 0 0 0 0 0 0 582 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 841 633 576 686 590 540 923 827 407 760]
-/Encoding 674 0 R
+/Encoding 678 0 R
 /Subtype /Type1
 >>
 endobj
-668 0 obj
+672 0 obj
 2362
 endobj
-669 0 obj
+673 0 obj
 <<
 /Filter /FlateDecode
 /FunctionType 4
@@ -1079,7 +1085,7 @@ endobj
 stream
 xœ«N)-P0PÈ-ÍQH­HÎPsõ,
QE¸zFÆ`^-=1°endstream
 endobj
-670 0 obj
+674 0 obj
 <<
 /Filter /FlateDecode
 /FunctionType 4
@@ -1090,7 +1096,7 @@ endobj
 stream
 xœ«N)-P0PÈ-ÍQH­HÎPsõLÑE‘D Êk8/«endstream
 endobj
-671 0 obj
+675 0 obj
 <<
 /Filter /FlateDecode
 /FunctionType 4
@@ -1101,7 +1107,7 @@ endobj
 stream
 xœ«N)-P0TÈ-ÍQH­HÎPq
ôLLÑD\=C0¯=D³endstream
 endobj
-672 0 obj
+676 0 obj
 <<
 /Filter /FlateDecode
 /FunctionType 4
@@ -1112,7 +1118,7 @@ endobj
 stream
 xœ«N)-P0Ð365³TÈ-ÍQH­HÎP€Š™X ‹™›#Äô-,ŒÀüZ&‹ˆendstream
 endobj
-673 0 obj
+677 0 obj
 <<
 /Type /FontDescriptor
 /FontName /NVXWCK#2BTrajanPro-Bold
@@ -1125,17 +1131,17 @@ endobj
 /StemV 138
 /MissingWidth 500
 /CharSet (/Msmall/C/Ysmall/Nsmall/Osmall/Esmall/Rsmall/S/Ssmall/I/Tsmall/Ismall/Usmall)
-/FontFile3 675 0 R
+/FontFile3 679 0 R
 >>
 endobj
-674 0 obj
+678 0 obj
 <<
 /Type /Encoding
 /BaseEncoding /WinAnsiEncoding
 /Differences [ 127/Nsmall/Tsmall/Esmall/Rsmall/Ysmall/Ssmall/Msmall/Osmall/Ismall/Usmall]
 >>
 endobj
-675 0 obj
+679 0 obj
 <<
 /Filter /FlateDecode
 /Subtype /Type1C
@@ -1158,44 +1164,44 @@ x
 ȼLçÇ<;—*X³«¥×ÛGâ_Y1ETïƒ4ˆÒ-U…_>´üØ¢æ}õï÷v¼
§ádù#¹rÛŸå¥@ÔÁ\5l…hð<8Ús·’?h¹†!-¶‚*JŠ»,\G/Wé9OW—×µ.Ÿ—­€&¨[”ÄIÁÚ´Ó½7ýáÐäKý¡«¨ðúš.cxQn<¼À°üÖëgöõÁúhíY8³¶+oî^÷ë°‹>9p¯“°¥!ÑÚÙ®ŠðK´¢†#©óRÄlxŽJ”ب¬Ò–àá•{ϳwÿaû’ožÇ£ëHõÅâH9”ç/.~å÷Ë
 »O·Øèv61Bá5*È<6ÞÍ,‡bh‘˜¶ž\Î]Çé#¹#ØÔÍ1Oúñ°Ï¤5oÂ]цÆß4}h˜î0$å,6ü¼”A,¯?/å;Rôcy6Ò½UJ¿§Y½X^é¶ÙÉŸ‡‹º–2¸K|o½Ø”/Ȩ/ƒ(Â2Ð#žNMKðrˆ
rœÛf9ËyZ¸Ú}$«Ö	õ–©) h`iÎGàAç÷´€H+Šˆ…Õ&*áX$žèìVŽhª”—›¾÷‡A1Ý£¤œÏ0‰÷—Hi éƒw~I(Áö2;à]¸L ™x4[¡OÜ,¾®ÆûÂQQ°”FdQ“ƒ¢¬„%\î¢Åâ:Ó;ÈÑ”ÌEb1ž’¡ˆÿ§=$¸¥?Iš¿CÐõ3¾C=VÐ'>·¯ôÌÒ+Ü~8	ç#;úÁ_£×á*qň+ô	8®‚ãÆpêŒ_YR”¾d%a	ç¡H\eÄõãDf£Ñ¨­ŽR[kφG¸ù/WT®ò•A5”H¥ÛVoo8hnû)¼ÞÃDn…ñëqÌzfåhý&þcQbµXÇß‚çLŽúõ;{²Ðñðué¿ÊÛÙ†-©[SÄ-Û¼ÔyubÜñhüm´œ4^Ë™ ääšLÿQ‹¡endstream
 endobj
-654 0 obj <<
-/D [650 0 R /XYZ 85.0394 794.5015 null]
+658 0 obj <<
+/D [654 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-655 0 obj <<
-/D [650 0 R /XYZ 85.0394 769.5949 null]
+659 0 obj <<
+/D [654 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-652 0 obj <<
-/Font << /F21 658 0 R >>
-/XObject << /Im1 651 0 R >>
+656 0 obj <<
+/Font << /F21 662 0 R >>
+/XObject << /Im1 655 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-678 0 obj <<
+682 0 obj <<
 /Length 999       
 /Filter /FlateDecode
 >>
 stream
-xÚµV]“¢:}÷Wð¨UC6|å‘AT¶\ÀÚÚÝGq†ªQ¼‚;5ÿþ6$Qï¼lÝò!ô±ûôI'„h~D3-dqÊ5›ÈÄÄÔÖ»Ö^À7‰ÁšŽãNëügðó7Ö6ú:«ï0ÁˆpNµÝÀ02
ÆÔÊÛ |;‡ºðª€×Ùtƒ˜È´¨¡éÌ@°»DÝ ·e3GÓm“#‹QÖ ³Á—	˜q‹ZZ¶Õ88M“hgT¶ù9ôÊÃDZxy­G¿³¯š‰‘yK
cX7Ž/b\DÒ)²-n·š(Ü/PN@{I	EP0DlAcãa¤S7¦Ù™VgÚé+Ø×ùqŸ×b–~Tu¾«ÄÄ+÷Uy¬‹ÓîAa×h¤3‚‰Qj©×0%
¿Ÿ•#Œ‚Ì–¥Ùàæ§2ŸÑú%üVgÂlØ`›wQÿKhú
-;IgÒÎdwÕ-·õûê8"Î0¿–]ëgaÄ©åh6eÀŒÏäS`ý}«že"ŽÒÅlÊYäÇ]QUE¹œêRŒ§*—õ¬AÞ!d(ç»rSl{+«ýF›¢ªÅó©–Ö¯…ì¦ê¦ømyTÿþÆát<”•t¿õ«°®Y)ORÌm.q Ùu8øŒ€„ nš´-í5ùžeü—ã
-6d#IZgù§ØäÅvU+KF_=—òNÑeít_ÖÅ:¿ª¿«÷p%k~8ä+YT!ý«··¶Âؤæ$\V¹‹¼j›sÄŒæR"6âŒÚ-$›ù²ÍâIö4âtè&r%HŸHâïÁØ‹YsrÝT!š™°Ýh¬=aŒÁ
-Ý`.Án
-CfIÜ(|é|
-²™°ê&cq$á¢e¤_RÖ¨h6Sï¼p9¢éUò`¾UË=&ñDŒs?ñfàÙÆÐ} ûÑÚ°³7[±#-»IE~š"ÅAŒ‘äë÷!ž <ë)½%õ0pCiOâDe•éÓ…ïnø 4N|¯å¨nÛèf	B´
@029ç}=½8JýoK AeLwîNÏr\çïyŸfn“(Kc¨-Q˜.Ãvõ¬þ$‰ç²¶8ítnXa÷âÕ/S_•'·{ÐçM	b§Š‡œôewÕèeAõwÊη'SäOÃ`êGžßÏ·‘ÛËÂ@Ô!¤¿å¢!“³¡àx™^攑Ý$HÏZÄˬO%¾¢
Ô"ÿ‚rw4ÎgêmmsøáÐqá'Ð> endobj
-679 0 obj <<
-/D [677 0 R /XYZ 56.6929 794.5015 null]
+683 0 obj <<
+/D [681 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-676 0 obj <<
-/Font << /F23 682 0 R /F14 685 0 R >>
+680 0 obj <<
+/Font << /F23 686 0 R /F14 689 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-688 0 obj <<
+692 0 obj <<
 /Length 2891      
 /Filter /FlateDecode
 >>
@@ -1216,1289 +1222,1311 @@ M
 ÁîGÓäm2ƒÅR…Bb7ŠÊõÌB·_K|òÂYÝ«Üý‡ü•y‚´O
 RDaYåxÏN,Š)Ò;ì]¥3"ÃÂÖÕgk›uÔaëê«m‘‚S)CvdXg‚±Hb¤k ,I˜†–D·œ…Ó™ó7íÉïå4ψ}µ
™J²#HÃz¤E‚ þåzø”¦¤ð ¥Ð¯òîââìÔ-töã)˜o•OþT¦3)$¬´ÄßxÁPáïþÌeÆÒØ'·ªïAœ+·üR#M.ŠgÎ×3ÿ¦þçñç/àJàí”s®Aendstream
 endobj
-687 0 obj <<
+691 0 obj <<
 /Type /Page
-/Contents 688 0 R
-/Resources 686 0 R
+/Contents 692 0 R
+/Resources 690 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
-/Annots [ 691 0 R 692 0 R 693 0 R 694 0 R 695 0 R 696 0 R 697 0 R 698 0 R 699 0 R 700 0 R 701 0 R 702 0 R 703 0 R 704 0 R 705 0 R 706 0 R 707 0 R 708 0 R 709 0 R 710 0 R 711 0 R 712 0 R 713 0 R 714 0 R 715 0 R 716 0 R 717 0 R 718 0 R 719 0 R 720 0 R 721 0 R 722 0 R 723 0 R 724 0 R 725 0 R 726 0 R 727 0 R 728 0 R 729 0 R 730 0 R 731 0 R 732 0 R 733 0 R 734 0 R 735 0 R 736 0 R 737 0 R 738 0 R 739 0 R 740 0 R ]
+/Parent 663 0 R
+/Annots [ 695 0 R 696 0 R 697 0 R 698 0 R 699 0 R 700 0 R 701 0 R 702 0 R 703 0 R 704 0 R 705 0 R 706 0 R 707 0 R 708 0 R 709 0 R 710 0 R 711 0 R 712 0 R 713 0 R 714 0 R 715 0 R 716 0 R 717 0 R 718 0 R 719 0 R 720 0 R 721 0 R 722 0 R 723 0 R 724 0 R 725 0 R 726 0 R 727 0 R 728 0 R 729 0 R 730 0 R 731 0 R 732 0 R 733 0 R 734 0 R 735 0 R 736 0 R 737 0 R 738 0 R 739 0 R 740 0 R 741 0 R 742 0 R 743 0 R 744 0 R ]
 >> endobj
-691 0 obj <<
+695 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 688.709 539.579 697.2967]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.1) >>
 >> endobj
-692 0 obj <<
+696 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 676.5858 539.579 685.4425]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.1) >>
 >> endobj
-693 0 obj <<
+697 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 664.4876 539.579 673.3442]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.2) >>
 >> endobj
-694 0 obj <<
+698 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 652.3894 539.579 661.246]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.3) >>
 >> endobj
-695 0 obj <<
+699 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 640.1914 539.579 649.1477]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.4) >>
 >> endobj
-696 0 obj <<
+700 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 628.0932 539.579 637.0495]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.1) >>
 >> endobj
-697 0 obj <<
+701 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 615.995 539.579 624.9512]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.2) >>
 >> endobj
-698 0 obj <<
+702 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 603.8967 539.579 612.853]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.3) >>
 >> endobj
-699 0 obj <<
+703 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 591.7985 539.579 600.7547]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.4) >>
 >> endobj
-700 0 obj <<
+704 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 579.7002 539.579 588.6565]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.4.1) >>
 >> endobj
-701 0 obj <<
+705 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 567.6019 539.579 576.5582]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.4.2) >>
 >> endobj
-702 0 obj <<
+706 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 555.5037 539.579 564.46]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.4.3) >>
 >> endobj
-703 0 obj <<
+707 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 543.4055 539.579 552.5112]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.5) >>
 >> endobj
-704 0 obj <<
+708 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 531.3072 539.579 540.413]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.5.1) >>
 >> endobj
-705 0 obj <<
+709 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 519.209 539.579 528.3147]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.6) >>
 >> endobj
-706 0 obj <<
+710 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 496.7003 539.579 505.4125]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.2) >>
 >> endobj
-707 0 obj <<
+711 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 484.5772 539.579 493.5832]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.1) >>
 >> endobj
-708 0 obj <<
+712 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 472.4789 539.579 481.485]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.2) >>
 >> endobj
-709 0 obj <<
+713 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 460.3806 539.579 469.3867]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.3) >>
 >> endobj
-710 0 obj <<
+714 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 448.2824 539.579 457.2885]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.4) >>
 >> endobj
-711 0 obj <<
+715 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 436.1841 539.579 445.1902]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.5) >>
 >> endobj
-712 0 obj <<
+716 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 413.4314 539.579 422.288]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.3) >>
 >> endobj
-713 0 obj <<
+717 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 401.353 539.579 410.4588]
 /Subtype /Link
 /A << /S /GoTo /D (section.3.1) >>
 >> endobj
-714 0 obj <<
+718 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 389.2548 539.579 398.3605]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.1.1) >>
 >> endobj
-715 0 obj <<
+719 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 377.1565 539.579 386.2623]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.1.2) >>
 >> endobj
-716 0 obj <<
+720 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 365.1579 539.579 374.164]
 /Subtype /Link
 /A << /S /GoTo /D (section.3.2) >>
 >> endobj
-717 0 obj <<
+721 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 353.0597 539.579 362.0658]
 /Subtype /Link
 /A << /S /GoTo /D (section.3.3) >>
 >> endobj
-718 0 obj <<
+722 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 340.9614 539.579 349.9675]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.3.1) >>
 >> endobj
-719 0 obj <<
+723 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 328.7635 539.579 337.8693]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.3.3.1.1) >>
 >> endobj
-720 0 obj <<
+724 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 316.6653 539.579 325.771]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.3.3.1.2) >>
 >> endobj
-721 0 obj <<
+725 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 304.567 539.579 313.6728]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.3.2) >>
 >> endobj
-722 0 obj <<
+726 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 281.9139 539.579 290.7706]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.4) >>
 >> endobj
-723 0 obj <<
+727 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 269.8356 539.579 278.9413]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.1) >>
 >> endobj
-724 0 obj <<
+728 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 257.7373 539.579 266.8431]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.2) >>
 >> endobj
-725 0 obj <<
+729 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 245.6391 539.579 254.7448]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.2.1) >>
 >> endobj
-726 0 obj <<
+730 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 233.5408 539.579 242.4971]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.3) >>
 >> endobj
-727 0 obj <<
+731 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 221.4426 539.579 230.3988]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.4) >>
 >> endobj
-728 0 obj <<
+732 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 209.3443 539.579 218.3006]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.4.1) >>
 >> endobj
-729 0 obj <<
+733 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 197.2461 539.579 206.2023]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.5) >>
 >> endobj
-730 0 obj <<
+734 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 185.1478 539.579 194.1041]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.1) >>
 >> endobj
-731 0 obj <<
+735 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 173.0496 539.579 182.0058]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.4.5.1.1) >>
 >> endobj
-732 0 obj <<
+736 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 161.051 539.579 170.0571]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.4.5.1.2) >>
 >> endobj
-733 0 obj <<
+737 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 148.9527 539.579 157.9588]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.2) >>
 >> endobj
-734 0 obj <<
+738 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 136.8545 539.579 145.8606]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.3) >>
 >> endobj
-735 0 obj <<
+739 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 124.7562 539.579 133.7623]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.4) >>
 >> endobj
-736 0 obj <<
+740 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 112.658 539.579 121.6641]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.5) >>
 >> endobj
-737 0 obj <<
+741 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 100.4601 539.579 109.4163]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.6) >>
 >> endobj
-738 0 obj <<
+742 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 88.3618 539.579 97.3181]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.6) >>
 >> endobj
-739 0 obj <<
+743 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 76.2636 539.579 85.2199]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.7) >>
 >> endobj
-740 0 obj <<
+744 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 64.1653 539.579 73.1216]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.8) >>
 >> endobj
-689 0 obj <<
-/D [687 0 R /XYZ 85.0394 794.5015 null]
+693 0 obj <<
+/D [691 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-690 0 obj <<
-/D [687 0 R /XYZ 85.0394 711.9273 null]
+694 0 obj <<
+/D [691 0 R /XYZ 85.0394 711.9273 null]
 >> endobj
-686 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R >>
+690 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-743 0 obj <<
-/Length 3152      
-/Filter /FlateDecode
->>
-stream
-xÚí[wÛ6Çßý)ôh?‹ûå1מvw“4q_¶ÛVfJ¢W’›f?ý‚"-pdìÖÙØR{Z;1‡3žÿO’lBý¿l¢4ÑŽ»‰q’(ÊÔd¶<£“kÿ³ïÎXÌ44…G=¿<ûËka&Ž8ÍõäòãD*E¸ÚÌj-›\^ý|þâí›ËWo.?\ürùÃÙ«ËxVè™QÑžò_g?ÿB'W>€Î(ΪÉgÿJ˜s|²<“J%…³8ûpöcÖëz5«Ç3N~ïñ`ã-Z°ñŒÓa™ÚóšýL1KŒéWuo³©y=s‹W‹zY¯¶~¢˜9Ö~e”ÒâO0Ä>YP2Œ“L/¨÷0i¥š©UÀe¼Qù{µ}
-EyÓ¢¢
?õ´wP	é,Fb¨@¹G%†
-êqM¤`r¢<4†I›`Ùá"Úõ/«mõÇÅT8uZZ½(1•¥ @C”T(¹8Ppï	ˉ¶‚PxÊ˺­C«yªBÕê*ô½Õu»:ÿ-Ìô¿Æ*{ÌR1Àcª Ä8™80Pï}]Q†­<
-WÙ—íL£_EíG
eÍiÔ@Q	é,Fb¨@¹0T2q`¨ ÞÓp¡,Ñ̙˩®ü· „Tƒ1P T(™80PPï	©‰²©¹ñ œêÊ>!KÅCŒ¨Æ@&ŒÔ{èo•hŒ……߯¿ýn]-—U»zdÄ©½½ƒKÈh1.ÀÃ*&ä8.™80\PïaÂ9Q\†ÊÒÖïþ΂`ÄZ*½ƒö¨j¶èAŠpÆṁmµ­Ó4&Òe¸=õÀ1çÅ<CŒ'¨©Pã?÷˜B+þpå$䲘`ˆqµÂ8ÉÄq‚zœÙnÀŽ˜¨ƒ˜ÌW³ÅíU£DãØ¡ÉŽeü¨æÉ!ÃÅð$;Œ Ÿß›	#sÀѾ&iæ4ú¡È9<¾|íëùòf˜ÊbD€!Æ”
-ƒ$F	ê=`¢(tRæ &¿Õ_rS__‚œ!ìiÕ7漘'`ˆñ5ÅxÊÄñ„z<	KM£Ž}œ8Š>½N*¤¶˜šd‡A„ãÛò3A`È`®1ÜsbXBÆDfÑ\_·;É2…Êø!Ï©Cë9JÕnØâbt€!Æ”ƒ'Fê=àä?Üé´HŠŸ{Ltþ?»¬þ´†;䲘`ˆqµÂ8ÉÄq‚zW™$å„Sã)íõHÛo[Þ‡FSßUË0ë}ªV«:·êç9©”î{÷i]m<ZðãšÕ„ôÃ1x |büæ€\<¨÷pÚ©öðøäºYçf:’mÍx$µGU¡bzKá†<ù$…'PÂX¤êðÕªÅçu[èã¾>EXƦ7\é#¾îÓ]Œ0ÄP‚rÊñm½¹80”Pï%­==”0þ (žéHæžÐèÒZŒ0IJaÈdâÀA½d”$Ô2ž9|¥jYm¶íýñùù±tú`¥«z…ó1~ †r|×o.ŒÔ{àGrB¥S‰ùPüܧ¿r¹¿Š¹,æbœ@­0N2q`œ Þ'¢ðÂîêð¥ªæ¦•z“¿à`ýÙ^ªbÇ5µ	9.æbü@
1~2q`ü Þ?Ìg5¨Sú¡ø¹Ï+ù¨ëQÈe1'Àãj%Ç·þåâÀ8A½§Vœ*â”I‡uœçM³¨«^Ô·=S%Ü_mŠé*†b0@9äøÕ¦\¨÷w‚8Î-„¡_—yݬ?WÝVv·KÊO·ÙˆÙ+e"lÔQãO.„
Ü{bÃújá`ë£Û§‚µl¼¼­ÓͶšývç‰`âÛ»eék1UÅ C(B&Ô{A;b•TÙðl6‹·B¿h7صãE³h‹Æé¾ç”¸b,€!†Ã"†ê=a¡±Üj‡ê°ø~åØ•gãbª);ݾ˜Ç#$°`ˆáRãýH.Ô{ÂC*bœfÝáñãmÝ>¼h÷@7ø@ảŠ˜·b*€!FÔEߧ–‹£õž¨‚=ì>LGE÷ÚŠËGÏ×Õjóq7©P†°ˆ‰+ÆbX@aÔxSš‹Ãõž°àŒ1ìCl‡ÅO/ßuT¼‹Oퟴ¢äi¸H™+æb\@eÔxš‹ãõž¸ ŽÊEÄu\¼½<õü×Ͷ^¦Ç¢ÝîÊÊ,>Oo9o‘±R=®5˘€by!&/L°ßS”‹“õåeέ¬EQ?ˆ=å!A
ÓO¼‰ˆ9*%"4@ÈÅ€{OXE´Ÿ÷
`ïêõ¼¹šÏ⤀ŸW›~Åa×aü^-ÚÏô·°>ù°„$#1 j|oX.Ô{BÀ¢é°Q`¼C`'zsÓ,škß0aN8ÉrXL0Äa„dâÀA½'B4#ÊÈa™=!÷Ø>¸ñ3Ç…Ÿ3æ®tIB9sûWº„UÇq›pLn1:ÀCŠ§ÆŸš‹CõžÐ‘Ž(ɇõEv輿©ûŽâmw¡£/¹8Ýf•2WÌ0ĸ(3¾§4Æê=q!Qþ‚©Xsèùmÿ¬e}´Æ)ƒ¥Og1+ÉCŠ5¾Ì	s8áŠHs§CÑ(Ïoç‹í4¼ædú•ùêãîµq‡Ä¿›U»nŒ{”;gbŠõ†˜Àƒ,¯TçâÀ$F½'™ RÞéALNãWË›í—ôάöêÆ7´õ°=HHR1ÀC` Âø²t.Ô{B€2"™`Ó³[aò“C?‰œÏ6ð9jÎòc¼´VLC²Ã`€rŒ¯Eg‚ÀPÀ\G¬#ÂJ1 Áu$<»ºÚmz«a×Ã,ð/ªÙ§Ý”ÁiýtdÙ(•Ø!2r=þ`˜LˆÌ¨ëð"*C„âàã~ø±
}yÏtÔ3¢Þ3ÍÍSž3Ž¾ÙªOtñ‹­’ö^+(ã8?™ °·Za®Ãû4öð¹Ï3ïžÂDŸÏòw´3ô
-I+¼Ÿån{ˆÄwúN¹óÒf_LâÿcÄ)Åÿ÷W§7ËöV3;²K‹[J\ûv.á红¿C¹Åewˆü?m2L-endstream
+747 0 obj <<
+/Length 3171      
+/Filter /FlateDecode
+>>
+stream
+xÚí[wÛ¸Çßý)ôh?Åýò˜ûɶM²±÷¥Û}`dFÖ‰$z%9©ûéŠ8´À‘ÑÆili÷ìÚ‰9œñüf@d#êÿe#¥‰vÜŒ“DQ¦F“Å	MýÏÞœ°ö˜q8hz~qò—×ÂŒqšëÑÅç‘TŠpµ=™%ÔZ6º¸üýôÅûw¯Þ]œŸýqñËÉ«‹xVè™QQŸòÏ“ßÿ £KÀ/'”gÕè›ÿ%Ì9>ZœH%ˆ’B„¿™ŸœŸüO~º5Mþ&Œ.4Oü*\€_¥þ¡b#£ÑÂÿ¤þE$±„§ôôM¹,WÅf¶œž¹¢§-o×gc«ù)9+Àãû"ûn'»+5õY7BwùÜÑf55ß|„j»14ÜUk÷üµ^\ïÄÔOű‚z¬HC4¥:²Â[VÎgÓeesU6ßü£ZúïÕGbPbBV³‰†1P5Œ˜D1¨÷@ŒPDië"1¢%æEµü'¥|z³ŠÜœ—«¯åªc˜8TT	yÌfbŒ@¸f$ÆêÝ0?äh?=r?«	Ã[HœG„zÞ~øª[2n®¯«Õ¦ùÃlÙ|}þöÝËæ;oà8{¼ƒÌ(ä8 `ˆ5äv D@¨÷0È0æë¦%K˜g——«3fOËõº!åoUõåæºýÃoë8ô<óÿ4ß},'ÕÖær[ì˜Ç@À æ!/ÙšCLs˜wLóD˜æ¨÷Vsí‘F¸¨9Ò|S5_ß‹§àÝìÓ§y{Ìëjµ(¶#ŽûÙeŽ©È•"2÷RÈœŠ‘y×;ƒÞÛÖIC˜ŸF¶ÎU=3ø\\„
+³7l¥M¯6ßÊúÿáó¼®æ¾¬Î^pàø_Ö€A"îón³æ†³N‡ekÇkj&ÕZ&™m²µë™4æk8=í?­ŠÕ­ŸN¥|ÊSæ !}ÙŸ$`ˆ}’ <‰806Pï‘
%c”·lð–7Ë®u+RT¼,ÊEå‹.gÔÁUUƒ¤„df“1R X)‰80Rv¼'Ç\A‰¥®ÁT·cîÎPÛupÅfV-9ŸËU¹œ”Ù'¿÷x°ñ-ØpÆÀé°LíxM~¦˜%Æ´«€:Ž·ÉÔ¼ž…ÚâÕ¼\”Ë/@3‡Ú¯òRšýɆØ'J†q’ˆãõŠVª‰‘Z\†•¿›ÉU˜”×5*ÚðcO{•ÎlT€!†
+”KðaTq`¨ Þ×D
+&GÊCc˜´,[\D½r»Üÿ:§ŽK«÷%¦2hˆ€Ò“
+%
+î½År¢­`Þ‚ò²¬ç¡å¬›…Šåeè{‹i½:ÿ3Tú?b•=f)›`ˆ1Ub˜D¨÷v^Q†­<
+WÙu¥Ñ®¢¶£†²æ8j ¨„tf£1T \*‰80TPïÝp¡,ÑÌ™–ã¼òß‚R™
+0Ä@Ra $âÀ@A½w HM”íšÊq^Ùe d)›`ˆ1UÀHÄ1€zý­õ£ÃÄÂï×ß¾Y‹EQ¯qloïà2š0ÄpŠ	9ŒK"Ô{(C8'ŠË0³ÔóŠwgÁF0b-•ÞA}T1™·Çô† E8ã¶=æ|SlÊ®Œ‰tn=pÌy6OÀã	j*Ô0O‰80žPï'¸t"âħýS™uìé
Cmj³©éì0h€p3»A`È`®[b¤³DêØq"ö"3©–›U5_'¸ŽP&øžaHY÷$‡¡!tbŽsÙ†<=
zRq øàÞ?Ö×¾Üu3˜|0~îQB+þpä$ä2›`ˆqµÂ8IÄq‚zœYoÀŽ˜¨½˜Ì–“ùÍe™¢DãؾbÇ2~PurÈp6<ÆÐOïˆM‘ƒ¹àh?'iÝÕ4ú¡ÈÙ?¾üèëùßy³FLe6"ÀcJ…A’ˆ£õ0Q”:)³“/åmªôõS³bÏà"„=®úÆœgó1ž ¦O‰80žPï'a‰ Ý¨c§ý#Ž¢O¯“
+©Í¦¦³Ã ‰ámù‰ 0d0×î91¬CÆíEf^M§õN²ÄDeüçÔ¾õ%j·aLq6:ÀcJˆÁ“ˆ£õðaÒît·HŠŸ{:ÿŸ]Vß­á¹Ìæbœ@­0Nq`œ ÞãU&I9áÔ8@J}=Ò¶Û–w¡ÑÔwÕ2T½“«b¹,S«~~“Jéö¸W«bíYЂVUÒ›
0Äàò‰á›Rq`ð Þ#<ÂyXh§êdÀã’iµJU:’mÍx$µ5CÅôæÂ
xzòI:O*Ü{±„I	ç¨úöÔûÂóçM¹º—«UµJ-þ)Kœ´añïE ÍKÄ-5ƒœ„Lfs1N RrxÏn*ŒÔ{[Éø^0ÆÁü´ÿªæüÛªL1Á}•¡2˜+}À×Çcº³Q†JPN9¼U3†ê= ¤$¡–ñ%þ (í¯ˆ%sOh–
+iÍFbÈ@ÙäðœT2¨÷€Œä„J§:dö_Ñ\ëM™œ“ê>J:½·ׇUå„gó1~ †?‰80~PïQ×,°»’ÅÏ}úp÷˜ûð˜ËlN€!Æ	Ô
+ã$Æ	ê=pÂqVƒ©iÿ%Í꺖z¾0e½Ë½—4Ùa•6!ÇÙüCŒ¨!ÆO"ŒÔ{à‡*â”ó”~(~îsaS>êù(ä2›`ˆqµ’âRq`œ Þc×Í ŽsH	ë}Ï«j^­¨ï[:ÆJ¸¾*Ó•4D`èÉ!‡×ïRq 0àÞ;¬ìˆtX¿{]­¾Í“x¶'”o?¹ÃFÈ^6Àcª£†{åT¨÷Ž
íˆU°õÑayîåM1¯7ÅäË'ljŸïÖ¶2H„Teƒ1 ‰80PïÊËMoÆ
Ï&“xËü‹z#f=^TózÒ8Þß%.`ˆa…QÃg*Ô{‡…TÄ8Í ªÁâíÒ7°ŸÏÆÙXSv¼Í5GH`6ÀÃ
+¤†oEJÅázïð‚ÝëHˆnðøµ¾rÓ>ø>xCs¤"æ-›
+`ˆQuÁ¨HÄQzï¨àŒÑï>LCEó´âŠ‹3GOWÅrýy[T(ÃŽXÄÄec1, 0j¸)MÅazï° ŽÊzs‰m°øí准Šñ	´íy”<]æ²¹†P…ô§‰80.Pï‘æÑÚIÈ…k¸xÝ{:þùízS.ºÇçÝl§•I|îâbV#c¥z\k–1¹òBCDÞ^‚ySq òâÞ;y­"ÚÏú½µ(êØSîÔ0ýÄ›ˆ˜£l€!FÔ@
?é0Fê½#À¢i¿‰`¬!àC¹šU—³I,
+øi±nW¶Æ×b^¦†õɇE $)`ˆ!EÀHÄ!€zïÐŒ(#{c<ã
[Ñ«ëj^M}Ã`„9>'MHÈa6!À#¤§ÑðFÁT!¨÷Ž鈒¼?Mˆ–{ì\ûÊqîkÆÔ•.I(gn÷J—°ê0n'ÉÍFbèôÄÞ;˜ŠCõÞ¡#Qý¾‚Ɇœ×eÛP¼o®s”á](Ç»ñbⲩèì0( ,ÃëÙ‰ 0$0×\iú-Sqº¡§7íã¸õÁ>;)”ÏlR€!†JO/„•D,¨÷Ž&ˆ”w:ÝÐòüf6ߌÃëpÖ _™-?o__wHü»ZÖkáƸG¹s&f![c`ˆiÜËòðšd*LcÔ{§1eD2ݓؤ$~µ¸ÞÜv¯V«/nüDKPÛ‚´9Ê ³Ãô‡
+ ò啕Žâ[G„•¢'¾íJËfmÉ—…¾|œMÖðI{ÎòC¼¨–K°CHèÉ1¼
+!uI0†ÅûÀkHxvy¹ÝîVÌÃ~‡I7¶¿(&WÛŠÁiýtdÙÈ~uUg‡½¹
+æy#ânØ{«0×á
ŠÚýÏõhçõDëH="zïMõÜ<åŠqøý,Û<ç¿%˜¡ïfé44È›YîF°ƒN|›ï˜;/yò•$þ?FœRüyp÷ŽcYß> endobj
-748 0 obj <<
+752 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 758.4766 511.2325 767.4329]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.8.1) >>
 >> endobj
-749 0 obj <<
+753 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 746.445 511.2325 755.4012]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.8.2) >>
 >> endobj
-750 0 obj <<
+754 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 734.5129 511.2325 743.3696]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.8.3) >>
 >> endobj
-751 0 obj <<
+755 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 722.3816 511.2325 731.3379]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.9) >>
 >> endobj
-752 0 obj <<
+756 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 710.3499 511.2325 719.3062]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.1) >>
 >> endobj
-753 0 obj <<
+757 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 698.3182 511.2325 707.2745]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.2) >>
 >> endobj
-754 0 obj <<
+758 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 675.998 511.2325 684.7301]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.5) >>
 >> endobj
-755 0 obj <<
+759 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 663.9862 511.2325 672.9425]
 /Subtype /Link
 /A << /S /GoTo /D (section.5.1) >>
 >> endobj
-756 0 obj <<
+760 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 651.9545 511.2325 660.9108]
 /Subtype /Link
 /A << /S /GoTo /D (section.5.2) >>
 >> endobj
-757 0 obj <<
+761 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 629.6343 511.2325 638.4909]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.6) >>
 >> endobj
-758 0 obj <<
+762 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 617.6225 511.2325 626.7282]
 /Subtype /Link
 /A << /S /GoTo /D (section.6.1) >>
 >> endobj
-759 0 obj <<
+763 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 605.5908 511.2325 614.5471]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.1.1) >>
 >> endobj
-760 0 obj <<
+764 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 593.5591 511.2325 602.5154]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.1.1) >>
 >> endobj
-761 0 obj <<
+765 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 581.5275 511.2325 590.4837]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.1.2) >>
 >> endobj
-762 0 obj <<
+766 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 569.4958 511.2325 578.4521]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.1.2) >>
 >> endobj
-763 0 obj <<
+767 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 557.4641 511.2325 566.4204]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.2.1) >>
 >> endobj
-764 0 obj <<
+768 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 545.4324 511.2325 554.3887]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.2.2) >>
 >> endobj
-765 0 obj <<
+769 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 533.4007 511.2325 542.5065]
 /Subtype /Link
 /A << /S /GoTo /D (section.6.2) >>
 >> endobj
-766 0 obj <<
+770 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 521.3691 511.2325 530.3254]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.1) >>
 >> endobj
-767 0 obj <<
+771 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 509.3374 511.2325 518.2937]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.2) >>
 >> endobj
-768 0 obj <<
+772 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 497.3057 511.2325 506.262]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.3) >>
 >> endobj
-769 0 obj <<
+773 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 485.274 511.2325 494.2303]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.4) >>
 >> endobj
-770 0 obj <<
+774 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 473.2424 511.2325 482.1986]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.5) >>
 >> endobj
-771 0 obj <<
+775 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 461.2107 511.2325 470.167]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.6) >>
 >> endobj
-772 0 obj <<
+776 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 449.179 511.2325 458.1353]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.7) >>
 >> endobj
-773 0 obj <<
+777 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 437.1473 511.2325 446.1036]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.8) >>
 >> endobj
-774 0 obj <<
+778 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 425.1157 511.2325 434.0719]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.9) >>
 >> endobj
-775 0 obj <<
+779 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 413.084 511.2325 422.0403]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.10) >>
 >> endobj
-776 0 obj <<
+780 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 401.0523 511.2325 410.0086]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.10.1) >>
 >> endobj
-777 0 obj <<
+781 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 389.0206 511.2325 398.1264]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.10.2) >>
 >> endobj
-778 0 obj <<
+782 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 377.0886 511.2325 386.0947]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.11) >>
+/A << /S /GoTo /D (subsubsection.6.2.10.3) >>
 >> endobj
-779 0 obj <<
+783 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 365.0569 511.2325 374.063]
 /Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.11) >>
+>> endobj
+784 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 352.9256 511.2325 362.0313]
+/Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.12) >>
 >> endobj
-780 0 obj <<
+785 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 353.0252 511.2325 362.0313]
+/Rect [499.2773 340.8939 511.2325 349.9997]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.13) >>
 >> endobj
-781 0 obj <<
+786 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 340.9936 511.2325 349.9997]
+/Rect [499.2773 328.8622 511.2325 337.968]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.14) >>
 >> endobj
-782 0 obj <<
+787 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 328.9619 511.2325 337.968]
+/Rect [499.2773 316.8305 511.2325 325.9363]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.15) >>
 >> endobj
-783 0 obj <<
+788 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 316.9302 511.2325 325.9363]
+/Rect [499.2773 304.7989 511.2325 313.9046]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.16) >>
 >> endobj
-784 0 obj <<
+789 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 304.7989 511.2325 313.9046]
+/Rect [499.2773 292.7672 511.2325 301.873]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.1) >>
 >> endobj
-785 0 obj <<
+790 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 292.7672 511.2325 301.873]
+/Rect [499.2773 280.7355 511.2325 289.6918]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.2) >>
 >> endobj
-786 0 obj <<
+791 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 280.7355 511.2325 289.8413]
+/Rect [499.2773 268.7038 511.2325 277.6601]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.3) >>
 >> endobj
-787 0 obj <<
+792 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 268.7038 511.2325 277.8096]
+/Rect [499.2773 256.6722 511.2325 265.6285]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.4) >>
 >> endobj
-788 0 obj <<
+793 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 256.6722 511.2325 265.6285]
+/Rect [499.2773 244.6405 511.2325 253.7462]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.5) >>
 >> endobj
-789 0 obj <<
+794 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 244.6405 511.2325 253.5968]
+/Rect [499.2773 232.6088 511.2325 241.7146]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.6) >>
 >> endobj
-790 0 obj <<
+795 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 232.6088 511.2325 241.7146]
+/Rect [499.2773 220.5771 511.2325 229.5334]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.7) >>
 >> endobj
-791 0 obj <<
+796 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 220.5771 511.2325 229.5334]
+/Rect [499.2773 208.5455 511.2325 217.5017]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.8) >>
 >> endobj
-792 0 obj <<
+797 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 208.5455 511.2325 217.5017]
+/Rect [499.2773 196.5138 511.2325 205.4701]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.9) >>
 >> endobj
-793 0 obj <<
+798 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 196.5138 511.2325 205.4701]
+/Rect [499.2773 184.4821 511.2325 193.4384]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.10) >>
 >> endobj
-794 0 obj <<
+799 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 184.4821 511.2325 193.4384]
+/Rect [499.2773 172.4504 511.2325 181.4067]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.11) >>
 >> endobj
-795 0 obj <<
+800 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 172.4504 511.2325 181.4067]
+/Rect [499.2773 160.4187 511.2325 169.375]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.12) >>
 >> endobj
-796 0 obj <<
+801 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 160.4187 511.2325 169.375]
+/Rect [499.2773 148.3871 511.2325 157.4928]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.13) >>
 >> endobj
-797 0 obj <<
+802 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 148.3871 511.2325 157.3433]
+/Rect [499.2773 136.3554 511.2325 145.3117]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.14) >>
 >> endobj
-798 0 obj <<
+803 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 136.3554 511.2325 145.4611]
+/Rect [499.2773 124.3237 511.2325 133.28]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.15) >>
 >> endobj
-799 0 obj <<
+804 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 124.3237 511.2325 133.28]
+/Rect [499.2773 112.292 511.2325 121.3978]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.16) >>
 >> endobj
-800 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 112.292 511.2325 121.2483]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.17) >>
->> endobj
-801 0 obj <<
+805 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 100.2604 511.2325 109.3661]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.18) >>
+/A << /S /GoTo /D (subsubsection.6.2.16.17) >>
 >> endobj
-802 0 obj <<
+806 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 88.2287 511.2325 97.185]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.19) >>
+/A << /S /GoTo /D (subsubsection.6.2.16.18) >>
 >> endobj
-803 0 obj <<
+807 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 76.197 511.2325 85.1533]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.17) >>
+/A << /S /GoTo /D (subsubsection.6.2.16.19) >>
 >> endobj
-804 0 obj <<
+808 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 64.1653 511.2325 73.1216]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.18) >>
+/A << /S /GoTo /D (subsection.6.2.17) >>
 >> endobj
-744 0 obj <<
-/D [742 0 R /XYZ 56.6929 794.5015 null]
+748 0 obj <<
+/D [746 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-741 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R >>
+745 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-807 0 obj <<
-/Length 3350      
+811 0 obj <<
+/Length 3405      
 /Filter /FlateDecode
 >>
 stream
-xÚíKs7€ïú<¤j¥ƒ°x€ÝÖ^v”rd¯$W¶6É&ÇËâPáÃŽ÷×/†`š"¦%8~ÈJ‘’¦§›Ýß4ºÌõ¨ûõŒ"TXÙÓVE™ê
&;´7r{¾Ãü1ûá }xÔáåÎߟ	ݳļè]¾ç2„Ãz—Ã_w^ž]žœ]^ìý~ùÓÎÉe<)T̨¨ÏøÇί¿ÓÞÐéÿi‡aê}p?P¬å½ÉŽT‚()DøÍõÎÅοã	Á_W¢©¢„!Êpø$\€OÂ8'Æjg²¤îoõG)wŠëâgàpÁˆ1T:õa‹Ùr¾(‡ûïÊs0<·2ÄrSøƒ/ýE9)«ÅÞ>Wt÷ù¬?™ôg{ûFÒ]²·¯èx‘Ö~ŠÜ­€+nHÁ)k}º¡Ù¨×¼9‡1rûPp3f›ç_ÅLoØHÙƒjo‰‘šZ³H§_”˜ãò7Jy5^Œ§Uó›~5lÞ¼ž÷GeýVyyS5:|›FbÜ‚ç²¹‚02Zts‘°ãÕÞr¡8¡BÈ…l¸8þXõ'㯠n†®ØhÞ¿š^ãzÔ‘J=Ú°Çd‡ba‡Ž×ª;ì	;°°£Ú]ía½BRB

ýKŒ®e‚gãk÷N)ûÝ º„
aÈfbŒÁ0뢛±„c¨ö¶ïqf0®Bß#êú•qºV¶Ö¬Mß6¯çå|ºœí1³;(ÃoÓÕ/†ó[
Í/W¥ïqÓÐâ„¢øªœ¸VG‹‡7m=’o ˆÅz‹wÂ,Þ¨öv(aašŠ6Þ«ˆ‹»Ck{’•EpX6@ÃÃ!a†ª½Åº†„)pà—ønùçbÙ¿nh(ÿ¼YÁPÎçqò"¦…óU/S<ÚA ø)› ˆQã »'¿Rv` Úã  ¬+)•µ‘îãñ|°L„ûçÿ$„ü¦áÿÖsíч¹„@A„µ!„¤ì@Áµ·„J•&"6?M]~–³~³îßé·pjgÀýü6-Þ<ïÊ_Ýk ðt˜Ÿ6´¦Ö>eÁ‰–Ê/Š­jüzíó`0(çóè–Å*¯Mýõb<_¬þ&·kžùW]pxöU±«£(aFª=Ò¤(Ñ–ú%7’Ú[îÒ·e’ùóèj6.«„J«W:cµ%Â
aÿg¹XŽ‡©SâP5þ°'¾‚ÿ)Ć f1b!4¦{a.eF,ª½-#œ€JdÛuùd}¨˜ãÒæø2Â5uáIõ¾©§U³AYâé$ÄN®‚ç³¹‚W0²W	;0®Pí-WuOj(‹\…¥¾×ó8óžnA\b,©oÞ™ÖÞ46ÆÏ–Õ Ùê.õSl;¡
-nφ
-bPÁ°bP%ìÀ BµÇá•Ib¹ôK“q£ZçÖĶ¼Õªx⋃ÀŸf1``Ì0`v`ÀlhOuAÂÖóþÎUã» Ë=ÆØîlº|s]ίÜøUç£.÷Ä3Ü·ÙH³³nY÷*;<âŽM­©ëG7z+?E{£édö]¼j†iç™I=M 嶵ɾ¢‚—s/( ‡\Ok1D¸Ù4ÃS‡tQXB­¿Óø
}«µõÅß|¯\Mýíg¦³wîºúgóÓÕôCófЋíÍK}Ú¨ÙèsötÎpÕ§ýà«ÇÑ¿\*gæ·Ñ'ÙÑ‚X¸×|ŽÄ;apT{ÌJ׫ú^zUÁÕ	ã´4«‹ùXÌÅݸGWýj´VãùÁx6S’gËÉ›z†Ú™ñ
-ùè¦l€ ÆÀZv` Ú#Rfü&Ö\¿Ô;%Ú«öèÖuý¼ôWñåõ»h¥ÜŽ÷B)x;% ˆ¡´M¥„JÚ“Õ„~BüÀerÎwnnÊj8”ÝóÍQìÞ%ÀJ0hŽí^¾§Ã|°¡5y91FªñA=‚jí¼0xWM?\—ÃQRë=ðÜn+¯ü«'87ûê‚ØÕƒ‡“°#ÕË/nëù^#:5<¶¾„šL{8—~×ôãùb:û¸¾•:ÄÇg·Fìf]¨ ìñ •‹DPX‚BÊ\{H"Üh"©`žÞ$‘çeUÎB…ƒ|^¾õ#uî¶9­Þ®‚WÓe…}ZëOÑwÙ`A۽꛲ÕÞæ­ˆô{¯šÉü:Eœ¾z_øk~8÷Ö„;î~sõÜûç^Ýá…ÐÛ­ÁÙŒ´r" H!›F`€`ªcâ(‘–>D“8Ço®ÇÓѬsõ±E"ŽËѨ¬Ÿ·J躻†ÁùIÁsÙHAŒ	Š„¨ö6m(F”ÐEà"äóò¥}x7h„
_¦VΟÍ ŒàO£ÖŒ.Ëb@À`@$ìÀ€@µ·@[¨÷Iµ(gUhîgý·5Öòmcrf‚W³™‚30j¶{­%eÆª½e†ëú‰ˆ"2#fÀ]5ÇÓÁ¤Žƒ7q¶·iA{*Ù#ø*› ˆ‘c‘°#aC{jž‡SE4µ
†‡õ˜ vîWñþî›þ™î‰Ò÷îÈtÏšU¶û’ðt˜+6´¦
-.fÑJ6q8\
«ÂîÇ£G•4¿Ÿ›_c àãl‚€ FŒ!cÝI‚„ªqN(¡áÓ€ ×[µ-»¿BÙbMă1f)»†`„¡ê#aŒZ˜Ð噆°Y58ï2³mï¾:n! Ù¸A7pƺoiL‚ᆪ¸YCéÌ™›°74Ö’U•xX«¿mEooDüú0å"ØŠ!ë®é7M@àÃôLA\áúB7’ïKŸéökÂV‚‰mVû¬$¯ç¢ä–`Lë.ïVlпÁr¿¾Õ•ËäÜÿŒXÕÜÜð×¾1³ý^Ïú!^ÆtÜ/!¨%‚SÙŠH_%(dÓöê `ùÿ2'{endstream
+xÚíKsÛF€ïú<¤j¥ƒfçýØ=léeG©DöJJek“h¦XA…9Þ_¿3hŠƒ–ÆŽ-[¢S)RÝìþÐÓ™YúÿXÏ*B…“=ã$Q”©Þ`²C{#ÿ·—;¬9f?´:¼ÜùûazŽ8Íuïò-8—%ÔZÖ»þº{ôêìòäìòbï÷ËvN.ãI¡bFEuÆ?v~ýö†^ÿ;”gUï½ÿæïMv¤DI!Âo®w.vþOþºM}%,Q–›Ä'á|Æ9±Îxë”#Zø¿UEN˜­>ˆ?œÃ#ÖRéuT‡Í‹Ùm1kƒgÞn­usØÅ¢¿(&E¹ØÛçŠî¿QÊËñb<-ëßôËaýæçyTìí[GwÉÞ¾¢ò"˸nÅ-Ñœ²Ö£ñ™zõ›s± ·7#¶yþUÄ̆€”/¨ö–iˆ6†µ¼¸{yYÌ–óE1ÜW|˜'¨Q–8n;¨y9ëO&ý™‡C>&Ÿ†Ê}ÄŸf1bÖb溉I؃jo‰ŠÎ\$†ÓÏJÌýy†+ñ¥”àÂl@€ ÈZˆ@v`€ Ú[@¸ FkÛÂîäv\¼O€Á¥ÿ@FÝ“J”_M*ù+óËa
+îΆ	b0­…)aª½…‰yNÓ-Lü³Àt–ÑN{ìtBÜš

Ä YMÂT{„F;G¬Ò²…FÜÍÿ¦e‘††gîË@Ö>åÔsLÑݹ0AA¦µpÚ	SÊ&\{“5ÄQÖvT\~˜îÏ@F±§3lE·fC1h`ØŒè†&a
ª)IŒ1®§"Nj !Ì7=>˜ÿ­ØX…õrÏ7ÈnŠ¹÷•üÊK˜GÈ*Á…Ù€A"„ ¨ö-ˆsÔA@x
ÈÑuî‘”KH|vNîÃ%84 ˆáfd7.	;0\Pí-.Š*”…¸ˆ»ùäÕM5vTèðm‰qžËæb\ÀÈ`\$ìÀ¸@µ·\HJ¨¥r!k.Ž?”ýÉxÐT7C_lÔï_O¯Çƒq5êH¥žl؃c²Ã±°CǛ);°°£Ú}Áê¬=í­`\…þÆ'F×2Á‹ñµ§”ûæG¯º„
aÈfbŒÁ0ÛÍXÂŒ1T{Û÷0M˜¡¡ïUýÊ8]+[+Ö¦oë×ób>]Îö˜Ýá7ƒéêÃù†æ—«¢éqÓÐâ„¢øª˜øVLj¯ï¶môHv¼ oèq,Þ	;°x£ÚÛ¡„ú
+”)ÖÆ{qqh­`ϲ²ËÆb8À€`8$ìÀp@µG”óÅ„ràÀ|à»ÅŸ‹eÿº¦¡øófC1ŸÇ›1-œ¯zýTè§\
+  BÁZl÷ͯ”¸ö8(K‰ ÒF
+x3çƒe"Ü?ý'‘ 䣆ÿ±ïµGf1B`Œ,ë&$aFª½%D["¤Ó‘ÑrQ,ãrÔŒê—?®8Ûú2ŸŸàál~€ ÆŒ ÆOÂŒT{ËòÐ8{™ª}]ñsZÞ³PþÔ¿¹‰0›œsúúÖ̭ض"Ñ‹ÙŒAŒ%Ë»IØ1‚jo‘’HáxdD5Œ¼Z\³†»ÍïjJe\—%ƒÅø¶jW„dÏy
+^ÌfbŒÀ(aŒ$ìÀAµ·õªàDZÙ¶/*¶/¾¥LÌØiJ(“a2î»Wç§/OÏ“vÒáIlŽ[Cjoß)öTW±E‡fã1\`À0\v`¸ Ú[\8%Þpá9¸œžýøóñIj1›"T‹.^¸xzy%¸2 ˆCe»'êRv`  Ú[P¨0ÂPD(¾òM­ÐÄJ׉yœÛòW¼g1€`1€v`¡ÚcñâK`¢™m$Ý/‡§gÇ¡º/BÓV/'.Š²ê°ÿá+FwIܘÑT–µ}÷òäìäü ºCs™ÊNZJ…Lƒ§¿PŸÞBtU.Pa-);pí-V­EÛ阄ƒápµê'ÜNkx1Mú_¹j£·MNt`6@ÃÈvOå¦ìÀðØÐÎ{¤æÄHÕL(V3zk)ÂÕ/Å`9/>Ô?M}~³~=ïßé·pjoÀÃü6-Þ<ïÊ_ªÛ_àt˜Ÿ6´¦æ>¥¢Ä8ÚLŠ­jüjîó`0(æóè–Å*¯M›êÇñ|±ú›ÜÎyæ_uÁáÙWÄ®:PŒ¢„M¨öH“?Þ
+ÕL¹‘ÔÚrŸ¾“¬1®fÓé"µWN*y8¬šéLŒÕŽ_1„õŸÅb9¦Ne‰GÕ6‡=óü!65›X ˆ¡±º›Ø„±¨ö¶Œ¨zKY@¶—OÖ‡Šy.m`nЉ/#ÜðPž”·ue8-ëÊB‹ç“;¹
+žÏæ
+b\ÁÈb\%ìÀ¸Bµ·\1I—.r¦ú~žÇ;ïéÄw Ö1ww¥5ŸilŒ_,ËA½Ô]šç0ØvBÜž
Ä ‚aÅ JØA…jÃ+õƒ§vÍâȸP­sib[Þ¥Ÿùä`'0Á§ÙÀA3˜„0ÚS]°~¸RÍBÓ]î1ÆvgÓå›ëb~凯*uy'œà¡­8étÖÌêÞÍN†xbCeêÊÚêš]—6¶9GÓÉ$,¹x]ÐÞ+“ê”Û®&ûbŠnν˜  r1­‡!'a†ª=é¾Ù ¾uÑ¢X*ž.þÖôÊå´Ù~ö~:{ç/¬Ö?]Mß×oý0Ù^¿T{ÔFõZÀ&gO—áWýxÚ÷Mõ8ú—OåÌ~EãmôIvÄ ñ5Ÿ#OØEÕ³†T„Ùf§¤]UpUÖ8-uĪb>sq5îÑU¿­ÕxÍ`<‡[’gËÉ›êµï	òÑMÙAŒµ0 $ìÀ@µG„ \4m¬¹~©VJ´WíÑëúeÑ\Åß×7þ¢•r;€<¥àíl”€ †ÒZ4”v`(mhOVcŒZ)?ð™œó݃››¢ŽE÷ýæ(öà"`U4Çu/Tƒ§Ã|°¡5u9qWÝ´³uªÔï…Á»rúþºŽª”Z­çn[~e_=ѹ¹WD®žµà!Ĥì@ÈÁµÇò‹[C$, SÁãªK¨Î´‡³qѬšþ~<_LgÖ—RÇøøìâΈ]ÏiÊž
+ÁYÙ(A…„
+¨ö˜DŒ"²Y¡}P•eUyY”Å,X1ÆçÅÛf .Ãf›Óòíjxu·L»ç5ý\—E+‡Qãº× %ŒÀ˜ÀT·ÙA"P„ìpúúV7—ûp¶Õ„Ív¿ùRîÀÿó¯þp-ÌvU@ôc6!@CÆ	c$a	ª=&ňF7ˆ:sŽß\§£YÿæêCËE.–£QQ=o/d”þÐww52‚óg’7‚ç²±‚02	;0,Pímò®P‹<΋?–>ôuàý¨DLš25°rþâh^a&µfpY6@†"aª½‚›êév"Á›Ñ¤\³24÷dzþÛ
+çø¶1y3Á«ÙÌAŒ5×=×’²cÕÞ2Ãц³ÈŒ¨™»jŽ§ƒ%HoâÝÞºQì¹dà«l€ FŒFBÂŒ„
í©û<Ì	b”¬1<¬Æ±ûS¿Œû»oú#ävO”~èí(€ÜîY³Êu?bžqŦÖTÁÅ,#ƹ:‡«aU¸Ýáxô¤’æ·³ù5Æ#÷ºƒ‚Èu·o²„l¨ö›vÄ6›*W#¶gíjZÕoÊlaûr°	¢…51e­Ûr)ÔŠ6£ÝbÂ
+Œ4LwMbý¿†4Ñdµr>/ÕCÙGÕãx¤T[žþ"‚¿³I‚J0žŒvoUH‚Á„ª4IEœº¡I®Ñ4ÊÕão=ObÒ§‚\
Ä@‚¡d´»îL‚„ª 	Aœ±ªIÕ •ýI1Ü\ƒwƒiùv¯zâ– &(ø8›  ˆcÈh÷uÊŒ T}$È÷²”‹¦s©¶VÞ!¨IEj›ƒ>ž àãl‚€ FŒ!cݸJ‚„ª1J¨¶¡á3€ ê¬Ô¶îþuwˆA6a@#Ƙ1¤ôN‚†ª„9KÊÖ|ÍÊáÀû–Ùmw÷¥ak‘‹Z+†€BÍX÷VÆMÈ0Å1«‰/ÝC{×|ƒ›p»+üȪ¸JHcݵ|Â
+„?TwÐHÂ)¡Ã÷e“åö+ÌV÷ÛŒö—⼞‹Cp‚1eûšÁ
+6pŠßuºï¥ŒvÉgøÿqªÞóiß­Ú~lõø.k;vÛêˆà´Ú)AdS*dÉþê `ùÿø6š±endstream
 endobj
-806 0 obj <<
+810 0 obj <<
 /Type /Page
-/Contents 807 0 R
-/Resources 805 0 R
+/Contents 811 0 R
+/Resources 809 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
-/Annots [ 809 0 R 810 0 R 811 0 R 812 0 R 813 0 R 814 0 R 815 0 R 816 0 R 817 0 R 818 0 R 819 0 R 820 0 R 821 0 R 822 0 R 823 0 R 824 0 R 825 0 R 826 0 R 827 0 R 828 0 R 829 0 R 830 0 R 831 0 R 832 0 R 833 0 R 834 0 R 835 0 R 836 0 R 837 0 R 838 0 R 839 0 R 840 0 R 841 0 R 842 0 R 843 0 R 844 0 R 845 0 R 846 0 R 847 0 R 848 0 R 849 0 R 850 0 R 851 0 R 852 0 R 853 0 R 854 0 R 855 0 R 856 0 R 857 0 R 858 0 R 859 0 R 860 0 R 864 0 R 865 0 R ]
+/Parent 663 0 R
+/Annots [ 813 0 R 814 0 R 815 0 R 816 0 R 817 0 R 818 0 R 819 0 R 820 0 R 821 0 R 822 0 R 823 0 R 824 0 R 825 0 R 826 0 R 827 0 R 828 0 R 829 0 R 830 0 R 831 0 R 832 0 R 833 0 R 834 0 R 835 0 R 836 0 R 837 0 R 838 0 R 839 0 R 840 0 R 841 0 R 842 0 R 843 0 R 844 0 R 845 0 R 846 0 R 847 0 R 848 0 R 849 0 R 850 0 R 851 0 R 852 0 R 853 0 R 854 0 R 855 0 R 856 0 R 857 0 R 858 0 R 859 0 R 860 0 R 861 0 R 862 0 R 863 0 R 864 0 R 865 0 R 869 0 R 870 0 R ]
 >> endobj
-809 0 obj <<
+813 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 758.4766 539.579 767.4329]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.19) >>
+/A << /S /GoTo /D (subsection.6.2.18) >>
 >> endobj
-810 0 obj <<
+814 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 746.5215 539.579 755.4777]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.20) >>
+/A << /S /GoTo /D (subsection.6.2.19) >>
 >> endobj
-811 0 obj <<
+815 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 734.5663 539.579 743.5226]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.21) >>
+/A << /S /GoTo /D (subsection.6.2.20) >>
 >> endobj
-812 0 obj <<
+816 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 722.6111 539.579 731.5674]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.22) >>
+/A << /S /GoTo /D (subsection.6.2.21) >>
 >> endobj
-813 0 obj <<
+817 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 710.656 539.579 719.6122]
 /Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.22) >>
+>> endobj
+818 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 698.7008 539.579 707.6571]
+/Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.23) >>
 >> endobj
-814 0 obj <<
+819 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 698.8005 539.579 707.8065]
+/Rect [527.6238 686.7456 539.579 695.7019]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.24) >>
 >> endobj
-815 0 obj <<
+820 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 686.8453 539.579 695.8514]
+/Rect [527.6238 674.7905 539.579 683.7467]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.24.1) >>
 >> endobj
-816 0 obj <<
+821 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 674.8901 539.579 683.7467]
+/Rect [527.6238 662.935 539.579 671.941]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.24.2) >>
 >> endobj
-817 0 obj <<
+822 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 662.8353 539.579 671.7916]
+/Rect [527.6238 650.9798 539.579 659.9859]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.24.3) >>
 >> endobj
-818 0 obj <<
+823 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 650.8801 539.579 659.8364]
+/Rect [527.6238 639.0246 539.579 647.8812]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.24.4) >>
 >> endobj
-819 0 obj <<
+824 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 638.925 539.579 647.8812]
+/Rect [527.6238 626.9698 539.579 635.9261]
 /Subtype /Link
 /A << /S /GoTo /D (section.6.3) >>
 >> endobj
-820 0 obj <<
+825 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 626.9698 539.579 635.9261]
+/Rect [527.6238 615.0146 539.579 623.9709]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.1) >>
 >> endobj
-821 0 obj <<
+826 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 615.0146 539.579 623.9709]
+/Rect [527.6238 603.0594 539.579 612.0157]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.1.1) >>
 >> endobj
-822 0 obj <<
+827 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 603.0594 539.579 612.0157]
+/Rect [527.6238 591.1043 539.579 600.0606]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.1.2) >>
 >> endobj
-823 0 obj <<
+828 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 591.1043 539.579 600.0606]
+/Rect [527.6238 579.1491 539.579 588.2549]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.2) >>
 >> endobj
-824 0 obj <<
+829 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 579.1491 539.579 588.1054]
+/Rect [527.6238 567.1939 539.579 576.2997]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.3) >>
 >> endobj
-825 0 obj <<
+830 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 567.1939 539.579 576.1502]
+/Rect [527.6238 555.2388 539.579 564.1951]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.4) >>
 >> endobj
-826 0 obj <<
+831 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 555.2388 539.579 564.3445]
+/Rect [527.6238 543.2836 539.579 552.2399]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.5) >>
 >> endobj
-827 0 obj <<
+832 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 543.2836 539.579 552.3894]
+/Rect [527.6238 531.3284 539.579 540.2847]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.5.1) >>
 >> endobj
-828 0 obj <<
+833 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 531.3284 539.579 540.4342]
+/Rect [527.6238 519.3733 539.579 528.3296]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.5.2) >>
 >> endobj
-829 0 obj <<
+834 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 519.3733 539.579 528.479]
+/Rect [527.6238 507.4181 539.579 516.3744]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.5.3) >>
 >> endobj
-830 0 obj <<
+835 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 507.4181 539.579 516.5239]
+/Rect [527.6238 495.4629 539.579 504.4192]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.6) >>
 >> endobj
-831 0 obj <<
+836 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 495.4629 539.579 504.4192]
+/Rect [527.6238 483.5078 539.579 492.6135]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.7) >>
 >> endobj
-832 0 obj <<
+837 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 473.5253 539.579 482.2574]
+/Rect [527.6238 461.5701 539.579 470.3022]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.7) >>
 >> endobj
-833 0 obj <<
+838 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 461.59 539.579 470.5462]
+/Rect [527.6238 449.6348 539.579 458.5911]
 /Subtype /Link
 /A << /S /GoTo /D (section.7.1) >>
 >> endobj
-834 0 obj <<
+839 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 449.6348 539.579 458.5911]
+/Rect [527.6238 437.6796 539.579 446.6359]
 /Subtype /Link
 /A << /S /GoTo /D (section.7.2) >>
 >> endobj
-835 0 obj <<
+840 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 437.6796 539.579 446.6359]
+/Rect [527.6238 425.7245 539.579 434.6807]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.7.2.1) >>
 >> endobj
-836 0 obj <<
+841 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 425.7245 539.579 434.6807]
+/Rect [527.6238 413.7693 539.579 422.7256]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.7.2.2) >>
 >> endobj
-837 0 obj <<
+842 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 413.7693 539.579 422.7256]
+/Rect [527.6238 401.8141 539.579 410.7704]
 /Subtype /Link
 /A << /S /GoTo /D (section.7.3) >>
 >> endobj
-838 0 obj <<
+843 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 391.8316 539.579 400.5637]
+/Rect [527.6238 379.8764 539.579 388.6086]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.8) >>
 >> endobj
-839 0 obj <<
+844 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 379.8963 539.579 388.8526]
+/Rect [527.6238 367.9411 539.579 376.8974]
 /Subtype /Link
 /A << /S /GoTo /D (section.8.1) >>
 >> endobj
-840 0 obj <<
+845 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 367.9411 539.579 376.8974]
+/Rect [527.6238 355.986 539.579 364.9423]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.8.1.1) >>
 >> endobj
-841 0 obj <<
+846 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 355.986 539.579 364.9423]
+/Rect [527.6238 344.0308 539.579 352.9871]
 /Subtype /Link
 /A << /S /GoTo /D (section.8.2) >>
 >> endobj
-842 0 obj <<
+847 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 344.0308 539.579 352.9871]
+/Rect [527.6238 332.0756 539.579 341.0319]
 /Subtype /Link
 /A << /S /GoTo /D (section.8.3) >>
 >> endobj
-843 0 obj <<
+848 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 322.0931 539.579 330.9498]
+/Rect [527.6238 310.138 539.579 318.9946]
 /Subtype /Link
 /A << /S /GoTo /D (appendix.A) >>
 >> endobj
-844 0 obj <<
+849 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 310.1578 539.579 319.2636]
+/Rect [527.6238 298.2027 539.579 307.3084]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.1) >>
 >> endobj
-845 0 obj <<
+850 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 298.2027 539.579 307.3084]
+/Rect [527.6238 286.2475 539.579 295.3532]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.1.1) >>
 >> endobj
-846 0 obj <<
+851 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 286.2475 539.579 295.2038]
+/Rect [527.6238 274.2923 539.579 283.2486]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.2) >>
 >> endobj
-847 0 obj <<
+852 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 274.2923 539.579 283.2486]
+/Rect [527.6238 262.3372 539.579 271.2934]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.2.1) >>
 >> endobj
-848 0 obj <<
+853 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 262.3372 539.579 271.2934]
+/Rect [527.6238 250.382 539.579 259.3383]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.3) >>
 >> endobj
-849 0 obj <<
+854 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 250.382 539.579 259.3383]
+/Rect [527.6238 238.4268 539.579 247.3831]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.3.1) >>
 >> endobj
-850 0 obj <<
+855 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 238.4268 539.579 247.3831]
+/Rect [527.6238 226.4717 539.579 235.4279]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.3.2) >>
 >> endobj
-851 0 obj <<
+856 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 226.4717 539.579 235.4279]
+/Rect [527.6238 214.5165 539.579 223.4728]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.3.3) >>
 >> endobj
-852 0 obj <<
+857 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 204.534 539.579 213.2661]
+/Rect [527.6238 192.5788 539.579 201.3109]
 /Subtype /Link
 /A << /S /GoTo /D (appendix.B) >>
 >> endobj
-853 0 obj <<
+858 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 192.5987 539.579 201.555]
+/Rect [527.6238 180.6435 539.579 189.5998]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.1) >>
 >> endobj
-854 0 obj <<
+859 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 180.6435 539.579 189.7493]
+/Rect [522.6425 168.6883 539.579 177.7941]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.2) >>
 >> endobj
-855 0 obj <<
+860 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 168.6883 539.579 177.7941]
+/Rect [522.6425 156.7332 539.579 165.8389]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.3) >>
 >> endobj
-856 0 obj <<
+861 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 156.7332 539.579 165.8389]
+/Rect [522.6425 144.778 539.579 153.8838]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.4) >>
 >> endobj
-857 0 obj <<
+862 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 144.778 539.579 153.8838]
+/Rect [522.6425 132.8228 539.579 141.9286]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.5) >>
 >> endobj
-858 0 obj <<
+863 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 132.8228 539.579 141.9286]
+/Rect [522.6425 120.8677 539.579 129.9734]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.6) >>
 >> endobj
-859 0 obj <<
+864 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 120.9673 539.579 129.9734]
+/Rect [522.6425 109.0122 539.579 118.0182]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.7) >>
 >> endobj
-860 0 obj <<
+865 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 108.9125 539.579 118.0182]
+/Rect [522.6425 96.9573 539.579 106.0631]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.8) >>
 >> endobj
-864 0 obj <<
+869 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 96.9573 539.579 106.0631]
+/Rect [522.6425 85.0022 539.579 94.1079]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.9) >>
 >> endobj
-865 0 obj <<
+870 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 85.0022 539.579 94.1079]
+/Rect [522.6425 73.047 539.579 82.1527]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.10) >>
 >> endobj
-808 0 obj <<
-/D [806 0 R /XYZ 85.0394 794.5015 null]
+812 0 obj <<
+/D [810 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-805 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+809 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-868 0 obj <<
+873 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream
 endobj
-867 0 obj <<
+872 0 obj <<
 /Type /Page
-/Contents 868 0 R
-/Resources 866 0 R
+/Contents 873 0 R
+/Resources 871 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
+/Parent 663 0 R
 >> endobj
-869 0 obj <<
-/D [867 0 R /XYZ 56.6929 794.5015 null]
+874 0 obj <<
+/D [872 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-866 0 obj <<
+871 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-872 0 obj <<
-/Length 2197      
+877 0 obj <<
+/Length 2174      
 /Filter /FlateDecode
 >>
 stream
-xÚÝYÝã¶÷_áG-pfù)‘y¼»¦¸ ¸¢Ý
òæA+qmádÉÑÇnœ¿¾C)˶|wé-РX`M†äpæ7¿ÚlMá­µ"T¹ÎŒ$Š2µ.ö+ºÞ»¿­XБJ%…€‡…·%4QšgëÍ|‘·«¿|ÏÙšS’¦\­ž¦½ÒL#¤Y?”?'ïvùa°Ý݆+š°»_~Ài’d:cn…-ÉÕ~‡fèÚr,†ªm‚ºXbRžFí悹Nûagaiºi¶kì€OïÛ}^58þ˜ïƒÎý±ìÇÿ¦Š¾ÿxÌ	²¤h›¾ê‡_·Oø9Äõûc3ä¿ad[TOÇÍö»XÅ6C5T(Í’êŽ%
Ý$8£;cÄ(Å£Âa§‰;ˆà,ÉñqWÙ.ïî˜NŠ]Uä5J÷yÓ€›3™¼Ðh{ÓÝéd¬Ýæn‘±·%ÊŸÚ¥­í6ªfö‡]ÛU˜yDIûlƒ®?\Ø!oÂJa+Nò>;ó'ªö‡ÚîÁ¹ë†ƒ¡Ã.wáÊT’Ø×õåûüÐã(ºT¼ÏA4‹³›X–Þ¶ïmOÀ-ˆ*ª–ù£ZÕÇ•+° jœܳ‡ˆ[·~­v< ¢·›@ÒUãàQKñpR·ùcî­Š˜g’™ò€bI	Obž!£”&÷E{°¸‚|¾o‹Ñyn9¸&ifÎ’&om÷	‚êýiÎRƒÆtù)I¨O‡·>¾ùo§ˆõ¨‘ãG'J2‹&½í /£OüÓãö\•6¼ÏW«ÚGØ lÇ0sÖ+õp®Õ”8(0¶^Q† ÌfNÎ]8òMa|üÒvC5îñÙyüÃý»àp8÷ã\ÙChbð£oŸ†—™)49äŧ|ÐéN/rŒór_5®ùÐvDobô|Ž©ú…M#öÂ1=½ŒÚEÛ…¤;´M¦ûüüÌ)ˆüºDà!þÑmó¦ú}ŠÈɦ“É_Ÿ…RG9n® jBÐœ,³ÙdÍHÊ%¬áƒh±ùùla+°_¥™ê@0ˆF(ažsý®7
°t2ÏRN†,
-ôœA)*ìaˆÔqf§†d
-DÖñ›Öñ 	RyEÃBÛékÑFdœ(&ø9˜Q÷×±ÂÁÄS¬4MƒÙÏ0Bš1ÉsÞUíæÙæk¿d¹äÄjž°8ùÚ‚§D
-}å7A,û+£c”ú…%%”Æ8yÿiU¢¿^OI¢0SÔƒ©C>”‚e”<÷á!8|V5T•Ëã­Wóø·áÕÓØøú*ÉsUž›vð>¯Jœ‹–D‚A Gcoƒyä¼­ÙŒ6á¹sîqA¢Ú—š…2î5ï’~<¡ÈÔuûUKÑH)´yŠ-X.DdDdYÌZ젉©ŠNƒ¼rÕ?ÀoßNl
-OyùœCÖ•“¦Ï@´64* >2óNgÃŒ&ÌõÀçUlN¾.ÝR Ñ#ë›0Hõ§øn*·Ø†¤°ÝàK­{hîôËŒB/-RvÍi¢n0‚b‰ÒHUéŒ
-êj»^¬ûh‚*"¸‘K4Ñ·õ3v£®tgihM2îc`ˆŠw.°Ëº>,)…¼â`7!]
->YÉàT&³ëdQ¶®ÂŠ¾QaÁô'ìL,ßN¥ÆØ…òn³%†x¾¶Ù¶˜R~*”»	0QŒåï,cš7¢“²°½Ì»k/™ŒhaÄ•“`j¶ä$¸Ç±)CÎZç°Ÿ-Fèûh†¿•ÐÛz乄Úq\µ”«,ázÉ}Ó’hø,-A?”Ïñ®,»¶õù€x“€sšês¼íl}pœ¶…öW$±­•Éc[ç¬'cŸµ ®9ΉI:bòÒޚɗ1gÔäÔÃÁ6eå*ÿB⥄i¸=£êË.ð’ô€Œ˜¬†;ÚÓXã8€^Ïp‰þ€>NëÌœûcÖî¾qnQI?º}„FÜûÏÅâ§:«Çºj·]~Ø—ªŸ FŸ ä[Xº+ ;ßâø3+äN€€.Û}—Nbª8"ÖBÿÊâ-ÅýÝ%$“!œK}žLØp]£)B£	}ù³£Ý¶	]å}¼ÙUÍ·uœØAǹ§ŽÓ?¾„΂}Ñk#È&[Ûxð¡Òñ€QÁëkÆ'ó¿sV­þú0}ucRh5¸AiBShèŠýê×ÕÏ¿Ðu¹¢ëV”£Õú(aÆðõ~%©ÒQR¯îWÿü/gE;fMÂMp…µÂ0‚ú|©M<Ó†¹t¢šM_F]ÀY&$,#
I·ß:…›J¬|Wn\ÐÓëùßfõ´äÌÐ6J—ÓgfÿtÇir.ýp¬¯¡\œ*õŠ‡®²~æþïàÄ ÄàLqÆM8q rcÄé»M±'×fJd›ÜµÂîáÃÎ}âèV
-¸×S^ÛIÀ“ÿõ÷7¨¹kûa¦	¼VÇêvñÍA
DŠÑ
úþ®ø}	°ÝþüUè[o#zvÊosÜÑ—žƒ[Ñ¢gžû¾úÍql
-ôûR•Ãî6x_ÍÞ?xc _‘©!RªôKàe‚PÁ#ĆSYVébÍ;ŒŸÁÏl£WcÄK㡪/ágnü@?yùáÛ¶.oCéÕLÿ¿†Ü)¨aæKH¢ZØâô­†kK"Ãç@4Ûâµ0tiõ
-š[}¡[Ày5sÿ,¸áî‹®Œ¥î
-ADÆåüg¿«Ÿÿ¸§` Ô
˜¯µ^ü0þô·Š¸_Ñ# §r”\²+·Ç_O+ÅÝþ-Õ«endstream
+xÚÝYÝoã6÷_áGXëø%‘ìãî¶ÅÅî’¢½>(ckK®>’ºý
9C[ŠåÍö6ÀE€ˆ¤†äpæ7¿Ê|Éà/M–2iÕR[•fŒgËõ~Á–x÷ý‚“ŒÊdš))¡3óv•I“fFèåj¼ÈÛ»Å?¾|)Xšç"[Þ=œöʵI­TvyWþ’¼Û‡Þµ7+‘±„ßüz÷NS©6šûi¶ÈRm™	>Ô}۔ú¯ššÄåÒ¦6y”Ö0ÔõÒw[K›ÜOsmízì½oöEUcûc±'™Ûc×»=¶ÿÃ2öþã-<¸Ðɺ©»ªë;|Ý<à³ëwǺ/~§Á†Æn]=ŸIÖ°ß³U\ÝW}…£:©nxRcÓO‚3úSqžÚ,Ñt)Xâ"O
+ìn+×í
7Éz[­‹Žî‹º3k•¼iPÿ¦½1É°ó›ûE†Î•8þдØ(ÝÎmŠ¾ª7´ÏÐo›¶êAÍ#Ž4ŽdÃáh‡¢¦•h+F
+žœˆ‡UûÃÎíÁEðëJ€¢ý¶ðîÒYR¬û¡ØíŽ8¾/¶¢)A$؆F~öË2XÂuëRPÂȼŠ¢eÑ(Vuqå
+4¨joßñË`wÖj†Ž‚÷f|SHÚê~èÃ"Ùœ?ü¨ßü¾ZEÌs•J•B±b©È%bž§BÎKn×ÍÁá
+<ð|߬o¹ù`&͵KÞºö85ØÓNBƒÅp€ñs°o?||OñoOëP¢ÀG'HM‘Œε"~4à*ÎðRÃþÞÑ<.Xl5ga‚¢È$*x–[8_p$Œ—Ñ&¡w@¿=V¥£÷`ùjͪ…öv0PÜ7MĘ
B]KÕ%6ÖèÛ ¨È)£™'ãÎù¦C7¾~iÚ¾öØ÷ÿpûŽÞüØSv¤K,>ºæ¡©Â’C±þTl¨ƒF÷r‘ã ]”ûªöp-ú¦E 5Ð3ð9B¦êf6Ø£cz"´×MKAwhê’¦‡øüÌ)Rõe (þÙnŠºúã䑳Ng•¿<2>œ(§">‰zƒ“•M6Ó2žÃ"Ó𙽔€ôi‰à !‡¹.nëp׈K#šÊi0B¦ƒ!ÈEkwè#wL”L§,jN;ñ¢v!k`¯¨ù±¿0­¤©á°ÅÍ(ûÛPa#Rƒ–>h„TS×¾Ð'Ä´2y,Úªhž«q±¦«ù0|5ŽXœ|i	%DžÃÐ…d"¯Øë(0¸\Ò¦Fñ(Ñݧ¤AP˜þr½*)ò“×qçªïІJòTg¹žÚð@%B#º8a 	b!½zêP…4É9÷i^XŠ;x_T%ÎEFÄŽÆß 	‹Hzè­ñrY“8I1rÍLžŸZ
LE[GW2ÊÄ ³Û5O(Â’ûãŒ7xþÐvÆÁA‡5¡RÜ/”„&ËLÙ-nÿúgE=F…ÂU
pƒµ¨Ñ=]jÏ´â>œ˜á§/RS43À‡T°Œ‚m]yBùDו˜ý.Ì&0çf9Þâë´>-ù‚ÚJG•ÏTíŸoK®Â¥ë»ËCd"OUže¯x% Ìb>éÓÜÿœ„L-¸øOœ)θ
+'E»µòüSÎÂIj d›Â§—ñ~ë?‡@\+%árÏÄÎDòÓ¿|ƒ’Û¦ëG’Àk¡Ÿù|°"Eï’|¸Ó=¿vO×¨|½ŽèÑ)¿Îp#D?·œ´³ˆYî»êwϱ9ÐïSUöÛëà}5}ÿBàŽ~E.dPª,	¼\¦LŠ±þœV€UÚ˜óÃgð3ÚèÕñ¹òÊÌâg¬ü@?…æÛfW^‡Ò«©þ·†’Õ)³Ü¾„$×4
[œ¿lø²$²ÑÐD£-^Cϵ¾BAc­/ t
8¯¦î_7îØLs¨Á0R5þíïâ7@(Øß^A}cÌì…ñ÷?¸­¥þçÄYôHˆ@)˜Z’÷‚¾0{üÉñ¼RÜí¿8£sendstream
 endobj
-871 0 obj <<
+876 0 obj <<
 /Type /Page
-/Contents 872 0 R
-/Resources 870 0 R
+/Contents 877 0 R
+/Resources 875 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
+/Parent 891 0 R
 >> endobj
-873 0 obj <<
-/D [871 0 R /XYZ 85.0394 794.5015 null]
+878 0 obj <<
+/D [876 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 6 0 obj <<
-/D [871 0 R /XYZ 85.0394 769.5949 null]
+/D [876 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-874 0 obj <<
-/D [871 0 R /XYZ 85.0394 582.8476 null]
+879 0 obj <<
+/D [876 0 R /XYZ 85.0394 582.8476 null]
 >> endobj
 10 0 obj <<
-/D [871 0 R /XYZ 85.0394 512.9824 null]
+/D [876 0 R /XYZ 85.0394 512.9824 null]
 >> endobj
-875 0 obj <<
-/D [871 0 R /XYZ 85.0394 474.7837 null]
+880 0 obj <<
+/D [876 0 R /XYZ 85.0394 474.7837 null]
 >> endobj
 14 0 obj <<
-/D [871 0 R /XYZ 85.0394 399.5462 null]
+/D [876 0 R /XYZ 85.0394 399.5462 null]
 >> endobj
-876 0 obj <<
-/D [871 0 R /XYZ 85.0394 363.8828 null]
+881 0 obj <<
+/D [876 0 R /XYZ 85.0394 363.8828 null]
 >> endobj
 18 0 obj <<
-/D [871 0 R /XYZ 85.0394 223.0066 null]
+/D [876 0 R /XYZ 85.0394 223.0066 null]
 >> endobj
-880 0 obj <<
-/D [871 0 R /XYZ 85.0394 190.9009 null]
+885 0 obj <<
+/D [876 0 R /XYZ 85.0394 190.9009 null]
 >> endobj
-881 0 obj <<
-/D [871 0 R /XYZ 85.0394 170.4169 null]
+886 0 obj <<
+/D [876 0 R /XYZ 85.0394 170.4169 null]
 >> endobj
-882 0 obj <<
-/D [871 0 R /XYZ 85.0394 158.4617 null]
+887 0 obj <<
+/D [876 0 R /XYZ 85.0394 158.4617 null]
 >> endobj
-870 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F48 885 0 R >>
+875 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R /F47 884 0 R /F39 868 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-889 0 obj <<
+894 0 obj <<
 /Length 3125      
 /Filter /FlateDecode
 >>
@@ -2521,66 +2549,66 @@ J
 ÷&M¾d)#þjºàZK×û^ÙÊÏVøË8–rFÏõÛ‚Ãú×»=ßÆ@Š³8UWmÍmŒ>v/›øª„JÓ£¯mM‡ÅŽ lÛÖZe¶â×cú Å¬Õ+Ö4a“	XQБä5|ÔíC2:Íñ¢Ü!;­õ–OÞ˜ád°>C$_œEI¾Ò“”×qHHS9kí=³¡­-¡:½Åø—êw½ypv»ï¸)ü®óк7‹æØWçöhFiBº@:yÑáFBÛ”î­Çµ:
 S™ýä-ç깇b뤈;=Ÿµmê®c?Ý*؇ñù	»”åþèmÓ+ô‚¥ÿ±%:W€Ï$üE‰.ùȨ¾Ì\Ô>‘Zø!çC°z¬ÌÀÏ9ó.8Ló3.ˆ¬ã2ÜÍÓ©ÏÀ}W¤#›Ù¥ô´¹Ü¹g«"×Z`ä1RãËO:0‘ÓàÖt#£nÁß“zí6§š»Æ¸M9ÝšŸ4‘f„ï~[ÓòF¤¿gþÍHGþoÇ‹‰ÅÈ¿ö_Îÿ‰•‚NSõŒ;L±C¤G¢Péáî_•®)ÿå¹€Hendstream
 endobj
-888 0 obj <<
+893 0 obj <<
 /Type /Page
-/Contents 889 0 R
-/Resources 887 0 R
+/Contents 894 0 R
+/Resources 892 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
-/Annots [ 896 0 R 897 0 R ]
+/Parent 891 0 R
+/Annots [ 901 0 R 902 0 R ]
 >> endobj
-896 0 obj <<
+901 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [272.8897 210.0781 329.1084 222.1378]
 /Subtype /Link
 /A << /S /GoTo /D (types_of_resource_records_and_when_to_use_them) >>
 >> endobj
-897 0 obj <<
+902 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [190.6691 182.1322 249.6573 191.5418]
 /Subtype /Link
 /A << /S /GoTo /D (rfcs) >>
 >> endobj
-890 0 obj <<
-/D [888 0 R /XYZ 56.6929 794.5015 null]
+895 0 obj <<
+/D [893 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-891 0 obj <<
-/D [888 0 R /XYZ 56.6929 756.8229 null]
+896 0 obj <<
+/D [893 0 R /XYZ 56.6929 756.8229 null]
 >> endobj
-892 0 obj <<
-/D [888 0 R /XYZ 56.6929 744.8677 null]
+897 0 obj <<
+/D [893 0 R /XYZ 56.6929 744.8677 null]
 >> endobj
 22 0 obj <<
-/D [888 0 R /XYZ 56.6929 649.0335 null]
+/D [893 0 R /XYZ 56.6929 649.0335 null]
 >> endobj
-893 0 obj <<
-/D [888 0 R /XYZ 56.6929 609.5205 null]
+898 0 obj <<
+/D [893 0 R /XYZ 56.6929 609.5205 null]
 >> endobj
 26 0 obj <<
-/D [888 0 R /XYZ 56.6929 551.1302 null]
+/D [893 0 R /XYZ 56.6929 551.1302 null]
 >> endobj
-894 0 obj <<
-/D [888 0 R /XYZ 56.6929 525.7505 null]
+899 0 obj <<
+/D [893 0 R /XYZ 56.6929 525.7505 null]
 >> endobj
 30 0 obj <<
-/D [888 0 R /XYZ 56.6929 422.4834 null]
+/D [893 0 R /XYZ 56.6929 422.4834 null]
 >> endobj
-895 0 obj <<
-/D [888 0 R /XYZ 56.6929 395.8284 null]
+900 0 obj <<
+/D [893 0 R /XYZ 56.6929 395.8284 null]
 >> endobj
 34 0 obj <<
-/D [888 0 R /XYZ 56.6929 166.2827 null]
+/D [893 0 R /XYZ 56.6929 166.2827 null]
 >> endobj
-898 0 obj <<
-/D [888 0 R /XYZ 56.6929 138.253 null]
+903 0 obj <<
+/D [893 0 R /XYZ 56.6929 138.253 null]
 >> endobj
-887 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
+892 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F47 884 0 R /F39 868 0 R /F21 662 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-903 0 obj <<
+908 0 obj <<
 /Length 3414      
 /Filter /FlateDecode
 >>
@@ -2602,60 +2630,60 @@ _t
 •®piQâEpd
 £¼(†¿_]rþ_q'Šendstream
 endobj
-902 0 obj <<
+907 0 obj <<
 /Type /Page
-/Contents 903 0 R
-/Resources 901 0 R
+/Contents 908 0 R
+/Resources 906 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
-/Annots [ 906 0 R 907 0 R ]
+/Parent 891 0 R
+/Annots [ 911 0 R 912 0 R ]
 >> endobj
-906 0 obj <<
+911 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [519.8432 463.1122 539.579 475.1718]
 /Subtype /Link
 /A << /S /GoTo /D (diagnostic_tools) >>
 >> endobj
-907 0 obj <<
+912 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [84.0431 451.8246 133.308 463.2167]
 /Subtype /Link
 /A << /S /GoTo /D (diagnostic_tools) >>
 >> endobj
-904 0 obj <<
-/D [902 0 R /XYZ 85.0394 794.5015 null]
+909 0 obj <<
+/D [907 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 38 0 obj <<
-/D [902 0 R /XYZ 85.0394 570.5252 null]
+/D [907 0 R /XYZ 85.0394 570.5252 null]
 >> endobj
-905 0 obj <<
-/D [902 0 R /XYZ 85.0394 541.3751 null]
+910 0 obj <<
+/D [907 0 R /XYZ 85.0394 541.3751 null]
 >> endobj
 42 0 obj <<
-/D [902 0 R /XYZ 85.0394 434.1868 null]
+/D [907 0 R /XYZ 85.0394 434.1868 null]
 >> endobj
-908 0 obj <<
-/D [902 0 R /XYZ 85.0394 406.5769 null]
+913 0 obj <<
+/D [907 0 R /XYZ 85.0394 406.5769 null]
 >> endobj
 46 0 obj <<
-/D [902 0 R /XYZ 85.0394 301.1559 null]
+/D [907 0 R /XYZ 85.0394 301.1559 null]
 >> endobj
-909 0 obj <<
-/D [902 0 R /XYZ 85.0394 276.6843 null]
+914 0 obj <<
+/D [907 0 R /XYZ 85.0394 276.6843 null]
 >> endobj
 50 0 obj <<
-/D [902 0 R /XYZ 85.0394 200.1512 null]
+/D [907 0 R /XYZ 85.0394 200.1512 null]
 >> endobj
-910 0 obj <<
-/D [902 0 R /XYZ 85.0394 175.6796 null]
+915 0 obj <<
+/D [907 0 R /XYZ 85.0394 175.6796 null]
 >> endobj
-901 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
+906 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F47 884 0 R /F39 868 0 R /F21 662 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-914 0 obj <<
+919 0 obj <<
 /Length 2458      
 /Filter /FlateDecode
 >>
@@ -2672,39 +2700,39 @@ Y
 ä4	Õ’BánUàhjUÔWäÎÜ2÷t!8ŽŸ
 e*Ѳ€Ç,EJ¡¼Mq	9jÕäå/œÆGi²5—Žøy©Ö…¯¿«vzOÖSo9¯ÞøoÒþ!²ðOH8&ºÿû—éï§(
T–Éå¿TðA8Ê€3åRjxùÿƒæ–õÿ÷Å:êendstream
 endobj
-913 0 obj <<
+918 0 obj <<
 /Type /Page
-/Contents 914 0 R
-/Resources 912 0 R
+/Contents 919 0 R
+/Resources 917 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
+/Parent 891 0 R
 >> endobj
-915 0 obj <<
-/D [913 0 R /XYZ 56.6929 794.5015 null]
+920 0 obj <<
+/D [918 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 54 0 obj <<
-/D [913 0 R /XYZ 56.6929 717.7272 null]
+/D [918 0 R /XYZ 56.6929 717.7272 null]
 >> endobj
-916 0 obj <<
-/D [913 0 R /XYZ 56.6929 690.4227 null]
+921 0 obj <<
+/D [918 0 R /XYZ 56.6929 690.4227 null]
 >> endobj
 58 0 obj <<
-/D [913 0 R /XYZ 56.6929 550.0786 null]
+/D [918 0 R /XYZ 56.6929 550.0786 null]
 >> endobj
-917 0 obj <<
-/D [913 0 R /XYZ 56.6929 525.2967 null]
+922 0 obj <<
+/D [918 0 R /XYZ 56.6929 525.2967 null]
 >> endobj
 62 0 obj <<
-/D [913 0 R /XYZ 56.6929 393.0502 null]
+/D [918 0 R /XYZ 56.6929 393.0502 null]
 >> endobj
-918 0 obj <<
-/D [913 0 R /XYZ 56.6929 363.1913 null]
+923 0 obj <<
+/D [918 0 R /XYZ 56.6929 363.1913 null]
 >> endobj
-912 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R >>
+917 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-921 0 obj <<
+926 0 obj <<
 /Length 2095      
 /Filter /FlateDecode
 >>
@@ -2722,66 +2750,66 @@ D
 Õmíš™Q‘‚z
 â~ó
¯	fÙ"‡èâ9Lt¨ž¹£j¡	mK(ÈÏbµÌ¥X2¼É6õpT!h_¥^ÁO8,uU•a¸‡àk"¿°•6ªÇsÓ÷Oã_IZ:ä[²ÑiÉ*Np’êZÀu
‰¡‰ñìK—!Gµ&¯!cÖ`þû$8‘ôbGÊ=6ü¡ºJ¬« z¸Äã5Âr‘> endobj
-927 0 obj <<
+932 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [519.8432 268.1131 539.579 280.1727]
 /Subtype /Link
 /A << /S /GoTo /D (acache) >>
 >> endobj
-928 0 obj <<
+933 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [84.0431 256.1579 143.5361 268.2175]
 /Subtype /Link
 /A << /S /GoTo /D (acache) >>
 >> endobj
-922 0 obj <<
-/D [920 0 R /XYZ 85.0394 794.5015 null]
+927 0 obj <<
+/D [925 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 66 0 obj <<
-/D [920 0 R /XYZ 85.0394 769.5949 null]
+/D [925 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-923 0 obj <<
-/D [920 0 R /XYZ 85.0394 574.3444 null]
+928 0 obj <<
+/D [925 0 R /XYZ 85.0394 574.3444 null]
 >> endobj
 70 0 obj <<
-/D [920 0 R /XYZ 85.0394 574.3444 null]
+/D [925 0 R /XYZ 85.0394 574.3444 null]
 >> endobj
-924 0 obj <<
-/D [920 0 R /XYZ 85.0394 540.5052 null]
+929 0 obj <<
+/D [925 0 R /XYZ 85.0394 540.5052 null]
 >> endobj
 74 0 obj <<
-/D [920 0 R /XYZ 85.0394 447.7637 null]
+/D [925 0 R /XYZ 85.0394 447.7637 null]
 >> endobj
-925 0 obj <<
-/D [920 0 R /XYZ 85.0394 410.3389 null]
+930 0 obj <<
+/D [925 0 R /XYZ 85.0394 410.3389 null]
 >> endobj
 78 0 obj <<
-/D [920 0 R /XYZ 85.0394 348.7624 null]
+/D [925 0 R /XYZ 85.0394 348.7624 null]
 >> endobj
-926 0 obj <<
-/D [920 0 R /XYZ 85.0394 311.223 null]
+931 0 obj <<
+/D [925 0 R /XYZ 85.0394 311.223 null]
 >> endobj
 82 0 obj <<
-/D [920 0 R /XYZ 85.0394 189.9853 null]
+/D [925 0 R /XYZ 85.0394 189.9853 null]
 >> endobj
-929 0 obj <<
-/D [920 0 R /XYZ 85.0394 156.0037 null]
+934 0 obj <<
+/D [925 0 R /XYZ 85.0394 156.0037 null]
 >> endobj
-919 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R >>
+924 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-933 0 obj <<
+938 0 obj <<
 /Length 608       
 /Filter /FlateDecode
 >>
@@ -2790,75 +2818,80 @@ xÚ¥TKs
 "ÜH!ÌÜÍÎAî³ö];ØÆøc?ºÈœOW4r!	Ýl;ÁâqŽÝ,2èiÒÕry—x4Y|éù„!p·Œ“s/
 @6¿½6¦ô[šÅ‹Ôó©0˜}>_fqb\Ä]Ìom~§w«dÚýjžÄ‹ø6K½ÇìƉ³ÃÓ91¢ý¿œ‡GäæzÜA*8s_µ‚ ‚¸;'`²€ÒÑR:©sœx‡Ô“¼a	
É	âvqi S昀„GddÎó1Bš“n¿Wu+sËÚ^Ö붨ž-coM+wM?±Æ¥“A®O8#AÀy:ÓšK –„96j·/JÙm]õ…hjƒ®²VUY¯9Êuíaž¥Q«n÷$k¹5çª*~ûeñÓ†¨IÛ¼1mŸi-@cÍc™FílÞ‹¬›BUÀýHCÁ˜áh(…)X›¡Õ¨mkL_<Æ@Qåêµ1†¢Ú”]nê¿÷àëÒÃD€³Ò	B´÷‘±ÙS:ˆë¯”ˆ\©Ú­+ãëö~ëa ü|ÝJc*‹¦ý{,|+à ™\|¯N( ‘Ò˜ÛVHâóËEläï‘ÒÚ‹êŸÀVíPÊY1/å¦Uõ›1mò쇣‹ۑꆬAš¶.žºV_üh)ƒýâœØýÚËýïý<þ´‚RÎÉqõ¦+B"®AlS=û˜¼ë|\ä÷­ÿèD-endstream
 endobj
-932 0 obj <<
+937 0 obj <<
 /Type /Page
-/Contents 933 0 R
-/Resources 931 0 R
+/Contents 938 0 R
+/Resources 936 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
+/Parent 891 0 R
 >> endobj
-934 0 obj <<
-/D [932 0 R /XYZ 56.6929 794.5015 null]
+939 0 obj <<
+/D [937 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 86 0 obj <<
-/D [932 0 R /XYZ 56.6929 769.5949 null]
+/D [937 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-935 0 obj <<
-/D [932 0 R /XYZ 56.6929 744.7247 null]
+940 0 obj <<
+/D [937 0 R /XYZ 56.6929 744.7247 null]
 >> endobj
-931 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R >>
+936 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-938 0 obj <<
-/Length 1222      
+943 0 obj <<
+/Length 1215      
 /Filter /FlateDecode
 >>
 stream
-xÚÍWIãD¾÷¯ˆúäH¸âZ¼©OÍ°‰Hs`8TìrbSeìrBƒæ¿ójs6sàÊÁµ¼ý}ïsŒW	üðªHQBK¶ÊK†Ò§«êø”¬öp÷ýö2,¥(e”Âfá6NiÒ‚ä«øÚÈ×Û§Íw¯H‚²Œ¤«m3ûÊrP  °­Þx¯Å°ŽIšDtýÛöG§ÆP^äب%à"C¸¤Vþ'~Nø1œ‚â;%?$	ÙO×­’Þ]•¨ÌHæ­d%yά™$(i¤íhV,EeUíñY¸Ã~Xã"R§¶îbTG5Nû½µ¨ÝEuÁGJŽî‚wJî½ÕVœò~‹]+…jŒÆB­_N£€´ŽfÑûuI¢Æ´M’&-ŒQ™¦Ä¦e"r±>*Éw¯Ø‰w“õëFùÒUbм•n£z_XBëVîG473DYF|9FYRbë—"¼Žq’@Wø±þîº2^…­!ŠÉ<ÀÐlêÕ[áÕ∕ìÞÜÉÛMRƒ2W—íh…V]§Î­éˆÙŽ-T¸ó·ÕŒì¡ˆyòÞ£¡Z®ƒ=ß8+àÜÄkN¤×úó˜¥s0‡¦Ëv±óòU×
-©Ç¥·†EòS€Š2Of=§&ü¡W.tÀLFXôÚyÉß'1´¦÷fÓ¸<Žn§&=Z|KÁµ½áDnãÖ
[;ÑiteL-dçÞ^z@3Š Ñr0¡sSùØò¶Ð°´@EžQ/ëph‘@#†I¨„ƒÜkg+¡Û“€:cŒ£¯&L0À3LDc‚o`Â=æÕÔÕn¹ó"¦iâ$ü©ÏÍZ™Z}!W‰37µu£VDS' Ðò‡4A¤L\û6è@{{VnZ&ÜvœvR˜ò›ÍÙžÛñàVÚkÙRºåÜX³iuD·°qÅâUwñwñð—{à’ œˆ¡dCØËía~}øée	”®[³M#AJTyy+W·´@Aÿ­äóFèjc†£Þ=æ0Tè½>Ú˜ÍEq)·+\]gR½
=^Œl9¯ËσØÚ»Ç`Fvn˜ƒµsm»uð×RýŽW½ºÄè«…	Ô~x)³?•ôž­ȶ26úˆ=þbÁõ[?G¯ªa1˦킗NU¼;¨Q#Hïùe)&©tÛøBKõåš.ð=¤Á¼Î|OßûÏë¤j€©3³ý/iß’7.-Ñ[–‡Ñ}dyp‚…ge8àþ‚/Dcg*}àÚ¶÷fá
-ÿ¨2ûù@[ –¤('ðVt„(þ°	F—7¯€ÑK‚sTRRx;Ö›#<鹎{žëøIÜý7¸Pé´«Õqþ›ð™˜1t6Ihb–{â^Ž­(áÏ!½Žm‰CÁe
-5€B=—âÿëÄæ/n¸GÂä^xÞ`W>¾QAF?°9¯ª™Ù;ëƒû9âãòíÊwÁ®|»0«ðœIª
Ÿ:½äÊ0
£•0ö1¦ÿ˜SM™^ÿ^r0m%©ßÑ1¡¨Ä	ûOèøéÛíü•¾]hŠÌ—ÐÒwP‰/2î#èñ4ÉPAÊ<2yazïmþ¤zt÷7¯Ì™øendstream
+xÚÍW9ã6îçWSÉ@DóЉ©&“Iˆ-²)h™¶…•EE¢ìL‚ýïyä#e{¬Ý-¶HàB<Þñ½ë“Å~lQ¤„Š2YäeBRÊÒEu| ‹=ÜýøÀ¼L’
+’&BÀfæ6NEAÒ‚ç‹øÚÈ·ë‡Õœ-8%YÆÓÅz7ùÊrP °Þþ½dgT¿ŒyJ#±ücý3ª%$/rfÕ(¸È+…“ÿE
+ÿ¦úSP|Ñí{Jù~쥩uë͈EIÊŒgÞJÆÍóÄ™ù©ÅœEæPvE£jÇg…Ï®_²"Ò§z«PjÐG5Œû½ŒÚⶺEàÊF·{o²6\íG0×Ô­òB;Ý0ªöËqPd‹œGï–%.>c›†1R¦)wÑX ˜‡WÉA·rÓøDd3:_ið‹JõFÖ-ntç²æÖƒ2¦n÷™jÁ"’Œû,&Œd´dί l3J¡òØ/oS1
+!ÁÏ|€¡ÉÔ³·"«àˆuÛ¼âÉ]ég«ÌSÛ\˜—õD–BØM£Ïµ­…Ý€vÉ¢Æß¾©Ú¾°OÙù&èúZš`´m&€7rƒ×ž´¯óç[Ud	VÀB‰q±ñòUS«Ös®[hÍV6 ˜¦‘Ñö™8Ï©…ßw¡CÏd<‰ž/ùç¨úÚÖÞnvÇwz4ƒkkk)¸v7›7¸ÞØ-ŠŽ¦Ñâ€ô†Ú^j 2A Ðb°Ð¥Í|l¼Î,-H‘gÂËbºÎƒFãœð„ñ	l¹çÆeÂÔ'yfŒEß`OX0ØÀS›¨¿S•ŽJÍ—/b‹¦NÊŸúØœ•±6—²í™8K›[µ"E”·}((á%Åò­VPhíõYã"”Láv7­²é·›³?<×ÃWÆk¹Târ*¬Ýìz}$·mƒÉ’Usñwñð>XÉ	Ë
+’ºâÉÓía~}øñi®)±Z“M+ÁKRyy+·­{(†ú;ÉÇ•2ÕÊÇvóhØáwºÿàj`7Źخúê:ªê-ôxÙ|\˯½'~—{|ôÐ,ýàÏŽÀ
X7×®ZÝhÝmdõÁØn{5øl1ù…›‹ìoÝzNdë6¶úDö|übÂÍk7!„7T?å®n‚—FW²9èÁïñiS«M½ó‰nõ—s:Ã÷	tÌëÄ÷<ð½ñ<æ {˜:;Û_IûŽ¼YéˆÞ±<Œî=˃
+ž•á@ú9ƒÆ
+NT2æ 
ž®öv‰¿W™ü¼ç<™!Ž„¦$çðVDBT¹#†Ë›„WÀè÷)a9)/¼ç
	¯õ\'=Ï5ò¤Þü7¸Pé¸Ùêãô7á˜T–R‘ÌížÜóØŠþŠkls
+.Sø«ê¹”ý¿X'¶o|uÃ=-Lî…wà
våã;d̛˪š¨!=ZŸÜOŸl_¯|É•o»
+ω¤¶j'ÇÆÌ9‚4ŒýàF%Œ}ÌÄgcê®)ÓëŸÂKÆ ®Ô,u°7tÌ)Mþ:~ø~=}Ü„O‘û4÷ùDâ‹~û\w¼ )x™C6.&Þz›¾¤îÝýÄý˜!endstream
 endobj
-937 0 obj <<
+942 0 obj <<
 /Type /Page
-/Contents 938 0 R
-/Resources 936 0 R
+/Contents 943 0 R
+/Resources 941 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
+/Parent 949 0 R
 >> endobj
-939 0 obj <<
-/D [937 0 R /XYZ 85.0394 794.5015 null]
+944 0 obj <<
+/D [942 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 90 0 obj <<
-/D [937 0 R /XYZ 85.0394 769.5949 null]
+/D [942 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-940 0 obj <<
-/D [937 0 R /XYZ 85.0394 575.896 null]
+945 0 obj <<
+/D [942 0 R /XYZ 85.0394 575.896 null]
 >> endobj
 94 0 obj <<
-/D [937 0 R /XYZ 85.0394 529.2011 null]
+/D [942 0 R /XYZ 85.0394 529.2011 null]
 >> endobj
-941 0 obj <<
-/D [937 0 R /XYZ 85.0394 492.9468 null]
+946 0 obj <<
+/D [942 0 R /XYZ 85.0394 492.9468 null]
 >> endobj
 98 0 obj <<
-/D [937 0 R /XYZ 85.0394 492.9468 null]
+/D [942 0 R /XYZ 85.0394 492.9468 null]
 >> endobj
-942 0 obj <<
-/D [937 0 R /XYZ 85.0394 466.0581 null]
+947 0 obj <<
+/D [942 0 R /XYZ 85.0394 466.0581 null]
 >> endobj
 102 0 obj <<
-/D [937 0 R /XYZ 85.0394 237.1121 null]
+/D [942 0 R /XYZ 85.0394 237.1121 null]
 >> endobj
-943 0 obj <<
-/D [937 0 R /XYZ 85.0394 206.4074 null]
+948 0 obj <<
+/D [942 0 R /XYZ 85.0394 206.4074 null]
 >> endobj
-936 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+941 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-947 0 obj <<
+952 0 obj <<
 /Length 1859      
 /Filter /FlateDecode
 >>
@@ -2874,182 +2907,174 @@ d
 €¬SËþ‘.oBff¾ï¾¹¸<5û6íµ˜e5²#’ÛÛUæîÝ¿*Û
î–Ÿû–²*ÚÝùAJ§A¨k35FfH Ž]Õ®(ä¢Q%”E挄ڦR->‚‹Bá^ØÚؚȒœ—wº<Á6õ«
£Ak””yvog†A©KÐÞÂ0ÇÝ¥-s•á•Ö9ô•ý—ñÚŒÝÜŽÄ®›ª©¿aGªd&ØýºYÙÊ+@ëÚ¦Dà΅˜Ví©]™úkͺ*d²ÇF’ÖqÔÇí¨Zãhº*•BÃÑ«RÁrs‘4³D6Qš¸Tzät«>]¼Ñ³ƒŠS‰Ï¡Ä_ªÇ¿kaº+Ù:%D!â3ÚÞ*¨*'e•˜æhß1ò|Á,n½ž×Êrcrp…~æƒW	h_0åöt¹jR`và检ᖣî
 -”ªzå¡U$äÈ×™ÀìT·Ž¦C¿æ¶Ø‡CÅQ|L§ºÞÖßúÚßã…@ŠczÌ<xΣ<ìSRL ¡¾r©ï¡~ž!_´ýhûKS$ê_€ö7€b%«¨ÿ¤Ë*¦Ûd~÷O’Xr³1!Ä-ˬÞëÃ>·Nt3fk£¾ñóqÉÌz¸á…™g‹Î–©îBB°€Xñm&‰¬ã*ëðŽìá(3{iž¸’EÍuoªÐÓ趀hÆ*ÊSÕ©åi‘ÖÒÅE2±`,mÊÊvH¾ŒÔçœRÓj]Ê=ÑëûºQ™B‡‰í­æ:B[Õ˜“eƵw⊜¯oo»õŽzÑ)¶î)6ÑŠE‡œž—36h Øy²¨zî/ß­»ñ1!¤ö®h¹Ò¿ÎøÞÛŸÃÌÿ¿y¯cendstream
 endobj
-946 0 obj <<
+951 0 obj <<
 /Type /Page
-/Contents 947 0 R
-/Resources 945 0 R
+/Contents 952 0 R
+/Resources 950 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
-/Annots [ 952 0 R ]
+/Parent 949 0 R
+/Annots [ 957 0 R ]
 >> endobj
-952 0 obj <<
+957 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [55.6967 190.8043 126.3509 202.8639]
 /Subtype /Link
 /A << /S /GoTo /D (rrset_ordering) >>
 >> endobj
-948 0 obj <<
-/D [946 0 R /XYZ 56.6929 794.5015 null]
+953 0 obj <<
+/D [951 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 106 0 obj <<
-/D [946 0 R /XYZ 56.6929 480.2651 null]
+/D [951 0 R /XYZ 56.6929 480.2651 null]
 >> endobj
-949 0 obj <<
-/D [946 0 R /XYZ 56.6929 441.7923 null]
+954 0 obj <<
+/D [951 0 R /XYZ 56.6929 441.7923 null]
 >> endobj
-950 0 obj <<
-/D [946 0 R /XYZ 56.6929 373.7178 null]
+955 0 obj <<
+/D [951 0 R /XYZ 56.6929 373.7178 null]
 >> endobj
-951 0 obj <<
-/D [946 0 R /XYZ 56.6929 361.7627 null]
+956 0 obj <<
+/D [951 0 R /XYZ 56.6929 361.7627 null]
 >> endobj
 110 0 obj <<
-/D [946 0 R /XYZ 56.6929 167.4388 null]
+/D [951 0 R /XYZ 56.6929 167.4388 null]
 >> endobj
-953 0 obj <<
-/D [946 0 R /XYZ 56.6929 126.8733 null]
+958 0 obj <<
+/D [951 0 R /XYZ 56.6929 126.8733 null]
 >> endobj
 114 0 obj <<
-/D [946 0 R /XYZ 56.6929 126.8733 null]
+/D [951 0 R /XYZ 56.6929 126.8733 null]
 >> endobj
-954 0 obj <<
-/D [946 0 R /XYZ 56.6929 98.4089 null]
+959 0 obj <<
+/D [951 0 R /XYZ 56.6929 98.4089 null]
 >> endobj
-945 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+950 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F21 662 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-958 0 obj <<
-/Length 2706      
-/Filter /FlateDecode
->>
-stream
-xÚÕZÝsÛ¸÷_¡—NåéÅA°O—Ë%×ÜÌ%×ÄiÒÌ”– ‰w©);ÎôïÀ$EJÎø©ãàò·ËÅ~f3
-l¦SBE.gY.IJY:[ì®èl
Ï~ºbž&	DI—ꇛ«¿¾Ù,'¹âjv³ê`iBµf³›å§ùË¿¿øõæÕû넧t.Èu’*:ûâ—W¸ò¥éüŸâå»·¯ßüôñý‹ëLÎoÞ¼{{d4—ðæåwßýúêñ½ןo~¾zu¿¢û¥Œ
-û	\}úLgKøàŸ¯(¹Ng÷0¡„å9Ÿí®d*H*…+Û«Wÿˆ€§îÕ1Í¥B“TólDuœ©.͉\8ÕÙof„]'ŒR:ÿ±,ÖUÝ´å¿öæš16¯ëmc¿ðDήHγÜ!ÝlŒ'ê2e9¡)³²Zše¹b’äRhOóÝŠ$Z$Ø€€c(9*ã%á’Í‹j9Çaw¸–ž´j¶uýûq?‚)SÐ>Ë<áþpÍô¼^Š]ðBÏ·bì$ŸÛ-®.êÝÎ2v“mYµNŽtUp
èŽðÞÎþ8šÃCY­qV;ܘÃ94ÄJ8KÏ@ëvž1’§)êÀM[–++ÕÊp^VøÛ´[ƒC”õ±Ý[ƒP»¢%'6MaÁÑ”ÎÁ¸r6(éRM›`¤êE—g¯hÁÏóD#<{vAÁ¼”LûL­µ&œfóe½+œ†¨M¡ʺ‡kÜñ½S%ÌÿMS:fäR°6ñ
VH1Ë™·A¢µo7²›Ò¸]
-Ü5XÛoMëéëUhü’7h7vfqçjþÆoŠÆÛR
-’S¡ú¶ÔÞ×׉ DYšæo׉d|Þ”–)®—UkÅ¢-ïÌ#!Žœiˆ%ΰçðš³oRÀ=“øEöÉmÑ.6C¨ûMͳ8¶¦ÁYÑ…³ßAûò£{I›Ât ÀŸmÙx«wÚ³Þa@ÛÅ'ˆì)+cÕ'¿Øž>¯÷Ö\ã,¦iÊÛàt+4¦Îp»að-<·S„TÇ5xƒTD0H‡#ÞÀ •ÂxÌU¼@Šèbœú'£0–ê‘“ÕæǦX›I™„$"ÕêY2u00ãçc2ªàb‰+ûô=ºZÚu5‘­ÒÔ»FO$ë!E8¸­'û<ŒÊû5†ŠS Ɉ–"}JIžeÊ8ëIÚ‡½Á‚äœe©ŽBáWŽÉY@pÝÃ\l‹¦U)ÉR! Aå‚ä¶r颢‰ÀfŒd¢§¿Y"¤Ëø}‡ü”\Vn¹žf4®”?]”ßú–©Ú‹[öy$^Cl̉¤”Š¯Ç¼žzlŽ!Z„Ȉ˦Wœ¥ÚÁ}¢G[ünAÀæ‘ÄB{¼#Ô÷Þ¤‘AH`!.¡euæ«pô×!hîênëçÄní0J‹»¢Ü1îù×Kœß…ðÛQÉ©"8ªX~>ÃfD
-Üx"âÂ×dU“
-¨€©¾PÕt©¦«šHÕ­R»LmÈ“T©ó\#Õ[1ŒÂ–Å=¾Óe8“ü|ÍÁiŒ‡G(<ÊÖU¦éÜìöP3”×lþÕ4¸ä¬¾\D_ñJHºÎ`ɬ€SØJÓùžxiVÅqÛÚÍPµ¸º¨+0ë¶Á·nM{oL…6XÁ²-‹}õ"¡gR”‡Xƒ
-ˆöÆ)•ñÆY,—hÖMc‚Ñ݆ҷl½u®ŽÕšeá?Ýšo°£[o¡æKkª¥Y·n7g>‰ÞÔ'{J9¡
-vòI´‹1Ø#ÕÅÄ.sP.tIÏ‘©‹1Ø#U4MïIñr¹­ÍÍý]ˆøÉb,ð{-Cv›Ê<‡&r˜B’·ˇjY·“x±)€íEÀ‰ÄßÏ\ï_—ñÊ>î	IÎC¾„¼­‰Ê¹ì'îƒi¥ižŽ½»(îj[¬Ç>‚^¦ùOÆ‘+Ðzˆµ×4‚dyD¿X¡}[ÉØ/xšð¹ÿ¯Éu:;è4ÚûÓ²«ä™=j’ç³k—j:»Fªá™M/Ãr
ýlÆÏsŽTX3H¬LÃNò>=/Ò:çE¶ËNx&°Ÿ¶ƒÐO‹4ë÷Ðö!nªºJ:OmêÔ>ué±Qvon·õ}àµñ‹…˜&UN˜à|Ðã;‘2["BVwÝ,Ìü™Œ¼@s쩳ìÑfá™3[X+nk—JaxËÅ¡¬þ=kM~è?Pù’Õ¯"®Šíðí¸TàŠwXpNA{?&,„9ºðŒ\÷žÍßöÕŠ„^‰@ëÎa`ô¶Ä‘“ž‰`é·cãG>Û‹ 2˽OÌÑÅA³@ÌæƯœ‡c
-Ø¿±C_ñXgîUú“U„È8äAö¬*¢‹1]EDª‹U„P”¤\=ëÈ¢‹1]EDªž‹úÜáÙ„ñ©†Z
-"U·FNÚ:Y•á¹ßújÂhpôÿ"ŸÄ³C×ù<ž Œ¦*ï%‡¾gë<%ŒœQ¯±$Ϊ–¸p¿q•qN!Zà
-ž=­¶ámºKj
ðí1&Ú/L|)ŽoÌ:œ9{fغÂÈÕÀ¹+q—îsÄpÑ\£ˆ*VÆ–1å4ë¾ÀH‡.˜;ï…éæa)ŠüŸäÏþØÔÒ8gë‚7ú‡å%l$·èu$xpŽ¢«Në0b:Ä 3ãO@£A…™œ“ävNâ‘ài8ý„‘Øþb<²#T¨¹\yfvÉ»Âïc×cg=aÙª‡+·Tãï­b](°¶®dù•£Q7˜–†
þ¢šað¸åöig[\G¨ý
-:ºV_Ó…ýuͤ ÜÐ?:Ÿ‘‘ÄnÒªXø7ñ«˜9ªÖ^
-!-h¢è¾Þ®ÜšMqWÖN"{ÎõüÞ#-½UíiÏÁ–(†/‡ßÛíZG®Ì4Éd,Ï•@P2©,ôYþàüccƯá4Ð~Ù
­)–d,a"·­­²IŒ(Édç~“ûûÍË]Y*E¨žzljÝéØûáZÏÖÂÛâ!â¡ÀoÍ:^+ì‹CÛ¿ŽˆgPOCõ~T&8Vk3™ªÕ…Z»K5]kGªàËd±1‹ßÁW'%·J	Ôdùy"Õˆýý¦"1ï‹0y¨ÅTìHFÄ`kN2žóÓÛ\ßJÙW›Á¾4U[|îÉi=à¬OÆëg'™Cq•JãM åÛéK{Û«)Ï© ºÓU]¤ºXÕ1}Ž-•ž#Scºª‹Tc;ì‹»ß=}aŠ0jãÌÁ,Úo‡Ç’(ž²o½|Y•[3qðV¬9U݃1çÕÀ˜ªó®ûH3í¸žf ­¯ueNÝ6J2}Žu¤9áÝ×d.x—ù9‡Õ§:¬„OrØ"„Ѧ
#èXñ~åÔŸãiIL°¼ž¾M‰àìYwáÌí+ÒL»¡ßl‘û¯A#i¼\{ö =þc˜²Ðš 
-=Ï‚PVx–%ÿªt*úÿ(_Ñendstream
+963 0 obj <<
+/Length 2721      
+/Filter /FlateDecode
+>>
+stream
+xÚÕZÝsÛ¸÷_¡—NåéÅA°O—Ë%×ÜÌ%×ÄiÒÌ”– ‰w©);ÎôïÀ$EJÎø©ãàrw¹Øf3
+l¦SBE.gY.IJY:[ì®èl
Ï~ºbž&	DI—ꇛ«¿¾Ù,'¹âjv³êðÒ„jÍf7ËOó—ñëÍ«÷×	Oé\ë$UtþöÅ/¯påÛ]ÉTT
+V¶W®þvžºWÇ,—
+MRͳÓq6fº4'JpáLg¿™v0JéüDzXWuÓ–üÚ›kÆؼ®·ýRà':üè,áŠä<˧›ñD]¡,'4eVWK³,×#Œ˜$¹ÚÓ|7ÂE­Al@Á1.9*ã‘KÂ%›Õr„‡ÝáZzÒªÙÖõïÇýO™‚õYæ	÷‡k¦çõúPì`/ô¼p+ÆNòy±Ýâê¢Þí¬`7Ù–•ÁQëìèHWõ×€îï=àì£9<”ÕgU±óœs¸3‡†X
g	ãXÂÎ3Fò4åÁü¸iËreµZ™ÎË
+›öakpˆÚÁ >¶ûc‹cPjW´äħ)ì šÒ98WÎÆ£×%]ªiŒT§èÊÌá-øy™hDfÏ/(¸—’i_¨õÖ„Ól¾¬w…³Õ`)´AYWøp;¾w¦„ù¿iJÇœ\JÞ&¾ÁËCžeƒÂÛ ÑÎú·ÙMmܮƒí·¦õôõ*2hü’wh7vnyçjþÆ3Þ÷¥4§Bõ}©½¯¯A¨²4Íß®Éø¼)­P\/«ÖŠE[Þ™GB9×K
+œ7àÏá5çß.¥@x
+&ñ‹ì“Û¢]l†¬î7eX4_ÌâØšgE—ýÚ×Ã\Ú–A7
+üÙ–÷zg=¬]lq‚œ=ee¬ù£óÛÓçõÞºKã¹Ç|`'‹…išò6Ý
+i‡3ÜnÂ6c$=ûÍ!]Åïä§ä²qËõ´ q£üé¢þ6¶LÕ^ܲÏ#ùrcN$åP`Zp_u"õØC¶™—MÌ+#…‚*€j:?_(2"…Þ{_†¤Ó¿›Aî°åjD@	á	ÞUÝÅŒ}ë{ˆBýi
³3ï8Õÿu¸¿9wWw“`¿¤v¡Çd&.îŠr[Ä´éóc3D.˜w¿Ù»cšSƒÈ©bßbw‰÷ý&AQ*@S}u©¦AQ¤ê‚Ü®P›1%Uê¼ÔH5"Vòª°¨º'wÅ3ÉÏpÙ€ÆtzÜR¶ئs³Ûä(¯Ùü«ipÉM¹ˆ$0K¨Ù.„`É9¬@LÙLÓùžxiVÅqÛÚÍ€ Z\]Ô¸uÛà[·¦½7¦ÂGÄT°lQµ?Ž\ŠòªÐÑÁÞXŒSïœÅr‰nÝ4&8Ým@Îeë½su¬Ö-ÿéÖ}ƒÝz5_ZS-—r_¶›APwSH×Õ'qAJ9¡
+vò5¸ËcDª‹¸@æ`\8d=G§.i\©¢kbuHŠ—ËmuhnîïBÁHceH@ÜkŠãT	å9œA‡(y{}T˺äÏ´‘a{‘ánè¾Èï_—ù•;ÇÀ'ÔHÏòýK(ûš¨œË~Ý?˜öPšæé¼wÕ]m‹õØçCÒË4ò“q¤Æð]ÀXßqgîü!H–GîÞ·!Î>êà9XFÀçþ¿×éê ÓèïO«®’g¶S%ÏW×.ÕtuTÖO¯Âr
Çጟ—©.ˆfPX™†-œ”}ÚnpÚMöžðLàqÜÂq\¤YÿnâæÁ ª«¤óÔ–NíËY—ÏÙîÍí¶¾²6~ªÐˤÊ	œZN¥ÌBD¨êî03ß²‚‘8ÿãäYöè³ð̹-¬·µ+¥0¼ƒåâPÖGÿžõ&?ô¨íl‹;jßg£®%³¸™ƒ·üÓ½Y”–³Šó»
+#¿MÃ¥ìœôçS+`ÌŸ°ŽîÇ£µÃraÝaÒPo8?:_‘‘ÄnÒªXø7±‹ƒU¬Ukï”,Ñ@	t_oWnͦ¸+k§‘íÃs=¿÷œ–^‡ªö´ÈÛhKTÃÀá÷žo|bÊd„ˆç @&•…s–ï»lÌø-žÚoèéhhM±$£-3‘Û£­²EŒ(Édçz”ûëÑË]Y)E@O½"ÅÓéØûáVÐbámñ€xø­YÇ[‰}qhû·±gxʨ÷ðÓ¤2pÁ1¬ÍdF¨V°v—jkGªËd±1‹ßÁW'[¥0Y~^H5¢A¿)LÌû*L6µ˜Š'’5¼5'Ïùée°?JÙW›Á¾4U[|îÉ)pÞ'ãíµS†Lè¡8áJ¥ñ"‘òíô‘½,Ö”‰ç ¨.iT©.¢:Æàœc¡Òstêð˜Fu‘jl‡=¸ûíîëÙîSŒ€Së˜gfÑÖxñ8lH¢xʾõîfUnÍDã¼Xsªº
ƒ±àÕ ˜ªó¡ûH3¸žf`­¯ueNÃ6J2}Nt¤9‘Ý·T.xWø¹€Õ§¬„O
+Ø"¤Ñ¦
#Xñžå4žc·$Ø^nO_à¦Dpö¬«ÒÈáÌå-ÒL‡¡ßl‘ûŸE#i¼›{ö?0=þ_¸²Ðš; 
+=Ï‚RVy–5ÿétªúÿFn;endstream
 endobj
-957 0 obj <<
+962 0 obj <<
 /Type /Page
-/Contents 958 0 R
-/Resources 956 0 R
+/Contents 963 0 R
+/Resources 961 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
+/Parent 949 0 R
 >> endobj
-959 0 obj <<
-/D [957 0 R /XYZ 85.0394 794.5015 null]
+964 0 obj <<
+/D [962 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 118 0 obj <<
-/D [957 0 R /XYZ 85.0394 769.5949 null]
+/D [962 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-911 0 obj <<
-/D [957 0 R /XYZ 85.0394 749.3395 null]
+916 0 obj <<
+/D [962 0 R /XYZ 85.0394 749.3395 null]
 >> endobj
 122 0 obj <<
-/D [957 0 R /XYZ 85.0394 221.8894 null]
+/D [962 0 R /XYZ 85.0394 221.8894 null]
 >> endobj
-963 0 obj <<
-/D [957 0 R /XYZ 85.0394 197.4323 null]
+968 0 obj <<
+/D [962 0 R /XYZ 85.0394 197.4323 null]
 >> endobj
-956 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
+961 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F53 967 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-966 0 obj <<
-/Length 3396      
-/Filter /FlateDecode
->>
-stream
-xÚå[Ý“Û¶¿¿BoáÍX>‚lŸœÄN™Ú‰ïÒ´ãø'RwŒ%R©;Ë“?¾»ø"!’’'éL;é܃Àår±X,~Ø]àØ‚Â[È„$Ï*‹‰¤L.VÛ+º¸‡wß^1˳tLË!×W·W_¾j‘‘,áÉâv=•š¦lq[¼‹ä$Ðèõ󿿸^rI£›o¯¥Œþ?úùÍ÷/Þ>¿VqtûêÍë›ë¥¢Y}ý·çßß:ŽË2¾~óúå«oìå\¿¿ýîêÅ­Åp¤Œ
-¯WïÞÓEþ¥rñ”°,ã‹íU,‘±Ž²¹º¹úÁ¼ÕŸNY.–”HËÅRÄ$…þ§¸XB2‘HhO‰P 7K94dFÁEoül`ü”™erá¹Ðøu¾-‹åê¡\}øÔÔåõ2¡4z·,~ùõñ›÷îi…–úò¥iLÁ¼¡F(eµÉÛÖ0]òŒ¤©Ê,——×LÈF/ÀæÐíÝ„ÄÍKì.J,ª}¹êšýqB¨ŒIÂ%;ú4!f	甩Œ1’IɯôUþ™JZÝ×;4¬,°ÆŒ¤±pR™ƉJTlžò}=!…’¡«¦”u^m@+67Õéé ë?á ÇþüÓ¤£ð”(šÆ¡£ü§‡û™ŠN¬_«”áÐkÿ’˜wb$É”JœåªM‰€2!)V$åT

- —ÅX²PT¥Ôôcy–&rœMm1–irÍv
-º¡»gqF“êlÿži¬@`XXï4S,Ðà¦ÚV›|‘Qgñ/Ð;–„RæL}ËÏìÃ~Ò|Á[ôÐR¯ôo囧üØZqØîZCîJC3h¤USweÝyÝÌçæ±Ý•«êgJyY 
-‹%§1á	eΫ™õjÊ7¥ÙfÑûã®Zå›ÍѪÚüæ槨Ö×,ÖåL×@^7ûmÞ¡C“9÷HAÒKî1`šwÇ„ÚïëbuÚ£R„%2;Û£ã÷Ì',V"èñVÏBÊ#cmÓÙg½z Å¢"rm¨8Cš³ÙÚx‡ŒŽÆ~Q»q(Ä)A}<ü2#sgz¸ßç[C€ùkžZ£MçnmW:†b[ÕUÛísØùI»Ï”Æ(@;«Qmµ!,6»¤T8`Aã¨Y›ßÜü«*¢¶Ü?‚Û@á^¬8,¬zU®¯^½þÆ´2ŸM™'ƒ,8»`Øß©ß-ÚÃn×ì»Öê³Ù˜†¶6T¶y]´F=§·Ýë”N)”f$¦‰ƒÏi}–1ã„ŠƒºjSu¸¾ÀåÇU¹ë&:H ¶"È×üm—ﻉ®`ÿÉ’ØíÌ0¬I#BÉ“S‘ûrV(„ú™tö|†î@£§‡êšE«óñ“Eó”oZô"%¢ºé¬Âf„4½ªgœR
-uÖ˜HËÌïW_´Füê!¯ërc„o›¢çàõ¯ÖÆg1æK™„ wl¸ö×it˜RI(ˆüRyÁß84…Sû©êšƒEļ¶Úìpm´MíÛ§
-½Ñj»ÛäÇdm~oy[¶ýCÞ:´ÕËû/#¨…ä­˜0J(géHG†"ÆHìÒÏ…ÃÿQ+:£’Ĭ1åòûUŠ˜Ï<—Ÿ¶3‰äxÎ:ÿà[W÷S‰KB §¡c{1@¶7)‘ó˜ŸJÜ]”ˆKi*ØÂd/ïxQÞ‡r*íaþÊ,ùìÔ"éTì˜Î2ö¹QèA:¾¶l„÷Sp+Ò	…Ž"Yšõ;ö$²ÄÇÇAÇ!*"8w#­ì46Öæ×ì²~qVõýhy:O–’â^vÁÛ{&íìq:åì–Iûz¹iòbƒ!âPï\§žiÔkÀwqœÄA·oM·zè°€0š¼?¸xÀÄ”}|‰Ö
Œ`[2k sX
-ÓxÞB®3&r\¡À	ålöÖgTÈ M~7!E»òD]%®¿Y1nEk˜oó®+·;=7ÜçÙœžÈ\ƒ}¬ZOÕfr­z8sÑ¿…µOe=‹_°0ˆL“ô<~
¹æñËsµò§yô
-å²ÿ+àåbÔ³í#Ù‘I§#ÙÀ¦/êüN;a’öØÅ“Ìx$sóØÏ»!÷^/-–‰$ÑX†ïë¦e(•ŒXæ L¤$NéÉ©d5À2å±L9,S¡.ðì±M
±
kô86làíÙRø-+W°0ÄÆ0a6Ô2;(ªöó)hÓPÉ´¹4ª!4q6Ø€¡ß@à!_k0CfÔÁÖCnàѦìôP%—Ñs÷×[üØ-x++“6²ˆS–S8à¦XÒo5<=Íð»iim\tWº£Ç›Y¬àx¤’±Îk+<—V½éªõñÿ*ß=kË%FÆœF‰Àšo˶tŒ×on_½üWP£mçÒ ³¹ÇÒ·˜¹šÓÏý€ëÌÜ;.“ûôõÌ "Ósz¡gÏ5î:¬	‰˜Äxg(èÛWDâN-“‰êýöm)@£ÿ¸gÐ
n†"sç¥IT4–«±„ªà¹üXµ]Uß÷2†½¶ö„€‚›Ç<„ªÒ$3YUˆåYŠã8ÊCþXš‰­4¶ÊÄa+~Óš÷k
 ¦6ÔÜÖÀq]’NâÄŸÒKVåƒôÕŸ?==8}AOÿ™Ýp€œ›ÇÙô‰PëÃöÎ(˜b%Ó'1Ölyˆ‚n{ÑЦ÷ŽðD#lª¢=ñüº,]}ÈBdùÐÔ…S}>Øz¿[
ê†]µuŽj¬eìTί/Ê^’µ…!×™õå¸tm¿Ë»v\ne°—+y¾[Ï5î7\\,W:þ	óæ}ÕY[ø-Û züª
­î
wÊ`¬7k<¼(F»°1
¹æç¹p¿ÊýqÓ̃ÓÙž{pu=
NA߷ךû{é0etÁ&¬ \`ÁxôÃè…ù`…©6á’Î’˜¶,Ñ~\~ÜmªUÕmŽ†^Tf®:+2uyÔ	œB÷¶«J{'VLyïﮣÇùá~Ëì/‡Le!2fOT' øúãu}3Ä^K™€1EX*]…ÄÙoB¦°ñ'a-¥±‚
 ž8ņwmnt¢N`¥9Ñz[©8+þzÌúØk5Ô^q’òÔ}ª=ÄFëBé}îd»@WÖêX¶%|Äüù¶»S3k¹8KümJ{|<-‚™‘å`NZNÆ<þËÉ¢éŒ<x†¦’5ü!×xp\úJæa»+îÜ)&¤<¿-Wùê¡üm‰Èÿ~>ý…؎婃IÍL™ˆ*/Ül»JÑõ\㑆óEìØìd¨ßÀP¯—,³ 
‡èóxËIzô¶ˆŠr6¹„Dˆ¾DǶÙû+_"f'•Óm¡ÐJœžÖ#Ùá•2M@·˜ô2j’ÞA6dŒ?,›>f£—BiA–æëٙÌIz¨äÂAá€iÞÿ“ÙÚ›?’yƒŒFd*=Û¹gõîP1ÍXÐýî^ÐÔ•éÒÁÝ)ÌU¹ˆ¶ù¼…£÷šEíÁ
¹õÝlØ}F_ÓÃçA-0µuJÓÉß÷†Ðçâ4õÕ5l7{‹‚€=`Ü_ýó%^×gÃ3Áö¾íÌ›bçÂе2WO‚¯ÑEèú…Žÿ†œ¾FŠT{–¬ãYíƒÀ°Ü™wÚó°[çy`3÷FÀ/,ƒ½A·*Ûvî_`Fñÿ&f›úëøßúÿÆÀ{i:wT§°fB¬Rh~–Œ¯^RXý	ŸPýßz7endstream
+971 0 obj <<
+/Length 3428      
+/Filter /FlateDecode
+>>
+stream
+xÚå[Ý“Û¶¿¿BoáÍX>H€lŸœÄN™Ú‰ïÒ´ãø'RwŒ%R©;Ë“?¾»ø"!’’'éL;éÜh±X,?ì.plAá-IdƳ…Êb’P–,VÛ+º¸‡ß¾½b–f鈖Cª¯n¯¾|)Ô"#™ärq»ðJ	MS¶¸-ÞE‚r
hôúùß_\/yB£›o¯“$ú|týÍ÷/Þ>¿VqtûêÍë›ë¥¢Y}ý·çßß:ŠË<¾~óúå«oìù\¿¿ýîêÅ­ŸÅp¦Œ
+œÂ¯WïÞÓEþ¥Éâ	*”°,ã‹íUœ’ÄB¸–ÍÕÍÕžáàWÝuJsqBI’ÄÉb)b’ÂøSTL’LÈÊS,ÈÍR…$#RpÑ+?(?e$ɲdá©Pùu¾-‹åê¡\}øÔÔåõRR½[¿üúøÍ{W[¡¦¾|™ˆ7¦`ÝP"ä²Úämkˆ‚!yFÒTe–Êók&ø‰fŸ8†Í¡Ûº	Ž!™çØ]äXTûrÕ5ûãÓ$&’'ì”éÓSX%\S¦KÆH–$ü÷rÿpQäŸiB«ûºÙ—†”ÅÒ˜‘4Žë/Ì8QRÅ–à)ß×\¸ šúgrYçÕ¤bsKžN²þNrlÏ?M
+O‰¢iÊzºŸ)èÄþµB
+½÷/±y7Á&!™RÒi®Ú”(œbERNÕP zQŒÉ…¢	QJMŸ1–f9 Ò(ÇÙÔc‰ ×lw  ›êpxg„±DßûfŠÜTÛj“ïá IÔYüäŽB)sª>åg¶ÃpœT‚-xÞZjæ•þÆQ¾yÊ­i+Û]kš»‡Ò´´Ç¦USweÝyÙLwSmwåªú™R^(ÂbÉiL¸¤ÌY5³VMù¦4Ç,ZxwÜU«|³9š¦ª6ßÜ|Šj}ÍÒh]îñc††æu³ßæ4™3)I/™Ç€hÞ<J¿¯‹ÕéˆJ&“ì숎f¼¯-€¯Ë3%.Ø€êŒ-8*càÔíÚÁÁHñŸýS˜Ì=ã°;Ï*ÔS5š((Ã$X Ò·½JÏ.¶µ	HnOh·9D¢6œ³	A‰Hx|Á&TglÂQéD×¾,?¹dùŸ%&`"6,;¯TO5Öjhà5CPÈCµÞÚ]‰Ç»qtØyW¶¦‚yaÒRø)Žu¾­V¦b`a™HŽ›nª›þ'Sª,#ÐZÚT¸ ±8ME˜lÆ©™@kÓ9˜Ä„þ<5<[ÛæÃV¨´Fø²ÀÌ‹ÁcÔ~^)	Xm}È-§²¨:Ûlò&ItWšŸ¶yQ1	¹Ô§í TcºSl8†¦Fw¨H0л#~*
bn«7¨"”VB¨Ûb|ci•Z­~,C€|o*Lgó°Ñ&9hôKsØ×ùÆTœ«†”eug	Û#½•
+€¿±T65DÃu°û{ɹóù¸ËCñÁ˜Xñî!”µ¾€òÎÖ]†íQ/Žü|c»y+Šцé›w]¹Ýéµá>Îæô„çôcÅzz¨6““ðhÕÙóþ-¬}*ëYü‚A’T¦çñkH5_žÊˆ•?Í£Wˆ(È‘ý_/磞ÕhïÉŽT:íÉ:}QçwÚeÚc—™±HhÌMµ_wÓÜ[!üh±LH©±¯›þ'ÓRYƈeÊDJ┞ÜJV,SË”Ã2Êumjˆm˜£Ç¹idkwÈ–zŒÀ6E¬\ÂÂ46†Ð0³®þØá™óС¨ÚϦ MCÓ–åÒˆ†ÐÄÙà\‚þJ¾Ö`"†`›K¹e€wD›²ÓSMx=wݸ>zàc ­,kÜLZÉ"FLYNá€[â„l#Èáée†ï¦¤µ~Ñ]éŒof±‚ã}’|!Õ~Œó’\pKK3LYšÂWÿôôàä9=ügöÀæÜT7ælÐ7
+ÐZ¶wFÀ3™æšXƘ³å!
+ºãEC›>;Âü±©ŠöÄòë²tù!‘åG@SçNõñ`Sèón5ÈvÕÖ
8ʱ„±K9¿¿(x‘rCª3ûËQéÜ~—wí8ÝÊà,WÉùa=ÕxÜps1	¦üÆÍûª³ºðG6–A&´øUjÝ+î”ÀhoVyøPŒ
+vá`RÍ+ÏSá~=”û㦙§³#÷à4zœ‚±o¯35÷÷:ÒaÊÈ‚EØÐpãÑ£L‡ndlµ4é(‰ygË6ÚÎåÇݦZUÝæhÚ‹ÊlÐUgY¦.Ž:‚Shâ^wUiß„ÀŽ)ïýÛµ`ö¸>Ü™ýã©»l"Dæ¯Áìêä]½®_†Øg)0¦K—!qú›à©lüMX‹Ji,cH§÷@N ±á[‚ÝkÉ	ì4ÇZËÀWÅ?Y{©†Ò+NRžº®ÚB¬·.”>çNŽ4e½¡ŽeûשYB'æï·Ý›šYÍÅ™ô¯)íõñ4OpfFš3€9©¹$æñçh.ÉÀëIœ’çáïД¼ÃRG¥Ÿd¶»âÎÝbBÈóÛr•¯Êß–ˆüïçÃ_ðíˆP~’Ú™ÔÄ„	¯òÂË6°«½0QO5ži¸^TÁ‰ÍN¦ú
LõzÉ2ÒXpˆ0¯°IÏÞ–ñQQ®óæ3/€°|§/ѱlNÇþÉ—ˆÙIfãôX(´§·ucOvø¤L7 ‚[z5Aï 2ʦMÝŸY¯Á…Pš‘móî‹•ìLä¤=”¼pQ8 š·?GdŽöfç¯äGVÁ ¢™JÏî‰F£‡'TLÁ^3£‡4uiºtðv
+cU.¢mþ_áèóƒfQ{pJCjýööœÑÏô°>Ȧ6Oi†1ñûáþÁ4ô±8M}v
ËÍÞ¢ `(7ÁWÿ|ù-p€À
+.ø¾í°"£|ç´£²L9»W>kè:mŒÅ+íÿagOés¤X±wÉàÃrûêçôq„8ÃÇf›»W'®Ä—Rnù‘õÉÊÓ÷ˆö–
+ž}NÁ4…PÒ¿úÂr¶/öVeÛÎý+XþÿÁ„uQÿüâÿ›CÿßøÎ!Mç®樀‰
+§Âäø©'jDò	Ñÿ
Â"3¶endstream
 endobj
-965 0 obj <<
+970 0 obj <<
 /Type /Page
-/Contents 966 0 R
-/Resources 964 0 R
+/Contents 971 0 R
+/Resources 969 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
+/Parent 949 0 R
 >> endobj
-967 0 obj <<
-/D [965 0 R /XYZ 56.6929 794.5015 null]
+972 0 obj <<
+/D [970 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-964 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F53 962 0 R /F14 685 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F55 970 0 R >>
+969 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F53 967 0 R /F14 689 0 R /F21 662 0 R /F23 686 0 R /F48 890 0 R /F55 975 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-973 0 obj <<
-/Length 3750      
-/Filter /FlateDecode
->>
-stream
-xÚ­ksã¶ñ»…¿Už9ñð$ÁöÓå’K.3½¤wîc&Éth’¶Ø£HG¤Îqû绋@R‚$OÓñx‚‹ÝÅbß ¿fðǯN˜ÌÕu–«D3®¯Ëí»~€wß^q³ö@ë9ÔW·W¯ßÉì:OòT¤×·÷3\&aÆðëÛê§ÕÛïÞüxûÍÇ›µÐl%“›µNÙêÛ?C3Ÿà•Ö«¿yˆ·?|x÷þÛ¿~|s“©Õíû>ܬ3–+Xyyí?~3­ûtóËí÷Wß܆]ÌwÊ™Ä-üzõÓ/캂
Å™}ý,áy.®·WJËD+)ýL{õéê/áì­]“œ–&ÑFdÑ	9—<1©4יΓTÂ;”]SݬejVÍ@¿»nVõ¸ßuuÒHS½ºÝø—EÛöO~ÜÑoýÛXﺢŧ|õh×÷e=8°±§ßª°mÓÕôø´©Ýú®ØÖŽ‡MQ–²ß>¶° BÃ.ל'¹ÖÂr<ŒýãcÓ=$‡ÒçLÁfUvñ,‘"Ï£â
-Pë9˜—2sq1«tB†´7E;‚P[ý´~üåˆT&™Ròê˜åy¥&É„>ààìTQÈÕ¸©q VC½ûRïh²Ù‚4›b¬ÛçÎù
-ŽP2¾úX—u7H¹)º‡ú†¯zÞUí1Òéí64Q=Ãé4%‘Ù?V€—^ôŽÜû¼ûhÏŽ
”‹›åQ¤MÀ׫®i0_ì‰ÃÐjW´œØÈ{ÁñÏŒ‰¶^Á“ä«»½[þÔ´-îÜ"âºm=Öû~÷D¤+BO[GÔûW¿wš;Qs4H=ðB	Éå™ç©5‘;6êa,v£µ¥²Õû{z·~\ÂuÙ Iä_X3øÃ@+B𦊑
-VŠ”ÈJñeq³æ«˜Œס±âo0Öˆ]-‰‚¯ÃÃÁß™éâ#ÉGÎtqhM“éºùvZŒûሰÉ!?OØC>°`p„9î‚ò×ÍðØ*˜ðlØqYó)")"ˆ+ÁD@­>ô£{5nŠÑÜT·ßÞÙäP*±ú7„"‡½éÊv_ù§°ªé¦ÜØçóè¡2t@ÂéÝ]ÓU¯ß~ççû„42Å!–©	÷î»:P…ª¾/ö•SÍ``>f%¯ßˆP„§¯Цñ{"ÙÜŠ>µÓNïlZ{:²þöGX˾ÃôïaO8«3š«3p?æR53;£¹
-w»«Ëýn@ß~ª9O;2G´ã…Ì‚ø×ûíãÁQ¶ÍàäÔ;™ÿº¯w÷³tÓø'ùucû<xؘˢ*R40’å)°n ž”Ê¿Dß̤›³ÃmQ€‰tM¶6žÆ¯ûÆ”(ŠËP,k‚(lK ÞH!nÆ
¨(ïÏpÒ)öðºq©-lÌ®ŒT#UóÐŒXÈ	¶ÞDÛWÖwËÔ:è-†
™RbŠs£yÀÊ+P[A€Ü6m±sË{¤x„3ý}Ì•i°`Åù¬rªN9d£y™à×°×¾ô-P§€>£Þw‘i‹ûSp’§ùa÷ÔKØiv"VAÊ•3¾ðªC„U‰$¡ã”o*ó)tÜ
-9dì,Ë^ŠÄ¥:^D×܃a¦±Í„¿šÍ‚0ë*Ž6M¹!}¦É‰7xØÖEçÐ{¤wž|HãÐÑòÜ%?ÙSWÜæWhÓl\0€QVr˜u…J3L›@Š0&ti°ÑÃÓyª/+e–9ð†…«\m¬kÍÃeE]ÓcÙû¡þuèYÂSáµÁ%€ë“Š˜büaçB?Àw"F‰DCñ3sŒÆ•âδmõ±ß1´*ÉŒò,$1éMH<6çY 2N³ÃËš“òÀÖMžúäe,>Ûªê‚~6½-Û`äú6\ЂT•+Düûø°w'Š3¶¦€>:x§Üw1°¾ò—.<Ô0KéŽîøå±()êã-à‘»>âØ×~wY¬‡©jÎÌBÑ ”Ë;õ¼Ê©è
AhŸÃ*[º&††Xàúû‡9=øvñ2
÷ÊŒ88­ô;ðÛQ•Aõ
-Í““Ô¡ÄäŽÅE‘&à8ÅäZPß4¾³æ?ƒÁÎ4ùß…JE:séê±Ø
6]S©OÒ`T”eý8ºq÷Lƒ ¶JSF¡|‰¤ÒÔQ¹*
-ßxá ¨ìè:@¨²^àsÄþGËØl‹r½­tü<Œ…ƒS=ûŒ×½Î]R`ñf?‹	Zç®5guã,¼î«b¨×©CZwe_ùû ?bíÚY¤ÿøî­ûTR+ãoF°m-^¡
Þ7™KÀ¡Ô{l*¦rTMS˜†çy.	ó{w“#Ù‰eo™³\ž·P“˜\Ë8G®ðžxY\˜BUæïØ…h…Í´¤ü…µ8@–†Î²
\‚Ï— ®%þbàÌ•[8Ay=ŽlA¦r?euQ6&1ƒý‹ì‰É¦´uÙ˜UkX·†ƒ³E8¤I,TO'½¨aê|h­@°Y¶Ñ'²}>
+stream
+xÚ­[m“Û¶þ~¿Bߪ›±h¼‘ÚOŽc'—™:©}}™I2Å“XS¤"R¾\û绋 R‚¤KÓñx‚,°Ø·gÁã3ÿøL§	“FÍr£’”ñtVnnØlï¾¹áŽfá‰cª¯îo^¿—ùÌ$&Ùìþq4—N˜Ö|v¿üqþöÛ7?Ü¿ûx»)›Ëäv‘flþáÍŸßQÏ'x•¦ó¿yŠ·ßx÷Í_?¾¹ÍÕüþîû·‹œ#¯ýþ‡w‡qŸn¾ÿîæÝ}ØÅx§œIÜÂ/7?þÌfKØðw7,‘F§³'x`	7FÌ67*•Iª¤ô=Íͧ›¿„	GoíИäR©“T‹<":!G¢ã’':“z–§&É$¼CÙÕËÛ…ÌÔ¼îñ7ïn¹žWÃ~×VKF–ÊùýÚ¿,š¦{êi@ÑR_õëPíÚ¢¡Þ­ß•UïȆŽÈ–m궢î§uÕ¢ô`|´FÉÒ„ç\ÁÎpqm±©–Žl¼©’L¨ÌQ­·‡²Ûlàc‡ÌRš$7ÙlÁybÒTXâ~è¶Ûº]%ÇgÇ™‚ùU>ËyžHaLTØj1&³ÂVz,lmXa ¢…6ˆ”±ù‹íÏ'Èd’+%¯,ÀS.`zÚ™Nr‘­àìYÈù°®°!æ}µûRí¨³Þ€¼ëb¨šç[Îù@2>ÿX•U;I¹.ÚUuËç==oŠeåg¤³ß¯ÖÔ±|†ó«Kb³ß.a^zÑ9vwÿxÿÑUªÉõô¨
+ÒEXOçm7P£/¾TKjZÝâŠö‚›¢p/Øþ‰1ÑTý+x’|þ°wßꦡփD«n?ëc·{"ÖKšþ‘(6Ž©gö¯nïôþÀÍñ@åĸAæwF+È<7ÖðD®áõC±¬åI“ÍïIù¥,¹NYî”±ØWI.¹£ fÞo«²Æu“[^ŠÎ!—×%ÆHoxp3OŒ÷‚NåtoÁ©àÖÈ© ‘w*HXÜ.ø¼¥vp,VC¸‰RâÈš§œÁ?£JàïÈÝàãwÃO„¼êmd¢´’coƒs¼}Dã¾èW21繸âWÆdçýJ Â%
»¢¬Nø‚÷Óà¯ðõT§|4
+´ŽƒÔ'ŒïÚ’ŽvCþ`íDN:ÞûãxدV zlª/UC͇gúíÚê‚èKòüšàѱÍDh¯ß§éø´S0è¡Ó¦•¯+O“Ì@œ¿´.Os¼®©X5K2ÍôxaŸª¡ÊÒE6wQ¢Þ0@ãoõ붩ËÚÏ—¢Ù_tjX¢„ÐWd=&;/í@e­«‹«)èS®
¿ÂÙSržÊ3Í@ŒLMYÿ¿$Ê.È-c	Ë!Ü^‘Ûˆì‚Ü<.þ±Ù÷ë³Æ}™o0î¾qãž0~Œ«®,Êõ%•†	­®‰fDvA4ž*ˆ½vÄŒA„ÖfäÚO*Â!Á¾²@OuºÀ©
d®";Za\†«úKåŒÓ.̶YÆï”·2&‘š_‹3c²óòT”;þ?a¬Àcr@—{ªSÆGŽÐ€áN8]÷Û¦ÀPÁ„_†mwøëÓYÒY$P݇np¯†u1ø–ëj÷››ˆÁ4•˜ÿB‘›½nËf¿ôOaTÝ2“c£rt@ÂéÝCÝ._¿ý6’T@Ê›a€Ó„™{÷½ÙY×>bXÖ£O½m·Ó;›‚Ÿ,¤¿Ýɬe×bÖ¹ÚӜ˚›æà~ô5ä5&» ¹ž
+w»«Êý®Gß~t]æ@×	ï8èš0ÿz¿ÙeS÷NN“ù/ûjWW},Ie:1Úèß”¥ú3ƒm“ØÛ¡yS‡K¾ʲƒ„8• d®iÁ•7²ëñACÝ!ÂÑÜ@ƒME¶R =“_öµ;t€aŠË9°,+¢(,ƒ!Goöm]†I!]¯‡5µm•÷ƒØé™{xÝ8Ô‚7 ³##ˆkY¯êÁšà#êU.Ä!.ì“Þ9À[ê¶Ò‚~\öôد*]º©*—¯°#sfk'<Ú߶£×OÖ›AÇà:”ùR/Ý¿"9bBo:;·_v;Ý/ù’ `Z¸:=DbO«KŠ,Xq>ÎSÎ9äÔ yéà°W£…éàN}Ľk1$Ó÷;§,à%ÏÌq‰Ô+RXüY~&XA®fŸxÕ>~× Ã¦b~pŸÊ}î·B©>Ëó—NârhùUãÉ0ՈئI”	ÑÂ!˜Ø\ XBù#8È#(9(Tž$x‡ÏêP—Ç—O”¥@«èû®ÄË—J¦µ0r=(PélšÓè×Ó›á/‘æ£J"ôº€Š­u]®‰HŸ©ó°6xØTEë¦÷“>xö!CGËË~€²£Ò¿M°€Ðæç8`, £´ä8í
+	SL›@Š0$tj°ÑÃKM–^WÊ<2rX"^9_[×jÂLUÑcÙû¾êÿuèyÂ3áµÁe€‹³Š˜aüa—B?šïLŒI
+¨iä˜:£ÜwÛö³n»Ý›V%¹V~	IÌ@zÒ?›ó,©³üøFê¬<„½iôÉËP|¶°OA?ëÎâ=h¹‚t†$Ë¥C"~Œ}\í݉bР­£wÚÈ}ù–¿Yâ@@/¥cØzptà—‡¢¤¨ùã꺈c_øÝMd±èϤª†é‰þ¢A(—w¦c˜³¤7D‘úÖ^ãn\õ#…Xà.Ž5rzðíâeî•iqt<©ò<ÓP‡K 'ÜŸ­gÁg·zpcÇÇä …UÖY&¦>ÏŽÌÓqòˆ6Ó‚ß"¦™ qÆ™ b©ò–‚˜À¥~¡ÝäI*¤ç}@4n$2hØáÔÕÑ/yäÈYáR±*Ï® ÐÚÀwÝí')PÖ0z°ªš§NUñ–_CpM/iq£êÕ¨èê¹j
+ǬÆ9º›ÂcÁ¨ªB{ö‚ÐͳàÙ§§…ÁrcÉéÎÄ÷ìšf¸U‘è eОú!5‡Jç(à"†Eõ5²ÐT‘ê­á^ÿ5Yæ‡Õ¢´œÊ&‚I\¾ ÎƒÓeæwƒÛlÿ^ïW4Pêgô„«Á;ÙeÙÛ}î>4`gIÀ¢ŒeüÚ‘äŒEŽÄr‹áa0C“‡šîoȦqÓ†;D‹‡=¹¤†ÆNÊ¥p~™6—=
@"&•¨—Ñc‡÷ôÕáFì-SzÆ…¿ò€Xƒ
è©sôYœÐóÍÞIáÊ)Â~€?_ŠÆ~QÍe·)¬9Míjeþ³3·õh m«Ê
¢¬ç+‡}ÑØÒވ˺lT®ñÌÿDe°a½·BJ¿Ž~Ø‘šÂà¦þ\Å2ÀŸ„P1«Äh.¬äøFOÉTÍðC`Æ_òñ˜€YµŽ:¶3.ÆSF
+æ
+à¬\È.¨1(¥i¢Ý뤪TУ?0E‡äŠUqfÐ}_õgkѧþP¶‹Þü©£žKy.L•©	ͪۿÙD˜ªp_0ª³XK¦"¤©bUdà „8Ø'JãïëÚ×äüWBXÔ&Ï=Q©HM/›o‹]o=•ùôZEYVÛÁµÛgjµU)å"ʃ+•'›Êá/|ã…ƒF ò“« !L>™Ï1û-c½)ÊÅf™ÆÏC‹9œêÙïn¼îµî‚aŸý'h»I!ÎQbP¸QŠ¾ZdnÒª-»¥ÿ²'ȉûX¡w”#||ÿÖ}‡š*í¢;f…L¼$¶k¼âÒ×r	M™FìA²ïÉQÔMžÇY(ôïÝ-<ÝìÅvnäeÕ‰6©Œ¯ÈAöÃZ&w´€çüÕ»«°Ì€–d^ˆÊÀ²LŒ¯Ä¤àã¸%\Ü‚_Œ[‚9 †„°e+ËHrjø°g34•ü)¡Î	ï('fV­±aÝ6.ÂwH°XÀ]g½¨fêrñh¡@°y>
Ñgpž9„ŒƒWË4?#PØìÿŸI2~¦ê§£ÍÂÆAI¬­ÝÒU£ýÄ2÷%Mh¸cÊ]µóðÊå´¶§£Ž7†rZìqü\o!ÑìKº…´Sºrì6­ãe |¹» »,* ·3â…¤K2cŽäq¸uB—å:\Ž>úRÉŠìñùæŒ8MsxˆO:½zk>çÑ•“Cg£œ@¬±ÍäÉgJ[è?¸Å7Ž¸ÀO+7¯ÛzS4ç®· 3ÜjŒºû%c÷F3I°f¤¡EÐJûm6
+àŸáé?ç¾ñ—i‚æGªüðß)Çïþþÿðg˜Žh}æ£É2ò8nQ¸ž¯<ü¡ÀéÒÿÃÅaêendstream
 endobj
-972 0 obj <<
+977 0 obj <<
 /Type /Page
-/Contents 973 0 R
-/Resources 971 0 R
+/Contents 978 0 R
+/Resources 976 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
-/Annots [ 975 0 R ]
+/Parent 949 0 R
+/Annots [ 980 0 R ]
 >> endobj
-975 0 obj <<
+980 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [120.1376 365.8002 176.3563 375.0156]
 /Subtype /Link
 /A << /S /GoTo /D (controls_statement_definition_and_usage) >>
 >> endobj
-974 0 obj <<
-/D [972 0 R /XYZ 85.0394 794.5015 null]
+979 0 obj <<
+/D [977 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-971 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F48 885 0 R /F55 970 0 R /F21 658 0 R /F39 863 0 R >>
+976 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F48 890 0 R /F39 868 0 R /F55 975 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-979 0 obj <<
+984 0 obj <<
 /Length 1632      
 /Filter /FlateDecode
 >>
@@ -3061,75 +3086,77 @@ x
 ‹¨„¦ͳÒcZ0D¥ê„o,qç«xi-Üæ…	†—Ÿ²2‡wv-±é²±/DàbèÌ}Eú²ä½Û¶[C&ú­…»j
yÏ°vÌ2F‹º²x1&PD‰ÜÎè4¯oŠØxL¨+„ÁaVÖùú¦*Sƒç>Œ„`2wþôi¹ï8SЩu'8dnk2n¬MpÞ>*³¶™À£¶¬Á“8Ý<ð`†Tv475.½D¤äªgR‹ßaÑd«2nòOÄ®Ðr,dýˆÊh;³­£¦’uYjkŸjrú˜Öîc‹šîãÜB`>s©¾¾qƒ„)DBë!™ü	Å!­	a»\j«@eå.«4¿¾óXSPU5å]PD…èDã¦o㨭Gšj„	b€G„`Ñßé$„ËÜjóy{ÙfJl„tD¢vÓQ¶jâ¼Å›Œ/N§¿ØQíöÄö}ž»ëé:¥í:¥Y®ìŽ&þØ­ÞdInLì‘?šŠæ)Á
 q†£>ÛÛËÚm'Pû#%†i‰"ÍÈCº	kß3øN?ù¶]ƒk˽Ø}t¹a‡óNCëÎ2ÅÕ·³-5ERIÅNC1Š,cϧ'/.Þì‚D$!ÁY0Pø÷\ì5îû¸CˆIŒ-'ûëÛô†ô¸/A®¥¾LÔ‚H~C-èêÍæêºãJC:Äu¶G¶®7„èǃ‘i†$–ãæMõ_e/}LöB_÷ öúJ¸eH¬;úÎŽÏ^ÝÏßÊG#ðž›~ý|0ƒ“"ëêdßF;þeäÍý{´“þ¿9&0RÚõ—9&"—´ãØôtv?Åb{^ú)6tó Ø£ô¿B1Ç’¸ÁMQnùÛûï©HjÌÌ2¼ÏQ‹Ä®¾ÊÚ‡~–Ü|­…k3SŠúùop;b4€«¨ÑeØ@ÔÞGÓîû¥“¸þ¸¸:‰endstream
 endobj
-978 0 obj <<
+983 0 obj <<
 /Type /Page
-/Contents 979 0 R
-/Resources 977 0 R
+/Contents 984 0 R
+/Resources 982 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
+/Parent 949 0 R
 >> endobj
-980 0 obj <<
-/D [978 0 R /XYZ 56.6929 794.5015 null]
+985 0 obj <<
+/D [983 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 126 0 obj <<
-/D [978 0 R /XYZ 56.6929 466.6686 null]
+/D [983 0 R /XYZ 56.6929 466.6686 null]
 >> endobj
-981 0 obj <<
-/D [978 0 R /XYZ 56.6929 439.3642 null]
+986 0 obj <<
+/D [983 0 R /XYZ 56.6929 439.3642 null]
 >> endobj
-982 0 obj <<
-/D [978 0 R /XYZ 56.6929 409.8468 null]
+987 0 obj <<
+/D [983 0 R /XYZ 56.6929 409.8468 null]
 >> endobj
-983 0 obj <<
-/D [978 0 R /XYZ 56.6929 397.8916 null]
+988 0 obj <<
+/D [983 0 R /XYZ 56.6929 397.8916 null]
 >> endobj
-977 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F48 885 0 R /F21 658 0 R >>
+982 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R /F48 890 0 R /F21 662 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-987 0 obj <<
-/Length 2297      
+992 0 obj <<
+/Length 2336      
 /Filter /FlateDecode
 >>
 stream
-xڥ˒۸ñ>_¡[¨*K<ÉiãÇ–÷0®x&‡Ôz’šáš"µ"egüõéF7(JâØ©ÚR•ØF¿r•ÂO®ŠL¤Ú™UîŒÈR™­ÊÝMºz„µ_n$ã˜L‹Ìh
ƒ…ÕM¦‘*_mæDþyóÓ;%W*Öªlu¿Î²9lÐnu_ý–¼~òû±>¬7*K³þýþWÚeD^äw¥p‚²°6lø¹ú⻲®hÇ›Û;ÞÕ~<êa¢ ÐÆ*¦`™Í×™¦irÛÍö™·è•Î*Ë;”ʦEØNÑÚ&·îß¿ûÁÍ€ß<ñ4ÜÕå“ïšaGÃñɼ޶ýבü.‹ðP¾Ô^{Bîˆ#&Q7·õ_ê«myÒoi~¬/hy¼^EJá²L…«|ë»úo€¨t–T~ôpÓ,yßÑÔa-‹¤ö}7Ô4ƒÔðë'ÉžÄ$•Zæ‚´Y:×â4RX£sFÛ†Cú]¤>Q2Ó×¹I^áD’à’‚_›¶%¨|ªËÏçÌuä>¨¡fä[£ôšžïD!m¤Í[°Ü3aѹ`](5‚Pëø–Êã„Ö4q¢ßU¯xã–¾ á8Ó5cãG¦ã/O¾¶$1©²Zä	ïz´Ž4Ov=q@£¦Ûö‡8áúãH ò‚3¸³2ùԨЩRŒöŠHQ#$‚@Uå¡ÙŸVÊKF”Š\Êxz÷’Oj@Ó“õ3úM‡è7oïO+—\€Â
-ë2‡‰+>ÎBØ„¿™o vfÈWt‘—»º<1c…âÕ%KS”œŸðXú}Fb(59J“R`cÓ1'¨ŠµL&màjã‰MΘ(ÔY'
-cß·C¿yQQ`MÖéh&×ʈ
-GID濯œ	3ßp-“kºgÊÁ«²rò+–
-Ìg]©†q~ÄÄ%d!ÄØ"¹_4Èt6ÏÍÿBže´=…б/û–nâ¨pØ×eó)MdÈÙ´Í@*28²É¨•d>¾{M€tΊK±LV¦¥tã?o~û=]U ž_oR¡]‘­¾Â @@­v7F*á\fâL{swó¯‰ D°BË%Â2-Ú—-ãŽsR›ÈÜF›ªŽ,›+dŠâÛ•ÃðR€Ë‚y9×·3gÖ„BC¦P•¨¨‰ë•É=ü«äí¥`€¦‘ÀšÎ5¨Eɬþ\I‘ç4!ÍàpדÂÄOïwjõ¦‡­f—Š„7sÊáRPÊÌcf.RX†¬DŽ19”Fh®©Ä9L–kùh­2Ì
¸òm-!t<*}G˜èÏ4õPŸ‘˜²2LŒÒCà8,œ0 ítÒù]]Ø$ˆòL{«z»ÖëŽíȘCÝU\´Ù‹
-ln¯·Ö&MN¾q&
ÈK&s’·«‡Ás1d’p^H”0¨q@܆ԙ„JKÏÄ‚XÍH߶÷U¸øo&er‡®µ}nºÇ~UjPY,Ða!‚6}×"Áç,ÜÂia
-1PÞ몧LŸ—&¥?†
--/HØÁÎy&å»À®”N¤Vº)ì|O¼…p©ŽEÞ$P¤>ÙG~²­Y¡Ê †¿3y^¦kWÔÀàÜ•ÿZtÀ8”9ëVÞû—c×yÀ‘ópÖmD4( ×p×b„âžãÍ3è«))êþ{_aøãdÚd]Üàöáë鳫ǧ>ØBšlƒ’p­ªÀf±è„J’*Å}ëK´ã°ñªº­Çi–K*-+>&¤ÙqQýsÑà‡gb,T&]E4a–°Ð’på2—oi€%,Aýö¢Ó‹þYU¦!«N[ü8•Ýz²püŒ°¡>'v^ÜÏ“(—êéRIm‹òIS`É‘5¥9Aã\Ýù‡é⻲=’œpÚ/Õ`*•Â`‹k0h+7Ç—ÈBúÈòX/€—
-oQÈ"ú5QÚìû¶)—ª:kE¦òXÕ•-Åä…£¹ ¼>Å‚3eSojÍkâ
-}FÇ>ŒÈ	E?ngʛ̺­Eñß`{Ó¤p0ú¡†.[$.d2ÐèSš¥ßbà2Éq˜öƒÍݽ}
ë’–¶=÷ò¸H¶³:M󿃲<ùøñîý/´L&Ë·@‚¦®]
-–ýG[¨R¹b»ðŽàK¦`ý4ðÓmpp{ì÷J0	F¦åǺ«~F“‘þÅÉe‘<ßéuô…$ÒtŒ{„"ù\?¯%dCv¿)#Oý¡ùæcq™Å£=ø!zVl”C·ëc©Ž>ØÕÝÅ2~FÀEKO2Àþs*€˜ÆðXZÞGBXÜ~ÆI|`ËÍ°äz˜QÈy8¥¡åí÷uÌh0;äÀǺ¦îY»³÷h2rÛø£k—b …’ÄhF
-f2€ïFt-˜¢~¶åônwâ-ú¬;]àc×BλÈs¤Hz	ƒúÅå©9Eª;4UUw—iwÉIÎ’iÌœæšÎž¿“²‡§þØVÓcïb¢uÕŒ1tì|w|ON~™
ˆI›ÏŠ“<>Ú<¶=õeéQylψuhFÞŒùá“R¦:îöøå|`ùɲßí¡xšFCxo´ôúu†LÆ\Ñ€•d¹v‡™&nŒ¹òÒó&ï5:‹ÞëT¿$3*nô`ivŒOávNBÒá¶NË–OŒ?E“¡IS ýØnÀ
-ö}eEÁ‡¸Ø÷(‹| ÿÒû‚Î Cú_zv9UÝ'¤…g—ÔŠB¹|"…‚’îÅG¸…ÿü^KÄendstream
+xڥ˒۸ñ>_¡[¨*K<ÉiãÇ–÷0®x&‡Ôz’šáš"µ"egüõéF7(JâØ©ÚR•ØF¿r•ÂO®òL¤º0+W‘¥2[•»›tõk¿ÜHÆ1™™Ñ«›Lç"Ë•[mæDþyóÓ;%W*Öªlu¿Î²6èbu_ý–¼~òû±>¬7*K³þýþWÚe„ËÄ])œ`…Ì­
~®¾ø®¬+ÚñæöŽ€wµ‡z˜(H#´±Š)X#df] àz#Ó4Mnû±Ù>ó½*Da•åªʦyØNÑÚ&·îß¿ûÁÍ€_—xîêòÉwÍ°£áøäG^oÛþëÀH~—Ex¨_ê/Œ=!wÄ“¨›ˆÛú/õÕ6—ô[šÄ£ëZ/†W‘RY¦ÂU¾õ]ý7@T:K*?z¸i–¼ïhê°–yRû¾jšAjøõ“dOb’Ê
+-]‡ m–ε8ÖhÇhÛpH¿‹tÃ'JaºâÚ™äNä(	^!9 øµi[‚ʧºü|ÎìPGîƒjF¾5J¯éù¾ @ÒFZÜ‚åž	‹ÎëB©„ZÇï´T$´n¤‰}ø®zÅ·ô
Ç™®?2yÒxðÝ°%9ˆI•¹Ð*'Ox×£u¤.ÙõÄšnÛv~<à„è#hÈjÌàÎʸ©QB§J1Ú+"D@U=”‡fb X)c,Q*œ”ñôî%ŸÔ€¦'#êgô›ÑoÞÞŸ"–“\€Ü
+[dF$Z<<®ø8aþf¾BØ™!_ÑE^îêòÄŒJHˆW—,MQr~Âwbé÷‰¡Ô8”&¥ÀƦc26NPk™LÚÀ9ÔÆ›œ1Q¨:²…È1,|ßýæEE5ÙBG3¹VDP8J"2ÿ}åLø›ù†k™\Ó=S^••ã®XÊ1[œ1t¥Æù”…cóä~Ñü!ÓYçÌÿBže´=…б/û–nâ¨pØ×eó)MdÈÙ´Í@*28²É¨•d>¾{M€,
++.Å2Y™–BÒÿ¼ùí÷tUx~½I….òlõ©jµ»1R‰¢ÈLœioînþ5„–ka¹DX¦EûR Å`ÜqNj™Ûhã êȲ¹B¦(¾]^rpY0Üq
p;qfM(4d
+U‰Ššø°ÞX™ÜÿJÞ^
+h	¬i§A-*HfõçJŠÔ…&¤îz’A˜øéýN­Þôp£ÕìR‘ðfN9\
+J™yÌt"…eÉJ8ŒÉ¡4BÈóJàÉr­ ­U†¹Aå.ù¶–‚»Bé;ÞþLÐC=#áNY¦FFé!pNö+’«›.dp(ŽÞïÈ6/î¤Á5ÓBŸ²‹*Òäé?ÓiU½]kH”ÇväÕ¡îªaáÄr t§/ŒþöÃÚ¤ÉÉÁÎ/„É
+ÉÇïêað\Q™$œ²-jЕCþMB¹¦g²E¬f¤oÛû*H‚@&er‡þ¹}nºÇ%I¥µy‘
+ÖHcÓw-|þÇÂ-
+-L®3&j$ŠÚA	nyVß”þ8ÔK|@¢7…û‘ÂøS‹¿`Ì£kŸ	Bí,‡bÞäNOï{:ÉE‘êx¤$>Y&ÀQò
¹æ¨áïL	—…BrÑÀß<ˆüµ¸„0+l±ÚðÞ¿5ÏCœ§ž³>'¢AYŽû%#w;ožA“MIñþßû
+KÏ·>Ó&[ÄM	¾ž>»z|ê±üpi²
JµªCGg…–jÔ}ëK4þ°ñªº­Çi–K*j+>&$¬ÙqQýs»à‡gbÌZ&]E4a–°ÐqÍr¦oi€Å3Aýö¢ÇŒAó¹LC>Ÿ¶øq*ø#2tƒáø)C}Nì¼­˜§on.µ’Ú.¶“¦À’#kJsi€suçZ¤‹TXìÊöHrÂi¿Tý©T
+ƒÍQ¬þ ¡Ý_2 ‰+s±R-.•ü"—Sä J›}ß6åR=i­È”‹õdÙ† ¸Eáh.e¯O±àLÙÔÕ„*÷š¸BŸÑ1ì#rB!Ó€¸Lç&³ƒ>oQüÁ7ØÞ4)Œ~¨¡?äæÇ™4ú”fé·¸Lr¦ý`swo_ú¤¥mϯ¸H¶³:MÝßA™K>~¼{ÿ-“	Âò- ©k—‚e¿ÅÑêc®/¼#ø’ÉY?
ütÇ;ÍL‚‘iù±îꃃÃd¤Ä-G~rY$Ï·Fz}!‡4£Æî$O>×Ïk	)”Ýo
+FÄÈSh¾ùØ¿œîÂõ.û׃¢gÅ=ôÙ>6	èƒÍc‡IôráÖž‘êÿîÁ\öúé>³§ÓkÔ©M±&F›<Æçé=jŠ(ôÇC#†ƒö¥Po(jC"Ùì5Heø°RÕ424|=}âKC6i&«SŽ8‘°iÒ;lF~q¨h‘‚”"öôÊȳ»X¾jP9¸.©%N31žCãÚ,érnqR'%±ÂÖ¼@Ü0ià¯Ouw±Œ‡†‘$pÑ’Æ“p‡ÿ¤
+ ¦1¼†*rÖLb¡DPpÿù'!ð-/4Ã’ëaF!çᔆ–·ß×1£Á4ûR–8ÖÝ0õíº8{ÙöÆÙÞÄ]»-”$S}Ìd:_¬èZ0EO³%ˆ(§ÃoÑg‹ÓU>v-伋YZ.€ú²ô¨<¶gÄ:4#oÆüðI)Sw{ür>°ü؆@ÙïöP> endobj
-984 0 obj <<
+989 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
 /PTEX.FileName (/usr/local/share/db2latex/xsl/figures/note.pdf)
 /PTEX.PageNumber 1
-/PTEX.InfoDict 1002 0 R 
+/PTEX.InfoDict 1007 0 R 
 /Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
 /BBox [0.00000000 0.00000000 27.00000000 27.00000000]
 /Resources <<
 /ProcSet [ /PDF ]
 /ExtGState <<
-/R4 1003 0 R
+/R4 1008 0 R
 >>>>
-/Length 1004 0 R
+/Length 1009 0 R
 /Filter /FlateDecode
 >>
 stream
@@ -3142,12 +3169,12 @@ q
 n*Œ1½÷¨¾x¥Æˆpîâ‹&XîÃœ§³±è\íD¤ßä0}#XŒûž˜‹¸À>#^V°¡|2Îi‰9ÊÎr)`˜¢Xh¡Ò& „hb—H°Œe"Ãêʱ„£~Ï“a³tŒºìZDß!#Z¶ÚÂk! e'jÝ=§ _tsÙ¬ûÍ&­Nå@‚i¬ˆ3t%kÐE„\H–YZxÿ/U¥Ç™åë—Φ@±¯iWH
 þrÓGçX5¾ûû8‡´ÕªOª«t–Ô³$Ây°‰—BÒ›ÀÄ5©/¨vp÷o`kA“ôr±ñœÓ4N.4Žæ&F°ÑTÆG%V½ Î'ÌØR5¬BÔ‹`qUžv-UÍ=ëÆåQv2ë_ ”¿­qq‚~èr¯Ú5ÌJ¼ð˜°h»P¡õ‹kÜàéÚýªå>Ò¸D°o»Îi¸CrT]¿MJ¥ ÆÖ¹’°;¿ö‹ûóZ¼¬å[Ç-œÁ¤ŸBx¿ýpü|üÈÂendstream
 endobj
-1002 0 obj
+1007 0 obj
 <<
 /Producer (AFPL Ghostscript 6.50)
 >>
 endobj
-1003 0 obj
+1008 0 obj
 <<
 /Type /ExtGState
 /Name /R4
@@ -3157,56 +3184,56 @@ endobj
 /SA true
 >>
 endobj
-1004 0 obj
+1009 0 obj
 1049
 endobj
-991 0 obj <<
+996 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [470.3398 482.8902 539.579 494.9499]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-992 0 obj <<
+997 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [316.7164 470.9351 385.3363 482.9947]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-988 0 obj <<
-/D [986 0 R /XYZ 85.0394 794.5015 null]
+993 0 obj <<
+/D [991 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 130 0 obj <<
-/D [986 0 R /XYZ 85.0394 769.5949 null]
+/D [991 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-989 0 obj <<
-/D [986 0 R /XYZ 85.0394 582.0558 null]
+994 0 obj <<
+/D [991 0 R /XYZ 85.0394 582.0558 null]
 >> endobj
 134 0 obj <<
-/D [986 0 R /XYZ 85.0394 582.0558 null]
+/D [991 0 R /XYZ 85.0394 582.0558 null]
 >> endobj
-990 0 obj <<
-/D [986 0 R /XYZ 85.0394 543.4475 null]
+995 0 obj <<
+/D [991 0 R /XYZ 85.0394 543.4475 null]
 >> endobj
 138 0 obj <<
-/D [986 0 R /XYZ 85.0394 324.8439 null]
+/D [991 0 R /XYZ 85.0394 324.8439 null]
 >> endobj
-999 0 obj <<
-/D [986 0 R /XYZ 85.0394 292.4184 null]
+1004 0 obj <<
+/D [991 0 R /XYZ 85.0394 292.4184 null]
 >> endobj
 142 0 obj <<
-/D [986 0 R /XYZ 85.0394 174.5048 null]
+/D [991 0 R /XYZ 85.0394 174.5048 null]
 >> endobj
-1000 0 obj <<
-/D [986 0 R /XYZ 85.0394 146.6189 null]
+1005 0 obj <<
+/D [991 0 R /XYZ 85.0394 146.6189 null]
 >> endobj
-985 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F39 863 0 R >>
-/XObject << /Im2 984 0 R >>
+990 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R /F62 1000 0 R /F63 1003 0 R /F39 868 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1009 0 obj <<
+1014 0 obj <<
 /Length 3382      
 /Filter /FlateDecode
 >>
@@ -3225,54 +3252,54 @@ J
 9ÐìsÉ3ÛásLÜC¶;e/hÕÒç›™E=žÍ?¹êÜKüä8UàŽs’"ºÃ²	žP~(¥ËýsÃ;B^~:_ؤÍZ¾‘3JŸFåO¦ÿÎ^À3›ûkº}h´ù=˜'	hÃÅ™î’g¹U(@^ºÇL­@|Ú󄈥¯¤žiU°ðâ+|j—Õs ñs
 õç씯•P#¿DÞfno.5ÃÆä“"u%½©§Î—h¦µ»Ô¢=~Â"*•ñùg8J=x&5Že¿¥ÚÜa°Ç)ì‡ù㚦0|ÿ_µrˆUp[¡rR4^žv˜ÂgmùÕ-ÆWx[¶ï~þHwö%h䂌٨9	³åBÊåg#Þø›óÏž.ÿ^s¾áû\¥Ì¬ë•Gë2ù¦u…~¬¥3̧íÝ"¥¼YDÉìž’NRBþZå³!R’z:2‡& O‡·ù ¯0?¾¹éH=¼áŸS¬9©ç/MÖˆD¬½½i¬¿c²;ÍYvÐaarGô~‹ÝèÂœäi÷õ%ÖƒF Z•IByy?‹é–ìÈ0Ïé=!N†ÑÜ´öÓêâó­°âg 5>VÍlföA›¿ì^XÐ@\Uì¬ó@Ü¥?ºäâ¿S^uƒœÿï?ÁŒ’ÚI-?G:ñeLX(Ôd\Hîþ-s)úOK¸Pendstream
 endobj
-1008 0 obj <<
+1013 0 obj <<
 /Type /Page
-/Contents 1009 0 R
-/Resources 1007 0 R
+/Contents 1014 0 R
+/Resources 1012 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
-/Annots [ 1012 0 R 1013 0 R ]
+/Parent 1006 0 R
+/Annots [ 1017 0 R 1018 0 R ]
 >> endobj
-1012 0 obj <<
+1017 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [464.1993 519.4233 511.2325 531.4829]
 /Subtype /Link
 /A << /S /GoTo /D (proposed_standards) >>
 >> endobj
-1013 0 obj <<
+1018 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [55.6967 508.4843 105.4 519.5278]
 /Subtype /Link
 /A << /S /GoTo /D (proposed_standards) >>
 >> endobj
-1010 0 obj <<
-/D [1008 0 R /XYZ 56.6929 794.5015 null]
+1015 0 obj <<
+/D [1013 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 146 0 obj <<
-/D [1008 0 R /XYZ 56.6929 584.989 null]
+/D [1013 0 R /XYZ 56.6929 584.989 null]
 >> endobj
-1011 0 obj <<
-/D [1008 0 R /XYZ 56.6929 551.635 null]
+1016 0 obj <<
+/D [1013 0 R /XYZ 56.6929 551.635 null]
 >> endobj
 150 0 obj <<
-/D [1008 0 R /XYZ 56.6929 396.4263 null]
+/D [1013 0 R /XYZ 56.6929 396.4263 null]
 >> endobj
-1014 0 obj <<
-/D [1008 0 R /XYZ 56.6929 360.8629 null]
+1019 0 obj <<
+/D [1013 0 R /XYZ 56.6929 360.8629 null]
 >> endobj
 154 0 obj <<
-/D [1008 0 R /XYZ 56.6929 173.1662 null]
+/D [1013 0 R /XYZ 56.6929 173.1662 null]
 >> endobj
-1015 0 obj <<
-/D [1008 0 R /XYZ 56.6929 145.9427 null]
+1020 0 obj <<
+/D [1013 0 R /XYZ 56.6929 145.9427 null]
 >> endobj
-1007 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F55 970 0 R /F39 863 0 R /F48 885 0 R /F47 879 0 R >>
+1012 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F55 975 0 R /F39 868 0 R /F48 890 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1019 0 obj <<
+1024 0 obj <<
 /Length 2880      
 /Filter /FlateDecode
 >>
@@ -3288,29 +3315,29 @@ _
 ªºìIú³ÏÎ$ÿ¥þ08Kpó<ŸÞà3hóešf8™Nf8°iìbÂ/­xN¥|Šýï°|Gÿô?ájQÖóíê’þ,®º¬îK,ú˜¾­š2¢*š¸ŠDŧïQúÍFÇoE×Ø%?¿4 ½_ŽÓp·Œµrl->VwÑï­ø^£Œ¿º,‡ö¬…cN+7‘ P…ÿCz¹½žÐâ}bÚ-ü,ý`׶wñ¢ >`¹RLìPc!âä}bv¼+£`ˆ+ùiXA¸4Æ
Íy/_
ºö¾à÷Œµ`Î9*‹ùšÆ|1
Ö´ýWfàœ–ÁÿùK©_…Ãéá¿_E›¢1 î£é´>f«Ûzv]Í–å¶ÜƒŽrFu‹à-Žt’Ùk¢cc¾sLÐ40YVô–W |GXAÀâåK:è¡AHù¦]:ÝbêQ8*½=
 Ã?1>øÿÇ×%&
·srÜŒ·ÌÉ<‹D!/rÇqÚ?ØÛ%ý?mwendstream
 endobj
-1018 0 obj <<
+1023 0 obj <<
 /Type /Page
-/Contents 1019 0 R
-/Resources 1017 0 R
+/Contents 1024 0 R
+/Resources 1022 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
-/Annots [ 1021 0 R ]
+/Parent 1006 0 R
+/Annots [ 1026 0 R ]
 >> endobj
-1021 0 obj <<
+1026 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [417.8476 228.9788 466.5943 241.0384]
 /Subtype /Link
 /A << /S /GoTo /D (sample_configuration) >>
 >> endobj
-1020 0 obj <<
-/D [1018 0 R /XYZ 85.0394 794.5015 null]
+1025 0 obj <<
+/D [1023 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1017 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F14 685 0 R >>
+1022 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F47 884 0 R /F14 689 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1024 0 obj <<
+1029 0 obj <<
 /Length 837       
 /Filter /FlateDecode
 >>
@@ -3318,21 +3345,21 @@ stream
 xÚÅWKSÛ0¾ûWx8%+zÙ–Ë)…Жé0”¸½×Q 3Ž,‡W§ÿ½’_±‰œÐv˜	ÒZúöÓî§2¡üC¦íÇÞézØÙf87 y#¿}2P¹ÆªYÍU}cpB\ÓžƒÓŸ6°€Œ!ÓŸ\ö(  /`o|þõ‹ß·°
{Çgã¾…µYïèóðÜ]öjéðøG!ÔžŽ[Ôàd4ì»´ç¿û×þ©1òk¦ÍÓ HÍ;ãòšy¨Sâ1Û|çasnP››RY"cl|«_ó­Úè 0q°.<^#<J(×ö€C0ÉÃóûPAY϶qn
¢(y°²4ˆÅ”§}Ë°÷«ø'1?,†r¯ÜEåh0(,"˜/"^ŒuWІqRŒ%Žœ¢n÷wKž>µ|Ï⌧q‰’lÏ!â4ø¤\dé,ÌŠY0C.DÛ7jøNy¸LÅ,‰7úWþ\Öéo¢9#`“ÙÂxÒ6¹U¶ªÏÊú,CYx<³Œ#Àó<€0™Ô@wdjˆ¬ÊPŽ¥|T¤Zþ³§EkV<ÓY|0¬ÒïIÒ‡ ðT´ž+Œ53:I*¦ó *Ó"™Ùì¾ Ž]*%ϼ6óF†’h™Õ™UŠ\a–‰+ÙÔò´^b¾Y¦ûÝ9îrZÚí¤¼¯FDÜóý$’oÙ¦1X§£ÝS®-äb€ IGhÑu½oñùßYE Â¬SúîW¹ö°ç=î,µÛ#ýöÈj‹µ%úë²K`ñu]€Íq}úÿFNþYJ'²EYu/Ò‘M•ŸZ3*o_Ñ“©*þS†(/ëÊp›ˆ,/ßíÞMðô^Sã0‰¯ Ä7
 g­Vé…³ Œ´QXK`ZyÊÈjõb«áë’Ò‚/fͺI¬[žò¸¢($µ\l­[:×·„ØyÏ–p³.ƒø©éÚ†Í^Oƒe´[ó·Vû­0oùÞí'Âí`pƒÝÚOL÷mGwƒîCl &š	¬õöæ÷ÏêéG]@ÃõÓ¦U°Ëe¤$¥¨c¼Æ¼z(­SÿÖ8Å.endstream
 endobj
-1023 0 obj <<
+1028 0 obj <<
 /Type /Page
-/Contents 1024 0 R
-/Resources 1022 0 R
+/Contents 1029 0 R
+/Resources 1027 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
+/Parent 1006 0 R
 >> endobj
-1025 0 obj <<
-/D [1023 0 R /XYZ 56.6929 794.5015 null]
+1030 0 obj <<
+/D [1028 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1022 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
+1027 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1028 0 obj <<
+1033 0 obj <<
 /Length 2146      
 /Filter /FlateDecode
 >>
@@ -3347,152 +3374,157 @@ xÚ¥
 KÖûcâf±$îfˉ&Ägqdd’ᮨl–­÷L\Ø&¥¨ŽhÊŸzœ†»IEC#Â÷#Ë!$â)IcûIlqر!pRPGÊQŠ&Iœ¸Î€qÛ¼Ö•nŒ§#;·[Õh+ÞOCú_;‘®UfÓù;U4cIÞ@‡Õ>ÒeDL$Ij‚bV ®µ-H[ADN
 ðeÏ¢™˜…¢“Yéî^ëŠØOŸ–XøÎèØò	nEȤ/ϽgL	_|qzBHL÷IR9XÞžð*bS5«Šæ<\¢}Íû½±üÐ×ÕsêÉô¨>‡îy”>q<ÃÃ5&XHUKטpB7à¬ìÛÎ:§>kÚÉÕöUíê8ÞѲ	ŸÅg@ÀÒ4G¼ìªïêŠpFD¬ÓaëðU‡!b¬ø¨±­¦<	EXÜØ‹álsôgX)¸H=Ð8-°åä1ÍW‡N»ÖSÎßürõÂûåeD+Òiitm¤½S­ê;SÉâdþs
íÞdAµM×âµ;i0"ª*¸cºmê_ÒÇNkÕ…:ŸÔ6*GŽd8[w¹3]©p•'¥úR”}9ÜAxOmŒ™mÁˆ#.,ÃE‡/D!15ñÚ‘¬/©á=¦:×#x\^@/Ô¹„slÉx¸µ±yŸÙ“Š†£a­“cƒf½3LÇNEÝ9U^µq<8þBo+OѸ-Uæ•yd¡+ûò©Xô7¿Þ.í“Ø›vçӛɥI˜UKNÏéÂ&öÑñ°~ɪÃð0þ锧ðš{êヶênº:ó4bxý19…GÙRtI´Œmd»eJWët,‡Ï°›³}‘€òU’²ˆË³O'Ø3yqh_òUVçÎÚ®ž§ÑKLjSAªHW¡d=ŸÊÅæ³k[)z9uþ¨¿@V·\“וgéÑ=Ï^Fî”jG.zZ¢Ìz¨t“Ÿ!x’0žrì5F0ãm?«Ëëèŧ×òקuË?}ö•ø”_}ÿý·zÞ™šÑk$˜86zãN¿F|UÕõu,?jŒ=öáºüÚ:ñ™Õú¡üQ÷ø;L NÅð½v¤‚À©ùµL¡"DpÎùðõ÷!ëÿB,endstream
 endobj
-1027 0 obj <<
+1032 0 obj <<
 /Type /Page
-/Contents 1028 0 R
-/Resources 1026 0 R
+/Contents 1033 0 R
+/Resources 1031 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
+/Parent 1006 0 R
 >> endobj
-1029 0 obj <<
-/D [1027 0 R /XYZ 85.0394 794.5015 null]
+1034 0 obj <<
+/D [1032 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 158 0 obj <<
-/D [1027 0 R /XYZ 85.0394 479.27 null]
+/D [1032 0 R /XYZ 85.0394 479.27 null]
 >> endobj
-1030 0 obj <<
-/D [1027 0 R /XYZ 85.0394 444.0186 null]
+1035 0 obj <<
+/D [1032 0 R /XYZ 85.0394 444.0186 null]
 >> endobj
 162 0 obj <<
-/D [1027 0 R /XYZ 85.0394 287.5734 null]
+/D [1032 0 R /XYZ 85.0394 287.5734 null]
 >> endobj
-1031 0 obj <<
-/D [1027 0 R /XYZ 85.0394 259.9325 null]
+1036 0 obj <<
+/D [1032 0 R /XYZ 85.0394 259.9325 null]
 >> endobj
 166 0 obj <<
-/D [1027 0 R /XYZ 85.0394 214.4637 null]
+/D [1032 0 R /XYZ 85.0394 214.4637 null]
 >> endobj
-1032 0 obj <<
-/D [1027 0 R /XYZ 85.0394 191.8161 null]
+1037 0 obj <<
+/D [1032 0 R /XYZ 85.0394 191.8161 null]
 >> endobj
-1026 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F48 885 0 R >>
+1031 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R /F21 662 0 R /F47 884 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1035 0 obj <<
-/Length 2336      
+1040 0 obj <<
+/Length 2357      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥]sÛ6òÝ¿BÓ—HsŠ‚—éƒâ8©{M.W«÷Òö!‰)E*"G×éï» H›¶“ëxÆ‹Åb¿b¢C&2™DIÀ4z²Þ_ðÉÖÞ\™{¤yëåòâÛ×*š$,	e8Ynz´bÆãXL–Ù/SØÀf@O—7×ofs)d§—ß/Þ/¯~‚©æ€‚‹Wÿ	!¦‹w—W¯péÕ»¼¾ZÌ¢`ºüù§«›ÙoË.®–ý;®,s/~ùO2¸Êœ©$Ö“[˜p&’DNöVLJyHqqsñŸŽ`oÕm•‰àLªPŽEŠ1¡è„…JªN(‚ÉÙ\pΧoÓ²M¼çSšcÚäUio	´TŸ.•åÎÀ&Më]zœ‰xj2;§µYã¼Áõ¼&x¾?'„¥ø9¦eVíý¶­)×D´Ú t•7õs|
-‹UæÉKÄ[¥µ™‡V‡ŠëéÛª¦C7—××D¸9æ嶦ƒ‘5œ|J‹<³7µw‚%Zã݈ªÅŠ‡û嚧uÝî„Ë—CaÊm³C`^÷îO÷mÑä‡bp·xJôA/Q<11æ€knºṉ&ìþÚÚdÀ‘ 	ÕÕ€¥¸¯šÁ-Ñ9Ší¯Ó+ƒß½3
Ç̶h&c±˜)ŽØ¢¨+ËF$Ü¥Ãhú{YÝ–8DâO;¾ÇYGqÔõŽF)ÌaW•†æ¦Y?®ÙéF‘n®ËMuÜhÇ?¡oÂÄ	©¿ú/sz6Ó Hœ^}ÎëÆŸ'£ëõ>Ý‚.1èç9C$¼ì â‰r2`?Z0εC™îÁ‚ÖU¹á=”L†¡—ůœËÂüs„æ<‚ÅI®¬ ½†Tí†ß
ÀlÀÉznÿK†?œzcZl«cÞìö´wŸ®çûL¿x([·¶ˆßü˜~{¥/?¼Iþýª>òT~Èß}÷
nžöç‹q“êßÃéCqyfí¹UTÐñFS«‹Öx|ÌKŠ¨nÖÁ­þ,|uBðËëw¯‚ºÓúYÆ.Œ7¸Ò%bsU}2lÌÑorW'¨0*Ž^HlÃ7µÝ;Ö^+‘Ó¼éãé)®®+›Eœ!"¹”ÐpÄòTO"V_dyŠv#êŠx.«r~[:I³tUÇ«r	Ù¡-Ö1Û@u«¥”w²MN·iòOf˜ÃG¼,ÅO
;í³ôÒÒfè¾ ƒ¢íh¯Nc¢JT©Ñ—H
-êÓ(êܵ>WP	s!ã;•†c$$ÕK
9¼ÊËÆÅv_ûÀ²s[;ðX^áÛ2ÿŸK7
-r¥mÓd-Äô—…½!ª>.Ù14 sÚ˜zRunýŽ|[¢”"ç'CÖ-—¶ëx>œÉòK&;€£óÍ	Çä?; m(/Ú,
-%Øõæ1$¡#ÂR»^Û¶(Nçc¬òMæBBt&ƒû!¹—õ]*tM;^ÝcT?æÈþö_šƒ.CEÙ‚µ?‡öþsmîçå§S°2<¶|Ö8JÏL]\™æÖ˜'Ím…›0h·‹¤¨n°>åwfeÇû¶nþŠV›ª nwžü,5•g¿¾²‚zÊFä|yvnvfÄÉ…P„êÿÍľF8ŽÕ:‚©H$OÕ:‚é(öXTãåwk±ë÷ÝÅÈŠÏUÛý“cˆGJö«,ùd•åE½9´×LÖ*,Ô:æf¯[øí”Â{Oí‘(P^üùw«†·çÖ5JèH•¦'­hé@R5Šmuß6¸D-ŒP°ÝêþXÓº|ÉXUú¸˜wsàe•¡eÕ \“ºG€¦%w.Ü#‚í ª1Èßðž†Ù3/)Ó¥ËùC™òN_Œ
Þõ˜u%,P±zº„Wô%7È5s—Æ,c5Ðe™¨KY=·ÀrŠSdöckj’”óæÁŽžG8)g5
θ͋G+Zîr›[um@äS0€êƒYS"¡„®XsýhJrq2üªf‡Ø´íÄg`€T‹6ÑÕ9˜Âêa€;§jîo~ÃÛE“.Þ5.ß¹ÑàrÐa€N÷VÐ3‘uÛݳ„4PCeÚàs¹eÖ}wC@^Žµx«aðdDÐg]^Zåm[ztÀ.h»±æîö#8X]äöçöìÑ>n!p$fN;ëÅ	Á‚ðÍÈ=ù d,ÈTÅ 8Uaaqù#2c—ËÜšéž,/€6{r‡°\ÎO}	ÇÐNt…Ãf„R‘( uÐññ4F%ò£+>ŒPmøö¦±¯^ß2記I‘ЙšÛ(š`{ÈìäÅ€‰È‡Åíˆb#	ܳ6H¡îyF+Ÿa¡Þ¥nu»+^íÈ|n¨+¶ø$ ¸DƇ­ií—ëÊèíÇÂl[°!Ø-=ì¹q-3ÉM6*Á¢DD÷J4íAÉóÀ/3а۟SF~GáËýí_mÎ?SSq,Ï?È\?ŠYbÊ^F÷8÷?ïÜgý/"óendstream
+xÚ¥]sÛ6òÝ¿BÓ—HsŠ‚—éƒâ8©{M.W»÷Òö!‰)E*"Ç×éï» H›¶“ëxÆ‹Åb¿b¢cg2›$YÄ4z²ÚñÉÖÞœ	™¤yëåõÙ·¯U2ÉXËxr½îÑJOS1¹Î™Â6
+|z}uùf6—Bf|zþýâýõÅO0ÕPañê¿3!Ätñîüâ.½zw…ƒ×‹YM¯þéâjöÛõg×ý;®sÏ~ùOr¸Êgœ©,Õ“˜p&²LNvg‘VLGJHyvuöŸŽ`oÕo•‰àLªXŽEŠ1¡èŒÅJªN(‚ÉÙ\pΧoMu4%Þó­ìÁ´E]¹[-Õ£Å'€Ã¢ŒKOåzka“J¦ÍÖf"ÚÜÍãicW8oq½h^ìöå-Â~¦Êë]Øöñh«­×]mó†ŸÂb‡CŠ
+ñ–¦±óØéPq=}[7tèâêüò’·‡¢Ú4t0²†“O¦,rwSw7!X¦5Þ¨:¬t¸ÿW®¹išã@¸Ü9”¶Ú´[Mïžétw,Ûb_î–N‰>È€àŠ'%Æn¶d}k©d*ÎR8Û¹Û¡IŒØª–,JœyÄú€Ô‰10Ä¢4Û㛃Ù5~Ãu‰ÙÎ"`,щä±4Rb(ÛÜ´†uWèlË{‘Šáüä‹ÁÏëý-Š	¤:„ÁèÐ[½ƒÆ‚¶<Ÿð}Y{£ÓΓWÛ¢²Íc¾+Èw½¦1jªA·µ·C€áÑlVõÞ"ÌÛ,|!$2\\ ŒèØ™¤Û<έ›}}h²³`ÃUÑìhö>–y8aÎŽl$’Ž5=]¼¸Ãë6ⵯ¯ßÏ ¾OŸ£8šfK£Ö–v¿­+KsÛ®×ìt£H7—Õº>ìF´cŸÐ7aâ…Ô_ý—½}6Ó Hœ^|.šÖǸ'£ëåÎl@—ˆõóœJ!’GÁ¶ñÄ91gš°\ˆ¹OIdLéDõ(!›rŒ^Ì´“Ñë4î¢Eg€
+ÃcÁ)Ax]—e}ÓÉ® i˜<vlÙ‚÷IÍæuŸ‘A«¬ÏŒsÄP™XЪ®Ö#¼Ç’É8²ø•sYÚŽÐœGR°4‹À•¤×’ªÛð»…ƒ
xYÏÝÉò‡7Ã`Ac4å¦>ívG{wf5ßåúÅCعµCüæGóí…>ÿð&û÷?êF|øÈü/¾ûîÜ:=íÏã&Õ¿ê#KO¬=Bœ²ª`Äöõ(a©ä	!>G{Ýf	yœE9Í,®5ǽ^÷_ÒúËËw¯btœ2T–Ž‘§A—œÁ,ëO–í&z(°«Â—*Ž€˜#ëFákÜG÷Nw·Ëä´hûxzŠ««Ú%"oËHΚƒ
¯‚L¤ê‹ŒW±ˆÃnD]ÏU]ÍoêCIg"#&7ËÒz^•ÏyÈmqfŒ	
+d-¥¼“°
+ºM[|²Ã2`ÄQ
~zl¸iŸ
„ ³…¨hÚa”ÇŽöòvLT™‚B7ùIA‰›$]D å+(¦¹ébÅ3“ꥆ2 .ªÖ§‡P>Á²÷|7XAᛪøŸÏX
+Ò
e,í2$>Ä—…½ë!ª!´¹1´ sÚh©¦1›°£ØT(¥ÝeÀºãÒ5.ÏÇB‹7YaÕåpt±¾Å1Úܦ¥Ôê1Tq—ëÇäÁ-W+`x}ôÅb8Æ)ßæ>2$'2¸ꃪ¹K…®éÆË{,‚êÇ’~¸ý—&ô¨KèP”ÁÚHéC{ÿ¹±÷SûÓY™“³Aóä—¶½±¶ÂI{SãÀåÚí*ª¬O¥Y¹ñîØ´HI«m]Ò	7Û@þ–Ú:°‚ßPœAIæóˆ¾<Á·[;âäBH¨ibõÿ&óPfÆÊ%ÁT"²§Ê%)"ÍNÉÌßãn9wù¾»Yñ©ð»r
+ñHÉ~¡&Ÿ,Ô‚è ½‡©Ñ2EE‚ÅZgÃôô°ý‘*EïiÒ5΋?ÿnáñöÔý&)°Rs‹ %-íIªC±kŽ-.Q#Ôlwº?4´î_2V•Å!.æÝÜxymiGU·ˆ×ÿ®PSÑq§"À¿C¸&¤ó¢
=óí0{Õ eút9(SÞi­±G¼³®ŒE*UOw*’¡j¹æþÒ˜eœº,“t)+¡X68Ef?mC’òÞ<ØÑó/¥è¤¦Á7EYâhIË]n󫾓HB
+P³·+J$”ÐKR®MAIÎ NÆ_Õ/›®#ùjÑ&º:SX3p§TÍÃÍï`»ècÒÅû±Æç;?\šÐiæŸz&² †½{Ùp“êa¨L[œbN8uݺïn(ª±.1b5ŽžŒcƒú¬ëá+§¼Í‘^=°Ú~¬¹¿ýÈÁÖ_¹Ã¹={tïcO±vÁT<¦#Ñãué彩H+R1­u<´Ë¡çŒ™Äˆcs«¯ºöhñœ@žPPŠÜ+‚4Aô(Nå>'™&XåÂu8>‡àx¨Ë§K×Æ9áh3¡(ðú˜9ì¤/Âg'ÿj„’|° Sƒ0à|T……Åù8È­[®
+gfD¤{õ<"ºìÉAvá)Ãq9G<õ%ð©pXPJ E´:>ÜŽQÉ ü芀#T@¡½iÝÃÙ:´Œ:*eRdÑ#tæ‘æ®ʆ&xÜçîs„bÄDÂâfD±	ƒX¤Pÿ£UÈ°Ð	o@Ýî‹W7²Ÿ[ꊾªF(n‘ñakÚ„å¦öÄ#zp0×ËãlÈvCoƒþD\Ë-dr›JF°$ɽÒM{Pò<ðã4ìŸbxçrû‡ŸÓ/]QÂTšÊÓo:×OR¥@„˜r—‘Ñ=ÎÃ/D÷Yÿ\€endstream
 endobj
-1034 0 obj <<
+1039 0 obj <<
 /Type /Page
-/Contents 1035 0 R
-/Resources 1033 0 R
+/Contents 1040 0 R
+/Resources 1038 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
+/Parent 1006 0 R
 >> endobj
-1036 0 obj <<
-/D [1034 0 R /XYZ 56.6929 794.5015 null]
+1041 0 obj <<
+/D [1039 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 170 0 obj <<
-/D [1034 0 R /XYZ 56.6929 769.5949 null]
+/D [1039 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1037 0 obj <<
-/D [1034 0 R /XYZ 56.6929 752.2692 null]
+1042 0 obj <<
+/D [1039 0 R /XYZ 56.6929 752.2692 null]
 >> endobj
 174 0 obj <<
-/D [1034 0 R /XYZ 56.6929 663.7495 null]
+/D [1039 0 R /XYZ 56.6929 663.7495 null]
 >> endobj
-1038 0 obj <<
-/D [1034 0 R /XYZ 56.6929 633.2462 null]
+1043 0 obj <<
+/D [1039 0 R /XYZ 56.6929 633.2462 null]
 >> endobj
 178 0 obj <<
-/D [1034 0 R /XYZ 56.6929 587.2939 null]
+/D [1039 0 R /XYZ 56.6929 587.2939 null]
 >> endobj
-1039 0 obj <<
-/D [1034 0 R /XYZ 56.6929 559.4406 null]
+1044 0 obj <<
+/D [1039 0 R /XYZ 56.6929 559.4406 null]
 >> endobj
 182 0 obj <<
-/D [1034 0 R /XYZ 56.6929 362.928 null]
+/D [1039 0 R /XYZ 56.6929 362.928 null]
 >> endobj
-1040 0 obj <<
-/D [1034 0 R /XYZ 56.6929 335.0747 null]
+1045 0 obj <<
+/D [1039 0 R /XYZ 56.6929 335.0747 null]
 >> endobj
 186 0 obj <<
-/D [1034 0 R /XYZ 56.6929 132.2109 null]
+/D [1039 0 R /XYZ 56.6929 132.2109 null]
 >> endobj
-1041 0 obj <<
-/D [1034 0 R /XYZ 56.6929 104.3577 null]
+1046 0 obj <<
+/D [1039 0 R /XYZ 56.6929 104.3577 null]
 >> endobj
-1033 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F14 685 0 R >>
+1038 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F47 884 0 R /F39 868 0 R /F14 689 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1044 0 obj <<
-/Length 2916      
+1049 0 obj <<
+/Length 2937      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥YYsÛÈ~ׯà[¨*žÁ`pÄO²%¯½©õndnR[ë}€HHB–h(YI忧¯ÁEÈvUŠUœ»§»§oz¡à§©
”É¢E’EUÚ.6û3µ¸ƒ±δÌYùI«á¬×ë³—oM²È‚,ãÅúv@+
TšêÅzûûòÍ»‹_ÖW×ç«Ðªeœ¯l¬–—ÿ8×Z//>¼¹ºä¡Ë¹òöêâ<‰–ë_¯¯°Ge0/
-bY¹þÛÕoç¬<»Zwü
eÐÊ sŸÏ~ÿC-¶ Êg*0YjÐPβp±?‹¬	ldŒïÙ}<û{Gp0JKçtbMØ4Lf”š9¥Ø,ˆ
¡R.*–µø’ﻂõ-—¹æ»]ý¸:¶y+3¶es®Óe±iËéz¬»-WoŠ¿¢fàP²Áþj±2a†)ï<&+µüO\¹¯]«WøÜó꿯˜ðH°	áõ}é|K}ûTåûrÃ
ÞUFÚšKwÜlŠBD¨«Ý×JQF{/‚²äŸ…kEò\(¹ò®òndyÎ	…àÂOù†‘ˆ£â˜LÊÂA)g¤…Sá-¹
e2’¤Y‹UÙÀÆQ¼Ë
ÒÄ°üvž…ËúÈìó'/AÕŽ•ÁBæÂi~SÛ‰ö5ÏáÖ¡~,šÛãnFžPk¨áU¿:Ô»ró4#O\'&–Ù®…ÉûÂsWVS‹t˜(ŒqbÀå€Ø>6w®\œ¥›¿.8u–SºÈÎG4øZ¼"´°”Æ
-u6béÄk»Yßbä„2tzFåZ8˜ºŠ”
-²4´xøAñT° >_iþsÕ4uãæ](Ì‚0V‰¸«N–:ãzS8WVwÜGÑAÇËõÇ÷?pOg÷PßÃÔüŽ|Z
-!0™mÅw-”•,-Š&ßq£hx»Æ¿‡Yº|Ëù³û5Ç»8¶è!;îWVuµ"·A;¡ ,C-óǼ³ghº¢Æ0ü¿ÀŽŒAÿÛŸ¯ºº¾æÆ'eÕmÝìó–Ûÿ0 ¹ë±Üí¸v#”y—öØ€(Bt»‘Qv¯ž	‘ª–­ŽÕ¶hÀ;ªm¿nF>‰Òìª[ЪQ¡¡]ú2²&‡ÝtÒPîK·©«OJ…wÇ&G@Æê·žq;`º‘ÑâË¿l)ºB»§K{o…XíiUÛ‡–Ïk$'‡µaäí-cÏ$»C±)qCIý1žì0Z¢ý™0ÅÕX°µ˜0Zx™±.*/ 1ºÁêÅÒ
-aë˜*h^Åå±ú³ª+^…‰
-hÜD)«ûå¬uå„$[	,Ñ Q¼Z4^€|N>”¯J·çÞÛºá~`¸ó¡ÀØ]Q˜&	0áÉè÷ù ÉÐÌF°€ícQT<Ø>ÖÜ‹ÀßQâÖˆeXL¤û{IƧköpFŽî0'Cã8UÜ(”ÒþúñŒ®\WUê'‰9EJ°·Oܸ¯‘qoeÐÃ× ¨v¡]‘N¡†äŽÜý\h‰À°_¿ÿpÉs2¡€÷U¼8^"76$RCñ«oãY:vPï0´B~ú˜­–—pñõ’w­Þ»ÝžÜÑSŠ/hw…g±Æ¨Ä‚;ÏVHÐ﯎eg¤ZVå²wÎó,à9”¯Ã=Äh)¹W¾kïëãrg0— Xǹ%t8P²Wš9¾q˜ø67°‰½à'”Nb°ð7kÊCN)§r‚±¢’t½eÅo ø0æѱ>N·’ä¶à¡Í¾ô)ºC#Åv篯ðFfú™Å—|#hcø‰ú,ÛyÀ¯Hí¼S¦Y¦ö;`Žõ“'P®O–ÿ¼/
åe¬&'n±t
T3eÇZñIý”½(4:Æ·ØKmjìÁ)F[ŸAàhX³=2Áno[!ÀןD¤púð€¨=È,8±²[¸’<²šâ
t’U‘¨Ð†cšÚ÷þDÿ0ç>ûi þ"µ%	ÖNr‡^w<ꦕ×ÄË?^½á‘Ñ>4Ú½Öåþ=_„}À1ÿîÄÏ—±¼ÚåõÛ7ÜZc¹‹ýº`,ÌŒæÞ˜“iL‡Žk‡ãܼͮ„ ðÀÑúäØ3y«rxÓâŸÎÁÄ@É>™¦ Æ¾¶ãŽÒïU4èýtÞ)îeþM	*.ßÏ^!Á+ŠE˜Ú]º¯%î•ÏÅåC¹+:”ÑîàÚî³Mã‘@Uv_br×Õ™|Ä}–™}G7ü	‘~b	ÆöHFûÇG#Ï«&¾¶Ð“/Bì–§ÈÓ.L’û‹‘·Rèé/÷Bî–KæÞDÂý`#y7$n+áÎ-]ú'¤þÔS™{7£¼øj¢§îQ×ú§RZwkoÛb˜\ôwõ¦û^ܼôgã_ÚfŽ‚gNa¢tùÖÆwðÁrøº„kájô¼~ó‹¬iå³ÖÞ):A$x”§NÑÝäë`[×;8ËÃÁZ…%ä@-›âN)…‰y'¯Ú=ã3W'“aª=N«œ|\=
‹\”íîÁsŸ±
ðÛóÌç+Õ}wú¿?q÷ßô£$0i΃c†Yâ™BÆC;å¼û~Êúÿ@3d¸endstream
+xÚ¥ZYsÛÈ~ׯà[¨*žÁ`pÄO²%¯½©õndnR[ë}€HHBh(YI忧¯ÁAB¶«RªâÜ=Ý=ÓÝ_¤
+þô"µ2Y´H²(°JÛÅfw¦w0öÙ–9+?i5žõz}öò­IYÅa¼Xߎh¥JS½Xo_¾ywñËúêú|ZµŒ‚ó•ÕòâòçZëåŇ7W—„jGÈòÃÏkô·¿®ß	j×ÐO€£º+7`Š[¤6B: ²8¸bU 0ÛbˆãŽOéŽ (gY–
+¼fA  c£L 'Çƈ#ýlîóºt;î½mZî†À0
+ŒÝua’N‘ˆ~Ÿ‚œÍlx€Ð=E̓Ýcýün°lŒQF€Åô@Š°¿—dzj°fgä(ï€9^ŽSeAF¡”öéÇ3º2ìªÔO’ë)ÀÞ>qã¾yDÆý-ƒNƒ BÚ…RtE:A†Z^;2÷sM %‚‹ýúý‡Kž“	Ìv15p¼D26$Rcñ«sù,¨7˜GZ!»½ÏVËKHü@½d]«wEUíȽ8¥ø‚wâ®ð,6è•XpçÙ	ú}êXö´ÓȪüAöιcžœ ‡òu¸‡-%óÊ«î¾9Ü!wp	Šuܘ[B‡%[¥™ã‡‰oÃp˽øá°Œ@¾!„Å¿á`ؤ)ڭìW'A”™äë×.¸Åž4ÊRx'ÁÀÂÁ	s#$„Q	œµSûð™a[3@JèÄÆ´'ö=ÄžFF •­z$Rav­Ÿ±¼Rö’½oÊ©ÄNÜ”ä'Ù‘“IœLæ-j]P aT%â2üf‰CI,šP<½n£\Ïú Œµ5“Sù2ð,Q}S¼X§þü™KzËqe’Gç¿-Û¢*:(‚âW„öaM`¨’òÞ?wÈE~(›ƒóÏ@½£’çš ŽáêL†ù;
3BkãozÔDÙhîJË“ʺìJv˜Ø¤Ü!f„ÍMU’õa|)”=îóÓ©¯ÞR|­,ä˜ýÌE©ïâß?ó|>­ì…6ybu¡Ñ	[¢MÇÙô^å{ß–ô:N]žcxa$¿7œßcAˆ½à'”b°pŸ·kÊ}N!§r€Â±¢–p½eÍo ø0æѱ>
·ä¶`¡í®ô!ºG{Åvo¯¯0#3ÃÌâK¾´1uüD}7ÛyÀ¯HݼQ¦Y¦ö;`Žõ“'P¬O–ÿ¼/
äel&n¹é¨fÊNµâƒú){Qh4Œo±—ÚԌ؃SŒ ¶>ƒÀð:`ÍÈ»ý-Ø
+NyÂéã¢ö(²àÄRÈn!%y(d5ùè¤[EzHL BNm`|Õ¾ð'øÇ1÷ÙO=ðgi’A$´1#w“ MïÁì›–Ðt\~øøñê
ÏlE=¤¶.—'aì˜<:8îË…Tÿôĺ‰	ayýV6­±²†µŸÐØÎ3ƒ#N²®ÆEǵýá¦*7/Á<°…>þ†]hb&)÷ø¸.[\l$Áz76ºJŽ¡$V÷E‹ž€å3"Ÿ9ÍùåÉ.ßù/	y]“_Â0ïÑ9q¯|\.ʪèG<$¸ƒéúO8­GuÙ•ÉÝð…çèƒÆäÍìs ½áçHðúSåã@atxˆ4òÔj¢ñË=ÿ"ÜîxŠ<óÂ$ÉeŒ¼›BÏè¹[.™{	÷£ä
‘¸­…#8ºtéŸ#úÓ@eî
bä«#=õ¼Ö?ÓÒú¾ëŠÝþ(鯾]üMrûÒŸu›9
+~Dœ9…#¥Ëw7v£OŸ;ÀÚ%¤ˆ«É{ðúÍ/²¦“O\;7}°èg€žÀ#>uŠôŽ¾vMSyðYî÷þ¢
¸XrX¨eÇÔÃKab^Æ£îñ™4Ê$A˜jÙj÷ì^4Êö9GðÜqcüŠ=ó)Kõß þïåÃDI`Ò4œÿ&Ùc†Yâ™"—h9￪Ÿ²þ?!fuˆendstream
 endobj
-1043 0 obj <<
+1048 0 obj <<
 /Type /Page
-/Contents 1044 0 R
-/Resources 1042 0 R
+/Contents 1049 0 R
+/Resources 1047 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
-/Annots [ 1046 0 R ]
+/Parent 1055 0 R
+/Annots [ 1051 0 R ]
 >> endobj
-1046 0 obj <<
+1051 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [418.3461 669.297 487.0181 681.3566]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1045 0 obj <<
-/D [1043 0 R /XYZ 85.0394 794.5015 null]
+1050 0 obj <<
+/D [1048 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 190 0 obj <<
-/D [1043 0 R /XYZ 85.0394 648.2128 null]
+/D [1048 0 R /XYZ 85.0394 648.2128 null]
 >> endobj
-1047 0 obj <<
-/D [1043 0 R /XYZ 85.0394 619.5539 null]
+1052 0 obj <<
+/D [1048 0 R /XYZ 85.0394 619.5539 null]
 >> endobj
 194 0 obj <<
-/D [1043 0 R /XYZ 85.0394 444.3683 null]
+/D [1048 0 R /XYZ 85.0394 444.3683 null]
 >> endobj
-1048 0 obj <<
-/D [1043 0 R /XYZ 85.0394 407.9434 null]
+1053 0 obj <<
+/D [1048 0 R /XYZ 85.0394 407.9434 null]
 >> endobj
 198 0 obj <<
-/D [1043 0 R /XYZ 85.0394 220.8457 null]
+/D [1048 0 R /XYZ 85.0394 220.8457 null]
 >> endobj
-1049 0 obj <<
-/D [1043 0 R /XYZ 85.0394 183.187 null]
+1054 0 obj <<
+/D [1048 0 R /XYZ 85.0394 183.187 null]
 >> endobj
-1042 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R >>
+1047 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1054 0 obj <<
+1059 0 obj <<
 /Length 3094      
 /Filter /FlateDecode
 >>
@@ -3510,76 +3542,75 @@ a+
 ScvøÛ»Û7ÿøñzª2„"rU.NÞÓ±£ô•Q÷g;.Å×=˜j¬Zb#÷—Dÿ·¾=âÓô¦yÕÈ_ﻸo9–Q¸=û~·0À¸÷jž§ò²JZˆoC®Ÿ`RÛÄš¢8Ó©€àÛrÙíÚ¦ªÁ±¼	ÉÏøòä‰X?,}dzÁ˜³ƒg—÷L²GÀ›±àO{ÂrÑ#bdõ¯
ç×]`©“ª“s;ýÝJa]“™?¬k@ÂY¡C¸»»÷Í”øT’ËTN¾ïøº?=ö-\ §áqEA<,™ˆûH€ÊnŠ
܈øŒûÒSS)–IøÔð˜
LJwEf€®'ŽÃ”Ç­^-ªW/
 1ôr5ï7xŸFK97uBf ·õúð–BòR½FšŽ¯Ã^Gçg‡ºæWœ»;p†n¢¡†=¹ÇY‡ÏÑîÔq—¡û©ª0yààŸÃð›ñË}–.²aŸ…ÃØgá¢#¢~‘#Jñ3^׶q%6\š¿¢"¡¯Uú0æ?‰rŽÀC€7WMæƒ4Ñ ûA'•|®ù‚Ž*1Eô*Ð~¥à×\§PáBxW㺸råaÓ³¢ÊÐMŽÞóXÞüÑA~ëàRßÿ¾/ëM¿ËÃa¯9úšð¹÷®qå–L´‘b²}Œù€ZÃv¢!$ÔŸ’éÉ?à¾zÅÐ#"Š0ê?Û‚~M=üœ—„?óN…`Œç¨fU„GøSvB@xÉ8’h¬ÁV.ÌO%1™æIšÇºÛ(®«©’ ˜LŸ<Ï´Íãçêݲ;qøºñ¤òš¸ŸŽ1Oýk‡6	þ?ÆÄ?bˆX²üÏÿöqüOŒ¶Vÿ£c\©YlÂLáµUvÆyøÿsÖÿ¤‚-Lendstream
 endobj
-1053 0 obj <<
+1058 0 obj <<
 /Type /Page
-/Contents 1054 0 R
-/Resources 1052 0 R
+/Contents 1059 0 R
+/Resources 1057 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
+/Parent 1055 0 R
 >> endobj
-1055 0 obj <<
-/D [1053 0 R /XYZ 56.6929 794.5015 null]
+1060 0 obj <<
+/D [1058 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 202 0 obj <<
-/D [1053 0 R /XYZ 56.6929 769.5949 null]
+/D [1058 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1056 0 obj <<
-/D [1053 0 R /XYZ 56.6929 747.8139 null]
+1061 0 obj <<
+/D [1058 0 R /XYZ 56.6929 747.8139 null]
 >> endobj
 206 0 obj <<
-/D [1053 0 R /XYZ 56.6929 540.916 null]
+/D [1058 0 R /XYZ 56.6929 540.916 null]
 >> endobj
-1057 0 obj <<
-/D [1053 0 R /XYZ 56.6929 511.3349 null]
+1062 0 obj <<
+/D [1058 0 R /XYZ 56.6929 511.3349 null]
 >> endobj
 210 0 obj <<
-/D [1053 0 R /XYZ 56.6929 239.6059 null]
+/D [1058 0 R /XYZ 56.6929 239.6059 null]
 >> endobj
-1058 0 obj <<
-/D [1053 0 R /XYZ 56.6929 207.3747 null]
+1063 0 obj <<
+/D [1058 0 R /XYZ 56.6929 207.3747 null]
 >> endobj
-1052 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F48 885 0 R >>
+1057 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F47 884 0 R /F39 868 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1061 0 obj <<
-/Length 2903      
+1066 0 obj <<
+/Length 2923      
 /Filter /FlateDecode
 >>
 stream
-xÚµYI“«F¾÷¯èx«§Ýˆ¢XÃ1mOûÚl @b‘-hbþûÔ´ÔÛá˜Ð¢2++óË­
-WýÀ«,0,TøWIá«῰¯6¢µ_@Æó‘3}‘­Ôš‹7@¥6j´š”ÔÍéà{«ö&ñU›µÐP¢ur¶±Í[·ßÕÞKK-4|´°«wzùõwöÕDÆô^X*²ðzE/,…{õ_x2a>ã½Ì_¦…À*YZ†ŠeF9©”Á"(Œ9H`1ƒ8¶ŒØµƒ{XØ ´>,“$F	í…ù¯®ç!|d©¢{qHGÇè
È•Ð<VF¢ƒ•ÆV’M&È3.æ~cYγâ'©7tÏKŸ„™ÞåËBä	žÕ±â|_¢ˆE7:Ç–‰ÍA°d|À 7rÄ)+qMOð•Ä±2J&.H(àC(ºé»'‘ž„QL©W7q( 0BåF²ÏË|†#ŠŸ~k—àÍóŒ"åpÿÆ
-lr݈nf„Õ->†évɆ€™òýæ%[çGÎB%"ÑøiÆhko¬'I¨HdåÊOØQÚøð…Õù‘€pŒR:<†.•°‡_–a”™LWðZl³CJ~@¬Dó§"Dyɲl¥8$ìs„¡ bæVt±¢2|‘ÙÍ!Œ±õMá*X	"õ­g›?ø2¨˜€¨@÷ih}‘!à g\I&ôÁQx‚«èÇ,掑«'‰sÄGù¹¬Og+Nb:³£ëü‚— BѯŸN@¯†ç"¸ãŸKL€C.äó8ÌòÿÉòG›> ¬0Päá³Ëýsœ9p[¸û‹GS+&~Ä€‰QT—‡2ø€‹ŒÂóÒÎ3’,€À±Ð‹î¹&¿±¨®ÄW‹$)"}ˆI!
-ºˆâ,\ÈüJtâX Â?‰œˆl–Ø<¹py+ɈBW™ÄLTKý!A•ùOûƒV<úeP“”ÎÃ!‰ ËüÀ¥»dwAf®(?nj‰H‚1Û%{XZ $FxñÑÉ’°+ÛXa$Ô·2V¦ÄŒÔÑÀç`ûc{xæ-R(2åèâÞ0;:G‹6Ïf1ìp}Æ\¸res¤b’Ñ“LÒ’/ŽÕl±Ÿ/ɘ0€QœP>Ï
tÚ
¾ðQzLB;ÒŽkÐòœ›ó†£ãµœˆø™Do¸?&¸ƒBX©‘–Žæ	Jdä¹6:vƒ¸*‰²,ÿÉ°A%ŠÊCO£A‰„ÿØÉÈ4Á’v üúYÜЋiY~®)6èiÝ\‹˜7¨´\8UfŽ/Úí EË)ŒEã4ÊN:ÑMÝ÷XãòRc~iby à1
-”¢4’°È8³^øÔ<óúTàì_l”©â×ÈÆ›˜VlDîö3;éÓŸ™ÝÍì÷…Ñ3sâ¸Lfhœ}Ôl˜"ɾOºjç°`	VêÝ>i£“µü3~*Å¬(”`†äPˆ&‚0¡S¨8»»”N⳪žd%&cÊç…º™‰%§SD¢Ç6LÌ|‹æHÎâ~Nœ0rTn/W–Ƙj†t
-«‘w²‡Ì
-¬¯ñPߣe¸8‘¿‚\DÈg¥¤•žLæçÚ’®YÛQpâCß+¶EÏ"B"AÈ‹98s¨`¼Jzt
Ý£ïËÔMfF^è÷äs’ž˜@݉FÔ W2ϯˆƒ)ƒªK’S¬8zL:}PßàADŸQˆjÜñŒ”GVô5¯Obæ@%ß
h愤¦ñ2º¸ùNX¯|œˆŒÏÓVàœÄäð$•jcë{ÏÂ58¤Ô­õl+­+EQ@ª@¨PÛÅ¢  Qvu„	;÷kãzÆŠFÔPĉn#I6Gʸ˜%Ô=ã£nX_H%ˆ$új½gZæ×(ñ³$•ø˜¨{ O¬øiñùižÔ9ÈsÙÉLb§ïŸƒ/ŒÐÏÎľK³¨°¦h}mWõRç²»®;ÕºÅqí Q^äýÞŒm>½ÞÇÊÒö†i¿Ý-!´µþÅÔNÄ	í4W§Ú½¾´øVzR’=;HU­ƒö®µàô7bãôýæ×›	Ǻ¶êÞÜ 
-Fd¯ªýa«mVKMtÏ—ïü©×Hͳku·óvøÕ°fÌÞo®ÎQƒ®6¹øÕ0]Îäú²ê,Íûø”™8o¨Ž×ÙÁ›»ö¬æ6©†`¬NY¥Æþ3÷O§ýß>½wß<¸é
-¹›áþRÙ—Ð]‹“„g39]æ˜îè£ÖlÎ&5fÔRÿ(Χã`Îß‚j×kÇú¤·¡}¿·±9Òo¬@žž6Át:­QuÀpä;ô£Ã‹èÝ8m5µ°.§­{ïG½ÅÞm;…ËëH›P4Ø2‡'ñ}}Ú&ÃñíiCnÜûá~X]Ñ‡íª¥g˜¶5»úØœ³enNÇ]±nOâëûzcÞ½õPïöÚ;~È›iØï:ws“N¹ízíÓi™ü Îz
Iñ0]÷;µ5»Ð'·}wºòÍ“=îµOïtŽk³biÃZ¾ƒ›½î9JÔèî´q¤Û·Á¤Í]Vj³:«÷&T¡6(3BêôÖžSÛ4… ,.ûù$Þô:V³¡¥Ëut™l¬xÓìÎ.N³Y¶¿ÀÍû—­cYjOóÅ–s¸§ÉhÄÍGŠ8ä}ÕíÊî¶ûRoþû—\2Mú'ýd_~z\Í0ÌûÇ¢P‡°ìÿ
¶H¦¿ýoÊçHH=(ËÜç%OŸñ—stÎÏ•"$}Õ¼øÛåGÕÿôtúendstream
+xÚµYI“«8¾×¯¨x—qMua$±FǼ=ï;xëžØ,6àubþûHðò˜yÝÑ1áB™Je~™ÊLaðÎâx—x†E2÷.Êó€×½7öÝ´æHy¾2¦¯G®ªòVþŽÄw™‘(¼+›YÃJxWŒßJµVe¤4&_gKóñÅl©RŸ}J•A­Q§¤ú`Jß•‘+)ê¤g€Ìó¯“Ò•˜mÚ¨}üSé¼5”\ÃG+‹ˆz‡·ßþɾؘÎË YâßÏø…e€,ÃwïãÃse3îÛômœ| &K‹Pá‘Äð` ^fQ‹áG‘©EŽåßß$áeèa™(2	E3<Çw¢8Ôâ Œ(õìÄ6¥	ŒH~€"–á8‰KqÄñÓm,£¼9Ž‘ÅîßYž
Â\®ÒÍô ¤ºEûÀ7ß*Ø°#q|¶ß´`+À“ó‘±P‰X4yÞdk1EÉ"ƒxI~†ò;>6	|d€ÃêøHÀ8†W:Ü5a^–”™TWðžo³ÁJ~!žA¬HÏ39ŠŸK–eKµÀ'!aCE"fj†'3,ÂËØnˆ1&r”–ˆaµµkæ›?ø18™€(_óhh½HFˆH)Wœ
+}p™€%mŸÆÜ>t´ØLâóQ~˜& |ááhFqDg6t—3’”P´óÝ	øUwwôK)@ìB.‹Ãôü?YþhÓ’d	zv¹wŒR®sw¿xôjF‰	à@ddç¥GÀ‘þà#sœø3À9F”xð8zÒ\ÇÀÀ’7ç•èl&‡“îR€ƒ.¤„(
—d~	:Abô‘°Í"›.’ÞŠD2ŸÇU*1Õ'ÁBˆˆÁ)@úÃþ ‰•Ì^ÔÉ‘ÎÂ!± Óø"©»`w^bd˜'Œ7Õóƒ˜cº1>ìAa‚‘ç„G'3X¦hc™qÝJY™3¾pEc$€žƒíçöp,Ê<š! ‹Ø”½CjqÀlèMÚt<™Dt°!ù™p‘Ì•Î%3=ÉLJRÂKb5]ìeKR&`Å”Ïuüvü>=¼îãÀ
+µ½íè4=gæ<…†nkd-”AbyÆá©1© •*IIÇó	JÉÈultìøpœ%IúƒaƒS䇚Fƒÿ±’%Ó	–´‘×{rÃ/†iz™nI²ÁOóâ$±Hx3ÑSk‚dqf†\^¶hÉKNn,§àQÚé:>ͧׄ×k'Žb\-~ÞÊ!1oø¨å’ãyÇ$P86…_ÆVxiÿì9‘™1ú)“*“Ey¶Ç›O$LIªpÊœ\Uœøš““T dàë]çñR˜]W"¦ »!×üÆ	ÂéúKÀ—–%»p"#AßMq÷"–K˜Ë	‰'÷@’I‘C”ð÷„éó@˜$S±]“=>¹²À‚å©Ü‡ùrf0ÏðPFÏýùF%C^¤ôôøV,¹s8￶é|ÖÎ×¥¬c1j46]¤»“uSSÎÓÎ%lî.y°:
+mqtëéÖø†.²IÕx€º![N­[³Òr]£ÁÝ–íýÄÖª]ÿ¤× *{+{g¨{Ì¢ ÜªÛ)õ¼¾ëß–¨(ŽoW¸¸r;w>¬Ô•Ñmz’MÍÛJ3 ZÍmµ§ÍâåiWv}~UÙo—–½ù6
7ôz;C»úþk~¥6‘€XÿÎU«š¨NÊk³Þºîyg®,æSGXxA§·nÊSý ‹®Èvë÷´˜ ~‘ŽeWUg“õδ@{Ô™:†×E«kÍumn1í®·f™ã§Ý£Þ²ü³ÊoÍM?>‚Õ
Œñö³P¢S ²Qg¦x”åùMéatî¥n_–ã1d¿eqúÙëªÊ~¬ 8+
+*Ïx{2¾Lõv‘ÕƒÃY¿qÛåaU‡›±a]Öz]©¹*[›T
Ç1¯½þà¶h¢o¿æ`¨{ÿZ“ÐNB.Id³AxOv‹r.|+6èKöqë"™|šCæ`@1,@â3
+æEóö¸\ë¤_+ó¶­!ÇqVoWRÔ®º){5±uÚœ—­rÕ„°é׊"Ã
¿ÛÙƒ¡Å]Ï·¡<·ÜþNÜ®7s„,µ{rB¥B¾Ù§ÊX½U×¼]
+›+ɵü«¢¶"£Î¹¶äíîJ¨¾_¼Êl5‚¬c)ÎÅñË §‡Ö¢Üí7šF¹ÐDçxúÎ:µ«qtÌÖqw\¢·èWôÉçÅÑ 5Ño«£“W®ó‰T—í¹qžü"§5Åv[tq–®Y_Çå•1+WØdñ~wÚÿ-àCÒ8Ò7m»°»ˆàO¥}_Ï È?›	òA2íÁW¥^ŸŒ*Ì ¡ü,ÎÇCÊ]ürÛªûꨃÖu;ë—¡1Ð.¬z@Vþx<®Pue€K,|ù4;›…ŸNÏn*þ ¹G­`>î©í[7ìÌVèfYW4?a·
+-rxÝ–‡u|ÒmÏפڭlûå9¡ß,›ZŠiSE‘£
)[äæë°-T­Qtþ\®Œ›»ìkíNsÃõ9ãtÛöÍX]Çp½‡Ûë¸H	®WeÝš¨
ý¨]v[­¥99ÑG—m{¼ðŒƒ5ì4Ÿ'Ü6Y¡°`Í?ÁÅZvl9¬µ7¾š$Ò­KoÔ„§…R/OüÞⳎ¤öŠŒ[e«cWVu¾Ç˳Óv:ŠV–Y¯©×ù2> endobj
-1062 0 obj <<
-/D [1060 0 R /XYZ 85.0394 794.5015 null]
+1067 0 obj <<
+/D [1065 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 214 0 obj <<
-/D [1060 0 R /XYZ 85.0394 717.5894 null]
+/D [1065 0 R /XYZ 85.0394 717.5894 null]
 >> endobj
-1063 0 obj <<
-/D [1060 0 R /XYZ 85.0394 690.1986 null]
+1068 0 obj <<
+/D [1065 0 R /XYZ 85.0394 690.1986 null]
 >> endobj
-1059 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1064 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1066 0 obj <<
+1071 0 obj <<
 /Length 2379      
 /Filter /FlateDecode
 >>
@@ -3596,48 +3627,48 @@ tÒ“'--$
 ?Qù=‘ê#ÏgÙ¥XíÀÕXu¾ŸõùŠ¶€$y&zT¼çNª	ÿµwQŵ³»Wdî¡!æÁûî¥ë5”ÓÂ}…×ÝlÆ`DB"zÆ^gÈŒ}Ò]„£Ã™ý÷eç-ª]™¢c$È6É©Å6uYÖ‡Á‡z_ú4ë'|S‘Ë5ƒˆ™¹§¯L!vèý3ÿ
 £”òåjÎ$PšÀƒÞd·ÉD,ŽTŸllF¾É Ö~E9;ýMØË¡®'Ù‰'§+ë²/-„Ö¿fŒ¾·«;ô'#±)–Ï}‡äÖóEàà»ÿ½pü‚¨c¦°Jš­^àu‡Õ‹ê•rÎJ^hÞÿâ¥êÿWu˜endstream
 endobj
-1065 0 obj <<
+1070 0 obj <<
 /Type /Page
-/Contents 1066 0 R
-/Resources 1064 0 R
+/Contents 1071 0 R
+/Resources 1069 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
-/Annots [ 1069 0 R ]
+/Parent 1055 0 R
+/Annots [ 1074 0 R ]
 >> endobj
-1069 0 obj <<
+1074 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [349.4919 384.4828 408.4801 395.2672]
 /Subtype /Link
 /A << /S /GoTo /D (ipv6addresses) >>
 >> endobj
-1067 0 obj <<
-/D [1065 0 R /XYZ 56.6929 794.5015 null]
+1072 0 obj <<
+/D [1070 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 218 0 obj <<
-/D [1065 0 R /XYZ 56.6929 594.1106 null]
+/D [1070 0 R /XYZ 56.6929 594.1106 null]
 >> endobj
-1068 0 obj <<
-/D [1065 0 R /XYZ 56.6929 562.6395 null]
+1073 0 obj <<
+/D [1070 0 R /XYZ 56.6929 562.6395 null]
 >> endobj
 222 0 obj <<
-/D [1065 0 R /XYZ 56.6929 370.2937 null]
+/D [1070 0 R /XYZ 56.6929 370.2937 null]
 >> endobj
-1070 0 obj <<
-/D [1065 0 R /XYZ 56.6929 341.714 null]
+1075 0 obj <<
+/D [1070 0 R /XYZ 56.6929 341.714 null]
 >> endobj
 226 0 obj <<
-/D [1065 0 R /XYZ 56.6929 214.6004 null]
+/D [1070 0 R /XYZ 56.6929 214.6004 null]
 >> endobj
-1071 0 obj <<
-/D [1065 0 R /XYZ 56.6929 186.0207 null]
+1076 0 obj <<
+/D [1070 0 R /XYZ 56.6929 186.0207 null]
 >> endobj
-1064 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F62 995 0 R /F21 658 0 R /F47 879 0 R >>
-/XObject << /Im2 984 0 R >>
+1069 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R /F62 1000 0 R /F21 662 0 R /F47 884 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1075 0 obj <<
+1080 0 obj <<
 /Length 1913      
 /Filter /FlateDecode
 >>
@@ -3647,59 +3678,59 @@ xÚX_
 veÒÖNϬ—ê¼g¸rÞÊ.ÎèŒÈ¢h¡Á¾¨îý<æBh%ÒËÞ:z³á˜èáhÓ»>HÅôÑhÇ L8[Ú,²j¼œ—D>Õ/…T¿—T„
¬ñØ€0š&îm´Ù­4DÈÞY¢Bž¼è.ÈÜ&ò0§5¤RP¦†³à÷öÆ'çSʯ†í°ÓF^b ®Æû+ìY‰Óò¸ó†_Ž;oDHàJz+ÞI©!úê`Dñ:™Œ¡£Q’â™ÞR-ÅãT!pº Û&ƒè¦H,xÀ·Üór>0“³äÏÇß·;é”ßCÍmk{È@ÁD4¤I¾qž_»ÊÏ_î9×*p
 M&PÄqíèÙi7jÓŽ4¾§YyŸ"A¦͠ì‚d,"û©ì±‰kkÒ;¥)ÏR^Š:”&JÓ×9*—“²,Jן©IW؃È!6Š‚OÆ¥KaäÆ¥ÀÐU§½l†¤(.sÝ«Õ@BÃäf˜R‹eÞj1-£O.拪‚#/`h~>)×­lS€³†1Œ•ô ´ÅhmsV݈jµ75‹Êš5ß²Œ?OdoÀ7*ƈ·ö2Q¥z¦k{WÌåU*ê*¹Ž""!Ú–•ÐMåLÜ žqQ&ÚK¨#¾ºÔ7ÍŽÇ$%£(–qÅ‘`Wm¾œµO^˜9ÈïŠxp:¯çB£àFGBÚ/땱ˆ¡ZkÛµƒ²“íw„¼æº¨ã[½$x(ƒƒFlBLÀ{‰j8K	[|ﶪ,}­UP[>é®S‘ÿº–vY•òZ\Âòâm$s–ò*/£ 6*,¬C:‹æZ¯Hy‘çAúƒÛ'†zQCz2.–¾‚Dܯ%‘H–EeACd.r‡ZÛ²¾À?ÐÐ’«Ìˆ­)²¬‰¶&ŽHäǨí=Q»i¼#³ŸÆiîP 2,àÁǯé+´'¥9¾¾z†oÔ’nÅ›9l¶,Š…;Ã1#?bÍZ=MZ×UÔ„nçËç?j£sƒàç®ܪŒý-nñ´®Êo1<Ø	èÐC`¯gFï—N‚šî-Å9„b±K¡û@6_æúx´á&pé_–Gú¦sj½7Ù,Íó²üq‹R-êrBd:]QL¤T1/­{¨˜Û¼`É'ÕJʼŒ4Á(Õ¹ ÄÒ3îïÄSÒ§P˜	XÀ²zÖ¡ƒ‚N9ýl¨	ñêî¶aM:¦¸à~_VY(>Y2h£l—y©%«a3Ð%šÞŠ¿­6^:ꬕÛÌ[‹|pA˜ªj?RøÃx½Í¬m­ÄÞtd¨æ.Ú%Ô­¢Z¢¨ù´+¡Ö–bíî ZÓ@BÍ`*ƒnèÜÏኻÂ;Ë	züÊAŠy¤Zy”þÚhêûkdv–nwuhg‘¸ið©ø6<­ømRËi´Æpsó‰Ø‡ë®5kw"wT­ÆxªîæžRÿ4xÍË¢Ùªn@C@gçá‰à
 vþjÌÖòF©›ñ3VÈj‘æ‚GÃÔèîŮĭçŽæÕûÔÞ$>1‘ÓcJç¼ZO¥=«rþ÷Ðή|u×6è€Eô×#X7±‘B\áMò‘˜¡ŒúÀ’½Rá	ò,²Ð³ÈYé¶zy­@ÂÑ€¤×eOÖÜ^_¼…RQï´
Xä$òbÆêpE_I«¿¢ñâ§zRvÛ”Î×ô·A4¨Êù|ÿ0;Š&­ª¢¾îUÞýò4KŒ_E‘â÷Ƶ¯Qd{‘¡O‹“‘änGE¸onW›?\¾]îÿ§endstream
 endobj
-1074 0 obj <<
+1079 0 obj <<
 /Type /Page
-/Contents 1075 0 R
-/Resources 1073 0 R
+/Contents 1080 0 R
+/Resources 1078 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
+/Parent 1055 0 R
 >> endobj
-1076 0 obj <<
-/D [1074 0 R /XYZ 85.0394 794.5015 null]
+1081 0 obj <<
+/D [1079 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 230 0 obj <<
-/D [1074 0 R /XYZ 85.0394 769.5949 null]
+/D [1079 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1077 0 obj <<
-/D [1074 0 R /XYZ 85.0394 576.7004 null]
+1082 0 obj <<
+/D [1079 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
 234 0 obj <<
-/D [1074 0 R /XYZ 85.0394 576.7004 null]
+/D [1079 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-1078 0 obj <<
-/D [1074 0 R /XYZ 85.0394 544.8207 null]
+1083 0 obj <<
+/D [1079 0 R /XYZ 85.0394 544.8207 null]
 >> endobj
 238 0 obj <<
-/D [1074 0 R /XYZ 85.0394 403.9445 null]
+/D [1079 0 R /XYZ 85.0394 403.9445 null]
 >> endobj
-1079 0 obj <<
-/D [1074 0 R /XYZ 85.0394 368.2811 null]
+1084 0 obj <<
+/D [1079 0 R /XYZ 85.0394 368.2811 null]
 >> endobj
-1073 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1078 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1082 0 obj <<
+1087 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream
 endobj
-1081 0 obj <<
+1086 0 obj <<
 /Type /Page
-/Contents 1082 0 R
-/Resources 1080 0 R
+/Contents 1087 0 R
+/Resources 1085 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
+/Parent 1055 0 R
 >> endobj
-1083 0 obj <<
-/D [1081 0 R /XYZ 56.6929 794.5015 null]
+1088 0 obj <<
+/D [1086 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1080 0 obj <<
+1085 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-1086 0 obj <<
+1091 0 obj <<
 /Length 3113      
 /Filter /FlateDecode
 >>
@@ -3719,47 +3750,47 @@ Hy
 ³ÆGZP[ññk(ü[wÔ6-µ]_6zü´ ‘5hÉsª\0Á03
 “ã…õ"GÌX€2Á K!§óÝ–(Š¯x¼‡]Ç^ 2Èíc™¨/Öìªn>EXX'»ÃîÅOÃ;"¢Ùmðx¥Z 5=J·[S­  2³¾ÍAèAøñ¡êŸ«ªÉ²œÈK’dB©
›Êó>”_>u|¶ô&2¶‡œ­Úy¹Š(FiÁ©Ï“Ã[ã’Ï{¬—=+K£z©Â©«Â&±ÂPÙ÷å|qh÷;”ñÄÖBý«ÒaMSñ\ðt¾•‘’‡ˆ¿Û@ö/RõùäÁ$w>ÊáOù•
–£Îì¿÷TÝ©8Aç­‚¢‘uŽ–±<	vÚÑŸñVáÿÑVUT­ÌÒR‡”«çò%¾(¢øpðzh(ÐËš2=Hkªá	RKíCzJ4ŽçÓ¡qšñÊÔe”EöþœqƹlÈ…“ÓkçAÊ%nÕ™]!ÓØ«3¡„p6˜!O@þƒWLcòÎæAÐ/†ƒûw¹^X|Ü[×ú4yWx´mnÆè€ð2£™àk¡¾„уÛÈìùüa5œIm•VLr-oÆæ€ð2›J[˜þe\ÆÊáZ‘>Rï׌ւIiÁ
ÔEÎÙ[Òô<¯ ñµyþ¢–[HÛ¨„¨“kÙáIúUZî?¿Ó5endstream
 endobj
-1085 0 obj <<
+1090 0 obj <<
 /Type /Page
-/Contents 1086 0 R
-/Resources 1084 0 R
+/Contents 1091 0 R
+/Resources 1089 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
-/Annots [ 1092 0 R ]
+/Parent 1098 0 R
+/Annots [ 1097 0 R ]
 >> endobj
-1092 0 obj <<
+1097 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [356.2946 363.7923 412.5133 376.6291]
 /Subtype /Link
 /A << /S /GoTo /D (address_match_lists) >>
 >> endobj
-1087 0 obj <<
-/D [1085 0 R /XYZ 85.0394 794.5015 null]
+1092 0 obj <<
+/D [1090 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 242 0 obj <<
-/D [1085 0 R /XYZ 85.0394 769.5949 null]
+/D [1090 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1088 0 obj <<
-/D [1085 0 R /XYZ 85.0394 576.7004 null]
+1093 0 obj <<
+/D [1090 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
 246 0 obj <<
-/D [1085 0 R /XYZ 85.0394 479.565 null]
+/D [1090 0 R /XYZ 85.0394 479.565 null]
 >> endobj
-1089 0 obj <<
-/D [1085 0 R /XYZ 85.0394 441.8891 null]
+1094 0 obj <<
+/D [1090 0 R /XYZ 85.0394 441.8891 null]
 >> endobj
-1090 0 obj <<
-/D [1085 0 R /XYZ 85.0394 424.9629 null]
+1095 0 obj <<
+/D [1090 0 R /XYZ 85.0394 424.9629 null]
 >> endobj
-1091 0 obj <<
-/D [1085 0 R /XYZ 85.0394 413.0077 null]
+1096 0 obj <<
+/D [1090 0 R /XYZ 85.0394 413.0077 null]
 >> endobj
-1084 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1089 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1097 0 obj <<
+1102 0 obj <<
 /Length 3978      
 /Filter /FlateDecode
 >>
@@ -3785,109 +3816,112 @@ x
 º&TóÄ®?àÝ"­D¹Œ…©d­ÜAigx:Ã+9‡ÐrùNé	²~Œ¾¹9úÝΉp¦OU‡îBI\@´­>¯U}¿ª»Ç¢ƒ,¬œá§8è2ÜïŽ)Ú½Èmç¦â­Éß||¤´Œ×
°ÕÄž*<ðÆ@i/ÃgžoŸ:àYâ@#l}´—Nã=}>7Ú£œÁF»ÌwÈ„:Å©mõŒŸTí|÷D]þ«›WŸëÐåkßׯoCË_º8 úJå\—x6Ÿý>æj¶¾Oü¿ÍÊùZð8¬ÂN…&ÀÌfø]ãÎ÷ÜXLÔ¡êõ (Ýd8ËÒ>øD”è³ZäOD°3¥tòöîX%Äï«>Ý©ú®Á¤ÎîutŠ—€‹ùTöÓD&_Êéê0kóÙ,úqë}w,0Eó¯á±ûúc=¯ö„÷ð–>írÄù?ƒð‡0€¿Ä\ÔÛƒæˆn\ów	 ø[yO«D^?ðͼ^>ôqȇmDõ>ÚÞ+õc ñ±¹KãÃÞfóáBô ó¿öí;ôÿOFŠíû>ä?ª-|MK3©_ýíîæËf	lkíæk·-ß1²wD
 I"øæ<=¡yõÿGÁ0Lendstream
 endobj
-1096 0 obj <<
+1101 0 obj <<
 /Type /Page
-/Contents 1097 0 R
-/Resources 1095 0 R
+/Contents 1102 0 R
+/Resources 1100 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
+/Parent 1098 0 R
 >> endobj
-1098 0 obj <<
-/D [1096 0 R /XYZ 56.6929 794.5015 null]
+1103 0 obj <<
+/D [1101 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 250 0 obj <<
-/D [1096 0 R /XYZ 56.6929 194.962 null]
+/D [1101 0 R /XYZ 56.6929 194.962 null]
 >> endobj
-1094 0 obj <<
-/D [1096 0 R /XYZ 56.6929 163.332 null]
+1099 0 obj <<
+/D [1101 0 R /XYZ 56.6929 163.332 null]
 >> endobj
 254 0 obj <<
-/D [1096 0 R /XYZ 56.6929 163.332 null]
+/D [1101 0 R /XYZ 56.6929 163.332 null]
 >> endobj
-1099 0 obj <<
-/D [1096 0 R /XYZ 56.6929 131.4748 null]
+1104 0 obj <<
+/D [1101 0 R /XYZ 56.6929 131.4748 null]
 >> endobj
-1095 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R >>
+1100 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R /F21 662 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1102 0 obj <<
-/Length 2913      
+1107 0 obj <<
+/Length 2933      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sÛ6òÝ¿B™{ˆœX4Aðóú”8vëNëægîfšÎ”¢`‹cŠTIÊŽÿýíb DÓòõÚÑÁÅb±Øï%f>üÄ,<_fá,ÉB/òE4+6Gþìæ¾?Œ³0HëýõÑé…Lf™—ÅA<»¾qh¥žŸ¦bv½úu~öû×矎AäÏcïxÅþüýåÕ‚dô8ûåêâòû/ŸÞ'áüúò—+:¿8ÿt~uv¯@Ö¦ðÌ‚‹ËŸÎitþÓùÏçWן»þñèüÚÆ=°ð%žä£_óg+8÷G¾'³4š=À‹ï‰,f›£0’^Ji ÕÑç£Y‚ά^:%ÀH¦^”É„1%Á(óbH-A<´ð‚ã…ð}þA}õý .û²©é¤y½¢Á—.¿Ux^ *ªþlÄžïÇ™¦÷nµjE:W]ë9ßä}±¦aUv½†óœ¾mËMÞ–Õ#½î:µ¢QßÐs¥zÕnÊZñ⢰䋦î5­¦"ÀMÓÒàH6;Þ¯Sí½â‰f«ÚOغe’ͯ×êO†gÂË¢(Ðgq˜„M«®¡ÑîXÌ™Å`^Öôì×F8{"OA©1hOÓÃó«z¢}*ÆPz~%Œ‰RJMd^”„‚qº¦í‘â1zL
±®Ï{µQuOçð¼Ä´ªNoë’4%Pª]_ö»ÞžO™ïk7`í¢ììKøajd(ì™É€ŠœMj©Œi=Ò ¹¡g¿æ™›¦ªš‡²¾ýçsgÂóA\Šƒ¤½A„ŽŒ2¦r „Ì~õE2ÞŽkÂäà–éÉž{z>ŒÃxoO#•Ë,•=à«ù—ïC–UkÐïc˜Ï
-(	0bd/HÈÁ: "ƒõ²Œíêi¼í´”ÜmÇbÚ’0\}äT2Ö璘iP7½võƒ¢‚›„~ú‚¨¬¢2X/‹êЮŽ¨ÆÛN‹ÊÝ6§£ß)v¯Ë'lZlQ+ŠòŠ#ûòqp¿‰ Q'…‰:w*Ç|d½R98ÏJ\Â3Öa‰;X$n°^–ø¡]‰·–¸»­
\u¾Qû1ÍØí·6y†CŒiæ¡ìׇt¡—&ad²FQMé&ò¤ÿ³nDì…Aø’n¬º1X/ëæЮŽnÆÛNëÆÝ–½¡V{WFª.ª¦3kLdY¶9”ñ@ú™ǘú¼8â’ô|È©RrÒƒNz2>nsb€¬_åô¨T¾‚´G/ê[Q囜k1‰É¶½£)Œu¿¿zQ
}[Æ\§ÁÙ¢
-/)Í¡`„Úµ¯`=‚ñ¡i$R7µ"ÐDA„USäÕºéz^¼¹ÌÄ€P«¾ÃÛB
-_8r[S‡¢$Î~n$7Ôqæì¸Ê<{Øš	ñYp¨ÅŒƒ%ÏÝ4;ÃSiWªý3‘¾Vª+Úr;T¼Oªt+=°¾ãYBŽâ©ªŠb4/[@ÇL.2äb—ã9hw×1p“¯ÔÏÄC"†©²£Q÷X÷yÑ—­á:ŽçšLmEÎâœP7eWB‹Né¼+ëBM©»SÅ®-{.Ëo]ô…lÔ	µS±‡¶b¿Ï«r•SùîìhóÍ®§Rù-ÙLjDN45š0…=ØÖC£=I_Æ¢\¸©˜_ƒ+ØôdJçVµØVpõ€ÞðB\ ƒÖÑ 3QVl;*ú55$»[>¨kL«¦Ø¡®´iOÚÑ¿×
--Vú(dóÛòÞ@°úAЧ8²Á‰ý²gUœ)šÍ–ýpE3(hMÌl·G&øø8‡Çs‘aFG10B,™‹¾Í¡ËÒ‚ÐàÚ2‡ê£›0²]
2Ùd1åÊÌ5ç,&&j6cv2—5èŽOÛ›	kµ¹gdîf5ͬÔVÕ«Žàýa†Ò”PŽ—¸
ã/Á¼ù¼±®a„Ýæ„YƒÇ¾gèPOö²<»¨ïô…TÚBc×ì—û&ýp63½ßɨIŽãÚœÅTœ‰Ù h›ŽŠ#\§Ÿ/M娳/òb=u!„5iG¶‹€H"÷¶ƒÈQw7!FôâÐi¿DoŸýÝVgŸ	j¾'…ü“ܵ8ûCÞêm¢ÌxýaÙÐÁ2}æ"/Ì@ŽŒº¬òânÝTSì†)`J1pƒ‘5ëºái"€çBF‚E±®OЗpM¡æú\nÊ*o«Çc!„fÙ&
-Š½°%Ycj$˜z ´§+/ªa2g¡½lC`CO°t"ƒµí	ˆFVêz”+<|ÒµnFt7`qe­^O{ú 	Õ™hXšô½jì}À“Ônã$x5é÷ÊœRdÄU`VcyÛõC1ÀF{«ŠÞÁœ6õduÛ@UµÞ`ð"Êz¥5vÎ#S'w¼š ÝnÙ©~Ÿ£GÁ€µ@g	‰GihÒŒ:¨X*Ì%)Þ¬nx~©nlqŽïvá’b~¾Ò»ÂÞO–«»Š2"`i†aù­àE•ÃXg]xÖL9KA8æÁþ–o¶•šìRÊzòÃË„0]°ðOžáw˜J²ù«ãE¾£¡žßM8"t¾2±Ñ›j @Ú%øBÇ)*¼´Ó^áõ6"%Uì®XA³iጥjM„^ÉÛÃä<Ä©éÎz‘%8ÇèÖµiîv[´s!.B‡WkÇF™BZ™%_q³ÊLç_º!îíÅ2j¶MÜ{E؃(µ[ÚO›$^*lºÐ…«¶ud‘ 䲶YG4¥ï¬`bßS%]PsI+ýlß6–ÐÞM]|
%‘m—¦xÏMßÅmö†^°Gá˜sc‘6À³r³¼è'2ñ"§öCŒùsÖl†‚í3özß^þò·ú¡ùþRÆýš%/‘£‹ë.„Ûï&ŒÝ¹ÝTqÛ­ÊLïa(¡4i*AŸ.{ÕmóB™Ï?cá3ñC[œöaT཭ÜîZ£•8ÕR)lôb1¿>΂yCzƒŠVj®áÉvsÛæp¦¶# ?¸ bì»ú‚úòѯu{ÓÔå´îráù.Ù+–ÌÙÎNøùöí	}™n
:èK«Ó­jí¥Â#ç©c¡}D^‚kYûð[ˆk2›2
-²ªSÍ”4I‚u€—„PûàÄ=aÄïL\ëK†Ø§ÎŸ9=H/8²ö¤g
vMÏ3"ŒñÒÄĞ̌?eõ3/Píµ"§§D÷/óõöíT§ó¿‡:N6<þruùi]zØËà@«þ€º¥£î¿ï»ìÙàÕºúáÐg½’¾Ç¹n­CXÞÛRjpë猚Ôá;üSGÖßkÈ‘'”r¶Ð^·$”¬]Ÿ·=MÐí©4wžê‚ë¼Í‹^û¹‘÷)8ò¦\­ÀKS›½szà-ݾú2in"nWôaÞ¹­è¹ÚƒaeovU_n+[h×x£óÌpüÇÃė߬¿üÇŠáSF˜x2MƒéO
- s/
²Ä0…ç•r̹ýÆSÖÿœÐådendstream
+xÚ­]sÛ6òÝ¿B™{X4Aðóú”8vëNëægîfšÎ”¢`‹cŠTIÊŽÿýíb $ÓòõÚÑÁÝÅØï%füÄ,‹ý@æÑ,Í#?D<+×GÁìpß	¦™¢¹KõþúèôB¦³ÜÏ“0™]ß8¼2?È21»^þêýðîãõù§ãy^âÏã$ðÞ_^} HN³_®..¿ÿòéÝqy×—¿\øÓùÅù§ó«³sxÖ0_0‡g&\\þtN£óŸÎ>¿ºþ|üÛõGç×ö0îE ñ$ýú[0[¹<
+|™gñì^_äy8[E±ôãHJ©>ýË2t°zê”c™ùq¦Å”ãÜOd(µñÐÂç"ïƒúaS
UÛÐI‹fIƒ/}q«ð¼ÀU:\ƒÙç`I.üÄu0 8DÚDäÈ(‡a&GN¸Ù¯H÷W„#Áœ(=¸¤%z²æŽ^Dã(ÙYÓHåò#KeGÄøÄÁåÇûˆeÕòû0âY¥!FŒü	9TDd¨^–Ñ¡U!í/;-%wÙ}1mHH®¾rª˜ê÷Ó×4hÚA»úAQAŒM£ {ATÕQª—EuhUGTûËN‹Ê]¶ £ß)v¯Ë'lZlQKŠòŠ#ûâqt¿‰ Q'Š„‰:w*÷÷‘CôÊä~ÀyV☱KÜ¡: qCõ²Ä­êH|Ùi‰»ËÚÀÕkµÓŒÝ>qk“a8ÆÈ=Í?‰¹$=sª”œô` “ža·m€¬_ô¨U±„´G/ê[Yë‚k1‰É¶»#ƺß_½Æ¨†¾-®ÓE¶(ÇÂKJs(¡öÄí+X¤`|h©†4m£4Q!¢nË¢^µýÀ£—¹	5ôøB`[HáGnkêP”¤°³ŸÛ‘Å
uœ9;Î2Ï–fF|j1ã`Á¸›vköTÙ™j÷L¤¯¥êˮڌï“jÝJ¬ïø–‘£xªªâÍËÐ	³‹
»ÄÄåÄín{®‹¥Ú£3±Ä°HUõ4ꛡ(‡ª¤9\Ç1®]+ ÔVäL.ˆt]õ
tØÙè´y}Õ”jJݽ*·]5pYûÖE_ÄF²Q;{d+öû¢®–•ÑNÁŽ6ßnz!•ß’}ì±(è¦FS؃m=´Úµñe,Êu›	ï
+ŒäXâ'S:·ªÅ¶‚«ô†â´Ž½±ˆªfãØÚP1¬¨!ÙÞòA]cZ¶åu¥M{ÒŽþ½Rh±2@	È0÷n«{ÁêA;;EÊ»ebp«ˆ)Ûõ†ýpI´ff–Ûa
+>>âðø`.2Êé(F„ïbè
+è²´ 4¸±›Cõ‚ÑMÙ¶‚lò„reîšsžÐ&j6Šv2W
èŽO;˜	sµ¹çdîf6a–j£šeOpCþ°BCéHJ(ÇK\†é`^Š|
+ÞX×0ÂnsÂÀ¬Ácß3v¨';Yž]4púB*m¡±ëOvË}“~8›™Þïd¯IãÚœ€ÄTœ‰Ù h›ŽŠ#œ§ŸŒ1g”»g$¤±ôP‚@b™Ûä‡c]È
+Û½~­^ʬÍ<ìüÑ9¾TMÅIy¿…×ÜÀx’\z—7¸£ÌÓ"â\¯ÚzáÙ ?¤)1ÆÌ&‚q7Ýc
,¸Ôl#²IDp@‡@4U«%Xœä¡©ÕðÈshOª›©‚:†
+&JM2Á/ñã4Œv¸ý±UÝ$³Ø—QøðšSŸŸer¯³/‹r5u!„5ižÄ–‹I*w–ƒÈÑô7!öø%‘/²,y‰ßîö·}&¸¾òOÍÁÙŠNhe¶Àë»
,³g.rðÂäȤ‹º(ïVm=µÝ(J)ÆÝ`dÍ<]7€KŠo‡lg'ü|ûö„¾¬L7=tµõéFuöJâóÔ±Ð>b?ŽÀµ¬}ø‚-Ä5
+™OYÕ©ÞDiŠU„ŸFP9!âFñ;ˆk}E‘Ôwâ³ éGÖž4ÖP7ô<#Æ/ƒXL¬É›qà§ì±AªFæô”øþå}½};Õ'ýãïáŽÈ–Ç_®.ÿC#­kÃ;!hÕP·tÔý÷}Õ=½ZW?ú¬WÒ×<×­u+[Jnýƒ½wüŠÿÔ‘õ×rä	¥œÍµWàÝCèÄ#)%Þàu!èîUšS
-AÊUÑå }§oŽ×®}]ôØʘØé/KšŠºU¼¸¥»Æ›S‚h0‹¯ß4dˆ\ðÏqfëÅé{+,‚Ô¹Q
ÒÝÞ—ª†Âžexå]ú‚£7sìO¸|€”mÙÓ}j@ÑŸ|
PpäE¹Z—¶1kôÀ;º»
(dn"n×ôYß¹ë¸Úƒae¯·õPmj[h7xôÌ÷pü¿ÄÄw„À¬¿ü·ŒñCH”ú2ËÂé s?óÔl
+Ï+åþÎíÿ7žný¿ŸýóŠendstream
 endobj
-1101 0 obj <<
+1106 0 obj <<
 /Type /Page
-/Contents 1102 0 R
-/Resources 1100 0 R
+/Contents 1107 0 R
+/Resources 1105 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
+/Parent 1098 0 R
 >> endobj
-1103 0 obj <<
-/D [1101 0 R /XYZ 85.0394 794.5015 null]
+1108 0 obj <<
+/D [1106 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 258 0 obj <<
-/D [1101 0 R /XYZ 85.0394 769.5949 null]
+/D [1106 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1104 0 obj <<
-/D [1101 0 R /XYZ 85.0394 749.6335 null]
+1109 0 obj <<
+/D [1106 0 R /XYZ 85.0394 749.6335 null]
 >> endobj
 262 0 obj <<
-/D [1101 0 R /XYZ 85.0394 336.0663 null]
+/D [1106 0 R /XYZ 85.0394 336.0663 null]
 >> endobj
-1105 0 obj <<
-/D [1101 0 R /XYZ 85.0394 307.6963 null]
+1110 0 obj <<
+/D [1106 0 R /XYZ 85.0394 307.6963 null]
 >> endobj
 266 0 obj <<
-/D [1101 0 R /XYZ 85.0394 248.6123 null]
+/D [1106 0 R /XYZ 85.0394 248.6123 null]
 >> endobj
-1106 0 obj <<
-/D [1101 0 R /XYZ 85.0394 222.7648 null]
+1111 0 obj <<
+/D [1106 0 R /XYZ 85.0394 222.7648 null]
 >> endobj
 270 0 obj <<
-/D [1101 0 R /XYZ 85.0394 150.9902 null]
+/D [1106 0 R /XYZ 85.0394 150.9902 null]
 >> endobj
-1107 0 obj <<
-/D [1101 0 R /XYZ 85.0394 123.8975 null]
+1112 0 obj <<
+/D [1106 0 R /XYZ 85.0394 123.8975 null]
 >> endobj
-1100 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F14 685 0 R /F39 863 0 R >>
+1105 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F14 689 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1111 0 obj <<
-/Length 2398      
+1116 0 obj <<
+/Length 2539      
 /Filter /FlateDecode
 >>
 stream
-xÚÍYYoãF~÷¯ ‡P™Ý7ÙÉ“ãx;“ÄãÅb‘XšjKD(R!);š_¿ÕÙ’écÖÞ 0`öQ]Ý]U_-!øÉDF©d	G˜GÅúEK˜;?ÂŽfî‰æ!Õ·WGÇïhÉD
-"¢«›€W– ,ÃÑÕâ—X$$™ŸþøáÝÅù?/Of)‹¯.~ü0›Žâwÿ8³­óË“÷ïO.gsœqŸ~òÓÕÙ¥ŽÇ·¾³#Ò~`zyöîìòìÃéÙì·«ŽÎ®†»„÷ňê‹üqôËo(ZÀµ8B	•î ƒ,%‰ÖGŒÓ„3JýHuôñèça0k–NÊ£„PA&H蔹L…)-ÀÓy×ï*÷¢$.šõZÕ}§{8.òºnz;sí(jÕõj⢈ÆïšÖŽª?óõ¦RouÇýÊß4UÕÜ•õÒvKÇw`z›WåÂó/òm§,ÁÀÎR¶3œÅûçÓR‡«Ï1N$çÄÜCÕ‹Î*ç®ìW¶eù@ãW„HÛõ¶óÕñךX—„£Ù¥‰¤$3ìŽÍ<‘i*`&Iefâ+3áw&®Vú~¡ØÍöºÑõyÛÛfsc¿¹ý¸%û7Â0ìú²ªlssã°ÛÏáR{ÂzÛåµë×EÓ¶ªpÇÉû^­7CÇ~µÕ3xèê±$ã"›8Œ;e0nO?§`öelÿj÷Z7ö[5õRµþÐþ»‰ÓDPégœæisBÒ³ Id’e©´X{óf@“!Ú çŒD7CËZ°nÜ5nÑ*oó¢W­[v|l¿¿"Žº*ïVo;݆Al»y½ð›¦ê­gÛì£<6«½™Íj×ͧW9%%"®ÊZiOJ3PƒÚÙAïEt[{3汰ݼ0 oºÎö×Ûª/7•#ÖïïÑ}mÁÌéõØ*¿u´MíU³×x·a:Ý,wnã¦ÚI˜mÞڶʋÕ8j[ë­w'Ök…Þƨ„kŒ‚ó‚¸1¢;p0ÖwjîÖw>ê“RkiÇÖV_æiæ˜ÊCóO·À\nB¿~Ûø~áÝç·¶§nUíÕl—+·¶ßçáÔSíÛð·iÕmÙl»ûà=@"ÚGàÇ•ªªƒ6^Õº9‡¡Òa`×l…
F7ª‘õŠËÁ;¡lJHÂ8dNúÅÄe2 €àn	ôÉëíúZ»4³s¹¬Ý©8šÀ»õ™%†÷n¼@hÁÖp+ø½™Œ$¹‹¾Ú³šÌéÍÛðò9@Aúù(Èœ`þZàp׿_¼S	)£ß/©;Uçóծ˖-+n·U 艠哉ð}€£}…îÞm7›¦…-¿>Äg–&¥‘.¹$OŸõæB%`	ƒ¬ö°ô¿­
-#¡0ÿØ«Ï=ÿàW€Ù]iN ,F,
¡DšÐŒâˆ`€áÙæE5NŒ2(GSJC°6ŽTHã.!>ÔùÚÔc0rñ“Ê«‚Α®ó¾X}éé
-06C¥M¶ŽYQXjqÀmaWMÙh>$™Ÿv(¦ºû8…B=âx™|µ&9éx ç³ô+PÖHâìqaˆò"ÍØÖ¶©ºg(®¨(:Ÿ\"¶+HTå¦}b­ñ:™_ïÆÄÞnK¤kŸHµõ¢˜8dcRP¸m_Ve¿›aŒã‡UŠçeÿê0:*Ä:Ì(¤lÔ=‚€ÓÞ.Ô“*ttÝž»´)Ð#BÎóZB{u_…!³ ÍŸZŠ“T¸ÇûßÕîIuU”Z@Ff™E 5¨Îkð:ë!@Ö	éû$#\1
-ß|vup1$5þEÌM6“Y@[~
-² m7Dª«ç¨+Äkù©×W…¢
-?eâ,M2žÚÐõêRKàó4FSH(Lò-÷°ŸA‚ÐÞŸƒÀפÌ¿Z˜%j|÷ÖZË`
Q&_BÙwvÀ'jì&³úA[£ ^WYì•fˆ?¥-Í…¥6¨Tw­z:¢„5’‰*÷c“‰¿:Ù,á>[Ê žQGdÞeu2`2F“IèŸÌÐ~ÒQ•ËU?¿Súc'ÜAšÊ؇Yä.GŸgPÆPyðà¿öøÔïÄù	ÔÓ
-4ŠeòPÜg4x\ØL Ž¿-ÀAXLò§Ü1B	¢ßë¼3?+|Nú˜r«I6¤0♎N-…ÍaÈÄÀΖã¦kç»~{íXÖŽSWé—ý‰ç¸OÍðï73ÙO•?žABùÛ*N HçùãzKE‚‰°zk6:F=ë>WÔâ’Y¼¬škó”üà‘aü~‘~CaµÔŽÜTk0¿P7ù¶š.Goü3oêÕÞÃêEñ2Ñê‡ÃŒ¢´Å̱œúEÞÂ^ü«ýø”f™þAž¤àG2`¢g)µ¦MÙ½7\ÿû¾'ÿ_À¶endstream
+xÚÍZ[oÜ6~÷¯ «i24¯’Ø>¥Žãu±q[ÛÅbÑXYCÏÕHSIc×ùõ{x“([ö8µ·D¼’çúzÈÃ?21Š%•³Dr$0³|s€g+˜;9 Žfá‰!Õw—‡X2“HÆ4ž]^¼R„Ó”Ì.—¿D1¢hptôÃÙ‡Ó“ŸÏßÍ]žþp6_P£§ÿ:¶­“ów?¾;Ÿ/H*HtôÏw?^ŸÛ©Øñøîô콑öóÓóãÇçÇgGÇóß.¿?8¾ìïÞ—`¦/òÇÁ/¿áÙ®ýýFL¦bvŒˆ”t¶9à‚!Áó#åÁÅÁO=Ã`Ö,”Áˆ²˜N²)
+‰bSZ€G‹¶»+Ü‹Ñ(¯7Uu­î‘(ϪªîìÌ•£¨TÛ©%ˆ‹a}¨;ªþÌ6ÛR½Õ=ukG|]—e}[T+Û-ßžéMVKÏ?Ïv­²=8KÑÌIϧ¥W_‚¤ÔÜCUËÖ*ç¶èÖ¶eù@ãWŒiÓv¶óõá7šX—„£Ù%H2šv‡fd’Ä0ƒθ™øÚLøƒ‰Ëµ¾_Œqä¿f{Ýh»¬él³¾¶ßÌ~Ü…ÐøFä†mW”¥mnpìwñì/5ÖkÜ.«\¿Êë¦Q¹;NÖuj³í;ö«­Æ˜ÁcWg˜£TÄéÄaÜ)ƒq{ú³Oçã«=l˜N»Ëp·aS$Ì6om[eùzµ­Í·µÂhcT"´Bð‚¼¡£%Á.Zj~6Z>'
+Zë|YlYjx(æ:¢ðÛö®îÞŽ8¿µ=u£*¨z·Z»µÝ˜‡SHy7eB~Ã'¢Ú¶Q7E½kºë=ßÃcŸ»X«²½N;Š×ÄV5nÎyMá¬þ®Þ9
+›~®U3øÒ>¿ím!t×	e3J!Œ`sÒ¯&.“¤sK O^í6W:ˆ™‹UåN%ð„‡Û(É0’0<¸ñûÐf­ß+øÑÌà~Þœ[d.ßêXj°Ò›7¶áåóWì>q¢ø{Íž†»þmVÿÕŒ~
+tò„ F˜xê$I)ø4ꄃ¦%óÇyÙux¹¦_1f5 {–¦H¼Ái/ŽëYLKHˆKÿø„ˆ9Ñ„°F$`6Ö)Þlhtnþt“è´oÓè侬`œ€•qÂ$r#«Ù I8g†(l›ÛR1‡§6{_ÃgÁ5=ãEÈÙ\€ù`èP»ìÏB‡Áÿ3'´!‡ã!aê¶I.ºaLB7Zµ)ò°Œíê˜ðßoÿaÃO°	8sð:tìÚÚ-ŸÑ­È1ÏÜ~>;šÎuf¶µß»95g›0à[½Q½+uÜ&˜æ«»ŸæD¸„=
Á!ÃF	±Ž©g‚éÕEµ—éTkg;Of"”&Ð^¢Ü6î4ïÕÎ^»+<#¸n§&ˤñX"š‚Ý…vú2Ó×N&d¶?To/s̱7ÊãÁ›ÈŒpÄxLÃZqpœ2_,CTÄJŽz¡9™R¹ðèç¤É6›¬y$»¦(N$óÞGÁÍ\Ý-i?ùþ1ÓƒmÑš¼	$&ÑÀרÉçSèÛ<ÓQáItqNy:—uõRÇÑT¸òQC0i\øô)FÙ†ûò“û–k«†ˆnZªTu·Î:ÇE—G†Áv«²Æ¶õIë¡Ðöœ—uk‹c˜»˜ Ì]±Œ>šºDÒ™8¿Nõ™Ï¿™ý\•uþû8—·»«ÅÀÈ¥ïÛuáaípIÝ)[T³)*X¶¼_X»­AûÃIüÒ#ˆð@à±ÂïïÞî¶Ûº-¿¹ïŸi‚0Nf`H(¥€ŸáKL‚/ÕÈ—þÚª 5RóO=î<ˆ~Å=gvW†à`„ŠÐ—ƒ”ÁK!Q!Üj>ËË	ï$‚O\j\*탕‰¤±4ñD•mLÝ#§?Ú¡l¹´:hé&ëòµQ˜ž.ÁiÁh˜” ÊÆ1ËsK­SX¡-àÊ©j"ë¡%øOÓMíÃœHxAÇ<^&a­KAâdp›ç³ô+S”øR$lÒ ÏÎdï®M]¶ÏÐ\^:·h=¦dlÖTé¦=ž¿R½|Яî.ÃøÃjü6†Â†k©Ã¹)Û`~©®³]9]—^û'ßòeßã„ñÅâ~ˆL\Š=°?Õ?Q Ò%%#é½ÉTù‚8WÍPÕçS/5ƒntg\ÿom>]ô
+ÖE@ÖOˆ=¸ÒÕàÌñž´˜ÄˆÐØõ®ÙéŸ*,F~V˜3ÅR3O#³Üöߟ]\Ù¶æ÷¸(ƒc~±¢Œ1”3\>-ʘ#’VÒÒ¹)ÔíçŠÐY£Y*é…¢9xùí8T©)ƒhû""ˆœú­žù—‰ÿ2gxŠå	ˆ,¥Ó?º¡IŠx
+L û/û$Âøƒ¿áøßðx²àðÿ½ òÏendstream
 endobj
-1110 0 obj <<
+1115 0 obj <<
 /Type /Page
-/Contents 1111 0 R
-/Resources 1109 0 R
+/Contents 1116 0 R
+/Resources 1114 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
+/Parent 1098 0 R
 >> endobj
-1108 0 obj <<
+1113 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
@@ -3907,220 +3941,222 @@ x
 6\>RgÈbÏWÖ¹j[†›
 WŒÏ¢®{6;»²þFÃÇñ÷ø]š¨)Õ/Ô¬Mu;pk;Ì©Ëdh<åE–ñ¬AÏw³ð¬±±Nê¦ó¡Ä½t•‹ùD„™Â²]°Ä(‡;„ ·åŽ°Š­r²ÂÙÄLûˆ
T¥Í¡誋ŠŽt’¹w_=Î]ˆ‹=¦uSä÷—ä"ï±yl±‡µÃ-ËkHsŠöreOÚ³êvg›<7ºt,‡Ýe—;ãÒèЭ/I…B÷&ê(ýê³ö󻉨YÙ¹Ç,çkRÔšÚ'^
m"	^˜h±ÎW9AVªy­Â©/fýÆ"•œãûFy-Sng	\Çdª¼˜©Æ¥†Í}B©•µŒÎ$âw1.¶&Øíþ²C¶O–ÃVç X×9g¹E{îÇ<•ãóP)!ÍZÜÅŸLÞª~ÑÔ'¯UâXLµüc“ÅXsЖõÚ¯½˜Ó’~òBL–§èªÆ¹O¦ºNZ_[Èü.øšŠû*]3QôçÇñ!Ö-žendstream
 endobj
-1112 0 obj <<
-/D [1110 0 R /XYZ 56.6929 794.5015 null]
+1117 0 obj <<
+/D [1115 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 274 0 obj <<
-/D [1110 0 R /XYZ 56.6929 330.9243 null]
+/D [1115 0 R /XYZ 56.6929 366.7898 null]
 >> endobj
-1113 0 obj <<
-/D [1110 0 R /XYZ 56.6929 299.0803 null]
+1118 0 obj <<
+/D [1115 0 R /XYZ 56.6929 334.9458 null]
 >> endobj
-1114 0 obj <<
-/D [1110 0 R /XYZ 56.6929 240.311 null]
+1119 0 obj <<
+/D [1115 0 R /XYZ 56.6929 276.1765 null]
 >> endobj
-1115 0 obj <<
-/D [1110 0 R /XYZ 56.6929 228.3558 null]
+1120 0 obj <<
+/D [1115 0 R /XYZ 56.6929 264.2213 null]
 >> endobj
-1109 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F62 995 0 R /F21 658 0 R >>
-/XObject << /Im3 1108 0 R >>
+1114 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F62 1000 0 R /F21 662 0 R >>
+/XObject << /Im3 1113 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1118 0 obj <<
-/Length 2415      
+1123 0 obj <<
+/Length 2584      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZÝS#7ç¯ðÛ™«X§oi²O„e÷Hí’= O›­­Á`níÎ3@È]þ÷ëVKã±óHUŠ‡‘ZR«õëVȈ‡?1ò†q•é‘Ë43\˜Ñt±ÃG0ö~GÄ9“4iÒŸõÃéÎ?Þ)7ÊXf¥ž÷xyƽ£ÓÙçñþ?÷>ïN¤ácËv'Æòñ‡Go‰’Ñgÿ§£w‡ï>ÞÛuz|zøÓ‘ÞíìN„7ÖËÈaË‚w‡¨õþxïãǽãÝ/§?îœvgéŸWp…ùÏÎç/|4ƒcÿ¸Ã™Ê¼ÝB‡3‘er´ØÑF1£•J”ùÎÉο:†½Ñ°t?-“2S£‰òLã·oK[pØ66…`™1›»N„0L…:1–qm\§)z:R0'33r&cVI”ÒË›b‰ØÀtÕŸÎ=Úá64¯mÎi±l󲊺ú…syq½ÌÛ²ŽÄú
-Ûqz"æô¹‚Í„Oâ¾v–7eÃ6õc¸cÞq1êëeP©L2#¬CÐhÂk¢¯5ã7¡¯³ÎÑ•h—×M[Ì&ߊ»æqÌ
-ĺ*"²ír×Ãzê¿=:99ا62|Ñž¨eD•dš!ª4D0º)‹Ûg#m3¬ÍäøàH"ýWNÂLÏåcÀ3rÖúÉouUüQàpí õ¤y-ÐV.ö1Ÿk2¼Ö|ö[•™`ÚYðâÒ1îÖ}ý=Ÿ¯¸e^f µ®Ž«ž^Ô½ ©FÖiæ×ðÓˤ•5f`È¢RæõÅEY]hO9¦,hšæåÕl˜—2NÅ9Éwð‚SpáRr ·tóÊU˜Eu†ÆÏM~1tw7NºÝ”„O¦„»8ߪlSõ°»6ã¼iÊ‹í±CŸænqVÏË)õUlµuœVÅ/@‰éÀ‰;˜Ò)žâ~|·º $Zej¬xŸNõbM«e	VpGë¦ M)ͤ—~]­õy„uM¦`Ú$4Q¦æ{JðñÞtÚMÙ¯«–¶Êû€©ù7|oÿC_¬õ"Ë”ta㣺…#(ð\æ-¶l)kÂà@ÇP˜¿E2Á€ÔdD;‹”ä³gD¾-ÛË;γŒwŽ~‹!@&fuògÅyMÒÑFeÜxš¤'	,?#J1oŠÛKÊ‹7@sÙ¸ªãýD-Aæéßs£ÑЪ$Õ"ži¢ÌàÖoÏ!„ZGƒcÖ™Š¾´º0šL1%L
-BÑ€;Íã}¹¬á¾¤P$ipÿ}a^šB(f!ÿ9˜3Í Ay3ˆFy²ïj8ïz´ª~f=a^³âžÎ2­ØŠ™Ê°ºê1Ì@6ãUÌw¦ùOÿÜœïŠ7ÚÉñá§M$
-¡D²‘´ò¸iaˆ0‰¬UÑÞÖËoÔ)«¶XžçàˆqZPu~§çÉÚäwš;(ÚÛ5ׇäe0¯4醗ü95tZ±]sÚ3)ùcÖ®<¼Ñ÷ÕUÆŸ¬:‘éàX ¡‚Í	³ ¢RjYÒ—tŠc¾|žÆo/K¥8!¨i¤š!í]æ¨\¡(wr¥wHRdæÇ'uÈD`1ihÚ¬&bU·Ô¸¢DáÌ¥œÅ9}nC
ãºYÛ,Jr+¡DϤ¤ŽLC ÿ•(ó¢&íeCý`ÄHG
P3=´ÖŒ>$]b|XÑXs²IRaš7ÅwC¾l@.ÙU%ÛU=é殧`]í°è;¼îâ$Ù¡e_Ï׊æ;¢ý;$A”±}Êz%§Ò«¾¬[<ŠæBÛ”=pk{×áeWlukŸSæ¾~b! \åFP—a<ÒË\%¡œk™C¯öIï®ü‚6JtŠÐ“ézÞ¼¬®[qY•s)\3ºÏ4nXK-LØ#íêk°®Ðù±»FGÈœŽyÏßã1í
`ÎO«ã.Wõ²íx¯:_b	Šùhx"$çCÅ&
üNIs2¡5·žü!®ÅÔ¤q×ÀÂ9渷 Â[[Æç_Wå¯ñ¤9”ÔÿE­êzqVD8ëÛ*5ûä‹e}}uŸü¬m8É{¢m%VÎh{ån™“|e·ú)vûg•ï’ãëMªÈ:ݘäê~	¯l1f:5Ö“.ž%´8ez™WU1ÃXÇ#5xðŒœÝ%Ò@Ëg¿@W˼­—
'ë9röA)–3c7-»cJ¿4XGAÍú!€Ÿ€`pzŒñÌJį‰ck›â²ÕépxUþÁ
[x´´Ù}E û“è#	áe5›hò4¡:u]·å¼lïˆ}x	‚WqÃi
®®šE©ÚX&+™1¥7CggM${»,‹›"ÕÕäíÑI¸¹ž§ç‰Þ³ÉêA7ˆ¹jƵZš^®öª¡'%>ɦ< ¸§hz!û†ÛiDvö†?."æÔ=ÝÿDý¦ž~Cÿ„mtEEÅ<ÌÉ#9fHëU1-ñ³ÁÜÅ2ÃSîY^mFyÐÜ3íGð•ÎŠ§„d	ô~8´N:†“ÇûY´òÀY+Ûí‹â…¸1`[‚ñ̦WºpEž€ƒÅ<Í6´—ÌH­^
€ŽáÃhHŒ€,¡@Êèt1T*&ù*aÜp½áQÂc•ô>ø2é³qêÇ*(X0DŠ¥V/çÙrÀ‡	Ù½­ßGU|YÍÄȦäËAíøMVïc*‡ÒÌeiׇ …º’ëtKÁÝÞÏ»L«¸Œ	‘Y%D›?o0oÀ÷fa¢•Ã­]–Í7Ê”ÛpÙõP_ź†~ãDàú’Uì¤%?¾-ç³éê¥5¹ÒÒ›m¿þãó•RC¿ÕóÑ£/DOýÏ€Õ¿M@º¦¼ßòP—AG¡#eîÊ3ã¥ýÿ‡ýÿ’endstream
+xÚµMwÛ¸ñî_¡[徊o€ÉÉ›8©÷%ÞÔñž²yy4EÛl$Ò©8n»ÿ½3€¢d*vêìóAÀ˜Ì÷€bâ
ã*Ó—if¸0“byÀ'W°öú@Ä=³´i6ÜõóùÁß^)7ÉXf¥œ_pyƽ“óù‡é‹¿½;?>;œIç–ÎŒåÓŸON_$£Ÿ¿ž¾:yýÛÙÑ¡ÓÓó“_O	|vüêøìøôÅñáLx#༌öxuòæ˜F¯ÏŽÞ¾=:;üxþËÁñy—á}Wx‘|øÈ's¸ö/œ©Ì›É-L8Y&'Ëm3Z©Y¼?øGp°ŽŽÉOKŤÌÔd¦<ÓÆøýd‰²q(ˌ٥:Â0eêÄXƵq½N¤èDHÁœÌÌÄ™ŒY%UPÊ¿›ºDÉÀf5ÜÌ=Ú!Ü5/ç\ÖeKÍéϲ]±î˜w\L†Ü<í†*“Ìë&³dRžÉàÚRÕÿw*1"2Á´³ <éwÛ*¾§jÅ-ó2®ôÌX?ЋóÁA-&?¿NZÙRaÆ@>*eÑ\]UõÕˆö”cÊ‚¦i_^ÏÇq)ãtÜÓÜtUS·c¸à\¸¸¯íò®\–u-a™ßÑ ©iTëU%nÊ*šMéj½Ê‘"ë9Kº’`Ò’ÙÌ‚I+Äà6ÐF—àþœƒÂ÷>1}}•/—ùŠ°ªlpZÓ,ÓB“P%L³:_–4ûžœ€“ff=Sxb>_•mûi™wÅõ§EÕvaïlg3ź?ž]xÐ`9Ü>]H>p¡—äy
++:¨3~kó«1ßݹé~S>K&ÔG‚ߪlWõ@]›iÞ¶ÕUÝÆ	ý´wË‹fQ4#©â¨kâ¶:þ‚(…Ÿ‚8`§A¦´†‚…È®¸ŸžDRWeéTi°Á}05Ë-FnVXÁMÖmIšRšI/ý¶Z›Ë(Ö-ž‚iO0DžÚgÀ”àÓ£¢è·¼hêŽÈGå½Á4ü~ôâM¿"X9êE8–)éáÓ¦ƒ+(â¹Î;Ù  „l1ƒ‘\CfþÁ$„.×mÄq!)fÏ	|[u×#v gïýC€HnuŠåeCÜ¡*.÷ÄEÁÏ	R.Úòöº¤SÏæ²iÝDÿü›9±£ q›‡ýÑÚéìeÄ%å¢ÄJ˜,Ím9•7úAØtÙà.ŒœaŠJAu±®ݬªŸí&8!4sÎɉv$T÷Èt¤A„Î}o:;•á‰ý€""^j¦­ƒ‘Tû‹a ÆÚò‡Ïb†¹±šL1%LÊBoÑ‚{¥-¢Ã\7à0#5Gâÿ™§ÖŠYëŠÌŒa^€= 3(¼4WdŽõxáõ
¡ÕÍãd6`æGÉ,å¸Ç£L'öËLQnýC2ƒ„©5¡Š§ÈxýïœS_ѧœž¼û¢	DI”@6‚617¹6‘¹ .»Ûfõ™&UÝ•«ËJ1Mê>òŠ.Ežö®…ú
Õ
dò49oTòó’OžNìUò–¼}ÐÜ7£¼Ü¨®ÆDþhÕ‰L‡ÈŒž@XÑ­RÃÊŠ~I§¸ÖëÁ—iýöºÂdŠ‚jFªÙÖq~£r…¢êEÈÞ¡L‘™Ÿ¾oB-;IKÛæ
릣Á
•
+_À\ªy<‘ÓÏm(£aÐÁb<7/̲¢(1nRRG¤!Õ%È¢¬ÉUwÝÒ<1ÂQ4ŒF£-£e—˜žÔ´Ö®Cý#‰Ky[þ4VC€ÅX¨&û¾d¿ªgýÞí"¬ï–È×;N↑÷튭l"Ø?CD5Û籺Wb{*½òº'¢hE´M•Ñ~¯ºÃÓ\lãµßÓèþøÊB@Ì4 .Ã,×â‘. 	e†aÐþ¤NWItx¿éêTl‚
+¬§›Eû´ÖnƒeÓÑ¥BpËê>Ðp±ŽFX³GØͧ`^aò_B! œ9‘9­ˆÖ_ã!,`ÙO§#•›fÕõ¸7“±Å’41<’ó±~“þ º9ÙÐV\ø\Þõ÷?ˆgqmi¤P8¨®Àr
+clëÝ¿®«¯ñ¦9t4‚F£z½¼(£8›Û:
‡à«U³¾¹þ®íDÉ{¬í^%6;Ñhón¡à碷[ý»ý³:xÉñ'5e=£qLru¿‹W6ƒ$S,bÛƒ-¥‹wI=-n)®óº.q[y„†~c+w‰™4Àò9$0ÐÕ*ïšUKë	Ã6!GÑ>(Årfì®e7`Ly”¡u”Õ¬)ñE@m¹úÖãôš•(¿6®mÅc›Ûáò¦„%ºŽðj‰Ø}E`ü“$I«z^ŒhbžP½ºÖ]µ¨º;BžGãu$X4êêy䪋²’Sz7wöÖD¼w«ªüR¦Ž¡ž½<}?\n׋ôB1x9Ù¼éF1b±:ãV;MWGõØ«´Àq¼d!#¯	0ôB
·×ˆìí
'~ZµÌizþâÍÛ¦øŒñ	ÇÊšúyØ“Gp,‘@¬7eQ¡–óÑâÅ2ÃSñYÝì¦yÐø™ö!þ-ìc’²„z?ž\g=ÆÙåýBZy@­•ÝPFCê1/ÁxfÓ[]ð’ÇËzyî…Þ+í%3R«'ƒã2€Î¡Ä¶Bj—Jnˆ¡R±Ö§„	ë†ë¸^­¤÷!¢IŸMÓ<6‹Á¾!B,¥'Ä-Íw€H& /Ü+Xið‰5ƒëqhš¼5Olq6Dy_°J5a\¶¡ü-ÁB“ÉuòX½÷k0©U\ÆâÈlŠ£Ý¯Ìíƒ]XtåàÁ«ªýLUJ88>È>4[±ÉéB> endobj
-1119 0 obj <<
-/D [1117 0 R /XYZ 85.0394 794.5015 null]
+1124 0 obj <<
+/D [1122 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 278 0 obj <<
-/D [1117 0 R /XYZ 85.0394 656.7756 null]
+/D [1122 0 R /XYZ 85.0394 692.6412 null]
 >> endobj
-1120 0 obj <<
-/D [1117 0 R /XYZ 85.0394 632.436 null]
+1125 0 obj <<
+/D [1122 0 R /XYZ 85.0394 668.3015 null]
 >> endobj
 282 0 obj <<
-/D [1117 0 R /XYZ 85.0394 563.6675 null]
+/D [1122 0 R /XYZ 85.0394 599.533 null]
 >> endobj
-1121 0 obj <<
-/D [1117 0 R /XYZ 85.0394 533.5536 null]
+1126 0 obj <<
+/D [1122 0 R /XYZ 85.0394 569.4192 null]
 >> endobj
-1122 0 obj <<
-/D [1117 0 R /XYZ 85.0394 456.2156 null]
+1127 0 obj <<
+/D [1122 0 R /XYZ 85.0394 492.0811 null]
 >> endobj
-1123 0 obj <<
-/D [1117 0 R /XYZ 85.0394 444.2604 null]
+1128 0 obj <<
+/D [1122 0 R /XYZ 85.0394 480.1259 null]
 >> endobj
 286 0 obj <<
-/D [1117 0 R /XYZ 85.0394 307.3784 null]
+/D [1122 0 R /XYZ 85.0394 343.2439 null]
 >> endobj
-1124 0 obj <<
-/D [1117 0 R /XYZ 85.0394 280.2293 null]
+1129 0 obj <<
+/D [1122 0 R /XYZ 85.0394 316.0948 null]
 >> endobj
 290 0 obj <<
-/D [1117 0 R /XYZ 85.0394 163.9859 null]
+/D [1122 0 R /XYZ 85.0394 199.8514 null]
 >> endobj
-976 0 obj <<
-/D [1117 0 R /XYZ 85.0394 133.872 null]
+981 0 obj <<
+/D [1122 0 R /XYZ 85.0394 169.7375 null]
 >> endobj
-1116 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1121 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1127 0 obj <<
-/Length 4048      
-/Filter /FlateDecode
->>
-stream
-xÚ­;ÛrÛ8–ïþ
-¿­¼eqp%€ä)“NzÝ5“îMÜU»ÕݵEK´ÄŠDjD*Žgjþ}ÎÁx‘ Û³IùA$œûæ—þø¥Î³Ü	wiœÊ4ãúr±½`—+˜ûñ‚‡5ó¸h>^õçÛ‹?½—æÒe.ùåíý–͘µüòvùÛ,ÏDvØìíÏÞßüøëÇ7WFÍno~þp5šÍÞßüå=ýøñÍ_ÿúæãÕœ[ÍgoÿëÍ/·ï>ÒT`üùæÃ4âèçÐïÞ¿ûøîÃÛwWÜþtñî¶?Ëø¼œI<Èß.~ûƒ].áØ?]°L:«/à…eÜ9q¹½PZfZIG6Ÿ.þ»8šõŸ&éÇY&d.2E@í²\ÂpÑÔu¹èª¦n¯æÒèÙCµÙà“šÝ•4R,å®+—ôÖÔ4[Ôaàž~»uXß>¶]¹ý–ÖÝüòE8ËåþŠÛYÙ¶eÏ-ÐôʉYCó›
-¾«Ð+>«à¤¼Çq¹(<°%²è0çEc‘”ž©„Ö
ÞQo×UúÑ*ËY[mw›Àä›_¢Z2tÔülÈ,XÑ›.4¿´¢èïpîë`^!;®4´„þ˜Þ„:Ï!BÍQ„¤5ßLïâ|ò”ÞBˆ,WŽ;{Ë»LÇ"|L8E¹)Áóuø7VuCïËè˜ÀÛÈl¦±È›”ƒª°ž‡ºúš2Þ"3’çÑxOÌ®0#³+rÒP,èç×7ÿCËf[T5¶ÍâsÙÑ3%%¤y°¬ÃdåqíÑŠ]Ñ­i*‚ksÒãøO’Ђ01{VŒQ%œF13µÞ¹Ø<€‚‡E«éL86AÐÇƯR6‚g"—‘gèƒÒ¡¹e,.ºNÀÑ™1ujê2•›HžåÂ=é§Á|.ãšÕ¾9ìÒß™>=é58i3ûÐt:Þkz*mÃÈnSt`•·-‘CþO‡úçO40ÂL
-Ü„úŸšM!lÉyä(öKøJ¡Á¡	f*ìee§Mp„8ƒL˜`q½ÓÖ/{ql‚Éëëj±&Š¡aˆQЇåŸbÁ`‚À\ª<Ó¹OG
-‘ 8물ÔNdBéo/‘D€ó1ÄSp<˜Àõ«ÎF>ÿ†ÊÛegï
-r¹Ç„G£ÆÜy™ÀŽÃ
-Îw;oñ™£Ùv,w/81‡(C«è½;rç¼°™âO( Œ¢è¾ã#Äg, @·<âäÀç”À@ৣõšGŽæÄ›M$AC¿å×rqðN^†|ß(ßô‚sYàde‚(}*Ëså`mY&|þA3ûÕ%=|L•Á‡Õçk¸a
ò·å–<Ÿ³…÷xFÎ~(`¸¦Ñ·ÌaÒ;‘…·®œ¤Zg` äë“’s¿æIdÇÜ{„mUŸìÁºæ‚¿ŒJýê§w>‚é½8¥ëD™ÉŸӔ€gJª'ÏÞ¯yƒcH#nb‚Œ¨jŒJŠ±â®9t4ò†ÑÜê?˜å‹K4î'r55ÌUªºÍ}Ë=S‚e™2ò¨€Ä1£s‰’!×X2LXªÞd¼Â4›TÁŒ¤1°o»¢óÉöj¿»ÃÄuºvgtq®AòSFB.ûT˜
-×¼-Ãngúß‚~–å}qØ„¹©ÊóQ‰_ƹ×!lÒ1lÒC5š‚%púFkõDÞ/­UšáUúÐÔW]XÚ äPwåb¾Ž¦^½â`Œç³›š–t¾6s‹¢-¯)Pîa›¶¡ukßy±ê\”¤]ÆsýÎ*†e—ü”³þ1Éq¨Ÿìˆ#~c’¤fw‡ð°lJŸ¸¡Ø…¡uñ¥¤§"%ó‚S1ç鲟„¨	(›HIäd̾@Ð ±“SACô: À.`í=@Ñ(–adŽ1°ø2$­Ê»cÿÕ=Éâvø’l¤É
-«¥“0®Àb†DÖÔt|)SÒËdË r÷˜ÍœÂÏœ^G‰{ðùaGé°a³8A²ŽO¡ß‹cqòîPm:4Ô˜šÃ{lPâÜ‚ä³ gË¢àMðÆD?³¹9J!Ÿ¦2ä ²'rí:¶|ììÈ®ìXÖ`Ù‡k|ŽôYáÁ€Ö³y‘ØÈbNš©ç@³<Ñ$H0x¢™y‘àäC]ú(vèsBk±­tI3Tçp0Ô†µ¡âû¢n«à(­£Æ©Ž¦{áÉ^‡¾åÛ>#‚ÕË*lKFF¼Qñt1ൕ:R©eµª:jEÂÆÚöC#ËLh]Ú`¬™”G‡þ¼lÁâ«øa¿¦[ÂLJjb¢¿ÞÀ±.ôÝýî
ýRg²GȯÄï!ÜNÊmw ×^KpÕ•>À¾§_¢~ii¨='Z9™¬ÿÝW˜j‹Ú‚w]€y!æÃñ©å…GÉhò¤‹q”¤’̬«Õ:¬.WôqI3ÞäJ7ÖØÐC¦{€|>û_ï0aelÉK4ómå¥SR}n¶ÊĦAAÖ>Þ¢'êªÅZHéÃÔýdJá½óÊ5LZAwXpź9l–4ˆ&žR>„¬_Óz©BHß‘²­*ß ]òÍCMý«û	fx½©]Ž]t†å`ÄQW §¢?xÓö îXà’2žñä<4=_¢'=ñIt(µ‰$]{Ž'éÂô¤¬c¶…ï}5Ñ"Œ‘’M8K„kõ(°r@ð—; ÇÉž¾þh¨‰;&š…,s¢÷›O„÷š÷¡nìøR„r@Ø¢ˆ]ì÷{ˆƒÔÞ¡qçÃÃÕ¹.AÛÚj¨œ«ÙªŽB3Î-Á—Æk¸¦
-×¼
-HÈYgGÆǜ˩L¡…žhUÂlD1á«°àìó÷·TáÇBÚ5Ýê(܆MÂõ13«KªÄÙ~ÿIhø$óˆ?Í—'ÔÐ÷­z©EÀuØ9¨¼ÃŽÁ_€×€Ñ²¸‹ßzŸ‘ƒHb…„œÈÞŠïOáJÒ¨þ®ã•5º¡´cëp
k0M,Úglõ{ùE*ÊôY
-,[Vm@y¼Í]â¢×=ñ.ýbºšŠ[V’tþ‚ê/\ŠãÀ«”|a!(wI˜\…ºÿ«dê\‘‘÷¯Sâš)ÇòqäAô\ľ‡™qRâSÆÃ]Y¼l¬¯æœ1ŒS›Ã2îÓ¨~…7÷;•ÕÛ w*ÅÐêûjS¢ñyBˆ ’¿‘Jý:fMžÅA~õqÈ)mzí4<îÕ²!xŽ$ä ÇŒD%ª|Rc¤Wî½ÃѸÃÃ4k—£¦9LÝÑê]SEphób¤s¶ËâæŒÈ¿ó€tY‡
-ÜôvöÕ-?ºdz–Z¾ƒŠgèX3»/è`¬Ü€4q¹­jH¾úX{ã÷4wšvÙHì–VÐõo§‘{ƒ²Ÿ¡+–ÔÊ°NN)𰯺pc7±¯z¡¨…F}ÝCê«É¥ù¦1³÷âhùµÀûUèh‹¸ž&˜Þ˜âL¯,8¾ÛW_¼ÃÁŒ~èÂ"‹¡	>Å^v"@=òšõq#ÒÍobñnî+^F¥-Ï©¢› è!^üÿX;DÔ9Aú?,.àó?üÑÀ;ü…iiz³j€gë-­Äû›õêuê¾=Ûà/›Á%Âýóõ¹>¶]¥Lu]XO£oþ—Š¡Ñ¦BÅ™’±™²$ …˜Ëüóø¿§¨ÿå®jendstream
+1132 0 obj <<
+/Length 3749      
+/Filter /FlateDecode
+>>
+stream
+xÚ­Z_sã¶÷§Ð#Ý9!øG‚È=].¾ÔÆImg¦$Ó¡%JâœDª"u>·ÓïÞ],@‘d;½=VËÅb±ûÛÄ„ÃOLÒŒeVÚ‰±š¥\¤“Ùæ‚O–0öÃ…ð4Ó@4R}wñÍe&–ÙLf“ûÅ€WÎxž‹Éýü×$c’]ž¼ÿéæÃõ¿Ü¾»4:¹¿þéær*Sž|¸þëµ~¸}÷ãïn/§"OEòþÏï~¾¿º¥¡Ìóøîúæ{ê±ô8ÃôöêÃÕíÕÍû«ËßïÿrqußÏe8_ÁNä_¿þÎ's˜ö_.8S6O'ð™°VN6:U,ÕJ…žõÅÝÅßz†ƒQ÷רþgRe2¢@©b
+L-Ë¡¯4¥º¡ç¶ÙuÔªZz¶ÛrVýƹ,çoŽilªÆÄû¶œƒ2•àÉýª¤¾¢íÊ]Õ~¤·ß¤Ô¨6X];N*Åx¦ôd*˜Ñ*uÂý‰dz`Ö˜l2 rïYQ×í¡!	â¼T3Iïbv[…÷븯«Ï1·-™Q"n{äp¥8\™Ñ…΂¿Ü\ÿæͦ¨jêm›ÙDz£6η¬içYá»É¿#íŶèV4ØyÚŒöqøßðÝ á2y7›yûåÀl47Á;n\XÉ3Ï
+½ˆyJs¾‘(ÐÑ5ü+æ#“™
+k†Ñ'¦\ÅrÎÑ›Ÿ”iiüxóX—»%X&í³LÁh–»f¿ÇzkRy¢!<›ä¦é¼v\¼tZÚøžíºèÀ+oZRÙo<åwûú§;õKÁå Á|ó]³.¼ÂŸЋ°¢Ðp!»m}ü‡dµc˜]Êó?¢ëÃçÛ	_¶ÛuåViFå`}D[w40¯è}Ö5»'Ï }iN}CŠÞÚ ]um¹^ºld0Ñ#Pôüîç *3›lwÕ¦p2ÂK±ïVÍ®úwЊº6%näªÝàkNþº»ðTýK¿çáÅíO™(ºíQ_$Vx†83ÓèQŒ±§C–œ¢ÏÁµõd¯Æ&˜¦L\U³i#¸8¯Œ‚Ž—k5‹ˆr¦Jg,Ít6^ሒ Xä6W“L戚/VQà70‹AδQG•$	ž
ñûP:)–#žEÂþï3n5ëXáÜ$æ·]ѹTX»ÝÏ­ÏaàM¼†gÒ,ˆ\ÃVˆ9F,Bõ‰ñcµ^ó¶ô_Ôéž=æå¢Ø¯ýØ؈A©_†™¼ˆJˆ‚ñ¦Ù>³:0iªŸ©¨\'B9øªPuýUç	®þ”ÑجÙ×]¹ØÑзß
+ðQFˆäº&’ÎU*plV´å‚Í=ÏbÝ6D÷¸*kê;ƒ™RËD–¾be·(Ý¢ÁʺI„”Çâ6åGº¬7¦L:yØûƼ)]‡fç»Vŧ’ZEÌä%V”}¡ü§ êAå1Kƒç¯04HóÔØÐP¼4°õR»€$Ñ4Š¹ïYùià,¾RXíB´ûׂlqsø'¹Hš5VMG¤Ï=O‹îà‘‚ñƒ;`ÇŽ‹”0E„—^Aß”]Ô³dÃJ,æKäü8XXǧ?Ž§h ½½Aî&·ÀÜæ”&aöi°¸G—í~”ž„²ulù“ìƒûjÝ¡ŸÆDÞï/­L›‘}}y0¼‘ܘö³<3G	åóZ†ŒDõêÁUóG.»Ë<Ù{µë|hkð
ÕC8d>Eý,qb ëdZD>”c¹N™±‹¨y9,ˆ,6¬IÊÍ«';Ô§ ±}Ÿ!æ¹Wvn
+ÓU=,tµžÖ×? ±+ê¶òq2·”B?•U<ÃÁ!¿¼ÐÊQ¡Öbrt)—õ¼òŸ%§=Ω8½ΤÖv¼ŠójYutpø0$ºýÄÐÉrÊ£qŒœ57‡M½‡sxÙ€Ç/–á=M·Úû.'v9é°A.Ï‘GÏNË´~ùăۃw.q-Ā뎘oŠ$ÎÃûk±œöØÃl›¶­\}Ky¬­½QGQÓ³üq’¢$ûEþœ”P2‡ÂTžOø§qç´Ð±¯Q£K:¡T–”ˆð9ç}4¬èÉ)8.	èyLùˆ4Áà›ÝG?Õày1¡ó£ÍÞ*×`oE¬Vï2lÖ þiØkÜdÃO»=<:àéÕ¡½uã™-ž=¤}Š'úP<9õ-+Âÿ˜s±€ü´ìä˪bZX5û
¤¾©9®¾Ê_ÕÖë3µ£»ªž•TAí¢.JCšöžçyK«c.
+¹;ÔÄ¥;wÁ–ÁëÍÝ1&~½¡'Pö9J„|T›ƒæ6[°k·Kj›Þó^Г4„ÿÌ©´=%]YÅVƒNûp·X¿[Z4Í=æÃþ±ç…£TpyÊ¥¨@#«j¹òÔå’þ\Òˆs¹Êw¬?K9]e;KþáæÞS†£y…n¾­œu*ªÖ-ýgÃfâ§'L;Þ¢±€
2}?´
i€÷>¸tns`E“(žœlH±jöë9u¢Ë£V,¦ƒñ‚÷ë1­³*Ü1³l¥zlõX¹“úª¾y¬©ÑO°ZŒ$KáoíŠdì¿gxî@í™^‹nâMÛ7a»cÅKd<É…?}Í>ìIŒÐ‰×Ô:¨tåâ9Τóq9
Ù6ö.ú¦èDßG›l´²t¬[ÚtlAþ2ú8Ú!)ïÏã!í¼6ñ‹‘£Cάìãæ3ð>=Ô
ç¿„Ð|Ÿ(™žû»ˆtØCÆ[á¯à¨°ê
+v[[êè:YöàÈ-üÄÒp}i*MÀ¹!/„J˜»Ÿ2NÞç\V3zdBT ˃ˆ‘X…%›¿'°î~¨¯½¡AÁmøMÕš¤.©@—÷ßAk”'š·þ4#YžÙ†&Kõ±Õ"ãÚÙoy‹çÔC
+o\=^½Dóâ!ü×ÅÔ  }ÀMn¤Ñ!wZ]ø«Iƒj¼?Å7•v¾ïqå¯c\þþÝÅÏTB–dóªõ"?sÈ.ñ…€è›^‚p³€ž˜®Æp‹ÄBRš½¢ºàE(y\ø6f_XÊl”§Ðgyú»Ëhê«¢ÂÚ¿™+Ó–gÃ<ȱèWOARÉŒU
+!ËRq¸w˜^NçTfëýÜkînPÀÂK‡»´Kk9îX.Â%ˆÀqÕ¢Z—è}ÞÆ$âAÙK’½B’ïK4þ:äMn‘½üâÈ©vzÍ8<>»åø$ˆXB†9‰ŽÔùTŠX¯Ü¹¡‚{‡Æ8oWƒCt,º#êmSvèõÖ9{ög̾Pr/tYûÜø¶ž³cÍwäÎ*2U¯ÇàÖ3qr“,ŠèkG· QœoªÒ¯-âYù‚ÆN¯<(»%
+ºN`Â=5
+0CöÁGö#tÙ’N8r{tLü¸«ˆâDB¿©?±ÇÂ-Ôë*Øé“ß”‚š;Ç3&ù€P{ËÏÞ·ÂP#y€àé¨ìÈ1ÅtîGúÍ‚ýÛ]õÉ…|AüCWy'Ø
+gÛ#ˆJîà(BøkZþ2×Ó‘0¼{¹Ãš—ÑqßÙéÆïtÿc :#NÿÄú¶ÿãæ1Üâååquz½l`ÑV¢Ä«œõòm®#ÞFŒwL6=âKšûïÛs'hx«Tìì…÷JúâûÕ‡8m°*Ï&™œé˜x¡Pr•H.bŸŠþ?´µendstream
 endobj
-1126 0 obj <<
+1131 0 obj <<
 /Type /Page
-/Contents 1127 0 R
-/Resources 1125 0 R
+/Contents 1132 0 R
+/Resources 1130 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
-/Annots [ 1129 0 R 1130 0 R ]
+/Parent 1098 0 R
+/Annots [ 1134 0 R 1135 0 R ]
 >> endobj
-1129 0 obj <<
+1134 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 576.4843 256.3816 588.5439]
+/Rect [55.6967 612.4761 256.3816 624.5358]
 /Subtype /Link
 /A << /S /GoTo /D (rndc) >>
 >> endobj
-1130 0 obj <<
+1135 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [268.5158 576.4843 332.4306 588.5439]
+/Rect [268.5158 612.4761 332.4306 624.5358]
 /Subtype /Link
 /A << /S /GoTo /D (admin_tools) >>
 >> endobj
-1128 0 obj <<
-/D [1126 0 R /XYZ 56.6929 794.5015 null]
+1133 0 obj <<
+/D [1131 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 294 0 obj <<
-/D [1126 0 R /XYZ 56.6929 311.2132 null]
+/D [1131 0 R /XYZ 56.6929 334.822 null]
 >> endobj
-1131 0 obj <<
-/D [1126 0 R /XYZ 56.6929 286.8682 null]
+1136 0 obj <<
+/D [1131 0 R /XYZ 56.6929 307.61 null]
 >> endobj
 298 0 obj <<
-/D [1126 0 R /XYZ 56.6929 252.8569 null]
+/D [1131 0 R /XYZ 56.6929 267.0706 null]
 >> endobj
-1132 0 obj <<
-/D [1126 0 R /XYZ 56.6929 223.8335 null]
+1137 0 obj <<
+/D [1131 0 R /XYZ 56.6929 235.1802 null]
 >> endobj
 302 0 obj <<
-/D [1126 0 R /XYZ 56.6929 155.208 null]
+/D [1131 0 R /XYZ 56.6929 160.0266 null]
 >> endobj
-1133 0 obj <<
-/D [1126 0 R /XYZ 56.6929 127.8981 null]
+1138 0 obj <<
+/D [1131 0 R /XYZ 56.6929 129.8498 null]
 >> endobj
-1125 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F48 885 0 R /F14 685 0 R >>
+1130 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R /F48 890 0 R /F14 689 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1137 0 obj <<
-/Length 2663      
+1142 0 obj <<
+/Length 2659      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥]sÜ6îÝ¿b噈å‡(Š—§4urî]“«ãÎ=¤™Œ¼K{5ÕJÛ•6;¾öþ{A‚ÔJ+ú£ãñ  ‚Ù‚Â[’P¡³…Ò‘”ÉÅrsFw0÷þŒyš4¥cªï¯Ï¾{'ÔBó|q};âUZlq½úœ¼ýç›ÿ\_\§\Ò$'ç©Ìiòý凣ñçíÇï.ßÿrõæ\eÉõåLj¾ºxwquñáíÅyÊ
-É`=÷Xðîòß½¿zóÓOo®Î¿\ÿxvq=è2Ö—QaùýìóºXÚ?žQ"t!P´æ‹ÍY&‘™SŸ}:ûy`8šuKcö“¢ ²à*b@ÎŒ-%ŸXPj’.œ­Ò€RšüfîQ½O}Ù›izþ`~¥”7U_µ
bÊf…À/]yg¬`31:-ºHyFtÆ2·Ëõ:±§$ϸbKcwŸ3©¬Mw쑬P0Óá°ÄŸn]îÎY‘˜•›%Žý*§¦nÛûÎ p¨ú5Bן.ß#ô+•´3æô¬3ªHÎAH%2’kª­Õqrw·@àjtL}:^€Ç4VxÎ×*þÉ,ÑúV"8å™4Rða=‘fæ*ÕS2̸YÀvë×ÞnËv³±>R-R¡()—‹tp>X½\—Mcjt›lÊ2§«…âœ(!Õ6èÓñ‚¹>s¾›bòà$›É£Á-(aÓÆCYAžú¸ûÔG'€Ô#iž/òœÃéiýœ(‹¢ˆW(éÀ1³tÆšŠÆ%É´ÌŽ;[«U,Š¼c¡¯¬K3ˆŒ®ˆ«ä·¦=4–þ¢íœ+axž4åƸ•<©—ÇQHÊ¢Îì¾™],J)¡ŒG’»Ëc˜!–å°;LG8Ÿ’÷ëÒcü®ˆmÇYÖUwCâÄ‚	×V>I9óc±0Iq«ÊÒyúMÙ/×>¹€ê¹½IǶª+¹P(JQ$ œŽÇ¡ÐU
Ô!xd@s¢0̯ËoçnŒi7(°W¦p•¤E 7àD8{U5x™ïªïÚ0Ø„±/‡hP†ùãÅ(¦]X„µ-”•a=ì4îB'§š°œå/mÏ0sŒ„v.Õj´ñá-Á@€šX3f”YsÛŸ®ß9[O5ƒë¶fY3wa›qaÒ¥êï¿+÷ ±K_8¦ÁLªPU%à¬V~Ý~»mw½¿û„	˜ÂŠ2ʦ.¸Þ”Ët³’2E
-NÕ¬æ,%Qr¨'x¡°+xìÁëV<Ū8aÅya–[Z‘ý]¹¸Ìd&ÿ.3QD%ƒ[3ÊR''ì€*“'ü$ãò™Ð?Ü8É>
%Ü BÓH{ŒÍæœ&×çšBÞ€ax¼¥3HÝÚ:—"ñ/Kœðn„t"¹¹Gt¹ÝB‘†ÙÐþr	¤¦j³ß Q³ßܸ®¢–Ç]
ÏWǶrùæ·ˆO§yÅ?¯–… €“C»¨²ÃˆÿÊÞV,1äŽDŒ­¡>f‚ŸzhZЈµƒ·K¨
ÁnÜÍd­î±|¸¡ ñ™þ4e	–“
-fxã®sö┦cŽó”%ÀÁ¤fÅqc¼E]ŠVÄJr”¶¬eñd5›tÜDëOÂÏû:t6~)_ÎW9È#\ΟîÐoq[ÛB÷NJ±²¿¾à,;“æÜ‹«@ˆ:’¡î5ˆÀ¥à½¯T¦†Öö­¡º½»ó=k½ß•ðúßEë¤40ÉãNßPÒN"ó3RƒÑà+Vl#^üÙk‰n«Ú“oK{¹[ȱ°k¹ Ú¶é&kýæPat:†¸µðŸø³oêjS¹“ð´¡/±Àóïªÿ™7ÝxeUÎïÚÝw`Ï1üõ¶\V5\‡±üVõ+³ÛÅäú3èW×G=^å`QCuÆc°é`¨%!¯Ö#Á®íÔl‡r×Þvoa¥	(»·O7'Åóm;Y¶27{ÏÈKåûhË	é=µ«8¶øt»É‰m!núÔÞ±^Ý{ã$èÖ´¯£gÏ眦†{	§¾
-1ñ—SBÿÿŒ¦z‡ÑóÂq»¯'‡õà®ï)þ¶å®s,©B͘š±<)¬f¶“ÚãÌÁñƒ‰©´€À	™t­“c„‰'4n½WϺÜ(}†-a‰ÿEÃÁ|ùÚÙàc;5öá^Hb¿¶G>
-СBxñGýãûîPMtÎóÅõíˆVAhQ°ÅõêsòöŸoþs}qužrI“œœ§2§É÷—~@ˆÆŸ·?¼»|ÿËÕ›s•%×—? øêâÝÅÕŇ·ç)+$ƒýÜSx`ûË_àèýÕ›Ÿ~zsuþåúdz‹ëA–±¼Œ
++ÈïgŸ¿ÐÅ
+ÄþñŒ¡¹8À„¦5_lÎ2)ˆÌ„úìÓÙÏÁѪÛÓŸ‘Wr¶`Œh)ùDƒR“\pá4h….@”Òä7sâ}êËÞlLÓãôó+¥¼©úªmR6+üÒ•wƪ#kÑEÊ3¢3–¹S®×‰8%yÆ5 [{úœàHeàpº#c d…Œ™§%þtërwΊĬüÜ,qîw91íà¶Ýá`ߪ~£ëO—ïqô+•´3æÔÖU$çÀ¤É5ÕV븸»[ààjd¦?o@3žÓµ‚2KÔ¾å¬<ãFJ>¬'ÜÌ\eÀzŠ‡5Ë(‚!AoýÚëmÙn6Ö'€«E*%ãr‘λ—ë²iLnó€NYÆÀÚ¹Z(ΉR=¡Ó?o˜Ë3§;Ñ)&N²?ô@ÁCÇägZ°žâbF-h• â£DåÂ*N-¸z$vXA£Å£±8yÆ"±Ãi–,Ëír¹ßá°ôkήœÊ¤o·©Í7g;‹;AJmcÃðn¿+½>h!µGh=ùªéª•‡•™•Dr„úV™C,#@nUTžJ©›k™üËÜwxÂʤÞsEÀß²©?bæ°iLXÎðäMQÔ9wJ‘MžÐ¸ÎèLãRG•ÃàÆà/ä	2)ëVød ‰—É¡õ¦Yá&‰ùËÓ™ÊÓ.W’¦2ÏX­ßµu‘.”BJ6ó§Íœòƒ<Õf< )äžž4" ~:Þ	¥Ýg´Ñ2Hlcòó€XOq1£vL“–…;ó7¨38ü†Ëßž¥_ÆP²o0pNèÓ‚6m<”ä©ÿ»O}t¢H=’æù"Ï9XOëçÔ(€YE¼BIŠé˜¤SÖ”5.I¦ev<Ù²X­bQä¥xe]šAdt-Œ¸J~kÚCƒÃ²Ã_T ]s%Ï“¦Ü·“'•G*qeÕnÊÊï·X8Ú7Õï{SßãÒTÓW·÷Us‡›&0Æš<¹ìŒ¡
ƒ›@φ¶3Ÿ?dŒOãå±@#
+ICYÔ™Ý7³‹E)%”ñHrwy3IJR–@ c‡éHåSô~]zˆ?¡í8kÁ¾ênHœX0áÞÊ'© "§~,&)nµB^:¿)ûåÚ'=·7éXWu…,
+Y)Šxëx2
£ª:M8'ÃúºüfpíƘaƒ00ö®’´ô&8Ê^ÔB
^¦Á»ê»v6aîË!„aÞœ¡%òëâ‘°¶…²!¬‡“fÁCˆ‚ãäT–³üå±í	¦cŠ‘ÐΡZ~8´%¨P«ÆŒ2«nûÓõ;§c;F«fbÝÖ,«sæ.lÓ!,l0PºTýýwå"vé+G4¨	BªªäØjå÷í·Ûv×û»Oèƒ)¼¡(£lê‚ëM¹L7+‘(S¤àT
ÉjNR%‡ºÁQ‚
+‹‚ǼnÅS¤ŠRœgb¹ÅÙßå‹ËüAbòïE”3¸5ó¡,õqrBŽÁPeò„ždüAz!ú‡'Ù§¡dTˆb‰c±ÙœÓäú\SÈð lŽ·ti£[[ÇãR$þe‰ÞO$7÷.·[(Ò0[Ø_î"ÔTmöDjö›—`aÁUÔò˜¢«áùêÈV.Áúáé4¯øç•Á²p|hUvºö_ÙÛŠ%†Ü‘ˆ²5ÔÇLðSMѶbðv	µ!è-ƒ»ù¬•Ã=–7$>ÓŸ¦,Ár’CÁo|ÂuÎ^œ²ÁtLqž²8˜Ô¬8Œ·¨K@ÑŠXÉBŽÒ–Õ,ZV³I‡Á-´Þ~Ý×ù#Ûø­t|m8_åÀp9wlÝ¡ß⎶…"žœ”b%d}ÁYv&Í3œ¸We$CÝ1jKÁ{_©L
­!í[Cu{wç=zÖz¿+áõ¿‹8ÖIh ’Å?œ¼¡¤DægÄ:£ÉW¬ØF<û³×"ÝVµGß–ýwÛm\m;t“mþ\(.:È	ÎŽ´BÈÚñŸø³oêjS9#x\†£/±»ßÓïªÿ™Ù.¹ñÎ4*—?µ»ï@•ãñ×ÛrYÕpÆRCØÕ¯ÌnãëÏ _]åx=æƒEÕ[‡Á¡ƒ¢–0…”ZO”§¶SµÊ]38B8½…&€ìÙ>ÓœÔÍ·ídÛÊÜì=!Ï•oU .'¨÷`þj9q¬ñéq‹m!dúÔ^	¬^Ü{ã$ÈÖ´¯£¶çsJSŽ„R_…pxŠÊ©G¡€ÿÆIS¹Ãìy‘8Û×c=¸Ny!÷–næ¶Æ3`–ÅýëÔf@FŸ‘_Ò!wÈ©PáÞ	Dï'.4‹tÉ…õçðÙe¡Ø,öÍc;rvô­ÜUÆú¤Ø’Äb
B;à¶Ç¼h'Ø<þímqцä_*³‚Tö™ÜÅú}R(KBÕòý\<¨à‘ª8É×Ûõ®Äç­½ÿºvYܶÚ}¿Ý÷¸¶1ýº]u¯ð¹	ŒoJ¿2Hä:Îdbœ×ìÌår°|ñb}뾇 èð|f¡ÓçJ?Â×3;6NÜÕ?>}7(¢,M¨Eó’‘÷¼‹ ÒACÒ%¶0µYz¿]·Xã·{_C,kЦñ,N­;ëÉ¡Ì8ÖÁfºUš¨lÚ«úظ¾J–%m-ƒ:#x~ÄË”FYiyiWe2ÔZ™ïj$4ÝZz¼MÙx¦¼ßy8z£Ž+:O`€‡²é­èP^Éå-Á€GÇ™ÓLA	ÇîþÈìMëÁCÙ³’ëY+üÕIWq’¹æÝzªºÊÄ^Å’áb×H=Ç5)
+uR½N/•¹-÷uva_±šy=º+ÞÃ0mÏ?“ökׄ¢ìcu3%’ž0˦Ãi²¶Èؤ¹´ßárí?4Û‘~5þ €cÞ„ÉLåhýÕþ¶.8ìÈ€oêªsœ[ÀÁ%;èÚ'kð­I‡o/v¼.ý9®å)þ¶å®s,©Bɘ’±<)¬d¶‰ÚãÊÁу…)·À™t­ãc‰'4n½WϺÜ(}†#ጉÿEÅÁzùÚéÆÇNj웽Ä~h| C…ðâïùÇvÈ@ø¢àñ‚æ¤àZ¦¬àBr>|øŸ³þùÌ^#endstream
 endobj
-1136 0 obj <<
+1141 0 obj <<
 /Type /Page
-/Contents 1137 0 R
-/Resources 1135 0 R
+/Contents 1142 0 R
+/Resources 1140 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
-/Annots [ 1140 0 R 1141 0 R 1142 0 R ]
+/Parent 1150 0 R
+/Annots [ 1145 0 R 1146 0 R 1147 0 R ]
 >> endobj
-1140 0 obj <<
+1145 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [406.6264 730.8852 456.8481 742.9449]
 /Subtype /Link
 /A << /S /GoTo /D (tsig) >>
 >> endobj
-1141 0 obj <<
+1146 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [140.5805 719.5976 196.7992 730.9897]
 /Subtype /Link
 /A << /S /GoTo /D (controls_statement_definition_and_usage) >>
 >> endobj
-1142 0 obj <<
+1147 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [103.6195 677.087 159.8382 689.1466]
 /Subtype /Link
 /A << /S /GoTo /D (controls_statement_definition_and_usage) >>
 >> endobj
-1138 0 obj <<
-/D [1136 0 R /XYZ 85.0394 794.5015 null]
+1143 0 obj <<
+/D [1141 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 306 0 obj <<
-/D [1136 0 R /XYZ 85.0394 769.5949 null]
+/D [1141 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1139 0 obj <<
-/D [1136 0 R /XYZ 85.0394 749.4437 null]
+1144 0 obj <<
+/D [1141 0 R /XYZ 85.0394 749.4437 null]
 >> endobj
 310 0 obj <<
-/D [1136 0 R /XYZ 85.0394 543.6821 null]
+/D [1141 0 R /XYZ 85.0394 543.6821 null]
 >> endobj
-1143 0 obj <<
-/D [1136 0 R /XYZ 85.0394 516.3776 null]
+1148 0 obj <<
+/D [1141 0 R /XYZ 85.0394 516.3776 null]
 >> endobj
 314 0 obj <<
-/D [1136 0 R /XYZ 85.0394 259.6272 null]
+/D [1141 0 R /XYZ 85.0394 259.6272 null]
 >> endobj
-1144 0 obj <<
-/D [1136 0 R /XYZ 85.0394 229.5133 null]
+1149 0 obj <<
+/D [1141 0 R /XYZ 85.0394 229.5133 null]
 >> endobj
-1135 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F53 962 0 R /F39 863 0 R >>
+1140 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F53 967 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1148 0 obj <<
+1153 0 obj <<
 /Length 4006      
 /Filter /FlateDecode
 >>
@@ -4144,2453 +4180,2466 @@ M
 Ëé×xÃ2žI•E‹¶˜DNÅYñ/
ÔÓ;[TØbìíª£;ý‚ø9y~ݺ˜_·.&÷?1HÐ9,’ÂÉbžMïN
9I†uf ÈGçŠnú(0í|ÚšûÚd®yØv¸s> endobj
-1149 0 obj <<
-/D [1147 0 R /XYZ 56.6929 794.5015 null]
+1154 0 obj <<
+/D [1152 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 318 0 obj <<
-/D [1147 0 R /XYZ 56.6929 728.4063 null]
+/D [1152 0 R /XYZ 56.6929 728.4063 null]
 >> endobj
-1150 0 obj <<
-/D [1147 0 R /XYZ 56.6929 705.2957 null]
+1155 0 obj <<
+/D [1152 0 R /XYZ 56.6929 705.2957 null]
 >> endobj
-1146 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F47 879 0 R >>
+1151 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1153 0 obj <<
+1158 0 obj <<
 /Length 2604      
 /Filter /FlateDecode
 >>
 stream
-xÚÅ]sÛ6òÝ¿B“—Ð3Bü“§4g'î´îë{j;š„$ÎQ¤KRQu7ýï·‹(R‚ítîáF‹Å~a?¾áÇ*f¡Ì¢EšE,y¼(¶áb
sŸ.¸ÅY:¤åë»û‹·×2]d,KD²¸_Mh)*Å÷å/ÁÇÏþ~uw¹q$ìr'aðÝÍíß’ÑßÇŸn¯o>ýóîÃe÷7?ÝøîêúêîêöãÕå’«˜Ãza)<±àúæ‡+}ºûðãî.»ÿþâê~”e*/%
-òûÅ/¿…‹Äþþ"d2Sñb!ãY&Û‹(–,Ž¤túâç‹Œ'³f©O±T,V"õ(PHŸãŒ%¦P÷
e<èu÷Uw8ƒ"o,p÷øX¨ÿtÓW_-~©vëuÕ¬é³jVm·Í‡ªm}¿Ñ–H5ØÿžfªÆC!¶m©Aý‘ÁÍŠ0†SæÀ¯{T:H¾äœeq,Œëº}Èk@V	ÑÅaÔú«¶P³;ü¯»K®FXÀ6FZ˜ú·6síÜ4ÆÝB™r
-xÈ)Mì«ú’5}âǵ®)z)Ô#…’ÙÉ0¹ÔC^Õ¤â0hwÃãn@ËsH2¢
-S@õº¨VúÈ'0ðxQÐ÷è 0¬uÕp¸äœ£?#l…ýG¾}¬õ;ÏÃ90JRÃhAÜ\.“бP_Ì>_¬âÌŒ¬B²ŒŸZwrÒ«UÛ¾z?CÜFˬÁ³RàPúÒKùÏ÷—Ê2daÈ•Á 
-,B	Ö&ÖÅ³Ô GåÓøºù·’áPÚ™Ž°kp2‚äÍCµÕv´±ƒ1ÂÁŠÊâ£CžmÏÍ¡Ãp“&yÍ:7ÿåq'àÊ»i3%Ç!U4#SFð«|àèW8câîùÉ!ê.uÁ¨<@D¯
-_Ð’Œs9tg>$½ë513r8Ï°fîÈ´töF°S<@!x‘éq+Œï§HwÛªÑäÐûñ˜L¢Ÿ–þ;ðlTãÄÁoV5d¥¤K:fíÒXÙ£ÅT*#‹ºÉq߈C(6é=
-¡ mƒ1’.ûã´	O0WBÑ@#
-:8gAäÅD˜þëv½Ö%ó™0Féâø¯s¿ÍÓM&áÅ	€„‚Z1•ÄÑÜ(¹‡JÌÄ1Óz`Üè9¤Î$³h6è¼±im7Pº2UVœ‚ƒíòÚTŽ1¦qÎ
-ÎõUSx•R’EýFFòºo‰®QcO[’Íhm»D T´IáÒïY<
-TâéÌ:ÐY·ÝÁÃO’°4‘.“Ú*nE	HŠ“RÃÄßwºt‰ÊSÜyDâ:ƒq7ó…!ÿÇi{€h‘u<?Øir<o‡ÿ½®1ÊH(9¯«ÆØÆe%‚ʧ	¦0¢Oõ0Æ"–r5Ñ1ßØ=Œ˜¤š<Êz_°äbªàË…šÐÏùsÔ~Ø4£qpeT­yN¢Ì˜I4“Ñ#›È ŸÀöûœÞ2‘æÛBp-idò	wyE»}íãê76t¢ÓË8;9¥ÆW¡¼µÆ…j3¯÷ù¡'¨14À»Ú¢šjJ:/Y*­©ö¢Js–îÞ/¡4ÇM#ÕÑÝœKH5/NÐsÂ$ø¬mÕDZnLmûÙŠÅ2¾™à"÷µ¯¨6„ä5
„/™Ä/Zô—‰ìÔ2¦9À¢ñ•RÐ<ƒýñòašp„Z^ë‡%dÚj¿ãwÐ<¨Dd­Ýå5è_ˆõqUh÷ÕÍÊnùtév?ÑR"''Ì·ëüHàRcœ§LÐâX„&¡s"Òú"Žl^8óh³0{©9Ĉ8¶¯{"YêU¾«bùòлMÑ{tŸHŸÛ=ÁE´*Ÿ–á0Å„ŠNÊ+‚-Ó¨„î‹®zÁÍé5O±_Ñ"‚Ø̯ØÚÉn½ ÁÝäeÄ_Nœß œÓEÖ…½ö0wP"§,Ajf+ÞégW9#ÖŒœS£æËãà<–=Ó3X;~±÷¥naŠVæzÛ6ïÁï%:þÛ·¶ÑÀp„Õ˜Eè9Çe´Þ
d'¹£³Ê‹ª¶Ù´3Gž¾¯¡Î¸i›úpÊÄ“v¾Ìǘq“»Å¶Õ´m¦y"ÀŸcE*ŒžÖú¤•ò*Ÿ¶hæ2ˆ1¯PR¨VŽ’îA$=Wüˆí$}YN“A¹¶û—9ӆߪG·%Ði§ã–Þ¶FA£ërMgwµv§³L|@”—¾¤0šmu&ðs[W«î]K3eÀ\˜éò9:tÝ5£ôz¹zmy2ù…yýÑÛ'Swvf¨ñaÔöpmo9Ÿ5S±ë:Ýg
9UL^ç^ç”Ï„„‰Ÿ	
¥LÏܱ?	DñņÿÿIþfe5»zvÇÂS–I¼ŸÝ Ê“MåÚ¾w†ÍxÖúÑ®¶Å‚3ž†‰ÿ¤ÀJKÆñ5(ú+W2Ùø*à»y€ŽÆ.ùŸ¦^© €x—ÅPX	õ-O ‚e
-ûßÈr$¸œP¤Œ8oÚ8Kp¹Ã"ñPxÊÁb9Þ}Ž¶Äs= ÓÔ61vn§©kugúÓ³áÆÕ@rÒ	v¹+toçÜMàÓ‰t}ŸÙëìc©À†ÙÑðb"˜)8Æ[æc}Ô´»N¶–7ƒ›é¶®/?Ïé-Œ½µÄJ³¶•s+\U8«-`’A×N‹G“iÎ5ŽEˆR®Ì¬wsªÝMèìöÉ0çr©ø*ª)ÿPGB—!tÙišÌ«›ks‰šE@‚¤‰
øe_~zhÞPCã©"÷Ô¿B}ç‘•G’©Œ¯;ß+‡µ}å@B†$t}[êèࣦ±,¶¹„ ô6™ix‹Ÿxláæñnl‹^Ðy*²äøèBìVŒoa¥e	]÷‰7M3|ˆô”­á(ùÿüÞy|ŽR&•þúÍ®D–:¦P@™r>>Œž³þ_ÎŽÙÙendstream
+xÚÅMsÛ6öî_¡É%ôL„?€ä”fíÄÖÝu½§¶“¡)Hæ,Eº$W»Óÿ¾ïá)Áv:{ØÑA ð¼ï/ðE?¾P)‹¥N¹NXótQnÏâÅÖ>q³ô@Ë)Ôw·go/e¾ÐLg"[Ü®'g)+Å·«_¢Ÿ?üýöâæ|)Ò8ÊØù2Íâ軫ë¿ÑŒ¦¿?]_^}úç͇ó<‰n¯~º¦é›‹Ë‹›‹ëçK®Rû…;á‰
—W?\ÐèÓ͇üpsþÛí÷g·#-Szy,‘ßÏ~ù-^¬€ìïÏb&µJð3®µXlÏ’T²4‘ÒÏÔg?ŸýcçQMw†–‹r.!)\;þÂjÃì€aŽ(ë
°O"Ê Ôá®ÚÓ\?Ý`ñÂ/dœbç±s.˜2ƒƒñ¼¦Øš•›j‡M5wPžáxì#\L׎H=Ù™ÇLÉÔï\†ç)ã"Nȯq,‡óº­ëö0šÑUÐßCÛWƒÕ8üªšÁl€Ý€èIÊ4j’~gw®¢]Ó ONY±R0™(éYLN¤kV%šµŽ†®(Mÿ$a¨„ßáÕ™-ìEc/ÚT¢…Y2(X5+U{cKÿSÝËxT4+œª€9Õû®1+·kÜ»¶{cË
+œ}–R)–$±r$Y öýI籜kaÓ>ÅÉŠk‘Fj«Ózn9*Úš¾/6¦§/ëˆÌ\©ƒ‚Éûâ«›-èo4MœµVª§`ý¾ÚÜÓæSXwᆼ—B>’ š=
3’Wf(ªšXGínxØ
(yá\FC§Â8Fýƒ)«õž>ŠÉh¼(é{TXÔºjØŸsÎQŸqn
+óG±}¨Í»€Á¡‡€˜d¹E´$lΗYìQ¨Ê/öž/Nqå?–V!™æÇÒ]ôjݶ¯ÞÏýwÁ!ká8”¾žüçû€ÊÀÉ2fqÌ•…'
+(‚‰6Ö×¥³Ð GæÓèºýw”áPº•Ž kP2š)š=
†jkÜèÞ
F;*
+yr=·F‡î&Ï"ÒšMaÿW‡›«€ï¦Ë”=„TÉìpX²t€^å ½ÂëwO-WÄÈ»Ü;£Õ(¦r™8ÐûïM8¸bÞ“øàJa¶mÐé£?.[÷k+HhDN׬bái1Lÿu»Ù˜‰0EêÒô¯c¿-öÓK&îÅ€„œZ–0•¥É\(EFÜ#Óï{@<äè9Ë3ïçÏA«½½³ÆÇ.ÅÓ _»¢¦ÄQCòÈT𳯚2˜§äœÅ<ÿ6<¸v`EÝ·t.@»\Ú¨À1®—1H¥yX­¸ÌX.Õ\4%œ³i»}›,gŒºn™$KD,Žòë<~ß™~0+T3Žšk!¬ó4o³_èïð\vÖC›œÖÁô[&­£±Uuø45º	ùæeÕXÉø£DT…ø Áºó)F'àCÂr>å!߸;,™Äš8g)äô!OÉÅÔOÁ—÷50´~ŸóäÈüp1FwnÆ[ß2Ñ”ªÌPj&E–ÌhÐ&4scö×>`‘Ó;$ŠýüZð¬+Ù`Â}‚‰²ÝÞ÷q÷ç73HÂdªLÔê*ä¶N¸jõc±ïiÖ
+æ,ºÆÚTJz-UÊ«)ñ¢4–éÞ¡=Hk(©êæUBªyf‚šgÑgãR&ºÐac[¸Ï¥+ñû	,b_‡2Šáž€‚¢ß%³ôEÉÿ´ÐÇ’±é׈&M(‚Êä‡i´jyiî–fcJpxú.NßAå 2I3Ó˜®¨—õbLŽ«Òø¯n–s˧ó¶Û	—29A8 ¾]GÓ4½2èä)LÁlyÈ@3á3Ðù!Òé"Ž\P8Ѩu¬_ªc¦õX?¾îéÈ•Y»z ÐØHׇÞ_Š*Ø£ú$*úÜ>Ò4¨èžvÓ–˜PÉQáHp9åÏ}ÙUwãts܃á9k"Y$YÆxä•[·Øm4¸™´OFøåtÃiûäô\DðgSºž‡m@	ðL£q™ILw§7œôqF¨9=*¯€‚óPÊDòLÁàäøÅÅÛ—J…)ت0Û¶yz/Qñß¾u%ˆA†#LíìŒÝ„šsØFW`c@•ãþœuQVµ‹6À9¨%؃:Á¦mêý1^àOÚù¶6b†Má7»:ÓÕ<䎱0yšë“:*Èt~\ŸY#eàc^!¥<™Pú$™9ãGhOéËtÚbk»Y›¶øV(ºKŽË¿õºÐZ^k:w«“;Ù2áP±
+…Qlë‚Ÿ»ºZaïë™)¶[fVÏC½®ÙI¯—ë×'_XPƒE2•f'‚
½vk×â|VLå®ëL3œTã”1•S•S>ã&B|Î%X0¤2?QÇþÈЉ/¶þÿ–üÍÌjvõ¬Á¡š’ØŒŸµÏéÑSz†¶ï=Fûá~´µ~”««¯…àPdÄYØR`§;Æã5%(ù+ý=>	„ÚPÑø$ÀÿãÐ+Tàït
+‰•Pßòþ!˜VX7„^?–ãËɉgEDÄ·{(Â"Ζʱñ9Ê»;¶7 óÜ0cËëÂ-S*Ö>˜ÎÖ'¶fCÆÕ@3¤¤èÕ®4½[óm,€§çéë>{×É#ÇRõAðbB˜M8Æó!?jÚÆ÷’]·òjð+ÝÖUåéÁ<§-ײÄL³v™s	;|V8Ë-`‘AÁ—O“GiN9ŽIˆR>ͬß65¾
:k=Yä|ì±_Ey"ŪH¨ÃC•çÙ<»¹´TÀ¹à$­oÀ/÷ìÓCð†
+ÿB•ø†Aý
+ù]€VžH¦4Ÿ8v¡''!÷ÄÙ#¡êÛºîCÕÔ
Ó©‹%4K]“ÄH‹[úÄK·/wcYôÏs¡³Ã‹Itr[9>„­J¨ºOÆ||=Eý¿7•ØÁendstream
 endobj
-1152 0 obj <<
+1157 0 obj <<
 /Type /Page
-/Contents 1153 0 R
-/Resources 1151 0 R
+/Contents 1158 0 R
+/Resources 1156 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
-/Annots [ 1155 0 R ]
+/Parent 1150 0 R
+/Annots [ 1160 0 R ]
 >> endobj
-1155 0 obj <<
+1160 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [173.6261 465.0053 242.2981 474.4149]
 /Subtype /Link
 /A << /S /GoTo /D (the_category_phrase) >>
 >> endobj
-1154 0 obj <<
-/D [1152 0 R /XYZ 85.0394 794.5015 null]
+1159 0 obj <<
+/D [1157 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1151 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+1156 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1159 0 obj <<
-/Length 2725      
+1164 0 obj <<
+/Length 2737      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZKsÛF¾ëW°r1TebçÁc}Rl9«ÔZö:Ê!›M¹ r(¢Há¦òß·{ºHÚk¹Ê¥ƒ€ž™žž¯ßʉ€?91¡&*™DIà!Íd¶:“;ûáLòœi;iÚŸõýÍÙß^ëh’øI¨ÂÉÍ¢Ç+öEËÉÍüW/ô•„÷òíõë«~~qÞÍÕÛëó©2Â{}õÏKzúáýÅ›7ïϧ26Ò{ù‹w7—ïi(dß_]¿"JBÿ0}ùúòýåõËËóßn~<»¼éÎÒ?¯òûÙ¯¿‰ÉŽýã™ðu›É¼_&‰š¬Î£}hÝRò³ŸÎþÕ1캥£øIá+ª•Ð$~¨aLµÝà1`²ìMVÊe¬`œU¤+;çY}–¤3±äYË´B|"o¶L‹;X/±W—D¬—–…} ÊÏW¯žÓSZðä´Øeno›;¢•M½nj"ßÙÂnÒšxGÞÃ2ËíˆôZ?ˆ“è³ÄÏXúªN7uVðîÍN¦:–*¼¥ôcÁçã¨ê,Ïéqs«Š‚8À»CÅÑ%¦Ä“Dšvê<«f©šÛ9Ø¡Ž•wµ ±mÙÐCa-ïãЄÿ³t]7n™%~õ²åHx!²±Ø±X5UÝ—Ù9¥ üvs†àž²zé-†‡e
-ï?J§Nú6#}'	Ã9½A¼eGSDZ\×YYÐ3ƒ Àì<£ÿ³š¨ žbΈÅnÚ
½’ÁV•[Ÿµ¨}Tbä'ZENŒ·Å–·$	ý6'šƒþÏ-r*ìÕ"ò²šè3˜[òó­%,y»Ô¡w³l˜ie°8ôÒ¼¶çÒÛÐ<›,¯§YÁH´Š&í°É·çRJïù˜Þn†Ž¶…Ø–Vå<[l·V½s»H›œ×äåÝ;ƒðnyêºÌŠº£ÎÀ!ïÊMf+ž—ödío¾Lï»:€û°pÚ’²é1ÐAüB–v°9ön¹I+;bxÀM~ÈÀqƒå­óèâÏî%öV.!yw0Ðy W•4à΂sH©,Z-’ŒHä*"ñtˆWiQÓS]ÒPeyöC+‘sÃG«XtMðï1-'ÒØm­ZI©”ųšhÈÏ™dB‘FyZ´›zÕÚÎÈ8!fœṲ\|…
ráœp7¿Ó'8Ž¨ I &M[ÙªJï,Ë¶>8Ÿäèƒv¥UÜS¹V	@‚éè}H]ðL‡2PP'-LÆ£9µf?’'ŒŸ´1«¿y¢VµMÑÁ
88¢‰TÒìËh"­Cé)Ñ:GCÚ#¨‚¸•€ˆ%äcu òE™çåCç‡N¾Ë/»0›±/6•ÿ}$‚‹a`Ü5½°€/hªmÊ|1$ºδ¿^pÊÄãØívÞ¢ £K©Ð³¤«un—ÛúYEUº¥™ŒsØúHã†LËM¶³f“Õ¼¼«¨™M;5¥Wʼ›™ƒ-Ò¼âùíf¡÷ÑÚ5oëœH=#Ú7àa$µ3ðÈ·˜õ¥ð~9O$ïgœÕvî×ÍʪíÒ*`µýÐBña0ð§“Ui?‘"J¼ÀêÊMú®¿Éß½A½ظ(+%M›î±§Ù½ƒiht;õ”•˜œoTÄ}‹‘`Ï~Oà±Q÷•pã´Êþ¸«õ8Sºšóð.¢›ƒ
-f?2ŒZÇH	/é¸+‚Ø챸P´µa³,8ädv$@ü±°›)f§~„Àm1`_!CP
¹cãp ŠD‰ã÷ºE°KíøBn„Ôû4ËÓÛê-¦ŠœáªPx¸Ú‚続m2Wªò¬r1`eøvm÷Æ(ËÁúÃf•r¥K«¶¼{YÔiVøc½)»#Œ[«tÛF6šùÜ·v´hz½‚é÷¹DÍ-M•¿ßÍJ‘@ý%è“4X’RŸÒÏBÚò#íõ³ÿߪV,!U‡Æ–€Ö	àÅíŠ!«iw(,5`FíºåAq ±…Œ&Ý}êðD‰wd‚Ö×\uèh—3Ý+†xˆŠßŠ^kZîÒRËÖØð‹«Ñ¶¬¬pm(Æï»27ѹˆì‚î>ãeeow͆‰ØÍÇ[k‹±ê½o8‰ü@Bû݇øËÔ†ÅcÜFbý,Û‡-!‚&Ž[ô¶~p;Bù§Y‚L\|™-§ð},r¥÷Æu8{å:>ó5>ràr¤c§Uå´†îèÁÊŽùtLY»îeÐXsÜé' ÛŽ5kîÒØrŽ(·‡Ú—ib_¹Á“*×_á	݆Æ7qD){žÖéíx9Tî›.kkcÚX
-.Y‰®È4mh‚Ž9/ÂJœ@›vS€B¶4½ö±;¼ÓâR ½ºéÝ}Tõ iü·,ìž
ÌÒY×ïƒHGÔ¼Ã充ܚ觳l!8¬eû"§ãj¤F‘áb•KËSj¾X¯é‚é>Í÷PœÛ"k‰.ßw9õ÷ÆVuuÖžÀ_Â>®êIqU¡/µ9‘$`‘â+å6›œÄõå~ÚÙ]×ñ5Sº©ºŽ©Ãœ•1çƒÁ#÷D*„¿FòÊWÊœJ>PvGaDa}c«2¿ïîí#üêú§ó©²”lV5ˆôsüÜyU3[â0]Qã4]À׊
àoi,/Ëͺ¢ñ5e‡Ñ¤ƒEn[¶ZÅv7_ýd–gÔŒ÷oÓ]tê4ÿ(Ô¹žù Ú{x>mÀzRÇ’‰ðU$ÔqµËDû±	)/aåP§²£šÿwñëMZT°²Ú»Iè§ö^ˆÕn³û£žÕ—ýŽ]2æý¯a£ÇÀFÈpˆ0ß±~ˆñ¢ø8¸$µüÖÁ
C_›äD•!Ђ.÷öŸT2#T×oo®^ÿ2úu9+ó#Øõ„ú–±3ˆàDR•pª$‘œT]°<‰Ý»An‹·ŸS£ôå|*8
T
-‘‰?ƒe»â œAÍÙ	4ƒÐ:¤Õ+lÇF?
-*ñebøv\ôIÙRnÞš"½Í-ÏäÎln¡ª_eEK^òƒëæƲ'jKljûš©A_Tð°Ì0]#­î}½Â‘´":ö÷Hp‡Cý|óˆ±ùt÷™}»TP8…í‡\hX#{´=ºš$þn£ßŸäî¨JC kV«Ô}—Óý´à[t¥¥»æpU‚æ®EºÇ”ÄÆ»½¥<ä	
-*$
µýÞw¼4Åv(anð9}O‰Ü¡>t©5}¡×:€Ú¿y!…?,iú””^Û¢IN_[ù9~˜†Zå95x·[Ø}õÁM˜a6jUç°mc7x—€Rásoz{~Ï¥¾ÌK¿jز>FãÐW¡ (ZØú¡Ü|<éõ×<›`©A9){’|Ãy'~$ãQ€lÍz.qºÍØB8Ìfí®9‚UOŠ/;X €“‚âo‡UlF%&'üÔcí~©D¾Žc5þ;+\
-y!BxôS±öW[<«'úÿ.n‰endstream
+xÚÍZÝsÛ6÷_¡éKè™
+‡$/Onbçܹ89×}èõ:Z‚lN(RI»ºNÿ÷ÛÅ‚)SRrqf2~0¹‹ß~b¢
3‰L&Q2Í…žÌ–'|rßÞœ?fÚšöGýpsò·M–i&7‹¯˜ñ8“›ù¯a’¼zwuqùæçë³Ó(n.ß]N¥æÁÅå?ÏééÍõÙÛ·gקSk¼úÇÙû›ókúd<.¯^%¡{˜^Ÿ_œ_Ÿ_½:?ýíæÇ“ó›n/ýý
+®p#¿ŸüúŸÌaÛ?žp¦’XOá…3‘$r²<	µb:Tª¥ä'?ü«cØûꦎâ'8“ÊÈ¥P'Ì(ø„¦‹Ú®q0XôKÉbKXGéÒÎý¨>KÒéXøQ÷i…øDÁì>-î`¼ÄA]±¾·D(ì#Q~¾|ý==¥…œ¢ÌímsG´²©WMMä;[ØuZï(x¼Ïr;"½âš…q}–ø™—¾ªÓu~õf…'S•KÞB°DkIð9ÁÁ8ª:Ësz\ŸÂ¬¢ ðîPqt›)q'‘¢Õ€:ϪYê>ÍíìPÅ2¸\зMÙÐCa­_Ç¡	ÿgéªnÜ4Küêû–#á…ÈÆ|ËbÙTu_>ÏÎ)å·ë0÷ü˜Õ÷nÓ|¸Y¯AüGÊàTIßf“q’x8§w#ˆ·ìhˆãã8–«:+zöÆÀ	0;Ïèÿ¬&*¨§˜{Ĉb×íš^Éà€–s™[浨˜5*1b‰’‘ã]1Ã%ÚMIŒ³ßÂæDs°Âÿ¹EN…²ŠGAV}cKÿ|k‰—¼j
CÜÜ7žie0Ùi^ÛS¬éÀFžM–×Ó¬ðH´Šm±É7§Bˆàû1½Ý6:Z`YzX–ól±ñ¸µêÛEÚä~N^ÞÝygàÁ­º*³¢î¨3pÈ»rÙÊï§ödí/~Ÿ>tu=õaî´%D/Òc ƒøÍ9,í`q/ØûûuZÙÃn2dI(BÇ
¦·Î£ˆ?Û—8Xº „äíÆ@ç¡ÒAUÒ·ë€DJeÑj‘ä`D Wɇx•5=Õ%}ª¬ýØJäÜðÉ,/º&ø÷˜–iì‚––­¤ÎTÊâEM4äçL2¡H_ý°h;ÌÕÊÎÈ8!Ï8«<“r1ðoç„ÛñvÈ8Áq@
1iØÒVUzg½Ì`ëƒý	}Ю”Œ{*W2H0ð"½) ?Ò¡ÔÉS¡fq¢•F­Ùä	Í’6fõAÔª¶):¸G4‘Jšƒu=šHëÐDzJ´ÎÑöª0nå bùD¨|QæyùØù!†Óïú—m˜Í¼/6•ÿ}$‚óa`ÜîÕð^XÀ—?´Õ¦e¾]÷´¿^îqÊ„ÅqìV;Co‘„Ñ¥¤	ìér•[Eä¶~Qч*ÝÐH³iý
+H¤qM¦åÛY³Îj?¼«¨=›vhJ¯”'üj.d–HóÊo3ÁGkW~Yçô@êÑ®#©…0˜·@¾Å¬/xðËi"!y¿ðYmë~ýØÜ©ü úÐ.¡–›-þt²JÅÁáĬ®Ü ïúÓ‘üÝËñÑË“²bQÒ°é{ý×Ë1˜†F·Uß^Y‰ÙÈþFEܵØ	vì÷Øžu_	7N«Þ·µžÏ”®fÄ<¼
€è¦Å ‚Ù£Ö1RÂÍ"wEp‹=Š¶6zØÆ,ö1ŽÌˆ?v=ÅìÔ¸ì ì*dȪ!·­CöD‘(qü.zA‘‡ÛÔŽ/äFH}H³<½Í¡Þò”Aƒ#\
+·@[ÐãÜV³uæJU?ª\C¾YÙo”åàýa½L}¥K³6~õ²¨Ó¬`c½-»-Œ[ËtÓFo4ó¹íhÑôzÝïs‰š[(š*¶ÛÍ
+ž@ýÅè“X’”ŸÒÏBÚbvúÙÿoV+–‚ªÖû% yxùÇvÆÕ´Û–0ÂDÛnyPl!£	Dw¦Œ2GJè¼#¶¾æªÓPEÛœª^1ä?Qñ[ÑkMSÌ6M µl
_°¸mËÊ
+ç10|Ü–¹¡Aç"²¸úÌO+|»kÖÞ8‘ˆÝüHp¼µ¶«Þû†ꈅÚï>Ä_¦64(ã6«Ï`ÙÎØo	ŒÐ&[­è€é!ÍwPœÛ"k‰.ßw9õ÷ÆVuuÖžÀ_Â.®òYq•†	¥$I	X$ý‘r›MŽâúj7ílëü1Sº®ºŽ©ÃÜ+cÎ Üý¹þɇK&¥>–| ìŽLDa}m«2èÎí÷#üúê§Ó©†²”lf5ˆô÷xÝU3»ÇÏtDÃ\tA‚?VlÿKßò²üج*ú¾¢ì0št°Èm+ÐV«Øîæ‹¡ŸÌòŒšñþÉbºN柄:×3ïU{Ïç
XÏêX"áLF\V»H‹µ¡¼„ý•CÈjþß]į×iQÁÌjç$¡Ÿ6Ús!¯v›=ô¬¾ìßpì0ï߆".ÌaÆú ƃâÃà’Ôâ[צtr$á
+´ÐPÂõ½ý'•ÌÕÕ»›Ë‹_A¿.ge~»žPß2v:d!$U»Jᓪ–G±{?Ècñösj”¾œÏ§†J!Òñg°lgì… 0ÐœA34Œ+C)ª)–ØŽ^
+ï+ñµtñô¤Íà…:T•Gn›A€$lo›Sϳ)Ò[,xÿ’þÏ-ôˬhÉÝ5Ç#=VÃSì±i ]»ÿx‡&tƒ„Çû“½¢ðÔ]wá—ÔÏÅÓœã Aë9R„Üinü2û8v¤(¡î2í=0ã»$8óç¨2Ä£:=ìj(’F2ȳö©j–ËÔ]ëÁ]mKï–wôƒHú;q¹ï–ÚÔ(»û›}Ž$cö¾{˃G®þîXrXÅr(ú
Ý»+Ý¿‰T&h©·Öݘ)㯥æVtݬ̶ä’»?ÃÁõ¯µ¡ÒÁæ]ÅT )Ý»œÅEF/z©¦¶…㻥Äçžï=‡ü2ÿªQ8–Ъ#A86LN1¸°õc¹þx4f\ùqþ—
–Ú›q¶'É7œµ"Î")§¢ðvجæàÇ›”
DÌlÖ?áœXõ¤ø²…8I(­ñlYÆzôÇU|rÈOý)×öwnaÄTËñ_iI(ÿ˜€TÈ
+ù“šµ¿ùò£z¢ÿÕezendstream
 endobj
-1158 0 obj <<
+1163 0 obj <<
 /Type /Page
-/Contents 1159 0 R
-/Resources 1157 0 R
+/Contents 1164 0 R
+/Resources 1162 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
+/Parent 1150 0 R
 >> endobj
-1160 0 obj <<
-/D [1158 0 R /XYZ 56.6929 794.5015 null]
+1165 0 obj <<
+/D [1163 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 322 0 obj <<
-/D [1158 0 R /XYZ 56.6929 687.8392 null]
->> endobj
-1156 0 obj <<
-/D [1158 0 R /XYZ 56.6929 663.0573 null]
+/D [1163 0 R /XYZ 56.6929 687.8392 null]
 >> endobj
 1161 0 obj <<
-/D [1158 0 R /XYZ 56.6929 346.0859 null]
+/D [1163 0 R /XYZ 56.6929 663.0573 null]
 >> endobj
-1162 0 obj <<
-/D [1158 0 R /XYZ 56.6929 334.1307 null]
+1166 0 obj <<
+/D [1163 0 R /XYZ 56.6929 346.0859 null]
 >> endobj
-1157 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+1167 0 obj <<
+/D [1163 0 R /XYZ 56.6929 334.1307 null]
+>> endobj
+1162 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1165 0 obj <<
-/Length 2655      
+1170 0 obj <<
+/Length 2836      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ZmoÛ8þž_aà>œŒ=©")RR÷S¶I{Y´é^’èEfládÉkÉÉå÷ßo†CêÅ–ë¦Ý()r8CÎçá¸lÂ_6KdŠ4šÅiÈÉY¾>gK˜{wÆ,ïˆü!ÕOwg¯ÞŠx–©âjv÷0à•a’°ÙÝâ“÷æïç¿Ü]ÞÌ}.COs_ªÐûéêú‚FRjÞ|¼~{õî×›óyywW¯iøæòíåÍåõ›Ë¹ÏÉ`=·Ž,x{õþ’zïnÎ?|8¿™¾ûùìò®;Ëð¼,x?Î>}g8öÏga ÒDΞà#XšòÙú,’"‘n¤<»=ûGÇp0k–Né/
-YÀ¸3_$A$er\,‰A¬í2¤RîKõ™ˆSŒ6‘*¡ÛÙ„³MX$‚D9‹e(Á…1Ên³ÈZí7:ßm‹ö•ëÄ`¨'–QÂþ|³ÙÎYâÕYIêͪuº*Ü`ý@-±§¾Y§ÿØé¦m‚}kD`ŽX)>âû#¢$à} ")ƒˆÅü%<Ý’£ÚVa(žÈSÚŽâ@Å1…~[è椖o7:/žIoO+Mª£OÇÃ|4«zWZýß[‚²^.µkk£i`ë;-+¶s<ÕkÚlÛî6ƒ¯˜‘Ô¢ZÒl»ÒÔÉÁ†Ëzë¼ctN\1a7~ü€àïa̸¥{*Ê’xgeS›-ú<ä\º­’Êt•Ý—x²8EîsæmŸéÏiöŠ»ªÔM3µA<âÉ`ƒÏ°rb‡`±8b–®Þ´E]ïU†ÚŽа®h¯,ƒ4ÉX­F¿…!׋Iµß­412» .îÅttÕº12÷¦Þ¶VpëæetµÃW¿Ð³Å‚–4vcr$Ÿt‰ç¾P±WíÖ÷àUpc‚íEª(ŠqƈŽݣPÊ«²µ¶ty™¡$è—…©$`D€î‘QY	ÉÉ'ç=
¬Þ1$-™Zwo0o‰3sc':?ÆuÑäu…)}¹Ûf	LòÍýD¼®äN‹‚øŠ+Œç¼~Ô]&)ó¥wöRj Î*ê,0!lú5µG³H»ªsN'ÎÞ›{ âM]îð@_ð™5¾Ï½ÓNxøtïVuš(a-UrÊixÀ‰ìÕªK½4öôëª<ýì¹èèÁ”€šÌ"Ƙþ“&Ü{_/šéà9~´«¬¥Þ*{Ôû½NîyÍCm,”£D<6FÇöúŸ?œc~DoB¸`f
J‡Ž5ë®l银5ƒ#O9Ž9‘/„òþSWšzb@uÀáWÃå…ÂÁêÓúŒeÀÓÈÑ›ð	5¹ZE"€µ»ûÁvtƒ)Uš¨±¶0)ÅæqWúÈ÷ù]ïÊý3ÿTÝ×Äa¼W7ø¶Un#L¥ˆ9VàÙÄŨÞpPw¡‚Ó¤1Dî_F£héÔÙWn¢0†-IŠ,¶0¶,4V>mÝëó¶…‡áÚ ?ShÙfë5\Ÿ‡Æ_@*Cؽƒ
-ËÁµ„B ³´å>À2ŽøÉ«“ŒŠöý§!9½$Š"GFGš±Ñq¤C±HÿT´+^Hú`Tµ"(¸í…ŠÇV°¤Þ¶ÍúÒÜàž´3KÝ©»›wºv(&âM_l˜Gvf=X˜Õ—ñˆV§:Й²Ùç\âDkò)ŽH¯r½ÇØI†Ì“4ë½
-ËŸéÞûÅE ÝEÏœŠú®ìŒý,Ïõ²q‰Ÿf”ù˜îꪚZ[‹„^aIÕS,6r5 I9#	Žxgê#ÎVÈi`0x×EÛQû?Nز»)Q‹tRWšstWj³œhÓæ-Î^àk@Åò!“:',Âý«	0“ﾨ
uIØë¿ ‚6£bμÞ'pl8âo×#”áIŽ“lEQÉ:˜wCF€ØØ€ßd9V—¹Hñ)Ng"¢Ý®@«Àc‚ìEãŠ>
+æŽ"œ"Ù*ƒ·Î<[žw
+œqpgÙŒ½[ËxæqÿèeånP¿õ„ž	ƒ[tG5	¦×ªÎhgJà±H
…ĪÕèá¿3ŸýDz% &<Çó§CÃo;´PÍ©Cgtèh¸è{áïtí½xaîøc³E„8-üØs=?Ž¾j¦ªª¬Î‡ŒeñPVÛÄx-ÎdU¶

!&Í&1`ã3Ú¼!»âF«=§.·Š I–·„x:f÷÷£b¶'Üø‹iÙ’vÇi@¬
+ƒ³"ˆà&#ÍÕ4«wI³ÞœeÿµA¤€$<Ê€à›`NÊ]²þ¬´ïƒ¥¦4_í`P«êIûBoË´Í)’¾0›aBÛM¦Àå0-0yÛ‚„	Oã²<0éûøþ÷š“ï¹£s²„dr|I²,àåëó’¼¹»[¼>Êmïï–ollÊu™¿`,ÈùœíÝùGY‰ðÝ(ð¿ÅûÙ§YË7–ÞY3‘Ò•"&Ì!A˜‘öž÷Tït.¾ט;ˆ³£Ú,tŠŒ“mV¯ËӪǶÒN' L{+D äm	…ÆHl2‡`ŽëhÐëòIuÙ„ˆ¹³z¦/Õ¢8Šé†VÐR3mÃz\Òw$’7šMY£³<¡	J,íºb¨.óô¥éIãû$ü·*Œ8¤÷ÁY{d‘ë‡"${T¹zÔòœ•E~¾ô¼îð1ÉŽÞÄ!FþÈ‚ß•5­â](l¼ƒÑ&yR4Ò‰¼AÐDI¬uDìrL¢7ÿ½þðþj©[øjyÆoàHiNÕ/ ÞñCõÚ_eavÃ
FÔ6©e€Û¡­ Îs/•ÌVf:´£K£ªÆ”ê•QÕ¦]ÑÈ^
KzÈ÷ÉæN«h_ö?JE-”s=ܲð¨'óÿí²áAìŠÐÃ.
¤c\†ý^΋žŽ`yqVTe ‚q+°
'Éb7àQ Å‚},7„\™AªK¢©ò»ÜcÃ"\-1]™9RÇpKôëàÓ¹%¶ˆ ê0È]ý?XÒÔôíªÝu’çv­hT‘jÇ
+34.ø G«ÖëßµÕ\d
‚”žs?!_2R($tëgûP­	ƒM¹§
+<Œ]©™>ðõÝ•€gÒï9­µEà;ˆ+„ŠUi9Ÿ^ÍŠ4[S’‚¾À8ôu	þ‡ÅÎ{H’GKBû‰N"3~ÈÕ¤®ijÜ‘"kØÇî¨ßáÙgÍfDÚPãøà;gükÊp×=ë`sõ¤rjÍMfQà†ÔàU&¾jº”Ó:$Lm'½{ØþãC³É7]×*Ñl>ÄC-„ÞƧ‘«.S5<ånq;õ}ç·7HùjùŽ Yý²fKì‡2ÏË}=?QT÷^|¢¨æ>óõ-a`µ„gáX—î‹ÛßÞÀ¨/ 188*¸_-o^éŠw¬}bÎ׹빈"6îú7¿×Š®ÏÙª¤0ÃDç3aO5ø`&ˉ(¹‚ïKæâ~ݬÀåT5jÝP&é›âržaAˆ¾«¡´ð[—­	¹4GsrPŸaˆHºˆNËKá%w#)¬ºƒA†¾À„€t?¢T8dëö`¯=e2öjÚêbn“ý¤j²uQ17E×Få;£qïhí:ië¯ÒØk'‰Õ-¤’UÖ@~$”äu¬ªh`Z·^ ;Xg Ö˜G}0€‡„(^£Òˆix£þ4Gdƒ†C&)“nàé[w ›íš;˜Äì°l°–c†ð5†ŽÎ˜÷)õWa`Ä},м,?›QöY}‹›çI1üAa‡@›(X2tc}€µÜ
+ßrã…˜Åθ‚Q'€öˆÈ<c<sš7ÙÖžV¶Í«º]¯uÓr›dżGür,׬Ô8„$Ÿ{—pSüM`^þQ=× ÏóèÚsÿë¼9»,à…Uƒ±‹®’ˆìæü2IW„öA]#Ÿ’œFŸÆ=XÇT ´¨jÔjó#ðª+™MÆêr­‘«![¨írbH$8ÖÒdµ”`d“°Ú‘½tzjèkå4%f3ƒ^ê“zzÂcO—CIÙ	—À5œRà	8Ñ)"é—"9Sà/níg7¸HÆQ®ìÆÒ./í	Ñ´oÇeôíÕ6+ìþŽ öî8ÒÊ<¢PÖÏõ}=µ³™7êè}¨el‘ƒ¹Œ§¦aèÇ«§ßc8TPk‡@ÝXÆMNZ-ÂÀŒ†Ø_»põÒÜ1'ƒP©?tØN’¼Ú¬±…i	ÊC‡	``Yj
+,È"¥½³DJÀþQW€±W€wÉ÷ɳs§³{\0}%-Ž1[öv×ÐÄÒÛ&)þŽBt–í£hˆ‹F¡ñg .J"†ý™H°#7®)2VÑPÏfcOêeÌ·µU²Òu@VÊDQœ$軑Wu’˜è³èõ®{“´Ü4ÒÉ|Û‚Ö!÷ÄŸñE0ÍU’Rò(ºÅƒ”Ì” M2CN0{´6RwÌú½Ä¾t²QføZ„ÐÏP~'¦‘~­-&¡’–Ôx?®KÙälßõkÿgÃá¿}ÈÐ…ŒÎ;¸ƒjÂÂæRÈÉoî°õÈG®þ?ŠC©5endstream
 endobj
-1164 0 obj <<
+1169 0 obj <<
 /Type /Page
-/Contents 1165 0 R
-/Resources 1163 0 R
+/Contents 1170 0 R
+/Resources 1168 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
-/Annots [ 1169 0 R 1170 0 R ]
+/Parent 1150 0 R
 >> endobj
-1169 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [519.8432 216.1999 539.579 228.2596]
-/Subtype /Link
-/A << /S /GoTo /D (lwresd) >>
+1171 0 obj <<
+/D [1169 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1170 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 204.2448 117.8035 216.3044]
-/Subtype /Link
-/A << /S /GoTo /D (lwresd) >>
+326 0 obj <<
+/D [1169 0 R /XYZ 85.0394 429.2635 null]
 >> endobj
-1166 0 obj <<
-/D [1164 0 R /XYZ 85.0394 794.5015 null]
+1172 0 obj <<
+/D [1169 0 R /XYZ 85.0394 399.1571 null]
 >> endobj
-326 0 obj <<
-/D [1164 0 R /XYZ 85.0394 429.0696 null]
+1168 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-1167 0 obj <<
-/D [1164 0 R /XYZ 85.0394 399.3522 null]
+1175 0 obj <<
+/Length 2818      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ]oÛ8ò=¿Âoçk)~Hº>eÛt/‹mº—ft‹…bÓ±PYr-9ÙìáþûÍpHI¶åÄmÓ»C€’#r¾gh1âð'FÚ0“Fé(NÓ\èÑtyÂG·0÷Éðk&aѤ¿êûë“¿¾–ñ(e©‰ÌèzÞÕ0ž$bt={?6,b§€_¾½|}ñÃ/Wg§±__¼½¼ÿÀG3¸ö'œÉ4Ñ£{p&Ò4-O”–L+)¤8ywòaoÖm¤Ÿà,’& `$‡¨Sf$L!¯î”Èq‘Õ
õVÙÚõÔØ–Ó¢ªíŒàyImýi“­OE2ö;oÖÙô£mj?»¨îkÚ^7Y“×M>­‚yµ^¬ò˜¦UQØi>³ÔiyÝ%ŸnŠlM(é»u5AÊÃõ'B°TëÈÝ¥ØxÔ*gMc—«+yân	@¢ÒA’˜Å0hp÷¬ZfpE·l‹n2a2Š´_öç‘-fô•pYeàÌ–`3kWÖÑ V¥7‹¬	=K“á2Å]ÓA²éÂÎ^ $ç‘#Hs‡ù~a=;&Æ5ˆÌmhÈ®]»ÅŽÔ0¼Ïjêà½Ê¬(h8³ãPp/&_Ú¬ÌË[Tsj[äU³°ëÐÉcÏ}[o–ËlÿéXŽðrÃD¢ºo¿Ðd7…e»j&xÊüÅgZ'É1Š&UÂbï(Ú—í
+”š%FëÃ' }pùnرjÒ^jbš*egûR+„f*‰G±ˆ'ö®í›â6!Ö*öâKŒkVn–7ŽWÐw|Œ¥?ÂTÓTÖïk™ÚüÎqÓ-&ÙÚÜ.v”¬uµqÒœ)N;¬­ê¦ã!™ÚºöÒwQîlËnª;ßµdËUa¼¸}ç¥~‘OÔíLJwåzEþÑ]˜VK¿¶ôbë?Ê`fO8•Ž™i<ê³ñëD…U¶>eq¬“Ï@v–¶H±TÄúqi3±+¨/m`ÚÁI%l@Vذ†íôaZØšúd©ç·lË››Zç(hÝä²jì—k»†M€<ãkN²³ïh·IÍS.@q–ªÖ éÉ–Õ}I[Êli	Hô÷˜çæ}òï0îQ¬M´Eÿƒjדç¯Ó‘Ní"	(ùçhrØqXí¸`œÇÑj'ÄIêîýiý,>Rí"#;o"Ïéä(·5
š°rǺÃz÷%7—5Ýâ}F\3)Uú”
+MÚ…["ø/{Dú:ÂïòR='/u3žšäq^ê4‚¸;1åK‹îð8^BÂÒòúwEIMÐ:/§~qvíðµ…´^±,­¨OÀÛõÁa^õ‰ð\¼úîN‹™x‚Uè ÿð„XÚ#]0«š\Ài]‚É×tÇ×ÁT¿i”5CÖG¸„rÑ“IM
+Tàñ¶G3œÏ äÂÌÆÛpìcL%]f…#t‘Kcº$ölî=dœ:•éÞ±¯ˆÆ7Ôf%¶˜ÞeE>#`_èRùm˜±àòlká¦hü²9µEU}ܬæ!÷‡é~úÄ&ëlæ1yÀ,ƒä#s‡úܳWߣ/üŽ ]ÚC®/£–Ç,Û
+6§.Ï{D¡:I}.?ö
ô	«•~Âiž"å¨P‚Az”JIµ*…}Ç]hC[‚¬	Ô	‚PTI=‡j×Ï9Då`-aZmÊÆ3ØÙIãsUü=sì#-wUr–ÚRN –QGhg" w´SFñøm²ü³|³ãM!Yb,'•ñr²=Ò_¨ úá³wÊëñ¦l‹˜ƒÓ$&@,ˆþnE£ƒ8wãôJ“¶ÃÌÅË7?SoÿSìÕ)p¸´õ ŸêìöŸÔÎçÒ¡oð«H0ÃyÕ!¥`}l(~¸Éf…­ŽS"HÞZ%Â>*¶›Òþ±ò&Ç}›[힯êàTª|:Ž?à1Cä
+i˜V(!œ'Á¶U$Pü‰=tn¹K±ç.…Óº°d@ëÁT¤ôg‡¨Ñ!jŸwϕ嫘%èœGv1K–èô		’I!È–d³›c¬ôë,/6ž#ì¦ÚÙIª(’™Dpßèà8\Ús¾Ê(N}uâ˜$iÚ3¤XVûàÛÞ†5­1 7¦œje´ÓYJ®B©i¾µe‘½2¾x…-ëã@ˆX]0bB.½Ye¬òˆÙŸÌÊß™
Ç^DÓÅñÓʵ³ú°L÷„åëäï›ZM)c–¦ò‰Â•4Цœ"y^Îæ °Ÿ)ÕXb¡ü¹o||õDl1t»þ!¶%›QrMUJ˜
m6èU«&+(šè’?ã“¿x<ß>¢‹9Úò+UZux–Ðf¿Ò
+(|¥u°6Då׃Ò£ýÿ±Õ‹RX	‰Ü"¥ÌDŠŠ,‚|‰„$	1&‰Ç¯.ß½;I0—и/ཊ¢ñ¯§)äH‹æ{¨²ÞƒÎ``Š‰a,÷8®BÅ^Årã8Ù«­Ó"ôïβàl‘/‡ë„”ôiMI¶ƒVYµ#sLLzF9¤U	x{¼‡Ä0®TøÏV%V:±·ÈV+[R?
+E&IÊ´<Ö=x™¤“÷¾=—Eì^tÿ/W¤LÆ@°?,U±é?-ï=1G1$$	ä-X„{™øñ'æH)–`æd=sõÃ`ŠŒÏìÍæ–`…½³î©ÉhoaÍXRã^(¼Èo1üñÄ‚vÌ;<µ¯8»ìšF™GØ,ªÚ/ ¦{Mÿ‚¦ÜQüê6MGxu{ëR@˜ j<œ‰T¥M[|¶ãf×{w~u
+Bûëk¼ÊÙÅOŒ›KŠhiC½ÒÞ‚y¸óð¨Aõð.›ª=š¾zûæìâÒC»Ê„öC‹è–&gN¥{z'0;¡ØÁÚIp‘~‡Õ™ÃÑóp8Úç°j9¬†9à_J|L‹}Ç¿`b7$êÚ7ÚƒbW~G^w·»å¯êŽÅ8w|öDH툺ÕuÿåÔµ7všmj^>ý[h?eìÕ†©èBU­2ì÷¿$È縳©+Ò¹wý*üÌ€˜4ôS®nÖµX¸#óvlX8ÿÜ?Äó8MÛŸ	Otœ‹ûµõ‡{×d]ÒËþ$háÏàÃg$%Ôê´§¼õ8ö~NÙ7ÀŠê6¥s
¤É1“I3êí÷‰´ïû lçq@9ÄŒM«r>ð
°â äýß´öoCÞ4‚ÜY$r[ß=E±\ü/'L¡¿%RïiE‘×-'ÈBÚàš|õ»ÝàýªÂŸy8>Ðè…Ÿÿ‚=Œù‚¶ÿûEH¿ÿÀ]nï»ÞïHÁá]¢¿«¶ÙÍqïvpüNiÜþEM?zæ¡ß™Ì+úÁ®Ëæ­v|õoкè)”Ì$öý>FáPH!í<üXmÿèÿ÷Øendstream
+endobj
+1174 0 obj <<
+/Type /Page
+/Contents 1175 0 R
+/Resources 1173 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1150 0 R
+>> endobj
+1176 0 obj <<
+/D [1174 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1177 0 obj <<
+/D [1174 0 R /XYZ 56.6929 732.9125 null]
+>> endobj
+1178 0 obj <<
+/D [1174 0 R /XYZ 56.6929 720.9574 null]
 >> endobj
 330 0 obj <<
-/D [1164 0 R /XYZ 85.0394 269.1889 null]
+/D [1174 0 R /XYZ 56.6929 161.1765 null]
 >> endobj
-1168 0 obj <<
-/D [1164 0 R /XYZ 85.0394 236.5067 null]
+1179 0 obj <<
+/D [1174 0 R /XYZ 56.6929 136.8369 null]
 >> endobj
-1163 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1173 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1173 0 obj <<
-/Length 1372      
+1182 0 obj <<
+/Length 1976      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥XKsÛ6¾ëWèH€|³99‰œ:Ó8­£œ"A¾B€¶œ¶ÿ½J¤M§3
ýöÝÅ’x‰ä/=ú‘-ƒÈ…ÂÞ2.hy'×Þ/°ÙúM`¸ëÍzñêÂ	–Œ|Û_®ÓVQâå:¹±|hÃ3‰€¬·Ÿ®..ß¹>?\k}ùéêز..ÿXiêýõùÇç×g‡¶Þþ~þçzu­—|ƒñæò꞉ôãÐëÕÅêzuõvuv»þ°X­÷¶íÅÈQ†|_ÜÜ¢e"Íþ°@ЉBoù â(²—ÅÂõ蹎ÓÏä‹Ï‹¿ö€ƒÕŽuÒAÛñí	ÚΔ½úŽ\R\gT!·âÁVAÛ^m)“Jp³iˆg0
-#lvqA-h)”‹\‹qõô,ú½e÷$ßÏ‹JÏ‹i¹†QàúGI¶_\j'Ûz{ÜWTįÊ«üÆU™Nˆˆ<è»Ø12>¤Ã¬K¡•geÂb)”›¤-Ý|!ec(¸%p”›}.–FyžÝ!±¢-$˜ë[e[li£èÀªR=×ÙÛÍH¤n†èas†C‹æD°{Úo-ˆÞX%)̬ȈÐϪ6O†Ü¼ÍÍZÏGŒº#±ÐSq¦góªúÖÖzzKÓJ£tÆ¡±Qœ’nQqªü¨‰0Í»“ázD„Ô5-šÀ}ì!S%Àñ¡k;î>ͱ#S!$Uä‚6òóððe’7¤(¤˜ç èŽ.{_"jÿ)ꦮ¡IVoÔàVþÖ¯ÈCš2›œqÃðÏž$Ió?x7ß裦$q»Çšzm6AÍÚ¿¯_p“B'ƒƒ›Ü#ÜôŽ~EÈ.™`UiN£L4ñ…“»©Ô”¢lz8ˆFþ{ž9ÒËŽõ©¦ÜÓŸ~žWšTÁ¤çô#®Š¢×„S£¤J
-õ¢ë’iŒp–?jºåÔ±53…yVçf/íö‰µ<'÷fõGUR>Œ 7ÉĤwp¶gœ]ÕÊ•GÄäÈUO|ºÎ˜A蟦² ëÎ`ŒóB
Å!t=×3Ðk6qP²&"LUQÔ•ˆ‘ŒQ2DõeZ¦OòR!õmhû~¯
-»œþ6	ìA/
-¤—¥ŽmJËÞ±:	Uñ±©ËuT‚nôŽ{(]L.VÞ™œº*`†;«¸8Ô‚~ôS~<äç´‘2K†Ã
KŽ× a
EÕ˜Ú 
-éFép«¬#à4ö‘îÝ!‚]J›ÓE‹N¶¹:3:ú$îlX7‡SP#AŽñ~L⌂”åôt’¶¨g²´P¹#ë‹ùñ#Õk–Ì”.Ï»•Q^ÞÍäÿeÕUÙ=ùHù¦j6eu„¤(wÃð9…=¡ê^QݨJ@wL…ÇYGrÕéè®;GÈOÉ7
-Ø÷–öIwŠò©lD3p—·ôt¥Ó¼åèn-e9ÏZ‘T3<˜	' ΙnÕN…òÔÀ?Ù™¢ÔõÈÇ$!+YAr ›úZ^t†}¯bù3¬(+ÁÒ§A0j
é®ÎYÌÆý¢noäæÇç{5㜛4¶ñXS|ºy²»’7¨«*Ÿá\™ÛBþÛ¥
ØNgdzÉ9-É6Ÿ‘/†]¾Œ²„ˆY4êÅH¶	^væ.kZʤŒ³ª®^(€­,©ê '$Ì0™Ä1­…¬µl’UªjH“<}R;Šä”5ý»z•"O}$q<¨¾lL|Ò@ûîû—? ¾.¹²‰C{úÛˆȦ9” F)e½k?Ó¼ÿÒò\õÿ8Õ+endstream
+xÚ¥Y[Sä¶~çWÌ£§*ÖZ’¯ÉÓf6¤r'BQÆÖ̸âËÄöÀ’sÎ?ÝjÉcÏlQ…Û-©¯_·$_xðÇqÀ<™ø‹(ñYàñ`‘U'Þb
c_N¸™ãÚIîxÖ×'Îd´HXŠpq½ÉŠ™Ç|qß8Ÿ~úø¯ëÓË¥+Ï	ÙÒ
BÏùñüâ3qz|úíâìüËï——‘ï\ŸÿvAìËÓ³ÓËÓ‹O§K—LJõÂHxfÁÙù/§D}¹üøë¯/—·×?Ÿœ^¾ŒýåžDGþ:¹¹õ9¸ýó‰Çd‹GxñO±¨Nü@²À—ÒrÊ“«“G£zé\ü³ Ñ\“Q¹³ÄO¢E$,”BêÞ,ÝÐóœ:oúλê^µ?ÐË-º¸p…d	:ärÎ’ zéÿ~ÀÁg‚/ö
+lrýˆÅ¡ô$*a¤•­ê(‚W}Ú«JÕ=½~Vxž¨‹¾hjâ¤uNÄï]ºVF“ùŠDÀDÂ#­èz£sFN',Ž|ŒÎ!ýÇ¢@*‘ÂÌêö¦IÁ¬©Ñ¶õ®]òØAû‘Ûƒ:MÔi¥)ÏéTû Z3ÜÐ3-;KeF^j$¤ô(‹õ¦TøŸFMSaƒ`À"âSHç/ð®”:„_ <#þ€ x‚@ Áv½ ârŒ;ß/ÐÈ™„çX.†éJe.¡Ã—‹§Ø <òÄw E‡vr²Ø‹Ä"Â0šÅõ0ËO;¶îXÀ F”pDÅ”ªÒ'"î5C:Õ®ì‹m9¨™ÈÁ?á,¡ˆŸŽôìTÔkR9I:Ι&9”ôŽæ?ý†Øy±Â©+ã€T§€‡“|7Y ö¸Õ“š­jûBuLO…²á1ã—/”
$܃4¯‹®Wµ	=öÜ—,’3u#§Ûª¬@ÇuÉÈPø(ŽÍŠ8ižÿ;šh„ë€ó¶MÛw”Oë7©Ðo
+3¿¨A{©ÁVã¸Ä`œ´ô†à‚ŸL7TçNžª
+ÁŒt·iveNtšej‹¹gþµS&G›jÕ‡Ô¯ˆQ7ôDgˆ*ÌÔ} òï°àÃÑœDpÒ`'ï:•H6Q@I£›ñQi6UÑ÷ZvשåÈy,Ê’(,ÝŠµ§ÊôcÛ ¹ˆÀ„q#‰ŒÖÛ®àX/·h?	
†
+õ8W`>ÚMÄÒ¹/ê¼#’BÔø†€ÀgJÄ’;{L oZȱ‰×‚›‰m¦Ñc5UŸ/®ˆÀ¡³Òg~ÀÃi"¶i¦0v2vp“Ðm¡A®ˆ0vm›ºS4	Ö—ôro¦A“éúv;»Œ2¥‹ÂJ5“:½W!U¥u­ýĺ숗ңnÚ*5ÒÉ`@Ú'»´Ï6º“	[‚”ñ}"¡w,¬úVý)V¥cÙ{tJé™]†sµJ¡MÓŠ>RvV…®„Î
zlP9´ÿ±"ªG,YVõiMsTK´´ÎÔUßëµQ•¿
ÿeÛ*m³ÍL	H΄ïÏôZáÇÚ)|B!i9ð5lýDÇqF3ÈÃý¹ç}ªÍ¶09ká~[ø úìC«+‹JW3
+’€…>·û'@Fz‰sÞ“íf{(re¼LéA	RÍŠÊL† (É41yS¥ÐLwÛà#µ5ý²Ýª:·=NÇmèŽeÚfž®j"Ó±6Ž·×H¹à6ìtôžéyKâ„ÏD= à‹ ˜&ødxðB“È¿Ió3ùŽƒAî»2ÇZñûV^d ´3>éöüª€¾W›–*ñzç΢ÚU ÌÍ5éˆÎÀ£Kr0wÈIéušgšŠ ¡QsÄ÷mFj8	«;ê"0f×¥F‰úJ‡`éæIܲiþÜm‰}¯VAãLgÁÂÄAÜmÚJ•ö ù, Ù3—48³'^,÷—4i.iU
+ǽvþšö¥M«
+Ô#%FÐ&BºBôRÇ©:$ Ylïðå–ÞþC<öeÜQ‘#ç¿Ã:}^|YÞÍŸê‰( náœ(s¹½aŒ™±×ßeýW„é•·YþümÖJŸiÆpÐ÷“`t6·Ù/Ëæ‘Hñè‘5Ue-é”1RŸ‰‚Glã³G?•vEùD4n²fÔp†›Iîw÷ÞvejçßMmzäa”]ëÒ1&ìf‹¡|&_þBPØÎm½ÝãÖFÆ$0ÏôPhï~àÛXËf…×RÍuÑýÞ1è˜S$™‡wÓ¦¡|òç)ÜyEZkv¥ú~F$Ü„=$Q8ÝŸ†ÀRbó™ýÖc>áTczôrçN8N>y³«7M×ï{}{q=¯§+±[äã×»"½yѪ¬oZÓ°‘Þ¡
¯X
+}Ä}Ûò‰í:‰îW¼·¿Yu¯u›
I»¡é7­ÞŒâÝ>øÖ§¯‰~–f宊R½Ýƒ|Wmß¹´RÖô¹"ë^/cbú¶Èß©ò½”×ëw®ÿfÓ±mº{)Ä|RÝ]ÓÞÕÍ+,HwýÆ­¿Žá3»|î;6ôcüø<óuÎø7ãÞÿ{­Œc1ÿ™Ozø‘
îIÆ(tÑ—GŸ@íÇðcÓÿÌZ_endstream
 endobj
-1172 0 obj <<
+1181 0 obj <<
 /Type /Page
-/Contents 1173 0 R
-/Resources 1171 0 R
+/Contents 1182 0 R
+/Resources 1180 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
+/Parent 1190 0 R
+/Annots [ 1185 0 R 1186 0 R ]
 >> endobj
-1174 0 obj <<
-/D [1172 0 R /XYZ 56.6929 794.5015 null]
+1185 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [519.8432 670.7162 539.579 682.7759]
+/Subtype /Link
+/A << /S /GoTo /D (lwresd) >>
+>> endobj
+1186 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [84.0431 658.7611 117.8035 670.8207]
+/Subtype /Link
+/A << /S /GoTo /D (lwresd) >>
+>> endobj
+1183 0 obj <<
+/D [1181 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 334 0 obj <<
-/D [1172 0 R /XYZ 56.6929 716.8068 null]
+/D [1181 0 R /XYZ 85.0394 719.9774 null]
 >> endobj
-1175 0 obj <<
-/D [1172 0 R /XYZ 56.6929 691.8907 null]
+1184 0 obj <<
+/D [1181 0 R /XYZ 85.0394 689.5132 null]
 >> endobj
 338 0 obj <<
-/D [1172 0 R /XYZ 56.6929 633.7645 null]
+/D [1181 0 R /XYZ 85.0394 463.7313 null]
 >> endobj
-1176 0 obj <<
-/D [1172 0 R /XYZ 56.6929 603.0741 null]
+1187 0 obj <<
+/D [1181 0 R /XYZ 85.0394 439.0414 null]
 >> endobj
 342 0 obj <<
-/D [1172 0 R /XYZ 56.6929 569.0137 null]
+/D [1181 0 R /XYZ 85.0394 381.4304 null]
 >> endobj
-1177 0 obj <<
-/D [1172 0 R /XYZ 56.6929 541.2283 null]
+1188 0 obj <<
+/D [1181 0 R /XYZ 85.0394 350.9662 null]
 >> endobj
-1171 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
+346 0 obj <<
+/D [1181 0 R /XYZ 85.0394 317.4209 null]
+>> endobj
+1189 0 obj <<
+/D [1181 0 R /XYZ 85.0394 289.8617 null]
 >> endobj
 1180 0 obj <<
-/Length 1187      
+/Font << /F37 751 0 R /F39 868 0 R /F21 662 0 R /F23 686 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1193 0 obj <<
+/Length 1204      
 /Filter /FlateDecode
 >>
 stream
-xÚ½Y[s£6~÷¯à1îŒT]Í>eSg›n¶uݧ4ã! $L¸xvÖ³Ûÿ^a.Ç“L°è;ßùt$)Ø@ú6‡ˆ
-fX‚AŽ07Üp„ŒýîÓ߀ò#Pÿêãlôë%µ…ILcv_ò!²ml̼›³‹ßÏÿœM¦c@8:3áp}¼ºþ-·ˆüqñõúòêÓ?Óó±ÅÎfW_¯sótr9™N®/&c€mŽuR èpyõÇ$ÿõizþåËùt|;û<šÌªXêñbD³@¾nn‘áé°?¤ÂæƳn ˆ… F8bœBÎ(--ÁèïÑ_`íí¦k›~œÚÛÄjPÔÄȆ‚	Ë°¸€&%t£à͘ÝÇɳ“x2QyûGþ(Þú‹¹ãyIa[ÄIZÙ³ÆmÞú? „ùÂü߇²©ÕÒ”ÆPpNêî½¥•:îP2YU4úú±#ŠLç俈£5?šGN(ÀýÜÀ•(\žbÝb×Nq©Bv°rj•4MM@k…4î£Ôªd1¨ÊU_è¨T&e›‡
-œ•lX©q¤dg‹txG:QæÞñƒ†Áˆâ¤†Ú7¢ðûn8'úD/8{öÏÕùÛÖRÍãdÅíýñ~?JåCâ§ëN­Ñw›‡ï³JVoë³E'åß~ôÐ_%'âgÅ©¿n¬@ÙÜ“JÍC'uç¯Òî«Júm)““0ñLà::êÙ¦‰©ûrV›Hw™(?Žb¹ðœth
rPPìIU>
€_ çÉú¤žú¯9Õ	Ô:J¥òÕ`äî½ÿ=ÆÁpr.•+–Þd{U“jfé;æ«Ø÷NEÜgh‡W04‡‹9ûZF œ97[ FÐ(yºÊ­æ}=çk›Š—‰»·ulùV«‹ŠúÉ‹kXh1Ê6¨¿4J«Ú‹ªØ´ µkÕbÝy-ò²vÓ•²Åpá›òÍ·¾ëºý,˜9íuK!j'%¨™ÍX69
& £Âl¥ñ:AºF]zAû5|(uª¼mÏs_3aAb"ÒC³œ‘>uQÝP¬wÍóXöôºãCô>‚tÍž†B¡ó½*@ê‡R—Ýù›hÞɤÃÚµ/Óãø †ï§ÒØ@t¢ÑÀHÝp_FåÖ9fÙÚÓÑ}’]º“f÷M©¸’ÝÝ7úkç¾>ÍçkARU‡é×úûR½BµbëÔKÙ·{9hºöÔ{çîD‰#	ôÏ;‡îЉօ]õ:4•îÔ&Å0y
UõšÜªú.t¬Qß«TÚ-:õ•„CaYfûBrì–é¶Ãâ¿Ã³±#½°Ñ·¡J…„ZâÀÁ'½d­¡íîu®ìµ\$˜óG =®G¥%Cl!ó¤%ÄÌ&åísG‘ßNOκ\ªÜ8òT¥ö‰S tš6Ûš¸U0~Ú´±(¤Lˆ—âì:i¶3pð‘m»[§fâ-7á¨*MN¾wßþS‚éa°mR]©Z»R§È„6VI*‘Ñ]æÕý>õÿ/9v›endstream
+xÚÅXÛnã6}÷WøÑ.@V÷ö)›:iÝlëzŸÒÀ %:&B‰Z’rìnößKYK‰œHŽ³…aH$Å3s‡Ãõ¡¦~úÐv ãþÐõ-hkº=¢6¼Sc—½ø”úWgƒ_/LwèCß1œálYÃò æyúpÞŒhÀ±BÐFç_®/®.¿NÏÆ®5š]}¹ÃÖFWLò·ËéÙçÏgÓ1Ð=[ÿ~öçl2͇œããÕõoyŸ?€N'“éäú|2¾}Lf—:_]33"ß7·Ú0T´?
4húž=|P

ê¾o£e›Ð¶L³ì¡ƒ¿U€µÑÝÔVýt
¦c´	è×ô4èh
+ʵ}蘆¹ðfM…QÊ$1`1À"óþ-sÆç1û·o3ÆÊ,ÐuèÛ¶ÑÀ ˆ¦Iý}ÎIXÜaîÝc@¾¥˜o;Ö“±VàŽ¦¸¿ÓKšŠø—ÅXdÌÅ*•!{ˆû­ !(Á±ýY¬˜@H$‰$GxÐÚäq-0˜DˆŽEÂb`¥T’„bÄ(ÂG°ˆ™$˧A7óÞ$”e„sµ„tÛÁÇAÊ…
+Íþù20LÍr›`½?½T¨8AÂí?9B$–êÈfÉÁ	ÜßÿÝÔ%gÉr‰9Žƒr™þÑl­]ò\ÝF— hÕ½Kfˆ…ÀÀ1ZÐ#öh1}(	‘d ¾Á(Ú<¥óF›Úò=ÕÎé³sóù*Oã;NäöX€h“Ÿ ?‘³àë÷µÙBS%ñ]•²rõÔ‹…"e{1*
+ç””yíGrÐZz¦qH±>1²ä(ËrWŸL„'ÒÉÜMu„ãwÅ™TÅÓ	Ä(ó`½÷ÇêÚbËDœŒü‚ªóoÅ(>]U®-†	ÈΪ¦«YOßåY3Uìžqç¡ó&<½ÅCçtf_ã”;çfÔ¨%Ï	‚¡2«È¼»å†„yn,åÁ³£cÿF«Võ“ëCÓpm]Ë´w¨¿4J«Ú@UŠÝq¡éV«{Šuã5æeífBÛµô¶ëº=ž6´
¿½n)Dí¤„éB˳¬Âë7Ö3or7,Z¦ï´®ÏϤ^оäšq(tª¸mç¹f¾
G3zGgCSµN==Öë¥èÑ;EóZôôXº×—èÿŒž¶«UÓ†Ù}hËE¨VYzóµëþNÚR™ÆóŒêFÕ0k7ª†ë)ÝHáTFͲžy^ÞÏ>wý?Ó`endstream
 endobj
-1179 0 obj <<
+1192 0 obj <<
 /Type /Page
-/Contents 1180 0 R
-/Resources 1178 0 R
+/Contents 1193 0 R
+/Resources 1191 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
+/Parent 1190 0 R
 >> endobj
-1181 0 obj <<
-/D [1179 0 R /XYZ 85.0394 794.5015 null]
+1194 0 obj <<
+/D [1192 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1178 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
+1191 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1185 0 obj <<
-/Length 1261      
+1197 0 obj <<
+/Length 1145      
 /Filter /FlateDecode
 >>
 stream
-xÚ­X[wÚ8~çWøÎY¹¾`cŸ<¥)ɦgKº”>¥9aÐÖ¶\I$!Ûýï;²ÌÅ@RÛ<i>梑dümÃóM?tBcöMϲ=#J;–±€¾›Ž]ŽA›AhÔûIçݵ;0B3ôߘÌ÷°Ó
-Û˜Ä÷]ßtÌ XÝ«»ÑõíÍ×ñeoÐïNnïF=äxV÷úö¯¡¦nÆ—Ÿ>]Ž{È<»{õçåçÉp¬»üãýíèƒæ„úó
-èxx=GWÃÞÃäcg8Ù®e½¶åª…üèÜ?XFËþرL7<ã	–i‡¡c¤¾çš^ßu7œ¤ó¥ó÷p¯·=i?Û2×wN0Ü3``™¾P/4}×qÞ÷oY]œ†2&é|­ÿêͧ8Ž¹nÜçŒË-_5të¢ìo!cš¦&Jö›&˜Ö‡lÛ=ÏÙW6Åψ>Ï9JØ	úB4;[¥3ÂkÊÿÃV<ÃÉž¸¢¦"'Ñi{!bœœ¬¬ì-
b,ñ9òsšÑ@¸¢¼8ú~ÎìQBpF³¢™$ü'
í¿$˜ËÁ²@e…ØG¤­`I…¤‘h‹ YÎ üªÙ¢Âž1M±Œ–Óf(ƒúáâ-@RìÆ6…ªhŹ 1^A+8ÇN¾³÷05wúº	N	’²©CUFfŽ–5…Ò¹­¬ Χ1•ë“¡P;«Rš!Θ
5X	Rlfºµ&bÊø4cµ“1çì‘Æ'1jhÍɲ¾t5	¸Jâˆ#,È!Û.¢0™CÄ/‘¤)i爃6 '4‘|}D¡GSˆÊRŽŠfiaÇ ’2UÔ朥¯ä²­?±ŠôjV1œÅ€“Gº‰Ëå4Ãë4Jòs*W±›¢ç9‰Q¹Ån
-i“´É!Îç²HV¥6ß,ÏÒÔ¥þü,[ð«0Fw£áVÄ®¡5‰3VqÞö¬S_´ê7ØÍÀk	Y`ˆeɺR7Ès”¬bR©4Ê©{ÕªR9j¨»_C]m¸1x–„“ãT.ÓÒ¹€˜fÕ
-»R-†‡ì·Ï¥ƒa $S*´N=
rîKù·J˜êA7¡$“å„£Â7­wÄß…$ÔÑŽ¿hÎ8¤ó.÷$y–?9~RIU{}$Í¡ð°ðF‰F»’XGjÙZþ…eD4ûTàï5_QÍvÚÂÕU	†wªæq|S·„ Ç5CÛêW©Ïœï®ÛØN5W÷pá¸Û·Û‡û½¥Î´¹Ú³„¾¯ã>I!ütóùfYNVT8Í
-¥‰¯/H9—»ww†©Ï´]OO5Y’­B»Av`†a8€ÁjÌFƒc0ׇû·ë•ãÄžr®Û…¼ÐÔ*×ßEÂf*ÿ½[4$Sß~wFJAbMÍÖú«4LMN–´;˜0Åå`U1/ç)özMED{Æó”ÚNÕÛjSu}¿‹ÕgãLÙv±âX[Wõ)NBÔe»·sÍ”KÈ8;è-¨”SlŠ†õ3Cû×–i‡–ý°C¼¬çÚQM8KXô]“OT˜ÔÁªyz¬¦Á5º[^1¨¯½¹ž©žmN¼×XÛ>ûuh÷tyà³}ø©XÅf?R)e›~ÿHóÍ3Ò±êÿ12endstream
+xÚµX]sâ6}çWø1tFª%[þ˜}bS’f§KZJŸh†ÑÚÔ5¶W’ÙÐÿ^ÙÆ`Bl3a°eߣ££{u¯„S‘áhZ¾m¸¾
‰‰ˆl¦±ÒÏîhÿ¨^õ·>Î?ÞY®áCßÁŽ1[Ö°>L~*[üòïöqr÷pÿÇt4tí›ÙÃã¤lžŽïÆÓñäv<È#HÛã=Â+w¿ŒË«ûéèóçÑtø4û4Ïc©™V>oƒù“i„zØŸ&´|ßõ	‘ïcc3°‰‰mYUK4ø}ðÛ°ö´0=§±ŽiÞlè3P‚ÆrÉP|ÃË'q¶ùÂćòæ)±î }Bðeˆ$S×`ð0jG]†èNC)"Îb%;Z
+&™Ø²È$øÊÚ˜£¦y	É·¬g÷ºsN#ð-cbU¬¿=g]ÉçªE\*çY×¾“¶LĆî§ìO“˜åU3 _øÎDyÿo5Ýñnß.&¨Cw²p1„;ô`Û÷¶©k,ûª$“Lì¨Oí
Ã:9r}ha—h$èÚ–]ýP<"Ðw]Ǩµçº•Æó4ûañt‘ß<•w
~ù¢	-mtQ¢=O°uêTSª¾±£×Ì’*y…*éG›Ė럕”F
+t’µ†ö.\}ˆ!m¹¾)-Æ"×tÞÇ0v!²=|Ö2©ƒö5ywL.±ˆ“n'Š/w dÝUKUÄ¡}šÇ}]–ˆê‚RQBÐ`Ý׸ƒmƒ¯ä+ 'Ÿ‡\íκBë Øðˆ$é\ãç95_Ì^$ÑÖKA*’-Ïb´ÚàèÚ^ªžÖJäA@%)=©Z¢-µÇ¯‹½f¿Ð~p=HÁDéýVtÊ£+DƒÅIÒla£W®x’'µ¥H6€fjÝw>^báÕ¬éc45Fȶ¼ò”ªõ"¦•:‚üš¼Y¬¦`CÓTïé÷Kl•H»8~ªýŒ	¡AVQÆ^îmG-íH
“ÇɸÓÞ–…±Y˜ö­uÚ›6çM¯fy‰ÎV4÷ÄÑ®‘7Øse!kdš|RkÙª‘9ê}ž;g³ÌÇÎœŠéßžßÕgpÇJ[o<Ž×°U;^³LzØw+R¹.6yÉüpXwJýúWŒÈendstream
 endobj
-1184 0 obj <<
+1196 0 obj <<
 /Type /Page
-/Contents 1185 0 R
-/Resources 1183 0 R
+/Contents 1197 0 R
+/Resources 1195 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
+/Parent 1190 0 R
 >> endobj
-1186 0 obj <<
-/D [1184 0 R /XYZ 56.6929 794.5015 null]
+1198 0 obj <<
+/D [1196 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-346 0 obj <<
-/D [1184 0 R /XYZ 56.6929 122.4687 null]
+1195 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-1187 0 obj <<
-/D [1184 0 R /XYZ 56.6929 92.1609 null]
+1201 0 obj <<
+/Length 2863      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥]sÛ6òÝ¿Âo•§%J	LŸÒÄIÝ»&w®;77I&GIʼnD*"Û¹»ÿ~»X€")J¶{》Åîb±Ÿùyü\¥,5Âœg&a*æê|¶>‹ÏoaíÍ÷8Q@ŠºX?ßœýøZf熙T¤ç7‹-Íb­ùùÍüý$e‚]…xòòÝÛ×Woþ¸~q‘%“›«wo/"¡âÉë«¿^ÒìÍõ‹ß~{q}q­øäå//þvsyMK©§ñóÕÛW14!z}ùúòúòíËË‹7¿ž]Þ´géž—ÇòåìýÇø|Çþõ,fÒhu~1ãƈóõY¢$S‰”²:ûýìï-ÁΪÛ:ª?3!S1¦@ÓQ ŽY©L–J!ß_DiO¾ììöaUÝÒ׃­?UÛOeEŸ?ÑðO,#ΙQJt÷Ï‹:Ÿ®l”¯n«mÑ,×µ‡Wë¼(iþoZOöý8ø#
ÿ}ó|–Ï–6²%ŠðŒð"³•ÍË¢¼Š²±Û¯ùŠVËÝzj·OeßGžT]|óÒàìS½±³'ës¶*lÙÔÑÆn#w7]1ž|&æOS«u,
+¸âEµ]ç
?Ä*nì}óŸm~sþdzv½i¢4„(óµ}òÁhû¬*›|ÖFÙVÀµ¸ð’…sâlôœR!Ãë+«†&Xµx;o:¦ÛÄ¥ÖšFi¡nœ>k¸¸	¸ÿQ„L%T§qâlLÌdYê¾û,&¼%³Tõ£#Y\‡bÉDLR­	ánY¸S¿I“§u20ŽAmÛ`àˆ”VÁbFð®Ê<½eµ[Íiqê÷¹˜k­dtt§£Jj͹'ãTéx˜
+HÈò³}ˆŽF*Î3¦²ä$ë€sȺ§„`J)Ùãý¥sjO VÅ*“BUl&ópŒbF‹»ÍN'°ë#a.ÉB0Œ‘’´g˜3×»ºégÑ<”pmÀ¯Ó&+¡=MãGrkë„Ѭ6lF÷¨¹¡ÉÆȢ͞âÝb2OºOœC2†{ܩ“Rï‹é+„¡~lcÇ"š1L@ÏîCÚUC;(ä	ª+ä2)Œô@kš.ÉÁè.lñàîž)äã>n3ZD‹DAIßVÇ}•äŽ â²”>ôYo·ùÔ
+WÎHtû°¢'³HʱÞtßµÝäÛ¼-ë¡ÉøS$RpFÚ„¸¸´ciíÜÎB„«"t±+gxqùªhºÀ_w’x—Ù+ËO8½ä‡9œœ¡[:q	H¨0ò´Kt±Ž»D‹å2 ‹äôúrƦãäæ-Ö÷^(ç†ePƒ÷ÙS¨]… œC£-çά•·HïÇ0u¡]e“Üh)Ëœ¢–ßô¨·¶´hCsÚáÚ‰Cs’s¤‰Cqó—ËŽ’Ⱥ­B}Ÿ˜ðtïRg,‹UÿÞé¡;žÌW£_v¶F“ÆïH”e,’î´@Jb­‚[Úû¤ƒ[^”€
Qw½$2vE*Œ ©CÈ>BÀ)–ç¶.öZ….`F¯	·Lo>dÊU“N=Uª
*ù ­C1öšÄ»<×”ªýRï’a2ªë`ãhiéƒÉH!‰-¡2YˆáVÜ3œSA´ñO3¢p.SÂÈPh#ÇøûÓ|%:	—9p¿‹T±Lµ¡	²PÍrhÛ çô,ëöìwE·.Uâ;Š”¾’íRÜW$ ~Æbüæ^—’’9ŽÇÎÄA—i«Š-”BX7£ò–ö><€Ýúvü å#´éë˜}ORã	•!Ägè1éé1ļãK68€}uR‡z–×®L^©‡.šjI?œqZF0‘¦ÁîBÑ×-™¨sÚ'†2Ãwþ©,ÄIœ#ƒãZ|£þHÆè`Èk¯ê%zÜxõïk„¹<,¢Ü]Âd^QìŠÏè»Z­]¥i4ÅDñïmšzHvÍâ¢K×é ]ÇÔjšÑ3âø7óÀš\ÓIüR°Ø€_ô"ÞÉ5‹›#wèÀ«ÅX¡ãh¢Ÿ—™0iMï[VÇju€:Ã=pãÌéVVU>÷@"ô’Ý;HÇ% ¹’Ç®ñG™zVs™2‰ÕÔ)Z¤Czþ?ë	AÞ¢u×[´!oÑ¡ÍÐfï-]`ë*¼Ûk'£×<€ï܈„ÞžÖÓ©<³’¾í}Ñ`#Ò¶QÐÇÊasð¶Ï$ã¿3¡˜
‰¯ì§¤àJ#IuäJÀðAFn%nœý¿ÿßdÿÏ8øø¢õ‘ß™D¦Y¢ˆ
+U•¤‡6íÿ1åPôÿ•mendstream
+endobj
+1200 0 obj <<
+/Type /Page
+/Contents 1201 0 R
+/Resources 1199 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1190 0 R
 >> endobj
-1183 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+1202 0 obj <<
+/D [1200 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+350 0 obj <<
+/D [1200 0 R /XYZ 56.6929 565.0031 null]
+>> endobj
+1203 0 obj <<
+/D [1200 0 R /XYZ 56.6929 534.8164 null]
+>> endobj
+1199 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F21 662 0 R /F23 686 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1190 0 obj <<
-/Length 3581      
-/Filter /FlateDecode
->>
-stream
-xÚµ]sÛ6òÝ¿Âo•§‚‚¦Oiâ´î]Ó\âÎÍMÛ™£%ÊâD"‘Šãûõ·‹H"åÜÝÜx<„ìb±ŸÄ%‡?qi4ãÊ&—™M˜æB_®öüòú~¼g–1Ö·/Þ¨ìÒ2›ÊôòvÍe7F\Þ®_¼úéå»Ûë÷WK©ù"eWKòÅ7o_ÄÒçÕ¯oßÜüøÛû—WY²¸½ùõ-ß_¿¹~ýöÕõÕR-`¼ô3Ìxsó×kjýøþå/¿¼|õçíÏ×·ÝZâõ
-®p!Ÿ.~ÿ“_®aÙ?_p¦¬Ñ—ðƒ3a­¼Ü_$Z1( »‹ë&ŒzÝÐ)ùie˜62› TSÔ–¥
-ºP€ëb“w-­ê±Üí¨uWÐ÷Økv²Jθ†
ȤeR$Éô®z¤eŒEL‰)¦–cª<«¶><)©™µZ'ÝaMÐŽ"g6KÓ!ñÛ-¬]I½x¬Ëêž~KWÂ,€­+±@δÞз
cšâð¹8 Ö &©dñ²ò¨U]-ó»¦Þ[û·Û*ß
þLe5škUWp.-kß‹]r¹\J²ã),X0«µtìÓª$q{¨µhóEE ¼¡/­eó~.â–å›ÛÒ£õ‹Æ!ܪ¬ð2BŒ >HhW¯§Ðµ©ÔØ×MK-/‡\Û‡£‡Ó¢šðCó‚Ý;­`£
ãa©dü(¼5;+Bì-Ø
8
-°‡	s
-PhØ\~i‘Øš\¤2rq³!„|
-o0YU·ÔhŠU‰«)ÖßÄpÚMìê´ir.P°vÀ	³!@[î?'¡RÅRÎ3¿<6%Pí,õß|G“HÅjü@eHã1fK%r±qzOÛrµ¥¦$£M…~R0±hÚüТëXj£ƒºL±Èü|Ûú¸[Sç—WÔ×®†Wæ4ëªR¦®íyWcÍ»ª©~,ž–óî*]<9O¾Ãš ?pWØË…2ð÷­3nÁÅlnO.‹ÛÅú	¤\Qçña;Çm絡)VGÚ‚ÿ«®Šæ;òF´½o€·E7¦éPŽw»@/¯Ö^å8n‘íÕ¡üLìH‹"¤Fï¤éÕ:î<æ¦>VhX*±‹rCxkh/ÏRÕj»u:#{ЀÅq"of|]’…x`G
$4PeŒžûcÓã)2å¾]$À_gUWÛ”¥I–WÝk^u;¬Î}.¿ äÆz«2ÆSð8giwX§Ä“8q‰d<P¿¥(£À¹<ø ¡²ECùm1åÙ,kÈt¼k»ii¹˜S¹ˆ
-_ʱÏ]+~݆mž<Ðí3 …¸<ÄÅnâ%¬Û•J?;éˆï%x^–
-)Ƕà<ìý!ßcàœáÆ)‰éòX³°MR†~7ÅC~ÈÛ)ŽD’1¥´øŽ4¤‹ü3BT\xƒoUëbý=² eë¡›cµÂËweû{=–”Râ´žg/@H[8¬^‰ÓXNƧPs&¥„ÕϘD„uÆ$–‹„Î×û¼¬N}¹bB?C; MÐxòÄ0^vHœ
HÊ3àÚùÃäEµvJ­½>ê ®¸;>…„¦sì:[ä.D=Ùæä³ü`XžG½/ª5hM#Ëv;¡LJ–õ¾ýËõ?&ÔHfL€EvɈ#àã.¶]™Œe<±Cí_íJòÇ6óYé§cÑ ŽA½CCG"Â.S…¯JèÒ{øA"‡îuÑ”½\¡Ç»hQÖkÃþÛ'™vY¥‡àPµ¥ZÍ€l°h@&çlÄih@Ëmsªû®Á6CETèðÅ´\…®?¤L&JÉSp™ô»9¦A‰sãOp<í„À±æÒÒ†	GøÛót“&	ª32¿‰T³JªˆY­`ËP³~ñËw]iü»‚T>R]
-P?bRþDm/KEÁ¿sk ËÔ†Úã©æÏ(¼mñ…ëòé„Á9¦ÂءطÄÅMÉ´áÉ-Ç%( ÆŸ²ÁÆaŠª8tЫ¼qi¢ôB=5ÑÜ›Pa
Ĉ“ú3’É4
Ñ*$}qÊDT–¾i<%¶‘ÀlÄHÒ‚80"¤ùxz9oÑÜ&3¨ä,Ý€sJWfOj@Ø…
-	Îå5e¿.é\þTìv{—aZC>Q(BЇ´at(vº0
°„$gÖPËE‡C΢	ԨȵQÀW°ö0ЧÎM[#u¨ÀëÍT‚ãgb¾"&™>$áÄ$5Ó—¬Žåèu
-ünç[N&г«óµ‡„)B­ãTke
B½¨ ÕÕÐäø•f©•fèø»ÚU9¨t§úýáæ3PsÝøaó¦êÀX”mý‡·íæ>ooÜ‚“Ež7¸ëŒÅ,™òÕ¶Xö§`ÃÓÁŒ¥ƒÓ§ƒk‚üðtP²TòlHŸÊ·Iþë"¾ä-Ý&ÕÕn°7¯k/µºíNVg¥§29|òÌiEŒ5/½˹âãþaVx–™ôÚi‚öPt	3‰§üV¥ƒËg3ðmC·ç/ö®
-¸Šf4h·ùh»×ô}¤$ZeÕ´‡+³8®(çÖþÛÔDj&^Bœ4ýul·‡j½òf	\­ïfBœNe”£­nFú0::ŒÍppF_6áßùa³¸èo0±Lñ,½T)Tˆ˜AÅí„dÖ3}7±ìf\ÆSÒÍÍà´2L¢ä:´ ‹lR`€n%âÃÍI+Q)ÏYI„uÆJ–KuŠ}Óæm	æ¼jæÌ¢qj­=ÏE‡5ÁÆÀ`RËR#ä2cbƒ1–Æ„
-ÃØÞ`b`g0|<”­«‹£ƒ<€›ü> wöóÔžXE¿‹/e‹ŒL»
-Fƒ[Tz”&žœõÁ$¢0}Ù„l¶Eˆ}õh|X%yWúWá(ΰÄÉO…\Ô]ÂB,ÓòÑÚ.vªó·ô\ÙØêÜLX‘̘.ϥ믬êÀÁnœœÀ¶AÜ›µS	F ²grïiÞJ’«”Ëõœi‚"Håà9ÂÒ)åaYªH”o§
-)Že}Èê㘙ŠcYo–xVÙúãK
-·*¸yN3±LËè^
-;èBe£Ð¡RÞ“ëïçèpõT‰1»CÞöE(©Ak´Ò}Î/Çêi:ìÀó,†;É}ê­U¼mî7eQI¨RâªÄì#=N»Í[ê{Ì+ß"õT WgÖ€Õ”÷ØÍ°Û++Þ|‚Û«*ÌÓü1Œgw`>?6ÙðB7•| !?ÁIm~<³á¼l°Xƒ;VMÖÀÀ×aкl°ihˆ/8\‡
Ê—ÓçÝÍkjÄ„ ¨ÏI÷ÿ’ù’'‹®m#¤µÿºÚPÍtàZâYdÂGY"é£J‰‰ÉT1a]àMLñyCCÈÛ¦ãG1ÊÊpq?JÕŒ&‚¤>zˆ5qŽ¨¢D*"â©©ñqö
ߤ3¯pY·ÝõeÊQG©¾¼È½IÕ›3¥K86ZÍêPÞEQb¤±R|îa!ŸãJ üU¤ÎÃý%5ÞGºÛá/㧺{:/òÿ¡XÑ-<=¤”L€ÜÍɤÃ:•Ù€§+ê°žáät¶³Î|ŒTB÷Ò¼ëH.G«é>kà,¸bF›ô,É锦WChD½§0‹ß^¿{qûêýp¬@2•ãþŽœA(¸‰<Vî®pàáÂ@^o‹ò³Ïɺ|Ƹ츃¾~û†ú»­WõÎÓ:äÝ©ü
-s5“tŠ/ÀS1tQ$ɺçZ¹w²;+ͺ'ý#¼l-«ÝS÷JÀ_qc?Qî'ð¾›NW¿§‡ù)B¸yÐYè%yb_í:¤‡AÄçÔ#žþX¢¥Ýã.ë‹âýþX•«<¼äñ·"±ñßïê»ÜO	¢gso†!äâCß	Uƒ/óÿù=qÿØŸ‰3g™>
+stream
+xÚ¥ZKsÛ8¾ûW¨æ²rÕˆÀXsòÄNÖ3‰“µ­š™-Âk$RáÃŽvkÿûv£)QÎa“J6@£ñõ”œ	ø+g:D˜E³4‹‚XÈx¶Üœ‰Ùô½?“̳pL‹!×Ï÷goÞ…é,²D%³ûÇÁ\:ZËÙ}ñûüíß/>ß_Ýž/T,æIp¾ˆ1ÿùúæ’(=Þ~ºywýþËíÅyÍï¯?ÝùöêÝÕíÕÍÛ«ó…Ô±„ñŠg81àÝõ‡+j½¿½øøñâöüÏû_ήîý^†û•"Ä|=ûýO1+`Û¿œ‰ Ìt<{È,S³ÍY‡A…¡£¬ÏîÎþá'ôÚ¡Sú‹CÄZ¥
+Tá@R@;JfiœI]¨Àë
+6”yélž1‘òª Ê:ïLC´nU¶D|)×k¢æ1ïב»uG—
WÖ*ÐH®YåS³i»¼k‰$©ƒD'ŠÙáL"•MIÈ2)_·5ÑʪkÎ¥ž×E¿4<·Ê&ˆ£ˆ')È5[DB‰ŠâÙBÊ ‹ceûQIJíÊ唜‘Ò8䙺š ±¬k"t+C—¦ìÊê)8B‰Ð©Lø—M[	3-†\tÈrÊJŠ¶-‹ÅB¨µ9\ZJ¨0J__ÛsM,>B˜
+%“ñâ÷¸ý0LçÛ¼[áÑãh瑨ëfm§'¶¦yFìaÕgZb(»–'%U/MË„ëKæ¨Ð–S5¿æ…ªºã9·fYâj¦ø(‰Ø/ç¡Œ/e;åŒ(Ô™äCÃØQ€8“;䜞óæMÓWoïp’B‰ÔÙë¡Ð¤3Àâü3nN;*ŠæÖÖ·¦ ÖÃŽzXOM¾ažn•wÔzÉ«Ž¸,RÒšŠÇ·åS&4îîœ͹ž÷UÐ¥Ýz™G–BG«´?4pÖtÅü5þ¸ã	
4š¤YÂ`ÕNVÕ•™Ð["ˆØ
*Ê6X›–†àÐa#±`CBNÒªÞcζ•JÝ’4jØë\M:p€cg*ž¸*X7©”•Œt“W;<Øhn¾¡3=Ø7Ü4BžI†žö ͦ~ä€S9¿©;î³gz¬H%D¦¡óG'§â UÒ1!”pÊœ™ÝKm—¶¦!Õ8Žu‚gm4E	ì­“Ð4KV4[(•†Ÿ‘‰ØéÑ7šj¹®	Ï1:qzuÿ°fïùµ´'g¦A&òuç9ä:í<=ŠØ˜eß´pf§\ha¼*çšaäbˆôáäâxàBñÍ¢žÝ¹œ;ÙØp{/Ší¢ßlÛƒþ¯=Ì`šÒøë4 •»£ÄнVÝzG$zgéeFÁ\¥[BYµõ'Ëζœ?[~¾”ÝjÒ_¤Œç1›ªX¿?¨)wqF/+…8ЃpF±{Ÿä <§"ƒcðŠ™%9¯É¤ÁïÁ1{™N;ΕJè×=ä:
lÏ5NmN"[BÀÁ½*‚çša„ì(	2Äc!(;?1ÈÐ3bÐQ$øìÀú?nøì8óí»³AÖF#jzZlZö™
+~¶5±öítàZ€‰ŠH$Œ„Ç0!!&³FHÒ“=¨QÃŃŠáÕB¯bæk©oàX¢’Ý@W7»s)¥Û.9ÿD ò#›œMª~<0¸½#”ðX#l—Mù0ˆˆU1L/d6‹!K)l%DÍÓŒ·ìzþÅpÀ1vçEùï`Çe]¹âSöJ}(TZpÞPž
—8²"ÏõIŽg{Ýy€†~Çy¸^qŽË¦iuÓù:ÖÉë«z®‰eÇ™± fÌÆ벿Ðó/—ŸßÜ¿ýL/VhA¾ÒoÈ%¸*{?¡1'l‰óKbôšò™33ŸÕh›#{êåÍ
å<»«—õš×jòG¤!l—˜±éÈÃJ$ØÄ“”ñ­çPìcé¡`$‘Òy½uÓsGÛäeEËÈA²Þ6öD36åü	ÞiSà†ÞïÔõ’>±¯¶i%BVP99í¾ÄØóqŠ<¨lÀ¹ÏâöUòfÓWå2ïÌ Ú]ÀÓº~ÈyJPýIG€P•fß©›‡\§A/Ô›EažËåqt„Ó’2L^_ÞsM¬?Îût ²(`Ñ.3̉z¹%¿£»Ä§qw
ÛP¿ø|`Fª-Åqø9‡e^\N†€Ãç¶)7yS®™\S¸Y-â°twõ–?
Úa}XoM“#˜[[9¨yÛ/Wh<–ž÷¿^ýF-0§ªÍ­{EÐg™³H;hå’^úm‘SY$8g¶˜5Ìüo(‚Z4Ç8c£²œ[žØ²c¨]LÚÆ_ä’. J¿ÐÆb(Ö‰H— EÒû#©rCo/«ÒnÙ4Cº
+//èmxAcÁ‰]¾dAÜ3w"ನÑPT<\âk_6äÂÖmYm8…ƒÍKnQÒ¤ %ËLÁÚ+<=ì}À"±šo«¼o;[½†)m¹É5¤G¹vêÊàÝûFà{Î×=¯4™ì„Q
+u¥ŽÝ…œÏ²Û©dGQär/>=B¬Œƒ,:¼üCÕÁú 3:WeNТ ` Bt?…nL¡akoÛ²þó¥l½ÙÉ\L8,ÝÆ:å$;ò;ÛHEÇ®˜ñVëò¿l
McÃÑ#¤(ô^ôËæó²o³’ä°F+»Ò9Þe]á)=õ„,"®ëœs0—¿íã‰ÀÄ·éú-{órã‚@UŒÓ9°S¾*à7}Û?´ {›`ÚÊÎ2ᢧëÿï¾£ð;A`Èu:x.›é4æÑ4)OˆÄ£( 03Ô¯¯ï¹&G/ÊåXk;ZšLæR‡óuÙR=
lÝnk¨…¿ ›éþ0˜uèoµßj…s³Á[­Â÷w9vN ë‰¬ˆö®F«½,yQ”îN¬
+¬/„‘CW;L¡]
»Óì†h·àÙï÷§*óqâò
6ÖG‡Q{#gH[¶âˆÅͧ›+TÏi˜A_¢ {}f®W`測Í×u¿6OÖÎ5¦x‡`Ku§©~]
+Ï5!ÆlJ	¼´ÉqŽYCƒu &‹5¸sðíƒai6TúÝÆ\‡0ÜKžäþÃeKì¨â®ÞymžÍš‡×˜Ó¶=5û
+AÁªîOi$2<À“ñ‡Idî0µÂÍ|[®û‚Ïm&ðA0ÃK;ßåÕÿˆ¿Ò¸Òá¦ù–xtoà®n7yaÆ=œ»ìY ¹y1ÞõÙ¾ Þ+Ò]¯¹Ç§2i8¿ãÔi/äDúB«ª±õàv”lGa²E©í{[êÈé´f8ÈXöšÈÇg®Äð{å8d°ªä»e#„¿8}Aºë³›˜ÇUgØ~Ø
¤Ô,åÄ>÷‚`ƒÑðn/YøS)’ò¾[ÕMÙíˆÓgøBE“p†”ý&ÞÕnOV>ÁÔÏcÐÍTKã˜ðÔí<+&9›±sµS(Ô‡*ãJ{kŸTÅó;]ëxírÀ<ð§ÙÞ®y8¹iM1Ge£5¹öl¿œvJâhZvÓz즳#7­¾ç¦¹º„÷Ò]úä6ý¤Š¤eÚre–µž¼Çûo ·¿jb'O®®\—àuºÝ8|„Sçj¬²®éÙ§îSÕ¡]9IØj¼ãÄÃ&ÇN»Ç…ˆR÷»rS®óƺÿ(r¢`$.ñÃIƒ”%æ,ØÈ›Òq

ÞÌfká…p,…‡I~²Æö‘Ûù:zÈp0„1εðçÕ¨{”ƒL(‡]æH)\Ÿˆšûû(_ÜüÆ×ÇA•>x«|F½á¥’*:ôˆ¿Rccyñ…R«%<1
+ÿP*º¼Âÿänh~8ÏÔüŸž¨-ñËþÏkR}OÜ¿Ü]}ùˆ-*¸¼'Œ¦6»¤–£TœÅè“oJÁÄõ0‡P;&BŠ}˜0bþ;]”Z‰ôà+ÔT5aù˜f°
+óÃOÜ\?ûfßúæ¦oM¿q¯ÿý‰Ë»ñÒ$"uNý*.Œü)ÛDÍÿXøÿûsûŸ‚t¡ÖêÄw‘€ìYê„BÉ£ôPrÿÓºcÑÿ_¸[ÿendstream
 endobj
-1189 0 obj <<
+1205 0 obj <<
 /Type /Page
-/Contents 1190 0 R
-/Resources 1188 0 R
+/Contents 1206 0 R
+/Resources 1204 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
-/Annots [ 1192 0 R ]
+/Parent 1190 0 R
+/Annots [ 1208 0 R ]
 >> endobj
-1192 0 obj <<
+1208 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [250.9056 118.4935 324.559 127.9031]
+/Rect [250.9056 569.9548 324.559 579.3644]
 /Subtype /Link
 /A << /S /GoTo /D (statsfile) >>
 >> endobj
-1191 0 obj <<
-/D [1189 0 R /XYZ 85.0394 794.5015 null]
+1207 0 obj <<
+/D [1205 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1188 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F47 879 0 R >>
+1204 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1196 0 obj <<
-/Length 3429      
+1212 0 obj <<
+/Length 3488      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥]sÛ6òÝ¿BÓ'y&B	 Áé“›8½ôçÎvîcÚ>Ð$dqB‘ªHÙñÝÜ¿]ì‚"%JÎÍ%3æX‹Å~¯ä,€ÿr¦c§a:KR%t õ,__³G˜ûéB2ÎÂ#-†X?Þ_|ÿ>Jf©Hã0žÝ/k#g÷ůóX„âVæo?ݼÿðÓçÛ«ËDÍï?|º¹\„:˜¿ÿðË5A?Ý^}üxu{¹FËùÛ?]ýåþú–¦b^ãÇ7ïh$¥Ç‰Eo¯ß_ß^ß¼½¾üýþç‹ëûþ,ÃóÊ ÂƒüqñëïÁ¬€cÿ|ˆ(5zö/iÎÖJGB«(ò#ÕÅÝÅ_û³îÓ)þ)m„UœŒD¤âpšËR$RR¢¤ZG=—C9Åe…\ÞfuѬ…}*s{xf*‘ĉœ
>ھǚØ?ì/ÃT$ʨ1÷+÷–ó¶Ùm/¥™çüÞ,éiëÎ7›èz>0⮵xŒ~M»}²[¼aƒ®+[zn¶å:Û–×Ö~Õe³%àÝÍÝÝõ[dÜŒRl)Eª5‰l³±Û¬+›º}s¹ˆd8owù
-  ˜g-=ïÿ|ýO‚:`}›å‰Kçp4U¼ÔÙºÌée·)²ÎŒ<Ág[>Ö–‘ÿÕÔ¶…ã)3KÞ§ÙðÂ}córá<Å¡£ø· -bIE\C€…àt€çÇqD®,ŒHz_+×ôö¼*Ýaá#¼!ró6+èmx‘RJ¼0	óK¿}É„øgæIÀm‘£Q0`ñp‹?v嶬÷™8òsYUÀï.6+z^Ù!ILÀ!Ú•àÞÎ>\ʹõ¨öë*Ûµ-à QBAìºéplw.Þàˆö«K`ñ2ÛUŒ÷”U;Þ	Ž$ƒyLŠ©D(4;À÷p?ß“ÞòHËb#Œ€¯×ÝI¬Ô"UJEYûÏè^C•zn´!ö¶0ý†FœŒ"PƒØÔÀ©¶Ïek‘Aê4šèZŸ04ÂD¡§ìÈî#	„ÖŠ‘I˜i·.û‚‹ ]"uK›wô^ìH1CÅ‘‰ã±”uÙ•YE6?oj¼¥ÇI
V
Ê-BYGO6&wÙ¶Ûmè¥+×–QkþEØ=ë†xÈ~ùv÷Ðï±ôNH¸)èò¡ëaûën0QçÀë´è±›­]ÚíÖ‹G”Ä#/Â]€¹>»5AÀØ$BGq<¦ÀéŽ	U&õ
-i¢yU¢®Z÷²±¡„_š)º‚,Ì0Êêã¼]—]¿Òƒ]òñ"(Ì4õHZ	ƒeÍÛzZ²¢`{
-fW¤:¿¡x¡yéjm¾—*4àNPè°}
-@»ËæIäqno-¢EfF“?Ä'+ëÒËhVóÒÌ-8nÝ|º¹Föœ³‚Ž8x%Öb3åt¾i:ÐøÊ>:=[4uõr$l !XýóTôXdŒ„MkÊ0Óq‰Qî$2¤‘‘s¶½faÈíÚi&Ž;ŸkðÆ„»Á’¹ÿå]KèÈâ®ÙÐpeŸlÅŸ7묬[öž†m~AÎ
-nÓÉS‰XFòä|<]ásÙ­üý²Lm†âf¿æÕ®àûF½ÏÄ©[ð¦é¥m¼ñ¢3¸•{ÊÙžÞ”U/{±²â‘Åö·0Tï®ñïžð—Ë4œÿí`ðóþ=08ôñóÝõçõ’zàáÄ:mÈ{¬R­QìàÝöØšëThXæ<=Ö#k+¡“D	¹C«±D
-“ùª´[òš9€-
r­	A$— ÇÃL“›Éx	Š`îhÞ‡^J¨¤†ïd&ðVôaèlaB‘&f|õ ºÎ)3t!È_Âx±SÁ‚L yÍÀH‘ü×XpÔN¡IA¢¡,Ïí¦c¸nŸí¶¥—rIOXÉ£úãÊ4_PŽ=I~¨#aÒÔ[к™¢ŸypŠ~6®{ãŠðÀ¸râË ŽÆVƒ"ÔíTQ¬D%¾4¢’,CF5¸K‡èxN×aðÁO:Ž¹+Q’lÄ…ŽˆØ;1€IÂÍ/³«Ëd¾êÐ.lB/ÐܳPcc¤g!ë£P)LÜþ-xÑAâë…¬!ÃX1ïÊ'+&¶ZÈ,ˆQ	j.Ȧ‰ú^ÆÂp}ä9?6Me}úù‰S¯æ*Tˆ‚è•äfˆuÚ\õXNC5&`RkR‘D*ýß”’XVš(0>b8`!"T‰ä®®¦ÖŇô(Þ'÷‘[ŽŽaç“p³†µ›¼ûôñêÃÍÐóQ-ªe퓽ÓgjúÂ(ïÆáŽabÒo²Ä&E	ÜJ¿ð\%fT%g$™Ö—ê_0¿¯Ó—ÈGl—`•£ão7V?xn;·›øgF|•Õ–¶Ü7:p†[‰GhÌÕËtþÒìx}I1wNUiXè	Ë}ÄŸò„øMUô!„/Ï,»g^Ž+'´¦‡'ŒØ­Çû c_$œàve
èø·‹ëÉ°s–4~%½ ÖräŒE߃^4õÂ~-»ãô2*IÕYz¤c
-ÆõWç0#¨§¶/´qîò-¹ûèXÍSûV³!”ë†@[s)Û+›!ÑÐÜet·j×
…!o´Ù—vÜ8@¸Š¤¨¤€‡áXÙÒÃD{P^ž§/¿y3á*Êvd­¿s„ŸnSHAP%¯ˆÂëŒ,x,ª¿d¤"Ûš0‚äü¶ibÛ¡¤R÷äxÛSÁ]Ü7³Î)N2ŽdÐG)³3Ø÷•Ü ·L]½(p%"šð`n%ãÚa|÷QÞÐì`¹q²å?f\l:/9PD3L–­õKÓ02õ­°k”'bpTh,b|#‹HëyUÖ_ÐW˜°oÃ(f„p±“†ü’vÜ=®:šðßc1Ÿ@¢ëëqµ¿ßðXÖà\ü8ƒÎ3~Ac€Fý~¸ß‡)—ÀãbEÉmCbVÝMe¬ûÖ¢ïEç>ìû̾ËMÜu#®ÑâÐ].5öslHs–:l³ï¿Ã¦ÓPç<Ð6×Õ[°'ÎO'¬\MÀwÌkÚ-›ÊK[ð­Î„sÜfÑ÷zm܆YBOR/Ä+›m»Ï…_i*ú„¼A÷-h6,á|ÕlìrG>^ûf­ö}5G9œÓY9p®L{VµlDÛÝÆ7¦[ëãÔ@¼‘Tu÷Í
ßxëX_øÑ×çR7A	ù@_ëËM$Qq$’Ä|{XÂIf˜h$£pܵ™î¬ËTÄøS”àÀHì…¨T¶ÔSÃqšb1¹Lžãš:8'—¦'¢T©Ú8ò›<•öy‚’Pô?g`s|(õ‘‰» ‰…6õ’£Zûº'O«¯ùyÖòÉ\`”bU——^CÈTì"…9Øråw(@UóÐË¿ÿtA%*ù†ûˆb3¾qêWg‘øS±	×ôôÿ"mÿs=•ˆÈ˜Eë…2°…ä«ø8À-ŠŽHÿ/¾v=endstream
+xÚÍÛvÛÆñ]_ÁGêÝö†Ó'Å–S¥±ÜÚê%'ÉD‚"j`ЊúõٙŅ)9MO}ø€ÁîììììÜA9ð“m"“ÆéĦ*ÒBêÉ|s!&0÷í…dœY@šõ±¾¹»øÃÛÄNÒ(5±™Ü-{´\$œ““»ÅSÅÑ%PÓ×ïoßÞ|û·W—VMïnÞß^Îb-¦oo¾¿&èÛWïÞ]}¸œI§åôõŸ®þrwý¦Óøææö
¤ô8AôÃõÛë×·¯¯/¾ûîâú®=Kÿ¼R$x_.~üYLpìï.D”¤NOáED2MãÉæBé$Ò*IÂÈúâãÅ_[‚½Y¿tL~J»HÇÊ€$ãȉx\È2²RŽUxL;!ÇrLÈ…¼(êì~ϲõCµ+šÕ¦><·Tq¤ŒÐ“>õ#Z¬&’RÙH)é†\¼!.àŒš6+$Óz›Ï‹Ÿ„ˆóͼ¹ýøñú5MöösYÃÏrA÷ùºz|Žb™mrP´æÝ~Ý3<ýdftäð=“2JµŽ=“[`f¤*M$Ü­8#Î8ÅÚ…%u“5ù&/›š0Û]J7Íùe
‡ÈÈ¢Ó÷åú‰ÆéDlªº!¨=ۜދõš û@l»]HìP³Yà:"§:¯d}¬ÓJÖby©”uÏgëªú”ÕÅ"?R±DEV¤î<-ÖKRàAÊ!ÿXå%ˆAÅÓ:o^\¤ÒQ*€8Éòá5ŠHÅ6\ãÖ_[õpkÚ‡î€ÏÙºXdMµ£×GЂ2æ([7ù®5ÀW9ÝäͪZ0‘ª£ÁÊ)‚åP9´Z'h$¾þ`R¥y埋š½¥è`0ÐT[ª%cÐãßUé#AzÝ\—¢&‚DÈìè,°[µ¨6YÁ„†¶ËïŸüùD8E¶ÝtºÈómÊ~|sàG…jíé7g!ÊH“ò‚W@ßÇaE·cYí6ÙšàÖõßgQ•4·ÊjšX爆ZŸò'šÛ—ÍîÒM÷u“/xGD¢Md$Œ>¸Ò€?ËÊù
+ešËVã­GÀªsdaÔÿ\å„ä·ÇttŒ3ByóýeOÿNcC…9µ%Ê6çÙý¶¿µëb¤bÉφžsÐöÁýÒ)Y˜ùãRÊ)èŸrrz³¤až·ÏqmZºuï°¶U[„ZÔŦXg»õ“ÊΞñLXÿñ´œU^MyZ‹Áwv©ÆpEìüAÉ7d‚L¿ç¾;ý9íÁ%f±}ƃ÷°Îxð€Õ3ª
ªã}>x¿;vã:49ÏF‹5ÂÇÀÈ­ÕCF>¢×X¢MÅvº*ò…Ë9€5
>®ŠùŠ@d— /Cxzׄ3“(«´ã %¥¿•˜Í `¼óˆÙÅQjÝPÁAu½R®w¸’¥X±zÊDzi£4SwNÊyÅ,G<`l#«µc\´õÅÅ$‰¬“’±8?pbZQZP6Ÿç[ˆMá õc¾«iŸ°@m…¸ÐÐ^…?t,’bYà²;4îøÐ~ÓÖ#;Ñydç=ò¥œ†™ÈÐcÈÉ#$yle8òqZSŽU”4µ¤0m¦E9PDl%¢fò‰ž¤¥jÂMïV<>s@¥0É
+Ú#³/ùñd#שt›4;ïfè8媱újåZíÆY9£Õå?Z€}Ò>J?Ýœ7Åç<Ùj&m
+)°±pWI$e¯àÃtÊ8:ôMU­sŸ"±÷[¼½ú”ãÓp剌õyÇ×Ç:íøZ,/ö}³š•¿ò¥:¼Ø`&&Ïoßbì?Ì[e¤x…'܇MTú÷á:KJbÉ–„úɹÇq+<ÄÕÕ](HMëDîCt/Bœ]CÈdØG7ܬ*iàöŸoÞ¿»º¹íÇÐzך×Ì`þ9/‡é‡bÔvŸó]»%NPDÆÖÙ¡¥“Ow)jà¬û‰ßà*±(O‘‘fÎ gKu˜`.3¨ñÅñb—àß-T/÷`Òö6	ÏŒóUV>ä´å’*ˆ
Íp¿ ç5>Â÷§jÏ4Zç/ûš\1=±|R(™”pCWR­m2µcµl™Ü+¢]°Â̸æ,óÃ̤K_švbDjØúq.ùu=™à(
NGªgú }¬ÓvÞby—c˜C<ŸUå,ÿµhŽ‹Tt·©:ÏC‹5ÂÄ°âû%nÈÅÝ*$‚Õ–£Vò¾¾Ðî8Ü@ÁS]WË
+jwE`^rOfç«|þ‰Þ(ÆáÝæ›j÷Dèàk?…Í™:ŠÁ·$mD½qBÆC•âžäI›õAŸ¢J¡|wƒœÂÛ|lm×yÆëÓú \d¬|NzXgô!`Q#'[Cis°­3’
+{~Û€4²m_RŸÃmG½=Ì#ôeÉ¢ìíeÊQ!Z'êé¦2ßx¾×DX÷‡±š†|þ'Bþ‡#óáEåu+,fÜ$LKŸ0ùsòou MÃ(h4¹E¾A½ $Ft¿ÑÌ­§ë¢ü„ÃÅ!ÝÇQ¬0=àëT
Ií¸X54Öß?ÑX\"
+·Íp
Dˆ‡¢„BœÎ-ûÞBbQB&×ÀÆ‹S¾!€Ä…'BðÂ*›±
+8gœ9^D"¦’\X0äSx’týÈÓ–!*è%œ¿*ç°ÇŽ«^É-žá:Ìcp
€Jup±ƒPÁO¯¬|i¢ëÁݲ±,µ†ëcA<Åmv˜¿¢×ÊoˆPâÓQŠ}­V‰Wy¶kîA=gÒXšDN«`ìXâéªÚæË=E~x]ìwìûBWÎ3ÄÀÎ齄Xæ=[×ìDëývË­ÎCÖ‘:È:ìA{¸®6Á×-œX[¶Ìöákï&¨Àïi#·|ï.;¡vÁHye ¾³îåÉ	­±ÕN&èÑ9S(ív§‘Q.m»ÝÁIVšqäTJƒÖ÷§Ž³	t$bòõ<‡•ø ÇÞk„í ‚&a“ÏEþ8ÂI¬#)œî)Èè¡\Òæ'þ‚FAc„=jÚ¿¢{
+¼†î°?Ïj>™ORì“#à:5ƲÁ\¡oB;î ÷èa]Ý·ú?¨‚Uö÷‘7¼¾})ð®oß÷Ûœf;€¼“sÚwÄà±É ìÜuH %ÓPiôI´	<ÀÜSô£Þ}Tí›åÛ÷w7o ˜Lð—=6€‰jŸN·Í:ûÌ–zàœ°•ÃfD=›™Q¢uÛ):¯=¦Æ‰A[,<·†ï–‚ñ´@“F¸ÜoîªÏWˆœw”ýÕž3‘•î‹¹yCy´Ç¯Ž´$ßhì>µ©]«2¼Y?]éSëL¥^ç@uCºØ¥_UYB`jS·ž†Ú~è£Úz x@ºòº_' „ïoTcÐ$VB+à¾ãR˜j½yñýh`T+±¢k<5(†+‘4æY_‘hº$èÄf'é)lr´Æ¼m
+»(炽ÙÖÞb¢|-yIÀ+F#Û{…ŸÅónö÷Ý*Œ·F‡¦YŸf0@„¹ûg†î`
?ìׯú)ŽUÇfS¿¢'vCƒqAʼnÀlìÞ—¼çŠ5ÙØ)˜÷Žºr&ôYàî$@\"Ð0ÉÐ#ŸÔž±„RÎ_’W¨Hˆ 	ù¯Û¢«j`Ÿ‚÷Ë‹"|²,ë=Ú#_·Áÿ=Äc6L*ÛsmTçxIõtãmQzï§}•çŸòàSÞ
sU@‚µàÑ'zRs`¤4·6ŠzÞ2RÐYR‹raº„ðÔ5­ãxZ•=`glw%N™ÁU”Msð	>«kð;c¶¦£8Ñò€C%Z¾”ìøR¢å‹f(…Vâ0Ýó“ä¿U—Æá !µJL¬Àcg…5Pîµ!xKqÙñAŽN.û'’é18XCøˆ5ä`3‡5\ªqî)’ŒN.n
_¹ª'Ì-Q.Ò®Mþ^dn³vÑ°2êïU×:8®Ö‘siÈJÏ(‰Š’$±C%A²ÿj›×üŽú8q?’ŒïZÄzÔ¦H¸tc&V l‡/øÓPb!•:þiè·­
+|ô|ïIhZ†CR³p¦™ÔP¯	uâó]š’“\Y*“A
Oÿ\YøŒMéóbN„LH‹f¨F'°¤MìVçÏú—¢,~¥S“>ÿÿHPøJZõ?‘26
+Õ©ÿtµRV&‰‘gJ?ITÿ Æþ2dÎØZš9õ/P˜aIĤF¥×ãë÷•žü=¥9J•zFz	„{þ5Þ_Ã>z—ʵâé$ÆËF%Õãá+Ö3ü°“¤ñ3’ŠãHÆÚO†ÒQ«sÒêññKK@ZçžS+üã‚晈ÿ¬n1ÂŽ¯×á|&véyYaKMjýL?!ª¸«_¯V¹82ÇÎK
+ÒÃ؈¤Ÿ2ÿv1Ä3¿—ĺ?:ÿ?’ ü¬àL‚fþ½wôë˜<{­/ýw÷çwe¡Îq'¾ÅÖEÊ%ñ$ÑÒ‹Rîøƒ—€Ç´X=Öÿµc±ªendstream
 endobj
-1195 0 obj <<
+1211 0 obj <<
 /Type /Page
-/Contents 1196 0 R
-/Resources 1194 0 R
+/Contents 1212 0 R
+/Resources 1210 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
+/Parent 1190 0 R
 >> endobj
-1197 0 obj <<
-/D [1195 0 R /XYZ 56.6929 794.5015 null]
+1213 0 obj <<
+/D [1211 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-350 0 obj <<
-/D [1195 0 R /XYZ 56.6929 293.8263 null]
+354 0 obj <<
+/D [1211 0 R /XYZ 56.6929 556.4918 null]
 >> endobj
-1005 0 obj <<
-/D [1195 0 R /XYZ 56.6929 268.1652 null]
+1010 0 obj <<
+/D [1211 0 R /XYZ 56.6929 531.6301 null]
 >> endobj
-1194 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R >>
+1214 0 obj <<
+/D [1211 0 R /XYZ 56.6929 178.7136 null]
+>> endobj
+1215 0 obj <<
+/D [1211 0 R /XYZ 56.6929 166.7584 null]
+>> endobj
+1210 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1200 0 obj <<
-/Length 3311      
+1218 0 obj <<
+/Length 3619      
 /Filter /FlateDecode
 >>
 stream
-xÚÍ]sã¶ñÝ¿Âo•gŽñE—‹}u¦çkg:i’Z¢,6©ˆ”}î¯ï.vA‘%]Ó›éÇøvû
ˆËþÄ¥5q¢œ¾ÌœŽM"Ìåtu‘\>Á»÷‚q¢€õ±¾}¸øæFe—.v©L/æ½¹lœX+.f¿LÞýõíß®ï¯"i’I_E&M&ßÞÞ}G#Žï>ÞÝܾÿéþíU¦'·ïhøþúæúþúîÝõU$¬ð½äŽ|psû·k‚Þß¿ýðáíýÕoß_\?t¼ôù‰BFþ¸øå·ärl‘ÄÊYsù?’X8'/WÚ¨Øh¥ÂÈòâÇ‹º	{oý§cò3ÊÆÆÊlD€Rõ(€uz™§
-^¡oçW‘²fÒ.
-þ]W•
=sz¬ò¦-6;¤7W‘?¬ö¦hŠÍsÀ|)—Ë0Zͪ·í`æ»·7?¼¹vRü±-ÆikÆ
óì–YæÏEƒ[rˆ„ˆ1Ò3õkb’Y1Ï·Ë@›šêdò°ð7iõv‰ÄÀV·›òéÉS‹?üÜ°fÊ|Ipµ]=Ô题þNÓ•ÕÞמ2‘”µgª~.geõDÃe˘ÛõºÞ´£\XÒ9@ýâgÀ_~1x1?VÓ¤_Î_Ön‡G,!ô²(—ÅÞ,ÓºªŠi[ÖýFQùEaì¹	*k-õ<à–7vÈTaÕ邆÷õà9§9Ó𸣭%.—Ō߽â á¢¯áNÄ*K$,+Vu‹b ¼¾%(°µ45Œ–ƒ^ŽÍ+“逳lêèè|ÚÅÒèŒqcÏ}$¬¢­)d±SÒvö&SÉ‚€· /	xæøݾÂH½¡gÓnw_½Aаæˆ0 ŸtÌ«iö> á§í2ç¯~•Rï(Û®¿¦ç,oÄ`\Pqš Sã9¯¹`MN³	˜÷¦,úâ÷@]-_	Z›y½YÑ ’¡æÔl™2Öðƒ÷aQä›ö±ÈÛ¨¬Às=ƒnÕq’M(>­K¦–Ö)y½|6+Ù6põšžèÑÐy»Sô½r¨ô}Mﹶ&î$ÕÓ›²òÞEº¾ÊóhJ¡a.ÊâÍÁ¾ÒsÛ0AßÜhÛ×æ,‹eªÏ[†…/“¾ÉâÄ´9!×
ãxZ•?Í›ÑÕ!|Y=ýÕIYÀ“§qæT:”Û:oð;c¶fb©ŒØ£P']Zìè‚á@½ñÊæ±{Æ^’ÿ†—(Ÿ÷ù0HH+ð¯ðMlŒ
*µOñ³CF8—}Ž„;¤Çi†ƒl¦ð8æ¹ö3’ŒŽ~Ü&þ sChÜܔƼÙÿÆÜ¢î£Ó=Ã{Ãq'8åp‰­uŽW<¡$:VJeC%Áiÿµm8ÊÌÊ&\}‚XwvÚ“Åï'~B7‰—)ø  â³R?•¹Ø
-ㆩߟû*ÒºG) ï˜‹Á°颎©(M¸ÉLI,¥eó¤	äŸN‘7›AÚäHoUÏ|Ò¦ÍiI«D(R¤5é–ÈTv€µsiý}+	¾ÏÁÿ&”¿tü
¦'¦'g1&gã$dð6eo:bêô/†¼]BúüŠºoa1œ!²Ê*žjT~=¾fñA˜K\jÏÉÏ&qj•öÒy¥bO€PIe»”®“ÐNhüÙ¸°zd|Yi}Q«6©hjrFZ©3iÕéÌa(°å:)°%_³zA5.ljÎ	Ì@`Ï”8“œU±SæØ£äk$CR	uN`¯­ÈÜ™¨~D`Ÿå¾z„|Í)¡’ÌÒ³þ_Éئ\5p6ýçÅvÒ0{})¹íZYÿI¸,%भ×S;è­)üƒë‹´'h…=ÝZÓ¸´VÜ¿©Û®Ë²ËRvÙO¿6ÜÏÚûØ`Ήçˆ4/¦íÉ.ˆ„	Êà°áœ‡êl­Í2ÛïZz™ cäÒxsGz·Œõ±57ôE;,ßÈ/¢KŽƒ´M(‹Ôe§ï°FV&Cà,®~‹Å<¤AÜ,¶zb±ôpvËK•k.úámQa¹0£M¹Ú.ó–¶*ô$«~lêeá÷†¿»û‘bÒc´¯k~{ûÃO×÷WÊþ|%„€
Ðc&Žd£%ꥪ þÖ1u¨azóQG‰¬«ã{›¤±H’ôÌÞö°NìmÀò{[´ÓEô´Ü‡[›À§\»ÃY|°µÊÀ–ö9ÁÕ©Ó+S»ÛAlæ„1Þ#lj¦Š†YðÙÑÔžÚªÐÃè1ÕQr$‹„
-_ìÞûo¦ù¶ñkpë-ëõê,7–ì$oÛbµnûÝ&K+r¯)Íb«ÜP'ˆé,LM½õÀt0:­ý»8ˆ}h|ÎÊYõ†ÔwˆnMëªi7Wv²²Ö»À¡=æ=Ζ·9AM×S†¾YìÜ$¹†©‹x¬sÈÛ8p…/]K¸)gMÁÎ0gŸ˜óoxŸïš	885¤²=j0Ê@áÒ3ΰuÜ`:,ªÑµm6]›¨®¢f±mgõKµO‰„Ð,µt§Ié°FhÄ0	ˆCbþAg:JqKLA.š¯Šî\^ŸÊ¶¡W³mAc¬aEùLçðîÇÛ÷×÷Þ3I¯jžiVó
-æúX^ÕЗY9TŒ¼zå°ÉØýŽMÙÍþ¡—ÀFôü±K*”îêæ{²ï„S§Å.Ë)Ê™…3W%6Ö:;ã”ûX't,`ù]\,gÑtYU{ôAˆŒ&'	è°F(0EdWbHŸÁeiç™~Éy°¼“
-\kRë{Î8¾Z/‹íûÝ8À_’A#„Ñ['|œàQÂœOUÝù	x„E^÷?wxHhíäáÊj’îi¨â¦åÝ£¾û®1êlyV³‚Û¬E—¨Ñop|#Ê&Q.]š6²9{*e¸UB÷*ìóÇ	aNLh9iÖÅÔŸHn_êÐ^盼åaÚ—QëÐØ}Aóm»ˆªO³z•—cÁU@‚½w 2N¶Lb-;»;u béf>• Y¦SbLXP!u²:Ö"ÓÚ„^r	ñ­ÈgGRBÁjuÆñ÷±Že‡å÷½nÚ¨i!OkÚrzh”ÌȦú4ÖC£„­H³lH‚Ï€ŒèEGŸ
-Ra€(ýåù{Q¬Ùí
->“iîO-ñÓgJ~Df‡%‘ØAcˆá©BN°?Lȧ|Di'Rd{g&e»`oŠ¥ËðÕAp|·EgXÐÞíÖ‰ÝXH)ÚJÿQù‰ÚÑcÞæÈ`ê.Õ§ÉH‡dèlàdÈfŽZé]†0©]3’ÑÚØd‰ëbX¤¤˜Ü¶ô½÷ãpž‹SòÔAêPfÑtWACT†ý]•º5¦œ ú‘Ó£ÝäU*~»#uYó¹«0)R{á)ÑTÕçÑ‘>p[M) vø”ÿIÉ^¹ÂÓ1XqddÚóq…TG°•¼PN@+
-H¨0™æl~­k¨ôÁ¢xöÛùØ•‰×zÒÔ ÅáŠ_ñ-ŒmûTïúü
’£–y'mÛfô,=u18”ÐXoðúJAj;r.ySÿ|÷hò#Î%?Xf9—œñ³}¬ã–×ayË+«r•/£
W‡ž6
-!(Ÿ&¡Ã¡aˆÓØb>8 âv>"<9§M?#¬Û^X7Y¸øaL¨ÓzÛ„Æ„I5VC(ìoMψkZø߀1¨ê8¬±7]¾å}§!ìïNxI•ÛE
I9Î©>ÕcJG%Cá¨D(g•a"‹†ÃÝŠrW*º™RÄOÞÆÐÓ,‹'ßñª¯˜þöÕ®’CYѽ±“Eé*íB
ßðÚ¿UÅYòjZïKínoÑ&°Ÿ9[®G‚=¨Äè/Ps¨ÃyÂ	³ëa0»€åÍX(!GS_AF:+'Íi:¬
-̦i¬2e‡$ðŽ¹^?`Š.
±
-†J~Å® K(^סxÒƒ³_Åù‹3~褘N„ùîîí‡k2¨’´Äjª¯c‡'Q'å乬©«GÃ^£d¸ËÔt”x[ì,ç9¼
t)¼¯ÃT/ù`¡|ù’¿6aŽMIe¾)ªyÍ=¥foÕKÉ>/v²í2ÇǺ]Ó±p­a(¸e‡Ú5mf¯ ÙrÊÑj—ÏšøØÍ[eb¼.;¢EÉåٮϽ•»»²%¢²öȽ•@.D¡8tvpÖ®ï’þ§ÿÛendstream
+xÚ­ZÝsÛ6÷_á·È3	Ì=¥©“sçâ\wnzmh’²8¡IE¤¬øþúÛÅ)Rr3½ñxK`ýúí‚ü’Á¿Ô*bÒÄ—©‰#ŸºÌ/Ø匽¿àŽf鉖Cªî.þöN¦—&2‰H.ïVƒ¹tÄ´æ—wÅo‹·ÿxó¯»ëOWK¡Ø"‰®–*a‹nn¤C?o?Þ¾»yÿ˧7Wi¼¸»ùxKÝŸ®ß]º¾}{}µäZqx_¸N¼ðîæŸ×Ôzÿé͇o>]ýq÷ÓÅõ]ØËp¿œIÜÈ׋ßþ`—lû§I£ÕåXÄ—±’‘Š¥ô=õÅ狟ăQûêÜù	n"aLz¹”q¤˜c@5¡–H­%œ¶2Q"…§
ÍÃisí8¹Lc¥š){Ú·m_ÒþûuÖS«i·YMíÛw7ï~¥öf{Åõ¢ÍË®«šê«:ÿŽ{9[!ѪÌû² žûg^›Kñ„tvñ@5³úH:±Œ¸âãÕo8B­¼úëx¡_ï‰AZöäa¬ÝôUÛÐhÙd÷µ=wèªÇ]õ$*xî×%Qµ÷][—VîÐýãígjÐ&-Eÿ¼q£7?ÿ¶(ÓůWœsÀˆæ§*(#µä<2J	Ë|S>•[R¢-žæ³ÏžÉ¶9)Û$I#Áy|^¶CªÓ²
TV¶eŸ¯—õ®œŠ–Á«‰>¿v šY|$Z©Àð†;ÁÕïH‚‰>H0I¡ÏÉ\&’ºÝÁCÁZK¬‡+)°*-g.ƒ
.ÆÏ …©‰é$’
+ý‘}'ÏvÕ Xƒ4¸êÊ-É;[úÍú¾|ÜôDà;튤ÐiiÆ:A¼£Ö—”]»³|Ô›·ö·è¨³êé·¨Šæ•k¯³'÷Ê~]6ÔÊÛ¦ë·Wz±ËÖ¿hdEQá9[φ³e}F­œ	ÚþšE6bsS—VCá˜F;rb¹Â=5Ÿª(i
+ç3ç3÷ã®+k\×$ÖÍRÕŸ6.À·ÆüƒP1O…{ý1¹ëÖËÿ¶MÙ-ÛfÙ­w}Ñî›cN㑈…9ÏJ šáe„q 3óo+w)%‰XJ±h²ÇÒ«*”ߪ¾£¡bWRŸÓ°²z²*‚cŸoÞàøðšÜ&i¨u3­[ÃÜʪºþR-ÆŠ‘5Ï.l–Mâ%µöÛª/;´oÎ@‹\oQ®²]ÝšFNž¢‘±³×³29v\G	ž½Ú´3ÞÀoá…€«¥<ÎëØê´Ž*\qÁ.êb™×UÙôÝÄ3+àÁYÕ£Íªvkø˜2i™&Á3c{Ÿ¹ÎêŠ/pQN“úúÙõ?nêò˜F[·îM2hlaôŽYJ¶nIüœMüvÜÃ"ÏǯЖDëÅÝ•Õ$Ý‹ÓˆqÉt/_W%:Hn™6*`­)p|*P£gp|3Ê&tǦÍçHÅ
NŸ{åœ8<Œ~N4L,ºM™W«ç#–û}K®ÜdÛ¬wÝ$—Yë\	™„×ßlׯ—Í·¢}̪9‹€àÊ#f‚éò3lÅ"ØŠpfy±4õ±t»Ê…dz‰pŠÏ–ˆt8«ykŒáø•q$Ä·2+N%‹âñÏå€êŒQz*+÷¶ë—]8­ë«|j”1˜‘NâóªÆF	¢HÒtÌ‚E@Ñ¢£…ÂÐã 0´þºù¥,7ÎírŠêð;؃%Zµ[÷ê_hâfÇ)w(c1„7•ÇDÐFËÚf9Yؤˆ˜àéØ&÷U¿vÞþÖ'K#—a;š	8)í8‘Pâ…œgHuZÚ
+9E[éáY}[Y§´¼Ïº)FS7I|ž
O4e#NGABVG|xh2´©O²˜D«#yTˆaK)ø⦧÷­džù8¥›ÚŸ:¤Y´†…µðXÀ:ÛÇŠBwŒbKýôÛ¬é@ÀoVëö‚+É#°œÄTÕâhh‘>Bã¦É) vXÈ
+ÿ!ð3Œl+®€4¶{„¸â6¤†~¼(ÝBýx^‰Qè@FmÁ´C›ð´i!Ó‹r³ß¬æðs»ó0Õk1€™ªCƒ¤‡v×?´‡ºÁd#pÔ»½u¯éyוsEˆÚàP|u`³mŸO“ÚN½­ܤãäeðÃ_?1D0%Õ{HuÆò<•µ¼ª©³z¹uÇÔÓ¦À!åó,ªÆ8‰4âÁ7«™Ã3€9uò'º„u•¢ã´Æ |ž­б­/L¨d”cuDâü­xY˜¡ªkz£mêgꃬŽÓÌèHÓe»¥ƒì1„}£Æq¿_·Êqf€ú”I>N1• ÄQrŸ8vÔï6(m´ð“[ÔMí¯»êÉïL±2z°6†ž¦.l=Ī¾T`Vøl³] ¼Ê_HJ³çj¨|÷ê}¥ÏO¶+¬ø5¹·ÔÕ…‚ó3/¦+#Å`’©øÿsH‹—ÕŸ5»!Õi³TÖì`Dâen3Èi¤ã‘4”Î2¨f8m6I"™J=fÁIÌêyЦa« «rCÎÕCK‰ÕuxÌêÚ °I?ýZ*‡_ ×ÓûJŠ
+Ç@”ooß|¸&c,)˜M
ejpBwB,žª–ªzÔm5
+ºI£ ƒŠŽÐ€¬)27‡µñ`¼Ž› Ùg£…²zŸ=w~ŽmEiŽ”ͪu5¥îhÕÖŽìÅr¼oûõŽ=f¼]	nHCѦx†“­r­6à#0·?¥ÈLGœ±ÛêŒ"{*²®s¨cýå"J¹’ç×
T35“$ã•gƒgæRs6jÎסš¡•s’à\ÐËamF§¤6R™p-d`±]ö€Á‘àqq¨pA-rΖ€:k`‹Öƒ‘P:J¨˜g©wÈS­ÛDJÄGXÎ7Éä"_g
0ƒs_Sܬe”p@§`dGÐÇLƒÛ‡Kj|ÊÅÓ/‡/ÌÈe2/òõÙ×6‘·8â“Jd/=âfZ©óT/ð0Íð8Ñ4ÀØ Dâ#èÃý:¡t:z¨!‰³¥ ¨Üî%Šö•›Ý*“oE°RzK=¥
Èßr‹É¥Œ}y1^Û‡2cŒ5ܦ¯Ð/X–$%£W?|CÖÙ¦}¡.¼z#:iÜûvóðkkˆ‡å:z›?Zi
+Ü\Vwíòà#Ž„X"C ¦0¹à†@#­¸>‡ušzœH¶´hmº^¢¢T…zŠ­¾ëÁìÁà^ÅP; …#؇ÝNO„˘°+H:m1/~E|Â3ám®f~ñòÛ¦®òªŸá2N#-Xú\zÞDà—£@Éw ó„Žq(
ÒÅàáy©póÒ¦4AóLÙ	ì.U©òµ©³rŽ!ªª8dÇ€èæO)±Ê?‘1½ö7 áR8“–
+òÍN½°ÀŸr1V¯»Y‹MÄ fvb’ã#]†¬±€xHÔº/é×– ƒ;¬…óÆÅADL·ˆ
(3ñMAf%='X²)/‚¥+ì×U¾¦fŽµÛÂ{/üȾ݂“éÎq	»ŒXœU‚}¥t)´9}\I
+‚>fݶH¨n/ïÛ]]PÓ¥_ZÛ£³3—øU@F÷dž°%÷»mã^¡j³v—×fpy­•­Ü‚á&ƺPj&·ZCLv›o³n}vq¼‘Tú…;‹!Õiب,|,óݶÃÇzæ›–T3kï‘8v´ø	7¬4ûÎtÝc‹g Ô;œÏþã#B[v}GT.¸Ò¼q»!zw+¹<¼âry\)Ü#î’aïÛì QñÃ$ûvûÅ%ü¼f>+åØŒâ©5ÝÞrÀ\lÆmÍÝ`lÄ°£mÑVoaè Î,v‡æö„bFOW¶0LßÈà5MÏ4ò…\9V!çF§Êå‚¢ÓqHwç(üMµ³8xΆÝ+ð ÙˆÐ_i[aQ>c‡|fóy8r¼âøÕŠ¹/„öeußôý|DÓÍ1\¤¤ÌF"¥£4M½£u§n‰Ýv¨þQ>ax¦`¬TÄ…:º·õw[K‘ªÕ¿ÛGzzpìÂCâË@"’`z(]_uôNžåëòïÎÝõDæœ)´ºå›r~±ûÒñ£hî‚ȳn¬+Ü]YQEixó'dBÙ9ôÓΩïëîŠ/ÊmE7Ô,Y¼Å;E»PRU	]Oú‡³ä #êµUümhh¼ ?"8>"©è*ÅÕÚ°b+…Ö«^ÝÎ}^rŒl»éçjYQ8UwƒuÛ~Ùmü•ûçÒæÂ;^W‰xú-Í¤ÒQ̽¾g÷°O©–hH^(ˆÎ|§æˆfoÇ×s*’‰HÏ®ˆ¦‹/çX$ãñ⟽Yà%ÅvÛjç®<R&L/	@V¦?xòp8¡~•’Ô2äa´ ýdYP‹²¿tZ«ÂW³ºõLãÝÜhâÔel,9z×'Ž˜Þ¦fl_î2‘
K¶¶F„ž¼ûþÒ)W`±ùKŸkø*‘Šð“ÓÁ³0Å_þ²õðÙ/$MRk1¯Bp¨R™Ô3…ŒÇæ˜s%5`‘ΰþ?‡
+¤endstream
 endobj
-1199 0 obj <<
+1217 0 obj <<
 /Type /Page
-/Contents 1200 0 R
-/Resources 1198 0 R
+/Contents 1218 0 R
+/Resources 1216 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
->> endobj
-1201 0 obj <<
-/D [1199 0 R /XYZ 85.0394 794.5015 null]
+/Parent 1221 0 R
+/Annots [ 1220 0 R ]
 >> endobj
-1202 0 obj <<
-/D [1199 0 R /XYZ 85.0394 625.316 null]
+1220 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [182.6146 292.3397 231.8861 304.3993]
+/Subtype /Link
+/A << /S /GoTo /D (notify) >>
 >> endobj
-1203 0 obj <<
-/D [1199 0 R /XYZ 85.0394 613.3608 null]
+1219 0 obj <<
+/D [1217 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1198 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R >>
+1216 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F48 890 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1206 0 obj <<
-/Length 3763      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ6òÝ¿Bo•g"Ÿ$0÷”&NÏ7çÎqçzÓö¦(‹ŠTE*®ï×ß. H‘’Üi'3&,v‹Å~á3ÿøLÇQl…%VEšq=Ë6Wlöc?\q³@‹>Ô÷Wo?Êdf#‹xö°êá23†Ï–?ÏãHD×€Íß¾ûxûÃ÷ï®5¸ý|w½šÍ?Þþó†Z?Ü¿ûôéÝýõ‚Íçïÿþî_7÷4{ßßÞ} KŸHïo>ÞÜßܽ¿¹þõáW7ÝZúëåLâB~»úùW6[²ÿqÅ"iž=ÃqkÅls¥´Œ´’2ô”W_®þÝ!캩SòSÚDZ¨x¶*2@Zʹ†~t‹?¢D‡«o!XXmDZ6õâ` Ž6­ŽÒÚŸÄz‹z‘ ÂØãì¥8}ämd’$ñ8H`‹º*§èÅ:J´TE ­3_N0¸VÑ×Áç‘ëöz}tð «ÛèD
hÐQuÂ2¡Ñ7`õ‰xþû¶,²¢àÙ–ü.o¢ã—㆒íà	ÚÌá¶t›‹þ*°‚3ñwØllzšØf.ˆ2	¢<¿ÍÊ‚QVÁàFh§Ø	!)ØuðUÌ;–	dáÜtÒA6ÒRÂß”ðJÉk—`1ø;1Ô®‡I…†®:–N¬Qrc| Ê°Pƒ–¼P…D­Çœ¾Í6ϧØj:[00}¶8è¯H:^œ?™po:ÒR5àGò
¬$¥¤è(<¯‹lMÍ,m»"xç±ü%Ny.ÊÒSjA×ÐÏb·Óè\úoJPü€ä¹Þ}õ	#ðäÈqæ
-jàjùR@Z5ÏŽæý26hiœs4„Â:oáË"Niaè ËLy¡…è{º•B{Y;­…a8{~BI¨Óå|­êç#®<«Ç EårNžéØ{9
-ã¹õÇ
~§ýî˜tØlÁ&äm–ËṗÛô£h&½f¡Â_¡[IÏ¿À"ïêÖSiש#‘€ ÚvÚŸ1m‚EÚõ¶Lú!H«’¤cÌ‹ÝûõliåßÐ7“'†p™}Æge89Ñó•›Soèדg~ÄóeÚ¦S@´…‰î´öð»†ædi¶Îÿæ]K`Þ”B«Ç '_åÏç‰=æžM¸—ž6Ce¡•¥(>©AœöBZ€¿cÔf×O+§¾ßö×|žï
-CIÏßz¢Î…b£iIK{D½iã¿

	ÁÀ±ˆ$z\á*§¬ð«Þæ»´%³" êjöà$'ÎAê㋺Xc¹ôºî˺þºß6>Þù’û0Ä…SÎ=Ž¬AWy›­Oå~ÊÅ+)liúîú¤ÒÂFLšø¼êCvA”;#«LHfíË6åxŽ$ã±k°áÜ<ÆW‰¨¸à7¢š©™³èAûÈäjÖ3¹š0¹Ú‚VXþú |¤|`MµµôTe¶¯ªtIã
-wfºÒç/›Åú4.šÇ—o†CT‹ÀÝBqIJzZ×I|BѶÁ1aÖ-õ®'+îkNZv÷ó5„Uóø+æ£
- 3ùÆL‰$Ò‰[Ëì·øe­$˜^Û­ô ×ñöv#fjXϬ¿$wÑCìV‹Á9’
-*9SREÕ‘þÜ9‡•˜ù˵€dÐÿ(6ÛÒådãKð뫠в£}W1dzÆšY_²n³$ìBl!m^jœN• 芌ÁS$À*$üBtŽÈ8
-ð¬iì P¢`/År±­ërd„
6¨vlÔ˜ºJÇ6: ÿ@Éœï.Ù¡³N}M]æí”[$JÇGyú¨ê–ÏéKȯ˲Π{ó?CØÍÛ¾¯@àú hNº,ˆ÷À½Iya_zPgö%@…„yÙfqDÖŒö<€‰AÎ2ÐAMp0tZ:2p֜Ȟb8™4{ŠC’¢{™Žî25Ï겤Aª]¤>³Ò×'?šJY„“ûª¤Ñ„‚àqa$ôaàŒâò‰ŠsWh6
8ë·
-…á”>oጅ¯CÏcÚ¾äúøâë°Huõr¢¡d,zE‘þ;“>Ü€‘<¸¹~Iw¢d"ýø…ÂÕ®l×5°ØêÊÑpJËGb„K•)0åJh5Œ7]ÕC'ó4êçâ“Å9F C2S-3šD§´KÉHY¡ú%5
-D8ÏëP\î7[ê9m|«¦1RGè@ý(sê<Ôò úT9I0p·ŒÛžüH@o"¯ë¾½’]œwqöT`"ñH%æÂEH)ôá'®§Ž±®Aè
-Q€}Ž¸_ÍÈHÄàÞúÆ6'@]`dŒm2<6TX%§î
;CÛ‡:mh;¨Îþ–ÿ¸:Åñ™ó„ИðÀ÷ÙËœ|H˜\ŸLu>lw}§]Ÿ‘ä}×ÛÄUf¤aó—zOªÜjª7âwY4é#*;þ¸ýéãýp8¥Ï6Ý&ïËtGÁ
-ð¹Ï ৻OHÂm ^ä)ÎÝE![ûk@ŽGD³£dQA°IʾÓçÌhˆü:·»ú[±<ìÕñùJ°þ§jÚ.˜¤¯
-̆èöä…“À}ø‰Û½c¬Ó'kt¬ÀüEqÌõ€‘¦uP¸cëÅG£¼~ÀGŽC±W‹¥ƒ¿ÄÑïH0*’£ðœë¼ú©tPxc;ol墜·5 3¦ÆMið°‘C}Žt4¦=LxAcHûÄ»­oÙu“íŠÞA©WGÐ&êÂø¦<ð>àu•ç^?¿ÞÖ×<Å#žô6iòÜ ó<Œp×/ˆ‘¥R²¹>Ô
PTv—Ó*Æ —äRœ§ÞAM*™ÂÛH=¤ÿ×hÙñ*Žµ,°yZËàŒÇÜðÁBÏ©Y€¿°ä1Þ×*šÄ[r}aß;¨lŒ±Õ5Aº¶ú‚1ëCÖµ
-)¶»–Ÿg£ƒšàc tREZ0=dÄ×?¸}h?§¾Óß“*FA=ôø2´}\ZßMú5÷=N;ä«Øéï¦Zú™¥»]‘>ùƒK&øéè/B(R`®>cÝ=ýÄP‘…SÎÃÔ~d0 ÌÝ<_ët—f‘’bÇW-½§HB"”@¾•nrêzvtSâ†RúIûëš®Š#múè/oÉöp+g艎­Ò¬(ñ‰˜Ÿ\ÖéÒßÌ$t¿”Sc‹2(OÚm&²BŸïnòì¾@®¶™ºîð7h
-’w/*à×S^á}	邯$@wê¿wôuKƒï‡Ï_¨±q—;thæ·<¨P<·oèûXc[žKhÚžPéñ•û_M=J€È8½ýËY†õ¼õKЧØHt$“.‰}­WÒ׿hNm–µ>Jªü¹,ªÉ3ƒJ_†ÏÓòå›p»°P#NG±ÊH˜Bé+3¶x¨I±˜`ýÿ…¹Ñýendstream
+1224 0 obj <<
+/Length 3747      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sÛ6òÝ¿BòL„â‹ øè&NΫsç¸siû@K”Í	Eª"eÅ÷ëo@¤H˹iã™\,‹ýÂîRbÆáOÌÃL&³Yši–p‘Ì–›>{„µOÂã,Ò¢õãýÅU:ËXf¤™Ý¯{´,ãÖŠÙýê·¹a’]>ÿùöãͧ_î®.S=¿¿ù|{¹	Ÿ¼ùç5Í>Ý]ýüóÕÝåBØDÌßÿãê_÷×w´d<on?$£á¢wׯï®oß__þqÿÓÅõ}_.Œ˜ßÃÿr>R‡5,UÌ6nãÙŸ3Á¸Î2E8½¹;éQðÃÍFÎ>4pžYÿHžî¢GØÈÈžÁ
+©@/ZÍL– PÑ‘šŒ(µó—KÉç…(7ÛªØuW¬< ¦Ñ›$Ì2vz¢Šì|ß‹asAa˜°£€I”4p©õwGœ€õ#cj$˜WBlèZrs>Æö±^²+Þ{ß æŸlœ	t#{~ã€4Þxpéer-%†Ó¥§Ò,^z8°×/½L2%ú—žÉRŒÖuðùK³'u¶Œ34zWe›? ±ãÃͯï†Ë9
Û|–¼¯ò„( æ³ñ±ÙÅñPOž¬÷LÀE®‡µ¬×Ín“-ŒÓ~fȈü9·»æ¹\uuê_°Õ‰G¤õ©j¥¸a+ÑŽ
¥Rg<+ /úøcƒQö¬‘[AøcÆ@¹Ö'?²´ˆõcj½ÌÈÇ>o”‹CóïKÄ‹£Ý‘` £%å"ap«¿!•ˆõcjçƒ
جÐò»u&ج)#„W@ÔüúìîkbûAx…®
Ôƒý£øÏWE»Ü•=wiÖŽ˜¥ŒKý¹¢9&+§îwÜ…Éà çü/à¿qä1Ýïõ@0
+‘öu5éë
6ÆÔÎÚš†ÈŠ,9ok}¬×m-b¹\ª€â¦í¦mC5) ú:»{ÄšØ~hkš¥è]ƒýÿ[;=Å©­A´6_·µÔ‚ƒƒž³µ€ÿÆ‘Çt¿×ÖTÊ,¤|ç%±Þ`cLí¼­%²gó–­õ°ÎØZÀ»]‘w‹%ÕGy»h·ù²¬¤A™8ÏFÄšàc`tJ³DòdȈï$hqL`~È=pOõˆæ”àÄ7`fip%Œ›üká!Î~5?Ö®tg…SÓã2ßíÊüÑ¿AkXlÒ3–¦¿K©É€…Ü×pùq
+šzÂ!4ËÀƒ?L8b6MÜë8Ï×S¾Ë—ÊÉÔk<µÃ”¬ƒ,;c¡(J¡öÊ7ùMœa)§GÒ¯›bBˆ+]þ@ÚÈb³4«H¨°¶Î—eUb¹IÏU“¯°.t 8 Õ×8£jÊo픉¬ÐðËíͯžÝ¨Û6îˆ|XŠvO¤8Õî==u±Ë©ØÓ¾«àÜ·÷4º£ÁøáóšlòåSY˜Mq;¿ñèÁ„Ì<{GãCÓ=ÑÌs	³×ô/Rj>~§þë	ýƒVm*{úÇY…óüà¼ÆFš0•Æ‚ö{­px’¾þMçpf«±œ$'¥D]ª²}¼<ª÷´ß·\[Ðô;ÿèdÒ¿”¦:ŽåcÝÁÕ«±TYt\¸ÎÆÒ>Öë±4báÁòÕªD–òj±Þ5›E¾ïž÷'KK°ÇQ˜•	\M©²ç9ŒX,«'|1ä1t‡2íå×Òò©)06¨EåVŠ§ü¹tÕ#¾´¦=ÎpÆf‡¡|¤•Œ'˜õõµB0TÑóÃSQãL™Ü\À¦n‰–AX®7„Sà ð/DAÒ
+v±”5Ê9}Ÿ:Ÿ¯›ªj‘úûÛ«Ÿ¯Ã¾«aØ!&?j‚aY·,bY¦D`ÄúÛ@	éÃÎœ\`ì¼|…èÉàÑÌñ¡Å¯»™èÔŠ”³7:µR0®²àôxI‘º€äªXçûª£‹Ä팎ã&Ä–oœ#¤ôÌ=NF„݆ˆë_;6ÕÝúÞ_I"L¦§Qûh
+³²Ðÿq"9ý-2nj¼(÷qC\/kjöWסggzw²Ò·—©ÒŽîå _uÀ÷æF¯¹ˆ˜¹¶ÔÄyö5¤ôå»Jï|¯xï±™¤Œ"ùBÜ|”†"-Q}Ëbçqÿq@–q}G¯-»Ú7÷i‚hz,<˜g¢ñ$JOÔ÷ª"?ž‹‰„¡­\ˆæ(Tc]ÃÛÁü˜‹S¢	ئY¹¯
…~x!„=FDTrV@ªŽOÁ5ÜŠ“
+cæWUÛ uBî”?7¥ÏŽLP¡A‹¤(à
Ïëf7¥¯;+‡ÆmE02Xñö
+°vëÚ…ÜoiŒÙ®Å „ù’7$ÙÑHL¶iÛÒ5\|Ûuë—œªFlÈ¥§xoúîÕ6Õ³÷·%t8kö•¿Êsʶˆ®G_ìÈ°S±ŠÀáÝêöÞÙOÂuêxúˆV%ÀŠo9~eF%qpŒ5B-†E\ôa§yûµ¥Ùš^µîºCÀÏ¿Òèíº	æ€8ë°ÏSÓv´UÖÚJ±Ôfá‹Éºi˜çˆ-›ÍÔ·£Œ£zßãmg¶¸‹“î;æß<
+’1¨“dì˜Uxd|xhÃù\p7yYEÖ뢛ú”¨Kxluã.Ž9¯±ì>뉌‡C8…z›i	0<•â-rå_ óñùü£ÛŸ¼OŠ^•šÆOkƒxé@F—&™â‹á
9¬Ý
î ýà*Éqa*`ÁQ£|ÓÉýšÅHuZ]‡PsLWÊ.”"˜#üæ`2SÙ¶R½lŽÙ B6º¢v¦‚OŽoœìÛ¸Žã0Õ¾cYÐáqéøMG%t‹"”^TÃÄ#¾¥æÏeqèe¸½Ã_uP—o;<¢L(¨KCi«ÐgYZšøXÎ5K•:oXt
+}
ÞSwŸ8hóŸäa˜ÆÐÅr¿k)á"“›B唂⇎ÈËÜ	·$µËÞÏz8V—Qá{:
+/=I‡îÓ¯_«æqðû”C¾«)W€‡
Ä¿ü±˜4¦/礡-³Â„Š`ºÜ„LW¾¢
‘2ab|Ì—MÒO/àžËêà†0!‘iésëÞÊ`·Î#Õ9¦öŽ	†L¾IE…IXvÚç"‡UE×|ÝoчHÓÐ^Jö‚3ÊXq1©¦0æE¤ÉÆ.~ƒUYø¢k¨‘€¸ûÖKñE—4Çâ™8džÒ¢?•¢N¹!å.ÞÒ\šTôû!1SéPÔ°Pð«A!Ôëä±WÒî‹3…­»ièê©©Ÿ(ô‘IáówÕϺÞsáN” ú»ô-ÑÔ‘¦
+M>¼ÂZ¿_¸Ó
+(ÜãõçyÚßhæŽë—w“=Fo‹Êºð­$ïe øƒ9>`
+`1sÙoyLCH‡^»]^Q×NIê?ã*YK@k¿m¬eðÁYLw¸º&Š®¾›°$_T*¸Í\ú@Ó­¿Uꎞ•pqâ$Tþ0E% íëtþ¥¬—Å	fp9éMZ’<Ö}Y /‚@ÚQøÅ^ïÀÄ_=ª(€&ñèc
ƒs
+Ô*„¥…Kµà¡%IÆ^òE€!Çzȱ¹À1ªJHf3iÎGU£êÔ/¡UÂðçË<üû—%}ü	¹N!!³òõo_ÚÏ*áã>)öŸŒœ`ýz$—žendstream
 endobj
-1205 0 obj <<
+1223 0 obj <<
 /Type /Page
-/Contents 1206 0 R
-/Resources 1204 0 R
+/Contents 1224 0 R
+/Resources 1222 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
-/Annots [ 1208 0 R 1209 0 R 1210 0 R 1211 0 R 1212 0 R 1213 0 R ]
->> endobj
-1208 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [154.2681 743.8714 203.5396 755.9311]
-/Subtype /Link
-/A << /S /GoTo /D (notify) >>
+/Parent 1221 0 R
+/Annots [ 1226 0 R 1227 0 R 1228 0 R 1229 0 R 1230 0 R ]
 >> endobj
-1209 0 obj <<
+1226 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [80.6033 320.3921 154.2566 329.6075]
+/Rect [80.6033 582.5879 154.2566 591.8032]
 /Subtype /Link
 /A << /S /GoTo /D (statsfile) >>
 >> endobj
-1210 0 obj <<
+1227 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [265.4578 275.0376 326.6578 287.0973]
+/Rect [265.4578 537.6597 326.6578 549.7193]
 /Subtype /Link
 /A << /S /GoTo /D (server_statement_definition_and_usage) >>
 >> endobj
-1211 0 obj <<
+1228 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [367.5441 275.0376 416.2908 287.0973]
+/Rect [367.5441 537.6597 416.2908 549.7193]
 /Subtype /Link
 /A << /S /GoTo /D (incremental_zone_transfers) >>
 >> endobj
-1212 0 obj <<
+1229 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [280.9692 244.2883 342.1692 256.348]
+/Rect [280.9692 507.3368 342.1692 519.3964]
 /Subtype /Link
 /A << /S /GoTo /D (server_statement_definition_and_usage) >>
 >> endobj
-1213 0 obj <<
+1230 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [277.6219 213.539 338.8219 225.5987]
+/Rect [277.6219 477.0138 338.8219 489.0734]
 /Subtype /Link
 /A << /S /GoTo /D (server_statement_definition_and_usage) >>
 >> endobj
-1207 0 obj <<
-/D [1205 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1204 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F62 995 0 R /F47 879 0 R /F14 685 0 R >>
-/XObject << /Im2 984 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1217 0 obj <<
-/Length 3807      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]sÛ6òÝ¿ÂoGÏT<àøè¦N/6Í%ÎôfÚ>ÐeñB‘ªHÚq}÷ )ÑÎåj?X,€Åb¿!uÁ¿º´I™<¾Ìò8L"•\®÷Ñå=Œ}¡gåVS¬oo/þùÚd—y˜§:½¼ÝNÖ²ad­º¼Ýü¼ú×õ»Û›÷W+DA^­’4
-¾}óö;†äüyõóÛ×o¾ÿøþú*‹ƒÛ7?¿eðû›×7ïoÞ¾º¹Z)›(˜¯e…g&¼~óã
·¾ýÓO×ï¯~¿ýáâæÖŸez^<È¿þ]nàØ?\D¡Émrù(Ty®/÷qbÂ$6ÆAê‹ÿöNFiêÿcÃÄêlÚL¨"hÇée–äaj`ø[éº.7p¬<ª¿6ºª¹gЦènWÊížám¿+
o˜Îàu±Þ•À÷8I‚7
úv/£]Õ°nÛtnZÕ	­rX°R*Ì“DÓy†fSvÕ±¸«Ëo®V&2A7¬w8CÍ4Áã®lBg¢Jà¥u°n›uyœöÏiÉ8~äiëŽ)«¶[¿¦`áÁ„ˆV–¨dÑ®<²#=Bźº ¦¦#SSì‹'†ÝÉX±ÙÐ%¦ŽáÛ·›
-ï·”þÝ#M¼ÂKîÝp•(ű¯Ê.Ťip]w-Cƒ*mµaÑHÝÂô®,h:1ú[8îì(¬¬rwV#µ^jQc_9!ƒ‘ǪXw(‰<þ2×x¸=”G/¸dÏ_&
-m×U .?ʦ“!ºª32tðÇPáÜK×з¬ø|Q][Ó¥àqG;c«ê
7I9«Npîä{`
x¨ø®Bò_¦3’ ßŒA7ô4®'9‘ô…
-lœ­ØHÞuz±E(ˆ♞¸YtŸ:nmÛ+Èì¢áïOÿá¯Hvë×Úº­vm×#)`›ó‰iÑÆ„™Í3 )Û¶m(D…kPxš0³ELPj¾PN‚‹»7pßsZöÁá‰	X1ÁRÆó+ûMëxÖ8Ì­2²3:¢@EüÝUíIoÊ~teÙ4—p¢_M{ÜuMÜŽÜ!èJEj:ÌO%Àߢ$º–	|¾(¸†?€+î‰V²^G¡Î”P3£_˜“¤!˜|=gÎòÙ`­(5V]T10|O dSáûXÖ5²A+@}jÚÇF`å™\€‚«îÑN(2¨O²Œ7ÃÐiÚž•Ÿ##S¡"šÄ=DzïÑ4Ñ¡ÝANìOI™‚Q?8Ó‘Ômf…š°"Ó¡±ÚÉIÓ.IBê¼-£lª½NLj­ƒÕïÊ]ñP‘¸g7õiÄ-æíRØÔO:µ®š•f¶ÄŠ¦äfˆ
6
S=²A;6°mAæ‰V4Ý#»%è8½d{n™•Æ˜‘•Øñ÷ˆªéˆ${D66†Îã7žÅ`—ÊŸ‡ÄO¢MØ‹"”'šyàág™à¡*»pÉŒ_÷}¹?ôxB°Q×)ìÒ`WîýйL¨(3c^
-ÚLÅ^…PÞeõ©lx(×ÕöIÄuah:ãx,×ñó"‹›&6ÌàÞçzÈ나[ò­ÌÙ„Õ}Óz
d>ˆYd^–͹8jO"Ö
-u{/ñ‡Å±áX:{°~Å}¹$K^bFlC«¼±%~µ=¶û…X°A¬Ÿ¹•…*UÎ:k&É@㌉ÂÆN	¡ÁƒE	Ó‘Ùn½ 5n9VËXÔä˜5“بÒ$̳=du5)r®ý4P…ˆÒP\Êâ‚-Xq1‰§Æ°D Í õÅœlbjrPS´B8TÉêC'@ ŸH13ÝÿFˆðF‹&7ný%ZÒB]DÐ(Jíi¸sIcô´=ÅBÆ‹”‰‘KøH,€®ß
‹öËÎ9Ÿ‚ýNSìÅ¡x•Dÿä~š•…Š÷PÒÃCq||Ý-d–¬‰^­pþ«“ýœC»+ëöÑû>¡éP~æWlž&Ôm–xŽ¦¢±d»Ž&Ñö¼%ÇZ!æ/F-Ãá±ð!ùÐÛòx,j
-žªÈFà(‹Ck[ÙÖg2Ø!™âÎG·¼"ewù¤”\ÅÜ<ˆOizîÓ*ÎkbC"\lâ% èÇYð¡‚îÓiœ‰ÖÌ3Œ)/0åC æ(epÌdMj¼±<¹"Ÿþ¥‰P¶ÙLgML¬(ÎB@Ay¶ˆûðD^˜SÏ)Ùs›j”míªyΨ®üüÙyw
-&AêV„Üg ˜KLð!é,6¦JÂëVâ’îвS±’wå.‹ˆKÒdf¿c„÷7¯?~¸ù.d8>š¸si™=Lrñ‹"Ȫ7¦jp{136g¼³BÏ{²JS{';Ä?†ÑÚR¤ÕO,žO3‡ž=ÿHÒìdxVx‚x7±X/RaÇËu6ÁYM¸J¤Êl‰³Š~½[í‹Ã¡Ü¬08MžÒ £(Lmœ¿H„G:§bžˆ$ BD3%ãÍ–¥1¶³h)ÔƉòSudanô$Ù4–r
-ò©–m@’oÞ=ÄrH@ÊC³¢»‰eÞ
-­xŠÎH
-@®jm>»ºêÐD
-ÍK·‰´x»] É¶$šT¡H]8*€q<#LÈÀúZ7
XÉ9
-bB@Çw̆º¯öŽЙíP/Ù:ÑŒöNW%nB¢
«føÌÍî	tßQ))eÅèc{üÄ-ÖÎî©ÏŸOå±)kn£â¶xYh‘2wž€˜[·¯ÞÉpÛ4\DY,ì8â8•…¯K‹`#¸Ñ­$DZl‘’rLX¯Ë×РÇjª$Q"=8¯kן(諬&x§,j4i¼ª’8”ð¹yv—KvËÉGš‘,uÜÄ°î¾!q†'`iæ$Zä]p¨¨j€ÖDo
-–ú–]h&É4Ø
gNˆr`[5Û‹uGsÏ‚Ãp<´nå2.Äæëv8BÆ°yÖÖ™T…&ù‚­› =oëî\}fïξpSm±2P‚õ?3y
-ö‰u”½H‹G:'ff¥€š8Ò3b~ñ|fótŽþ×¼hô´
-ãÜøÄ©Ù°%bë6ÊG"¬Û‚¢ˆ„ª†iÊGîcôÆ·šÈHûZ–`¥ÁÁIp𪗅	A,`ÚXŸ¤è!¢ä(óüÔÊJˆÁ;)x€ÉƒþH@‰<‡”¸Ê9ŽL¿{b˜`a´ž·Úƒù¥xÆåD€âÌ&V߸cñø@‡ðÐEªËµï’Ãu!=Ÿ’Îa=;ûr°¡ã!!GêûYõz¨‹ÞÁJÅì3;ò`”aŽ£×TÙO²D´zEÖë99»Ìe…ÄÿžY,%»Ø•ìâ„ØøŽÿ•æjtÜ`[Œpœ8³>®ë]ÑÜ—²Äº
îd}ºœ}Õ÷Ž²ÒðÝ@ÑõL±—}P$:žX,ŸLžŠÄ¼`6‰¥”ó[#QkHø؈Cï|Q/gz"gt[þÞÉ0˜Þ
OÙ¢‘>råwó‰Oµf4z%Bbükª”glw˜}´ZâÃcµ¡œ12Ç Æf|K1'­ôg+ˆL½z÷QVh²/÷-åjпÜ
{ç3Î÷‰}árFœæô<ˆô>…¢ïUReXv~NïÐ’ÞaÃëv¸Ô ¹d¥ýk).PÖw¨Ëžk‰5…P`[l4=N^8=n=×eÚ–²÷× =IfY'lΕqX’Ë9Ÿ	_Pÿ,9ýaŹ%Ž¸ÜJhÈá®j8&'Ž+
-"±)þ厽¹g¡7p’ëyL¿ÛXÊŸ=SSºÉ=Àaý¶=ÇÊ•™PÅÖd¹ÎÈ6²kÝ»œèžø^¥¨tÆkWÂêÃ…z®ë_ŒN”µ´w¿¿g.P?'j…ï‡zóËÿjÆf¡Í´í.‚ìúD
-–µ"R&*Ê¿Èdæ:u»¸'¹9UhÓ$þ“é[‚{Ûsÿ&-T|TJÏFÁʦ¡³ðr<Åz>öXÄ¡î«ÕȇYÜÈâ­}ywµ°ýü͆i©ùþRÂÓáK8©–ß;(1—Ðs@ë©g'¿˜P|†Cízt–nöŠÆifê³>o©Æw¹“ìŒA¾â#¨­<¶âCL¬N“™¹u¡_*à[ózÖ–~f‘çËÕ
°:Ræ(oØÉ[ºÍ¨ºá}ÜO*\ʺ§š,wܳ®ôd©d[n°¿ã\D’ãç#¢ÿ±Í?쀅¹ˆOëÉk°nÕŒLaÇ<þn‘ŠVy8:9¥ÝÄ q´JÖºÜp±þ`¡(dñ÷Ö¾øP'7Ä(Ïë—QaAöö²~M°^Ð/‡ERÑ€4­¥Zr®`y¨•_ÞÞc-ì?;jã˲97„Öß½ýðá涱ÔzÛóÅó¤KÂ0L'ÁÇÆ]³=´¹0'ª…F‰úJñ¿âÅ×òS©Í¹Fƒdm¹_	™›Öa ŒËÓ%ø“%§åw8>uȯ¯8c›¦_q®gåËÂe^¯	ÒóÒå&ÂõPÔÕ†~%u&`iê4Ë_Üß#0?iê873
-œt᳆“.lOH¢~%_'`‰5ÁÛ¶/ü*ÕŽÓܱôLNÈJ³0ÉƧc~MÅ ¦ì¸Ù·Ówñ*2p~í+¸NˆúæõLõK>&>‰EÜïÀJñäàÿë¦ó0²ñß1n®ð•„øãÒ…»üû7¬ã|ã,4Ö>˜(…ÐŒ”…„Çù)åþÇ®ç¤ÿ"‹™‘endstream
-endobj
-1216 0 obj <<
-/Type /Page
-/Contents 1217 0 R
-/Resources 1215 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
->> endobj
-1218 0 obj <<
-/D [1216 0 R /XYZ 85.0394 794.5015 null]
+1225 0 obj <<
+/D [1223 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1215 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R >>
+1222 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F62 1000 0 R /F21 662 0 R /F47 884 0 R /F48 890 0 R /F14 689 0 R /F39 868 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1222 0 obj <<
-/Length 3299      
-/Filter /FlateDecode
->>
-stream
-xÚÍZ[sã¶~ϯð£3³æò"Q⣛Mö¤ífSÇ=—iû µåÄGr-9Ùô×€eÉ–îiÎd&¦@Á @I
$ü©Al…uÚ
‰Xªx0{:“ƒ{èûx¦˜g˜Fm®ï¦gï¯L2pÂYmÓEk®TÈ4Uƒéü—¡ZœÃrxñùæêúãÏ“ñy
§×ŸoÎG:–ëë/©õq2þôi<9©4VËŒo§—ê²<Çw×7ˆâèçȤ“Ë«ËÉåÍÅåùoÓïÏ.§ÍZÚëUÒàB~?ûå79˜Ã²¿?“¸4¼ÀƒÊ9=x:‹b#âȘ@YÝýÔLØêõCûìÅ©ˆud#‰ä÷[Y‰D)`Jb'¬Ñ¦±²V}V\håyQUùl”Ífùºå_×ËM>ß_»‚¡:IÓA[À
W¦¥‡²Jh+UW‘±×à|dŒz5ÎU:U€ ‡Õò¾Èê-Ñ*bzyÈê}Î7ËÅ벸§Ž7ww—ÔîD,@¦9õÎóE¶]±Ðe…Ë~¥-]¸ÂZ	¶UJ¸8Ö^×¢$ÖAze”ÞåuíClÕ ÷Êu½,¦–ôû«ÖÑk^áVyöœó€"{B[`óy»*òMöe•wÇÓ׫앞³ºÎf°æ} 3ZeDâlú¤Z\' ¸pé¿oóÍ몼ßìaãÔ˜zwŒ-µ°‘Ô]Éwë|H€õGâ£~È7ø`H'¢ƒf÷´%ðP=”ÛÕœÚ_râ­êlSçóf–‚Zapr šŒL‡×CÛ0FÅB*ÐÐ6ÉÞJ"îNŒ (¬¬YÔ:?WÃÙGB8F‘)R.•RçóweyÑ´¨V jVŽó¼Î7OË"@ìËëÞkv ¼˜1¥\ì±t&žeu~_‚ÌËØX¤ÆD-Ë,óªÇ0666;:ck¢¢Ó0ns‡qÃ…gùìq„»^ÄCØ]é7„7\=Ò;XÖph³'~ꃅ‰\,ïÒ¶•ìþHáª7ËYÍ=>ÌA×ì!Ûd³}éU^=+æÔ¨^‹:ûJ½¸±~P¾©³%‹—OÔ†²iS0,S‘X»Aò)«H¤±C芷E±ïKî€XM
V]Uà#Ò,_>Ó1`‡O*Ÿè‰Ö"¯_ÊÍ£?éÓÝm;ºÛásæaF
-Ìf¥ŸiÎg†E+âJd×±¶UvðN š’6:}¢‡W0Á!¶	Ix§l ÙJ»„Ùþ(å“àLIë`Bj8˜:¢ÒTè(V<Ç"[®úŽ¤XDN%­#	æîW]cMkµ‚£§gBg Øþ}š¿d›¢O&Ý£¹’ÕK¾©|r$ ë ¯ŒI;ðt⃇Ï`Ë••Ö"ÆS‰ÔÙ0Nû¢¹OæBЂéÔž¸}â#öøïâ#ä/å¦w+œ0Æ%íð8€I®Ž4ØB3Œ½Gh«Á(épëýP[3\xsy•ßg+¢=”UÍŽ=>B ý	æI
-x
-ö
-îHNÖ†‡–µoruAdØ'Y0#w™aªåÉŸÊùrÔuKÍfÅã®{TÑ4ЀC׈³Ê`“¾à¾g[+Eb’ól½^ùØ¡g[Òñ†¡|)|’!›Èè©"ßÑóx<¦­z>ý›TH˜Thg‡×5³¯*xZÐAûnÊÊQ[&CÈeˆŸ@˜| "ÿ©ÏŸÐus÷ŽwŸÇD¡C(¸$. Jœ_€g÷@þʳá’^öúÃI{¨JªØáítÒ+°!/˜ø12Óà}©j6+¥ŒšˆËb¾Ä„e˜³š;j¢ø4	ž3z¤™¡è¨xúUY>n×,aA´Œƒ?ÃËi]òbAœâqJw}3ø0ãÉí¹Ó/$ßÚ}’wn™b(:šCÁ¡¥hôF)Ðæ:žC5\;7{úzP
-8‘Æ2=-80õî–PÐ¥#ù%£L«€Ćü~»h"øZžm*Q¶ÍDLÎèçú–çsNe|} G_èj…~é·áÄc?GŽ¥pÒéo=#AÚg¿T:¡–2é~Z¶.«jÙÏÙjjÌÌ{ŽlÈ#¢4z#Ù€ä5Õ	ÃDÏA
-‡Vœ˜ÿálëƒm„‘Nº7Rÿ6×qØ6\;ؾ,WóY¶9¼
ÑVDR˜zÄwŒfì:ò)÷×&Ú]@;Ð(÷׆1”ƒšt¨¬ ‹Uuþl
-¯§	ÓFFNš”%.Nç:4r"IõÞÓÌ
ìš¿Ùê	‚ ¶#h¿d¯pTüX臇|ž½*¡;ò¸Û6a]óòáw[@ê5¹?Zuðqh´WL”§¬ž=P™êUƒ"uY?<‘ϘGô(JšˆB(ÞÉ…âLâM,‡ë3xÌ(l‘Ïj\šs»*:}¾ÜÌÃ.*ÀÑüS›DØ$„ƒ×ÞœEEÂEÆu3O˜2(êå\ƒhz¬`ßÞ^CW+!·ÔªØu&2ºÏe«-•Œ~0l©º¯q嬱§Ý·ÍuÜ}®û.‹:¿‡Ý}=ô_¨Ëe|Z~`ê‘ßõ_)tjMWÛ|¶õ¨’p=žä	Ùœhˆjí´ô,^õŠº¼ßÃo€öá®q”ŽÝ(Ò úN‡”ºî&çq<ü'»p*ljÓÞª©I­üÅhëà3FSÎäÖIGTÞ+L{ÇEÙ;;å“&(Ž­ûÕ6§2z§È¿.+J6XŒ`USÓ]ö~6Õ8"X‡ŠÊ”òYr‚‹„`.O=Œe±z¥îe1â=r»ˆÂ	w©¨¥­¢T3ñ[ù嶕‹fš¤5MO@ÚV}5œÁR©pûË‘—èg=)Ì(uÜ
-¾þˆØ*R
ñ~FËž½ÃN^?t‡åñK¾*_ˆZ—kf\­Q¤jzvFÁ-£xغT8e\oqãcOˆG"	µ:$/f\+6îícvŒä)ñ_3$¾˜þùÂ?Q"JÕŸòé[‰‘‘N@%¼Y[\'"kàjçó£™/Yö«Ñ"r°„“ò®º¡5PIF]
zoÛˆµébOôß›
7åý’Ù_‹ê4è@ÂŒã9„ÏÁÉOÙ_}öÚxvÌñÃöGŠPTÆ2"µt,ùâfüéòŽ¯q”±Pú¤¦‹ò£P
-¯z eDbµù¶:⨴5ØÞxÙæ:ª†k·aÕæù$ªNËL=ò{0eº
-Á”‰Òoì¢jCʦ)뤀 •˜) ÒE\Ú…Û@Ðyˆ+ 2®šnÂJ,‰|€«Xíòvõ+8´b§Þ¸|hsÀUàjá
-Š]Lø^á¤BI­O‹o¸zäw_á!S8/:
-ü‹ßÚášB~í˜t²¾ˆ“‚êõñ•´Bª5ñˆa=žÌ‡}^IÒŽu·£ÀÜ{襜J¿¥¶8º“*5Ô8¹“m®ã;Ùpù|-ß”£¢Ue6ªëÕaB¯EÅæ´
Wݽ„-Ô6éªÀ{©B
-Zo¡¸ÒÏïP³mý€µdV/ŸùN¶À”ŸÔþ.$yÅ>‰^†z*d—¼ÓéDñé”
-÷š@À(«…Ó‰:‘Õ‡‹óÝ2e¹ÿÚ8¬‰Ó¦
-ªÚƒ¯þ ‹ÖòÛÓ8!ü[ŒëibÕÈkq@^àêAÞh–S~#EC¦rR†«GîK»X$¤3E
-2TÁåüÕÒvPç6Ôˆ
w{˜ÝéüaÒ<Ü°á·;=Ü<…G·öZ;þŒéa¯=!sV‘R{××Uï	kU³µÇ>©–yk÷
vró[LÇ÷>0ù
-k=‡ú‘²þÑcõx˜—@.aÝiñ
Ó¡ü.Ì!}‰eW9:¼Û¿Ïñ»þœÈ?…îÉäîúcEÄE¹‚ò‹o¸œ¿ŠêÏ·ü^å²=!쾿š0ìÎ;~põÖM›óuÛ»ö]cxÑ9ÏÞý2iåâáw?Pêü«”&»'¢.Þq}¸¹ûáò?Ä8™pgI¿Íg)Ô½\„±>7ÖcþJ]Íg<@üÂ3ó5)€8ÍS²
ó=-¼EßUA¸ŠwË0vh»„mÎê¨[/ àqWíâç
-þÛÓZ;'žòKY?PëeI-ËE-“ $f*ÑÀ΂Z|™ÛúòÁëØç{à¡BcbóWŽýP!Æ?cì¿l>ŠûË_Kî>%ð­Fz$Á×I
-E4LÂJ¡ât¥Ú
R€têÿ£„‹endstream
+1234 0 obj <<
+/Length 3759      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ZÝsÛ6÷_á·£g"–$€|t§çÎÕñÙÎ]gÚ>Ð$eñB‘ªHÙqÿúÛÅ.ø%JJÚÆ3¸X`÷· îÁŸI×qx®ãЕž/ÏÓõ™wþ}?œù̳°L‹!×÷gß}ú‚ ²h@M„ç;yÕ’Ž/&ÛY i4{Óz;0š¢z¦~\1ÄãUè\WÉSÙq¶ÆT³Þ´`”¨oøHdßiêuÞk+XÎrWÎQTmæV‹'1
+”Õî5›7@€uƒ ™7P_ëígj‘ÝÔ»Š_Mèçs¾­ò’Úh>ÌM{ƒ-cÒM'@H­Ç«;*Oјš9Ñ-¼À|
ýþQW9µÚmR5`Û¦#`Dòæø…4Í7-™²O{€Tþ%íÁ÷š:ýœ·DÝ5fû±iUͼÔUnvHÒº˜yt–ãUø½‘Â))mt©¡f–7ÅseÔžÖ`ƒ5Z¸"Ó•%S@˜hÆÅQ€×F逈èiõ’_ %Bʆk4Ùö‚Þ2m³Ûnj;N1{*YѤõn›<£ÿ8€x*Ю§¤<ŽxC®Ãˆ×qáäÅ—¥ÙëÅr[¯Y±ÄPƒÜÀðù0Sxú¸8׌<#¨B/Ëó_„ª}äb7ŠáícÐøn‹˜y’*#<"¤jòí‹9 –u’5`D©òWzž†ÎVòÉ÷LëÌš‡ ÓÁNÚÁzMô¢å
ã r£0ÆzŒ!C™SÄ`TH(öˆi^¼ ‚ž„:HŽ˜‡œäLø ÜÀ–Ë`rÌÑ6^
+sÜ1{#$À4ôPæ/yÉí×UaК°ïX$ܞƧÿÍ«ÝH,´=ý'>Ë>;¦ß	éÝ4:Œ]íw'tx¿7”°ÞÎm·ïFJ†§¶[ºZÑ6˜Ç¼ ù¾h(|ϹáƒU隶‡WÍ6åËdW¶céP®&}<–rŽ¥;.³i0k±è·n:‡ÂUQŸ½ãš™~:‡‘«´çççr OWR)ÒÚBãÕT°õVïˆgeâF$™5lJûdÖÒ)¢dUu¹ctÊB»šäxDêªGÌZSl,"W¡?M‰Æàd²_¿Ó€5s"öçk$Xí”*üŠ"IÔIfÐǾ²Ê	‘FžÍc–]RÂå=“ê`³Œgjð–k‹'Z¡+(ûÂnýdöÚõ˜±Ï9°mÎ6ÕbK*N21=	07ò¯]î¯/•>½À0
+íÓÝÖ‡uD«¤aË|´5=¶¾ÎNgªX€´$Hvòzî„Xˆå )€?kuÜ”‡\‡M¹ã2
+Xâ¦\ÞÙ·åØ
ü(<>}Ç53ÿh©2ÄJ¶p]qÐÎûÛ‡‡ë+j7»
Ä-=ÕüÂÙ†^œ:[Ï㮘ˆÑ¦§œOkVd£³ÈZêä¸g‹¿nf:ŠOkaä’¹žòÇò Z¿ŒY䬶h‹„3Aà‚»™ÔÃìf‚®Ò.»ôð-êÂ~GJ}ÃVÖg°a“Néó€ëˆ>[®>¿$e‘%&ÿ˜ê4(B|\„ŽkF†ñr=7A=FBXBw:íTæy^­…r•Ðñ·ªµÔ¾s[·ùÌ€im]ÅžÉOFVÚ•Bû£¥Åx½¡fˤ'^$&ô¼	J‚ïÃ])åâÖÔDx(ÐcwiB¦?ƒÈ±ëEáßȾ€†J\GØr
N‡ò…¤ãÅ–Î\Ÿ]‰äq1:®9ÆõÉØUöHK#«ï1ì—x{ö\%íŽCb"ß½úË7º’€ŽÞüÉ‹¨¶Ò¢¡·;A|˜=Á…YAØI*ù5'i”å!o[®¿SÆ®„2H-
‚tˆPægLV*W{^ðMQÆË®¬ò.c痢­Ù”‰ÍÛ6I?¾#‚”ŽNhâë°&v\( Þ̾ad7U>k<Ÿ¹ãš™ztJdDh£¹ðªy‰;z¨Xtψ˜¤":'¹þ6¸-Ö&[.z¤žs"f§žúìDäu¹l"Bˆ%lt>†\¬!téãp+'ÃôBv÷˜FC{Ã,èÎ}ÁŽT_
+o’Að…ü»îƹšÜ=Û
“Ã
¤–YQ÷Ú–†úì²€K\M_:©—–ÑÀX°yÆBÍÌ®€[D‡îöîÿ@Æ!N¢pŽEx§n‹†\Gtßr™`•§Ÿ¨Í|‚Ÿ˜¼ãš™}&ÁLO	®ãþþOiT,ŒHáj·EÚrTèJWÉ6Iù2«^¾Ã´UÝ´lßØÃå.ª\”D"$à!ú¢°°œ6Khýfßý‡+"Ç2à7m!»„>Oʃ¯ë¬XÌÝ…Ã;+>~Šsº¬?Á÷i´ö»öͦ$ìÐt)´½ÈBýZ”šEFÍ7gð{ùŽº.áQtôÓÏD`MeD BE¾)#§_øb/†`1è&Õ½y\]dØ´´ÂaÓ’Øh¥sÿž¾gÄÿ.‰d\<üÞ>¼£ÆÃÇKnýô37è±ïþBJç?ô°¿I*hã;t#¢®\-©ÿvè¤T30}÷xO÷¾“©‰øºÊ;5
e{͇MÜjUV`ü’¯¬%\ð×^1gÄÛ0 ¬ëÏ»
Ï°ñZã¢'„š‰,3ºÎüæŠÃ~Xp„ws»¸|ÿþÞ½¼¿»ˆ£j†|§¦${!‚]7·ˆK‡?9Ô.œ†â‹ÃžéȇÌÔÛÛúË~.¹~¬ƒ£ÓvLûóŽ3	ð«˜@'¾Â‰éÒµO#¤°ˆLfˆ¿cÝ!~˕Їb‚ó31*ïÈ	ýÜÜñãè3=áǶL!†>@p.ºÂÉ8\–õίö•0ÛG³Tr±†Ü%”cÍÚÔMStÉçKRîòɧ®3®â‰0’'‚
ù\zè¢RH-þ„“›û¨Z€XBÌ©Ž×þò×ý×è!ngtà#WH݃;
+‡(`"y÷eö¾èÿ‹ËÝ”endstream
 endobj
-1221 0 obj <<
+1233 0 obj <<
 /Type /Page
-/Contents 1222 0 R
-/Resources 1220 0 R
+/Contents 1234 0 R
+/Resources 1232 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
+/Parent 1221 0 R
 >> endobj
-1223 0 obj <<
-/D [1221 0 R /XYZ 56.6929 794.5015 null]
+1235 0 obj <<
+/D [1233 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1220 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R >>
+1232 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1226 0 obj <<
-/Length 3218      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZKsã6¾ûWèºj„/¬œ&3ž¬S›IÖã=l%9Ðe±†"‘²ãýõÛnB$EÉ»›r•	6@£Ñ¯AÉErᬈufif„¥]¬vWñâú~¸’̳왖C®ïﯾý¤ÓE&²D%‹ûÍ`.'bçäâ~ýkôáoﹿ¹»^*G‰¸^Ú$Ž¾¿ýü‘(=>üüùÓíÿ¼{šèþöçÏD¾»ùtswóùÃÍõR:+a¼âÎøtû÷jýp÷þ§ŸÞß]ÿ~ÿãÕÍ}ØËp¿2Ö¸‘?®~ý=^¬aÛ?^ÅBgÎ.^à%2ËÔbwe¬ÖhÝSª«/WÿzýÐ9ýYí„u*Q ’s
-´™H´Ò^¸g	ÿ@q;lö/ù~]Ö¸5˜@&ˆ°wa•IýÐûmq½Ôqmü ké"?h6Ú䫲*»WâXå5‘xÈ¡-ÖDéfñyÇ9uW4ñ#SÛ²+–/庠ÞU¾ê…hx…œe*^xD±.öí;x“YD‹¬+4‰º}¾Aâoq¬V¸iܦ”"³–L¬áÀjâ¨*ë¯-5½Ô:‹Š?»b_çQë|WP‹WEsJ³è¶#*©yÕ6Ôzà k­³{¶ªy¡æ‡b_¼úÃ+­Î«ð mÎˬyxÝ0a›?ã­)¿µuIúX!ŸJ£|µ*Ú–Ú^å`Ú‚·5nµèP“&‰1¼”ív8$ª¦ùJ­Ãñx5•Íž¨¨&^%¯__ò×k)e„º2Š-p`LÀÕ¬V‡=hêê•&…ŸÙS·m@•ÞIƒÎðeƒ«cãe[®¶Ôô{Ã)’Ú%ðÚÃF~€9÷e—wå3óçõš릘²{e§Ïëö%L_ó³ãÞ†ÅI$‰El!È%I
-{KÕ|äd¦åë¼ã.Ô9ízº®TRØTf—\3+#†T‰°Â×héû-êXg*jžºÒ;n&£@£Ê®Èk°Í¡¢žrCt2I ¹Ъ²íÆ’¡Ø=uÁÖRm£÷DΫÏØl(îél°àn3غW\¹‡N££Ê„s¼Ä KlÉñ–&†¬•5qÀb“*t)•°ˆh	ïÁ4‘ØÐ
ûuÂ7ÕÒ0¦¡°ô¢TJ-²^h Bi’œ™ÐžëoºžÍv¸¬Ý⡽›‹•ÄåìQjg @TQ¡»¦…ì%¿¤Nj„e¡¼¤¨6p\Fšèvîp”´"UAïÞzf'©I3yG)ŸŠU‰J*Öx™~kd›Ø5@¼Þ¿e÷ǬŒ&5z|Ìã³9ïë±.NÒ7|}ÀuÁ×{®¯£]LÝ]á@Ê‹K÷L3Kœ]ƒhtöáÚ_‚ŽQé½÷*ðµÛ_ˆ¯×”†Ú6ð4ÄòPÐ;Ál‘¹dr:ÐB´!H‚Ù±ˆµœ®LÀÓ(\`ë·ØÆ5¯‹«ÀÌK>TïÙzlêƒÅa¤ýù‹,N`uB«ÌyÖiJSÊÀAlùÍbWS£¾VˆÚôüôx*HÂu³ËKîzÈÛŽÒÂj¤5Õ;4«æa÷žÈG‘¹åQÍ\¦õò&Ú¤}¹^{߆0æÅzNç’°W7ô5"BÒGp¤!ÿýëãîè¤`l‹Ž(Où¾+WÄþ6ÜDíÑõ–ÌmH;EÝßØ}¸ĸ§Îsè(ç2%…—¡×™T¤6îÃKŸZýpßöø409%°?f•‚0ˆ“ ìxÇã÷|1Ø£‹§TÕ»ÎSG׉ÃBB-,ÈšHiЇ©sÿ¸ ÆÝÀçÿr8àÔéOçõNÒ'v*Ë”Pz*dGÔY:è$ô®7Ä8
Å3GàU‰TJ-aL¢†uæ:èã!¯–m—¯¾Ò¾0Ò¾P%~žá@­¹üÀLÑÒ;\A/\ÉÛ;ñZï,H¬ri€Âq²ÙwÔCeˆ^šý×áüÍ¡^Óû®íIU±ãUÐCñÉ%×j›?ôÅL¶>°x}V›øE´â½ííðôäeí¢„	¸}û˳Û3P’ÞC&p<ϵÙÊú<:6Æ
-ÇörÆrϘ˳pŒËöxô£Ì	ˆÖ¤™½,Càšb”;SÀ
IìÆRŒr§6–5ƒåW_CÑ—UðœäQäò]¬GðCý¡à3\ˆca×P¯åCóS{s‚Nj>Ó%JXiܤøÚxCSÀàžd	B¶¥N¯Ê¡Fù¹H¢è@E7@¼,{h}=þÂþÝÁ慨ZJÆL/ušϨžûŽ-óöëá:`ø2z¤7®3 ubçr¼ÄxP}ðs›ãæLœúÍ!…A£êÕÌü-=Ñ”°¥#oO5ã†U¿þÄ.ÁþE¦]Ÿæ-ršM¬PB
áJÔa	DÏ‚SÙŠ÷r¨+< àñB:4ÕQdñÚp¢á×~|ÝËlEQ÷©³Å“ZŸñóU³Û…Jº"ÅAX!ç‚·r™HRó´AF99TÆy´‡¢¼¶]±C@fýå=ŠÑ™^h“	›õzüËမ´}2ï=€h`”BNå	WžÃé/\Œ^–¢ÏZvˆ³ñ
]^VíØ„·x-7t	_In^ûÔÆ~2:oãmw¾üÝCÍ`äåd6ä:ŸÌ—÷a¬– QÂi1.}cõÀ5³ü(p˜ÄMÖ—€J†+8¥|F`j€FH÷2SíÃå K…ø±¹‚¨Äú‚p™f2+¬ô¹[õe¢!ðÚA&žPšdýöCŠcÞP(Y&I:¡Hjé>UŒ:Â=#´F÷Œ)ß1øõèá
‰š¨´~¾
‘°0óÛ—)&ìDQÄäŽi˜ÿŽ—ƒkç>¢<j?&`üˆ‹š?í±ÄdìMƒv£<2Óö€M}ål¯2ÕÉå04ä:†×Ñìéîò$
-Í;i./¸fVG!ùâþhùq:Ú0`Š…ÐÍBú1
-9‚šžØ~%BÓß™ät˜E?¡®þ–t6¨`ZÝD/“ÍX'”LÔ0¨>×9ˆ-±”3—3pÌ£êà9#œ‚¹LöFˆ0 B4†åâ°@¯ÞÔPˆ Õ;z6àýÇxp^	—*c¦ÑG\ÖèXJyXgíx⪷›ÉUËÿë»üÝîôÔØ=ý­2×»§°@Æ°ÄœÉ:²õ·>&£-ÄιùÉNS)¼?;‹a.nö#ÆS-{é@¢ÞøP0D8@iE‚_Œ±ÂÕV“u~à2é9cÝýIÿAVF÷ð_E7'ªIµ²n!zGæ_ü±ß²L× íw{Ô‚'|{»S‹
ìi1ÜV?ór8µßW2
-1PJdêuHÔB©A„»–P`{«ÄÂ!z]®òÕ54zóW¸[F—gƒÏPºÖ4	½ðÕ7—ºøÙÌÍ}Tæ¼%™Øja‰°U³Ê«ºèÚï¸Åw4­ïæ.~µÓƒÛ’qvÈs¿x‚0ˆ?Sšq‘8¤ƒ¿ük¨ãOÅ”—ΩçÑ€ÊÒ^(ÜŽ½p‡p"ú8᣽endstream
+1238 0 obj <<
+/Length 3288      
+/Filter /FlateDecode
+>>
+stream
+xÚÅZÝsã6Ï_á·sfb–¢>ÓÝì^Únºç¤w×iû Xr¬YEJ-9iú×@€ú°eçvz3שh$A£fþ©™
E˜èd%°RÙÙêñLΠïã™bž…gZ¹¾½;û惉f‰HBÎîÖƒ¹b!ãXÍî²_æ¡Ðâfów?Þ|¸þøÓòò<
+æw×?Þœ/´•ó×?\QëãòòÓ§ËåùBÅVÍßýýòóÝÕ’ºBžãÛë›÷DIèsdÒåÕ‡«åÕÍ»«óßî¾;»ºëö2ܯ’7òûÙ/¿ÉYÛþîL
+“Ävö?¤PI¢gg5ÂÆxJyv{önÂA¯:¥¿ÀÆÂê MjK=­d%"¥€'
+ȘôJÖjJÉž•¼Úä«/‹—¢ÌVé6Ûß³Ò¡¤š
'>XÞ3M,oË+£„‰4ZÿnS4 xÌ맶¨+j{Ú®É3l™y[ÅÉKÍu½¥FUW‹6ß>UZ…÷s®âyÖ€	G¼É»IyÅõ©ñTœ@"¢XÇ°M%k5iÍÏ
ìÚ¸ðMËǺi±@û%}=Wó†zú¸áy³+[úíDñÝ°µ´(wÄCt·}øîª,ß6mZeLß0ÃpÇDyLÛÕ¦¨¼hõ¶h7´À¯ÒÊå‡wn‹ÒïÜl;€njëã2RÂÁvèŒðgºÆÅÖùªÅ­%	,Ø€©óϺʛn†œ²|ÒŽáJ€Ëï©6‘#
B¡,¯yÃ<#K
+D˜„yPVšÒꔿ½­@ÓÙ
+öí5tl…Î\ƒ³…Ê&ãC'¥Cˆ(šf—S3¥ÏKº­@Õâ f°g†‘‘CuÚ}‡\ÇÝ·ãêÝ·¨ÚüN÷õЭ0Òž^ß3M¬?ö_)tš±Ÿó-èÖY•œ?±õ«yY§ÑШÕKéXœè
u9¿‡¯7!ì÷&„§ÆQ8úQ`‹›´%ê§Ó—ýBÍo—çÖÎÿÉ.‹0÷\˜¼kUwŽlŒbâÚY±ÑÎœf;,ó¡ñ^RÓ|/á?2E99»“$8¶J´$q°ÆäùEÃCɤad–—ùCÚæÙ”7wŽÚùàf’ºâˆÕ¯.G=X9êª|¥î¢Zð™y'^¥yÃv1úÜQ¹ø
=¨±µ_¿Þµ‹zÝM
¦mN
+ãõa P‘Jpp¶p+ºYƒF3JmAC ÿ¬©æ7·ø8;ìäýC·ß.ïó²~!jÑ‘×DàÍA«WŠT¥@O¯8PŠ3[ÀB‰2{AȯneȈ°µª«$¯V¯Lðîícz`û×i”ä8õqÞˉE#%‚XýA>fž£‘Õ‚–àΰ§#ëëxdí¸úÈúøÇb…*9¬F‹ -œ\¿ãš`Z#®Kp½žÐ\pPF¬•‰è¿73*ÚF^‹;s“ãáÄáCE$Däx™±Ÿ²¿UÝ{¶åøNG
+ŽÊÀ6ˆ¦®£&ò»›ËOW·‚Œ\™PÄ66c+?jJîM˜”Q{§º=ªC¡½iT`&	‚7ŒjÀu¨nÿÛ5¸˜Ív5à:aWžk`WÅ}‰€ߪT	«Ö§—ï¸&ÖÙìUÆp_ŒøzΟRâD#Ô0(h.¨/-›šZª]ü¢ß#ó%d‡úä¨ý‰óä¥cBHåTü5¹ÅÑ“â@„¡y#B¹ŽŸdÇåðZ¾­U½hêtѶå! ×ÂÖœ ãš`|–\'a4ÏRyÚî ¹ÔÏPÓ]»Á\2m‹gT>\ýPþå‡5OFV’óQ`¼ýñ’¿ïòmA½’ƒ²mx»»ˆâà¸G¹ÕC¢#u
+Õ“[÷»È}W±Ãûpà·Ä¨©¤–j–³IøÂÉàDõ×£
KÛøbw±–oD!×	»ó\v·X¥à’Ög¥ˆ,à”“bt\rŒ¶l­ˆ3#AÈúàÁ¹¿J\ai½¡á¯¡¡ö0»37¤£¹½Í6Üéc§36Gáу£Ö‰¢£Fº?jgp¨*P{ö7yþ‰U‡d«zêô•€–yóô¥I½Qr8}ÏåR¬§H‚ý‹/Í—C``"LÞ ãšalë€`¬Ü“ÃŽNøXò*ßÂa»°c¼³B÷ry{ý±!âº.!ã*WâÊ1@ýéó{ªê^
'på	Ã>Ý󃿪m‰ËÝ.†õFwࡤ
+ç(¿&©;ÿþö{‚Ï¿JiÒ"º’ØžëýÍí÷W?ãrÉ5}³œ
+S9uk?Öáh}É_©«ÙÔ»2#â=ÏÌ¥R±š§dæ{R8
Š©\Û—cm¿
Î=­mw¬©fîô?ûŒxªº%j·w .—<å}Ýn¨õRP+äÄ–I3•h gA-.膃Œ2Ny ø©Ðn¾2ïMwŽÒÐ[7RÝC…‚ÿAÒ•Y&fŒÄö}k\‡‡º=b5煋Κ´ WEé.%äX¥‘ïy8R\
+YHïîÀñwJÝ%MüÀÔ¦W)²œz)Ò»žšWHY¦ü…GäÛç|‹¨Í(ïMÙnÅ‚dÛR1lF¯¦Ìª~v%µ@ÎÐa=›T]KÏÝ»r,R]^äZ¼*¾ßDÉüº%*©±uÏ°À¡ðÖïfwl®FƒÍs¸A¯´:¯Âƒ¨0­Œ‡;ëÅÆ&}Χ¶–Œ9O¦]­¨„m'ƒŽÉñp]áVó5	0õ~×ÃKÑl†C¢yY×_¨µ{"§¦Âý€Êu ·bõêž¡®Í80&àªWãx³pÒºš*‚×5Œnzœf%¿¸`½{S¬6{Š9ΨÈ÷Ë£Äaù*«ó}v§ì=ˆV5/ÝôÍŠ–:>zmjÉðôµ9ä:~mv\¨'rÚƒW³²Amíéu=ÓĺÃx!ÆãuùM&ÑÝ£™˜ÒÑètò˜§ø,±Þ•Ôƒáéd@Dò •TaLH>„üñ©í-‚`{Iôç”Êظ8 Ž3/%À‡9²®‹mÓN%щˆãŽëkÖ‘•à¾ŒA[*‡~¼¬CDŒ;Ê8BŸJ@£³ËÓPy88âÛ×Ò0 mhÀZGÔ"Ó…†»ÿÂî%ZhÌÕßZÏÇ6;\ÇÁ8´‹©hB\±í¥ŽÝkd9®×YŽØËUuÛuËžcæ~‚—äåßTЀFç£ qÝ©ÞÐÄù„×;JµDô)_¨§8–¡°\ùäÚ×ÄâãTkãàñ£Õo;-7”“0–ÓóëÏD¼u<5±DTDä·#nn
+´ã_Ê=|°¥h0Z™¢£QÌÀ>iT¼îšÀ"?¤“{ïz‹ÓK[€Hdˆç‰.,Ǻ©Aô$0€
®$iÆÃØUW¨¯‡]X5rméÝb±ÊI˜ÕiÁ]÷iS¸•aðЭFZÓÞÓ ñPÖ÷î™zä£ðÜð¨zÊ㼡qi[dUOºãBú‹ø<§p
;u‡ü‡!–U_]nÀŸÏ1øîˆNj	_•5ó§tÛ«"A÷›6ÜEEý¿í“øÆ.èb.¿@ç!>¢Í/ä‡SN ôHDà"þšàËÕ
Ç ñÆoRZ„AâkÒ÷9ƒH	RÀ¿ÝCƒ½0¾ðH¥,/< 9(€*Aç4°*A¦¾íÃŒËÏwì‹ÿ¡ËÌê<~XƒÂC›i’Då`öƒ¸Ó1½!Ãþ\Gs ᢨñ9æ@†s ÷»´\4mꊺ°[FÙo&DÃÆpêwYC¿»Ôp„g3`'^ë܉eJoæþEª©·-õP
+‰f½ý2œ¿ÞÑS}8:çzf}_æ¼
+ú&~9ÝZmÒ{Ÿ¨ÁdÙŽÅó7ÚžG”Vœ£¥ížžœL#.­víëÏÏÁØ’zß؃Êú3‹O%´	dÌ7œ±ÿmÂnäÌ©¿üwný‚ƒ›8>rñé(†‹&a¡PUVÞó> endobj
-1229 0 obj <<
+1241 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [367.5469 543.9652 428.747 555.8654]
+/Rect [339.2005 130.8727 400.4005 142.7729]
 /Subtype /Link
 /A << /S /GoTo /D (zone_statement_grammar) >>
 >> endobj
-1232 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [483.4431 345.7585 539.579 357.8182]
-/Subtype /Link
-/A << /S /GoTo /D (address_match_lists) >>
->> endobj
-1227 0 obj <<
-/D [1225 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-354 0 obj <<
-/D [1225 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1228 0 obj <<
-/D [1225 0 R /XYZ 85.0394 749.7875 null]
+1239 0 obj <<
+/D [1237 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 358 0 obj <<
-/D [1225 0 R /XYZ 85.0394 528.8451 null]
+/D [1237 0 R /XYZ 56.6929 359.8888 null]
 >> endobj
-1230 0 obj <<
-/D [1225 0 R /XYZ 85.0394 505.7912 null]
+1240 0 obj <<
+/D [1237 0 R /XYZ 56.6929 335.1068 null]
 >> endobj
 362 0 obj <<
-/D [1225 0 R /XYZ 85.0394 390.6092 null]
+/D [1237 0 R /XYZ 56.6929 117.5003 null]
 >> endobj
-1231 0 obj <<
-/D [1225 0 R /XYZ 85.0394 367.7147 null]
+1242 0 obj <<
+/D [1237 0 R /XYZ 56.6929 95.0296 null]
 >> endobj
-1224 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F63 998 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
+1236 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1236 0 obj <<
-/Length 3335      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ6òÝ¿B÷tòŒ…ÀéSš:­o®iêøæÚ>Pi"‘ªHÙÕÝÜ¿],~ˆ’ÓiãÉ\,‹Å~“|’ÀŸ¤šéLd“)–&<,v7ÉäÌ}wÃ=Î, ͺXß<Ý|õNšIÆ2-ôäiÕ¡eYb-Ÿ<-žj&Ø-PH¦o|ÿîá»=¾¹5júôðãûÛ™H“黇ÞÓè»Ç7?üðæñvÆmʧo¿óáéþ‘¦´§ñÍÃûo	’ÑÏ¢÷ïîïß¿½¿ýõé7÷Oñ,ÝóòDâA~»ùù×d²„cÿã&a2³éäƳLLv7*•,URÈöæãÍO‘`gÖ-“ŸJ-K…Ò IÉ„Ôr\ÊœÎÉ(΄NE”²àcRX(å|»­^f‡bq<Ô›ªžš¸£ÒI—ôk„Ùá€KÉ’4°ðq_,6¿$‰(êÛ™Ôvú²Þ,Ö4\Wuã¡ùá–ÛiáíbIME¿»ü³Ÿ&Tw¦gúíX6a‡fí0ªã§ulüT]ž‹*hŽÖéôa…BÈe®R¸ç,K/s £@Á•±!>î)Ÿ–Uƒ›7iÖE9²­VLXîWÓnx®Ól‘/ÖÅÈ~¬(Íø`¿c¢Ã
7+‚ÀÆw82Ó
-¶>¼lêbd{žhÆe"ÎÙT7QéÕ­aÑd&­e6Ix%Y¿g,²eÈ=Â
–Å*?nzø%I“1†¹ãÊ3±­ù¶,šúkZåžQž²¥ÃYaN‹ÜIàOÂμ„7Em
K$ºj¯]¬Ëö±Z™÷˼)ÎŒ•b¢ÕõÝ#ÖÈö=cpÖ˜þþ=cI4V‘˜`¬Æꂱ"+ëã|·ihüí©Ìw›!|ûþ#Aé5AWÕ »¼n
-?þOU5˜©Èôô‰ô|&øSkE_ZeÑ™×Å„XçeQžÒn	àùˆMÁ!ìNÉÐYdÓ÷US´YçMD¬^6å'‚·ajž“ö¼ñ°öH``LuƒGÿów¿êáƒ;X2ð5Ë%-©ë¾^nÊ›óz^çºbSfЗh-ÂEš<|šÐ౫5Ö]0¢5gtÖ‹fãŽÜ&‡Ü)˜²€Ü%~¦¹ë„T,3h9]HƒœãhòͶ¾l»°sH×m·ƒuÅvÖÐvgÀÎK~X¢¢¯Æp\#¯3±F8é]ˆÑÌØî±ÎÍXËhÆ0fÃÖŒñ!š1<íÈÖŒaÜš1>83†AǦ:˶ù³·×,eÜ
-Þ×ngÙx]~I*¦ó‚žIpÈ×Ò1S„"ClÁIP—Ü8ïàf:QC¢É8¿¯lW{„f	WÒ;þÿB$¢K´&þo,ØIÉkXsGäƒL‘¡"/kÏ,y
-–žmïÍÝ,j)mF²&c–‹´/œp|r2ÊL_6Î9)KBȾ8¥F¨™L²éÓm&¦áe>ßz¼¸µ2]Áå;B®QQV§19eœñTô“Qå†s®ì;e/Ú¼<É~ýªh1‡ÿ#±å$ e2}ηG—ÜIŸ0Ðd]Ž°Îeùª°ìŠ
Ö&á¸pM#tÓ:fwçÇ£
-‚´ª“%!ßÇúò<Ñâ:– Í{
-GËãÂ+‡ä ‰ÅAW9ÈxïðÒÁÈ6åï6–:àcƾ*ëÍ|³Ý4'B ïQ#˜/^`¼÷
y)1±%X½®ŽÛ%=ᆨ¼lšõ`ç¸qaL²=«”{ô‘hçü¹l7e™ÔÆÍP–ÊzÃ’AÃI7@¯GÃq_Ù=¬È›c¬2€s"DNËAüÜx—Ÿü¶¿ï«º@:m‹\‹vÛ’"»l·<â4ÀýžþUà\¸°Õ¦ìÜVêÓDjš|ñ¹¾œH“ ×™¤J0“ˆW2ƒ€=ë Ÿ‡¡!Í/É
-dª©Ö=FÎKä€t}%(=uÖc ¦»ª+éׄì\‚Oºž t±.'«õ¡ÏzVŸJÐÚšâS/7€Â9K„¹ÎCÄa¢—(ͬU}&žÖ”§Ójï¯Æ/¹jPÌ&:"*åR/G±Ã ÞU•ó<@ìÛRº—W§Ó7ðÏãU¢é7/—ƒÎíéj`¥úvô‹ªÜÌ)®Á’m>/¶5Bé™h›é|Sæ‡S¤Í¦ßCjÓº$a[ï	˜síyÓ·1‚4~)¢FáöXÎ;üe±÷Í	pEË»1Ÿ@½çö­}Рùnë*èi—–ËtÀM4ýr ¬^<àSéµÜ;ï£ÑT»"ìr(£/Ú/É?—
ÛS\qݺX—
!bµ†àgUΛRàK,O¯ï±Fè×¹)³zÈA/AV"
É}‚¬„nd„ÇPãð×ßPáQÀÔÖ£øóyZ­]¸ÉµÇê6¤Î;2M™ÆÆj7óùAÉ£†¥¯]¡žùhÌ´2OÊ…5!³ p0rÙ%üÖQ8KlJúmÖ£m#e˜’¡äp¾; e 0©n@§wEéº@ŠÇBN
ÃEîzB
-T»!H‚:l–®r¸Ì±L¤6HŒl¬G툋GÃõ_–5<@°ËU°Go !Þ]kmCŽáyô V4ð­ŠKÖ›€Ä!¼b½¬+Ö°ðèó-äëj{ÞtH8KëêÖkdo9èFª,lÞï&á’7øÙn07ÅQµòm"p}
-éF
b¦'„¯³pänÑŒkïÇm‹Zkv{z
-G—
-ªjà9¨¶ÏE`—*&Ål¦QŽZ­œó©WªŸÂŽxÛ¸JÊZ¦ƒƒ’ï:õqî±Û
-a"ESùýž.ièy-$Á”IB1T^6z|›Š»‘N»Ä¶5 R±Ô$6¾Âæî-¨”VX!­rÈ~G6ø
->>5™ò	Ž«HЧÄE®B¡ ûêà: Õz&B!ãFàØËÑ-®_4*>t®ÅUA'Ï}YÔ÷¥vÈ)»Íǘ‚º§±³ŽŠ]”³Ñ×
³ˆÛÓ#òy£áÂ$µ_@ZI¦mpvMþ™ªor _Ú#ßR
‹ÅR/å$eéÈʬWš[à3–Ù¨ºXÑ+(SË- Æ¥êKÞÆ	–YkÇßÅÍ"ÁY‡"½¨ìr'GÔq_
-”
„¤!‡©ÀzCþu‚¯pù€{íÒåÐù¾×oúAÖןjŽ#R	Å%].Æ
-™B0¡‡íªž™…\Ëü4ˆ}gå-‰—Þ×ÀæƒpšÓê×0ï½g[äTÝað‚ñíΠÝðx½Í~;j—	ƒQö%¶#˜51ÑŠ™BO·õÂò§~
-Öâ÷|\ÜXÐÌJ–¢
{¶ù€׊ò½)È™a¶×~–#ƒ•$<AZ§zÔþÆÁ)K¦<9xúŠëk­=ØI‚!áûštéÆ¥	
$–ù΃¢(U•2\*@Ü¥šÐÒ@¤àZ(0Ó×1\Brp¯@³PÜѦ3#¬Z$//ФÅêRGk—/Ö›²Ý¯´…WL]°‹ü’b{iii›lŽè)©ÍÔVÓ°ÿ•¼5ÞKϤ‚Ë趷ÎM0ÌÄäµu,þßêôôúi<ÇÏX¢ÕÙgÏz¬9,—ªWøºÂ—þ¥µò)v¨€V'\‡:¤ëédP¤ˆY(`ø…Šæ–O‹ëÒŠ²Ä¢Ç÷÷;²èŠzГ™õ5ƽî¢ÚÅRþ·n¢Xƒ¯	^.b<|xÖcªôïø%BÏË$ýkø¢^÷`ÍÆ¿Úíg@ø¾ØOÄô§·³1Pðªìz‚àÞzAæ8á˜)®ÿtüg]’瘛Œ°ûvç‹9‚à	\ò¿ŽÉHñ&‡‰„g}&/¥	)æ:ä„þE¼¹œ‚?×m©ÿºåA
-lz–‡>…ko¨Á@1–Uø€œ €æ·˜ÇÅ	KöùÁ1Á—ëL‰¶Ž÷ß—T‹ÏÎÙJë\wN­ëŒFѤé±ïå¥×Ui|"²(­SžØÊo¸öäª}Œ’
Âc}qíh¼Î=¢¤Ï”püæÃÇ<î	,>ìeá–¾Ž‰V¶ 7KˆA_ÿdļu¯ð­aMP'€>¾{K©2Ù½¹T	üF•Î\ÂIr ¬ ‘:Ô´”âc¢s—_ðwË…;óÊ·n¿Œ^$$¢(
~káP*ž½#$PG'ÁÂD¬ƒöDéϲ4ŠM»ç¼XçÏèÌÝ2ëã‡MÚ#Ö”Â(¼â¾õ¢}|5ÚÃ.}Œ(S†_ŽtQà¿ØŸþP±ýŠSú´fü«c™²@Ä3…çIÅyó)ÁÅëÿƒ”îendstream
+1246 0 obj <<
+/Length 3455      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZKsã6¾ûWè¹jÈà
²ršÌx§6άÇ{Jr %ÚbE"Q²×»µÿ}»ÑR”<»W@ 4šÝ_?@>cðÇg…Ι,ÕÌ–*׌ëÙbsÁf0öÃ÷4Y ÊRªïï.¾ý$í¬ÌK#Ììî!Y«ÈYQðÙÝò×ù‡ß¾»º½Ì„fs“_fÚ°ù÷×7©§¤Ÿ¿Ü|ºþá·ï/­šß]ÿrCÝ·WŸ®n¯n>\]f¼Ðæ¿Â‰	Ÿ®ÿvE­nßÿüóûÛËßï~º¸º‹gIÏ˙ăüyñëïl¶„cÿtÁrYzö,çe)f›¥e®•”¡g}ñåâïqÁdÔM’ŸÒE®…2³ˆ…±fZÊ,g¤–YÅs!e¥,ø””Jy¹¯ÖY¿«d}½}®·ýøàÜØ\ÙRÏÒÕxˆTLÈ„	nE®+†\|yªÍoŒ‰º¿Ì¤ÒóU×ï°eæmµ	Ý–~«år{É‹yÝ÷4dæÝ
mªÅªiÄ—f·¢ñj±jêÝuÔwßѨž_~V~évIƒÐeP³Ìˆ\sUÀy^jMʹÛVmÿÔmw=¨•)°Å¼ÂŸÒñœSgÓSﾯ—ï.3Åù|·òc$ußìÝ©¡÷¾¦žê~íé×ÐãOÞ­ŸÃÀÊÓ†ýpŸ¦½äóGzêÚõ+µÏÄÂaÄð0`…˜7þwUáá³îpØã¶Â†³§ïéU	[rîôÉU”gµ‡ù°ÿH/ÁèòRØ:­‘#5]šK?eU={^ÚŽ~ëÓC½ðgÙ·k|ÿî…Jir^ ª¦B‚€²ÆßÊ?&òG5îkw0h-›ßÔ’ž:ßKâ‚Æ¢Ûlœfáڭߘfuþ˜Oɤ(sc™õÄWë§gjB`K¶ÜSú|jÑLj“KÃ¥‚åµräˆÜä`œ16ŸâC×î¶ÝzbGP!¡s#´tkÄIJô”Wqì*ŽíEÕÒè½ôú¼Û6‹;#ôÝW=59ÉR‰Ãbןi @H(¹_ùÏ=,Þ´ž•×~Wo@­%¨õ—ºƒ*T®d)gFZkÅhpû8£Æm
+Ð>K'ÃÞñºö@?›pBPÊœùÑ@!쀟#ðTop<€‘2çû€‰„U§Äõ®jÖýP‡WÝËÐ&z„ê‡Wzp/
eð2œ’÷cê•a"·ºäç½YJuÚ›E*gÄëu÷’µÝ9û10UØ7vTÛü˜‹1Åhÿ‚Ï_VÍb…Má\‚ï­HXÔïxvê#NÊðëàv«ÆÏó†B«° €¢_ú.g@û¯®õ,VUûjZ¿ërÙ8Ý#H4f5rèqŠà` AKbkSmû)®´¥G¢ñû	Ñ@èÃ¥öÄ›ê•V¯Ö½ßúÞï×G¹.©x;æK‘3a-ìø>ÞðKéH¡nwè A@aÿ±¹Xòò¼´%·Ã  qÎ^Ò¶Yº(wàŠ'Ù„PÈš2¿{Â÷áç¼!827ÆŽYÇXÄB8ãùhüb!¿]W-`áÃ~ÏœlßíG?N‘¨‰Bë=P°CÇç=¶C}I^Ò»‘\ÖÕ~íýg3ò²Oκƒ×‰ÊmþúŠ´×¡ÒÚ÷?ФÍÀQ#ÏßxRRQ´•“0¤Qí{†RªÓ0©jžg;B óWç7T»QHƒCàl?D¡ƒCPQÍ,¢ôP¨ XÓuöPGçH—M[m_ièãÍ"ÿ
+Š;Æ”§™Úä2:ä:‚‘¢h@VW¶0·jç	xÍŒÀuð;…€µTùD(¨ˆf)Dˆ‚Å
‚x¡é ‚vßÑoÖÀƒÓüpP8+”£Î8/71çü¼Ì$ê±"•èÉÒ¯þخ㌚È^udžëuˆ&¦ÂÎà0Ä
+DÙ¿þšÜuE1[Ctjyn”Q§×¢yÖòÍ0c¸T¸ƒL¨„ŒUL1*"¼@Žñ°²3©°Ñœ´ó&yaÚ(î(Y®¥oúY>¿ƒÿÅüêH4°¨º˜)!!
µ7Ÿý9ãàßÊRUÒv§=HÁu|{½³œi–+¬œ¥K»s™Ä@.Q°+	lƒFK¾äa;­ÄÌaþš-ªÅ%4‚zƒ)'æVb±#·S#È][Z„öôû\±&fÖ!ÅHHI-ºæ4a­#åR%¼
	GJ_ß_ÓYÀ’%ƒ ÿPºùkú
+yrŽƒD“g<n¯°„bÏ;¤H5ÞŒDuTä¢ÔÉ´é"§šàaX䲟˜ydŽ±éÝ6£[rÁ-II ƒõζýÖÜÃrð‰‚Vh¸ãbíOK„½cà•’beô±ÊBpÄÖŽ¢(ƱË(rÅT‘(ºÔ:¹F_û†«ŠsØ¡ÆÏÛz±ßö>Xmg(NYŽ¶#SÂVó÷}Gõ¢vÞ¾4ý¤h’Úª¯õ×…fêk¶Æ†LŠ0G…	ˆwDìC/u8·«ÍµÝwS9„»b<åhiOh¸0^™¨kÐÂøqâÎ'ȱ…p`j30SFP›næËz '‰p©Ôè´¶N{±î3™µ@»aõu·¨Öm½ë¿ƒY¥¤g´“)Æ€y!b* šÔøš—â*…é02~2:–â1Åíùè8¥:Fê„R HCf-ÞØ?Mì?"Ù<ƒ®C 2‡šˆL»‡DÆ×b
¦Áøa"u'zö]1r3V„NûÇUèhüÐ!©ÇtËèi”ÊÀ
+
nl`!_…¬Pvàw¹û¬·Mì9G¨6|OÁ_arÕá~Áµ(`á‘°ö<6sɾ:`JŸÝ:¦c£4Â3„IæÁ†O§l˜cÆÕ„
»²Ø9vlÅü‡l8¹ÏZ«0TyÞZSªÓÖ©2ß?-!¯8Nf!†Ô¢<¿{¤šØ~i‚ó‘J÷&³ìÌ2“Y–&³,1V$r±"töûûKÊ ýñµ­6Í‚(•…^:dO½Te¡ÖEmLñRD”f~ç/S2—«#h=(xÒEŸ5Áó²n_©ç°%t'I“
I“)CÒäüËM·«©w·ªv‘°{¡
+7ôV„¡PHGÏÔzV~¤<ŽGüùÆϺþ<¼%òX3®ñ½lÚÈy=ï+ë<³JCNÍ°DmÞ¨¬Gú,p¬5Çë+ëÀÍå7¼½(쀛#ÍToñ
++9ZNÊø°~Úv!3±\½Q‡J©ÎØn Ûnì¼TÛ%*ÊX’eŠóŒDª	NÂ`:ç"=ֱ͚ÁŒ¡y0c|ˆfd;ò`ÆÐ>˜1>83†FbSÉ4WÙtöŠõ’BŒàßY6¾.?âVWX‚gœ+€Ñ%œ¿âBÒ•§I«“X‡n$ñ!ûöä‰À„ÉW!îû7DŒùÔ5ÿ3åìdnËXX{GË™"CuåªG.Ó¨üö­gÛ£¹} ÚžÏu„…D”=4ýp|fç/'Uøk<;ª·°Ò=T&Y9¿»,ż#šº¥kl¤‹[+›
+V~GÄ!çŸSÉs®…“Êù´§¼d/Úª}
’ýî¤hÃ6.u䤿¯N˜‹>Wë=å±>`ð)êªj'XÇОYaÿ·Wl±bø€×4±®ÈQ£e“ãM­
+‚°*Ma$Æ{ç+=,º}ÚìëòËý"$Â$#±6¸&jÜÝ“d`dM»Àw[Ë(ãýîS×öÍ}³nv¯D@èQ# 3Öx ½èð†1±¦¾~Õí×Kj‡‹cZ…>õì7NLoÎUŠ€=ù„·sxAí†
+¬éÐ]7ù`©
+oY2¨8)(¶OûŠx6lµÝ÷ÕÕnÓè \—>#…Â}ŒJ¾Q…¿)ÃmÿùÔõuè¤ãˆû©=h·5irzÓ›ºñ7nwCXcÉ×üZ ¾®´J¼ÃÏ9úÓÁ,K0×BCü\æº?Dú,pì‹Ž×ýšà@AÀZr°Ötñão³Õ<(…!)‡<Äà`Ó¥"+T(°†ÉåùH!!:(¢”>›¬mAwûæø#0Ë .Ï3‰Ž9V5Œ2=`áŽ.¹­ö7Ô~qŸÚXʹ‹hDùœö"´:Tõ¼ßtî›.׉í4a)3®õü=üótï1ôKßé¤è+0à¹P£o†~BµÍ=97˜²®îëu½ôLkÛù}¸8‹4è%‹rþ#Ä7É~q€P¾OÃñfoSRû¥ŽÊ„ÛÓ‡W@¿¬Ÿ|…àhùn
+ðüWOëx	ß:Ñ<©hº–w˜»rNs‚6Ü
+5­Wp¨ºMvÙ¶Âo~êL©sülrBY¼ùË_g>]U–Ò»i€a2„Ò¦P’ZžüŠç˜õÿ¦åºÔendstream
 endobj
-1235 0 obj <<
+1245 0 obj <<
 /Type /Page
-/Contents 1236 0 R
-/Resources 1234 0 R
+/Contents 1246 0 R
+/Resources 1244 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
-/Annots [ 1238 0 R 1239 0 R ]
+/Parent 1221 0 R
+/Annots [ 1249 0 R 1250 0 R 1251 0 R ]
 >> endobj
-1238 0 obj <<
+1249 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [483.4431 641.2621 539.579 653.3217]
+/Subtype /Link
+/A << /S /GoTo /D (address_match_lists) >>
+>> endobj
+1250 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [184.7318 660.5919 233.4785 671.3763]
+/Rect [213.0783 237.5372 261.825 248.3216]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_security) >>
 >> endobj
-1239 0 obj <<
+1251 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [369.8158 538.8963 418.5625 550.9559]
+/Rect [398.1622 115.7791 446.9089 127.8388]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_security) >>
 >> endobj
-1237 0 obj <<
-/D [1235 0 R /XYZ 56.6929 794.5015 null]
+1247 0 obj <<
+/D [1245 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 366 0 obj <<
-/D [1235 0 R /XYZ 56.6929 372.9462 null]
+/D [1245 0 R /XYZ 85.0394 686.2819 null]
 >> endobj
-1240 0 obj <<
-/D [1235 0 R /XYZ 56.6929 349.997 null]
+1248 0 obj <<
+/D [1245 0 R /XYZ 85.0394 663.2868 null]
 >> endobj
-1234 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R >>
+1244 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F63 1003 0 R /F62 1000 0 R /F48 890 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1244 0 obj <<
-/Length 3002      
+1255 0 obj <<
+/Length 2533      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ZKsÛF¾ëWpO¡¶óÂÃ>)¶ìUj­8Z¥j·’@Q†Ek·ö¿o÷t@#[v¶tÀ°çÕÓÓ¯{$fü‰YjÂHez–d:4‘0³åö,šÝAß»3Ác7(Žúáöìû·*™eaËxv»¬•†QšŠÙíê×ùë¿]|¸½¼9¤‰æqx˜8šÿpuý†(}^ÿtýöêÝ/7牞ß^ýtMä›Ë·—7—ׯ/Ï‘ó%¯ðÄ„·W¿¤Ö»›‹÷ï/nοýñìò¶?Ëð¼"Rx?Î~ý=š­àØ?žE¡ÊR3;Â(Y&gÛ3mTh´RŽRýãìç~ÁA¯ê“ŸQihR™x(•O€&c](À‹ó@	9¯Ê¶Ã–˜7k¢ìò}W.U¾§ßWîc‘¯Vûs‘΋¶-Zê\æ55òªmhÔ¢ J»+–åoQ$‹Õ Èd^òØã¦\nÜü¶ iÝÆÍ+ö÷ÅþÄ]Q·Ì ÛÊNó®À«yB„™1Ò®m–‹ŽnlÝì©Qä¸+¶¬ap²D¡Ÿw¹ý®*è :J	¿ÇMóÊ–wl¬Š¶¤™¼ðŇ+j”<¿=ìv;sý‹‡É
-íœxö‡JC'¤òïUWî*{`¸a1¸a…ÐÊ`$©MÀÍÑà¡:˜8LD?¸ÙueS3wö:-_ÌΡ-V!Êl —ã§|l¼ ¥U6X:È’Pi•:ƳÄQ4ÿ}òúáµþûÊw‹'¢è¨%¤Ò£Åþ"£H¼\-Ò—/¿Wò•‡‰$`?ö%%íw,«
-ΙyQç‹
-õ1Ò¬˜@¬ó-“zªÕJ kH1Š(Vñ\PƒM	ú¦¦¿E&:–݆±-ë;Ç°·Z²Br¯Us˜(Ѐž×«ž+@‰G‘ŸÈ´Uh¤oØšð†ƒºMÎK¦Ô#ÔôµbžMFóúD]£›!Òé°8¥7eÛG§â}¬‘JÖ‹­mÞ-7`@žXQ,c3²CnÏ39oH“·ùÇbj|µØ¶gÄ)";þÚKÅ	ÎïEÀ|ÖÍq26¯Û#bCsrúùÇ¡hQŒh§	
/‡ ³8¥¡À‚Tv9=^a@h%0î¾ìJAÛöËÂsà >Ž˜ý¢;Šc>UgÅ€Y;ÎÕõÅ›7 ±‰2@§"™éLìLŸŠe˜¥iê‡ÄA¿b0\’ðî=#$:sÚÙÞëy„
-~1Îtr’*ÅŒ@›(”Ò¤c+99´1@ò 5¯¶€×ÒiÌ›Yóñp$Â$SŸÓ…QÖûg¿ª¨,N‰Q)²””"ËJaA=uîÁª›-
؃BÓÆõa»(x…µÕ7Œgr¼–MþãîpÀ0Ö½+ÆûïJˆï+¢v¼VÍ–0ßDfÊÄcC&‡cy¢ã%Þ‰|©€ÃåB"5¿Ý0;>VB|¡z·l==ƒ	£¤ŒR»!>o#Á{¨4vvL÷:8¬vnìóijÌ£^»ë÷§o‰Ðã
cÈ죆ûÅ‹MFñã±þ~Žs$µ™²¢¤°ž˜X°á2Ô•A6°¬+€©ÔIaæX·D‰;m&È£=b4ÇSí<¿oÊÕ—™A¤µ“¼_Z ‘(Î’ñ²½¼Àª2©ÌW¬LöåQ£ôÏÝ•÷Eå´‘vây#TzÊ ×9äy“lÓ/§T‡‰âyq?·¥Ÿ•ÈBeíYïÉXitìË#)º/})¢ÔŽ-ÍØ]Ž¸§ÜíLg1š¯À)4\Rïøfî¶αÎd¦i’yf™0K’x8‰2Ð@$*œ*ÁTÙÓ*Ô±ä}ôSÜéÏq§ŸàNŸ¸›"9‘‰PÚúÏ$
ð#RñU~	ttA<Ú"C)’lì{ž¿¦u¶)@Çz”Lx|\<ô©ˆˆW>€¥ÂTÅN¿9ŠÀò).?b3ž—k"QªfWl´®û©ôB]Ôö
 dSµ¸/WÖÁ)c¨r©os·Ï·[òˆ
-d@¦à×9j6Rln_2’n_Bwqï:7Ü°ì@Ïö;Þ„]Ï÷ŠÓèyjh»M±E¬<Ï+¢ØÛ°ÕMMÙ
ðÉØŸÔ	È‘eæW&š®
-²–ü>/+,Œø®)Ã,*6_¾¦D¦z|M°&Êvº ,›½s¢MMñûûK‚!½@°ÃÆ›Wx{	ePDz-Ч‘M·pŒg¿’TÎæ¨"=I‹šc=öË/¿œÏ?2¯aNÏxÈ–° ÜR+6F™'JaÂo^ß°æSÕ‚Ç×Mþ`CÌe% (}Ú¥®–žb;´LkkŠv¼,!›«ˆ^Q,¸ã¹(ã‹åa_v'œ–j[“†.¬¢¢Å¸.ÿ]¸¾]Q¯xoª½¥óû|_6&îòÀ'A°É´Úh-æ‹êà—#*‚Bkð²d:÷²ÙnMaDÉ3èv¹‚ðÃ"E謊¼å~)‡¦&ß@@%˜¼(‰šQ€‡^ùŽÝ-Ì8£ØÞ	ocËëزàÔSú"ÃΡÓ÷<°èr`èǭ‘¡´À{ Î/Õ5
Úmn-Gp‚´ncýv‡ý®!c“Š¡¼èa´ˆO¼
àÍbô|u¿­ç`Ë
N²kj|:ðÀ1Hh%¾ì}„L†–ÜŸCR×àaÐ{Èž[=¯‹#ql[ªYÑüÐ5[ˆ KÖºà¹ùnW•'®‹Ú›.úÌ·1êY5ùÊ¥ŸŽTÆ'ÆjÕ1âné[ÔKÀ1ùCâ6Áw’½ù⽂ee"¿
-DÄq“O3˜ç/Z|1/Kò6pŒ–CºG­G	‰pø”§@>™$“‚˜ÇŸÙæÉŸQír5‚¼CøŸ·
¾#ðIJ&ße+]öaê”M¨ŽOW]?5§W'«bËÜÂno	‚]zy&ÿ„y€±Š§‹Ï©Î‹Äc_oóèA‡ÂÄ—ÔV"ˆuðŒ¬¥Õ­écƒñÒ¦\”QH
-UΉá5}Ûfˇh  j"‡RØ •22c[øåúêŸhâ’}dK?@‹ªÔ_3«æèż)œ½Ï×?c²2Š“ÑÙk‚0v¿nÓÜNô!A¸íwûòüœÕ1ð¨h£H&ЂýV É/“6—¶wÐB`#ˆ 7<0">Â9*#?YÓ0'=V_É=ù
-ÃY»{Â$¯×6ÈQÑájÙo±r…|æé¨Ë>5Á½%ÃT,)huZ߃'ÓòîqÇ.òë,èÜú‚*¼>¥Úå"~–FTC]Mu Cp3Ù%¶DqøeUTù¼Hò´¸ìkÖ1O ªÜâQóšG[ÿß©ÿ®„%‡»¯ä8ï8…9t}o¹m¾.œ3:9–²žøp©öÞØßý…í®ï鉻©u^Çó¨f<«è“BSɯ¨iô5Ÿg¯úü²FªÀáMËžcr÷Ã|Ãá¾ÿ8Q&ÄñüHÔWþô£œþU‹Wi*ýÿh˜5Le–8¦ðHF=zpÿ¶ò˜õÿ‡Ëgµendstream
+xÚ­ZQsÛ8~ϯð==S«¤H‰bû”í%½ì\»mÖ7÷°»Š-מؒk)Éænî¿@€´$ËIzít2¢AAà@UŽü“£$RÛ‘±:J„LFóí™}¹÷g’y¦žiÚæúivöúR™‘l§£Ù²%+‹D–ÉÑlñÛ8âhÄøÝ//¯Þÿóú|bôxvõËÇÉ4NÄøòê4z}þáÃùõd*³DŽßýýüÓì⚦R–ñÓÕÇ¿ÅÒã„Ðë‹Ë‹ë‹ï.&Ì~>»˜…½´÷+…Â|=ûí1ZÀ¶>‘²Y2z€"’ÖÆ£í™NT”h¥/ëe±ïoZÆÀšÁ±µ%­¸P-dœÐlGƒ_wÅ|ý»qQO¦:NÆ«õ|EÃUU7ŽšŽóýDfã‚èNëbA?šŠžÄ0/Ö÷Ìõïªä‘ßËZ:ÖjË“+檋ý=Øü!BCô̧’$JÑ…EËpÈ7š*ka?:SÈÈ&Iì8ÚFíYB™|ݲ¨mþΧ,Ȭ+Ýô¬ƒqDX—ôD¥u”±Š¤V’;¯L†™ê&oŠmQ6¯@²–a>ÎóõÑb¼nˆR¡öëÙÚ˜,Š“Ì[¬Ú5몬ýV[æKAkƒLæ“/0ŸF÷7¡®¤_-)”˪¡Aˈ¯ˆâŽ‹b™ßm˜o]ólEO§#“Ôã sÔè380ÓÀ,\{2zÛ\§£7páÖo6ùüvUmŠ£À2J¤~féÀ5°v'pEi›ôﮊãqNͺnhT-yb± à¬kÏÛ¬òÆ
+pø¹ñÃ-‹#wŠNÈ|^ìxüõ®Ø¯½¨C4»5YÂ]íÄ*wVH`
ªÍ}áÕuÞë(³©îÆ..ð8‘RŽÙ©>ûñ´+²3ÕìN½"‰vÒñÇæfÖ]U.\x;Çâõf§<ÔE@M+ ´†Ã¡<ô˜·ˆià¦
+O73à*æ4	yX¦QÙUˆ®²)öË|^Ô‹0g
+±,´{•6aSÂKðL_.hbW훚†ä8Ûø×¼Gà˜íè^®<58þh°ªÙ™],…‰»z]~ñ‹˜–LˆGd4t좜VåÀΧ·ãG„yƒéÄ6ê䢵Š2¥×·í‰’&RY¢G©Q¬„}IáG6˲á²g$NÛ"©(l맠ªPFLJ•)W6•úJ&PO$Öþ@%½Ä甄º,Ó™é*éðùœ&ÖPŒà!øƒ1ÃŒÈ1øœK:aÌ:”8c‰4íù\'Ø|ósóØË€-È"YØ
qñ^RÍéANÖNšOdÛs¢ú è±àzáÂ1Df‘I-aÈ¿õn3ž"‚‘}IÅQfB½
+o _Z¶¬ÅÛ¾Ät‚äâÏ|Z¼¤i…¼H2¯·ê©ƒ.4þ= „ŒL”½¥_ÿ}vÜ:¿Þ›d=Au§;Òþ"›U¤Yüz-ÓŽìc|V"2±&hçc€‚·(ó›
ZÀ(v
 –ù–IˆŠz!O(îT²¬˜%H¸úD3]'ÃWÈè Ær:”M{FHÉË2éeí±¼oÖm>_­K>eWä¢×ì™`;ù)Ïfk÷Ü”ŽûPt8jîgõ7û©Wà‰ú5L'¨ølˆo^•ðö¶&ª3P¯/ßAi«Ú9²3—è–‘XªXØs	;É]†ÈØ8ÀDîPÓ«”!­ÏÏm}ðs*„Ý-Êô|
+n=K/Á”@¬J·a ’QqÇPB5ÌN†…	oXG혒÷²‚‚Œ/æ˜Ö¼)Vù=¢¹{-ã’‰Ãk*b€”×CgwÈ÷K_ë¡÷ó9…á‚CJºà
+8³žßmò=ý&»"Gÿê&ç®oƒ]÷!VÁHéfzW¨àßÆÑûîjCJ¾:‘­«ÖθSÐ/åùZaÚ;ážmSp|v‹£ÆáUû>ã{Ñ&t×F«4Þ]ÁÕkz““c´
+0v“-9ÞêN¦‘ùp“	«»ãX臵:Õ> >íš¿•ïŸî‹O5±òÍâ&{ó浊߯ð’B‰$ôJp€Dê!|¨Î-Æw@Á¢)ÎóZЀc	æú±“³ëfÅDÄË+ÒÁ5šu~ŽÀ‰!tº&!­J:J›°ù¤ÕΣ‘Bºá¨§2²àäš).…:BIOg&œÙÑË_ÒTçdˆtØ,¾bÙÍÑ®xgD¤RøâÈUCÅbhƒmhG³µ7³‰Ç•¿ ¸-žhCB»4Ô…¸SõÅï)Á«ÛgËß“‚÷Ÿßà¿ÿGãörˆèáØ·öqßaÊÁ^¨“S)ìàýnÊ÷»ŸÝÍ7ñ¡Ðúžm¨üvTk;*‘®<+ÿÚÐÄm‰_T:¼þ:Wñw|'§ŸÐCÕ\ *“¸šF1*‹¯T”Zʘô4†²:R±¿ýt‚¦uu·Ÿ]žO=w7cv>€¤\A«4éÖ¬8CF<à¡i„y0¨ï\Ž‡Iî!¤‰¡4‚‡ïÈíšJä®ÈØ@ãªI¶ø{-äY{MüˇJ`è37x~›øjßý	üðÿ4Þ	gñðç§Ød‘Î@+…¶OôñÇ6¼MãÕÿßz@•endstream
 endobj
-1243 0 obj <<
+1254 0 obj <<
 /Type /Page
-/Contents 1244 0 R
-/Resources 1242 0 R
+/Contents 1255 0 R
+/Resources 1253 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
+/Parent 1221 0 R
 >> endobj
-1245 0 obj <<
-/D [1243 0 R /XYZ 85.0394 794.5015 null]
+1256 0 obj <<
+/D [1254 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 370 0 obj <<
-/D [1243 0 R /XYZ 85.0394 558.6856 null]
+/D [1254 0 R /XYZ 56.6929 654.3163 null]
 >> endobj
-1246 0 obj <<
-/D [1243 0 R /XYZ 85.0394 533.2657 null]
+1257 0 obj <<
+/D [1254 0 R /XYZ 56.6929 630.7761 null]
 >> endobj
-1242 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+374 0 obj <<
+/D [1254 0 R /XYZ 56.6929 119.4064 null]
+>> endobj
+1258 0 obj <<
+/D [1254 0 R /XYZ 56.6929 93.3955 null]
+>> endobj
+1253 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F48 890 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1249 0 obj <<
-/Length 2437      
+1261 0 obj <<
+/Length 2976      
 /Filter /FlateDecode
 >>
 stream
-xÚÝYYsÛÈ~ׯÀ[Àª%vn`’'¯-;ÚÊÊŽÌ­T²»	Š(ã 	PŠüëÓ==¤Ø©¥*¡gÐ3ÝÓóõò€Á´‰Œ6ˆ­Š4ã:X–W,x€wo®¸ç™wLó!׋«ï_Ë8°‘5‹õ`¯$bIƒÅê—ÐD"šÁ,|ùööõÍ›Ÿï^Ìb.nÞÞÎæB³ðõÍŸ®‰zs÷⧟^ÜÍæ<Ñ<|ùÇï×wôÊø=~¸¹}E3–g6½»~}}w}ûòzöÛâÇ«ëE–áy9“xW¿üÆ‚ûÇ+I›èà	,âÖŠ ¼RZFZIÙÍWï¯þÜo8xë–NÚ³HH#&(䔵Œ„WhÀÛºÍ~?›+˼ͥâaÞà“…Y•íÒ¢x¦aÓîf<	ëê¡›YåͲÞïÒ‡lE+ÛÚ³n³e¾ö\)=¶é®Í—û"Ýùq½óòÖµŸj7Ôæµ¥J"‘(8+êûqŸížç
ˆ]vÌÃ3ÏŸîÇE¥Gû![0WBFFë8˜sY­…ã YóG3!NiXÐëVoÛ¼®š?HÐœîYn‹|™·h5ƒÕÒû"kh„gvľñD½¦ç.­Vu™Bãâ˜†Tµ/ï³ß¸ˆX¦÷~£¼j²åÞ]ZE*W‘ˆí—ALg­VÓPeÁ<û)u~+ZÆ`+OºÒítˆF2€ª–C@÷wãn[ÆÜ1ãS‰%DîIÅݳHKÑÝÓÛÙÜðpÿExâ°'((a¹²(:ø frLÚõ`7ñýM)‚W5œ(ªÛx>ÜÙ
-\÷)ˆnÀòc
\†Î´@”(¡ÂtµÚeMƒInö+c!‚oóŠž½#™!X¹T‘³Á…äN3ê–
21D—Þ_ã^œ× ëXÏ$C¯sƒûºÝõó«wĉ`u®&àÆ
X¹Úâ%ð¯wºé0?Çw8mÂ{Tr^hï9À¼uÁ•h>Ý‚¿9÷‚wuåÜÙkšqºàıÈÒÈ3:ÐÎÅ2¦xÈg/ÝOÄÆ' 'â$çsZ—4ÞW[¿çc^d.nât‚7UÆBð³I0ô„¯s.ôbmXóCNùjÏq¤ßd¯¼?ì}ùI»çˆ&â˜.D@ÀHŒü–QDC†PZˆoE†;Ÿ"Í"ŧðûÚ%_Dfø„…„ˆéÒ™çÚÑ̪Î<U·D4ûíÀëÜLÖ¶yõƒØ’kºYÊÓ$¡]8èÐå&|¨©—èïð_Öz=çƒ+þ:Ðü÷»ŒáÿÔIýŠsî¡ÀvÆHûÿP‰Ž˜Uß4Ë*ųìße‡;Ÿ÷¥bȲZ“ƒdÅã´hꉪ8œz:_Z³ÆŸ¹äy9‹B6—Ê¿ÖçÁãm#™tÛƒ¯A	ý™ÔPa²KÍçcxÁ_‡™oïc
-£ašOt/2QQbyÜ·ÜD1Ö1Œ…«+_û.fœóÐÝVʧ•;:e‚E#]=u~Ò˜p“6D”Ùr“VySú1WøÜ©i@º~ÇÄá:]æ3!³MÛŒ¦>9US¯…R "&E^æ­[{!A‘½¬÷•gÄÎÀ-¨ÓIi7i;:2]ë@*»î¢:ê;šç¦ÍJ,~É‹nv]Eýäº[Eï8 Àò½Œ+ªàù©7|/ù´ãàQÌ!ŒH€C’Pù;ÑËÓ|Èu—s*ðÚ9¹Í±lΠ˜Vàï…÷\ÒG~
-îDú«+ñÊ¥J‘¸®WÄáCQߧMyÓå.ÞÞ¼óÌ]›Ö4´>ö,IX¥eFT“í	EÂ_<­¥•~€Ë14Yånß.n^ÿ•è$@»Þø"â°G5øÓÚþG—û
5ïÅ×^½
Í.ëí3QIÞá•õ¸gTdÀ+Dk¶úS}âÈ958"?ìr8+ÐnîptëGò~ç%ݾû}""Õ—µ{®—s%!/mP?aY¸ÉŠ­'œá™U;3«°Ü[ßÀÉ©°¾Q·+êâß=åEAÔÇ}¾üàüÅ-¯Ð´°óCæ7©h-1-°_ÂI|¯êÍz²Ã¨¦¾mÈA9ò‡ã¯AЀ!=/aS@ªvfc>äYå§ü3y">ä5wû§²„‚Èoº<Õ`”,ŸØÕMJ@¢·ªáô»|•Ñhú³—2bè|£o/^Ñ‹'O ÷'Ìk‘SHh›˜NÄØÚÙ8cX9iG\K;4‚ã=o|¨»™QÇ*Ð*¦¤D[OÈL ö-ûjaB
-¨Ž=©­Òw qðq¸³x}›ºew’Ï@’u¬õr°{ç,Î`þbHÎL:råîË7¤ºà†tÜ|Ûu™.mYê8Ñ­²uº/ºOuÇå²rÛúTçÕêW¦Yå_ßÝg987æ€eJ‘­[üül6‚#.'ÃÓù\Ø1¡¡Êôïó.ãÝÎÛ¼Ìæyu’5”ìÉE%<Ë©#¤ µár¤ÄMuµ‹k+U—€ÖC‰„ðŒŸE*êáuQWÔy"þð›&QÔ³*8ZõL+˼ڷ™Ÿ&!ußÉÉveî¿ìÆTåGv+ðºÕáæ!Ö‰ìp ˆÜ@•ÞÐ=·ƒ‹ÈË}IƒÇ´ØgãEâŦσ]“G/bˆÇTœ\Ñë<Šz®Iå«bFÐE%P=]Ö¤çšPe&Å–'c]hâ=šøMÑñ4ú(>·ô»ÅCåhÖU¼Gï‘Å5Êy.{pq.~.€¼â_—9‡-~ÀÖZeybõg 5ອŽë|„ª÷íiˆ2ç–_V¥çšÐe„-ƒñ	‘:Tæí¾õàÂ:Äço¬Gm‡¡
-Ç€ÄG+Çí¢Q]E˜rT½ƒR‡SJÃ%C@ÙH3v”ûþo¢Ub#!¹¼Œ¨Óy@uLçCÕ$ž FVö²=Ó©"ãH•DR²±&0IÖI26ŠTŒ"Ð.RÁs"R1F‘Šu¨¢µ.R1BÕÑãßøHÅXn•·‡‡–‰bˆ_ãX›üG«îs€Žð·ò‰eýͯþI~ðÁ*†n+ÓØPÁª6ñJ¡¡µ:u
-ÿÛý©êÿyVendstream
+xÚµZmsÛ6þî_¡oGßD(Þ^>¹‰Ósçêæ\wænÚ~ %ÊæD"U‘²“»¹ÿ~»X€¢dÊvštê^êíꦌ#,‚w¤f±çš\f:kê_9—·[zŸS#÷¶ÜŸ]Í>PµÏ¶ë8VÑ ÓNx–+c÷7Íu¢å¹¬,fw$
+a~*`qº*Ùõ]Ta—åH/tï6FO¯ Ëº»¢#I».g®*ÍVÕ©I9Ê[
JNïõt;_Oqâ1\ðœi¥Õ ¨i».Þß뤛z<¡”sF
ç³Óh6pFŸší	UÀÎ\js¨Š’U±¤Š’2¢b‹þ£ò¬ü8[nçU}K•h˜Ð'¸%áž±͘Z˜ÑH&¼îQõ¾©æÏ2çZ:Y~ÜZ`ns·?lo/ˆª\*“&ž7D™r/W U"ŒÂº»ê¾\&o¤™b¿=¸ …žórQl—]KoÍ‚žã†òš9#Rœ³Ûˆºp…û'
$r¦ŒÓ#ãÍ–FÛ}¾”^Ê¿Q'•:M¥LYi’ôcí§–óa6	SI€Å)¬"f‡|“ä߃Š„¬™3ï]>ÒË°Ü9;ìôšvG8Åv^ G-ñX=­˜¶òÏÖîÀüS‘&R1Vê§2^|0“RȈ·H&…Ë÷Áçåc´õ&ÛÖxx5rvªu±*çcK1¯lòï˜F`øÙ]9û€E›UŒÂB³.7E°ëÛO@¨VTEY­‰àFæqè÷Õ< œ2˜•Ò©×í¦X­¡®ª»2êfQ g£¤kèIAÒm*¨.ïSå],u fõ—8I„†Øð»ÑA5Êõ]¹‚|
‰}I’°êkt g»Å\¯y®UŽúJ8„­rÐø¾¨–ÅͲÛ¦"ÔYóü69éõþ6Áà>4mHfÍ&¡hSS‚Áú~“ Io¬	ç5îžËeóPµ%±çYÛŒÌW‘«Âú!×ù~hê}\ƒ4¾eÂ+àÅé	ä[*Yc”yMåÿ½Þß1^`̃­à	6L˜á²é¯7ØlU|@¿â…öß|tMîwÉÊ7QÖnØãxV•uI/È—”nãˆä©Ø¾œm7U·#j^ggTa…!±AW‹«ÿ”©n]Öó8wSÓó¾ØTÍ6
+×Åţ!&Kð꡵Èn¶è@`Ð*X,QmÓºgÍjUn
+-ªØ˜nW&/*B岄㉄U^S1î6@F%¢ø¦"iN	jÁ`„ëOÈ´ðÌÉmØ“8Ͳm¨ØéÈú(pD‚1
€çAŒ@Ubã ¸+kF.-pß?QåMªk´«"DȈ 
+äÀ@´ÞnÖ
›T‘Ë‹žGã8I·q2‹ÈW÷ÓŽ¸þì;…15¨]-Ë#IB+ñ<úé†	†ÜœÂ9¤®a=d¯­Îêò!6Ij×\ÒK±íšdYôhzûëõ²Úi]Ö£ç ÿÜü1¥Ñ=—M1OçÏ©æŠAð‰}·¸è"ånéYÖ3à1Åm¢â!Áóàø6–ï+ü,a­³Ï“òÃ#ÌË-?‚™g¡
,£Ë!ߣң‰Hü”§P>éܾáÆðÁÏÓ
Þ¾£¼Cþ_´M
;V5aŒE‚Áq:R|êõL×ñÂ!ŽR[œ]lVÚ=z!½ç<OÿÄy@±%	vÄ$|ÀIŽù·L@šxÎm%’ØD)ÈZ=„>"_º«n[QBVàœtPxA϶YEIb4pÈÞ!¡°üX¬Ö‘™€à(#$? l?_^üC\FŒlé%²(ÕMGˆçæa”ózX{`"d%·noí5Q˜0_w×lÓLô C¤é×›êp.ø *Æ(Š‰´`}L+P\Òe]8L5•„"ãFÆG<‚ʈ}Œ*iv~¬$0¿O÷„&Ûu
+)sx°×!ÉÑ­ÒÕŽ¿å<Ýí,;ªÂ=EÝÔQÐï´Ú?ºìã:r8>v[HðÖWtåǃ”HÃAmYD¬j–[
+„Ô3BbK’Ä_æå²IH‹Ãņ]Š!̘;U­p©E[ü…ç!þ	—‹–ÃÙ‘ä$t|LŠ/³¢Þ¿«l‹E™Àh,U}€?©aß"Þñ"T×÷yk
Ô¨ž¯p›ñ¢[E%?ãN£¿ôyñ¨/¿Öð
+ow­¡Ž-ƒ˜û!Í—Çô6ƒÏéÀ£tÌúšÉ-¾¶‘lÖ·I2¯Ú/Б`SñElUÐc]l€ól1Ò{¸VÅ^Äîõ±-VÚ³Ýéï¹+É,ïéƱ+gû;K/]*' ÃœþÄe–6С×-nûë#1¤ v{¶Ü»jñŒÒDáôÀáévÎ01¨â=4”èz½=àB·ªÃq)x;ö!Nê
+Ò¿èK˜.ÏÿÔŽÞl5xøѱ¨‡±b1õ8øjÓñoÇ}¾ûh£úë1ºÁuxE%•až'—l”±ZÄϲ@ܨ!@Dv
ÿev~hSP
/ʬ¥OŠ“ß'‚Á9?|cá{å°Ö
‚à›‹•œ¼m`E“Á¢ÒÀÓáÈaQVîù§cÜi9‘ ´u\ïÐQCKWˆè­û¹T‡ÜKÏ>”¬ÚcãšY°ûÀ÷ñŒêT‚¥nC¬cRé}/ÓE=(3 dqªxHwørÄ“J?¿}O-#à"à	æVûœâú
~Vô:éü"¯èºí•4hw'§14`t&’Ó1ª¥º¦çé
%AÎôǪ#:ÐÈËlXà"?Å	0pÇP¯Š?1»CN·ŽcY›“¸_Á£@Õ¹cÔšCáË¢ãØàÇÀéî£ùÇ>x­q¹û*c9Ž¾÷ò•¦ÇpÄP(Š§aD>FÜW‚8zrmõ×G‘ÁÀO€H.ÇûsÔ÷§&d_t>LñžgàLP1ä,”±
„І$ó¦ŒíÃYív=º )»ÈŽ]<‘iü6fHÈ…/=NàFÜÈ%NÛÌ0Ü?࿲‹!z,<;üe>óçD‡f9·vìç)¼÷Ä/þ1ÌÎßñ{¡÷rèïFÅ-ób²&Ž…¶6æÑo1Ò¯fb«êÿŸ¡=„endstream
 endobj
-1248 0 obj <<
+1260 0 obj <<
 /Type /Page
-/Contents 1249 0 R
-/Resources 1247 0 R
+/Contents 1261 0 R
+/Resources 1259 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
->> endobj
-1250 0 obj <<
-/D [1248 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-374 0 obj <<
-/D [1248 0 R /XYZ 56.6929 401.1388 null]
+/Parent 1263 0 R
 >> endobj
-1006 0 obj <<
-/D [1248 0 R /XYZ 56.6929 376.7118 null]
+1262 0 obj <<
+/D [1260 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1247 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
+1259 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F62 1000 0 R /F63 1003 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1253 0 obj <<
-/Length 3630      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ6òÝ¿Bo'ÏD(>xL§çÎ5Í%îÜ̵} %ÊæD"]‘²ëþúÛÅ.(’¢dgz£`±Øo@Í$üÔ,³BŸÌRŸ+•-·rv}?\(†YD Eêû›‹ï>˜tæ…wÚÍnÖ½¹2!³LÍnV¿Îßýóí§›«Ï—må܉˅urþýõÇ÷Ôâéóîç®øåóÛË4™ß\ÿü‘š?_}¸ú|õñÝÕåBeVÁxÍ3œðáú_WTúáóÛŸ~zûùò÷›/®nº½ô÷«¤Áüqñëïr¶‚mÿx!…ñ™=AE
-彞m/k„MŒ‰-›‹/ÿî&ìõ†¡SôKl&¬NÜla‘9˜c’ÊRHT[¤Ög´é¨¬Õ•#R¹)ve¾Yü±/vÏ‹]Þã}+'…öÎÎú“¡ÐAMà`z8(g…NÓlˆÄ—MþXõF|‹]ƒ5*7j~4ëU¹Ì7›gêSç6oÚbGͽñzÞÖôýMJ]­ Þ·ÔX®©á¯º:¬
´ rµßÞâ<@ÙÂZaŒÊ`›Jxku@úžpÎü|yŸWwÅ
-,Ñn~•/墳ÙÇRDŠû¦h¨”Óg[Vû–gÊ·õ¾Bü²l^¯©­½çÎfÓ­H»¼\ÿƒg«Šö©Þ}¥Êm^­žÊU{/Âäó›K¯çH•Ì7å¶Ä•å… ­ÃÊøv3,ìbõŠZE‘ß›²ÍX‹fçåžîËK5_ò„H¡2PAv—*›3|ST-Vûl~C³Ùùc¾Ùí‘ÒèJÖ…î‘h'¬—dý¿¦©ÐÎ*Q?´e]ᾕšç-UVmq‡gÁ=%nC*Þ¼Dý³Üî·T!Î"ˆˆîa÷R…
SóC„kŠe]­’@…À– †DfÝðpWÅ:ßoZÒeøj)Žô+
—ÂnUr^±ô€Në•4¢-îk¬S’TH	ÚâÜâÐñêbaóh”þò×x6ÚGÞÔÙ<ó1æc8ܸ<ühM—$É€+hÁ¦hi=:{h9œ=´vgáì¡
Nv¹ßLJƒÓ°&¢1>ïT‰#5æ3&;ð1 H6›ú©XQªAüÞôØ´ ÏeuÇÐ-uäÕ3îÊÇ¢¢¾¶Üh:SËÔÄ~OŸUMë’uKà¬O²÷¼^Ü5öî§Ä¶	=àH5=…ò®ª‰h=Us|²
-¹Ó[ó
G«$ûGËÚçº3““Ú±oÇÚ.‰ÚÎi»µ¨ºpŒ:ñà¤~xŽ4dõ°]¨4!TX1`3w¯Š`Ú𠱺oˆ€PÏ7)ÌŒŽLC.º:B%#ãs3ÍuÔ%@ÈsG9f;%¬ËÌXÅÚŒmZ\j‰=,BÙÁ!°è*€š¾«ºÁïbp’ÍÍøÐBü…£\5bb_Fá™d½3aÒÈL¤
-‚Ž;y^‚Œ(hòMØêO@êýÇ/Ô²-š&¿ãÖà`+kÁz
-ˢߺ$¹¢!‘ôÔ·šÚ“¶NþÉ+9ËDÙÈùò+ãž7´"Ž'¢§Að=d˜cܵJG¸7Ô˜ó÷¡nšòvàà}ÕÜO¦‘˜äC- º|-×C,ªLtK^}[|Ót^1F¼,AŠƒi0óÛb r<¨®BÔ¥fÿðPïÚbŦ¦ÌÛQnÑ
-+ÉdØä-XcœÀHt󟨓£P¤˜V7:á¨ÛÃ!Èèa‹0%‡¾LüÉÀhX±pèK„–ëê)çÓÀ0BŒiQ7Þƒ®H|ŸÄ|þ±gB(¦Èo@ÿfkur‰wCß|ÓàÑKÓ£jè@úá—Ù¨s§*—¡©nê57ýçÒZà¡UýÔÐTUDôì¹ÛöàY»‡ãLO^Þ½~i÷àû¦2í«ÜÑZVØÔ«oÕ©I7d›?“§pËÞE
{Þ•«UQq¿9}xöƒ>…¡y#ŒÛçWº Ôé¬Ï6A)”s£Ò‚s²
à	ÏÃJÌ”œÈNtžGê´çÑAõIÛ,ÊêÈå€crR¥çWï &–¸‰LÞ`ùÀ}(Ö]•Î£Ö¡ã·¬n!l_Q…’Xê9*¡zœ}(—·¹»Ìæûª¢¨	( ±-†FbP£…3é‰ÔȪ‡b”Pª¦ÌL9]É	^ˆsGaX$k_W$ÌE8nB@Àk‘Æ$$ãØgqÂ]O6ãæ¡A÷øe€<$wEµäÆp8µ3ñ(‚nÈ`)Zé¼…X@§#­Hš
d¨“Òò°Ýâ ^¡°©óÕPd{]ËEaðð>Ñö¤ü€>KòB uZ~:¨!á1óv”0àDÊìüòÔÄúCÊ„‚Ølˆ@ Dõ"q¬D	J´‡†m€ ‹ÖH„°Ô!'ÂŽ BX¸eȾ!è	"ÉdS72ý`„3Œ*=Ôh
-Ôš¶‰AßâÏ%x<|þëñùsvŠœKí)|šs~´ +Ç
’H,ÁœO:–`c
„ØJ‹ŸâBP}™Sî.ìAáÂ5äÂhǪ㬸¾iæÝy,:¨	4†™n%ÒâÆœÁ”½´T)AN)yPçXáµ’}^Õ{òŠ˜±é–!xo0~ÇJŒ(`=öLÖä(!~ž\øpV‹4í¶i¨£ÛD%¶è ¡C>Üó–}Ÿ©ü©ü	¦ÒI®”ŠvAOéláÓÔõ¬‚‘¯²
-@-d†l1vœ0rY:ðœp«Á:°0K°ÝéÈ»
6Cq"Ø(=a3%±³óèÕÁfè”m¦•[‚#ë€-d§”Y‡Þ’Š­¡u`Ó?Dì C¨ôñ˜†£ë„×L¬íùƈz¦ÉûÈÌÀýÄöš¿9uÝÏ0”ÜÏP|&0v?±é„û™@Lcœ3ÀÂ`u\ÒåHîwD\ÄmM«M/¡.Äÿ‰RéÿæéíÁš,uê´Žì Ž‚É—Ç—`X½N^@¢ƒzeSá¥}cnª¥Y̽t	pñ'»ŒŽ9¸@FÍóÕŠó
ŒïYiâ—u.@Óå!¨”O	•nÞ}¢ˆqU,1%Å„J1Îù!CO뢥LSF"νôgŸ:ýo=GW½×@Ëî0'«¢ë˜
i2Û϶@7Ëôôfêâ’ïÖq>Ž/c¡Îs§ó_Þ¢ŒÇßu!»6€wÑáU况—w‡5apÌAÄùVÏ ²Ê%õïV :µ
›Z^LL\84%k8˧»è¾¡Z80´~Èy¦2~KÖq³	ˆ@[´fPŒ¬‡Eb/(í›=K“ÆkÜsaÈ—ZóÕè—K5' ®wë|Éc~Ó:Ynêf1uNà%"`‚á°ÌËaã@íCGn­ÆûÕ Of€m÷qÎüá¡ÈwÔZV¼Î=Ï5œÛàÜÿ˜Ì”('¬rчëªE'ùɸT$RÓÁ¸ò›`#<ÄRS×*Æ€¼1+®Ü”¥À7CáׄŽ˜y÷6 ä9 lþ²Ä„9Í2a¢…¾¨»ãs‚¶9wéh$ÄÎ]ZýÕjOËÎÕ&y‚òøN‚"HªÁ³;DÄùìNð•œY`hX`¬sNÕhKJAÀŽb' 'Zf,>¸(›=_9Bs>É	&>¾‘"JHí’±ùŒ<NG’œÛ§²½/«sIª$©•‘ÌaÇÇ+kð
-u±­wSgð­ÈúLÎ#SÙ[0X_‡!^ÎêAÖ»Ûïòx"CöyS¹JÂ
-‰›i¼¿rIöšK&ﯲéK dR'\ªÝé¹hœ„¹¸G§ZDìÊX‘x­ûATwVH@DNÒ™ò™ðœ*¤ÑÇ­G!Á7:’úçË…Sóø×ó«#ÒÀ¤,_¸2̤o¯fÌ€“>9(‡Ý¨¾»ÞêÙûö4ëo+μèOör8~´ ѤsÄ—_ê
*V2eàEú¹V(*R~
-ÃlÊàC_ÃC‰®áçŒ8ÄDÀ=ÜR´-IŸã7E¡•ÄŠVOú*ëKðsXµŽl'¹A):ËK-ç_ñu uƉO!v»Ðw ÎK3[^Îý=ΆhN`'È“8ûÆŽW¥&=ïWwP'ôØâÑ¿³CNÐjÖ_aâCM 2È>€ZLÑ£`Òåw
-×é%ÁDì„ÒÓ—'õ0Xè,ëò¸oÉ©N#ýu”Úšzã¶ï/&^4€›êNEøN+uê…ç‘ 3¯#ˆÜ’vñš¨÷Ìq‰sŒÄðØÀdP;},Þ¢NSĦØUáe‰I]/Aˆƒë_¨£ƒ_’t'Û-›²	7eªš
-‘È—ëž|¼Ú;‡¬órÓ0Ò“Ïð||÷€
-„’:^•æôft{þj÷Ȥ½wS úĩ缨•Ìä½ììÐß~ê{x
Ž¨"=}úF:pØ|‘Â=X;ÆÜšLØL§¨ÿß»xÊendstream
+1266 0 obj <<
+/Length 3308      
+/Filter /FlateDecode
+>>
+stream
+xÚÝZ_sã6ϧð[噚å_‰|Üîf{é\³½ÝÜtîÚ>(¶kÖ–¼–½iúé,Ù²³½>ÜL'3!E‚ü‚¤ÕDŸš¸T¤A‡I¬pR¹É|}%'Ð÷Ý•bšYK4ëS}{wõÍ[“M‚©N'w=^^HïÕänñs’
+-¦ÀA&¯ßݾ½ùîßï_M3›Üݼ»Î´“ÉÛ›^Sí»÷¯~øáÕûéLy§’×ÿxõãÝõ{êJ™Ç·7·o¨%Pq†éûë·×ï¯o__O½ûþêú®›K¾JœÈ§«Ÿ•“Lûû+)LðnòR¨ôd}eÎÓ¶¬®>\ý«cØëCÇì×Ñ̬Z/«´ÁÙq±œ¡Dš*{ž“À‹«íˆ!«ƒ{ÓÌŠTËйW›‰R"8§Ñ¿©&Sé$3FHl÷Þ¢#a.µ
+é”ÎhPÉWMM³KMoU0;À=Ín·Í«æaªdRl§Z&³¦ÞÇʼà±}™Ʀ)Í«Å„ñ-ûªÞ•Ï—™Â\ƒ4ŽGˆcÛ4탟wÕ_Ç"Ó…sÀü_Có‚ZëC„…O#LjRpC#ŒJEqCJ™ü·®
+
+wS¥TTl›P[v°ˆ4Œö“¦É2o¨².æ˼*›5—•›U¾ˆÕ]e–<äórª’U¹Ëw5ýU‰Dñ=+M±£Êª\—;î­YÈnÉ£óu½¯˜°~àu¾ )»e¾ÃÉáthµª4£L´«ŒU€e€•æ¹Ùkˆ±€|׶>Ô«UýTV¼çE$qÆ%BŠ¾hõ¸æ
+h·bAíø¼¯XÒ퇱µ@ªÏëX.—°C8@zÔϹdY¬6\z@YT;3+¶“µ¡3/¦Žs½L†ºpßS¹ZQíÓ¾œÄõBÃ+4-p~ä1ÑPÂóÕnÉ4}1œùç]\Šù
+Xbˆ»jëÐOÚÚdSowT[çÏT¹/¨l6żDˆ¢)±á©DqX+òù’Cd‘i	0Ϭi·¬áò:Z°pSïÚ¿hjQT,žT˜%iÝâs0(g¸:-R²¡=Ú)Ã’–[¬ztXE,<_<äûUKú@œÅeHn¨†B¥ºi—~©!2-ÓÒšGÎeC"ËÏëVVԔȄý6övg«êT–¶Œujp÷YúÿšØ–,™°ˆ-5 j[.
+²§Qe¤G[Dz3AÉ«lS“n;0VõÌ[à˜E$Nh‰i½×ÉOK4‡±rÔ>›AVÚ3CzÞü)˜Dž£Q¸I³Ö´ûBeW‰µ°
™.‘&ƒZ‹wŒn©áHLc`·ò(°“Õ-LIëtˆâ×TË*¼qœªæ‚PÆê/Ã"fízˆEdÎÑ	j0”*÷Q®n÷
héö
¨Ö%~=ÔÛVÛœ‰Ñ3àP<åØÖ­8ü(›Ã£ xÁyÒߊõfǹ/¨ý­8Óh7T¬ã¼1¢ÍsÚJÚQ@¯Î¦x 3ΆËéGŸê|úÑQ¡êëü·Y›ý Ïg»r]ÌÊê$qpFò—õ`š5t^€Ó7Õ=¤Œ¸_zÛ®¨õÓPo`Wôɾªb†‡Ý«ºzŒ›>’ÆèIµè7ûIõL#×eµßÜÌHò´ÏÄ!Åv]ÎÈÇ™]ÕQÀ®`I.ŽóÍCtv”9`©´¤J'²Eƒ¦êÎF
y{È|Q®÷kúøœ¯öųö,6îqµÒI¼Œ$HSùR"Û§º€¤–jIåb5Š$ù'$­—5é¨FT¢I‹ÏË]hRšÔM
+Ññ‘¤p?§ru¯‰¶R ë¥:d)‡F‡ÍàR]¥\ê\
+Ž“Zÿ¯àJÏaK°õƒ–‰'÷BêS‡VGu>HÕûÝi”J…RA]V¥£Ñe€­œ%ƒeÞíw.
Ù;Ÿ!ñÐ;½Âg?Tá÷
+@ÂÑ*RS®k%!LÅZç^øàLj÷­¨> lHkü=£•Ñíe^€Tê¤ZªóÑjR°KÙð‚*Õˆ.Ãpå…Ô}¨ÌRF¶2Râ•T‡x%Å+(GâŒñJ¶Ø¢±1^IÂÖ1Ä=¯$Á+Žb“0ÀR‘AæÛÀäï³´‡lÓ¤þ2ÀúTçÖQÅ$¾Ø–ùjöi_lŸg[¼a;–A{^V€iFä@eR M*ða•F‹}¸˜Ð¦'мëE9Çòص¥ÎuÞìb°2ª?^ÓùÊxq´ \7±±| ‹$»ÌY`µ_ßóÅ&×®°qpµ$}Hðó1"Ìê4¹ÆÃ~loöm­Uªûx…µœ
+r=7ñe¤öt‡…mtÀFv«N"Ír:Ëlòs«ŠÝS½ýH÷yµx*»åè
ÇÝ4èM~¼Å*_³`[§Ô£˜ ´‰f7NZ«öÙhBesÄ3Š¸³¸§%žçÌ-/~"I{7„
eu{òAjZb#S‹êJ}æ­SáB{ZEý\38•§np(ÇY+•Ä-•Õ®À<Á=qÍK¾kC’Cp-®ˆ¢Uö0w©ø|ˆÍ›–®)æuµˆ6°Ñt¾“Fxç•£aMËóA¸dêÅ Ò£ºTZª#ó–t4DåEú‚t¦>ˆ(ÚˆÔbDéK¿A÷èЂSûÄ£{Œ9ƒŒoj`…Ë3º	M­ÐÖÚ0H`¼ö@yä~h9¸o›[÷CGt?´sçû-A>ú>²áPDcxS’÷âA>ò3Æ`dD|^ˆ—ºÐ¯]¡Œ»&”›,hÚ¢‘zG´óšî
û0Å«¤Ìµ8ШXÔ$Ïó=s@‰b—,¯5öìGîѪgœÄ†Èñ óXÕœJbÍÈÅšÇìÅ™?áZ%u:p-‡Ÿ›
+/‘)îiºý„»öÎt9wÃ] m€“Uv”wF‡éâ[P
+ñ)‰ðÍM›ÅУȂ>÷M÷¢tîšÑ&ùs10³™?2È™p¢LŸ¯/F“Ñù`Òõ_Ûbª÷Po×ùiîIjŒ¹¨AGtªÂ0IóyfÓôô©‚맺ø9Ç­+÷ÜO^»#zª©²Àk\Ÿðl:RšUóõØ®Zø`Û}ô˜OÀ`äBÒ‚{:~?ZÂËÐ^pb¶ÍüF—ƒƒM¦[”N`š#”=ºa½\€HÙ)tƑLjSÂ¥þ$º:ÏZÓji{xõøC2è².MŠ5•‹"I+&§e©YÄ%>§Ð3ÑѼŒB§øžOØ4Ò#ÊÝÐ6gýé°VÝm:å†&N+>_eÉ›ÛÔÂ7ÄÔSlåXÓkZ|6ïZÛ9ÒšžúcsÒ°ö@û…Ȫîe“Ï?²îñ}$Æs]ÉãOFðN}äÝ°¯»VÙñk"5æ\nê¦)ïWL
+¹WÍýT°Ä(µð^})ê½Ê´¯"%K_ׇ¼4KŠ¸ŽãõxÉoBÚ$÷ñx¡²nP]ÅÔšýßÒŠï©9u´›?ÓÑ’$­òlÄñqSbŠÿD|ˆU:ïàûˆ¶|âÀöèÙ&@Ø"M·‰CŸ¿11Ý?Ê^ŸA8j¬«§üð¶káx1¾ÔM+¬ï›˜ýO=alQŒ™ß!}­n]bºÝPIïðòõ¬;Ð~X2Œºdú‡rN×MýÀM?M-꧆XáOº—á.ÙŽ´‡´š”™=¸3Kƒ}yöê¥Ùæ“uOc`vÂeáOÇT”ê´ã7 ûöW+ôp¹(ªá¯Xrþ}³?Tš7íùâþùÓ
ñθ٘@
+•v¯Þ‹æ™_'ð'€#{¾ì~d÷—xø!•Í„ñþLö !Ų˜°R8—ž&LR€5ôˆêC(˜endstream
 endobj
-1252 0 obj <<
+1265 0 obj <<
 /Type /Page
-/Contents 1253 0 R
-/Resources 1251 0 R
+/Contents 1266 0 R
+/Resources 1264 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1255 0 R
+/Parent 1263 0 R
 >> endobj
-1254 0 obj <<
-/D [1252 0 R /XYZ 85.0394 794.5015 null]
+1267 0 obj <<
+/D [1265 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1251 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
+378 0 obj <<
+/D [1265 0 R /XYZ 56.6929 651.9185 null]
+>> endobj
+1011 0 obj <<
+/D [1265 0 R /XYZ 56.6929 629.2598 null]
+>> endobj
+1264 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F62 1000 0 R /F63 1003 0 R /F21 662 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1258 0 obj <<
-/Length 2802      
+1270 0 obj <<
+/Length 3130      
 /Filter /FlateDecode
 >>
 stream
-xÚµZÝsÛ6÷_¡·£f"ß/OibçÜIœã<Ü´} DÊæD&‘²êÞÜÿ~»X€"%Êv'm2c‚Àr±ØßîÂæÿùD›Ø¤"$©Š5ãz²¸?c“[X{Æ=Í,ÍúT?Þœýp!“I§F˜ÉͲÇËÆÌZ>¹É‰L,â)p`ÑÛW—ï¿\¿™&*º¹üx5	Í¢‹Ëç4zýæçŸß\OgÜj½ý×›O7ç×´d</¯ÞÑLJL¯Ï/ίϯޞO»ùéìü¦;Kÿ¼œI<È·³_~c“ŽýÓ‹ejõd/,æi*&÷gJËX+)ÃÌêìóÙ¿;†½U÷é˜þ”°±‘&‘/ØVZ§E;¾-›Ì¬Œ’éi^ô^~¾²šYë4Õ“™1ä´ª3¯ÎãTköµI,+&‰”1Ã)0ï*ئ±6Š#g±–Bs¤ø8ÝÀO™Ãš8SL6å7ž|›ð˜©4•DÓ»“î5à&~¸¼“w5œgÒ?’ç;ë1v'2¢ç°\€B¤’“„%@•¦NàËåt&‹§‚Eõ–^òŸ<ªê–&vesG£ö® A¶j‹
ú_Te­Ÿk7S+U³œJá2riêíf(jzÎýû¶)òW84C	š»z»Êý¸hIïFöŽ>AÖ¢ÈF3iÖnÜöÜmg¸;@b2Ð	±Ð:ñÖËÖëM½±¹ŽJ8Õêq
-îœÀ‰r Œ<ê)¶´ÄıSòb]T~r»®+Ü…õ[Í:'ƒo‹¶-«[Ðcb£Ì?ªÕ·ó‡psól‡øJo¨E÷DcààWÆĦiéeS,7Ú_¾mÉ(:è2>ôIeÒXØÔNúáð}&!tL
-p3Û£Ä÷ÅÿL¤±µIêLs>Üa’11t,YÄ(ÊŠGÞ\Dd
-¦Ÿv£Ñi/
-DÇt$õЋÀî ö'%鈎Eø_cBdùÒ ñmÀ›œ	ç÷΋{gjh¹ö€j1B™v™WÊb×x–îÏ°Y‹ȹ¬¶w¥g–Ël»jýW€^Ǿy9a0ÀcU˜›C1ÃMêÍ]Ã7Ÿ
-²zÙÒ³·¥fã[BE'"5žÑ#}d³$VRiOó+ÓléT£û噥Ǣ¾_gm9/Weû¤ü´ÿI@]ÁÅ3Ø£zÂ)¬-—§œÞÛ==³;`¦böéí´‰žª
÷ÚÌðÈû²BŸ“LE»»ráÊ­êE¶¢Ù>ÎáR–çävMƒ•·”ž‘´^·e]e+ÌÛøþåÝ'úf]oZO¼+Wžñ¼ð™ýŽ1t=¬L€ÎP¶Ågã²:T¶ÑÕǛˋÿÐì=È‘Ý
D‰12ºqN=9=å3´[Z¯‹lCcdÇ“
-+Üf•=„a±yÀ…jÿ͈KHÞ\tÅç}8¿óbic-d@È?03xä…T­´"ïb•m1ž¤TðéÄ”t="ˆ¡ú¯w3r…Yt'‰E{¹†‡åÁvM@u_T­-Z¿€j	e•sjÓ¸¡QXlPÞ
-gÌœgÀäœKƒ—l½‹ÌWr †8µL
ýeîK±,¶)ó¼¨ü»{&¡¸[û´ð‡ÏÎi{+ˆ¯ôÉËÒÌ^ü—›¬º-h(Eb,
ÖR¿¦ñÿ^åÄ‘ê³UIìõѧý=
-ÚâÀ§ VPt–‚»¨Ã)
-&œÙÃ.ÎìâüÒÙ¢¾«W!ëB¸Te÷E>ÖAQnôT¾	þ"vpý•ð—v}á¨ô@övÄy§–æŸP²htd®[…u™Â¿W&ÜW%‡wϨd>L+Š>"ÿsX£IÕtÎÀcÉ´¥ÃþîåÀÝ£²A5ãøË!='2ù“øÛc‹ÝÛL0N8ÈD;FÙ5ÜZýX‚ê2Ý%‹“f†Ã3“ÎmÜ>‹»ºn(a7±0[ºx‡	0hN†M×M6@cEhL#L(Êö&|€‘ë áéš$wdåÛI˜|DŽnä~ƒàοsm0Î9ˆQô{‰ÁvÇܽ6{¬Ý½œ—«…ƒ›æµÿnÙ]‹þObÙendstream
+xÚÅZKsÛF¾ëWð¶d•‰Ì˜ŽŽ#g•ÚØ^G>ì&9@$(¡BJQ~}¾žž¤ìr¶¶T%Ì£1ÓÓÓÝ_wƒr"ð''i	Å›ÅQ"d2Yl®Ääsß_IO3Dó>Õ··Wß¼Õv’E™Qfr»ê­•F"MåävùóôÍ?_¸½þ8›«DLM4›'FL¿½y÷düxóþÝÛ›ï?}|=³ñôöæý;þxýöúãõ»7׳¹L‰÷•_áÌooþuÍ­ï?¾þñÇ×g¿Þþpu}Û¥^)4ä÷«Ÿ“%ŽýÕˆt–&“'tD$³LM6Wq¢£$Ö:Œ¬¯~ºúw·`oÖ½:&¿8I£DÅf2±!´Q)‹H$ÚÜÆ"²‰M;)+9&å@ERnwyÕ¬Š]3/«ã#Km##¤ô×=Ù½£Ù^÷¶—±Š’T·¿}(fs­âé&ÿ£Üì7Ü©ö›»bÇízÅϲº«÷Õ’;Ö•¯ãßwò–[‹¼âƧÜÍÒ龪ÊêÞÔÕb¿ÛÍd:-ªvý<“RNII´rlAFRŸKeIŠ¹,Vù~MÛˆdú˜¯÷7ˆÞjg½S[¥:¶½*“ãÖVžÄÐÌ›jÁ¬å
qÌoõo3I¢Thãß:¾Æ£-@œ2ñ&fŽ›mQ,¹¹ßÒ“èOñ<Ž…û¢ZøAwôâ:ôCtÍ+´Ay·÷R)[ŸÌ¨¾ê¨Üþùº©ÙÖ'Ô(Ç-xÄ1Bu/¹UW'S‹|ÍÍæ¹i‹MtbµÞ4Lj"èhvÙ~úTçí§£
+¾Þ·'ëHÆ"½¼}G5²ÿЀÒH*¥†8Šev° ꊕp—Fc`ЛõØ„¨Õ3!"g¢	gBÔ¸ó”}"Ò3&Ä–f­QÛÿ¯ÛÔÝ¡ß”{¼Äïû¢i› ü,þX£ƒï¿Ü@Ó\ó©\{M¸+úk®öM±ŒH=‹Š¦:¦Ž·`·é˜k¸^‘Iõ%&|NqÓJkù‚ö¨.ha já–mv^5'ʘ˜È¦™¹ÌEG5ÂÆàÄFFÖŠlÈKXŠƒ2R'(£ß¡wNÖEjõtÑu.Ò{NièÎSžèÞàýwšN8`gC¾rïÕÄ_&¦9?îËÇ¢â&/»©Û‚ûU¾ñ­¦Ø‘[„‡&G­2䬯TÙA©²3J¥â8²F\Pc>;ʬ5=TÐâ³PÒÊNPa¨G;Ù —Ú>:¸£:tðÆ,€Ý6Z³ÃXìX¸ÄÛŠwßb®MŠX4Z”gütàטÄoÓ´9`{ÖG&™Bª^@ê>ÕyÙQõeÁr®÷»Eqê"U”©ø&:ª¸‰2‘|ÇÚ©Ù4õR[m±Û”0X&ÜÀÓC¹xàf´œæË%«|ȵwšôô>ÔmÍC7cnݾùÀ
˜qU,Ú²fE§‹˜C3ŽÌ¿)\`–òZx®ŠÖñ…¦3q?|²cοrðÿIæÔÛQ2@§C/«5Âá–'Bè˜e2x2¥¾ïˆmzzåvdé9óc¦õ–Ÿ¯ª ï׶ÓOß}à‘m½k_ñXƒ®êÝ€Þ„ÄïúÀƒsv%³m{âå§Ü.ÃzËg¸¬rÁóûí¦Ó<µb’ªn‡'	Ö踡‹”
+èÔpÏ]˜rÞ‡¬™o·E¾ãѲòû<øµ†kkZû͈ÔÒD‰4‡!œúiÞYþ©¹ÅB_ÌêÇ;NyÖQ†\ꜜü´†½A˜•ïÜ&2Ù#ã#­ÐfZ®˜ã.•
óå/B(š‘²ÐÜ\ðÝü
+tÌOŒã„ÈUr„D/º=%ºP›í	äìÇTX V!²;d¬ù>œH|þ/
#0L}?Ÿs7 ðcY3B”õ~ÉèŒá|T)êK%"#¡L|ŸA'tÄéQXöT¶e/U>å$¶‘MD³;ñéÎ
+Q¡²Ûz7²vMM˜sò]GØ,²w¬ß†)^—ÎÁõêÝïw9
ÒȺ8	¤À±™ÄHŠUŸUÓ©+/¦ãõ88kh­äüZüžÀZ¾Éo˜£¥æ;().&Ë%±î®H€	„[cIÇ|ïzBDè !âo­‚¤ßÏæFNoñ_M¯O$ƒ55€o¢3iᶞü>Å™÷Ä íÎzøæf£&ßÕ8Ѥ¨°ð¼·²;Œ°öà|)fcÌÐj.ôýT¯É«JW&C™MU”D’›©Qxšué‚`Œ,ëÂÓÔ¹F³ßnÉ6c¨Ž)Ú–MvÖ4Ê6Å;Àá³³Gg5Cãýê´pd)ŠXÌ”˜þFÿÈÑ©Œ3‹Ä	Ávÿ–¿Nq†E&z2?T…¿N­‘ÊE49‡¦8åù°»ÇHþ)'¸UwTg¼ØüÑœè¤Á+«õw8
¬Õ#ƒÚÄmc}ÄIWÝi8YG+ÃæÄDReò‹¼0ð9M»*î«Cijë‹Hž¶|ÍŠC:?$¦m
+_ÏôÙ5¤š³)… ÿ…âŸêÂå*ŽKÚùç¤Et|r(—øD#|鶴qeF^[K»*wá•5½"!Mö{êSCO6x3>cd]"ž]zªj,M–03cÓ/…b£Ã+«¼\7žéj9†±ˆ~²8xl$	s’¶Çí¶˜éd¼Ððbˆ¤m‡¹¥W3xÀ³©œ¹ù·@dJU}§oœƒHI[ât/A¤¢oa"KÿVŒTˆÉ ÎÿHö—¾€’ˆoAfÙnÜ÷1}&Ø©÷ÜYR9LH€‚òzJ%©å¿Ö6R…©·š„&a:Ex笫t¨H5?ï|ŸRY*Ë	3ä y¨÷ë¥o-ËÞ豚™¨;«4±í± SkjÕÊDªH%Ip³ÈÄvõÖ
8%˜±b{Cƒx¤¯È{ö<ؤ¶5–Ŷ¨üà~[W¡¢á·Xà}ˆ#(pg÷lH~Oþnì.÷Ñë¹lÚ†³î(¡¤Îù?çþèPîOr$Þ!Ìó!Eß*¾ÎÐþ¿!…4ð÷qò*uTPi,¬Há’‘Zô79&O4ÂʘRŠÈ¬òòÚ)èu{_¯ÐTœ¬äìÚ†ÄÆ
+Ÿf[ѵÇI¤‘”]|^GܧqËX
ÁÉ1>Np•VØ8±YÄpÊ©²ññ÷Ú³aÂ1p~¢«)_§¶H…†/”{ûT´(Pº Ëñ
]½¡«¿ÄLG5ÂÍ@‘™85Cv>¹ïÚipi6P©4í«TšõTªáéÚOÀ¯¹O	—1Cé{ã—ì‚MŒ÷J9<Ûr%'MûÅ@¯Çªü°+”jBU}üŒ¡²A—jœo€
+_TÛÁW¯£;J¤‹Ve¡àð\Œ}´@܆À?Ðü"á‹®ýŸ¥¡œ°ÙæmyW®Ëö¤ò¬Z‹DÕ¼ðY¶Gtá·5žˆ…Õ–«çs:ÃT¨> endobj
-1261 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [442.7768 250.2874 511.2325 262.347]
-/Subtype /Link
-/A << /S /GoTo /D (query_address) >>
->> endobj
-1259 0 obj <<
-/D [1257 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-378 0 obj <<
-/D [1257 0 R /XYZ 56.6929 318.8054 null]
+/Parent 1263 0 R
 >> endobj
-1260 0 obj <<
-/D [1257 0 R /XYZ 56.6929 288.9425 null]
+1271 0 obj <<
+/D [1269 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1256 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F21 658 0 R /F39 863 0 R >>
-/XObject << /Im2 984 0 R >>
+1268 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F62 1000 0 R /F63 1003 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1264 0 obj <<
-/Length 3378      
+1274 0 obj <<
+/Length 3277      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ZK“Û6¾Ï¯Ðm9U$kOŽc{JììÌlí!›EQ3\K¤"R¶'¿~»Ñ
”(M\©©)âÑD7€î¯”\ø“‹ÌÄBçÉ"Í“ØiåîF,aîÝdš¥'Z†Tß?Üüý­Nyœ[e›`­,Y&ë_£×ÿ|õËÛ»Û¥2"²ñíÒX}ÿþÃ4’ÓãõÇoß¿û÷Ý«Û4‰Þü@ÃwoÞ¾¹{óáõ›Û¥ÌŒ„÷¯pá…·ïzC­ww¯~þùÕÝío?Þ¼yöîW
-ùýæ×ßÄb
ÛþñFÄ:ÏÌâtD,ó\-v7‰Ñ±I´ö#Û›û›
³îÕ¹ó3:‹M¦Ò™TrîM[­´;@ܳ´1”BD÷Õ¡èë摶yÿÜõÕŽO«êÚ㡬¨÷S½«û÷\tÀE,`ä1Ê­ÿð„/¨,êªÃçêp»„ý[GCÇ®xäÙvƒÏ<ÚÍ3Ó{ÖÐ>ÜÊ,rì±QVü~Y4ÔXñ*[ªZÃ%j¡£û²ØVkšù\lþµ‚–ãÎvÛ~!ª<úÂʨ¡N·¯ÊzóŒg»Ä}Iç†÷u*²T$@ük£·íGeT}-vûmõŸVx'RëX8@áV•ïfN®Ge©'q›F^+æyìP|lÕ
YÁ8ÑvBÅ:ÍSÏN¤:Md¦’¶FÅ™“ö--˧B"Ø5mïÑqoXºÇú±X=÷U<#
$±M„ôGK6}løg„JÒ8©Y(º„ßáf{¼[m‚w©ÛÁ©Cì@#½ÓGh슯õNñ¹¨·ÅjËsÅ®=6ýœÈÊÊ8³I¬«MqÜö3‚ê$γÌ2ÈÑðçC£±‚[_
-&«§tK€E[ÀÁ‰òmÚAëÐAmjÑêÐðÖæ¦Ý¢8Ø6	¶]U'/­«®<Ôû¾ny¹Y‚‰ØèÔðÖºúê5 V–fja«e&íŸB…–ÍÃàrXq.yŽqÚX¸ŸtdìD¹"¥âD¯àtâ“]ä"N¬H'» ÉÃã‚wô32NTãl]ä_•ãÁÛXžJ“è4V2É'Òœù‚êÎWCbV:0}™J—\ÈȵåCÈ$ÝÖé‹SÛÔ®÷££îæÐ>GN|“Ós8P£÷<›bWy¬Ø0ºw+´à:ùItßzºQ€ð&q€›ÎT´n›¿!ze2êŽû}{èi¼skaËá8ÜoÕ%Å ã.˜ Ãç 
-Fðд륶Š=µýØ“ˆí3õAí6GDp«£‚i
-z|)˜Æy
Ë΂ßz‚äl!©¿"f±&+¸Úgj^ð|Lk¹ð7VGTlÃIó“Ò'6]úÄ[î8aæPÔO±zvxvëíZŒ²a˜k‡0×’SÂÀ·m™~W85æê™æØc·¨ï3Û|n@, q«;Ô'P-'9Œx¾8ä”ÆŒœpÂØ`"óû‡ÑÕóÉ«Ó•)ÒŽ$3A2dâ©Î=RÔ-Ë¢|ª–uO€%…°W˜ɋf=—¼eqž$>}¹–4ôn;½m$Vank^¸Ö€êʵz*‡F}Q~š7Lœ§Æ^g=PÍðž\¬ ø6Ÿ2Ÿ(A'&ÓzT¸”SÓ%S\ýíq¢I³1õü¦8ñ´†’,k¬Ä`Ð2,ëIÁu½û@ö¿PÈÓ*ó?•;8çò?løtÎQ44ÖûNJ8ä“BPö ¢`0ÄâìÝ*óêxȤj†¢Èš¦ë¦¯
ø•gê¦Ï¸ÙÛ÷äÛÀï´¸ÒN‹¤ä/š•¶îKýBR]6«Ê;•úëÆíz¹m—³&f%„¢"¿.Æ@5#Ç´iãÔ*5„`ë1TÊ9T±U×n«¾úVE}„ÓEYV{—¹º^³æédžã1žqElPui2(ÛÝ®cUoë~Ô óƒ£%…äi8βž›”–±*tÝÿ{Mºè¼Á¡í‹’‚v“ì²{جR›cÔzj~_-.ë»Ôꈩ®è’§º´ËS5J„J®K0P͈pªF¯dSî+‡‰;4|ˆ
-)±Ešªph±èÔ!íÛFtÕy2µà
-`’™z1‘ÎëXÿ|<ñVîEk—ÆĉÒ×= ºlëžÈ]S¹¿häZÁª*½Êy :g=MšSà=eýà«­A…ÞŽm*
ÛS‡‘A‹¡ýðúl›¦œy>”ÇÊn:©ìŽEcÊø»$~NÈN´ù|¶U˜F<÷[‹4εJ_rÖRêX&òoR]¹tOE6âÎa½ìÚòS5sõwÁ¹˜ëT3"LñÝÄ+eSÜ‘Bp3Ü8L¸Ç1\cÛÿ^ =t4ÀY¼Û½æbuœB]…GÝ®_×-¶MU}	`™	ˉ¤c]Ukn¢•ãsUÑ’«ú‘qßÄZèF&]5íñÑY2ׂáY¶ìJrï_²À]qLOW1Øôû" ƯÎkšÚB„QQ}ñÖŠ‰º™‚ßüR‘Çò#£,6®×‘R¿ÝÍ…¨ü!NÿØ?¶\s÷v߇:®@ÏÅûºŒx þÃýÇÕß1¦ÞT‡Žkê\o´a½Ñ^(X	Ê*}µØHuÑv²ÑÿEMÀ’ºñ•Uë];gùAÖÎÔ&')»TÙœßL?¡¢cH<²$!Š%#çÄ\põ2ÇhbøA֟ล/fŽ¥«OoÁ®yèòžS0dÎ
;89zí™+–=HRh nÆݱ“1ÀüI~¶9öTG«âK¿QÔøzÖwÀ?ú_þýâøãÎ$…3ËÔ…¼ô+/à…rJ–žJ>üÐñ\ôÿsg=endstream
+xÚ¥Z_sÛ8ϧðÛ93µ–ÿE^ŸºmÚëÎnÚK³O{û ÛJ¢©my-9ÞìÍ}÷P–m9ÍNÛ™ˆ"A‰Êr$à¿Y—¹ Â(&³BÚÑly!F÷0öáB2Í$MúT?Þ^üð^磧Üèö®ÇËgÂ{9ºÿ6v™Ê.ƒ¿ýtýþã‡_oÞ\æf|ûñÓõåDY1~ÿñç+j}¸yóË/on.'Ò[9~û¯7Ÿo¯nhÈ1?^¿£ž@3Lo®Þ_Ý\]¿½ºüýö§‹«Ûn-ýõJ¡q!\üö»ÍaÙ?]ˆLoG;x™A–ÆêÌ­SÏââËÅ¿;†½Ñ8uÐ~RdJ;5`@¥{ô2³!ØQnCæ4¡g‹bÛ”—­Í¸ÞгZáS‹®¸È2ã¤Ñ8½X,êÝdU·ÕÝ÷E‚¤<×–‰IV´µß>T
‰kÚ¢-—åªåײåö¡P@™‰àS’=iêífV¨àtæŒ÷L}—ÖŠSã¯zU6¯ mÍxºef´ôš!^˜ÑDÊ,X«"—)Lå~\?–›M5Ÿ—+~Ï|\ÐëºÜ\J?ž &ØŽQ 
(ÐG©mæµÕ‡ü\};‹Â,ã…È
+•NÔ¯zb8ÁF±^ál®jzrÐŒí%¯â>Q4„É=ÚŸÁ2Ä
+Î"†˜P6ÙHK'3eµÃó«´¾K”¤ËÖ
+€E+ˆÙ“G3ÙÎ×p¢9Z~Î
+Ô-ÿT-HïUÊëjþ-žp˜‘æ¥<£–îoi9Qšàc`÷!xys¤ïóÜ‚ó^p]—3Ú^íb>X[v\ßQì«áDÃÙ,„}¢Ag3b›R>xç ‹ôˆÍö¡h©µ«0¯Aº˜£@Ø…yÄäž‘d?T0#<ßxºf%QôdÜ¥ééÐBB§…)ËŒ3ó?È‹DYibBLƒ›{7=?îè'ý	§Ž|Ê7F‰rÆa”ãó~‚']²Ü—ðLJý¼"	ÒÞÛÀ›6­“ã?Ô»£¥x,ªE1]ðk20Ž_Ó˼lËͲZ•s´®„:&šFÊ?‹åzQ2Ä`Òv$á®ÆœœÒƤ(\z‹w×|-÷ÃŽ„¨:þ/=6Å꾤¦V¹óÔtÖjûšÚÿ{=<¨ÏÖ&‰×'",v³ˆ‰8ÚŠ£UÄSªUga­dô:ì"gž=îb?á.öߎ¨—C9+_ˆÛ	—VŲœ¨£!1÷N3¹%Ê@·D	±Æ‚÷Xô•£uØï#öG³4ÿ„̪W¶=’aˆÀqàß+ÇÑä6?Ü4²<Œ+†&Ñù‹XcÉÔGtqƒ‡¢
n3„ß^ì0Áødšaü•²r(ÿÿþöØb7QB
+•ÀNÅ°gM÷ˆ»~ªA€ôÌvÁâì6CE%D*NºcåÌêº!?ib¡·Šþ°¡s:aXX‰L¨p´ahl©…Åø^GhÅ*ž±PŠK6\RBçrŒ-ÄZÿ.–ÂØ!ÆxâžåÎÖì±®áà2ï˜îÌ"Ü4¯yÞ]Oñ0þc[nžq‚°sG.h DÆZÜ8†8ì*èÑ7ž8Ò­9¾<õf¹£¿ê§ûH´jv±j€ö®Þ.æ4‰Êè»/Û>W·ŸylHâ6ßS
 !ž&¼q9›Ç(תN.t?LÝžd±HWÜÕ*ÃÎŒ¯ë¶L°R±F0>/›Š4bnŒ¨ØŒnbÑÔD>å!šÂNP˜¦×«KŽ[1½Õ½ _ôjúιΤ`è.ÿŽô.ÞóÄ­ç®4Dw¥ÜÎ¹9,ÏÈĺ^Ç£M|»°/löíj^Äs]èeÊÑ°lÛ”¯y{ʧC>àô‚¥ømMýXÍËy
+õœL‹Ù×q˜§°¿\ƒN«EÕ>|BõuÝ4ÕtÁÃMyEW‘téĺ+bJ‹Ç\ûL8 ¢#ô‹ŽÀEǧu‰IHÊL¾<5m¹äÕ2ÜTŠ,«Á-î*
+ò·œä&7ÊÍøMÊ{‹{Ù6d³ËbõÄôI4´ùÀw Âó)€@#%ÒTŠò1ÌvgÅ"eÏÅb›¦í³8|ÁNTa¼{(™#×hˆp8Öå)’Ž©¶qŽ’A
Á¤K"(„&i»;ùaÀœS™ü d¢¬)Ë$ÇVµ{üæ'T¦÷×}R@ô6Ò+3t+ŒN'’7E„¶]Å„/EoÕ´Ô˜¡ôkw_ÝÓ§¶,‚µ0™3BzÐvÅ›8 ”ɳ´f¥ht›®¡dÛÏ¥×&¦àšË*è!Ʋø³Zn—ôÒÏ÷ñuYoWíÊÊáe¨I©Ä¼¼+¶‹v8³ÞÛ=.6GòÙhÔWpkW0Y•n¶É¬ÓG)"JÊ8°¼ 3Ûǃäjq¸H7m±i»Z+ÁÃI’f›j½¿•O4ÆNƒ¹Ãó>°Ì§z‹wsP«U
ž'8ZtY:¹Øôu#¸Æ„¾Î	D÷éz§OGS
+åüN"HƒÉrRÔMfÅì¡œ$¼=¾dWËð­;Ö`Lªþ6ål»iªÇr˜ãuæ¥Õ‡§{¶¨ÊÕ`i®¡þ³Þ_‘Ð5bõ˜ûµ”¶þÄi ,ˆîÇßýKªýÏÌ ÒÓÞŸ‰0*‡Hï	+…‹±þìW¤SÕÿb¿dendstream
 endobj
-1263 0 obj <<
+1273 0 obj <<
 /Type /Page
-/Contents 1264 0 R
-/Resources 1262 0 R
+/Contents 1274 0 R
+/Resources 1272 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1255 0 R
-/Annots [ 1267 0 R 1269 0 R ]
+/Parent 1263 0 R
+/Annots [ 1277 0 R 1279 0 R ]
 >> endobj
-1267 0 obj <<
+1277 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [389.4645 694.3759 438.2112 706.4356]
+/Rect [442.7768 519.0086 511.2325 531.0682]
 /Subtype /Link
-/A << /S /GoTo /D (configuration_file_elements) >>
+/A << /S /GoTo /D (query_address) >>
 >> endobj
-1269 0 obj <<
+1279 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [375.4723 314.3269 432.5882 326.3865]
+/Rect [361.118 239.5449 409.8647 251.6045]
 /Subtype /Link
-/A << /S /GoTo /D (journal) >>
+/A << /S /GoTo /D (configuration_file_elements) >>
 >> endobj
-1265 0 obj <<
-/D [1263 0 R /XYZ 85.0394 794.5015 null]
+1275 0 obj <<
+/D [1273 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 382 0 obj <<
-/D [1263 0 R /XYZ 85.0394 769.5949 null]
+/D [1273 0 R /XYZ 56.6929 578.6855 null]
 >> endobj
-1266 0 obj <<
-/D [1263 0 R /XYZ 85.0394 749.7681 null]
+1276 0 obj <<
+/D [1273 0 R /XYZ 56.6929 554.0828 null]
 >> endobj
 386 0 obj <<
-/D [1263 0 R /XYZ 85.0394 443.842 null]
+/D [1273 0 R /XYZ 56.6929 323.1321 null]
 >> endobj
-1268 0 obj <<
-/D [1263 0 R /XYZ 85.0394 420.887 null]
+1278 0 obj <<
+/D [1273 0 R /XYZ 56.6929 296.0587 null]
 >> endobj
-1262 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1272 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F62 1000 0 R /F39 868 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1272 0 obj <<
-/Length 3275      
+1282 0 obj <<
+/Length 3198      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sã6î=¿Âoç̬U~ˆúxL·Ù^:mÚÛó]z}Pl:Ö¬,y-9Þô×@€ËÞÞô&3‚ ⋤åLÀŸœ™$Jr•ÏÒ<ŽŒf¶Ú݈Ù3ô}#™fá‰!Õ·Ë›o>èt–Gy¢’ÙrðÊ"‘er¶\ÿ6O"Ý1ÿó㇇ïÿõñî6çˇŸoʈù‡‡ï	úþãÝO?Ý}¼]ÈÌÈùû¿ßý²¼ÿH]	óøöáñ;Âäô¹Àôãý‡û÷ïïo_þps¿ì×®W
-ù|óÛïb¶†eÿp#"gfv‚†ˆdž«Ùî&6:2±ÖSÝüóæ=à×
ÔŸ‘Ò‰šP Ò3™<7³ÔäQ¢¡¸Ü–--ªÙweS¼-Y•]WY‚íæVfó]u<€‰½5f^ÖëæÔFg
-‘Q*e2KÌgé…Ñ"¤"ùå”x*”W|Y¬ŠÕÖ.Úòûvz©â(S}}þžjB€PzS•%c	–[ÐŽ3¥ÜwØÈçÅ®9Öu4&°»æðJý]C¸cË£7Í{<¿Ö^, ÁôþÖÊ­ôÀ©îéµ³ øE"Ìü×­­. ŒÙ"Î"W)£ÜådöÒ©D9éð».º‚ äŒ_'	nZhÛh!‰"g@ÐU•»²{‡°†úE |*«Ê3të®÷]3+Ô~í—}IÔÞScWtG‚ªW·Já—GQ¡Åá šn[tBqJBÎÉ
ߺa„ý²²vm× L-òùa_Šêh	tª‚¯¤óvoWeQáÒAó;[ÔeýL]ƒçëdÑ/{ZÓ³]S{ãšÍnXÁh©´“¼5Z¢?Vh\RÎOd€ƒQåËå-!­ÂJã\Îï@[Ët¼"ýd_O,2Îþ͇8B¥i”ô#åX;åZ¦¹øn–‹Œ)QEm/ Më½Ç­Ö18˜LÇkõ;aØhá«ÕâÉí§Ñ0[>×N{¸³ÏöÐRë?Âñ…Øõ@)ßÃÓ¶\miü®x%`¶ÅËB¶@[ì,QC¥š,†`ék"ÛÁæ•5xÒ„
“åÈâÀq¿oÜØ5Þd°D5AZÑ´Ñ„*r#8ê8Vûb…›®r›ÎÈ}Ó–]ùÂ,’™EeÛöíDê§o	 ovsòPÐ>K·ž2Uêj-êDjòqøC”HªùCM˜‚>}èøTv[‚vǪ+÷.'Á—ÒžZÜ.%y¤ê}Yí÷UéB•c¸/E‡A#Ào  |œÐ|1Ô„SÝ‚Þ¢©µ-·œ$×vS€„Ôð©U\Ì‹‰4Qžfùõ¼R]΋=•3ŸÕ~Q•mgëÅç£=žgF-¢LÅæº=Õ„£Ì¨M”	“eà̘ÏI‚Iš…vºÚw[—¹²¶W Ë¢õš€]Ysneµ"Ró؇Í(sæµµ­fïiihŸM)5SèsÅj"e–BĪê\PÄ–R1&HNëWDP%@„Š
-B«¦î(zWÜ·mNì
-ô;„–ïé©kP}µžeÁR“!„N¦³Œô·&$ê	[ô«W.˜ƒÃx*ÀË]^‚†«6A³ã~ÎÿàOvÓGìy²ý¸}Ѷ.ÂLî#Yk.ª¤ó£‹pÁN
-!ŽÜ…„4D倛…)+[wos:G¢l15Sn	íÒc”‹$Å´Å:8È$’b“bþ‹=”ͺ\‘G.o%JÞ~¢æ$‹D¾ö’Ÿ5s¦¯ûiHuÙO{*—¿+*%‹pî¨p”Hdv]„žjB†±£æ‘Œµáœ/Ö‰¹·rŽVMÚ!„¸îj^¡	JˆuHÐ6Tì˜ì¬èAÒ¡®A’ÎÏÍÁ×q‡¸ÿ:±ÓênK_pôºã¢!K"“ÅoŠ†P¯o”ºÚø¢¤¬\I§‚ãQtl8O‡o"è{aÌp€W-áp•1ïâÕa¤«Ob¡Õ˜/Ö"/Že­íaCæK9Ã[Ã	ç}knïGÆïõF-vC<ЭV°}pܸ˜®bcà¤Å
BªËnÐSáJ¶¶8tO¶è®øûáÜs]†žjBˆ‘Ä:2KÆRˆáè‚Z„À¸#ôMÍÄ»e®‹ÚY=tuWZêsqq…g‚ãZÂíŠÃ'ç?€.Ú){×i¤áÜϺ†²ü¸Ÿ0d°Ž
-qH»£t†ÇëÖ¡ÓÌç©4\ÂáWvvœoÇYhûÙÜ&ÛÏBÛ‡1mÑ6uñTñP_F"ÜŸrp8,€Äiè+	
®0õÑ/dcÝœš±[Puuvy—SiÒïJ0@¡Ëa›\1ËMñNȻ҄½HœwÂyW¦È»O¦€=¡)L¬†².•!-Œlÿ«'ê,‡•ùŠ'†T—=±§êã媆+žh"•¤æº=Õ„cOœo³±\OçÁýÁ À®\-arøÊçµíà¤ú‰(ûEPÖŸ]Ê,
-
-]ç){Ú´ÎïÓ¤Éβ‡ÖTÍRØNE¤Í›”Ô»•Ìg øE·ÂïÀiNíí[B‘ÅöGûÆ/Ù7B}|Ù¾‘÷Æzœ}#€öì}C|*¡‰=¨w—9&Œ›w'Ëù"BåÞŽ’î$¢-ê^¬²Ÿp(£«Gâên&pÎߪ)èZ&VÙünãªò'”¯Å„pÞrpò^¶'û\òL|<š:|»ä¨¡¡[9 ì>¸ƒ¤Ö±;¿#’Jyj{ª\—íªÁ‰¹8B\oN-µqkè*«y)×D£äÌc˜Ø¨ªæä9=1ŸcÞæ‹,C_ò
/°©'S†§_'·¤¿tG©¶köþšgêK
-3®›Â^ÑùæŽÏtŠQÙ¥ØÉ	/œKtÔj%ú’;aøL°JcÀ­)ÐÿÄjŠ.Fð
àrâ8ž~éÑþàšú°_2µ?¢Ú4#gÇX¤1É‘JfÓu]–õsQ=âЂn·E]5´Ö¸–€’v%ŒŠæÚ°C`$ø¼¿ð‹dM
Ê~ðð’qÁ`šÃÖŸvÉùŒœ^¢C\µ®ùÅ-UëöU^‚‘ùñâ/‰×õÈ’„,Tºû¦÷Aüyu¢`΀á9àß|iZ·½hVF€ÇM3sݬúX—ͪÃBÒA¡gÅ·µ¿õ¬¬g£&fD”Ú8»NF‡5BÇÀÄŒ‰R#åù¦@1fŠ•a9íæM]ºÖýív¦žíp9_.Ý®õBÃQµâåÇŠäVP¼ ¨‹8–&–õvâXeÑv5׉*‹"‡PYaäPòLë¹I)ð±F‡\þ/ØhRÇதPÈ!èP uÛ°£a{(sV©õ¡ZŸ¼‡àg/›¸¨K‰±‘‰¸®K}¬ËºÔa]ºå©éXêëtX#$œª‘²»4|qÞchÏ4|tž*‘&àòå† &¢œÄ;»ŽJ
OkסÅýã„€‡ÞÅ:üW.v¾/]ŒÅiô̧ô€’Ld×ÙÛa½BÅùn”\%ÓNOÙ8¦†|òzÛQRDF'ÙÐxòÝÎ[g
"ðÙP²!š[¸Ú®ŸÙ½ЪiSoˇÝþku¹rMË“û¼jò%‡œñfÒGï(ÆÁsQ2´àåüÐÖ[pKžŸøAÞe[?¹Õ÷Gp§‘À•?›}©.†óQEs’Iä%„?-º2”jàLÀÃxŸÿG]1æ"oŠæ²×:ŠáÞ¯xÖ¯°ð2›ºig6µEŒnf`°çŽ#‹„Tò:ÖÇ‘b½%È€Œ{d±ÁƒštjQÛRÙÓĆPH{8fƒ¦—èÂWKxâÝhõxAZÄ}_І Ž5M.x߯ÌPÆFM?×-™¢t}õ+¶»Òma/o$ßt*Aâ•8ÐǺ,ÑË…ƒò¤)žÜlY@Üy-–dQ*¡B¼JB‡5BÃ0è(³lHÄXÊ.ŽBê§ì°\¶yåêCCXdÕ|	B*ëúëa×’81È÷Ø{iað&Ê@'H£²¡ün“—H†DøUæÈ_ÇŠ¯aûîpÇ݉Ê"›‰„¦ì#žDª(Ãj¿ó$k§ïÜ2‡"„6§ˆˆP>Oí¨£ex£!(§Åu^ìibQ´ý[‰Pabå¸í#”±°#)µÂàà‰X!—• ‡Ó2¦ñ×¢¬/­k`W¥’ð^:}ÊËCØbMSíÆdjÂZð±aŽŒ*ïi®–B®&ƒßîòUaÉãYT·ã7Î,x¼rKâkÞø´/Ŭ€:	j%•YN¤	:ÖnX9Tô+MÊZ/Y{l€ﺵ÷°®X{Àò’Zî.Ú¹ƒLdzýðkäôaižÂñ'§“}d¦gæ0èÌ`¯ð<1s˜étàùûŸy²®*×å0Aµ"Aþ¬^§&Ùì¢"$bQ¦Ø÷
+ò;R##¨Â{¦<¢…"2%Ó×:2E"ìÕ]•{é²Ø™‰gÂjÖÔ˯nDô&Ž€)ÉÕã;¤óó‡>‰ ³<3!{êd­ÉçBöŽ0äƒË}±kë}CÜ&ðäÓk¾À%Ôeþ6íª¨NÒ©k—à,ml8íòG;·b­ŸG[.ŠGöûI¤Ô©wsU}xDKÖš‚¿Æ
+”t
+§¼¢Ðé1¬{=†9ß’XçK׌:3	JCS¨Ê·£é¤R‘–"4óJHLœWwؾ®ÞŒì«MdL5NLþ´rÈ"­ã@BÎû>;o'p‘0C×S.žŠ•#×[®Ø‚ŒÅƒ^dRÈícMáI3à÷ƒãü
+¾!€@QAß!sê¯Önßø.ª	]TÓm8ôFJh¾n"äESµ½ôýت×UT¡_lBÜÂîèyPK-‡™„v,ØÇP"Ë 6bƒŽL÷¦>ž¬“ù…È0…	»ý™K×4áHߣ3ƒÏðc¬®g_¸°Äù¬¥YéµL{¯ô¢‰¢:ÞŽ3‹4'=©:ׇ–ºƒ.ê*:¨p-z}(êÐû+›¼	q·mKvãnÛ¬!Z+¬_n`aµªŸ/—SöGÉU¯ÜCºì•RèÀ,±šï¿à'—L¥WïÎOhtb£8MÄàxjïjÛoºd]›|*†ÜÇuŸ ÁœO@àÞLhöÂÌi³¦ü51éK•—<ÎùD´È€u…öDvÔ
b–Ù‰#éšøFrÙ&§«¼Í	ò:O.ù$K gqÜ»0¼êÀ’ÏÎ0Ï5ÉñÕ.k˜³¿!%Þ݆KÎxy+ª
åÔ}Û¡Wãë´¹mMûv€¶!‹Ñ¡zÕ)IsdpvZÕ<á¾-!¶QS#Φoi¶ó\áÂ3îoÀ]›¼Ä«ç·.¯ÈÛê´GÁù=a²kÄã`Gwz$Ó °=Þ`¤âÁÎH]ù†=äÃϤÂmÅž&çóš¢ëø6Á¿ÑDØ…à"gÈNÙ0@Š	¢|ÀÈÄ%ý¸cÄÂöyÑ`lù’/5dcÆŒÈü!ÿg¨êU±$‹œûÆQÞðÏî±¾Ï×\ú½J"=þ»øc*ÿïßh¥S¨(.ý«/¼Dù,;¥> endobj
-1273 0 obj <<
-/D [1271 0 R /XYZ 56.6929 794.5015 null]
+1285 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [375.4723 564.3095 432.5882 576.3691]
+/Subtype /Link
+/A << /S /GoTo /D (journal) >>
+>> endobj
+1283 0 obj <<
+/D [1281 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 390 0 obj <<
-/D [1271 0 R /XYZ 56.6929 564.5444 null]
+/D [1281 0 R /XYZ 85.0394 692.8552 null]
 >> endobj
-1274 0 obj <<
-/D [1271 0 R /XYZ 56.6929 539.4426 null]
+1284 0 obj <<
+/D [1281 0 R /XYZ 85.0394 670.2188 null]
 >> endobj
 394 0 obj <<
-/D [1271 0 R /XYZ 56.6929 176.3615 null]
+/D [1281 0 R /XYZ 85.0394 102.3833 null]
 >> endobj
-1275 0 obj <<
-/D [1271 0 R /XYZ 56.6929 152.4304 null]
+1286 0 obj <<
+/D [1281 0 R /XYZ 85.0394 77.0969 null]
 >> endobj
-1270 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
+1280 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1278 0 obj <<
-/Length 3129      
+1289 0 obj <<
+/Length 2542      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sÛ6òÝ¿B÷tôLDã“&Oiâ$î´NëøæÚ>Ðes"‘ŽHÅñtúßoP EÙ¹I&ã`,‹Åb¿(>cðÏŒN™´j–[•jÆõl±9a³[˜{wÂ=Î< Íc¬Ÿ®OÎÞÊ|fS›‰lv½Šh™”Ãg×Ë?’×ï_ýv}~u:š%Yz:×K~º¸|C#–š×.ß^¼ûÏÕ«Ó\%×.iøêüíùÕùåëóÓ97šÃzá)Yðöâ—s‚Þ]½úõ×WW§]ÿ|r~ÝŸ%>/gòùä¿Øl	Çþù„¥Ò={€K¹µb¶9QZ¦ZIFÖ'O~ï	F³né”ü´4©6"Ÿ  ¶i&…tìšûfÝÜ>žÎ3Æ’¿ñ@3!S‹ÜÏ9O­ÖÂ!rvf^ºi6œø±É3¡F³tAaÀ9ãÙKêH¤ä hÍ|rGš<{œîäóÔJaÎCµ^ÞÜoO¹IÊU¹¥~[n¿”Û;"ij¬Ëî¡Ù~¢gÔvw%amš¶{ MVÍzÝ<”K¸y¤öž¤’`©'û'Óf7Eû‰–­Sü˜ãSÒ*jÜQ©ˆ¬’‰D¦”†Ãvw4M,P~]”÷]å¸ÌfEÃQÃTDQ9F%C61°éXEFÃîwÕÂo_yÚ{™°œÒuY´½Ç´Åzö¨î6s‡zíŽËrUìÖ~Õ^E±{;­¨ö^"Ý«¶kÖÍ¢X£x^F}8;ÐÈ©7­-KMõ-š‹ÔZ­¦5œ:çi&¸:N‹Ö1 åAZ¡G¤öÆSs›ÂõåýÛ‡gÓ_ÃjÌ猦ÎsxüŠ$t=0)Žˆœ¥Z
-àÜa|©ðäþÉùX2@Sq`MK0RŒÜzöyÆS¦¬•„Áî¬{¸³‹˜½iàD³èPð<¦ì•‰èÖ¹ÈS–+`@ÓY¯BîPYl5@6Vj¦^//¦¨Tj$ˆMxY¹!•‡¶n:?°¹_—›²îœ‘Àé½@6KLY”>°ßÖ÷)ªš¶™Í÷.âûÔ3Ö)“
-ÔëŸð'ʨ47Â:™¡åYÊÁºpï©Òm³íÖU°»¢sÒ›6ñB¥VÁóØ©²1í}S·nDÂMÒLAÝ7—©ÿyWn	Ü4¹€e´=Œ:Cƒ02Üã`ƒfç€Å`tѸvÙÒB´šWW­³ãkÕl7U}K³ÅÿCoÂd¶%òiUئìp#ˆMØg’LÖÅÆCäëöç%°´Ô£m»Ý¶¦>¹« VvwÕpV%nwÃ\QÓÂêÜß²ìJ<9\'ús;þ
Ïs³Cz,®Kºðfê6ZKÿ·[àcÞl=á‘Êh–
-ÎnÛ+—#|ž!¼¼”ñl¦¤»À~ÓÜöÖÛ¦«(À
-èó?ØØÈ	©"/Ë…7"ÀIxjÌä
-ÌrtèõXÏ0rHÍËUHØÌ«0´XW½˜‚¶®I•p¶Yz¼ö®Ù­—1^±Ýõmt@]¢€N€}chÂc½.œåIqO‘Cs¿­àª0ÀÈ3 Rt4_µn(Ov-½)\S?z`¹ô¬¶¥§GF:Dr8¯N`]¢)
-±­~3&H¨l'¶ÙIÈÞCXˆðÅ”Š“ƒPƒbÁ¶4´po€%nª,p^ù©fë—Ó2ßøkѹ÷ì†ê?·;z!{Ì&ÿ½+=é‚(÷W¬¼ƒ6ˆ5`™^`zcâÎçyó\ 	Ç…‹dò䦤ö¾Ü¢I¤:'á›,ÄÚùhÐÉ›¢
ȧÕ#ÓþÝR/º4‰LÕ†¥N>&¨éç]åq=¥^j$xgO'­±Ë$^ç¢û¥ ÖǧÁÅ›íÑÐöÐÆAe*[½‹<4p;ÈQ
œ‹VÕSìÜ”¸x¿dáòŠOxvœ)ê) y4Öfž2ÊäzhŸ ËM>“9„yn¾%Ê€Ãs$Æè)Îc’‡A†{©³\ïwF67E¹È˜IŠÞÄd2P|ŽI•§F0>dòÈU‚V@ȃÀ1ãÃÛ© ’ÜzÛÔù«:ºD085lš`°×Þ—‹
-õyáü\,¼|Uï]QÄ]ƒ;œßÞ͸íÇDNãín(|Î.)ݳÉ1«ª6UW})©»·$œùć=çÔééäÃùH>œ“Bâ®í×6Ô‚?¶9º¾žŠëéò…–„¥\ÚMóe4Ò/º)o«º¦,Bšæc¢.7“ÉÅ'öù‚ôÛ‚_-‹‰?x.‚5A%¥Ž’>Oz2…w¢3ñÕ/Y“t>«ïHÀy&$}d{*îtHbLš+&Ÿ±¸Ì¦´v&2“jm~@Œ(Îc’S‰=òèÑžH$XªŒýNžÑÌÅ[üó¦»Ç%Љü›hûŸp“E´¯ßŸ_´ª¶ÙUåQæ7Þz¿¤¯}Çsä3p™˜ºŸðCœH}_‡ä~èŸÃ–*E®Î™?I9piÅ”„Ãë=9‚¯G맄͟Ú)3“òÞµþ2Sü	‹“öÖˆQ_ûчÔ)þúj¢*Èú_W|÷¼öܱ¬g̱Ïz,éÛ<0…ÑvÌyÿk°CÖÿ}2»Iendstream
+xÚ­Y_sÛ¸÷§`ß虃¿$8yò圫ozNëºOw÷@KÄ	E:"ǽéwï. @‰VÒI'ãX,‹Åo»Oüã‰Î³¼eR”*ÓŒëd¹»`ÉÆ~¾àžg˜1×÷oÞË")³2yr¿Žd™ŒÓûÕoiž‰ì$°ô݇Û÷7?ÿëîê²Péý͇ÛË…Ð,}ó·kjý|wõë¯Ww—n4Oßýõêï÷×w4”{?ÞÜþD”’>¯½»~}w}ûîúòû_.®ïǽÄûåLâF>]üöKV°í_.X&K£“gè°Œ—¥HvJËL+)¥¹øçÅ?FѨ›:g?¥M¦…Ê“…T™õç­Ì³‚s`*t™åRÈÑÊ‚ÏY9p¡•—­ÚºÝ,êv°ûÏUs¼o+óœ›$~¢ÂÈ5£ƒŒtà²Ì¸’|ªÄýÖ^.”ÌÓT¸ä©ÝS÷¹njí/¹Ií®ûìuj¿<ÖD[Å}÷äKÏFÔe羫žX×®×íˆek/«å6Hÿl÷/hˆ#JQfLqÜõÄvÈ
+GdòLU€5xVj-Sl×#c -˜Ô^Ú®nŸÛ^ó‚‘I$4Vv]=5uêž¾9£ï+svÕ—z÷´£¬ýd§Ó…ñ²«GáéïL3Ť˜Ê*Ïüæ¼®“½Ý¬Éiz;PcèèË~ oëûv_w«zI½`7êÑ!c«[.áøÀ³çó/ÏXÉøWÜ â:ãw²µÕ~x°ÕpÆ 6ÉBž×aäšQbâJfŒ›|ªù3Îœ°"8PÁŠën¿#ò¿»Ö3ï*Ô¹­Z‡zªþcOcÀO´*Áy=ÑvÕþ£ó WýÞe‘IN¡« ô8d@‡É
+mÊ)<ž·¶µn²0àh¿òàŽ~pe‡ãR›û&
³	û&Æ>̹³UßµÕCã§:Ô÷Ô®HQÙVŸ}üÛPðÄžáàœ¿ô´2½2y>èÅ\¯½‘·Ý°Ý~¨—ýÙ<<7åW”¹f´8ÎÃ!e
q,ŸÉ•‘>K`‡,@‹â8	÷ÈHÎB|Reì„{[³q†»·uH•±ßÛšßÛ û›³âØ°Sd?x-È°'x³è²Ô‰f¯ý-Å(úÔÖf¾…øSð,gùY4,ß3¦¢A;Œ–ž@„ÀñPàl‹LF$
+Ê&ÀÔm+îW£ʃàä{<½‡ÿEzR¤£((Ð¥D_·tò)©²”ĵÝV&p„77;‘üÔÁ†’xO^ð"–ì6•‹äBBU«$(PfF‚Ýܦ:—À™ôåR°ÔúN½{lìÎøWžÐÒ×?U@«<9y•—\#&‰lû}§Y,$‹Ã;Ä÷ai
+®¥>	eQd¥É‹ñÕ‡çpá3¸Nï]Dî;p…—™À•€)î+¨+Wæà¸¡°ôávÓùÁºKÉöÓSÕ€G*Í}r@Ì–8ÇˆËm×õÖ‹¨èÓºX‰£Nî\ix]¿)zn³…Ï¢k¢8y3©Iï1»(yZc1ȧÛÛ®a	’ôÆw¥òÌuà!3ÖK¸Ò_hhÙàƆ0îù‡Þ6k,¬Ô˜JßôP“{—^?¥2&Ê2
+úò~=ÈïªÖkWµ3ë8&ñ4¿Zù§…ϺPÓpµ·}?+™á"‘•ÓÃ<žC·¸ˆ%ž¢ÛÀ΋êîþª†åöä^çjliþ
+Ž¿¢!çp#hO”tÈ<=H^d…áåË%cR”ay0½§
a¿9B»ý£]Ö®è‡Î!ÕZ肧×Æ
–
ä
Í%?ÁÛä h¿TÕ÷õ¦µ^¿dÀVÀþåªÈ3é^&c¯ºíÚEk7•¾°¯ åBŒÞ`FrEý ’ˆU¦¹L\¸¬¿Þé±ëk*'pÀ¨äŸ‚RUtféJ’1Ñ,°prÊý‘Àãšu?(œ÷Jãg€xPy?
ƒ’ü˜µÈYÄ¿íö®´™H‰¶.ý#ŒÄÌox¶¶%–Ú¯âQ-ãC£{H€ƒÖéѦî°3 ûÔRb4WãEç-Æeâ÷N1Qz‡è;™1UÂ&mžãp&¥ß/¥lØwº¢áTÄjµòXžÛo†> endobj
-1281 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [242.0197 432.1255 315.2448 444.1851]
-/Subtype /Link
-/A << /S /GoTo /D (rrset_ordering) >>
->> endobj
-1282 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [238.0484 354.4169 311.8142 366.4765]
-/Subtype /Link
-/A << /S /GoTo /D (topology) >>
+/Parent 1263 0 R
 >> endobj
-1279 0 obj <<
-/D [1277 0 R /XYZ 85.0394 794.5015 null]
+1290 0 obj <<
+/D [1288 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 398 0 obj <<
-/D [1277 0 R /XYZ 85.0394 498.9148 null]
+/D [1288 0 R /XYZ 56.6929 396.8625 null]
 >> endobj
-1280 0 obj <<
-/D [1277 0 R /XYZ 85.0394 477.595 null]
+1291 0 obj <<
+/D [1288 0 R /XYZ 56.6929 366.1033 null]
 >> endobj
-1276 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F21 658 0 R >>
-/XObject << /Im2 984 0 R >>
+1287 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F62 1000 0 R /F39 868 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1285 0 obj <<
-/Length 2262      
-/Filter /FlateDecode
->>
-stream
-xÚÅY[sÛ6~÷¯Ðä‰Þ©`Ü	¤OnÖNÝi]Å;;;i‰²9¥HU¤ãhwúß{p£À‹lï:™Ï pp.€ƒsŽÈÙ	‰¤¦z–jŽ&b¶ÜœàÙ-̽=!žfˆæ1Õ7'g—,i¤%•³›uÄK!¬™Ý¬>$Qt
-pòæÝõåÕÛ,ÎOSžÜ\½»>S“Ë«Ÿ/\ïíâü—_Χs¢IÞüxþ·›‹…›’žÇW×u#Ú5G˜.../×o.N?ÞütrqÓÙÛK03†ü~òá#ž­ÀìŸN0bZ‰Ù|`D´¦³Í		ÎX)OÞŸü½cÍÚ¥“øŒ(“t
-@H¨BœÂP*4’Œ2‹àNçã„hŠˆTˆžQþ}ˆ†þ·€ÀlÎS¤(NgsB‚>Â>aðìÌM^]šý€N]¹e™5뾬·¢(Cš`þ,IRE’n~¼¸v½û&wD¿szçÈà›E2YI¦d’o†{!nìÙ¸±çâƞ¾7ú2ÜøX€èHcs‹µ7LÞæí._ç~°½ËZ׫òÖj†û*}'‘p“g—p—Ô0H‘fTYš›;ÀœJ™¬ë²¬ŠêÖ}æ_²Í¶ôsEYºÞmñÙíN‰Jò¬©«ìS û”ßeŸc‘ãè;mQÖËÌ3º«›Öõ²juj\×:Ó®
-'fÙ–{7²¬«
->óÕÒC½û­oö%WF‚Ia¸Š4iŠMQf;7ØÖ¾µÊ‰žòðU¯ÓÙjåti7ÐÔ»Öñ-*7¼»L8Òè‹×b‘7Ûºjò°,¯Ú¾¿ßç»"÷:®­zÓ7Ïí§Õ…1p4]‡£é¹MbL%ëì³1ÃfÕÞuŒ=¦íxô¡5#híg¦Hel†™ufXŽµk;3ÌGgF§ÅÄvÕ Œ[±nïu{C™kG"=
×Ó}ø“
-T[·l$Dûg±†!'‰ú[fFšl“÷¸‚ñ÷÷&ÁäGÌ÷;ÚRt‚^U·®ó)w­9Cù
-¹kÚ{K»kšZÞ†°,š6x #^
-”
-6íqí	1 ~}ƒMMßÏáI×y„x>)°s2¤¯=§ŒuA‘ˆ€Ë#.Mî‘x·[Tàu&=…‹Ä	·Lþy—[¯ ’Í}ÙsòÇ£¶íªq$™)Úû]eÏLUð=ž¼jìÞ™9ï—6ÙÞ
|òlàyZß—nÌÞ]há,þŠ1½½åy'¯Sîý õ)fñÝÕ'¶d[fK«5g µ˹çCþHÛÃiü
œUãÑÇ;BAàlð7lw;ØymÀŸ@^`$Rˆ2mÓfm¾qnDnóݦ°—9ØŸµ…½O@a턶ӲÃÁ=/°nD2 ža=x†»ÅÖA@øêó‰Ç œ¼Ï=}V6µëµÓ¸©âc.áŽAcaJ‡˜}7Œà•ž1ã¡‰‰¥Ýäîvæ:‹(øîèçñ|÷Åø=Þƒ£tûb³w
ÙH'
®FiÖÓi”tTOi2âf4AnK‡s¨%ïG!çÕôaàåíÎj¬8H’J¥3N1‚UÏʇ((§Ôt64ç1GgbO5³i*‚í¦oóåÄÁ q,Âm*ü«°ÊÍÅqÉœC?ì°æµ÷¸°§‹þ[ðÁ…âVè	’’LâuT1`„0”2ƒ¦I2ùbÄ:Žó˜¥…¬§íL©,ÙˆÍ<¸ùdÂYòÑAó¡Ýoó	³Á³IÃ9	D=«5àˆ•üŠVŽOY­5÷”¿Àêqßj]üù«U½ÉŠjt±1A’0ñõï8>a8ÃIæ5e¹FpëtßòÃë9a=EÔÜÓÈ7LÆÛ#»Q±¿¹2Ñ°€×Ä®B…äÖ§$ñ]sŸsKóäfLù—Ý,XåëÞ¿¤™ô^àüd6èüú_Ó®AjÌ@ŽSNyå ÀÞƒJÛ¼“e'ê¦cÝÔÝR†8íµÇt“ëfg$ð†“)"ûaL_ÝðÜzGèÕ5Á;þJ)ŸR+8(ç:¥þ2¡67%¨p‡,Çœ5-“æ7èÿïÅ0K§’bXUæ·™Ý?gå}Þ9éÝ„rJÁž>“𦺯|¨úzä´°FþÍ ƒB)Öê9w—q´é Ø÷¿­
-ŠàCyá¨n^¾Výf0
-î%dZ‹#,Ìr¸ßœ;„.ð3çç‹ËüˆBfbÃC‡è¢—
peœ³˜¶%GHâ¸ÝïGŒú/8,pÁÉ¿ë*Ÿ
-éͪ2GÃýæ"Eœ@¼#ó2´Í¾Â+¥ñóóY†Ç73¤8gOl «ÐÛ¬#«V®´ñ_쟈aï¢ùnÿÞ'hðŒ¤û¸ür¨ìÉ4ªY[Mïüh™Ivu$é„'_T4uí,ÔÌQMok¨¦pPHˆ†øMØ×[šºX/Ê1¦y%2×4÷k£­}7MØ•’Pº„0M!Lè ´’•Ù¾é×(ßüG¼¬-²œ‡ºgTÃø|OãÙ¯2<áWëA}h±qðª‡êÉš˜dZë;Á‚í6Ϭ.‡ðv?a\W†},„La1œ(Ojˆ ¤,òûQRBóKîDíÏž|Šžûƒñá×tn}E§ý”wg,(eËÀx¤yøey¬úŸåF˜endstream
+1294 0 obj <<
+/Length 3169      
+/Filter /FlateDecode
+>>
+stream
+xÚ½]sÛFîÝ¿BoGÏDÌ~’ËéSš:­;­Ó:¾¹‡¶´DÛœJ¤#Rq2þ÷XjIÑqñŒ	îb±X‹/J.üÉ…³©Ð…Yä…I­v±ÚžˆÅ-Ì}"g–1Ö·W'/ßè|Q¤E¦²ÅÕMDË¥Â9¹¸Zÿ–¼þáÕ/Wg—§KeE’¥§K›‰äÛó‹ïh¤ Çë·oοÿçå«ÓÜ$Wço/høòìÍÙåÙÅë³Ó¥tVÂzÅYðæü§3‚¾¿|õóϯ.Oÿ¸úñäìj8K|^)4äýÉoˆÅŽýã‰Huáìâ^D*‹B-¶'ÆêÔ­ÃÈæäÝɯÁhÖ/“߀œ¥ZXùEÛJ•…5óÛ
+P†L3Eº˜§EëÐb0¬“:¨7+òÔæ¦Ô«ôBÊ´°V¡~‘æÔš[:ÏH¿(aY¤63¥H­VÀ¹Çx{ºÌdrÿUr6ÕÐ4Ò³&S§î¼x¿©0E¡	'‚ýQ"ð/Ï·jñ]ZDg
+t—a¤LE+UžŠÜàö.u…Ôžá«»Š•é@mùL}{ßnÚÛOŒÓ4ö“±½ï붓Ì]RwôlÚž¶÷›j[5}µæÆäûP‘N%f@I™Öbm=ÏÐÔl‘‹åÁˆŸgžc›’yf6%g\FfËÙÜËo¹ÌR©áÖ!¼>üîÚ]¿©»žÞÞõeï¥Y` ×TkŒ”ƒF—J›dw*]Ru÷mÓù
š¤™’^¿»xGïï÷ÕîÛòM®`m£í

n÷›¾=Ž6h÷XFW­®;Zø»°âò²ƒ‡$¬›v·­›[š-ÿz <òpWáÈ]…|&lSõ¸xOc4Ë&›rËPWí>T;‚ê͆ç¥r³ùDo´m¿ß5ôÞ›ý°²¿«Ç³&ñ»æʆÖ§2iÖU_áÉA4ÊçvF#]ây®÷HOäÀuE@îìȼàÀÎZÍwq·>–íŽ	OLÆŠTIp»Á¸Ø´«rC`S¢ŒD[W7=›¯ñΉ•ÝÌV ;
ùÊíC…ðÅœ‰S€0.)ý= lGC+‡X㦦Îkžjw¼œ–1~»c·Ñûû쇚߅P·ä\ª5²'Šä_w“.‰ò bÃAžA¬Ë
‰?óÆ\ Ç…3‹äò亢ç}µC—胣ËIø.cZ.Ÿì6y]v¹eZ2á½EZA—¨0ÈÔ]Xêåã‚™¾ß׌˔©‘â]¼?õÆȪ7Iˆ\¤_H¿ô!Ä›]:) Ø3ÎKF>12’­!D;8
¹;ÄØc§!Æ¢WõÎ_®«MûÀq©å•âÙq¦læ8И<SFÙ‚\ý$Á¹ËÐu^¨/É2 ÇpÎ=’c—1Éã$Cƒ¿´Yn;#›Û²_Ý1IÙ›úŠLŠO1iòÔ)!ÇL>¢J™§Ê ðfMÚ©!“ܱoêYcuOJ‡ÓÐȶ
nߺûjU£=¯|œ'Ïëà,F»±
ƒoÅK•ÉG‚-Z$§³òˆ{ŒqJª™H´×­¿gP+ IE]]@9`ÀˆT–ežŠº}áÏDÝ)ÕqÔÍäuÕ±U‹ÔIó3s	çóLL)Eñl(9+ÁZIúí=Ðé†d5býYEI05]%Êç]†ÔƒoÙî»@¿ïªÍ
‹@M;aèÃu®|¢§!Vï7õªîgØÉLjõóÞC:å”Г¹âÙs ¸ŒI_Léò´PJv~Ô{(4g‹¯Çä@ñ	&D™£ÇL>æ=½.\TLÙIWmS‘²0Àþ¡% ¢2c%øQÊýýÆ"B
+3V<ÜÕ+&íK(®y%Ù…JÎ!+’VAúm&¹Þ!JCäÔûý2[à2ÿdg‡||œ ¼zýTã äÏÏP‡WVÞÇ©60¬}" 	Å«™(Ÿ¥Î¿B¬`ŠË˜ä\¬0àA…=ìüx@ËA®Ò÷¯Çd ø“¹MUAjÄäc&i 晋Áí±ÆnèYyï‡÷~°÷ó –‘ÞáÓ8|®îªÕŸ¤^`Z˜4¢Œí붬›ÐNè]†¨ØÆ$í`…4à+ÿxEè¸oúšsº’¤ÖLà¦Ý7ëÙï­/%Àˆ81;Ú¨1;ˆàe¯`vù®d¤ëʇ€¤¿42ráH­¡'cÈé-†)Ê‹FHÛº©·ûíÜž5Æ;vo÷VŒ\À\P»€Q¬°žÒ9jÍ9¾lÜ´¨Û=EírH¹Kü¾ðûšz_ˆ…Ñ¡öõüÐáXUµçÚ¡®Ú–Þ†U>ÈÄ›MZhHìç®õA .]",2]*_*CSÌ:j™±]byÓSÕ…†'àV57…;4SIÅ$¹7Íèa†7£oý3§h0têù(ŽwwíCCà5У¬C+ä¨cª*´Œåm­N~ð'†	Ø‘aÂ[I¶0Mý[OÝPIs®ÉŽ«ml è`þ[¹NMÞ’qŠ“›ÉúDÆxh§úðD}dµS…P}ä3£ˆƒ´l1•–]ãCÁÃÒ¼º¡f¬v7¼{(–fPì”Aš"t!#<”g,Ì‚…9sšé]F‡Ø±Þ¸®Gll—F7«±Ä^¾ÑÅø“`œi¾%fB$y¦”NüQÀˆµ¿Ã;à7xñ³äË—4sþ Øu¸z‘ÏЖG´÷E´¯~8» è¦ÞfojPDo|ØcEã{€ôm ïyŽbŽ#súaFcóýf<¤C?©Sä;œù¬¦\jNÂáÀ«M‰‘ÁדõO*rºSæfå½ïX™©|ÁÒÞñ€š¼ëÇ…ÿ“›z¦ÜÔËM}©ÜÔTnò¿–›üŸÉM?Snú‹å¦¿Tnú)¹©çÈM=On“
Ìñv¼A»
þfr$Ëg¾ßQ° ¯VöƒWšsJßYéÓäñÏB¦Ô UÏb/ˆ¯œ9Óÿ [ß @ˆëÝ®mÊë€w]Ý•jŸ^yŠôaðy@ŠÃq©BCôÍ!›F;9D»¹ÌìMiå’sßÖʸç”']½­7åŽ}?Âæìˆyx£Z$šž´À2=‰®¯¤`$ü¤/KLZ¤™‹Ë(ÇeTÎEÕÒ’–Çê&¨ƒÙß|hH|Ê>sA*^4wuq 1-ŽD‰¾Æ©ižÅÇÀY:†§ØÒóPTÁKœ©ü
+uüUàÌ7#1üîîÙ?P<ü?û8§ùü$2¸õE˜ò?Ä’SÎñã¤u*Ÿaýß´V\endstream
 endobj
-1284 0 obj <<
+1293 0 obj <<
 /Type /Page
-/Contents 1285 0 R
-/Resources 1283 0 R
+/Contents 1294 0 R
+/Resources 1292 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1255 0 R
-/Annots [ 1287 0 R ]
+/Parent 1299 0 R
+/Annots [ 1297 0 R 1298 0 R ]
 >> endobj
-1287 0 obj <<
+1297 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [325.3322 434.7534 398.9856 446.813]
+/Rect [242.0197 602.0286 315.2448 614.0883]
 /Subtype /Link
-/A << /S /GoTo /D (the_sortlist_statement) >>
->> endobj
-1286 0 obj <<
-/D [1284 0 R /XYZ 56.6929 794.5015 null]
+/A << /S /GoTo /D (rrset_ordering) >>
 >> endobj
-402 0 obj <<
-/D [1284 0 R /XYZ 56.6929 505.3435 null]
+1298 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [238.0484 522.6184 311.8142 534.678]
+/Subtype /Link
+/A << /S /GoTo /D (topology) >>
 >> endobj
-955 0 obj <<
-/D [1284 0 R /XYZ 56.6929 477.7522 null]
+1295 0 obj <<
+/D [1293 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1288 0 obj <<
-/D [1284 0 R /XYZ 56.6929 352.0635 null]
+402 0 obj <<
+/D [1293 0 R /XYZ 85.0394 673.0194 null]
 >> endobj
-1289 0 obj <<
-/D [1284 0 R /XYZ 56.6929 340.1083 null]
+1296 0 obj <<
+/D [1293 0 R /XYZ 85.0394 649.1998 null]
 >> endobj
-1283 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R >>
+1292 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F62 1000 0 R /F63 1003 0 R /F21 662 0 R /F39 868 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1292 0 obj <<
-/Length 3119      
+1302 0 obj <<
+/Length 2472      
 /Filter /FlateDecode
 >>
 stream
-xÚ­Û’Û¶î}¿ÂoGž‰^tãã6Ùô¤Ónzvݾ4}-ÚÖ‰-9ºìfûõR–lÙM&Mf"	@Ÿ1øËgi0©ÂY¢Â b<š­ö7l¶¹o¸¥ñ‘?¤úaqóúLf*P±ˆg‹õ`¯4`iÊg‹üïÍo]Ü=Ì}1/æ~3ï‡÷÷o	£èóæÃý»÷?þöp;OBoñþÃ=¡îÞÝ=ÜÝ¿¹›û<8¬v‡Þ½ÿùŽ nùåöaþç⧛»E–áy9“xÏ7üÉf9û§H•F³g°€+%fû›0’AJé0»›Ç›ÿõfÍÒ)ýõ4 Y YÄ¿Š-RQ8Í–Áe$AÇWŽ@ëìeA·b¼ÕñzcŃH2Þ_¯3ÎEïW± áp­IÁÇt¿÷¨aC©‚(9rÛÜP|˜û1÷ð¯ðîNïö9Š|R)ëÙçX¨”$¢lÎzÔA¼~¿³·œh68”ÛØîl‹Ír‘,	A)Àˆ¼Øj:V,´¶LÂÔ«®ç<òÝúU=ÌËum×÷‡›OSe—4mÖê½.Û¹/¥ðŠ†¾ee/¸6é­»ÝîÅî;³NçQÒ—ü!…~Á’!†>«®öQ.PDÈX¦3Ÿ®”®¯†]‘HR/¯tC‘+‚Mw8ÀIýyvò£áGÆÄ—¹±sÒDU£2|POQn‚Ó+˜!H2šÛ÷Y0úJ¤b5ó^ø}þ5v
-.y|t
->ó∡â‰Q*†)<0ÆÀö¹P^W‚6ÎâX>ƒ4ÜdH‘¢BN‡‡(g½‘Ög“ÞgÏõÏŽ‚¬Æ÷ÜV]}t¼SW…âÛ$w¾ÊJJ€‹þ²Òæ~N¬¾²+
š°Q0<¤àÆÔs±ÛQ˜XÚÔ;—™`Īç)¼Ÿ絋a}M-'ˆ]k»nÇ”}6ÖƒZc.î]IŒ"‘òBÒ€êJHrTNÓ—#RJ(Òëì{ª	þãˆùùXû8G±{âá{9_4ùÏÛbµ­„œ·×÷¯7€yò¢Ìê iª¦hp½'í^¨øˆ|)R—„ãÈ$åc§<¾ŸiH¾U‰LÓÈ{Öú¡YB 	¹$ŒÒ»%¬{÷pùšVÿ¥Ìa÷Ù«¬k,ef
-¤Ÿ;]Ú²oí
-¹ºº¤ñ#Ô¿ ªßßa±zûþçW´v©iG<$;J"eêíªÆ”Š4Ú–f„1°â½Î°fšyxh̵"Œ'o:¼0¤Í,öþ‘¾æQÁ‰9>¢náÏë[‚]C—g³âIÆa–j×™8=q˜is¥›æ¢ŸAu¤±Š®ûÙ겟õTÆÏŠÒ¯«ªmÎ`HÞs•uO5Á[ž$kB…|Ìܾ)JáµÓëZ7[ÏöªïjM¢
u[¿œÓ:ä™û`0‚ˆwMþžèü#çQa  Z`AÍ®@­ÆV€a´”›ía.WnA!ñŸÆff)ö	1„-f©·ÙSa.UB .éK±¶±n‹
iƒÏèóÙ—¤²ésõ™®_,Uhmè?Ü°Úfå¦o2"£zȨíC˜Ï ¤Ï	nk(õÖ¶Ôc‘÷[ƒ¬@îí0e?ðk·“Åqo4ÜL²)—ÜÆ ¬÷`ê£e×Î5‘Nö¬KmC°Ë—~û¬Án\‰ÝwS<ѱa²ÙeO–®/•qëÜ;“.ÐN[ÕóöÝ9š…ñÅ'×ÅaŠúH>oC"2€,2•bhqG-NÆ¡‹ˆ§‡qù@;WÑ×(ÃÐи¯oΔ–ˆíÃm|fz'¤½½ÞyãéÕ뤫©§ *ÝÇ{FwÃõTP@2舌2PêVKj9\’ý!À*7삃ãÝÃÀ¤\’à.iMƒ˜h»%¡P¨Æ²·Óà-»l˜ºö>f“ip¦­Q -Ø›qdïwlúD-ô».âœË€‡ôs×åX=¤º¬{*suyÙø]~ð›â/}ÞðRàix}O5Áœ„˜œ'c\Ã+96¼²¨-×·¼{‹íœùíí¯„Zv¦¿&GK<#½!1ER¼´Ú2ɼßÑꬱIL°z|¤/âÂöÑ*B„LÅÇÆ­]G)
äu‘LÆSumS䦳ǡ{ìÕ	i{q--fÐRxôÿw¶r›Í`:Må;ÌËwXæúc:6(ìéš®é2ËÐýFA]ûÄõꌭý
ô̱GÖá‹Øª&NÌÛò*ý£`qÜ$ØHl¤U1$û–Œn÷éè7½CÖ¸…[
-­ÝfKSKÂjÇèDt´g"ýªl2a[³£umúbƇlõÉš¢qé×.ó¬±æwBì:AlhL-m +	²vÆœ‘^øß02
-Âé&3ë»ßý?eŽ?©‡I 1a™N”°3$Ày­Pæ·O~*y$SxÔD2!úßL*úhendstream
+xÚÅkoÛFò»…OÔ¡Úîû‘~rS'ç¢uzŠ‡CšŒDÛB)R©8¾àþ{g_ÔR¤lç’â`À\íÎÎÎ{fgÉÙ‰¤¡f¢G1YnÎðäÖ^‘3‹@³êÇÅÙ÷/™šd$•“Åu‚K#¬5™,Vo3‰(šœ½x}õòòÕ?ççSųÅåë«éŒ
+œ½¼üåÂ^ÍÏýõ|>-Höâïç¿-.æ~I?^^ýägŒÿœ@:¿xy1¿¸zq1}·øùìbÑñ’òK0³Œ|8{ûOVÀöÏg1£Åä~`DŒ¡“Í	ÎXœ)ÏÞœý£C˜¬º­£ò#Q&éˆ) 0H2X²¬ÛÛb\i–ÝÖMÛØ!ÍêÊOåþ³Zï¦DgŲ-ï=À²®*øY¬<@U´wõîÿãn]–jë·]ÇòÕÊÏ4MÑø)ÍÚÛ¼õ3M¾)zXA9ël^4Ûºê6¶µ>H`F2BÐ; ¤ûb·vÐð#Уªnýà}á¿M½>ÅgYÜ
+FµÃmËuÛ%ÆÙgw¼H	Æ#Þ(?{ˆ²^æ¥êÉoà©	¿ÿûßžè÷øEP7éSÏŠÑÎSˆD„ƒ`@8Ÿ7EÄëÝ
+DUÝ$¬„rd8áÉ¿n«/)²Í¾l×ÛÒÊPÊ,˜Gí¾«Æƒä~6…h÷»ÊÙ,¯+¿’ŒyÕÜ9ÝÙµÖ¯mò{?ñ> Ù7Åõ¾ôs`î¶ø;ÆôfŸžvàWM³Ìêë°ùöé#*Ù–ùÒQÍPíŽå<`€©`ÒÎ8ÁVØêÖ†!Œ *¤üín˜ÕVø#’	Þêa›6o‹MQµþÈm±Û¬³!þóvíü	 Ÿðí¨ìä`íö
@ÆDÑ’ M꛸S˜Nî?‰5À¯>žtî $‚³7E€Ï˦ö£v\nZAä"Ê"úáPhŒ#Lé±Ì¾;ÓŒJ^-&ÂÀ^Á´
˜~qw3ñƒya;øYºaa‡x-o Pz½¸TãÝ
h2j´a=š±¾ƒzŒ’6K	ò*eìÐHÛr‹çÕ˜è%€+H´³Õ”p8Ij­&BS>!OIzˆÓz<åÍ"ÂYŠÑ³Ø#
c$•‡ƒÒ·ÅrÄ0(E‹èMëV…u‘¬†éëº,ë»æyˆ¸ SƒE?¼]–yÓøƒDï ‰ ’ á *!)f%&¹­dØWK¬Ã8KQ:‘õˆ# NE­È"˜%²²	wDd‚yàäÍÛö~[Œ°
‘Hí$õ¸6 G¬å7ä:b|Œkp`ü+¸>÷¹0ä1ž?[Õ›|]
$	ߎñã#Œ3Ì‘ÄÀÞ€ñgcœ^gúœ²ç÷Që§Il/"l´GNQi¼¹„ôÄ‚Ì~uð7µž’,­?¯­—«ï`F‡Ìn7¬ŠëòNØÒŒF/
Þ¨¢‚ίþ=¤á‘
äÑyât ΀EIÛ¢;Ë-ž¤Í¤´é´)†8í’ÚC´É‡isÆ™ò†„É4‘ý2¦OnL·!rí§”Ž5
+\nËyl}&ÍÑ¡ŸmB0;YF®»2¿×"m"ëáõh[L2#Ž[<‘ƒí¶È-‡
+÷~„¹®	z…(9
ª£Ê,*€ÚR"R®‹jþS®0ìiÝ7=#øɪ
+)å—"qÇQHî^YlL4`qIhël’ó	åGLúãU¢¸J@‚Ñhú¯!Zlÿi6x”XÁÄ`bêäÄ Ìa&;Fpß_nèä§Ø™$E¼³±ãHÒÔGµmy¨	ÅÜcÝåÂñ${·-Œ¸JìpJDæmqJñáÜC)SkC†mZƨ¿(Â×™›Ü[D…ûÁ²ë}iŸS 
2vŸµD7Qù¯‘²#cߨ°Jgüg¹ßÍ|0QNe¦Ÿw€Õ½Ú(ðÓÚX¥ƒÀ a‡Í~»µq×Ð~ÆF4µ¦È^…!CÛÅ¿`aT=ILíëŒ×º‰0Ò|I=ñ°kõýAP-Æ˹F(Ü,mc/}Ká-e1%Ôdû*\5{Aî™üIƒHa'ð<Ì,:MI²„”ñgm[z²àðЩfxj/Å)„5!½Sßþ鞪ý潿«Ñð®@Áu–uåïÌ?ÖÀä2_ú=ÔeGX)ý{ŸÛ°û‘¬«ÕzéÞ3“
+öó«u“¿/‹€Õb³B'Y€²-†Åí:7ÚxaÀŠ!4¦«×‹±–Çlêè-fÍ
¸êªX!ÛÄð9vqª“2,3DV£i,3 Êküà^¸"8äÑuµo‹ÆíÒQµ:ÊY›üÓz³ß$=“‡È—£6[ù£ˆ§G"Þuµ-9lHÎÉ„ÈàFÄFO½Ÿ=õ¥üàÐÜ6¿4·çPã³H”SzmxR’þ'‹¾Bendstream
 endobj
-1291 0 obj <<
+1301 0 obj <<
 /Type /Page
-/Contents 1292 0 R
-/Resources 1290 0 R
+/Contents 1302 0 R
+/Resources 1300 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
-/Annots [ 1295 0 R ]
+/Parent 1299 0 R
+/Annots [ 1304 0 R ]
 >> endobj
-1295 0 obj <<
+1304 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [326.242 275.682 375.5914 287.7416]
+/Rect [325.3322 596.1482 398.9856 608.2078]
 /Subtype /Link
-/A << /S /GoTo /D (dynamic_update) >>
+/A << /S /GoTo /D (the_sortlist_statement) >>
 >> endobj
-1293 0 obj <<
-/D [1291 0 R /XYZ 85.0394 794.5015 null]
+1303 0 obj <<
+/D [1301 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 406 0 obj <<
-/D [1291 0 R /XYZ 85.0394 667.0947 null]
+/D [1301 0 R /XYZ 56.6929 666.7383 null]
 >> endobj
-1294 0 obj <<
-/D [1291 0 R /XYZ 85.0394 641.059 null]
+960 0 obj <<
+/D [1301 0 R /XYZ 56.6929 639.147 null]
 >> endobj
-1290 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F21 658 0 R /F39 863 0 R /F48 885 0 R >>
-/XObject << /Im2 984 0 R >>
+1305 0 obj <<
+/D [1301 0 R /XYZ 56.6929 513.4583 null]
+>> endobj
+1306 0 obj <<
+/D [1301 0 R /XYZ 56.6929 501.5031 null]
+>> endobj
+410 0 obj <<
+/D [1301 0 R /XYZ 56.6929 144.8407 null]
+>> endobj
+1307 0 obj <<
+/D [1301 0 R /XYZ 56.6929 118.3973 null]
+>> endobj
+1300 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R /F53 967 0 R /F62 1000 0 R /F63 1003 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1299 0 obj <<
-/Length 3888      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]oã6ò=¿"«üE	=°ÝfÛ=\·½Ýôp@¯ŠEÛº•%×’’uýÍpHZ’å¸E±ÁŠŽ†Ãá|Ëü–Á?~«’(ÉDv«³8RŒ«ÛÕî†Ýn`í»îp–i9Äúæñæ«wRßfQ–ˆäöq= •F,MùícñË"‰DtØâíÞ½ÿîçoît¼x|ÿㇻ¥Plñîý?hôÝÇ7?üðæãÝ’§Š/Þ~ÿæ§Ç‡´”8ß¼ÿð-A2z\ úñáÝÃLJoî~}üÇÍÃc8Ëð¼œI<Èo7¿üÊn8ö?nX$³TݾÀ„E<ËÄíî&V2R±”RÝ|ºùW 8Xµ¯ÎÉ/Vi¤DœÜ.e¥°ÿ¼”y¤9$­²(‘B)>'e…RÞå_–}±_¶åïfzdÎÓˆs@Ò=Û=`Íl/ÛJÄ2™Œ÷ÿdºön)ÓxÑm

€¥r×ïhòðí‡O4úù۟ܺiÛ|ã-ßvTç;SÐð¥¬*·lj+kz>;Ó‚Rh.ÿ¾ËÄ"¯J‡òœW½iQ
- yÅYŒ§‹2¥„å5?ÜñtaPQäBqà»!@̲„ ÿeŠ9Zv¥é»¶,ŒCß–|ÈëÃ|r¶¬LÝUG‚æÅÿú¶3PæÀ»lñ¸u˜…Yç}բݖà~ä˾Ãí;x:6>Wßö9nÏÄ‚N˜·MMóus Akº®¬74)…X!À3§GÝÔË_ð|ÁÐò5xecŽ½`K¤n_Ìa„&û¼õ­å²é7ÛñiÈo<Ñêgƒ.Üt¬—¼ªZvÛ¼£ÑSÕ¬>Óp}È7;ºU#˜ïóÕgRO˜äuñ
-còiåùD>èN6N¼9¼zîFœr± ­’ãÓ•²ExÖ…Ùƒ†ÏhÖôìH9(γ9te‹GÂ91°2å³Cxê×Z#G8GÝEŽ&¾Cèl|³ü™¢nGncbë	øH9dRÚ©;u>+ÑY”*xëUÇ6ĺìØ960˜^~e– Æ;¸‘©“*Zǯ3°f¸ù·˜EB¥zÌƧ½Y•È:	’&7bÆŽ?;Æ;ÄçïM=ÂlýD±ÖœùjЦd Gg¡ÅÃæ–§
-øWNuN—¼öª+ÑG GI$#}ÆOÊ¢TBt{U¶ëgÔNŠZ“7Df‚×Á‰ó:8,[RS™
¯ŒAHbÂéig¾t3ºa+ÀOH÷.<ˆ$â—‡žçe[®¶°]Ì­…â“n;ÿÙ!gP¸%ØÎú]œ]îéA«ËQ¾x8ˆKïJº}¤[ӳ’w(“ƒJ‘ER‹äÊIu$¹C9ù-dõ¸/Wà<45_–$‰–—Šdì¼@ã­ÚG­(¬Á|cjsÈÝ2€mkfœ—2Š%X±dürÕìö kçGÈTÄ•VþœMS¡óLåâCÓÚ“|3îú²Å°œdrðƉÐrŒT”Ác¢„êŽd!¤jYœeá
[hyénTeÓW®-eê¬ÿŠU“¦¸Ÿ]¬"™*9”ÜU¯æÚ_ù.?ÙfW:	µÍÎ8ØÚÂIeµ5«ÏŽ§øV¦M_Ýñ…»þ'÷öÞP^+0«°Bã	‹@-³±¡ AÍ€^Û;pö4#Bð†^¡D“eƒ‹Aå`zñÞQßç+W}Ê\ÎÉ’yòVK”n;yĔ̆¸-íS4tªºéï÷6Õ#s¦Åù£rÁ¡"Þ&ùËÜQ¡¤zî¤6‡ ÛÕp™Môug ùr9'>„·	„û€±½%/1ÉT+qvÉX15â’ˆî ץ͟ÜvC·Ó—²Û‚Ktä¢ÍwndMÃÊ<›ŠóÖ3ìwiCd.œ2Z
Q“¤Ÿ4O^pQè2U–\·³˜« 	MÛnúCNAÉ“pí-¥>Ó0„Îì(¿Ã©Í0/³ÃS	úüÄ…hÂ]
-zÊ’ºÐ¹-I`€ÐÞãvï8YåŽñ'ãô	–N"bÙç¡,
-ëg¥^ØÓÊÔê<öäC—NÇá0^y.Í­<å­
-,Ú¨ ²^U}AU‰%:s?JCÑ™ˆ?''`þº†W›¢î•îó—°G±Xó±"]ˆX"Ž˜DŽqz«¬Iy“·"™¥“ˆù\…BE¤&8×?›÷“þ]HÓáÜ^è„4}ˆu9MXÖªDÛ.ý…ÿÖ›ÃñžxÂ2sv}Ê¥Y§	Í€5ÃçX’q'vŒ…³µl‚VˆåD
-².»’jhuªu›¬ï`q×ï0Y¥õ[¸8©ûÝ“	aQÀë‰o¦âNù®?´å3„ZCÐHUd–MßRÀ‰Ž–ɬî~¤å
Ô€5ÁH¨¡wAÚÅGv$u”Å!UøÛŒêHÇ©÷"¿¡+¼ÿ
GøUaí~N4›„$åï—h¦ƒ:’øõN<öJ
Ç7‡gªa]7…œ\yʲi~±Z™=H0 d\[æuö{r+É‹¢D;±×›p/VtÕqâ»Nˆèš8øJƒvà”'ØA©Ö4êúÚíæšAÉ©A‚o׎àj‹¢v®AàFÌ…H¹àfcŠÐ*pÐAsˆ-N=)6ìe±gXÀ"¿-Äi†!…ŒÀòË“À/Û-ä|‰*8	E¶Í
v¤z0B}+-'\;Ú9BÖSÁ“t9=¼¦r÷™4eXr;wùgãص—øk›êÙÌõŽNŠ…¹NÛûõHפ7U$£”ƒ#Ð|YŸ«ø~Ÿk/ÞŸÈÓÞXI¿mBŸ§”Ý°Ÿ‡ý¾¼"ådB1E¿©š`ÎyßÔ-u}d²8\ºr96äM€à#õ—áîl¦’l¤9¼»¡EÒÝÉ pÜÝ︶í/\œ,:ê÷s‡Á= auœÆŒAbY"UÚËA˜iA bc‹W¥d	Cø”F.ÔÖ8yrËUóâÊ»‚lÝ
‚ÑœzßÙ¢€P’cp‹É¦åÏ’Øåeír̉ºõ5™x1kl Û™$Lxx18ž'4ò”@xE¢0†*Úàw"ÓÜ{/KñÁjþ°õí	Ô¤‚[ÝõÈVâY[¦Øfzv‚ô~Èî`ýxšE*IÅX&ÇfbP®?#^©ˆ*¤‹¯$ Óö‹#ÐéŒc‘’Œc¡­Œ0q¬…“1.dŒSO nèý~o… §¦Gùàеèý¼&Ôr·olÃ×"ç2TÎUĵPc\Raü¡ç"2¤™iæóé‹ù¢„Ô)I•z=_b]Îy´®\—…©òãù÷*©¬ãÕÝÖÌö£å:R:æãý)²jð’–ÎùÍ%u%±ÆììÂLø¹Ét/Æ„¥Ú•+@ÀÕr0¢ÞJâÎF0÷‘«¥ŠˆÎéþÛ6¶²!C>ÔÃ$Tù*ÊtþfÐýB1Äë@£S¿Rd×è–H…šè8ÑA÷õ\È‘‘V©wïÁ³Q›I¨¡Ù$‡ýkþ.4E"üíðŒÏa·~³¿üåSéëH¦©¸ðÁL£ŽÇ”íˆsOÍ°A&fXÿ?Aȸendstream
+1310 0 obj <<
+/Length 3899      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZÍwã6¿ç¯ðm÷F*?õqL;™îìÛv3i/Ý=(6kÇ–<–”Lú×/@€²dÉNûš‘ 	‚À$¹ð/™…ÎÍ"ÍMl…´‹ÕîJ,ž ïÇ+Éþó–¨ïnþõ¯›»ëÿÞÿãêö¾ßËp¿RhÜÈ׫ßþ+kØö?®D¬óÌ.^àAÄ2ÏÕbwe¬Ž­Ñ:´l¯>_ý»ŸpÐë‡ÎéÏØ,¶Ê$‹H›8K`ŽY-‹XXÐZ”Ú|¡ÎöPÚ¦˵{,ºm;£'°r)UØðÑOn•:êdzè|À¶“™”9¤È„˜™G«Ø˜Ü2—ßͺ!Yÿ#¬ÐDnêîÐÀ³œ;áLŹ0êÏI.™}UTUÝÒ*îÛÊùó:e}¯,
š°W°–	¸±•AÄ‚/åvK¸ôàè·)·pðÛWzj×Ù²ÁZZAÁoJ?a%±,yoZ΂~žØƒZoÐð\l;O€ÑÐœX&—!iÈu’z® éóˆdl¬Ê./ßsͬ?F$_eäX€Ï®õ*KØE€8ºŸµÁ× ™|
ˆ—M¹ÚŒÆ`ûù“¥ß‘„<ë²*¯Ô‚¦¹¯›²-ÁõžZ&uô@i•y·ó6c@ü4“c§¾©ÌÂÀo]ᢙ]¾8÷…šp±”H4rƒÈH½¼¡Vþ<ü‘Fÿî¼Ì5µîŠW"VE×0gá7
+¬_;w(/ßòF®îPÑóg¸àAU¿~ÀÛøæã?ßÑØG3â&ÅØ!P­³å¶nZ¤rÒhC­Ô›Œïܺk¦ž»»Æ+Ò¸ó¦ÃCÞ‚[?}¦_©`Ç“ß>6ÝÀßw7DÓV|x
­IÞ°/–zÛyœm†ŽjOÚ\¹¦9ïgÊ‚iŠü
?p]ð³Àåý¬¬¢C]·ÍÄÇTk‰>viéžkfí‘Aè¢r#Ç‹óÍ‘¡Á³òeÕíÈeè(ñ—TDXš³S5ÔÕnŠ–(oæ6¨ükWr$A½ì¦!Ý‘Ë5í	;o>Z5;Yµ&–vBekN°X­Ü0=VŠ°]1pNDd¾ÞL6Ô—Hâ̦9_$j檱qž¦	3LG
+à„˜ì" ÌþH¨ª3ygó¡*Xm*cIŸ‹Æ	˜‹É0bJè€ÜB&â8ñÈ:yÎ
+ïF:x¤pz¸ä3®•ÈÂ6*(m™	¡BC.˜Ó…Œé±ëú|'\«î@íUÈ„8¢äDÛmýB$}ž´-weŸm»º³Ôœ`­¶õêçZ_ÜÖ7ÎFwF¦±ùÑÝë®>ºs×l"ÜÞ;“«¹fÏÝ^§¼¡qâAYŽ	ovy=×ÌF”›8‡”m¼‰{*aÈ”ë-¦¡0–"´-5ø£E"$]Nü­áøÐ9÷p>´›·)žK´ย_2‹GF¼MY=Q{A?¿“•iJž¾v¥¹Ã+s¶àûüÓ
«MQ=9NüB‡áBm?À¾€Ä~Mt{€„ï‘>a—¿4¸!—[ |òëµ7ç´:ø¤÷ã†h’-!.´ðf€*z/¬E½#HzèZj¥¤“9ã2.+@ëÃk?ˆˆ]Ñ`MŽ„ç}*ŸiÛÐÙl‹gæëfœzÍe˜-4 ¶>4ÁÛvüzhÞ#ŸC-„)G.ð|F\ e6´7ˆ¥Žö¦ÐÛérƶõ@î«é׫ÂóÐsŸãø6Ÿ^bk¹ÉÄðNX{k¡öàŽ§ïJwi4Ö?qP„§ŒþlLßô\(ùfK&i¤»õƒ‡[	Gä
/
+Á	{…àÃñäáÁ‡]D’•Žy}‘hÚîšP¨†—çnð•m±ÛÏB|Àm2l &ÚòP\­‡½íáõîÍÝû›>X[j^ç“q
ÉY.³ì2\¹ÎÃuÏån]5Q·ÞGMù»›½òXÉÌ\^¾çšY"ÐÓ±\ô‚@””D±÷iKªMÃóí{,‘ õËûŸ‰xè|IþÑ[EçÁ>qAŽWú‰kú»épÅãp—„ûbõ¼I.zæê‹+Ÿ1·¦ÈÂ;«Ó1PüŠÎv©¨eÄÀv¡ÃJE„zÈjAˆïÇÁsݵM¹vÄÖnJn> ÂSã–í|ýËp½úõZ\|ý¿®Áý¸5GKZ¤\æcyÀ„0lÆ!¨¨'½¬o^hhëš®ØÞˆøË
žÉ9|j€§5o™(|)ªØ«<­yƒõ•
+ªñùk
+ªºŠ¥Hy,'Ê~aÈ“c2,œ„ßXÐ
¹£UJN#?­˜HÓÕnȬº§
5<ÐóŸ6iá_‘V^éúQEËì¸!ùx(žBN‹ ò@šï<æÇxá'Ì~ú™«¬†¦“Ú;Œªˆ"Åp=é,2)HƒòD_¦Óy\
+L¡•’ØØ,½¸tÏ4][Ÿ”EÌxi$1Zk0
+¼1ÁuèÒ„g$d!ÕPßOŽV;ܨÜSB†Š$±n=÷
+ÉÄiÖ¿ÐáguþZF3a*"ùp Õ–CìA~ÆŽEUlÒÔžûì.wÞ:±MF$¤†ˆ„Ï="yvHØ̈„$K
Ô³ሂ„£‹ËH‚}Ç„4éß IËXFŸËæ”Ö,BrˆEø챉XÆ¥Y:xw	Š ·©`Î^ÐÏ‹°!lH¿iû!‹ ›’öøötÈæQÇŸ©ÌáLu¢Nƒ–áÍ5Ä"%Ì‹”/ýøŠ6²s‰e áÈ^°3`ÑhŒ	7´3§?¢0Ñg6þ:‡E\Û.›¾žM¿ÕÚíÁKÜifÜÇ]£Ð¢ÙüµÎ+úŠÒ‰h!âêÞWùô÷UÿÞwN1˜"•—ñtÈuP{.2cL†ðð·.ò_(´`Mtœ(]¢çš‘b­øæ^ÀQŽÄW)exkÅŸWl™fùämhuM»¢— ¡Øï)o
¹£Qg¶*•Ä-¸Ä¡x™ÛªˆµNçvêCrݶ¢ósݹÂWž,Ub­
+.
ýyXþzÍêsB
+g‰ÉßÒXaGRÒ¤»Ž>Pü)–¡<¾”í†8ÎÑ˦Ø1åMäÖ=»-1M8¬2¬H‘-z±'_Þ‘åé3…ˆióäm73Òö–PW¸ìSw(ø³B”ÛK.ÿÁ­Ñú×ÔüHæYqd¦Á>{˜8H—Šd`.\M¤úʸ†H…j¬!,xø8C+²“ˇr½ö0«S®þÓç!ð3,2ÃaÜã+¨¾ç¡h¨”Ñ¥MeµÚvk®ëã¤3çcÓ²'õç¡®ḆG‹¢í•¼
>„¹¯—µñ“㙘Gô_üå/›Ÿ}°C|ó2Âá‡.
+ë$î*ѧ’[
÷W¦ÒÑÿ­“š~endstream
 endobj
-1298 0 obj <<
+1309 0 obj <<
 /Type /Page
-/Contents 1299 0 R
-/Resources 1297 0 R
+/Contents 1310 0 R
+/Resources 1308 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
-/Annots [ 1301 0 R 1306 0 R ]
+/Parent 1299 0 R
+/Annots [ 1312 0 R 1313 0 R ]
 >> endobj
-1301 0 obj <<
+1312 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [324.9335 676.047 381.8296 688.1066]
+/Rect [326.242 468.2497 375.5914 480.3093]
+/Subtype /Link
+/A << /S /GoTo /D (dynamic_update) >>
+>> endobj
+1313 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [353.2799 145.2015 410.176 157.2611]
 /Subtype /Link
 /A << /S /GoTo /D (zonefile_format) >>
 >> endobj
-1306 0 obj <<
+1311 0 obj <<
+/D [1309 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1308 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F48 890 0 R /F62 1000 0 R >>
+/XObject << /Im2 989 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1317 0 obj <<
+/Length 3504      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sä¶íÝ¿bߺž¹UÅ‘Ò¤Ó™Ë/u¦ñ¥¶ÛÉ4郬Õz5§•öV’ç× H.¥ÕÚÉ´sž[A@[Äð-©ŒgÉ(‰Y²(vñâƾ»`gåV!Ö·÷þ$ô"‹2ÅÕâ~ÐJ£8MÙâ~ýóRE<º
+ñòÃç›O×ßýóöý¥–ËûëÏ7—+žÄËO׿¢Öw·ïøáýí劥	[~øÛûï¯niHYß^ß|$HF?gˆÞ^}ºº½ºùpuùŸûï/®îý^Âý²XàF¾^üüŸx±†mG"K“Å3tâˆe_ì.d"¢D
+á õÅÝÅ?<Á`ÔL•‹#.Ÿ gS%Y–,t’EJpaø[Û”¸À.—Q¬3
 R{°(!9Æ¢T%Ò¢KNº±¹Ä=, Êb8tÕSI èÔ}Þ”íФ¸dKõ7 Y¦‘7/Ôx„Ù
5I¨¦‰“v±ðì¸H£D3§^™Q@i™:=þÚä»òÝ×þeÿuÞu3DS	•;å¯oÑ´&ûmÞ»–“@yx*ÍÓåsU×$H!ãH
+É É•åEQî‘@’.J”
+ûÙrm:í~_5„‘¯×Ú‰9^è[Œæv¤b‘Y†Që™]	ð4J»mni¥¾/wÄì¬%`WÖjõCc™ì·UG0§k8Û¨ŒÛ¼y,;’çàíðàFªäÖŒaÿô[·å¼³`1ê:A×å&Å¢ŽY«£v~”Y¼d±ˆx`‡pDiÆD6døfÊó
ÍnÛõšÚD|‘(‹ž@Ûö™;Ò\h¡ºV†–€7ÛYBÆÑÁ/©:4rúqŠM<‘12)6*?dWîó/¥e׆ç¯kë§Òï/«ÕK¸ôp!#L¾¼ÞÈú_æ,ÝHªµƒÇ-A§üµ(˵›UuøßÍhÚfšz×ÿŠÖÉŒ³‰Ö±%Øæ°+Ýj¹=ìÊn¤²<­Ë¼¶&Á`r¿µGnµLóHèLí¬i›••Ø¾mœ·RtBK[e@Î	>2>áE>ÓˆV؃¹%¹;:záÏWw+nzrjjê0h©¿›;[\Cd™åTÆñòWHælVv Gyg¯Á&ï§ð†Øƃ«ÛgºêPp5xL}¸O†UÕÆ"Yî¶yg™3$vyÕ2L·34ä&Ö³†
+‚=Õ³,â1O­þœ½—'Z—Æ¡'m’öM„õrrù‘iÍÍŸX±à´Ž®FxWW»Ê’j3,Ž·3iíL8¶	¸w£îþëÃÌ
+FµÓœ5ÄÀ#éæÏ8S¯Y'âçűe¢²’z5ö™È˜ÅÃÒ@Æ’§$cɵ‘1KÍêÁ@ cì:MK󇽂ÚåƒÍÖ̲óó†P«Ý¾íJ‹ñð2³KcŸ\HϸMÏᦙs`gCÕ]*ÎFð6T
±Î‡ª‹ÜY_m^Vë²ÎO"PÆ8„ü`¯®î±f–(ÓmI6^Ÿne
.ÒpÀ[¢¹¤‚.3)ÄöëÎ@%hcÿ\–~¨Y“ŸùIh»€aÚÁve×åF»µ»MœÓ:ot¿i2äÂèT6òI”i©Æçìtp.zZA
+“Å
+fH6Ù1íd
+þ ›ŒÁ¯};Tu¿r9úLž¬î‚”9Ó#0Fd3¸®¼XEz$&R¶Ü›OÕÚxZ5q¶¶e½ß5!®«ü±iÁ»48âý–H
[š‘Üy'á) ìÁo{Ä¿A«³¹ÁIÄLÁÕµïÊaÝ®úv¿ªË§²^­[tþ´}ˆHåÂ4»Ë=µŒ¨p˜ºÄ gRc3ŒiLW–窔S*nÊ4vx\Pãv®^⟚ë	UÜáD°¤Š,3ZÌÙ©ÓHÀˆtÄΌӰXopqJ-Hš€cêðdc£S„ìXèT½qŒ€•2îjÏÛªØYŠì1ƒÃ2‘¤Ë
)ÿŽÆl°:tjžE˜uŽE§°³Ä)ÑõÍÜeþBCÆG(ßø…I\²‡.’+›ÂcÝ>ä.iLÒH¦Ç–æ]M†7;mGn0"ÈÀCv³×:‹Rž:sËkðÎÞä°²ˆ=À9S#ßïëZ‹D™™Ë»³Mc=`Tâ쥨±)ËÚÏ 
e²+­«.¨G”mA²H¡'ñ½Y$)TºŒ	K~aÃIÈî"ØöeÆ—]cËÀ·à`'ó¼IÏœ?Üp2é[®†Eqâókëò-ºÆ“7æ:D8F/ø[þº¯«Â„ÒÐsóò99§–p$‘N³ILóŠ'd,s®õ˜rÁ­Ql}‚íbÊ°Ü0î€ðam)^wB¬óáŽÇ2r+! k›éºYÉäe-Î̪¡2pS"âѪ6¦Hýò¦Ó;¨·Bl»Â´Éª÷í¡·³«œöÇEøФ' iŠ§÷$æ´9‡hù‰ÎÜ—ëÁqâ³k“ ã*/û¹+S&‘™óR÷?ÝÏy2h
+G‘rRˆ«!šUgݥċž¿åÑu¤¸¿˜1´Ë¸
Š á=5vªŽ~{7JbÏkêù#ÃŽo mÈÌsì9j‰jHÆïöe(ÚäÌÕC,™êÉQØuæËêF÷¸›´Î™ò
+xmmÃUd‚r¹/9œ3@&£X1ù†X¯ ÃB^·V:Ý…
1„RJ½±²ÇšYzœ<‚l¥ž¬Mf¨Ô‘	ÓëØÛ¡
+
+xà×Gvcd‡Š
+2Jy;„¦tHóœ¦,’Z¹¢ªcèœ!š‚ÃØq‘y3„àì)MÄXK~—=ÂÜä|0Âç±øæ$©H
+Œ9ÛëŽw´ù¥|%<SᇸNŠmÕ¸tß…(n¶
+rŸÄ†1‹U
+ÁV*Ç’ÙP€KmnS.•¦úæXÂðÛFž€±›ªKaÂþPír£ØX; F7hc+™©)Ö”TÙÀA"›¿Ô¥Dg”4Ùú?¾¸@Ìg³=uÍš±y )ò®§É—‹©0b0Š~€ûùÅáwÏÀ›ñÐ…€ë@­c­’go98Ð-žòd¢ãD=Ü7sWŽˆt’:÷î=Å°™ˆbObØÿ‹¿ã˜^€Q¾îïB¬óþÎc6VºªõIØ¡¢ŒALþêêifu1
É!­n=ž^^ý“žóy:ðyjâóôÄçéSŸ§ßöyogR¹4ëúctwuû¯«Û¹”AA¬%ÄÄãÁ—ly6ö`,V$ö0φ¿2æ–CÚ2²²ßíô¸‹7xƟУO°Aþº|+|4±±	þR*íO!l,1çR9Ñ	A8êXœuÙ-Œ:Sà°xèZï tø’¡øëÞÇ:âøÏ؉!vÖEÄ­39ufΉ3PzªŸzäð™'Å&·å«¼Ë,RÊב&¬®½¯›cœXª'¥8§È‡nV³5ܺê­w0q™9,s«b‘Ûä¯Ün]ðÑõÊMno~íˆM“N†3ì¸r/¯±:ó\·#øÛðvœ{{))ðÊtV¨3ù&Xgœ%Ç繧8#GïLDÍ9øl¿è|?˜Ð˜ÏTpõl÷j·ï_¨ùï·êµô!Æ9וH½v	|O¢â,€‚‚ ôJ¢Ž(®´P”ÿÝç÷7>½¹£_ûyŠÖv¶©_ðÈà}ÉŒ|:¦X>Y|Ã%]3eÜkÆä3 T0ÏH™²¾Ã½"¤n‡æ¾#¨÷láÓxæ™r5¤#ñÜ#µÈcº¯YpÝôå¡)û?Y:ä(ë	±Î$é…s&ÄGÂRóQQAßÅÄRBzž^´öË
á‹YÐDCéöyQÚ	$‡~844~óÓÇÏ?¼¿¾¡^øÐÛYZ-Mh†¯Ç¶IX\®ŠÕì+i›$Õ¼¨pOJ'žiíä
b÷h~£§”_µ-ÃÄ-€‚B)ôn?} ),c©cNû8–,…€,ƒÂw8…‹Vw-M­š¢ÖåÙW.ø„cÁFøýjˆ-¯|R2*HÀ`4††uTQa¾-¨›r¦óŽ^Ý%ü<©ùòMS[Ä)Ê8ŽCFÚýjN÷r÷éÛ˜ÁðíZzК/Mûܜ̜‰„]¶Ž¬Ù
+X¼pâþŸ¿K!tA?óÑšÆl
ˆX¦Œç•§1¼ý€ñ”õÿæÏendstream
+endobj
+1316 0 obj <<
+/Type /Page
+/Contents 1317 0 R
+/Resources 1315 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1299 0 R
+/Annots [ 1323 0 R ]
+>> endobj
+1323 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 244.9849 116.59 257.0445]
+/Rect [55.6967 431.6566 116.59 443.7163]
 /Subtype /Link
 /A << /S /GoTo /D (view_statement_grammar) >>
 >> endobj
-1300 0 obj <<
-/D [1298 0 R /XYZ 56.6929 794.5015 null]
+1318 0 obj <<
+/D [1316 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-410 0 obj <<
-/D [1298 0 R /XYZ 56.6929 320.529 null]
+414 0 obj <<
+/D [1316 0 R /XYZ 56.6929 504.3703 null]
 >> endobj
-1305 0 obj <<
-/D [1298 0 R /XYZ 56.6929 292.5255 null]
+1322 0 obj <<
+/D [1316 0 R /XYZ 56.6929 478.0508 null]
 >> endobj
-1297 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F11 1304 0 R >>
+418 0 obj <<
+/D [1316 0 R /XYZ 56.6929 168.112 null]
+>> endobj
+1324 0 obj <<
+/D [1316 0 R /XYZ 56.6929 141.3042 null]
+>> endobj
+1315 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F11 1321 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1311 0 obj <<
-/Length 2800      
+1328 0 obj <<
+/Length 2360      
 /Filter /FlateDecode
 >>
 stream
-xÚ½ZÝoÛ8Ï_aìËÉ@Í凨½§´qz^\“^â;,n»Š-ÇBÉ•äd½ýÍp(™rd9ECˆÎ×oHšňßEšqû£0ö™æBO|ô}/„å™4L—ëýüâçkŽb2ÍWŽ®ˆñ(£ùòwïÃ?.?ϧwã‰ÔÜØx¢Ý\%¦Ç‡Û›ëÙÇß]ŽCß›Ïnoˆ|7½žÞMo>LÇiòÒj8!p=ûç”Zï.?}º¼ÿ1ÿõb:o±¸xWäÛÅïðÑ`ÿzÁ™Š#=zÎDËÑÓ…¯Ó¾R
esqñ¯V¡ÓkDûâçëˆi飉òY€ŽÞ(sÆ5Dmê˜Jª6ÊRôE¹áÂ(Wiùœ–cy“lyŒYHͤŽäÈUüÊ|ËÕc_9ö…âLªXw˜¯Sˆ{z3Ø ðŠ½×Ô4.bµ.v›%Ñ×é¶(kê{ÎêHèýÛ.-÷'tæÉSŠha"ÆŽ‹2à,öãÛìŠÝOïþ3½#Ö0Aßr¾dõš4×û­ÕÜ	¾¯™<°ìóßæ=*4•¶,ïÈãÅ&©ª}ŸKª(‚øk-›Es{ߣZ…,QhuÃR±´¡…·-³§ÄÄ
-¨Û]¹-ª”^LààYíkâŨfiEäÌ>ë¾/Ó¼/[Ye/댪Òóh†¯Ømzóý"©jkÕŒ¼+ÀBèà5@˜’E½K6›½}Ë«ð2¤×}±+Sœü*Þý6]€§È÷:À’‡Db²î:1Êò"OÿÞë³Hˆff,³*yؤÖÏ-¡^¤UÕºw49/
nBRcÕ§ì8è»ë+ŽÃ~וÞº¨j\}îÇŠÅ¡ŠÛ‰½ÙÌ"Ùá¬PŠ›Õc5áÈã³í3(\ô–TÔ½*v¹}Ø[k+ú˜Ö(4!ÜÂW,UÐpÔø…kÿ‚òõj—/ê¬ÈqP·“èËt•ì6uOx„Œ@¡õÆçu@|XhÀ$†mRÖÙbÒ7.»
/|hánÉVU¨[§Ã&nÐ '£%´ð5 Ùôd¹´“·@ZQŸèíîú‰ˆXDVÆŒö¡O{
-’B‰…½eÛT‰fùb³[¦}°Èc%<†dæzýä1ÐgŸŸ"™)HDõáÂ:LQ“6«ì1O—¸t0†*h5	o“å_‡t¦•Á-¹ñØu¤ØNúæÞC²øJ¥ë LµMóØ°ú µË¿æÅKþJÒndh$b2rs”±Ýa°•Ô5æôŽÓìâ2…µô”å)½f+ËK“­HÀ$D aæ°<r!Yî‰þ™UuEmN_È›È³Äa ùÙ¤4µ?X6YùB©k9ÁäÖH‡‡v{³-Á']™àŽuØÃÚ°Ú`@‹òÛXX4µ|Bô°XèÚÃSÒH'UÚ3ív¹Ø•¤?·›¬²-óòÚ’YõË©³’†mB1x2<ð˜ìQζ
-ÍHµzÐß/öÁãc
-÷Aćìµ<Ç»_à<Æï× g³›ÉåÕÕ»¼û<†ÒË“hñ‹Qñsx®Ä
×yÌCVÔÇfûq»f…ߌÝð“ŠËaì.×iì-×YìƒVØ_™íÅÞ1+5œòƒøíøá£?Ïâw¸ð7\çñYuð›íÇïš•kòíøµd*æê~‡kÃuÿUÿ±Ù~ü®Y©±¦qøsàÃÎùþ™88\qh¸ÎÇaȪ‡c³ýqpÍröc³ÏÁù˜	Í"u6f×@Ì®ó1²êÄìØlÌ\³âÿ3‡Lk~¦êêrŽYËu6fƒV1{e¶7f³Wìñ¾
{Ãá˜g°;\Ø®ó؇¬:ØÍöcwÍFlú=è±DŸEïp
 o¸Î£²ê ?6ÛÞ5z,ÆžAïp
 o¸Î£²ê ?6ÛÞ5{ù}è¥Ï|Å£3è®ô
×yôCVôÇfûÑ»fߟD?šL‘€Î*a¦Ø%t{þ¡‚„ô*­k,¸Ò›9ýßWðœ¥/ÔÚÀ±}c˜ãÐÌAŽ·[jútµ¢•å[QUç
ivèqEß%q¤=ëÖãžÒ‚uAi8íÓ2«&8Ä;è,¶x‚¬¨ËŠ•)¤´¡ò!.ЗD\Üjãt4îµÂâ2ÖžÛ&Œª©ÔÁ†QÙ0š‚öæ8~ÖŸËl¨|‚'ËEïÓñµ9s¾£ö¾Ø5ÇÚ¼Ã{Tp*oóqs*n- tY3T¾Á£ïŸÉÓv“þÒsg
-*X	ævË­3Þ	™
8÷~b?õ•Ü'}:f+*ÔØÎX{;{€åǦìØ­Ö`Ý1É›Zf·ž„f®¼Ã±fÜ¢g·‚f×ÉsêÔ4ÛÊW|˜?­Ž=Å‘£ÖwØØa­bHejŒHÙ–X Y¤ôV¯3+ë4MJûb.#àiJ&Øx0üvÞ"« Ô¢;l=%¹-q·Å_’5ˆc™ºôkLö:*_•IU—ãÈÛ-ê];`¡pŠ·ðb™¶\HMS²	Å¡F
-2۱𰂋ë+TÞ}AtòØZAtñĶªdQfNù؉—Ôõ/OÓ¥™¡¹Ôé÷Ð^¬l7žY•&;âB\'yžnŽ–Us‹ëªH¬Hò’Xš“Ó\©Sa„®¶x~b‹oNô›®ç…„Ïí÷_ÏøH1úò´.’ã Ë6‰®*çgœ…¼»E¶†­zE;¯Gߧï£'_èÀ´™2
©½Jº…•" ÷Âzñ¦Çq>äGqÀbAf£o#ÔÇŠxœ¶Azˆ€!ü<{’£«ðŒHÞ‰£Ø@
-dç¦-d"ð€äwjŽaä•)M̯¨ðÔ
-ï¤ä±„
Šfkä­Æ@¢eÖHäý56ûvjÙÚì\&%¦têLLqͶLjCjJÚ®¢ž@€ܘbn 2Ñ3´Ø€`Û²8öçôl ë!dÆ«žÜ<'õ[ƘåÝ`‚ëO¶U4ÃY›‹vøØhfÔR¬,s¼Yéò/ÓtÛD;ËQ§F™¦­îŒöáܨ@œÅôcËŽƒx49ü燓ÇÀvø¨‰õÿˆÈ­-2E'j|Š,’1|ËkøúV4È:­VÓ‘<°9Îÿê°
Üendstream
+xÚ½ZQsÛ8~ϯðìËÉ3µJR¢DÝ=¥ÓóÎmÚK}OÛ}P,ºÑŒ,¹–œlö×HeËRz™¹É´‚@À‚ A™ÎüÑ™à>	’p'¡Ï	å³ÍîŠÌ¾CÛ§+jdVháJ}X_½¿
âYâ'‹fë­3–ð‰t¶Î~÷>þóúËzy?_0N¼ÈŸ/xD¼«»ä$øøøùîvõé?÷×ó8ôÖ«ÏwȾ_Þ.ï—w—óœBfF¸Ðávõ¯%RŸî¯ûíú~þÇú׫åºÅââ¥$P@~\ýþ™eû×+â‰à³gx!>M6Û]…<ðy–S\}½úw; Óª»ùÂç‚ÅdÁyâG4)Þ¥;™&xÏyQ •6Üí|i*|f²‘‡]^J|Í·êz)¾>ó¢Yä%¾ýUY±´8Ì©ðdš½ Cþ™×Mtu0c™÷tÓäO¦ã7Âɦz’ØݘøðÒSº­Ï©ÈUY¼¨éŸ,(õΙèÈäåwœ½LnŠô6yU‚ŠÌ´Ì0~ª¬$6D#­,>•—^4ÊMcó˜Úîi-}k#j¸6nýhúlŽTQš.x	©j;¨«6Êê¿_Bû<…2¾è)34tb&RÎXÊêo„ƧJ)	¡Skm¥ÎÕöB• Ã¨¯–ø«»ÅõÍͽ}ÿež0ïúòH@7.¢qä®Ôeä­Ô$òQ­ò3µƒÈ{j)‹_=‚Ž4™˜uWj»•šÆ>¦ÕÁ~ªv»«–qH¥Qòzüaì‡q25÷ŽÔ~+5L«ƒÿTí0~W-óÕÆÀ^b%ÉÔü;R#ø­Ô4þ1­þSµÃø]µŒsßý÷j?@ê	™ŠGjÄVjÚcZ?œªöƒ«v7ý­¾D“>ãt‚ˆNÄŽ+uÙg­Ô¤ÏFµv>;S;賞Zúÿð$«€ÑxÂgŽÔˆÏ¬Ô´ÏÆ´:>;U;ì3Wí«ð¾;$*&›ÀîH`·RÓØÇ´:ØOÕcwÕ
+ù3è!M±Mͼ#5‚ÞJM£Óê ?U;ŒÞU›üzHNŒSsïH ·RÓèÇ´:èOÕ£wÕ^ÿúÒ‚‰¹w¥.£o¥&ÑjíП©DßSûá"z(X`\EýÊeiªÊÛj„B]†EòkÙ4éCaÞt-"Í£a<åò©B>ÉÂ ‹0àér;î÷H†XŠš®µ‘Ûbtµa­î|$nòZéÏPBXÌ[‹*GcBÀ¡¢{”‡¼Ñ#‘·Õ}ª6V{UGÖؤ«b`ÊÖÀîüme…̬3¸ÖbPY†":&qHËïÒÐý[
`ØXy§æ.îÔÔÕ±02ý{Pû˜>eØcÖ†aãÇêêÙ7莵ª_ÀC´AGusçöÀ[•ÈÙÔ5ÍFâ[ó˜›.°Nez0/j¥ª§¾AQă–7q«êN©ç¼yDj—–/Hý8‚ÙÖ˜© D&]
üv^niÝæÂ;nšc;a1…¼tPÎÂŒ+ Êt'
O_àÀ†®mŸýœzéFÖj}Å÷µB>ZìvÚ‚wl÷ÔPuº9èU¼ÉÓbÀˆgéÚWJ™éÐPcTCö í=Ö¾¨^ìªÔÙQ-ÄÇ´,eq²¬”GÍõQQ¥¦Kúœž“ÓÜ^—ÜMi‹Ô>a­;y	J,7_‚zø<Ùå±°±i{ô‡êöfÆ"è*M²õ1lÎÄ© 3X6sYêd…·SŸ,ןa­PȾ°b¼å©g`ÌJùãÌ××ó3¨RÂ4h!‡ÖX;hÆûÕŽÍn*@4s@ÙîÈTÄÜN{Dù"ŒŽÝ;ÈXx‰Á™xûô€‘À…iViÉ{š3ؤ0b…·—NÒ­áý5×{·4bm)‰çL¥ulLõ5+vë!ÛŽe&H^H]­¥‚»}æPö‚o}JP-ä(ôn[ Ânª@W(
+·¬³!À0ˆÚœDl’ ²OÄ& w)#º»qÑmôŽÅ54€o#ƒÌ­´rWÙ÷#X½3TegR-Uˆ¯´=aR]2ê/ê¾|&åÞ::/;‡#q²µÏ
ç0‰ý(ˆ‚™»”Þ¶:Uà4f‹î{ÇÛrǯ‚°4"Ÿ\ªÒá\Ë…:B«#yœ$]N ßOZ)5Ax®À\xvnC_P8j»ãžŸÛ­Ô€úÞ¹=Lü8áI_ÿWu@ܪ]3H¼g½ã(ʤiµ³™vCŠÂÍi5ãê‰[3˜å!„Jµµ(Î×Ï×nÓ¦Â*ÈÓ[¨"Ld+RAÔÇ4 8>é:"H|É­àe÷ÙÄ>#ï»v7*Oö%5þßLÄ×ÿrcwH8¾dç;”™oÊ!&‚‰heFeºpØTe£ŽgñøŒ+neÎ4÷b‡P¹öU·‘ ÒF‚Ê1ÖÍ6®¶q•ÛPP´ÍQ&†'¡ št(tM](¨FI4j@+tnAßÏÖ%Mz&Ü´.
TåOyvÔ'xozÚy–„èYà9žÕw¥ƹ* mÙ­ûö40U®CA;¾bí
ð”´ˆÁÚ˜'ýš¨™·ò}[ªç;9rœç¾ú€I{n~óÏœ«³Ø„¸ô‰|Á’Ø¥ÀEüÔòöwç¦ÿ)ºûendstream
 endobj
-1310 0 obj <<
+1327 0 obj <<
 /Type /Page
-/Contents 1311 0 R
-/Resources 1309 0 R
+/Contents 1328 0 R
+/Resources 1326 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
+/Parent 1299 0 R
 >> endobj
-1312 0 obj <<
-/D [1310 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-414 0 obj <<
-/D [1310 0 R /XYZ 85.0394 693.6703 null]
->> endobj
-1313 0 obj <<
-/D [1310 0 R /XYZ 85.0394 667.7108 null]
+1329 0 obj <<
+/D [1327 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1309 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F14 685 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
+1326 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F14 689 0 R /F39 868 0 R /F62 1000 0 R /F21 662 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1316 0 obj <<
-/Length 2594      
-/Filter /FlateDecode
->>
-stream
-xÚÍZÝsÛ8Ï_á·S¦µNü’¨½§l›ôÒÙ&{ivæf¶û Xr¢9YòZr>î¯?€ )Ù–O?ævvº‚A$@›Dð›¨8ŒSžN’T†*bj2[œD“{hûp¬ÌÔ	M‡R?ßžüýB$“4LcOnç]:Œ´f“Ûü÷ yx
-¢àÝõÕÅå‡ßnÎNÜ^^_N¹Š‚‹Ë_ΉúpsöéÓÙÍé”iÅ‚wÿ<ûõöü†šb«ãçË«÷ÄIé³GéÍùÅùÍùÕ»óÓ?n?žœßúµ×Ë"ùóä÷?¢IËþx…"Õjò?¢¥)Ÿ,N¤¡’B8Nuòùä_^á Õt³ŸT:T\Æ`Iꈙ…	c “HsL{#s6fd'…F.ËîeÚ«Çbµ½bÐÊXóÉPïÎè^jdx1žqJ	­ã^³rþr:"
ž²Ž(;!C×Ù¢°íeU•-—EfÛËš¾Ýƒ[2ÝzU9q>_Ÿ
›fùÚÆyc[ùߦ.ZDN¢ƒË9f2i¨ešâŠÃT)næ_ƒ §léÛ⊾D/ò·Ä‰Õž"õÿÍv õ!EëCêÎrÖm‘‡;H´þ#†ZÅò0(†RûAá¥zPÌšºËfÝ*xBˆ&‡‡÷R#ão¢B…:›ã{Pp--(¸V›a[«ÛZ
xH#*°•LŒMT`“AEßÔ£çÍ)VD[` ¨†dÒCÊÇB~0¾p.CüßײDÄ„x©@pR=Ìš§EÝUÅ$$(•¤‡çà¥F&±L‰2åÆ,ÎidcŒUüæeÛ33g-ç(aè(Á ÷[^^̳uÕyã[vFþ·*Ì`lÍu }-èRlí¤p•vEÓÞ滶ŽCJvx^jd›¶f¡N ucï{»
-ˆ¡¼|,óuVÑoo^90ojÍ+‡æÿbh^áV™cW·"h–]ÙÔDϲš4ÞaIòDm¥ÞA<‘ë0x¹t èÊÎúoY
-¡–F1xIˆ±Aµ;ÓPDDÎÌêùÜe]Ùvå̆ñEIQ°eΈôB^0ê|÷v«;NØMñ¾¨‹UÖ¹ùßY<î”*>ƒ”‹²sBÁb3ÈÝÚ¢¹n,QæE
£e•Ë1ƒ{Ö9ª6Vñ$LO¯(_/–.YÝ—uëRX÷`Ë>UYoùŸâ§ÏøµñÍ›7ã.xïGô"_"¥‰€2•)ü`ã.ÚYÐIP¯w¦ØÚð]ZÔÖ&Ú¢µö›ÑQç™/%€ó[]>OÛš
»l±„…K΂E‘µkRlzè ³*[Ø~êÜý(ë™Õð1«×ÙêÅ;d€JEª–BxœBfM‚‹¦ªš§²¾‡–XYŸ‹86Æ'ÊG#
-dăj«4kº™÷=Z’2ûnY[µ±ë5kÖugì†C½,;ªÃ@à1«Öv §Õ·¹ÎÊ#‹£t‰ýÅ&‘>íØüûÿ[b‚ˆí$‚Dzx"ìä3UdŠ$b¶¡ˆ’¾—èõ÷£WG
- ü&ƒûª¹ƒt¹±"J0aË6e'T¡ëuÁo[…sÖ"ø¥„š„f›(aÐœÑÇN/qIü"_/|_>šBd£ƒ×áÔ*d¾“‘ñ\_κ´Õ,ÊΧ›¹ÛÁ}-¼±+£Vß­¤Ëõ†-!œm
-–‚‚xdäè€e£XO…ƒ¡„OÀ,­"ŸQ­lCìÎMf£:hC§¦¬h¢g8¥lY¦x†ŒQ“!¡bL^K‘½Ì×æHšœÏ,c{€
çv¤ Z@êÀôQä?í4Q
-p”ND¢B•¨£ÕjÉ$J¶Õ_×ËMV-“Pó(Ù?ê.Kº›ª¦~Qˆ’
-¬x¼dL…R''!b²w»žÍŠ¶qL*QWcô‘€aíÀ´I²¦VÉ|]ÿϵËïðc‘嶫²K¦Ÿ¿ØÉÆæ DÇb<üªÏˆ3ãX/Dšð‡o^`ÍcO]©Ùñ†’)Ô
-åìa,:ú3vfçÅÏÕõùÍÍ5ÞðˆØ
-µË¦nj¶™å;úV°ñZ’²¶ÕíÓøronvÊ©’PÂN;:õÛ€‚‘ÖP8Š0=x¥´£ÒõؽH„ZJñ
-öX
-“­‹y±ZÑÞõ:ö$ã{H#ö$=ÖI~5¤uäyÄr°Òê[ìØFq¦£›¨ñr{À=ƒu›-¨{xÖò°wx
-ßDQf¨ŸW«¶èŽÌz°-m2ƒ9ÊZ;ï ¹éäPœúHÛœÖ#ÛEmyÖeû½50Ã÷u–ü®Î‚óz™æo%,T±=F×ÏyƒßqîâJyw!î¯wþ°îBrÓ]0=ºí‚–«¿¿þtvy5–Õ6üuÀ'ƒÕþ•#HÀy}ïm–w
-äÞØvž•ÕzUBxÆŸ@Ag¢¯(æôí£Hù‡ü­(R”ãDð'MÀÕjO¦ãƒLgèî¡ðUsæï’מÝ5ÅLõWöh¤¡zÍ¡ &‘2±[Öl½jñÚè¸0‹Yf1íYÈëÃ~¸0r–á­+ÉvN{™@ÚÜ­@ã’£~„ª~A^²·ÌvÆtBªý­&^"x'7ý]Qo—3³ž¶†1GĽîïíú½¼ÿŠeCoÍ_q?Ãg!íézYÁ¹¬;6¢Å \¶\ÃòXHÎÂÕÅB£àT'ÙÅ’\˜zo¦EOÛ'
-º¦Ó1^ÎÂ6×/æyáRæh¥U_AÇn;í_1 F·Ïqpùëئœå¹MC-^Ç$i°lV!µS™§Ìm³9®³ÀþÂk›²êœˆY•µ­åU¤;ËG/¤î
->\Á#wéšC§¯búG`“qØÚÙ+Sß,(5å«f¹”—˜dóÀ%ÝÁ!¯OLðƒ®€pJÚë4äù¬´Ç]3Ž8
-p'4>£ÊG,çUÚ—óŠ
-Fä4ñR㞃$Fýô äWô˜:Kšh*~Sé.ðD¤,êI—N@XÔ
xPù;£i}×0vÝU£h¤80^8Àg¿ûçüÿÇU‹áH—â I„R±døH´óXÄÒ‚O¦ZàÓÕž·¢þq0"¼Êe&QFþ$¤…GàȉƒÏøGÙ4<íGþA(³×YÌF!WøÈÔÿ^»îùendstream
+1332 0 obj <<
+/Length 2824      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ]sã6î=¿ÂÎt£¿ôÑ{Jw³½tºÙž7»™¶ŠÅÄš“%×’“MýHÉŽœ¤×í\g'+$A_‹YÿÄÌ$Q’Ë|–æ:2±0³åú$žÝAß·'‚ÇœùAgãQß\Ÿüí½Jgy”'2™]ߎheQœebv]þ4O"…xþöãÕûËo\œŸ¦z~}ùñêôLšxþþòû‚¾]œøp¾8=™ó·ÿ8ÿáúbA]	Óøæòêarú!º¸x±¸¸z{qúËõw'×á,ãóŠXáA~=ùé—xV±¿;‰#•gfö8y.gëmTd´RSŸ|:ùg 8êuS'ù'âHªDN0PŠ)šTýŠ ‚>uÕØ7üýšy(öyH+¦nů¾újZïŠaÈϱ‰óTMä:‡†˜Ñ“©,7»õÝ\5ôÝ›E6^®lg;îäoA`DSÒ¸’0?6Õç³®¬™r_­-ŒZoààZŠùÚÝŽ»Ù¼`’]¶MéU³d
+ßÍ®Ø>ˆ(7†L^Q•›¹ÈÓì61éü}[×íCÕÜAObXæ*Ió	âsÑ€‚pÝV·ÃŒŽFÁÎú¢j˜lâg-Û]Ó;¾áRËûéW¼Ô}Qïx!O5ôùÉN•÷'ÝáÚM_µMQ×N;)‘žÿÖ6–M±&uÒs““Ôü¾²4'«”ö­üADmÉ¢t˜¥úÃê5¨#8ŠCîêö¦¨§N´g6pìÛvK€ã	h¸´A,÷Ä"Üs¦æßW§bN»M·0è.èÃÛK=GÒpˆ”Ž~lá»êÞ6‡
OÖ8#“ÜÈ	µä…Fn«]W}p7´ºsH<¬´·Å®fç„TÑ|» hìñ¼» ì±dD€#ö Ž”Pl€zXÙ`ãÁ²bBÁ£òؖнßÌÞÐÍŒ¼¢³ž	ná–þ~Àû|póÇ™ùçÊ’#´xA>©ŒbcÈ74Ÿ·ÛÎö¯ô
ÙèbØù¶:òYæŃà¾xC‘plí¨y²HÃþ†²è‹gÄ5â×—ú¢âR2Jbõ‚+×°¡aq•-Þ}¯“—4&Èa”~ƒ¼°ÁòBp_^Ò$N^Øsõïw?œ_^M9¶==#”ÑiÿÊ6gÈ«—|¤åR±ÆÞU½ÛÚWÚ¦ ˆéœAÓ™‘y9 ÌȨC32äåå"ؤ
øÐÓ¼Â×qݯlœ‹ÆC­ï/nÚ{ûŒDG¬ú›™Ê@
+™zÉ+Æ°†Ô9ßZËݶƒ´ï•v–ˆÁκ¶7Ø4¼¸,v³0Û{(9ؽ¯@熊IABd¿&1‘´ýŽ)KâoK	AÊíð^Ô”)“CâméDOqŒKÉÌØ/%Ö|ÁˆY©…÷‚E«4Sir³ånSCrÖ¿Ö¦Õ(fV3«qŒ
oÐÊÇ*$ã. ]oÈÄ•¤^Ž(jšüV'áF¬ºeK
+hg̳>L¨\‚%EˆŽä+Uzùª£ Ë¦ü|Q–ì‰:|”Ióù¦ÝöÌUÉÝ.isnác{­¦$`Y]ǸšhåãÔ¹olÈ7n`‹	‚-ŸQΑԿTHý'('$-p»‹ôå”YdrEùy¹m7P“×¹&=¼?HM/qˆ\4è‘ï£4?ª!.ø%€ƒ’Ñcã„ Pñ0í³ŸQ@Õ=gCF™„ŒrÐMlœ˜Ÿ4J1·Ç	¥¤mæÚko®ý#žŠ
ë"éá	Ö¹B ðnã(ín:k7}=©‹dNÇÕo,×/¥~C•âÿñœ!’ +ˆõ(	ƒE%؃!"¸S€ªº&ÈݶÚÏÅ¥ê.gÇù OÅd’T`rño(JE"3’ǽ™ e¢Tdš<“¥4^¼@Iñ€ã©›‘ÁšÑ«	M*4¤ò`Š¯¥„(+Ü€3RZìÛÎt˜,°Æ¥ž?8DÜÞ±=w;kH2gÜä7k%Úë¸CÕÀÈ,÷sÑS–Àe„_AÖ’”r
¾Â–¼yè^4.ÎjTC€.VIìDåÐ>	ŒE”æx<
+"Ò&è_¨Ÿ8Ú--wcI&*7‘Lâdß…#š~!V(‚Lî•5s.kž‡ò»±]ö!}ÆÌïÔÕMƒû?Äk3â¶1Jbrعrν'
]KC–ÀÛ Á=ACŒ*d°¾ÂMŸØø´,M³Au¾{¬Ç
5´J…¬åmñN¨Ã½zªZstrÏGéýˆý÷Dì‚Øþ¶…÷gÌ Ž±Ò<¶˜uáÊv"(wwg¡¨
+˜k8y6ÿ×Ê•Z y1W ûpÆ’¥ázpdG mŠ›št8KÇ+Ї¼)äS#²`š[Ür+ˆ
+Ï–»~êîtéëŒe-±6X#¤)Xw;à`NRŸWpÕöÖ/RôS¶•‚Ï2¹yI%”ÄÜ«„{xÆ
óÞF‡†l…®µ]B6]uk¶º8òX¨}«£·˜½ºüŸz•û¥®P†'%ª‡2ûP‡çîÝÕ'®„
aaŇpXsÙ5ŽÃC-’x©ècCƘ}°¼±ê(rÙR`–Óî\?úÎr°¿bà@ïQ€(¨“+¶±€„Ñâ¦?˜ºXÀíÆ‹„<–ãÅœßcï?'’•A¯Tð!Èb…Zf	}cëÖ•ßÐó=¥S
+
+ÊY˜´ôɇ%Í&í-&whawM…©5PÄÐCá*¯^òZNÎ0zSlûj¹«‹ítàioqÅ[<‰ÛL†I%¾ñz¸œét„ â¹1×Þõ`£VÛîù*’ùRnF`èãRm¦ýÏ=·*˜6–ï´ÒÖö®@&s§˜î&l&tçJùî7?‹§/‡>4Ä›G©©çÀSûÃ?~'a¸Ê29®rX«ü¦Üm˜<Ù¹ÿÍÐÓ­ÿâUfœendstream
 endobj
-1315 0 obj <<
+1331 0 obj <<
 /Type /Page
-/Contents 1316 0 R
-/Resources 1314 0 R
+/Contents 1332 0 R
+/Resources 1330 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
+/Parent 1299 0 R
 >> endobj
-1317 0 obj <<
-/D [1315 0 R /XYZ 56.6929 794.5015 null]
+1333 0 obj <<
+/D [1331 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-418 0 obj <<
-/D [1315 0 R /XYZ 56.6929 598.1755 null]
+422 0 obj <<
+/D [1331 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1193 0 obj <<
-/D [1315 0 R /XYZ 56.6929 575.8643 null]
+1209 0 obj <<
+/D [1331 0 R /XYZ 56.6929 752.4444 null]
 >> endobj
-1318 0 obj <<
-/D [1315 0 R /XYZ 56.6929 387.929 null]
+1334 0 obj <<
+/D [1331 0 R /XYZ 56.6929 564.5091 null]
 >> endobj
-1319 0 obj <<
-/D [1315 0 R /XYZ 56.6929 375.9738 null]
+1335 0 obj <<
+/D [1331 0 R /XYZ 56.6929 552.554 null]
 >> endobj
-1314 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R >>
+426 0 obj <<
+/D [1331 0 R /XYZ 56.6929 200.0951 null]
+>> endobj
+935 0 obj <<
+/D [1331 0 R /XYZ 56.6929 171.6487 null]
+>> endobj
+1330 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1322 0 obj <<
-/Length 3098      
+1338 0 obj <<
+/Length 2967      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ZYsÜ6~ׯ˜·U™‚Gí“ãÈŽR‰¼++•Çåâp03¬ðó<ÙÝÿ¾Ýh€Ç˜’ìré@£4}|_1øã«XùL&Á*J_1®VYyÁV{{sÁ-瘼)×w?¼–Ñ*ñ“P„«»Ýd­ØgqÌWwÛ÷ëW?¿ü×ÝÕí¥'[‡þ¥§B¶þñúæ'¢$ôyõöæõõ›ßo_^FÁúîúí
‘o¯^_Ý^ݼººôx¬8Ìv…G&¼¾þõŠZon_þöÛËÛËw¿\\Ý
g™ž—3‰ùtñþ[máØ¿\0_&±Z=@‡ùõvi5GMË×Õ°b®7¿jWYsÉãµ.uÕé­Ý/­¶4\¦'âO·Û¼Ëë*-Š
eißjìzA>!@@ÆÝÎÎú¦…%–dÝ(%,gV÷ Kc×®i»ÙbåÉDù"dáÊãÜOpN9;†¿ ƒ¹`a˜h¹<KfŒ­_$s}§3ìZoH³C^í$‡U…ò¹ŒÈ6î@žÔD_ØÖ­[3XNƒªe¯Ó¢­‰%Ý78»è\CÄUOj¦/È"?Ž¢ÑÍúykªh—UkŲ’Ð@W)/F•õ½=Jç8HÃí±®Z;tÔÍ®6dnG€0Šùí”i•¡©DɺÞáu(	pÔõ]Ñêî’¯‡ÛÒ >œ‘ÙÛ0#ÈÙRSWé¦ Ž£éôyÈ»š=5S»æ¨³Ý¡n:/ë;s*6?±H‘^°1½k!≰0˜Õ°rÕQ•e$ æ´j´¥ÞÞúÔ¸©;í6I»%ߊ”AI=gŒ<àÎ$ÐŒÀV¶É¡A’Q­0TêìVy[Z¯c‘Ÿ0.&(•˜ËT³ìñ‚¾@ a¶„oUwÔ #* òY£NüuB㧛wÔRhͽÑ´w}e4ì×ù-éz¦Ž,áfGÏ›šŽ„[ÞÖº%²‘Όá÷šÚd÷Ð8³{4 XÔÜ+öÿdŠéÏ™>vgSoo[ÝÙMÈQ¶º!¬3àt?Ï
mfWrˆ!¨b‰V¦‰¼ÑEýp3­7}G™¹gyæÒ8Bº–ç.riç±0¹EÛWùŸŒ	X±ƒøÏ9_£×2µ¾¶{™{îcÚtyÖi|³3‘Éèî¸Ã“aâ`ý`_9;ZB„4ëZ"¤­¥T¶ßwà£y—ºuÔh!0LŽ†|4öw]ÙÝŒCÚ!µkÃamNÛêBïST²zÈ»ƒË„Õié’öEoíîúÌ éÈ×Æö‚ñþ©kâ-’7]š[k7(Òç¼ìKêÌ®	“û,ɸ#’3Ë?‘"Û‹$GPÎÀd†£]7æ·³¬¹l’Þ®©KﱸÃYàDNPÇBZ˜Ã›ªziå+Oäk´Y]Âá·&Þ’@NúIœ1%%Æ
-£³ÔÆà/\°¼0‰ž
°Ò¶ZF6ˆb"g1dBÍõ8&c:.¦g ¤‚¼2V0Æ<~ZÚ6íÒEã|küB†`†÷yÝ·ÔÙæmº½gO÷nxII\2½B~E’‰i’¡óDhåöKwõ©ÏmX"jÙ›\‰-r!Mq®ÔÐ?Ñù»]d§¹
zF²­=Ü ‡ÒçÑùåÜúÑ€ˆ#th•+Õ¹†æÞiE¹´$¸5h±mR#Ž:ù‘	¥íË£5Êò¦a2‡7k‡7 öAýP¼XD(‹xЮJ¸øŠË
-·\#”ÛŒ™Ë”@@CAÌE½Í‰F'E¸„L=E¸-·ŠOjWDøØAƒÃ‘r¬Û6GyLÏÀ<ÓQgùîd‰W°I5Or=”bªy™Ÿ9ù`·êìÞO×vb:ñÞåîÛe­
-5ž”®h„äáYͶùßKz$Ôµ*4BgP
-‡‰|NM@eû¡ÁˆÕ t™URö…~™WäŸÁ$ÿÓ­4 Eˆ‰hsÀdP†ÝwÀ/sˆ¤œtœüq© äwoÉIê¾[.ª£h(㿺ÔZªö#ºü—2¨ö—Ö‰}ç°lS„ÀŠð=ÃLH2f‚
-LИ%|6…½8hWzÐE1§Ð|Ά:Äš…
‹²Nڶ΋¹'PÚÏÌÞà&T½ëŸëh ˆ)	³Ü65$55$A¤ùÙDåC©skPp4w<ÎlÚn\SÛêPYä<ÎÀ€dm²	
-¹h-ƒäɇ£‘Q©ãP‡HäºMKM¤3™“À¡I@!¾™ª[ƺqý>Ë´65°›6M;­Ý˜hû”ö(tÛÚMw3y‚!»ÑgQ^ÓÀ¯nÐkb¨)P†Ï`ôðÁÙƒKQÃ11s
-`Ÿ¾ØucgQ„ c‘R®3óAŠƒwœÊWœdo›@óÈ™óÜÚ°?ºrŽÖŽÝYfvŒyµ0&âW®……<õ–z)}Ú2%ŠÖU_nÈì¡ô–DëU	_ª;ÌÚi«-'šò×lZh·‹­þ¦‹?r@–Œ{!Æs×rfV¸;cÚ€J‹ï;·ä®. *Ösϩŵ}Y¦.º¼X]áõÈ3ÁBâƒp͸Œ¾-\û_¼A3Ÿ©˜¯d¨|«`ùÍÝ2yS®ÇŸŒ®Eœ3ÝÐ#€0On?p-ì?/™$â·x.Àõ’×'>•
'¸ðç_µŸ¯Rf6îÚíËœO©f0’­Þ¥}aíë>*é¼]ºër’ç‘^ðì=KPMðgîyÂõÄ=;®É=g…Ð\í=S„ÀÁ¾¸òàÀö¤$ׂ(3ëfÌUÏe!-‹d|èp…LIOBÈÕ¥òʱn*TÊMn2Ž€¼Ð±¥zÞ´ï§ðýõöwš<áI‹=‚‡CIEŠ—0 U2GæO‹×íÇ,˜?p.+ö~,¸›	™¥ï4‘Ø4% Œ¦ùÀ˜)CFýùœëlÀôQ¡ZD€¦húúóz8Ïp9Ym¥)4ÍùÙím`ì˲Þd»GmVä
-¢?m³S®Çmvàz¤Z˜™ª‚ð©g¸$˜]ÜL…g"x`ròì´ÄߨM	UŽ53´)ÓUž:Jž’ÞÔàk~™Â†ÅÉÒád9xèúvn;û3„›bî"*ç,8{	³Ò!|¤˜—jåÕX“rÎ9ì7·-S.¾ ,:ÌŸ¾ü-c_Ôœ¼‹àVû½…‹-Ôæç:\¤v{¥Ý(ÛÂíP±r¾…Ã|oÜzky`^6‘œÒg”S¸‡S –àfùÑÄèÝçúÁ„à±äÓ-Óã±ÈI/¸à1mЄý©€G­
-lÏÑŽû¡E™/A×Â…G5‰Ðq™G&³ˆÂ|—VúÊÈ»øc+˜J”Är’/%üÌVÿⱕ:épƒÐ9ö¦·§@ª¦}ÂÙε²pÑP»‘Í>r>X4WÌ$XaÖ.kå¥BfíÀ»؃Œ„/³Pß?¥FöwÔéï4ï:¸ßj/ÿ¼k¾a
>]£ÑŸzÝvߺÆL½­Úï™ëõÛ#vCrUÊWž“÷.0¡kÒªÝé¦ý®Ù½|k)jÕ•öÜ»öÿë„®N–ÞSø|Ó§ý—>µÎÆ̧í¨2š,ðþñß÷?Xýß—']úßp&ü‡•…ÄÊïûîÿ‹ÿi(ˆ 0ˆÅr†–€—H"'”qpu.ùð4_Šþ|¥¸endstream
+xÚµZYsä6~÷¯è·moYQGåi’x§’™]§ò0qMÉjµ[¶{wóß HmÙ'•òC“ 	‚| ,VþÄ*ÒŒ«Ø_…±Ï4z•–'|ucߟ;Çs“¼é¬o®N¾z«ÂUÌâ@««í„WÄx‰ÕÕæÓúÛÞüëêüòÔ“š¯vê逯¿¹x÷Qbúùöý»·ß¼|súë«‹÷ïˆ|yþöüòüݷ秞ˆ´€õÒrxbÁÛ‹ŸÎ©õý囟~syz}õãÉùÕp–éyWxßO>]óÕŽýã	g*Žôê:œ‰8–«òÄ׊i_)G)N>œü{`85K—ô§UÄt$ÃJµ¤@³@Á*ð¢:õ²nNE´Þd
u»Ú’oº$·Sº]F2yÈ˾¤Î>k¶uS&UjGóroxÕwY™U·D²k’Í&ïòºJ
+ìëu›¥Ý©X…úi’îòêöìÔó9ŽvôP×p"19_yB°XkiÎ2²õ¶M]zÈ&³Ë¦ŠÜg¯bXËà¬YÉGvJU/±ÑLëÈMÉ[=ÖksÐ,­K8ü&Ûà”X·9é'vj„™ißÐd£$ €æ
+£³¤#UÀìz» œôChÇ¡Ý:yê J±ݦmêÌÊXÕÎ^y¾Mp©çzlwuÓyiß‘¯ƒæwj5ì£ÕŒœØÉ+ã#a´8öÌ¡±ñÝ»Ô ™Ms“t	3¡AC$4‚¼¯p†
+À
ïòºo©³ÉÛds—€šnÝð’’„â,ö¥zQI’IÅåČȲÛ%µrûK¶ú½Ï©aç•}º³-ºBF¤p]fÐ?ÐhÆ1µçU—5¤HèÉ6öpƒ.<(&Âcã\íúœJEá:èÀ*WéØŠØîëªÍhh~;`&£X­3÷ÚIµ¡Q'?Sà×—{ë”@È-:¼á1Þ,hÀQÒ¤8Œj@!»¬0³VÀt,ä+ÐÂÎ*³t—Ty‹>F Ft½0^ßdD@G¹)Œf¡ws Ñ§Ã‰9‹üx.„—UÈdA– `>÷Õ³QD0?àúÙ("´Fô¢#™7‚ÌIÑÖDÙ×m›£<¦×ÕöLû,Í·K$Í­<ÅcLGÔï÷hm¼xE^æG—|ð[}dws§k»0™ÜÞ;»o—µ*µ`Z©À-yð¬fÛü?Kz
ä)¡³HHmA¬æâÍ4$)’ÔEhÄjÈ»¤µ$ê—yE÷Ó_g[tâ-f#3Dœ|woõúò¼‡hC¶Èí¾vö<Íပmií—S
!¿ÛyóKBFªûnÑAYªè¥K"c…¡›v¶ÀH³P.ÿ¥‡´ÈÓ%>€+àvÚ!ð˜büŽ:Ëï2"7Á&hÌ>G;™AËé>+Š9…ÖKí½Û˜B6úUÞž¤J/,ŠE<×(î×¢ê¥ZÿPßgwÀ È:op”Û¦Ž¤§Ž#¿r.Lô×Î1`Ê‘7ÀÐý.³ËéŠÑʦíFž`ž–º&tÁç`@²—m²	
+é-†T'y|5æ¹—«”I$ÍNß0J5ƒ“l²mÒֿφe¶ ç?~éù/ÚŽå+˜÷¼'³ž±³›5±sZdš«[Ï!p°G&plÏJ2ÌZeæÝœ³Põ\ҲĬÝÜ™‹m›~¤+dÊúÎÍêyÕX7*å&7GB¾Ð±¡cnSV…ߟ.?ÒâÉœ¤¸Eð°+©HñbÎZó‡Es³ˆûz^(,*ö‘HIáVBfé»a‰Œmš’F׃|`܈§þ|ÍÅ–F	6`ú¨‰ÀQ-ÒGW4}ýy½œgf9Ym¥©btÍy(¶ÖÀØ—¦½ÉvOú,9, ´g}v:ëiŸf=Q-Ì\UGŒ‡ú†YÌŒ7×Á‘¸š<{A')ëÞ¼Û@›ªkfhS¦¯ã>çfž+ÌÚÅ #b­¼ÌØ“‡UÛ•'ð˜ÒLD¡6¬ðQ_„§žàœOœ€¯?t`hbÐÍçºùŒ‘»_ÓÏõ’ÿÛÅû¦¾Ë7™—?l›?Ë£É~ﳶ{-Ù!²Mõ§Ï€k½~³§ÀnH®JùB˜^Ë`&~×$U»ÍšöOmïV{ôòMD¬¥¨UW™çÞ-°ÿ?'tu°ôvX"æ›>·ëoÙ¡u>f~ÚŽ*£	ƒOO0Æ®­þñj=ymÝ7i6ž4ßûæ¸"ÆLÉ_Yè+º…ÿ4CnQ¬&ôñìŸöuÓ
·
+;×òá‡:¦8æòç,BrzwÁTÔ౨qÈd`.èß ªäŠIÆ‹¢BÖÊ·‡/Sh2JßJéK©Wúë*¨ÄâxÑð3)_Vçh›¿Ãò±`Ò|æ\P'„²f®M;€2šÇ§ùå´{*½”¤w.Š=Ûo<Ël³‘lU¥BæG¾ÿêÍæ:Q‘d:Ðþ‹:l÷zµ@m9lÉûœÃ,ºß_Q‹~õfsµb>ü¹Oÿñõj€ˆç‡Lø2áBô2\ø.ÃçÜ*ßè©[ü0ù~ራåï`TËÃ#+Àâ›Q_ªÚ‰l\h4²ôÝt85…’4o»<µDƒVá×<ôÂoÒ¶ušÛ-è[ˆÌ	?Ã+É;³`7½#óY›úÐ<1›št\Iÿ`dz µEf^»ÝðΩtέEb}Úµæ[ºý¾b¾´Hú‚¢%}	Tì('SKÓ«´F9QS#pýž€©r¨emžè§;§ÄfðdU$¦ŒÃöX(±üî­rø:ät_Óp(À÷8¾Ú þ7,­«íÒä…øɧ&[jNÆÿ-Y¨™ùpEþò¿°Œÿß÷LEÑÅ·â‹$xÊ\ÆðXòá]‹þƲZŽendstream
 endobj
-1321 0 obj <<
+1337 0 obj <<
 /Type /Page
-/Contents 1322 0 R
-/Resources 1320 0 R
+/Contents 1338 0 R
+/Resources 1336 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
+/Parent 1341 0 R
 >> endobj
-1323 0 obj <<
-/D [1321 0 R /XYZ 85.0394 794.5015 null]
+1339 0 obj <<
+/D [1337 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-422 0 obj <<
-/D [1321 0 R /XYZ 85.0394 732.0195 null]
+430 0 obj <<
+/D [1337 0 R /XYZ 85.0394 394.7458 null]
 >> endobj
-930 0 obj <<
-/D [1321 0 R /XYZ 85.0394 704.3916 null]
+1340 0 obj <<
+/D [1337 0 R /XYZ 85.0394 370.3725 null]
 >> endobj
-426 0 obj <<
-/D [1321 0 R /XYZ 85.0394 215.3041 null]
+434 0 obj <<
+/D [1337 0 R /XYZ 85.0394 134.1547 null]
 >> endobj
-1324 0 obj <<
-/D [1321 0 R /XYZ 85.0394 190.7685 null]
+1231 0 obj <<
+/D [1337 0 R /XYZ 85.0394 104.0071 null]
 >> endobj
-1320 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1336 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1327 0 obj <<
-/Length 3841      
-/Filter /FlateDecode
->>
-stream
-xÚµÙrÛÈñ]_ÁG*e"˜3SûäìÚ§obksÔÆ•‚HPBL\”¬TòïéžîÁ%Ð’²•âgz®îž¾b‘ÂO,L–d^ú…õ:1©0‹õþ"]ÜÀØ÷‚ç¬â¤ÕpÖo®.~ýVÙ…O|&³ÅÕv°—KRçÄâjóÓ2Kdr	;¤ËoxÿöÝ÷?~x}iõòêÝï/WҤ˷ï~ÿ†Zßxý‡?¼þp¹Έ巿}ýÇ«7h(ã=~óîýwñôwfÓoÞ¾ùðæý·o.?]ýîâÍUGË^‘*$äç‹Ÿ>¥‹
ý»‹4QÞ™Å=tÒDx/ûmTb´R²»øxñ§nÃÁhX:Ë?‘&RerŽ~À@—&Y
-[Yã“LIøÓå*KÓe{Ì«f[WM}:®þ=5iyÐÿÈ7›#Aþ/„õ‰’Ö,V"±Z™°Ñ¯ÂI¼µÙb‡M-þéP[j–‡`çõ¾¡¿Oa¼žDÁ"h‰Ä#¿‚çê.¢š=FÕÛDÕÿTeª€óÖÏ¢ZÕm¹}xC3›(+5c©§XšÅþr†Z•(í;,ÅY,Ÿfg7ÿ›÷"‘NÚYvþ|*ŽcnòâX4MxwÐ{)E"lšÍ`œEÿÓ輞–Ña=˜Y¥l¢Ö/>lÌådb2£ŸäIww/g‹òh¬æ¤/
-̬øý¶˜6f‹–:Ñ©Óc™þÏ78úë·Rt<»—Ât—èLgËÜ@
-Û5Åñ®8’UÿØæm±/ª–ºßOSY•mYWÉ«
5~lò›‚R'I“cl8éê¶èðé'	—d.50ç0÷’`¤-øž6À-Ë
áV4Ô]ßæÇ|ÝDziË5Ûšþ¯úÏ›¦^—°Í†ú÷e{Ë#ôw¼nYìë6,Ë*ßóRF| 8JéÕòÝv´ò@K§/´vW\Šeu'Ðu¹D?QìU°û¡X—¸¶Ø¼BˆY¶·²\ÉpL«SP³Þòª€SCÓâVëñD\6€©Jõò‡j÷@c°)5öuÓNN^Ó64àV»üÔðŠüpØ•ŸAûßäá³:†‹1¤5‹$
-2SÓü(leEw>òÐàì½Í<ß9ò“¬ëj;#àÃÁ/Ä©	P¡k¤C'
-_“B…~J
-ÆVÌH¡UËu^Q£^¯OGjæ_Zßýõ-–z•ž˜qP²602H(5ÇG8¼áaâ4Î;¨¨£ýÆ,JËOm½‡<¤“rO½Ü’©ƒÖuœû¶H¨yuËÙë–âõï“i8D¹¯G»ÿnYA¡0«Nðæ%¥¿èíËõ-5Ä»!…¾£ÐsÐãƒuÒck¯Ûo ¥£ù†¡îz•De¸z.Ó
-"ïÍW媛5âEs[Ÿvˆ%¡ùî>h¨}_?£ædLJ;œŽJ{2O
-’ùsæÜÉD+ežmε•1HD®ÍJ£;%zZã¬÷#;Ét•ün:ÞŸA.DÝJöèÝ<Š M±c
…!§©.Þ4:«L.¯“yhdÈœâxg]ס¬06Z¡M²`}i&PRîù°šG;ɃNIþW,·5ïR|É÷:FKƈ°SŠ|SUé¥|`P®O77“ßú˜7·1ňVj]—ny:´<€µ˜|h1s&ëe.Ôimq±©š3…ÝÉcÔ‡Sï:1‰í#zá8hŒèÖ%zÐæ8sßòÓCËËjúçCìòÍwï?ò
-Š³–3öûSF/8^òr*£ÆwÀeGLÝ¢CyA“ŽËçsºÙôŸRR)ôÂì˜9À2è>+˺²^Òê´9¬šò_sea@ÉgÎO<&äèµñžW'ļ…Ößý‘ƶÄi»#é±|¬jK*üúà¡xH ¾#Çï”®ñ‘rçÀºeãk¥HÂïÄàÏ—“]¹¡ñl4”°ôÕ0B”¤È/!€ÊrýÐ’˜úðf0Ü¢>µTèÃÁö¶d0×ȲŠÛDË„jè曞Àþlð	!™3W´«NûQ~a ëÛÓŽ`Ì@€r5xZ6·4ÈÒi
ÁsoÀF3¶ìÀ©¼1X1
-Ï°÷`B;¡9#GB¢»rFDi¦îÜ¡3Œ°€7ÒñWÛFÃÌê®x5µe}Ø12hló°äÞ6FAШNûkªWó÷³Éj}:öQ!ÂÊêº>e‚N,+ŠqYq䊆‡ŒØËÆi=«òÇ3DʈSó/©`¹d÷•ÀìèÄM‹¹;ùÌc%Fž
gÈ×Ñ"w¾:¾ùÍË•„ä¬/—t8¯,ͳBfu"u:NÑ’øø*’Ô‡Ç×çä…ÂÈȯÏÅÙäݤ™œ&ï’
ˆñ¨!ÈÜ7N%ºÇ™~…*S¸Wª`m"m&žóªL¼snþ#ÔU·áj°cøÀtB=Øo—eݹAS6s	¸L\Gñk¦
Ñ̆>W‹·â”™P?åpŠvé‘É@óÇÏKáæ:¿·C‹üRƒo!И²âgí? 8ÃËÉ
-ÆÖWß}ÿjz%bg&‹´ïÀ?:Þ,¨ñaðEoœ½L'v©œî‰|,"Ò΂75S<„Ê›efˆÈ£Š»I_?ÿÑ^ý{xz,;dË6ßñçø”Uó?…µv\ipÙØlYÈäÿÂÙྻüV£ø}‹–Ví×OÁwç–AÃÇ–3ßq+ƒuß9&¥Ý†¿øïþx
®Î99Ïni>®©ˆTø–1{„yüü1êÿb–OÁendstream
+1344 0 obj <<
+/Length 4284      
+/Filter /FlateDecode
+>>
+stream
+xÚÅ;Ëv㺑ûþ
+/Õç´8xpfÕ¹·ûŽs&;ÝN2s’,h‰–9-‰ŠHÙí|ýT¡
+àC”7‹9^,T¡Þ€å•€?yeŠ¬ðÊ_YŸgFHsµÚ½Wèûåä1Ë8h9õ»›wÿöYÛ+ŸùBW7w\.ÎÉ«›õ_E¦²÷€A,~úã—Ï׿üéëÇ÷6_Ü\ÿñËû¥2bñùú??Që—¯ÿð‡_ß/¥3rñÓ|üõæÓWê*Ç﮿üLO?~ýôùÓ×O_~úôþï7¿÷é&Ñ2¤W
+„üãÝ_ÿ.®Ö@öï߉L{g®áCdÒ{uµ{—™\ëÙ¾ûöî¿ÂAo˜:Ë?)2¥5Ã@¥çh|VhèBÞÜWH•ƒ¡Òãr9àÇ1mu|¨Ž“
+ôud7'üÄCT’hufwÔ¢qŸžEAÑŠ@³ááÝ|peMf¤ñ¯TQpWFG}nöz߯B; ì8N€ßͶ¹Em°0µ¥[PÛAÁ³g´Kæ'aLÉFµYÐYÿr1¨ÌŽ^îHêr‘l“ù^&¢eRN‘eb³¤œìÍv2/d4K)°ò½YÂq*TòXVjå|§†êM³fµŽ5ÞŒå‰l²ÅXŽÍ⎴mÇ$Í&"„ÛLèà=øޢ¢fº‚5³`i
3»Cþ@_”Vèmîú=ÌX&À\%§õò±¹ÂœI+`¯Ù|CÌ	1‘×Ûs#Ǻ¢—a„%†(ÃèàDÑQÒ×KëõÆýüåÏ 8[b9c·;íÁèÇK~ ‡œÊLÜEû!u‹aäá»÷‚Ïæt³é—,l&”ÌßfÇÌÁ.‹°ÝWe`*©$Òò´>,ÛúŸÕÌr°%,šxLmCŒr¦˜¦ØÄ[ýéç_y¢
-NÛÑ׶)×Àª®¦’|ß>ÍmNB©àµ/wÕz.»E©J-àÄ„û‰³¼C€)ÐÐé‰åVÒÓàÏï=Ä5ÛzMý!Ji)ÓéË Ða¤"(‰Ÿ_@äUäö©#ùö‹¿	#†(šSGBììîkC`¶a 9¢‰[¬·ã¡›Xÿï	×0ËlΊÜÖ\ôG©ý"Â@IîN[‚1Êe°u{O¬\ô'ؼ$ðŒ0ãŽ=?ÕE xóGq~ELhräZòæHºòT‰[QG.4mgšo$äñv-b°ÇÛêÃÔöñÊȲ±Ä².u?RX„]ÝK6¡Ž-͆£D
+÷ákKR´!:lëª}["cVdWþxV¿¹$?Ñoá£~KËè¢Ô»ÓŽ>¢!¬ìØ_µm¹áÁƒÇ·ÊdnìËú,lÒz–û°«}¨´:7VF•‘‹Ž`䜚¦ˆé`•"U<ÿ
RQ„°Š"p¨¢Ø•T;IrÌ*Š@Ž¥
CzEèXE&ÉJÐÇŒ¦Õ¼…¨”ØÏb
+Ðð}ߺ¦Y3ü‰à|¿Ïø{ˆË~0Œ}~(»Õ},Š1	ã›=X…êXÅü	'¶ ’ÌÈ|áóÅÿ 1
Ž:ÂÝ(6ÚCµªïžèƒSçP%úBíàÇmŒ°¡\,6JFõqp½Ü]*ç8ðGžòY$-Þ/ïìÒLBf¯ì‚1egq=›®cO¼m1«2áÒ½h]„§
+z¡À1“jJàùBÇüâ_Xy°m¥(zëóõ¬ÍÎó‘ŸŸ½%²™ö‰ÿƒk_\"ø6.áˆÊ­«Ùm5I'›˜„/}Éñ|9ØL­ÜP'm* YöÚÙÖ»P.°1þ‚Æþ´»¥»äê!&ÀûÕéØÇ£«÷·Í)h|ÄJ¨WBŨ:XdÄœ6Îüè&˜RI&e$œó—¿`ºTz×ð{´nZxì± ŽâÓȳáèŠå*šääíã5å¼`)È'û
+OÚóòÀâ<+e6ÏTž/**‡n2>Ü¿&••FE~}¯ž.ÔŒ(Ô´ÞCÚ³Q µ™{6át–÷{…E¦¯j”´QFØÿyÍ»•yçÜü«še¸¢¤'3cúÁ„»¢èWÊ2PI•¹þ˜ÖR½¦#gÓ‘_ª "nm&˜2Y m:3hùR,¬ÃŒçWÐ"_K£ààÍGH?rôA_ññD÷Ä×>Ó?é1@¿ùvýˇé©8—Ù\)Sd®È%rúŽ›+j|¼RŠÃ—Ãñç”ΰâ¾Uqß΂S5Ó­H]d¶(Ìh/gï¤Ò¨¶pŽù iœ¸»bÑ•[~Ê€×p
ÿRpkÇÅWŒí—UbñFdƒ#O3øžIóÝMÝwϯ‚w惆Eád¬…`œ¬Á`ã'kL+7û²;¥j‹I¥?ÿ›j_A×ôyj‰
&V`Ê1!9Rôé~…p+4È=ã )¡ô}Xº,´]|œËÏÆWu¡@[oê}Ù%k;p7¯¨3ŽŒ8]ó˜þ¾¿æXlÇoSYb³}·Oq½ˆùƒu“ÙÂÃÇ-ħ
„r¹àMbcs,w;È
ÃzÞØ;çꯊIÊãÍ0@¯}È	Ä	JhΪm”ÿe.ìsïsBj؈^„ŒñæçxCR8—ëp&®xÓ‘/Ó¬±†×¬Š¿«ªLjñ
¢¾my”Cu¼žRÅ‚æÛxfjr¿¯&pî²” Ä(óf‰Ó™·‘¯ ç3mÝŽ^›´ƒ¤Î™é{í‡h<«‰y]WíêXÇêÛÅ—vø†N¿UIû¯—•ÔXý”TIQÓ†aà¡-°@[u%ñ1‘¶ùAP¿N8AÎñŽÂ z³®À€dvº%¼û.À²Œ¶t¥Q/läÛ°\ˆ—bJ»WÖÌ¥JÏÁ‘‚»|¤…ßeÕËvW¸9Œó‡i‹¬F½Ýâšhq‹‹×¼Òâ†Ú2½ÖfNäfš¹v´›
+•m|ÚF™už^ÁÍ?~j8xP9µ·øœ’´_²óƒz¦ö"Òh˜¬¿ho­É”O^),¥Jr¸„}V¼ųêMžò×!‹ÔY|kÒ&+7¡¨Y¤‡Â"úsË/)°N%LhS2Ô&ÍX°ã–âvnæâ]ôµ¶1ÒáÓ“×¾º(æ0—Ȭ@8…îQ‹H ¶Æ€Å\X
+¼ºKVòåS5ÅØ¡ãb·U¬Šá?˜8?yõÿ§@
+í¯5¯—0çZ¼V}æþ
K|™5çÅU–ù_´úÿ_Ëm¦SóžTY‡Ï_uÜTøï5w¶óø¿\ç[ÿ?Ñ_Aendstream
 endobj
-1326 0 obj <<
+1343 0 obj <<
 /Type /Page
-/Contents 1327 0 R
-/Resources 1325 0 R
+/Contents 1344 0 R
+/Resources 1342 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
-/Annots [ 1329 0 R ]
+/Parent 1341 0 R
+/Annots [ 1346 0 R 1347 0 R ]
 >> endobj
-1329 0 obj <<
+1346 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [87.6538 61.5153 137.7628 73.5749]
+/Rect [87.6538 253.0584 137.7628 265.1181]
 /Subtype /Link
 /A << /S /GoTo /D (tsig) >>
 >> endobj
-1328 0 obj <<
-/D [1326 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-430 0 obj <<
-/D [1326 0 R /XYZ 56.6929 659.7801 null]
+1347 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [370.941 145.3317 439.613 157.3913]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1214 0 obj <<
-/D [1326 0 R /XYZ 56.6929 629.052 null]
+1345 0 obj <<
+/D [1343 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1325 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+1342 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1332 0 obj <<
-/Length 2654      
+1350 0 obj <<
+/Length 2926      
 /Filter /FlateDecode
 >>
 stream
-xÚÅZÝsÛ¸÷_¡·R3HLžœÄN}í9w¶ï¡“Ëx(‰–8¡HE¤¬ºûßoðKTl7ÓéøA ¸X,»¿ý ƒ	ƒ¿`KŸ	N"ú’r²Øœ±É
-Þ}<,ÍÌͺTïîÎþz)¢‰öµâjr÷Ðáû,ŽƒÉÝò³÷þoç¿Ü]ÜLg\2OùÓ™TÌ{wuýf4ý¼ÿt}yõñ·›óizwWŸ®iúæâòâæâúýÅtÄ2€õÜr8±àòê4úxsþóÏç7Ó/w?]Ü5géž7`òíìó6Y±:c¾Ð±œàùÖ|²9¥ðe(„›ÉÏnÏ~mvÞš¥cú“"öeÌ£r1¦@©}%à*0™Î„ÔÞnÄ^úmŸV5MTÙªHê=ÍãTì²<§—ó”~Wi‘î’:]Òã¾ÊŠ
ëµ]ô5}²·é"û1î¨×iË\{Ia§“í6-–Ž¨ž^Ùc©½MZUÉ*…«R"òÎñ@³ ðµ”Üœªw¼¯r—­28'I¹¡'ôpSÖö¹Jw §gýeÝ%þ¶Ïh°´¼Jú; I÷nþäösÌP?Ax~sŒÈׂÇæçy½.÷«õt2+$V»d³IvôP>´oÜyйó@h?RRgd»U–ªk,#PÂ-òd_Ù­’@ËÂ×hRlSËÊéÇ™
4 B?Ší®”<}±ß‘š‹:·Z¬öÛm¹óUÞݸB´pÎíQë]RTdˆ³ªÜïéˆz"p>®c»-u”¯ušïìQ°Ž'T÷4–Jr˜ßð˜oY¯ã›€{JÆêUW>kVõpebqn¿TóQ,îÝf›,OvöX ééi}äîfzˆƒ»Çµ'ŽÅerqùj‹¾Žœ2^pžK=ò6¥Åkc/‚Žæ‘zúY¦u’åžé^—iµØeÛ:+‹Ë£ ±Ãçk4’á³N*#ñ_8)„cèàåó’¥@¹šiŒ¿ôr·šÐরúYwÁqÀ>æ‹ûߢß8ýaÊ(?:I)`#xO¤£Ì¡¡zN#n(ˆo-!à"~1úî À¾RÅ!vEüyÜeñÇñËŒ”¯˜ä¯G\éWD\ùBÄ5#Ä‚Þ(òcÊ>ôÒQ€PÑf<=Uqs˜éaˆ¡@1né“x+ày7°2@KíiO2uÀkOám$}Çxé%ÏÞâ‘Ñ	d¾Ù^š”ªRA]i$Ö[ì½Îóìá˜N .äS 7ù:{“AÔÜnvØ=
-ùø3wþ}ÇŸ8€žb™ ßÝ}ß4cê»îe¨õÓ§‹D[ok½I(—¼GÌÅóˆÙŒÞÑ­˜%o2$]o2lJz1·ü%6’†ò¡ÌI2#”ä@8mø‰~ÆçÖ°†9å@RYÂ%&aʶgêy:a‹
-Â%Ÿ¿U©ú7›Û8rH¦Y¬ûzù?:GüäË-L½ªà¥þc¶kŽŠ‰mJ‰œ€*GÙ²×ÄM
u?ÃÒi·¯ Š˜™êÈp½­¡ªÝÎbµo.Ã_èŽtPs€‚u‰3¥]N
-xÿÇ\‡°‰	Mÿê)G‘¬Øoæ˜SoÜ¥Û¯z)d|>¦{=_óóÙ÷ý/_È‚Feÿã혲Až0‚R®×)™³—*ùCŠ×XdmrCñ¿aô±öOæa[bõÄ8æ(µÏ1«eö†Z	cÌ^„&Ãã‡ëÛÛ‹÷4®R¨O³ú‰ž¨·PÖ•O¥p—2«3L…ç&Àéã¬a@‡ñ$¸FJ=—U:úYwÁX27äÛÏ*A˜Ð‡ÒHš	uO˜ãN”%zF‚#^”Mš&À¹Óç¬Å/Îô°sʆúÈ)›žŒzá×ݪW0ï°NzAy¶ûyž-hlm¡&L÷Š²˜%ûz]Â~	¢?MS9ŒŒÝ~_‹òP˜ŠMzó½Ъp‚ÍíRc)<	‡N\Ρ„2rC"ÒÒñL'À”ÞÐ(…ÒÛ”á¢ý‚z6øap¤x¤ÍZ´*Ã'[Ûèggùl×€®s;íjvùc=¹O…	ëè×ø¸Ö óÖIE3óo	§e÷·Ú7­5³ÐÒ%ôX鈴gÜ™ž]/
Y=ؾ®ª‰WR÷ÙÁ¸ëdé䙉xIž-;‹K´%m>¦ÅØ©Ûë¶ö®ßj¬Ê¼i0&5 Í¶¶ðØ€ŒíÞmÙì;²–ØVØIØveáºdóe¹›ªš’›ÖºÀÝ8“l‘kÐQ‹l;wƒÌÆb8Œ~g’LÃâܹT©,–Ôj…i´“
-zÌ3º1ê¶ô£¶GñbÇ@¬]~¸ž2r_¦Þv'S*Áoú¯Ìô„›ülEK–9•l0o¿‡ub);–O!Q†¾ÔÑ &šsRµW%m•Åt'¹2o	d°?g
-«P5Úñ¸v¢Øg<~±râ8vé¼IÉlq[VépëVwðàêTÕT°Îþ{展¿_üÓ¥
-
-r5H6onª´Z«Ò¿8{·lÈiH_z=w—÷¡|£Fz2	`Rê—k-Pj$	Úf "FˆB¤¦Ù¶%ŽO6œh<–B@’d±nÖVpÑÖE´59í‚“á`ô´ä¼4]$›ô
é›Ô;€™"Y¹þ›E¦º\”ù+eëÍ›AŠÕ´èÞ%{UØŨ­õj8MÒkÝõWÒ©-ù'òÃaΛ>féáÇ’oâ ,¯{Ô•Ql+9ÐÔg¨U«êK7IâMR/Ö³Ež$M2o~°,´¸7÷¹œÿãíX >îÕæTYü8³bvÙÈŒ\éŸÒê¾ÜÝåó‚QOiº°6ßÇtl;»‘í¾ñƒášÙ¨‚_^!ðç,àXp®]ii¶ù6ú
-0t¤²ŸÅRÈÊCº{ØÌŠ¼H5 h¾¡â9j>Q+úDxšXžyZ÷¹C6«Û¯‘Øo¨͘~l@ÝŽ'.!¹í]›Ûuצ£L»k@NŠß`	¢˜²
ø=¬K˜cÃoR}"„v-¼«ºÿ¾Î{÷"LÕRRŒ)"ù`5ÚlWmóÌò¢á\Zï·–1~s*÷õ©oï`øÁ|¤>a%þðwùöŸÀœEóñJG0åDz+”±ù£f}óÿXô?—8ŸLendstream
+xÚ­]oÛHî=¿Âo«µn>4ú@ŸÒ6ÝËÞ¶ÝK²8ܵE Û“X¨-y%9iî°ÿýÈ!G–l¥Î¢ED8’ÃoGNüÉIjB¡³h’dQh„4“ùúDLîàÛÏ'’q¦iÚÇzu}ò··:™da«xr}Û£•†"Måäzñ1xý÷³ß®Ï/O§Êˆ O§&Á«‹÷oh%£Çëïß^üüûåÙi×ÞÓòåùÛóËó÷¯ÏO§25ö+¦ðĆ·¿žôóåÙ»wg—§Ÿ¯99¿îdéË+…FAþ8ùøYL ö/'"ÔYj&ð"B™ej²>‰ŒM¤µ_Y\ü³#Øû궎éÏè44©JF¨äDÊ03F
4h²0ÖJ;
¢Ðô$…A[o›Ö.¦_ìcC‚^µyk׶lYî:_¯óå†ëÉz×#&S‡RG±#;¤íÿᦉÒa†š™v|rÓÖEyGhåv=³õ·á>þKGVx‚dñþ:]÷ø†áçÏîŒé(ï¾$eU
üDY˜¤*픬Äs•üÆ~B•E[T%­ä傀ߛüÎòzLûÆw½´W;$™…Qœ¤€|pC‡ÁF”‹|C;S,ˆCÛÐë›÷WWç¯	nì|[í#½Õ§2
ªªmÀ±"!˜Eã‰5óº˜Ù/—û^Åh¢Q:‰•ehßô±¾›pÙsˆÚß@Ññ.Šzeç¬x`&
+Ó}nŒÍnŸö¡O2Òh!NU"8óúœ’õE*Êâ¡ùuÊÖ²S6½9õÂÓߪW‹àaiKúЂ‘8`³­Š9Á`
ÜV59=ʪœæÛvYÁyy[ÜóÞÿV¥%Âþ¼/eõP¾@س-33ÏËÒ36ã­ÎRe»zsâjÖæ…ã[˸%ñ¶wKZSzA-@”šà™çÛÆÒKÑâÓ8Öˆ†íö°S¾‘0Uãä˜Î&'¾Ëƒ}þ¤mÙwÀ{8ŒîìC9Gtôk|°Òñ}™7´2³xK¸4¯J¼¿;VÕ‚72^N¯m}šÎé	J)TPÂz0tE¸«%Zy;$·„à7,ó…ççTÄ’îóU±èm.iCÚ¼·å˜Ô»ëQGÂ)Ôhµ©V÷x‹.Þµm6-‡Ç.hÌgw‘±‹«U‡L`åŒÓlg‹j
6Åt«[ÞËŸw‘Ëì"×îÓ0áðzæÓIÀ! OŠÒð2¯j–iS•—RpͤDI¯«‚.a
+zñÚ„I–ÄÏØÀ_–%ŒÌJÔb7ŸÔVô´_áx	õŽ¶,V¶a™œ~àù°Ì³gø”
Y¢‡Žëä„
Q49"^¹È‚«b]¬òzõH_)Æ@·+ N;k':P¥ÏVNš¦#W¥çâz÷ðèî༟¹pšƒ§7O0¼œÿÛW
+1”
+q6ô€ËËƶûÆ¿SéOÞÜÙ€:…7oŠ¢Ìx?ò7f£O–˜ìùJ“q|_éMb¦uƒºrªÒ&Lc³§©óUÞ4Ÿû%ú^^çí|9¯
+à¤+åÝ#_,j7ãfåâ	®ÿùr,þ(öàºú¾ŸX»ZdJø¶¹©ê›²:Þ8õTä…«},öÇŽã
Øn:?Øß3Uð‘þ ÙY€:fßÓÄß
+Je’ýÜH	ªÏBèH00Töà3§Ç¦z°õíÖ…¬$¸…Bª‡mU
§Àô­zL­:†Óœi®l;¤êÙínlÍ¥|,›‡¦—qðÇÖÖ. ´ão­ã—ÔØÐ%{Q„rÙ!c7ÖçoxuZ‡çò"À‰
ϼùHÙ3\´ÃàÛb¾õi/ÁBÍ’r¦ˆèk›¨Ñî¸f³*˜I„k¶Ýn˜ðįjÛŽø2¿'2—*Ãàd¶›^˜v…ª³Ë"çª-ŒAgæˆÁhmdvh0Zª~©%•±°J–Ú~àŠ]ùŠ]:+h6ùœ×É^¢‰(3þÖP
Ðìqp‚.µöOâ‡ÍWf ù"ÁAÉ~'LìΊCÔ'ÎüÒ4¸c'†¬¨ñ›ëh*rß/~ãÍÿ(½4´s@ºõŽ;üà¡T:ò5…Ðý†U§àºBÇ¥T¨që3ÆR*Ìœ·
¥¦ÅiŸ$ìúüé4òPE»“»Ø}ÐãƒÑ‰$•?ŽÉŽâ&#è½E—<`Ò% £ŽÃ$‘Þò«ÛÝí8
ø§fÄaûXøèIÙË·õ*„Š,:°O·‡h‚æ=½¹=M¹€ûTŒ_]²¥46‡Ú76\èŒ
_ž06`45ÝÉO›u¢ÕDIF"1?Àؘâ´OrÌØb¼¾ÝÁß°µ8L£$ùqek	Øo—–)N¥>"¦OÛZ, Sëø¶FñlP’e–FƒÃ1¹É‚äIkjJh6v^`d·=˜(˜UíX‘Zb9!L>môqB7Õõ¶`è#9	®&5CŠGDËpK—¢ö6‡¼H’`Öħ£ƒ¹”*¼Ø„‘B[ì+gYß­,f­ãà¢ì¾u…[ÆIº¨¥áTQ.ا3&*äß$ú¹ÚÓa¤…ú¦öp6óW´—âÕE¢ÜºjX¸6ÿ2VnB•–6yO4¡XwšÈ›ßòÀÞQÇQ7m*è±ü°¶óe^Íš^]……ßÉs`Å'p„Ý=ÃÇÆ®ìܯyDWd
+§±‘8‘ET®R?’dFhÆÌôŠ›k.ø°r'Œ#ŒÃûµíDuÚ‚’.ÔBìùG7_@&ë.côµ¡Aͺ‹üßhäpòÀ# î·„›ùºÞ€Jê Ã…žVÊASðžï‰hðã‚Ю%q2
+ÔÙH”
+®Bo5eG#­&e5ÃalË‚œÎ9ŸCÈ,f®±Äq}gª"òÝ™ªˆž°.Ðq”aWAƒû,欠xõHg°‚vbŸ‰œBûc„ÿ1EÇ4TÂE2h\ó‹ŸJ†¤³&\Ùus¸Š\âäKC1ìz9èíΑ<$G"˸{‚…»âÞòI9N®‹îÌÌÅÛ‘–Ô~ͱÃåy¸VT€é×e¾BxoœKà{Ÿw×Øêûá=7Ëý_\³<ÖÕ¾ËK7Ð<‡ÐÞ¹`aã)|a X”;Ä»ŽâPšÈ{ž'2R½C¨•›¢hŸBu—B5OyµŸB›ž‹!Þ+ø;@š¨ãAÀtåWLJ»È߃“¶ô•OE„Ú·ÛÍÆù`–yoˆah)kÀŽd
+=dA(õN	k½´™$øWG'zaÚ¥×9/æ«­%°`âîò^ôÆûxåSÿ½¡¡ÈÓzìw]ÑÍð¾û?;vÿö%!øªÿ…X°¥/3妅ÙÁoÒþ_@Yÿ?	ü$Éendstream
 endobj
-1331 0 obj <<
+1349 0 obj <<
 /Type /Page
-/Contents 1332 0 R
-/Resources 1330 0 R
+/Contents 1350 0 R
+/Resources 1348 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
-/Annots [ 1334 0 R 1337 0 R ]
->> endobj
-1334 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [399.2874 660.1853 467.9594 672.2449]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
+/Parent 1341 0 R
+/Annots [ 1354 0 R ]
 >> endobj
-1337 0 obj <<
+1354 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [461.1985 408.6709 510.2452 420.7306]
+/Rect [461.1985 617.9092 510.2452 629.9689]
 /Subtype /Link
 /A << /S /GoTo /D (DNSSEC) >>
 >> endobj
-1333 0 obj <<
-/D [1331 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-434 0 obj <<
-/D [1331 0 R /XYZ 85.0394 562.3583 null]
->> endobj
-1335 0 obj <<
-/D [1331 0 R /XYZ 85.0394 535.0538 null]
+1351 0 obj <<
+/D [1349 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 438 0 obj <<
-/D [1331 0 R /XYZ 85.0394 457.3433 null]
+/D [1349 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1336 0 obj <<
-/D [1331 0 R /XYZ 85.0394 427.2294 null]
+1352 0 obj <<
+/D [1349 0 R /XYZ 85.0394 749.0627 null]
 >> endobj
 442 0 obj <<
-/D [1331 0 R /XYZ 85.0394 274.9785 null]
+/D [1349 0 R /XYZ 85.0394 668.587 null]
 >> endobj
-1308 0 obj <<
-/D [1331 0 R /XYZ 85.0394 250.6389 null]
+1353 0 obj <<
+/D [1349 0 R /XYZ 85.0394 637.2799 null]
 >> endobj
 446 0 obj <<
-/D [1331 0 R /XYZ 85.0394 122.1428 null]
+/D [1349 0 R /XYZ 85.0394 480.6393 null]
 >> endobj
-1338 0 obj <<
-/D [1331 0 R /XYZ 85.0394 92.0289 null]
+1325 0 obj <<
+/D [1349 0 R /XYZ 85.0394 455.1065 null]
 >> endobj
-1330 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+450 0 obj <<
+/D [1349 0 R /XYZ 85.0394 323.8452 null]
+>> endobj
+1355 0 obj <<
+/D [1349 0 R /XYZ 85.0394 292.5382 null]
+>> endobj
+1348 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F39 868 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1342 0 obj <<
-/Length 2718      
+1358 0 obj <<
+/Length 1733      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ZÝsÛ¸÷_¡ÉK陈!~Í““sr¾i|©Ïmgzw4EœH¤N¤”¸ûß»‹]ðC¦c¥Éd2\àbwñÛ/XbÁ?1KÒ05ÒÌ2‡I$’Y±9‹f`îí™à5s¿h>\õêöìÅ•ÍLhR™În—^:Œ´³ÛůAÊð8DÁ럯ß\½ýÇÍÅy·W?_ŸÏeo®þvIÔÛ›‹wï.nÎçB'"xýãÅûÛËšJ™Ç««ëhÄÐã¦7—o.o.¯__žÿ~ûÓÙåm§ËP_)Tä³_fPû§³(TF'³Oð…Â9ۜʼn
-“X)?²>ûåìïÃÁ¬ûtÒ~"
-¥Jå„¥š2`bÂTÁp•Êê©ÕÖôÜë`_½Ù¯Ûr»¶ôÖØÝÁîšõ†Íç2
-SkÇé2/V8»ŠÁ®2ÉJû‰
E“I(c¡yQÓæ­Ýت=Ÿ+!ƒ…ý-Šde|AN£Ž“£ê%M´+K?\ÿB#U¾±Í6/x¼]åÌòS¹^Ó’;žk¬­ˆº»íÓìïÛŽw*Ö%Hf˜Ç&	.œ5€«¦c!B“$Ò©B+Áx:6y[¬P|Éñ¡A‹s "øR.i®lyQSïwçB¨¾_½ç7n›†¾±F;8+32q
-©b¶1²ÀϬ$°RÌ2™…Q"O‚°ÖzÀóŽã|È’Ü{(ŸTÊ8í7F)^dÔ&Ì”H¿£ŒžãS2f2ŠÇB®Ë¦Âtfø"Ù»^ö‡ãÄï_š	‡;diä}ÁY`Γ2L£§ ÖLH T©ÔKP¬ó}ãЮƒ¼Zá †ÄÂ6mYåmYW4€XsK‡XÃkøòÖ@Pt;?Šµ$ŒdšÍÀJad"ߎ5æ8²œÂ¤‘¤ýÎ_›Æ*¿£žãSBÆf,âcP4fF æÏÆB-…ð­UzÔhûH¦ðÈFÇ#¼afMLp…2)TuKD³µE‰qÝ.žÃHwu;•?„ ¤#!Ç|
-‰75™Gà|"%ÁÁèdÌñ	Õ~"²°Ëò"i‚YŸŽæRg@ð»0–JŽ}5Ç´#Á¯²˜G”Jƒ«ª›+Éñ’²	À犜ª
e‚c>SªBúÍ4T"'ZO…±Šä­'LÇIò5ÖÓø‰ìQî]7¬\›´[Í•d£{¬øÑÞOíª¦Iìá÷iU‚7Ã9ÄÁÖ™¨>”tˆT(Nll±Ê«²ÙÐë²ÞÑ ÜfU¯Œc\ÔUk?·ªÎZPÐ…*ŠŽüƒ¾r…Üuch
fV]äܩ̼ÉÀ¶ä'WÔ
Ì!™èTˆqSðïÚÕíP3ue<*)0B»rJFh´‰0I8%žQ¤iü°q@¶lgØŒÁ‘×¹-‹bfyç:›ˆ¢8Ž÷Xb¯r¤:¬Fñ#ð…¡l‹³'Ä•¡Àž%ô¯îi6PŸB ø%1Zt”B0Hˆà?`X¤"J÷©o€h ë¡©Š)áà„#};‡£(eƒéZˆtÂ¥%,RÔë÷Á"osbÂÁŒ›'ø‡(JŠiv](p{p¹“F5û9߀ŒÏÄÃJÀþ®Ê×HÓ¨«`ý4øÅÑtŒˆWîesnb·k`×)RcÛî·“mí»¼ÂóIÅ—Dy÷‚-%<÷Â6@²¬ú…ÀŽÓP$±÷=Ïd¢|OC­¤œÀ6ðæ$ªº$ªÚð„ªkATçc¸nJ¨ƒ3ɧÃ@Ò`îxbNÛÊ×>)”ò¸Û­sBc¼;õiåŒT)oÀ„Ì]é®]ÒÞ+alâ$þÕ1«ê~Á¼K°æë½%²dæî𞮎×US8}ä|¡ï‹;ÿÂñfÐïN®‰Y¬ØŸ¤q5=éÁ(êËà ðœr#¹+.éÁi¸ü@b•ìˆ½8Uyí¨qÒð·ÓêÎÝÎñ½ÇI¥Óú%ß?A2áÌõðà`Ef¯v5££¶\¡Ø…­
-«®,p\kÏÕ‚iM”Ä^.–'9f$”	œ•XiÄã0òÏó’:„[ŒõI“ÈôRÃã½Êœ°qÂ	‡èñÚ’Ÿ¼RÄÃé«ëñ2˜Øoì‚ù^×-ïî“\Ê݉۬šûϽЛ½«`P
-(Fòc§èòšâÇX„$‡ò¦ìχB†#®®}ì&KÎDQo¶åÚ.æþ{øòfÓ—’Î|	^ýÙÎâPŸ÷æ‡90íDk¬àŒ£"c›©zø’¨> ÀX
ö½!ÉIN’ÕäP+ÃIrë/úð#ÊL¢¯6qW?¹okX]pª÷„L­±sã V)@tpwaHla„?ºº‰¸¨î'Kµ8„àåbЄ± ·4ZO9¢n_W4á¬çˆzK3k{°kÔu<¼[é	Å=Dº/ôKøóe—{ ‚p8’îýŽ¯žðe×_¤8yíîPü‚>úPÈ‘˜6'¥e¾òpݽmN—)çjE˃ý Ìœx+žb†^÷à€w¸c¡ünö×û…«ëÝ~ô÷ÛŒùÕ†ª­=>Ù»7Ae ÉÓhÿ°
lõrJäe¹>b>÷r…‹»g/Ùs§øÿyÂdwêõ¾‡=õïz|»ÊíXÜe{ç	–Ýÿ¾9:ÎíÎÊzßôçþ•þ9â$G¸±K÷¨SýÀ›d¤Ú)è¯ê¯?²Ý•Eë­ô=áÏÕr‡ª}é÷wTýÛðNê›]@šPëÌ|ð'1pIþ'¸ÀÔÏ%`9þÆaâÇ
ðŸ9|óO)úß™ÄY¨´–Ó¿’$<
LX(÷+ý@rÿ›‹‡¢ÿL„Fendstream
+xÚ­XYsÓH~÷¯pñdW¡ÉhtÎæ)@S‹aƒw_BÊ5‘Ʊ
+Y:œxþûö\²äâÊš£ÕÇ×_÷Œe1üì±ç#Ÿ:¨‹ñÇ‹UGWˆpÚãE|9ñASЀ'/?Ì_ÏÞü}q6
ÜÉböa>µˆ‡'¯gž«Ñ›‹³÷ïÏ.¦–zöäåÛ³‹óµåk/fóWj…ªÇ”^œ¿>¿8Ÿ¿<Ÿ^-ÞÎm,Ýxmìˆ@¾Ž.¯ð8†°ß0rhèoa‚‘M)oF®ç Ïu³’Ž>þjvv嫃øÙÇ'g@"ß-`½æ"µ;¢¶ק _ÈäEäY¥åº*WKU5«ù†g5`DÝIR©gSñX˜^aêókÒ w]29K«üùÔr°7ù7ϸ1†å$b™¬Ù–÷T¨É–¥
ײUÁ£ä3ÆÄØNô»ÃáZ€2
!^˶õ<"Ú&üv fâ"ŸÞaÔ§Š` âj(Þ·ZO"µ¨]®´4û¢…‹rj‡ñ˜g‘^Ë·¼4Zs£UF¢
DâA—<œ9…Ø£@Btl9¡Bâ¸vC)õÏÔó&”pòÄ”Ëj¥¬Òëû‘Ý›ÌVj#ËïÉ&úy“lyù'¶ÛÝžÍûb°Ñlx¬õÎóZ[¯×L°û–¦ÆXf™×·{§7MUk/ò¬f€¦÷3ÏÄëD’F‚’ÏÕ°JöùÉÒÝ>r0ÓÂÄ ´0=ˆòM‘¤<¶L
+÷ôÕÆ*ÔzÓ]Âça¤E:Ø~Øhï“Áw ÇØpá'tv]zH„JéU®Ú&@"P©½Q31L2D¡FºQeTk`zmÃêh͵–íÔ~”&ªw«f³©sN"ÈêN13‘ëzv?_‘‚\‡r·©rÛ¦¶IƒXšÍ‘œe»¡Ž‡]D<Ç€%{ÐXri€%4÷ºŽ0ŸgjC¢'y¡vR¾å©ZËW=!»…¸)™¨^µ«Vã6óZºJbÍŒXd“€M¤ZT_ˆ'×\=VÖj$<Ïz-»Ì¨Ê!˜iCÈXlÄŽ€@¢G˜ÒpàôÝ·‰¬c±¢U&æ{Ã7§@.57žŠ3cU8BE¦ð»"M¢¤:¦[Ðì'œºÐ;•Ù6ö
+¶u-j78s}Ûv  ‹p@ýÖÍM´¦(jJs`~Yt0r=j?܆B5'8.öLÇ¢Rê-ï"XtÛãwlS¤¦‡®ô¦n¤»BT»nµ-Ï«ù'½Æë¦Ðz…á‹<äa¡Þ|3(£ëO‹ó%ëÐ.YàöwP×ë7jÕì|`Þ3hæ¼ÌXúLÍÿ“`9
+}Ïë—åɉYÈâ£j7i¬Æ²Wªa.*F·še¼¾ÍË/££C_ùº¥Zke\‘¸3ÊßIxª¾Ÿ…vØóîc™o‹ä¤ä@®*ÙêiÅËm鉨ÑûNö<Çæ ·Z¯hyBnÇ«ã}bÚP.HQëÅ}Bͤ{k½¥Iˆàµ`
+îÐ)c
Žý´‰Á”½8.yUñª¯¿6ÜÚêÃÄ}y+ªtu®8â{DÉ6¸*Ü?^DÊ=„ÝÀ9JŒ–Ûè饼Þ^õÓ…ùxÄ.Û*Ìo­¯
/wýúPýn)+h™&UÝV‹|^
¥¸§³.YV­xù›Õ6EÌL¿šÒ^üJUäÀé>jg©v–ecv‰ºzŒ×UnAWKV}õI±~kE^Öíº˜hÚÀåÞ7wG;7úb	Æénù{ø–•Ù·KÒoÉM–—Ö장Ÿá«4nîž®nÀAø·G¬ŒÛ{Ã2/—¢ù¾8oʤÞ(8:ª8a©¸–îÇKõÇçè@ö
KôpÓexQ•´xÝZåå†Õ{dkhyßJv;ŒèÐwKèyâcãÀWFÜö»_þ¦¹ÿà+šf’áÏ•$€[{J´S"æßóÜ|ü¼ïúÿG™çNendstream
 endobj
-1341 0 obj <<
+1357 0 obj <<
 /Type /Page
-/Contents 1342 0 R
-/Resources 1340 0 R
+/Contents 1358 0 R
+/Resources 1356 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
+/Parent 1341 0 R
 >> endobj
-1343 0 obj <<
-/D [1341 0 R /XYZ 56.6929 794.5015 null]
+1359 0 obj <<
+/D [1357 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1340 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+454 0 obj <<
+/D [1357 0 R /XYZ 56.6929 265.7828 null]
+>> endobj
+1243 0 obj <<
+/D [1357 0 R /XYZ 56.6929 238.5279 null]
+>> endobj
+1356 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1346 0 obj <<
-/Length 1045      
+1362 0 obj <<
+/Length 1100      
 /Filter /FlateDecode
 >>
 stream
-xÚÍXÛrÛ6}×WðÑêP€o“'Ç•]g§UÔ'U£IHFÍ[È’\åߤDÚt¬[Ƈä{pv±Hýaó!²üžáú=h#lAÜAÆL½»êàr¨ú¨Ãί—–køÐwLÇNkXDž‡a8:»øýüÏaЦÎضƒÎ>^ßü¦-¾¾\|¹¹¼¾ú{pÞu{gÃë/7Ú<è_öý›‹~`ÏÆÊß,^p¸¼þ£¯ï®çŸ?Ÿºãá§N¸‰¥/FVÈ·ÎhŒŒP…ý©ƒ å{¶±Pbß7¸Ó³-h÷,«²D¯¿6€µ·…k[þl˃¶gº-	4±1ômÛldÐö¡c™V‘ÁŽ‚ˆ1Öÿå@†iA?ÏØpTr••1’òÅPT
Ò³ŒôEé|›S¾ªpµ=9bÜM"&¤¶ÿ ¯ã&¦ùSr’ˆ)å'†g¡Jë1 ø5ÈÒˆÍè7ýfÂçQµ
-Âñ>¬E
-’T²iže“œw‰™¥\nìùC9C9ÁèE³b·3ÙàŽ÷ ¯8¡
ÿ -OÖS¢5›%)§Ê†3ý(¿1^×BpÁ¢0 <Ô¶“”O’tg–H:ãL®žìUÈH4Ïê÷“4“,Mvdʪz’³d¶³£néÜLS®J~›YI—rÍÉb¯ú7ó„DqQ›eȤI´ZOr¯U-q(ù‰UßH[N9¸%â°)¼eœ#–T¤úOˆì_—1Yj(ÁK dßVñN|–›Ý°PUZ:—Ç#Iï…Ôˆ¬¾ƒ>ÉËZ_è2S;5“
£î×åΤõT ¤)
Ò$;#dóÛ{ºzçK÷¯×KK.€PÐmó±¬Wk”u€Z®©”!†nϲ˜_ŠW6ô]×1jömϾÖešÀ®•ï’¨9‚§NÓyNSé*KÍþ“húš…ºk!šk, ”TS²âÐÎlHÄBõ«Rü¾ð‡jSݳg”ê oF±ÚE8*9tWôÛA½–wí! -L$_QðØ¢ŠjC2N™V7#ò®Õ;0x¤<oªŒ	2z½8@« ÿ¾QàÕëë|‘úºÌo‘¡Çò÷úí€_úv¥ÜØôÕ	h—ÈZ^Þ‹ûý•é{ÿNÀ'ÿN0ßNQã+jó(jü¶ŠÚ|EÝvrdÙ0?îi9çA›£œ£O•¶Gn=¥°<ÏÜYµ£9Ð3}·"UùO™oŽŸžSÿ5Ñ9’endstream
+xÚíXÛnã6}÷Wè1.@V$u#ö)›:iÝìÖuŸ\ÃP$*a£Û’tgÝ/u±­ÄŠ-ÛIÃI‰‡g†3Ã"ÃÔ?dx64	µ—ZÐ6‘mIÏ4nô»‹ª¿Ë@ó«£ÞÏçÄ5(¤vŒQÔÀò éyÈ…㓳_O¿ŽÃ>À¶yâÀ>°óäãåÕ/Õ­g_®Î//þžö]ëdtùåªÎÃÁÕÙ g#=ׯL8¿ümPµ.†§Ÿ?Ÿû“ѧÞ`´’¥)/2I!È·Þxb¡ûSÏ„„z¶ñ ;&D”b#éY6¶EÈr$îýÑû}Øx[NmÓŸMõĺZÙÉswéC]ˆ2µk­Ñœ£j4lˆ‰K_ÉßØK­
´wP+6)Äȶ_I6¸îT-Æ"×tÞƒnÛ=$±aqyØrk¨ÿµHGßQ®/p-]Ü{^]?bÒ¸~$¦=LÝ%©BD½d¾ºÌܤþ/¨Ó#endstream
 endobj
-1345 0 obj <<
+1361 0 obj <<
 /Type /Page
-/Contents 1346 0 R
-/Resources 1344 0 R
+/Contents 1362 0 R
+/Resources 1360 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
->> endobj
-1347 0 obj <<
-/D [1345 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-450 0 obj <<
-/D [1345 0 R /XYZ 85.0394 769.5949 null]
+/Parent 1341 0 R
 >> endobj
-1233 0 obj <<
-/D [1345 0 R /XYZ 85.0394 748.6299 null]
+1363 0 obj <<
+/D [1361 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1344 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F39 863 0 R /F23 682 0 R >>
+1360 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1350 0 obj <<
-/Length 1052      
+1366 0 obj <<
+/Length 994       
 /Filter /FlateDecode
 >>
 stream
-xÚíXË’â6Ýó^Bª¤ÖÃ/Õ¬z:t‡©“²"åA«ÆØŒ$ÒM‡ù÷ÈØæ
‹<Š¢,YÖѹGWÒ½Â2?l9.ta–Çlè ìXýqY#ÓöTÁÙ7`ù(~õ±]¹{¤žÅ s‰kµ‡,"ßÇV{ЩºÀšA@Õ‡/ÍÇÆÓï­ûšgWÛ/Í ª>6~®§¥§ÖýçÏ÷­À¾ƒ«?ÝÿÒ®·Ò&7ÃøØhþ˜¾aéch«þXoÕ›õZ·ý©Roç¶íň&†|«tºÈ³?U¤Ìw¬WSA3F¬qÅv(tlJ—oÂÊo•_sÀBë¢k©~AB]R& +è#è"å9º”Ð…€pªŽióâm(Ás xú~ÆU/–½(N«ÒG7±Û0†ÌqÈ:’Ò\ª´Ò™ÄR§E1é%•nZû+}ü´Ö­
-•u˜çý‚Á@Àë|å³´d
-ݯÑî@³¶ïGYò–ÊÆ# Ä{&I4?s¹O¼‰¢e©!—@BDt,ÙOõåHZŒO¡„÷K)ŠµÎJ}.óþ6	E_¬;Gê5 ŽÂÙÑCM¦Ï¹³Yî*+-E4:Z“\OeŸ¯ü\Lì‚'ÏØcÏ1Hг©³úaÑä@æy®Ux¿òçË`_²ÑAj:•Ê°Áü驺ÛT™‰Ù?nC• jö0•R
B
N’µ€–p²wpµÏåÊ ÁŽS:ý%\JK†ØCî¤%ĶOJ¥*vÊ›/Ä£ðqNïzzÄÞ5;ÎE³ƒ=
-©ÍXé쬱<ìò«õs‹ÕÉ0$>ñJå|#”´9E_{¬ów²±	$J®^›ûÙgÍå &ZÎN‚ÀÛD8£(–|+ä»»KŸÍ8[‘ñ$äci>€ût&¥:ÓKu&:+=}Þ'^†ñ+ø6år¶8'[Wª7tÿ¥4¿™’{·„ÓI±Ü‹'ÉŒp'ÙåGf-Iw0Œ¥Qu¥Œæoz.ƒ×“1 FÑÁ
-%±j>RéC8¸'O¨²éeØäg9Þ	)п)™;7
Ã×Jžnœ‡kå!W˜7óüÍC®Îu=!WÎC®6mä!ø&yÈÿó?÷øÚ÷bl!óÁ–ãB—n1nCaÇšD
d=˜±»Îß›—@ù­·ƒÆÕ-e‡Ü%®5˜•°<ˆ<[ƒé°éB[5o>÷n»wö¯[ÌnºŸ{-@Ô¼í~ìd­»þõ§O×ýÀžƒ›7ï¯túÙ›c¼íöÞe=<ûÙÚïÜvúÞM§5|ht…/e1¢©#_ò¦Æí
)÷ëÉ< ˆ9'VÔ°
+›ÒMOØø£ñ{X]›Öê‡$Ô%uò’€‚.2PÌáÐ¥„®¶€‹Ps¡ðC
´ôc5¨d!'"\
+5Nä8NÚÙó(uÛÌ
0†ÜqH(Nt0[VÌÿB
+æöØŸNeÖ³Z`—AÊ€!³©³†y³r g̵JýgÆÃy"uÖæãôa”=UØÌ(¤6ç‡Y‚¿Ý2Q÷%QÏÔÌŸµwµO$Ê1$a¢¸Lô{ ´¯¥ƒ‰z¶5põ«2õµï«|A”–Aüðjã(ˆ3)Ô#ÐA”ƒÄ‹è^È} G"ÿÛI 5L´\ž±æq,DÕ•E¨ùJoŒŽ_ïB& NLú@ëð0 rŒì*ÚÏöfŽl8ÛÓiÐlÃgûG‡“ÐW*ÂkÓZX½œçA¬ÛuZÌ‚°6šöÄ Ń	ä$I.OUnò(&_@ê“ÚîÚ'_Æ«™„«à!N¤ØnÂñê*ûí%ùŽìFóPD"Öb
+÷éŒku¶ÏÕ?ÓYéÅý>ñü0LžÀ×…Ë
jÖoŽ*¡Ô8òõäqšS"ëÿy1%÷íŒià‡‹y¹=Næ銿þ úw‚dWt¾â˜Jwujf‰4ªn•Ñâ›^Iÿé"U"‰4ŠN·(©W«Y •>GHUYþa‘^¶9ëPÚ°ø}¡R#‹:0Á­›³R\®Ž!<ü"ò0Q^Umhü½>èÓó¿(r‚©Yç >9‘@i.9¨¢í|q_øY6ÝÕ>2{×Vt;K2Æ!%̹PI¶­£ò<\”q‰©g/S”DMMÍxíŠí,”wÉZB»€¬qH°ãìH/¸”–1Cî…è±í‘Zºçüù¿pþOÎEI{‘Š—îªxóLÛ¾LRÇ¿6©ŸWký¢yƳ]Ë¥\§×ÝÈP¦×(5÷'æ›O{ömÍö*Ëfz).b-]ÄæAÛ3 9©”9#/˜o®u^Rÿ>ü> endobj
-1351 0 obj <<
-/D [1349 0 R /XYZ 56.6929 794.5015 null]
+1367 0 obj <<
+/D [1365 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1348 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
+1364 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1354 0 obj <<
-/Length 1867      
+1370 0 obj <<
+/Length 2836      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥XK“Û6¾ûWè(ÏÄ_zMN›t7ÝN³i7Î¥ÉN†¶¨µZYr-z÷ñߤÖv´}e|‚|I³ˆÂEyB¨(d”’$”%Ñr=¡Ñ=̽ž0/3B³c©—óÉó+‘E)RžFóêHWNhž³h^~ˆ_}{ñÃüòv:ã	S2%)_^ß|ƒœ?¯ÞÞ\]¿~{1Íd<¿~{ƒìÛË«ËÛË›W—ÓËë¹×ðÄ‚«ëï/‘z}{ñæÍÅíônþÝär>ìåx¿Œ
-»‘_'îhT¶¿›P"Š<‰ö0 „Ö™’H!§™¼›ü8(<šuKÇâ—ˆœ$9ÏÆXŒ0)H*¸püó…Ý(šqA
-F¥ãþÖµz:K)uÔ§V­ýðòQ}‡ƒßÝR\'¢c¤HÌ‹9lüŠªÛîն̠wRNDpð‘&´k›ÃU½í
Œò_àçîŸõèmüCŸñSo>©²ÜzÞ¦Ûšow'f!Ážûü9nž›/u£ï•©»vf7€Ìƒî?uÛOm7²‹ÙYèøhFÄ×f„ŸeäÌÏÿèËó+΢]Y×B”ãîmÕp	%D½sX!ïŒ2z­[ƒÃoôGJy[[³ÈQm‰Äû^ÝëÁÎ#^m$)$Gvó–~,ͧÄy£ûójdŒÊD%œ–Ðü_Õ#…Š+’Órü_‹‚Gµõ¤}\GA•'C:NU͆-Í$´A.Q痵Τ <Ïó(a‚d9Çt®UoôÖ‡Z‰g’d¬ÈÁ†›¯ld!¨½Þ>€¼£W
-ªŠçE¬pìu9zÙmHu
-™ ¢TÆ/€êDb˜ó`±:€µ¯›©…«tµh|ÖM‡ßÍvÊò¸{¨K?¡vfÕmk€_ýXm¿w]ÁÐ jCÎc£ô±M¾>_¬Hápã,J°ÿ¢—<žBeö$ d²,d^òë"Ø7êAA€‘L0€›–ÌË:2ä*ë9
-?.üzÓÔK…óa~À‰W}Urî0öeÉsZÌnˆáµñVd$ãÁÛ¦îwx£—õÌ74™™æò@¶i‡„,ö\Þ"cÝánptýκSòû~XYùas †ÅâÌJ™@y#!˜À[BëC·QK8x§ñnä—Õ8™†zIƒ•!ÄBÐøžð1	èþ¶-UªE¶júnìpƒ:œ	­=qz$­Q÷«[KæC¦ßÚêÁ	ÈPüò€¼RWjטg˜}³…’¬†*„]8À”£¥_a¡¯ÁÝŒÅx~óŒÇ‰@Ž;Wà‹¡Â'ä……˜\9à·+^p¹Rí½.q€íå:ˆ=&¸‹Ã˜owÕ¡nïaRZì™x'-£Ý­.VÀ]èjÀ™sÛ	Ì‘e¹ÇBÐé;† ÄP¤Z'Û¢¬ËÞF»u³¡“'2^¨Þ…HU™Àõ’ö'6-  —ÐY9Péá—§GËÏ˜ó ¹¸–"ÔåÀÅ®-g_›Rç®[ÞüÝõk¤~ÑëVB‹øºòjQ—­ðÆk³û´_—Wúå³Ñƒ}d؇%NúšH„?šìÔ‹ìá”1ÃÂ.(pF±‹Á€ÆmÁ®j©ºKŸG¦Í8Kð””{ßš*Ås‹ÃŽ¼@
>í€_…Ÿ!®ƒÂÞ¨­±ý9MáRVUaÕHÜ‚zNžƒ®e·†.S:ß9ƒb¬Ûe4øí*<»ò£ËÙT-m=ÚmP/	ÀÕM½®Gh½Òóöø‘E܂⠌̽'’®s‚ÀÔîëÒ¬,Èoº zx¸2€pƒêÞK`UfÎ>cjðБDuÛ#Ë/pV»ÖWYf*/»êv=øÖãèqŠ9Ôô(µqš}®ÚkŸ5'ÎÅ}WÇã@øæñ®×ÈP86ûnÖdäBûwÝÍNõË•^{i›âÃÍ_xP¸ó‚`I^¡ˆõçÑ´©õ¦Ñϯ—Ю‡«Ç €æòÐåso×]N/?	#9¼üAv6Àrä6‘Â^ÐáÖQ߯ZÙ4j©Ãù¡ý½‚S"~öàõ•}wƒç«Õ­k@)üiEáŒ
-ñ^rB3žÞ?ÿû
ä.“zñýJûóåKÍ‚b)hãŒÀ;1„ÃÈÀË+;MÝÏ;$èN˜ ì·wß!ÑL¡p¿ÀØÕßñ2  ,tˆ}䮌ÞtAYp‡³Çá†ýªyý¾Wˆ)b½-Iªnß[Wø=t;$6;ƒR°IäÐ@`Îz¿ÐeÔRÊk‡o«¬}û3eÐøˆ«ßñwÆñýýëÞ’ç„e4Åkoʤû«ˆ¯ø¯þcêñ_;°7@>¼ANïé4%9/²H$Ä겹ɾGøËK¹þFÇ>endstream
+xÚ¥Ërã6òî¯Ð‘®q‚ÉÊi2cÏ:µãdmç²I°DYÜP¤V¤¬q¾>ýDÉtj³S.FèwCz¦àOÏŠ,V¦Lgy™Æ™ÒÙl±¹P³'˜û|¡…fî‰æcªï.Þ_›|VÆ¥Mììa5âUĪ(ôìaùKôñ~z¸º»œ'™Šl|9ϬŠ¾¿¹ýĘ’?¼½¾ùüó݇Ë<n~¼eôÝÕõÕÝÕíǫ˹.2
ëáðÆ‚ë›^1ôùî×/î.{øáâê!Üe|_­^ä¿¿ü¦fK¸ö*6e‘Í0P±.Ëd¶¹H3g©1Ó\Ü_ü+0ÍÒÒ)ùe¦ˆ³"É'˜è™Öq™eɉ K´%	⥓$ ”ŠþèÚŠ/x?¸¡ÚTíÀÃOÕ¯J%m=Ô]Ë×.ø¹wO
+‚¶;êKÍæ°O™êt´O¬e§‡.K½l«þ\˜Z«Xicg6ÏãÌÿ“4È«ÌN…ù-ò§Àk˜¸Ô*}{^§€•€¼Âœ±š‡Í-èÕf¹=šz9NMœE1³¶D†,Áë‡j'’6#ò‡§b§£åÇs.$’»Ñ–M 2.
ÖA®ˆ˜C=¬:?:âîo>3ô{õ‚ÇÊTݬ„-óBo„Þ¿¤rýå»Iǃ{¥¿'qÍdF2N=
+É’Ìvžm
+P8.†
*¾ÆxŽªÕý”úÄ2Qã:ã$iT"gk:ðÁGr€Â&C¯ãOk`Øn7`|¶J2¿jåWMÈͳO”æ¼x-º
D™%=ÑàŒu»ð„»	×€~ªeÏè`ªã‰ö[&â°USoêÉÚB¬”,é'-£7`ÂŒ< q2H‘í¡^k4r­¢ÛÎSøî+ n8R=	{õ¤æ~U™ªQà>"™8VmÏ(r^À¬÷­xÙÒϬ„vÝí{8[œôxJ“ÕôLµ%
†`‡½†X¥HÊ8qnX‰DuNF8‰ö}ÅÇãáÐÍ0Ù†±þ)ºáT¿XC
+a¼SI¨û勘]òš‰LT}T›Ûl›êݱº„pJ‘Aš·+|”/d_*N‹ŸLÇtR"T_iÌr¢š°Ðý@ûã«Žúi=ð.ÛÆ-*Ÿ?*©+§¬?Ñ·x2ÄeHîçWÕ-€‚G")äðà‰Ó§I¬ò$§ÿ×(ò¢Œòú’üòš³ÑÀ8MŒ'¸%:¶pJ¡B!@CªòSÕýgO†щ5Þp°‡Žæw‚Æäãeb@¡éÄØäF_:Ϭs‡ÜCvÃþ¼yó†}¯/þÁx^ê›îÐ\¯øûÒí¥Ø‹·cs©ì-‰¬K\Å·#ËZßÐÁvB^Lž;Ý`Œ+÷oëF
†5Ø䇧_òf‹¡ó¬]•oµeœXØ<5° äç€~Ø?N;Yµß¨Ã09Ód½úG‰ç ÊcÀ¥i’¼á®Â;Yˆ±Ã”`΋j;0…Doä70á(£s–0Ø4/oXó”Ñí=~‹ÕèK±&) 'ìÚ0ôÝ¢$¶në–§+¬§B1(ë°®Imt/r»I›•ç´‚£,®ioWüŸê§|;0ÑÞbÒšÊIÖÆ4ÙâÀÈl	é¨]Møzm|ž•BJý¨–¿þ{zïãžÖg—ÄBÒIíY=‡&mL~^T2’•@[€ã )>íwdTÔ*eòº„ól}•üé÷[lÒ&K8ª 
+Ë1‚ R|ÁÚ)°_ÛÔp'Qú^8ëÊŽ¥ï,Ítéu	¸“>ØJc-üƒaM–Lü¬j} I,šE³'á ž=´kœ~ÁprÔT‰Dc¬LÖu#fÑ2†ŒÈ–>®Zª&ÎÆŠÆòtS9òŠœ«i*M5‹P}·‘ÂxḯÅÂÜy'ËݾY2øTI=ëPЄ’V‘èÎßSthOÀ¸`È-ß
+ÁŒ®Ú3–õ‹PÝò¤xy$ðï.0;8ñ¦pØ  ûÒ/¶¹/D̦þŠ.ˆàÐÁ×Üù‡RÄËs*Fâ :ÂC=ÃUu<¢C®Pt9⼞n	Flz«°ò”c®›8çáGâ9@%‚È3,üã‚A…D‰?0'b|SúûTéñ^ÙÈç¹¢†ÓÈóòÊ„5¾fPÙèIð¬Ì1åÉU(Maæõ+™*Ê,ãgécýr_/ñWCD$ß)SáN™zu§¿ÊŽªÙQ’G€(OªÂçIœbÇö(UH¯_D¢ò§#åËåË ¾köü$«&tå0ÖåÑSýŒ$¥GLs$%ÄQ×™r.ÅV(õbOeŽ)‡á<Ñ>î3
)sRFלç­oßñ[™T0¨‚n	4œ
+öºgÂQ–lwõ³”°¤‚g÷;öýd¨fþÖFw×u©ŒÒ®`ð“¤2k_Ùc%ðÙPXLÀrpz¾ÏÔ~ÝÎñ±ÛmÝD/MYÛ7о‹%…[úv–d$?HÃ[íZ×0•ˆÔŽžÇ©îy:4Õ~³Ó‚æõ9£GöÑ9Ç—¶±·~Ö73ßØ!¥Ië\a½’b¯”—S?¬ªðÛé7ÿŒ{ü;…f¿(’ã/´'?Œ(¬ÒÊ|fàªÀ嘛Wòð¿÷
+Õèè×endstream
 endobj
-1353 0 obj <<
+1369 0 obj <<
 /Type /Page
-/Contents 1354 0 R
-/Resources 1352 0 R
+/Contents 1370 0 R
+/Resources 1368 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
->> endobj
-1355 0 obj <<
-/D [1353 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-454 0 obj <<
-/D [1353 0 R /XYZ 85.0394 589.0297 null]
+/Parent 1376 0 R
 >> endobj
-1356 0 obj <<
-/D [1353 0 R /XYZ 85.0394 558.9158 null]
+1371 0 obj <<
+/D [1369 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 458 0 obj <<
-/D [1353 0 R /XYZ 85.0394 558.9158 null]
->> endobj
-1357 0 obj <<
-/D [1353 0 R /XYZ 85.0394 534.5045 null]
->> endobj
-1358 0 obj <<
-/D [1353 0 R /XYZ 85.0394 534.5045 null]
->> endobj
-1359 0 obj <<
-/D [1353 0 R /XYZ 85.0394 522.5493 null]
+/D [1369 0 R /XYZ 85.0394 744.4469 null]
 >> endobj
-1352 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
-/ProcSet [ /PDF /Text ]
+1372 0 obj <<
+/D [1369 0 R /XYZ 85.0394 714.333 null]
 >> endobj
-1362 0 obj <<
-/Length 3416      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ÙnãFòÝ_¡·Ð€ÕÓ/ì“3ñLìx²/v$´DYL$R){”¯ßºš¢$:“ìÀ0ºX}UWU×Õ2
f'*Ém>Is¯bmâÉl}¡'OÐ÷þÂȘi4ŽúöáâÍ;—Nr•'6™<,keJg™™<ÌŠeÕ%¬ £·ïÞݾÿ÷ýõe꣇Ûw—SëèÝí?ozýáÃõýåÔd±‰Þ~ýãÃÍ=w%²Æ··wß1&çæ•EïoÞÝÜßܽ½¹üåᇋ›‡þ,Ãóíð ¿_üô‹žÌáØ?\håò,ž¼À‡V&Ïíd}ác§bï\À¬.>]ü«_pÐKSÇøçm¦â$Èf¹Š÷¯ïË{hØW@›8¥
0úxßifT’¤(íUžÔ%ÅX­rXh’ƹJœu$•¶Û="kÞ¼Äap’©Ô[Ü]/]ÊcJ¢?šºd\ÕJ_µ®VÅ–»»†‘…ô­Šçò0ñ
-Á<*?ÏÊMÇ#ºe!PÕñÀí¥É¢r³ªfEWÊM½Ú#­@ÕԕDZ%òº%¬îlÝ}Â6“ɳ†ÚyËÍ‚;þ\mWnÅÇAlU¶˜Ïè×/ë®âµóP}}>žÒ†C|m¢"LµZGuÓ	–¿Û®¨çgúÛ–Ô
-Pp@º¿Ç—=ITf³T.0.6W³¦^ŒÜu0)Ø
-ú윋–•¬¿k‹'¡Px”©µ`<µOŽ9M*íàž¡¬Aaæ$D@²¨Ë€Tŧݖ”ª»àâœ9ƒý¬}åÜ´»Í¦Ùví¨˜qï,aA	>cédq„ZÖ1€{)ö—Æ2Ø1Â+8MŠ2Ðl—´,bÖÕg¼‚v
œxIûÁ2âçE,q/:ÂWü]êÉ@tï+4ŽV^V£ê>P`§ñ¶ÊRÖö±6ªPØça#ö œ›že–Í3ÿ0áˆQ½£DhY´°˜FHýÔþp®xpçiÝ9Òi\T¬VÜ/.Î÷1ƒ²lÏÂŽ<¢:„Fè)Vm3&Uö,äéÄã-y³¡ïkÅþê^ÉgŠu¦XŸéϼ£Îzï {GˆR‚ÈOê,øIì“Á7|£4ßqlEä3vG:„+:„Am³Ú¡}ígPW ­K£§ê-‚óÝÂq	q;ô„ž})6¡T³…}øM>' i4n×-›m…AÃsÆ0GoÛ;öó	xÞã
t>8ŒDA§„1ìêõ?蜖­2LÙl«g	-`JÙ½4Ûßøc×NÇÃ\?I¢ûwoMn2þ¸]€aÀž;IdОêcÅð%}|$½
-$lœÎÝ÷	QF«ªž"ªØnŠž;^Ûˆ§Ð*ÉX`ü@Áß$ 'þ[dÊm]¬x”°”–&¢€äLJvÿa³ã€æXÖt[ú‹|qc|@¬cê43ó™WYâ’É0ŸùÊÉk’hv2×$û‹öS^K¼\ê”Ï8‰I¼ˆM.žøÂ&“%Ä/àÇK±È2MUªaTŸ{yŸG?[ëyŠ¤ˆD=ÂþB?Ž-ÞN/†¿éúB{¢ŸŒ¬Iš8¼CýBy´)Ç"ÖÌ`&¬‰£Ç¢­àbO-ø­k9—žÔƇc‘•>?»u*=‚¤¨£¬ƒ7 ¨Âën¿)ÇÖO1äu2÷uþºL%ir[²Á¸:°§“³ ù8_âd{‹˜Ý©DÄ©Ui§§^z”Œž³,“… Þ}ŒÀÑ~.V©õÙñyð>„ðNA¨~ƶ+‰½–ÕmGk„ž¡b³¡H
lèßwå¶*%Æ7&6Y{|ËÑšt÷šqqC\¼›-x³}³cà¥à¤Œí£oɪ7ϦƟV™*qed¦Öç’¬‡QΖEýtSÂðÇÍ*8Â0¹9ŸVÀùæÜñÈMš||ªPcüÈ•¶:ïùÖ(¯|šŸž‰âBë-d_±Ïì!éÃüÎzîv°½È¶íØóà䮡áN•Ö›ˆÉvÈâÄ@?W³’ga¸P\iÒã®ãÚ
-Ë
!2[&‘(Ç$¡r“HìNPÈ QoRVxZ!·&Æz  Õ§Á6lF½ •Õû3q’,Cô3Ðÿ×Cža$ñ•ÑÉ!äI
8Õ¿EÉ„WÃ
ý>w_¨3ÃTû¤Ä"ðÝëÌÄ:ƒE‡ª«ˆwðÁ¥1Øÿ[–DÓV
-e40Ä›¸„´}É“r>@ì8„Ç…
-Æ J}ô‚ªÑ4î?¬à&1Зî
-¬O¼Û šÛ˜KÚˆà’Ýpîð$9ñ(Œh¸E©Rhr¦öt~ä¾ôTaöB+@uð†¡Þ”Dë¦í’Š“”ªqpq1)nœ„ü¡>¥›º8eŽý
·Aðc…qä»_l%e­¤Ð3[­º½»b€€ÓÂI[-ÎlÖ›jUΧäl1/Ån5J‘dGF²#380~
r"Í¢‚'`ôÞ"uœÏÁ\®!æ´fèöNfQ™1uÃíã®ZuS.ដPH§#;¾j8wò«nùÁld"˜ÄþÃŒ×‡5™Ò‰{å*ƒNï ‡Ãü2Ó©0aU>Q}xžNLˆ“CV•÷6„Ý´BË¥„Ø9Û¨¬CÑ„LuP&è9ÝŽUìd1vÚ°x½Øm·½„¸aÖ?²üùúX|QPOûúèíÇWÜuwó€ï–W\ýûxÿ]’â¾ë:<ñÔíMÈ¢±T(«‡\=Ã¥<"a¼ÞìºñØŒ#·ò3¾²Qý²ÆâƒÏ{`‹ôÖGñ`Ögÿ{Æ·Êà¬@SŒ@Çžï˜ò‚ªó&·ä§Mÿ~÷ñÃõíb4K¡ySÊzs 9œÎ ˆRÆ>"¡ ‹£ÊÏÄ{ëY%×±ñÎñ#âÒq—ê´x¸*‹AÈwôµzŽù‹J
WÀÄ.øE*¶:"[/ˆ¸ÀEÜŽƒ’ÈøƒNP4Ñ8é8‰
›žæ°_[†ûëlÅÁüžÑ¿ø.sâ<>~–ÿ¿&2€• "?0«\‚
-¯ùg¯ú6Í hsn‚¿W€Ø'=ü,⸀ ?90>Uij’þglXPP
·™œÉˆBhÜF´ð}¤drV¹oZ†Ù%#DµI8o—¿eÀ¢Y­š¾pš2ulnÈÝÒ5ÑäÎO»¬Â®|õГ³2úü:@f	)¯	õ
-p#fݩ̧!ßAÓ9^*5©Êµ
·TÐ,ÇBMå!4œhL=XZŸÛ“ò@Höà;|<Å$@÷ÞE÷ý³f+·¬;+tŠÕx.Zé[¿Š•&€ô v7så]œõb92€:Ü[–mÕ¼–	æ.ÔDrøh^IK¯ÂöOìá½¾B¹&ô<4“·ù¯·ßÈ’?rǯl–q)a?’p6ºíŽ	8ÿ1@»,®tg*ÏO“Ö#ÒPG‹GtqdÕŸ‹mÕ¯F…Ü·]¹n¹ßâååÒáO!vX£é2‚Þ2©r7>Çn†o¶T+—•9¢†9ølƒ-þ&bê‘0¿•û—ÁÏþÜ!|ÿiì@Æ)ÿ .Dú(µõ}ÝÔûõ‰Ê±.¨×~ëä¨6öË$øõï ?ƒç²ÌŒáQ4M!
-ϘÚ3ÊVÖ!>'ýlßEendstream
-endobj
-1361 0 obj <<
-/Type /Page
-/Contents 1362 0 R
-/Resources 1360 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
+462 0 obj <<
+/D [1369 0 R /XYZ 85.0394 714.333 null]
 >> endobj
-1363 0 obj <<
-/D [1361 0 R /XYZ 56.6929 794.5015 null]
+1373 0 obj <<
+/D [1369 0 R /XYZ 85.0394 689.9216 null]
 >> endobj
-462 0 obj <<
-/D [1361 0 R /XYZ 56.6929 167.2075 null]
+1374 0 obj <<
+/D [1369 0 R /XYZ 85.0394 689.9216 null]
 >> endobj
-1364 0 obj <<
-/D [1361 0 R /XYZ 56.6929 139.8789 null]
+1375 0 obj <<
+/D [1369 0 R /XYZ 85.0394 677.9665 null]
 >> endobj
-1360 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R >>
+1368 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F39 868 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1367 0 obj <<
-/Length 3031      
-/Filter /FlateDecode
->>
-stream
-xÚµ[Ksã6¾ûW¨ö²rU„àE8:OÖ©ÄÎzœÃn’%Ñc–%R!©qœ_¿
6$:oM¹Ñ|h
[PøÇ*"Th¹H´$eÑb³¿ ‹ÏÐöݳ˜UZõQß<\|ýQ$MtÌãÅÃc¯/E¨Rlñ°ýeùá_W?=\ß_®xD—1¹\E1]~ssû-Öhüùpwûñ滟ï¯.¹|¸¹»Åêûë×÷×·®/WLEÞ綇3/|¼ùáKßÝ_ýøãÕýåoß_\?8[úö2*Œ!¿_üò]lÁìï/(ZE‹x „iÍû	I!ºšÝŧ‹»{­í«Sþ‹„"‘âÉ„¹˜r`¤I, É8ðª(›§¬«T´üñæÁär›}ÉvåaŸ
¶ä5þ~xJ˺Ț¯àQ‹eŠµ?\Ýâ{‡ê’©eÙ”›r‡M›¶&K›lk{*
-R±bŸoWL'´ßK&—ÿ-Û²M›Á¥Õ0·úlÒÂø°bŒè(â­5ë‡§>d›üWJy+*^òæ	KF.¼	äÒ=ßhp3UÐ%ÕÝ'yœˆDŵ٥5èŒ0Öƒ­ˆRq¼X‰„…Ž6äâ’ॴ³º;4yYÔ#*QB#`yœ0qyfêXЪ‘g#ïPF¡t·+_V0üùãëP8“ŒH•ÌHw¨	ñ}¿1«üOYv‘¶°ÍêM•·îÀŠòq½:!”KmGahÅ@t¤ˆ Áy14T0Ab¦cÏPl¬>/°pß3ÙágL÷‹&oNÆB0pÌH%T®õŒïjN‘QoFr–mMÌâ¶õP¶u¨Ó8ý~̪	²N1îPÒ}²EÐ
-ÑÐÿždsF¹–%@ðy®Át¡'¹fñ3û};׳–&qØõ5§È¨·0ר†%O%3\ë¡\ëP§ajª´¨aiÑMÎUX|šï‘-’„S-|ùlÊ#[ߊð8&q²ÏòƒN”	ÏÒß:üŒÑã~ßÎ7‘DÑç;Ôœ"£Þ‚|‹=E4÷>ê<ßê4RÇìW²1Û E\‡¥;Ô„xŸo0±„ä¾ü÷äÛÉŠ!Û8Q$Ÿg˜ïæ Û,~Æäq¿a%5oÐ8ì{‡šSdÔ[˜m°éQ	„0Ûz¨Û:”‘ˆ#´:”»|3±–*Â8—añ5!ߧ›0ǘÄWà“Û\×èÿ~…?åûÃÎ’Æ舻|þ¹UÜ ðÙZÀ/ÂjG["Ç0†s‘€¸¯iˆV~Æ´q¿“´‚ûˆV’ÃLŠ°jF‘qoaZ1ˆyTÏѪ‡
-ЪC
§ÿ
-Î[/iµÍ‹ÏC=8¿Áf>¬ˆCMhÒ7žÓˆØ7ëÿÏ
iÎiÅÎÆ6)¨9FhÏè	~Æüq¿oŽmŒ™’áqp¨9EF½I(•$@W&auž„…cV—玤¶ZZÎw¨	éÞØß%Ñ@ü]±{·s½Ügidy<îð9Ÿâ˜£YÚœ=ƒÂvIGIw†h3)Ðc
-ƒü%Ã2¦7 Ð¬ÃcÌÖÖøkÌ4ØÔXƒ¯[Ä.¯Û„’)éÞÖÖYõ%«¬€_iDmj_M‹A'‡*ߧx’3»ÔÞÚŠÙÅ}
-b*è‰Á’[; €}HÑ™U‡Ý±ÆRZ¼báæ'[±Ýâ8ÔuVã{^‚Ê`ÚÕ˜b¶]<ŠO1Í›£YXÙ@M*S%Ë+«^Y5XÚ§V½u6Ðå’-At¸6]‘?ö˜E3ÞÍ€yêÂ&½IÛˆÁãNÛžPBSvƒZlm
œêf²y潤̎¤a4šš”¤e‚3AÁòò˜wô[aï3•ÜÓŠÄ&Oë9fÆRFÉ~€Èp,x±ž1˜,fs\cÉЬ¶›¤‡Ó¢hµ6]¯nÉÌö‡æ‹f¶œå°G±3±¼‡
-ÄòÕæGŸ²ÍóÊÌÎz¼K$VzF¸CMH÷3>0$&Nyâ0ÔH#vß ¬›Lݱn'žqX‰5–}M•oÛ‚“\ƒ%iáº%–&ŠÅ¤-9S¿MúV¶2ïeU“æVò¶ÜcYbȪ­B…‹?	—ƒX‹ñ€"^š	ºkß‚ûuiL¸nÖ‚CYÔ®þ·Xóˆú=>¡‰P(²æ¥¬žÛë…3Õ§‰_Ò*w
-l6eÛS»¥Â¾Ê©ŒüŸ.Ïݼ2Káe51µâ˜PØŠuÚ>™…×-¬£Ý¢?1&Vî„Hq¶Ç4ßMmaUÔ¬NÏ«ÎA'%ºµ¯Þ¥_¦ŽÐöVBˆwÔö´Å” ~ÒüÌÔþ…á‰ÂœŸösšôû?F3žÃ‰S'<$ÓaFBýœIÍ-LOêûúºWÖˆÄÒíôÆîP=óLJ:ìóÜÑ€ŽÌ°r%L‹¯&¨Â°§0›˜†=a3|ê¡ŒêP§q=ívG¸³"	«k…å;Ô„þœ×‡•ò5xO~õíO¸Ébªó)6iNÕ”{¦†r!~Æèq¿o暤&{¡“°÷jF‘qoAÆÁ8Rr†q}ÔyÆ9Ôi¤ò¢É>Wy3>ŠÂ´ˆá¤VÀ¡&4ð)§Ìu¼òUxOÊy†9Ç£<À9‘ÀÁH	ÏÖç:üŒÕã~ÿç$‰y’„ÝïP3ŠŒ{s.SÆg8×C8סNCUçëÝDÖ­½A—°èÅ;Ô„|ŸqŒH®µ¯Àû\‘ŽÌ^#¢´ÖkóÁ÷-
^#XüŒÍã~ß¾žjJ8çaßw 95†}…Éf>$jŽl=T€lªÝ{f•9¯®ê2]5Ínà(ŒSajBŸnКæ«ð>t›0dH8E„\’ÂqBr¥=SƒñÍâgŒ÷ûøfîW•{ß¡æõ¤Ó“h&ÐG§œCõ®­0><×Ï#ÎÅ ‹g4p¨	<Î%”$:èð>‹ê”%ÃOíà'ÏŽLZ/é«7w«eñ3fû}ûª
-§/Å:쇚QdÜ[˜u°,DŒÏ±®‡
-°®C‰æÂuZ¯å¹„˜‡« d‡ší±k¢bˆæžìöž´ÍSÊ.™$t›Á*LÑ“ŽØ^bíÚ¢l¦JÚ¼ ÔMYaÚÅu,i—Š†vÓa›ý¥]&Ǽszå±4Wc^S_1B™EÜψ÷ý9ºÌ‚8㾡|Î^_l†¤ð3oæ6£~'šaŸ«ejSü1	K,µ>ÀËSÞdõ!Ýd«m¶Ë÷¹}5YvRLzxk14˜„YÕõ3Ðe›M¾²·Vo/må®·ubƒNÕVÃ@~…©â6hêÚÔ¿)ÔÇuý~ÄïguOK‹s÷âðpHëvŒÛðùh¾ÀíÔ(ÃêØæu6•†ycî±ÿ’¾¾žÝØhY£æI²KìuB5á4Il
-Ö $륵à¡KkA<õ¾.Œv«TëæÓ7iJ¹›4ó
²Ý×Þгþç%[ÖX.R{½f$«}¶/«W|D/lWë]
-¼ÁÇNSkY{õ–Ø$2÷&i+³NNÙ t{x}·7é³u’7 oámë½¢rù%Ý1Ó*NT1
‡²6[ë›òG¬M·ÛÜøt‡õý€"—Û*··bÐôd2“mõ:Ë
-¬ƒú3¦‡¥áI‰µ6`I{«f>„o³Ãlù©Ü8†±¡NOß~8¡'Û³Žt›Ýq;ý]6¾š›Xµ>ž–,(wW&E6Ñeg@ŸÓëW/£JÎ}©/""§ïàÏŽäßþŠÿô_¤ù üìVͤ?¸I RÆ©‰jî>÷«þ?.1Š\endstream
+1379 0 obj <<
+/Length 3165      
+/Filter /FlateDecode
+>>
+stream
+xÚµZYsã6~÷¯Ð[èªB$€Ggâ™8•ñd=NíVŽZ¢,f%R);Ú_¿Ýhâ%j²“­©)€@£ÑLJîd>áŸE1‹­°3m‹BÍÛ«pösﯸ§™×Dó6Õ7W_¿“zf™E<{\µxÃgË_‚˜	v
ÂàíÇûwwïz¸¹Ö*x¼ûx=Q¼»ûá–zïn>|¸y¸žsñàíw7?>Þ>ÐTìy|swÿ-XjÎ0}¸}wûp{ÿööú·Çï¯n]ÚúòP¢"\ýò[8[‚Úß_…LZÍ^á#dÜZ1Û^©H²HIYl®>]ý£aØšuKÇ진aQl¡Ç#0M¨£óûÒ!ìë»\r°ylzûÎ
gq¬¡˘)«N>±-ŸpΙd4Ó‘e±Ò9eUì_“ýóõ;;ÑkÍthbØén®çJÙàW!-¹æ&XÒàŠ<Å	úÊJjlLðšé»*¨]ù¯a(žŽEJƒ-žYþLcEÞbdƒ]êæç(*5wêDÂI·,¶Iä‚GÁSRf%€DXR“^¼­—dRÕj¡è#ºÉô‰¨¬’*ݦyE+lã :îÒ1þša¤_{Þ¾Ò°Xáé‰ÌSy]bP}ȼ'N~þ'«Ì…LÛHw­sFÀã%ùòkà5ÜOFLeºú¤ûr„#™ÙÞ\Ï¥ƒ×u¶XCWÅÁk¶ÙP/Ùí6GìF 8ôÇ!ÝgiIq™„¨5¢PòšUkg£PÕ:ÅŽ9Ÿ³—ÔwŸŽ4íé4ùÜõòd›:¤ÄÁÝÊ#&N6ZóslÀ™Ñû
jçăðuC¸’\ºƒƒíŽFé'DnqlÓí®:Rw“•žh5ê<Cl€pò9‚f…±ž´Æ(œ½d%P‰+s3•ú‡Y*ÝòøSJ#KçY9•w%Í+¯yàvÖOÇ"Ý4Ì<]¤+Üe•.ª’fàlvÂ÷ØFĦ-Æ ^å4‡L‡„&L¬¼UŠ]•ù˜õ òÚÆÎ
ò\2Ž‚Çõ¡ÞlE›‹u^VbŠ8r(S}8yBsÕ5.¿¤ÌæâÏ\`¤\шG6ÎÔ.ÖIþ\­=ùSºN^24:׋i:Ï°|ñ”lÆNȤ¢> ÆìaY(BÛØ­	PŠ)ȸ=2ŒõB‰à×0
+«u‚&Q@ø;j˜vp³È¾¬(óàâªpäÒÕñä›#NxæÎ0ü’-RZõàHÞŒ!ééàŽ[ìý†=¶ E¿ÑÀÚwJ/¾—î_àð#)ëAÏáyƒÖ™ÂˆÓˆƒvò4]v·¡à0šË]ºÈVÇ;/]¿‹Ö/‰”QÌ@1k_X›¨PAAOsÈ©ü/°ôÎ;Q¬˜Žå™bG„Ì—Y‘r‚œQ`56L+QG÷Gg8è˳*s–ƒç,ìPö䇢ð£¹s5zW;¾užA¼¢7qàPº`†ŒA@:ùÜW]R±1?ÿ“àÍ­w2thW߯’}URÿ°C‹(È*?P¦eom[ëlTSÔ¢àù’úÉاýÈii¤Šc¬/¨óì,	Q‘€‘mQVÔ#p/¨Ô‚oJoØsf‡E­aÔ›=nNÜHS6Çù‚ÚÚñ}Kú€)(ùbÛõ” ¼êf›¤ôDw÷o¨C*à²ZSè{r-®,¶»l“.ç.ÕÀÀ2]%‡Í¨Db¶'…ñëHà
+ä\ÇòÞ¢tiéׂ\{êB0Í©wwïW%/) u°}:d›
+…q¡Õ§¿ã¹°Ñ:’_tÆOAÃBõ§ø_áX¯86Tl! p=7\Ê”³n‡Ò*åm°IŸLRsL#„‡Àž7ÅÓ£ÏÑ"¨[ÀÄ’z”™Eæ¾twI'ª±3ýíÜ –ÏŒ260ÏWû¤¬ö×P4,ªú>5âD„9®
¹K°)äwöì
+_×æohêþö¯Îî+>>¼Ç|ÄhîÆUP0œäå«zè°UÑhæ¹×ç7{-œÆ0ˆÅzqE»Ã&”m韻M¶À%áÊX—ƒÙ¶=z2‹ŸÍ;Å 	’ì³Ï\iã%T…žØ4å§ÆòsDŠ$‡²
„æV¸$Í­îÿõíÇ7w÷Œ†É³Ø[©'Éñpº5t—Á.zçœp8@‘†¨Ò?í9q‹›`¯Í’ŽœãŽ'ŸÏq—,]vë¼Mš´j@:¢=h÷¯ÌAmáF²N‹kW¶8°÷‚‹›ò›†œµ£$žþ„	WÊ`B1mK‹º7ØzÓþ¶S³ôíõ)õ¶Y@lKê`E­¨àÐ@ ‚S­ðžWhrÿ<£ÎC뵦¡Ÿ·¸¨Ñ­Š|Qª=Díùˆ™ÛÁ%†©P˜ŽDƒW£†jDŽNÑ=à†rœ×íXøeáõ±O__Ó`Md£îcÚÿ´¨$`†Ç€aY^i[s`U¡
SFJn+ÜšqçÖï„ngauó–	Õ™€#BüsÙwä…xëg!\‘O¥%·tH¿*©O5ö¶É‘:tÍÄ+}?y‚U±Ù¯¢B÷°mB«O\`	]ýÓŸ¢nVïJA+l<.òO= pgVðúyꉑD(™Qº¾b²iÞ%ºõ¹f6ºf•Wé>OÇjs…¯i¡>1ät/›+ÈMÊŠÞkJ}7
Ût‰å ›|6ó‹bïãRÕÜŒz÷¦—¤ôsÛäwŸWÚ÷åER¦­pd%>=Ö/	]•¡FµõÖi™ç.ÎVÖÏmÞsR(z‘ñ²¤.=œ@ÇåQ¤Á¢b['IÀzÑ]kù)îÂׇ»Ç¯<Ëiâw
+ä0pƒ7è_Ú¥TË`ÏÝIárQ®“Vñ1³¶ÇMž°(pyð%Ùg…«nDzJ·%Í,“*yBCãCÔåŸÝrOÒìi®º¤ÇaW“ïöBËs¦+¬)j‹TT’û;Œü;=¾þ­àb
+ýîÓØ	PL©È´žÑ©)y‘·=Șõñë;ˆºÉ}I/L„ŽÃŽ‚|ø’nŠ™†·´o×IQÂyÂ
EHB£?ÜÜÓ:z`,ªbQlhjÑ.§œHé4ÀÀ6[B¸Ð!FÅUð3Ýœ`]DĤñ—Md›äcÅV]ÉtïZ0€•âéíÅAÖ¦}ûÝÍÇ1HÁ¤n¡}T¾d͹ˆ˜1qérZì“¥ìÒöŸ›µ§§¿Î¯Hpá¸+ÒÀzôW3O4oSÏ4
•+‘1äÏÁÿø²ÓÛœC¸å
+¢ãäî
ÕÈöär|*Ýí›Òª‰‹Ë´\ì³?ÈGÞM5O¿ô•è?=CÀ¦~d©Û¾„Â=±­ÀTÝVÓ_ÐxÈ—T^œ”CîKðw­­Gÿy´×VžET.LGÊvT@\CAé!ßÏG\¬™’JN[¿¡º$È€Û4âð‡i¼gL#®E5¸šêä©Ã*–tÞÀ©a¬¦wo¨F¶ïâ
â¹Ñº»ÿ—áÍvðvÒ¢6ÁL¨øùøETª®™§â[MAå!ß¿K-‹âÓ¶o¨.2ä6‰61«ù…TÚ":µš·#÷ÌwÅ&[Œ¤RˆÀ:²“{7DÃÍ»HSpȵììþ©)¬»×üE龪zøwš¿ÂÁÔþUøöâsΓF÷½'ÁJª·–œSÑ«&ŸÖkÀuM üMÖ0wÒº
Ñ)ú¼&¡GL
+>¤Íy yšþaŸû_Ûñ—Ã>¢4‡SÊ)š<éì~Ræÿ·zªŒ‡‘5çc˜
+ˆ¨¥îâêIÅû> endobj
-1370 0 obj <<
+1381 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [251.8681 468.1254 347.399 480.8626]
+/Subtype /Link
+/A << /S /GoTo /D (root_delegation_only) >>
+>> endobj
+1384 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [312.6233 667.7189 381.2953 679.7785]
+/Rect [284.2769 214.7669 352.9489 226.8265]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1371 0 obj <<
+1385 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [310.4119 636.5559 379.0839 648.6156]
+/Rect [282.0654 184.1166 350.7374 196.1762]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1372 0 obj <<
+1386 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [328.1051 605.393 396.7771 617.4526]
+/Rect [299.7586 153.4662 368.4306 165.5259]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1373 0 obj <<
+1387 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [320.3548 574.23 389.0268 586.2897]
+/Rect [292.0084 122.8159 360.6804 134.8756]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1374 0 obj <<
+1388 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [359.1386 543.0671 427.8106 555.1267]
+/Rect [330.7921 92.1656 399.4641 104.2252]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1375 0 obj <<
+1389 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [429.9426 511.9042 498.6146 523.9638]
+/Rect [401.5962 61.5153 470.2682 73.5749]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1376 0 obj <<
+1380 0 obj <<
+/D [1378 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+466 0 obj <<
+/D [1378 0 R /XYZ 56.6929 422.2248 null]
+>> endobj
+1382 0 obj <<
+/D [1378 0 R /XYZ 56.6929 395.9843 null]
+>> endobj
+470 0 obj <<
+/D [1378 0 R /XYZ 56.6929 272.4748 null]
+>> endobj
+1383 0 obj <<
+/D [1378 0 R /XYZ 56.6929 246.6526 null]
+>> endobj
+1377 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R /F21 662 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1393 0 obj <<
+/Length 3373      
+/Filter /FlateDecode
+>>
+stream
+xÚ­[ÝsÛ6÷_¡éËÉ3J|ÓÖé¹sMzŽ;w7mh‰²YS¤JRqÝ¿þX"HŠL§™ŒG ðö‹ÅbÐUÿèJÅ$â©XÉT8¢ñj{¸ŠVÐöݵ˜mú¨¯ï¯¾zËå*%iÂ’Õý¾7–"‘Rtu¿ûyýÍ?ßüxsw½aq´NÈõ&N¢õ×·ï¾Åš¾yÿîííw?ݽ¹–b}ûþVßݼ½¹»y÷ÍÍõ†ª˜BfG¸Ðáíí¿n°ôÝÝ›~xswýëý÷W7÷^–¾¼4âZ߯~þ5Zí@ìï¯"ÂS¯^à#"4MÙêp%bNbÁ¹«)¯>\ýÛØk5]§ô'bEb&’Õ&fDÅ ­I-G$ŠAk)(I„J½–Ò²Ci-ge[oªº+ö¯C‰)„¥‚®úÃŽˆ{ÔuÞ£NyJ˜ŒäßWå+¨¥ëCžUEõ¸?•ø]ì5?cRºŠLç3ÛZŠ±L-¬hqÄlÛs,ïëÝ“kþ³®r°ñõý“…µy‡…zo¹Ì¶OE•·®sfÛ_ŠÒòÝ\SµÎ·¹'•!ƒ<í3˜ÄDHÅ,‡ß¾û A0ß4"2‚õB)H3ÓúîýýíÛÿMˆÉÅ'vCÞ¶Ùc®%°òéÊÇ#eäÃ:¬ÑÂìlÍ鈿ZLÍ´4ØÝ"Ê¢íò–«ì`kÛ¼ù˜7–À/QÕÐÁSΪÁ Ǧ8dÍ+Ê긷²â¢?d@¦‘(ôÌÊCp'TËS‹¥¬zÅÂí¶b·ÃyhÛ¼Å~í1ß¿D3Ræ¥èž&LŒ%Œ°8QV«ƒõ1˜6i±ÚÃ(¹~cÙ«›K‡Ì²÷x¹¦k`Õjˆ)xÈ`î
“F»9XÞ»"!\²ø“¸ÂYâ¸íé)tµ›Ôjgkpâ”[ih5hgA'°;Ã(4TxKPcKPë]¾ÏN¥ƒî±â„„Øí>Å,HJ‰àkz<;À±øøFo…¶;=`I›Y«Ý¬;€Jϵþp£v®5?»W,êÕBF;ˆuÓI‰Ré‚/ï£.ûrÒrnŸòíóF¯ÎväË'‰Jˆ{ÔõÀ—˜í§ò÷èj¸‘cWÔzÊ­štÝ©5O+¬Æk}]Sl;Û‚‹<I²ܵ1 =-9,‹ÉŒq¦}­ºì¬4¤ûåM—–ò®>`Y Ëj-C•÷?’	1åÈ“µ^ ¥é@ö«Ú6hwm
+V‚c]µ×sÿ;¬Ù›ªú€_("ª¼{©›g•(41]}^ðñ1k
+ÏÀv[›‘v`¹v¬ÚH…+¤±Ì×cnMø-ô/­$!¥Î!XÙ'öFRp‹fVÆÀô‡cbç–D€‹³cì³¢œ DaWLiÏ^fOŠ»½¯-3Øn'˜H®C¬ÏÆùKÖTS„8a‚9¿´ôaD$–~5³ôê¼ôŒÖ=S{J6OÙ£&H‡1'Tª$¤ý!ÏGJm·MaÃõ9Vl*IÄ„ÛhûwÙXŒnÃõÛ’ÁJT $66+,ÜõÄõøqÇ㢸۳`ú\AB‡,qØË$Mù¼Þ=j‘ñh³VCFŒÍ[YuÙÊ<ꧭõå—0«©R-ŽàID,uÆâ<~Aèñ¸Ÿlq"Jˆ‚E<¯}Z`d<Ú¼ÅÅ€JøBHÓGÍXœCgª¨ºü±)ºñFCÐ<Ë€GMpš„5œ©…Ïir C›£ZÑ36Ç%˜d³9‡_z<î_°9A&å¼ú=j‘ñhó6Ç"ÂÄmó6×CÍØœC§ª-Jié„[à,yš Z%‚¥iÈÀß³¸4°¸žÚ:tOÓô²½1Ÿb¡¤söæð2Çýô]5Õ=ؼîh‰áX³Æ&4Z%ñ¼±õQ—Í£LLš7ú»iëlÓuåØÁE0KTÍ3àQ„æ%9
Yø<æ6!ÈÐàá‚Ïø7kA¥¨³þÍâ„ûì-Ÿ¬Ä¼ö=j‰‘Ñhó&—D /™.˜\5cr¥)žŽ»¬Ë7èžÛç‘Í%`%4YàÀ£&XlNFD¦rÀÃçÙT§$Wp0K¤¸lu:Ý'ûì-XÃ/ˆ=÷ÓwU8¥q’Îëߣ6ou<""“™·ºjÆêJS„™Ê²6ŸPø$8dÍRö¨	Òµ±”¨„²öo5ùKá’L<5é¬ÂôQtæÛk¬}°(›Á6_¨!mW7˜Žñ‹È¥¨¡]h²Â‘Ëðè>ç.ûº,ë—`„‰(…2	о>‡S§ô(r‹ä9}±™# Â$fäô/£ÍV˜ÛgjÙÆt"KFGxy*º¼=fÛ|³ËËâPØ®rí¨è´)lðVbhЉ´Æ3àe—W]±±·–ï@N“²×Y›TZg…óD™j˜È/1…l²ƒºÎ\	èB{zhóßO@¿=—‡òãÇ1kÍ›†ðx:ÀŽzžÛü‡é9j]Ð@ës’æ7ß—Ìæ‘ýEÁÖzËzè5Ï”}ÂÏ•:C&ljV#í¥»àÃ¥»ÀŸöviF8\&ë‹æ¡ûbú†M)Ãö¥»ËY9ýÇ5]·X®2{í¦)V›C~¨›WüD-ì6e¼ÃOÇ©•Ì\ÉI›\fÁ"5°:wtêÍ(5‡÷$4£.{¶J
+&tR[ïíÕëYyÂ,?›Šn8Ö­­sl*öX›ív…vðY‰õ}‡"Ö»¦°·eÐô¤3–¦ú!Ï+¬ƒHýÓÆBÛIµÖa	{Û¦ï­MÖ˜®?Ô‡|*Üf‡cé,Ä=Ëž;£Û–§3A¼i
+«Ð¾êátÞ² ì®Rª|bH'@ߦ^ƒLëŇÃñO2µµê£.ï<eq%ëÇCþ}‡›êñM¥¢Ò]gšøin³“½Åg˺~6ƒxŒç!ht—· Ÿ”ªïFç{s…Î$,šæÕn˜¤vqËh$œnDy×ù.U•YÕ¾`à£#M™èCH9­
+æ§\’É<&´`ÝùKÝúTZú™>Yž°¦ª›ƒŽçt•S‡‘­Æ:ç˜d$RÉàAPùîâÐÞz5pHÄwŽX©ß!ÒÌ»®Ü½bk™5¹N´.HòXÜ®1	8Þþ÷íÁ"Èñoñ#şⱪíÃ%¬@J"ÿlKWúѶ`HR©õiÛ
; üºÊ,¦s][	ç¤Ó
æ8¨	yeÍ>aLL<”Œ‘$Niÿa^]¶6PÀoU¹r2Ó©+Œ}MvaÝ¡$—ß÷Ä„³…É3fæmb‚%ÓŽ«ÈѤ~`ÎfÉ{̈~ø°/&Gø%ƒ~ǺjWoM
+ÅEÙuïPëŽþç×úÊ>æºõÆ·»MÉ¥§÷<&ú½ü„xðg
áo?Ë?ÿŸ!	WžúÓg`dJkJÆCÎc®H¬˜œ`ýÿÓ¶Qendstream
+endobj
+1392 0 obj <<
+/Type /Page
+/Contents 1393 0 R
+/Resources 1391 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1376 0 R
+/Annots [ 1395 0 R 1396 0 R 1397 0 R 1398 0 R 1399 0 R 1400 0 R 1401 0 R 1402 0 R ]
+>> endobj
+1395 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [286.0435 606.2351 354.7155 618.2947]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1396 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [339.144 576.2965 407.816 588.3561]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1397 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [286.0435 346.6843 354.7155 358.744]
+/Rect [336.952 546.3579 405.624 558.4176]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1377 0 obj <<
+1398 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [339.144 315.5214 407.816 327.581]
+/Rect [322.5463 516.4194 391.2183 528.479]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1378 0 obj <<
+1399 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [336.952 284.3584 405.624 296.4181]
+/Rect [331.4327 486.4808 400.1047 498.5405]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1379 0 obj <<
+1400 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [322.5463 253.1955 391.2183 265.2551]
+/Rect [361.2812 456.5423 429.9532 468.6019]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1380 0 obj <<
+1401 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [331.4327 222.0326 400.1047 234.0922]
+/Rect [259.4835 300.9225 328.1555 312.9821]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1381 0 obj <<
+1402 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [361.2812 190.8696 429.9532 202.9292]
+/Rect [172.152 241.2048 267.6829 253.0054]
 /Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
->> endobj
-1368 0 obj <<
-/D [1366 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-466 0 obj <<
-/D [1366 0 R /XYZ 85.0394 726.6924 null]
+/A << /S /GoTo /D (root_delegation_only) >>
 >> endobj
-1369 0 obj <<
-/D [1366 0 R /XYZ 85.0394 700.1172 null]
+1394 0 obj <<
+/D [1392 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1365 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R >>
+1391 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1385 0 obj <<
-/Length 2958      
+1405 0 obj <<
+/Length 2776      
 /Filter /FlateDecode
 >>
 stream
-xÚµ[ÛrÜ6}×WÌÛŽª2X\	àÑqd¯R;++µ[çšáHŒ)rv.R”¯ßÆuxí].×€À!º8ÝY`øG"C™¦z!5G±X?^àÅ=´½½ ³
- UõýíÅßß0¹ÐHg4[Ün[})„•"‹ÛͯËQt	=àåë÷ïÞ\¿ýåæÕ¥äËÛë÷ï.WTàå›ë^¹ÒÛ›W?ýôêærE” Ë×ÿxõóíÕkÊ|ß_¿ûÁÕh÷3ÑéÍÕ›«›«w¯¯.»ýñâê6ÚÒ¶—`fùïů¿áÅÌþñ#¦•X<ÃFDkºx¼à‚!Á5ÕŇ‹Å[­öÕ±ñãB!Ay#ÉÔL2A’IŽ‘ÄRÆQ¦dl”ÊŒò¦Ì«Ó®o¬ÊÈ¢Ýá@lˆe-±š !@‘ŽØEáÆûøà›â°Þ—»cÙÔ®¢Ù­z6h‰0å
-è*ß“É(bŒ©ƒ•uß>
-Â`ìÛª»ÆýýÂnZ¦FüŒ­Ã~±ë³Y†Ö$Cd p_ªÒcQsŠz3Š ©=s$ÖHÑ9vA	ryž¢*îscúª©«—¾pPeœ¦¥GÐP|Û^t”QÖ•k¹¥³åGŒY~oÊbi5±µùnW•ÅÁ=÷ûPÖGÌë«:Ow®ôgS(œËåõÖ·=X";ۄЈp=ÇÄ7d+‘H3HýÝåŠai£öª3Œx'빬*oDuðšß¦ë¼¬Ö
-(BÒàz¶×ãþ’¨e‘‹ãa~p¿åÖÿý¯¯÷›RpÐîl:÷}Ùyÿ5ÊMò+Ë2¤5#i‚µQÓ‹(cÖ¶Ù?çûM_®fˆR!ÒrhDn'~)Dq¦ºrßÛ`L,‹¼.ëûí©2ÏÜŽ§©·³f
-nÖLÓƒsS•»§¼™—M±?8LUŽvÉâ–¾Ãc
IÏ–àXƒ@î/‰=A˜ôÚ¬óӡ𲢊UÓ|‚8êôn\ã6/+G(
-œ0Bº„Ê·ÇbS/ûS&ž¬PÙ7Î4:—‚ÆûâxŒ¯Ô«ÌëÃ3t	Ëñw¦"[>?”Õø”)żuàÝt8Ž‚]ZÃ(<7§ÊËÏ«ªyö:¹šºÙ?æ•«
-Ãamk\]ð.*)lQ2ƒxï*‹Í4û	
-±òŸA	î{P‹úfpûÃÊŒ
ý‚#h(¹›ÀL®ý[¢9Ø(B¤˜ãæ©ØïËMák|Á°Ù•š­ÞWÍg¨ëR™0¦]\…ÆÒ¿hã@êÆWvź4st(k‡ÈÝ£’Q¦tAjH#&4’4£ž­PÒßMÀH1šÅøl‰kDö¬ËƒÚ‡Ì–eŽæ­Àºqú9Toôgls®Òn‹#göFvŸ"µíîÁ
Àͧ)2m6H3ñ¸šædDÙ­Ö[«Íê.?ƒ¨œ!&˜NK é^b‚ \Ñ®ø_jjW6‹äɲ”hnbjÜ!À””k0ô5–SÛ÷`GÜ´Öùcáª“ZMPØC´Êý¶Î`«æÞµ|ÄÿÞœöu^A‘„JL+ß«uS¹yåÚ+»ÛÀÚì¨E€—LÈ.µ!2²¼þÏ›äŠþP“¹C
T”÷Ç,®Â±'Œq•±«5p6jyZû/8ãM•u£sYzó.˜fî^¼€Ý®¨=óáñ#¥Ü¹Ìëy
-9¥(:ø
-~åk;«Íïu5»q²bœÏ4=ßñƸSÅ”Ë9K¦}†ÀVÎúL•ð™€êøÌñq·òÃÙè0Š‹%"jD‹nLÏ`œõÔˆ¾ãÂ"õ¦YŸ‹:î›Ö­ô¿çõf2‚—בˆ›)¨ži®`3¯Ot5=ÒeYä‰Û?í‘Ál’rhDng·È‘’šwå¾òÛ
œHQXò¶ù©:ºZ¯ØßîÑ‘À“°–ÏÊnBì¯_m7Em#Xø“´tzµ+Žy=´®OÉx.>üÀ¾XjÝuÀ)F0&cý ×/` …½ƒñÜÔ,DÔŒÃÞÒ$„Ã*ã|f'ØF%HP.çt4©‹þ™†›¬ˆJ‹
 ±mK•Ù—o‹ý:t;+ߟeØmeYâJ$)´Úª§nð~ÆÖa¿_pƒÇÇJ§Ç<¢æô–¤U⟹Âk£¦éQçZmŠ*ÞàŠ„¦*-=¢FÄwÓ	ÉIWþ×YYûVôD›€ªq6Í6ð"%ïšb[ÀϘ<ìw’mb¸Åp€=hrð#jF“aoiº™Ã 3É°6*A·€2w§»OÅ€hæ8»'¥z̈ÐÞñQp8¼w„^›±–<$§ ¤¾é›Œ€š˜÷‚òsî+ËúhSæIø|>Tût²¿áâÛ*“ï5eŸv„·Œ¹¶*¾þTìíÇ:?‹´yK@Êû:_ùD
Gš³þEï霦.õm~x÷áÃÕkW6}X©ÓÃCŸÝ3µƒ/®t¾[ &ÇoÂ{.eÙ<º§MyødÒ88椡Rû¶&pwÔ¸}9+“Ÿ•6†ánæ;x‚ß»éæ»ÛAÂM×41†cäÌbÜ%ØëA!´:aÚÇr=¼—£æÀNdRz
Åw‚%…=G[üõväm¾‹Pÿ×÷á‡ý“½é…òù»ƒOE±ŸGx{sßTÖ[s™ê¹ŽØöK†òpþ”Á
-Ræ–wýàj×y¿e°¿›Óã®Ø8¶ÃÁCaLz¯­LÿÈE±4w—aqž˜V–½¿hÄE|cS`ÝÏaG’Å¡9_ÉM2ŽåÏDÌ6jšseÍ*ïWOyUnÊãËʤýÓ0ÅmÒ+œ«’jDÔˆý$‡šŽ_gC8iÍ0C™æ‰CJBLl[’LÀxüŒéÃ~?ÅæೂÍP!€fôô•\®	xVsù—6*A¾€r>´ŽŠ‡æ´_ﮨ¹d’3JDÔˆݸ§‘=-¾Îq–žéO$ˆ‡•9“Ž¹)âüŒáÃ~?ûÜË$7÷}"=5§È ·$õ`ÃkÔLú¹š&^MÌÕê)P)ĉH+AC-:Äãβ£Å7㷥爖 ƒ=e¤mnŠyž6|Ðëçç[0ü0Éá ´ƒ¾’¤ËbtîkÈI|oå0öÆ°:®>'Ú1ˆO„ˆ”
-3СK8Ž¸96·”ø:kl”>ã@4Ö‰kðL¸jY›$œG'íî÷ùtã0k°'N}Ä$Uè÷4εŒÈ|Å?"
þûƒÙ_þcó_RÀ)E'ò	b™‚N¼RFqɇ^‚aógå¡êÿXÔ€9endstream
+xÚµ[ßsÛ6~÷_¡·“g"~’Àcš:9w®îã{júÀHtÌF–|’l×ýë» ˆ È…2u&“1E~Z|»ûX›QøÇfª …áfVIej¶¼?£³/ðìÃë0ZôQ?Üœýó½(g†˜‚³›Ûž-M¨Ölv³úu^NÎÁ¿ûåêýå‡ÿ]¿=/åüæò—«óWtþþòßîêÃõÛŸ~{}¾`Z±ù»½ýÏÍŵ{Tt6~¸¼úÑÝ1îÏ„Ñë‹÷×Wï.λùéìâ&øÒ÷—QaùÿÙ¯¿ÑÙ
+ÜþéŒa´š=ÃJ˜1|v&• J
+áï¬Ï>žý7ì=m¿:?©4Q\IÍ1eFJÆTJJ4å1›ž»’@L$DÈbÈÃD!á‚+"z4Ôª¯zx¨7«z>FÁ‡–/<ð°n–Õçuí>Cœõ~¢™,IQHÏá¾ÚêÝÁ‰áï`Õf5fË¡JÏt¿®žê1)…ð
Ú˜îIÒ:•¶“¬Ä¥ÜGMK9 œŸ,:Õ,öÍŸõ‚P•!àA#ú3OÄ%bð±öi¹ë.Võ~¹kÍvãnloG‚lJB¹Ô!_©ƒæKM´‚!Ô}¡Ù]ÐWùêî¾ÌÜÅuÏë€Ï¸Úun/Úa›€J8™‚”…Txü*Ç$±Öv·IÑ%ôàBeD×C!¢ó(Ÿ¬Ã®Úìo¡‹1=_šûz‘f„)J”Æyt˜‘ô”"ª`"æñzÒ›òf8ªD”%"Áf=Åb—1	z|ÆýÔî”Ë!%É¢ãx*C$µ†+PDÆ3
+ì¡zÔhΚÕzT0+hFÎ$ F¨Ä*ä¤46
}.ßI…=†*„²ˆj>­B%IÁx9©Ðã3î§v¿A…Œpeš‡€ÊI­á*¤0SSe2*ì¡zÔôȱ}<¤!LÌ0œJ@p‰dX0˜j¬¨ûd¾ç`ع4äA¡0d…™b	y4v¢ÇgÚ=]ˆ¢$†šŒ(*C$µ†
+Q•P'sš©û¨i!Ôôà1*DA„4*5Â%5‚Èü=!t<¢1†pLË
+‚Æ"§ÑYÙÁ3Þ'V¿A„êèÀh*Ã#µ†‹PÂZ†òŒ{(D„e[ÜlÍíK²¨–DZãÍzÐH³}Oµ]—A·š}¹É³•WuΔ¶8/IÉa¥ß§Žˆ+à3¾¦v'W	%#‰¤Úà1¨‘Ä./&\’pyõPˆ¼<꘡Ū^W‰ÈãD®ñÖj¤ùhXc%¾Äâö_g~z1hÚ¨†ÓjƒžÂÊRFŽbjóøŒË©ÝIµ©´ÜT°&€z
~@e˜¤ÖP¹I
9-d¦¶ë£¦åP¶Å‡ÇÏ_ëDh†‚ã­v˜‘FKI%…Œ½´±.¥ß¸…+ýÆﶻapgë×ÏUw³ÙÚ=4ûIÍo·;w{ÿP/AnÍæ‹û\¹?àÛºYºk»oå¾eÝmo…¯?Õ»Æî.«c“ ñ½o¾lªE·SóŽ:Þ)<<¶óvmrËÐýýñêãÇ‹wîÚÚh9sÇ£ƒ>ßÕºÚ‹»ªœ1÷a½­Vþ{·íƒí½û´jö_í>"e>†pÓt϶¾è„îÂ:xûr$SI[Çhì‘ï	¶ùngrÓ]Àw·Gwûƒ„K×´~a˜×En»BôëQ~?r±?@æö‡f¹OFLNËJœ@@0ˆFLVŠ˜Áe7ÂØד=)¸ðƒá‹‹óÐÔÔ‚{̛Ͳ‹§)æûzYs×ÏÍzí®¾ÖõC÷Ü»\uš
èùÞ+n8yÃEקàÊ«mHƒøšå»»¬ºo|îÚ^=Þ?Ô+§yX‚hJÙ@óÛcöÓ™‚#u(%Ž¹Y¸=ø±éÀ©Â7Vµºc5·H-„&ÈnzCZhE‡’Õ]5­»€jÝj¾,žªu³j/;,ížÒ“»á"%è
+¥P#<†Û2îD<^§,œô&Ý’áÂHdKF]‚Júž [2>ãzj÷ôy[B§U"#ÊðHl¡“¶ÝHRd6¦û(D|Õö¿þ‚q¿}Ü-Ó.¡¸+3$j„E<ð¢Ô€ÅëTŠ¾E(¬ý"<ªíÚ˜EîbÂóøŒã©Ý“W¿–©šÃ¨†f  rDk¸ô¸€„éÌ|ÛG!Òó¨‰t-žŠô8NÉT†G@‰Ô'¡D6eL仩¯sg¸&—„3P@iÀ‹<ÆèñßS»§o¿P(¹)Wx*C$µ†
+NÊ2£¿hZ~Ôžc¯‹S?Ãc
+e@)X|’H»šîóxYñf¨>E5ÈQˆ=²fR÷FÅ×Áq×«ß =	ɃJK@á,[¸î
+¨Su™Ù{î£åy’¬±ÁÏm++œK@Ù|Ö1›ï*ÀñÐí>óÌîsŸè)ÛÏTçÚýÖ
hg" 2DRk¸#ܘ¸{(D‰e[|Ü׋SB+nc‡‘	¨6ñHÖ¾äÑy‰8ãTr$'	cº@Žä@40wFŽ£Gr>‚Ôîéb” &ðTxP†FbW"¥Pg•™×ú(D‰ÕÛåЃçZ÷ ‘Öãõô8cÔük‰Lk­àD3ä},‹bj7{ú.`{ÕŸñ9µ{úÒC•ÀcP"©5Tm¬0ÐEXf«ºšV[@%‰]tP¢aˆð ñ;€v{^‰˜ÁwÜø\[‚ÿŠaïRûÊ°Ž|Eßìð·S»§kN—0;‡? rDk¸æ RÕ²ÈT}}¢9jç›ÍbWßîêý]ûŠÈ{j?v»Ev/)ÖßL«&F
+ZHÜ…€ñ!®•
+¢le9ÑÊ–™N¶ö"’­½‘JLÚ·o
+¦#bˆÄ>C1µIÌ’™ÜÊSPq[3àùö¨“Ô®1Ú¾Œšy¡ B4æQm÷þÃî,nwÛûŪ¹µ ª7Ë:=ÐPœÐVC(€á/.`dRªˆ	µz²ÛéE2Ö‹}2:ÌÙ¥Ôqw8çVº¾€Å&öv`d‘çèú¢ÃgbÚi½zÁ¾¥¡zÆ“P"©5§ÇE¡äüUôj{‰©.3ãG00·g¨×ãs›RŸb¡°â›þ©¬TúSƒÈÒi?5hX¡ª_Þm›¥?h<ŒÂw°iï>UÍúø‹‰ê0˜ž»S_{˜Y?ÕkQd“¯O*XeÞç8bW'Æzðµ~(ï@JÛÝËX}¬J‰µë!I»qm̉RPªô~5YBXÃr°d©Œí›4PMé£uq‡F½Úœ¨OƦ„}w‰vÀ †–ÆçŒpjCì¯ÀFZƒÿ]ÇüÛ?6;þOBѤõÔz¢ÔDj0Ò‘²ÄË"í
”p½9¥þ}¬³endstream
 endobj
-1384 0 obj <<
+1404 0 obj <<
 /Type /Page
-/Contents 1385 0 R
-/Resources 1383 0 R
+/Contents 1405 0 R
+/Resources 1403 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
-/Annots [ 1387 0 R 1388 0 R 1389 0 R 1390 0 R 1391 0 R 1392 0 R 1393 0 R 1394 0 R 1395 0 R 1396 0 R 1397 0 R ]
+/Parent 1376 0 R
+/Annots [ 1407 0 R 1408 0 R 1409 0 R 1410 0 R 1411 0 R 1412 0 R 1413 0 R 1414 0 R 1415 0 R 1416 0 R 1417 0 R 1418 0 R 1419 0 R 1420 0 R 1421 0 R 1422 0 R 1423 0 R 1424 0 R ]
 >> endobj
-1387 0 obj <<
+1407 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [231.137 736.902 299.809 748.9617]
+/Rect [324.1075 694.2561 397.7608 706.3157]
 /Subtype /Link
-/A << /S /GoTo /D (boolean_options) >>
+/A << /S /GoTo /D (server_resource_limits) >>
 >> endobj
-1388 0 obj <<
+1408 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [359.1555 437.0578 427.8275 449.1174]
+/Rect [359.1555 663.4708 427.8275 675.5304]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1389 0 obj <<
+1409 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [353.6164 406.178 422.2884 418.2377]
+/Rect [353.6164 632.6855 422.2884 644.7452]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1390 0 obj <<
+1410 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [370.2338 375.2983 438.9058 387.358]
+/Rect [370.2338 601.9003 438.9058 613.9599]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1391 0 obj <<
+1411 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [364.6948 344.4186 433.3668 356.4782]
+/Rect [364.6948 571.115 433.3668 583.1746]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1392 0 obj <<
+1412 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [226.7331 313.5389 295.4051 325.5985]
+/Rect [226.7331 540.3297 295.4051 552.3894]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1393 0 obj <<
+1413 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [283.1811 282.6591 356.8344 294.7188]
+/Rect [283.1811 509.5445 356.8344 521.6041]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1394 0 obj <<
+1414 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [352.879 154.1545 426.5323 166.2141]
+/Rect [352.879 381.3231 426.5323 393.3828]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1395 0 obj <<
+1415 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [307.1508 123.2747 375.8228 135.3344]
+/Rect [307.1508 350.5379 375.8228 362.5975]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1396 0 obj <<
+1416 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [334.8268 92.395 403.4988 104.4547]
+/Rect [334.8268 319.7526 403.4988 331.8122]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1397 0 obj <<
+1417 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [337.0185 61.5153 405.6905 73.5749]
+/Rect [337.0185 288.9673 405.6905 301.027]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1386 0 obj <<
-/D [1384 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-1383 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1400 0 obj <<
-/Length 3140      
-/Filter /FlateDecode
->>
-stream
-xÚµZÝ“Û¶¿¿Bº€Ú''9»N;=_¦ÓIò@KÔk‰¼ˆÔ•éß],ñKäuâNÆ!¸X,v¿ýObÁá?±0šqiÕ"±Ši.ôb½¿â‹{˜{{%<ϪaZµ¹¾¹»úÓ™,,³q/î¶-Y†qcÄânóóòÛ¿¾þñîæözi¾ŒÙõJÇ|ùÍ»÷ßÅÒãÛïß¼{ûÓíëëD-ïÞ}xOäÛ›77·7�¹^	£¬¼„Þ¼ûû
ÞÞ¾þá‡×·×¿Þ}usliÛ+¸DC~»úùW¾Ø€Ùß_q&­Ñ‹gxáLX-öWJK¦•”
ewõñêA`kÖ-óŸÒ†éHÅ‹•Ž˜áѸ“9㜶J”`±µg'GbÌÉ
:9ÝÕ«úÕ6;\³\Uåñ°ÎVOqß~apY¼ho2P¥aQE¶T&fq’È®.³ŒN ~ðƒMV­ùc—Ê-ªÕ3Ì&ŒGÊ€óõ±–	zÐÒ¼è
þ§µ{hòp¿ ÁmËþÀ?〡\rÀúl*"VÄ,髤bÎ'Ó¸fJCEØüb‰ÌÏà°Å5Æw/V‡l{Ȫ‡Uï³Wä„}úe”ì¸ëÃiÈÛ‡Á
-èÈL›¸Flè·LVª¨k„ƒ­°¶8èÀ	#…¶ÔÜDŦ
-iÃ?£âPnb¨Œ‡˜Ð}àjÂt"ä´³׌&Ci“Ó6b‘†`cm®Ë\.¼¿l©ëÙÊýj“oñ:¡¬XgÕ°±ãLE<™V'pèÓ½ch¦àÆÔÑçëôu³Võo	3I4qÉ:PÓ±{ò’áùg<0”{)ã‰A„À½SÄq4}kF‘¡´i4Bc"“™»n‹i‹ž	·ûœà¨`}y85u6âjrïÀ4ܼßÒY®½û×)¯ú„
E2ÑÑEˆˆ¨mædCçÙ§
H½³a}À+'t]SNL3:ôeM#L¢ÆJÌ@¬Å5±†ËÕÔã®ÎWû´ªá¶7À˜d±1fz÷À5²}eÊ°8ᢻÿ×Éo}+ú(PR¸¸Œ2m5¬h0…2Ï>cð@ê‹“™4Š%îb“Ž\sz¤MCGLÃÚ¨µ¸& Öp¹CrÇóçÑ.[mËÃ>­ˆƒ|GpÛT"phѽ7⸎ºj|ÄvÁ˜žã<ÑÀÓPh­ì˜;<Ï>c÷@êEà
š:AC¨ç pÍ(2”×s.\ŠÓBA©’?*HQÏH1­(ç|ùÝ©H÷ùšløéq“Öþ,wù:meøb¬ÊIôŸãUì>Çã:>>–‡ºÂ7½¬ŸK"§;8Þ"­ó§Œû¬~(7½@Üóþu~-–Å=Ö»<+jÏEƒÁ!¿¨=­¤³¢†ˆ›`¼]U›ÔAËÐ÷~­É‘¿—Es¯Y—bñþèÚ¼lCÔO§3Ò‡>óógè]ù¼¢Ý/|{áªrZlÆ$ZØSÍÇD'jõˆg3Zû5tü²ùzXºøóæÕ#bö)Û®…„8M-ÝÚ‚/¸_Eô
änÜDË©_h kEš/ëë]z¬àø$O–ÏåásECw¤8¨Ò}3›žhzsxÆËG²â)/~æ);T`¤Cá!Éhø®¦§Ã•g»4lÐåü` N8~EhC"ä4À×>¯ªñHð<¶¢&-Nmw¯K÷Ü„Øe*œÅ8Ê‹^E ²€Pw*fêT³6\/^¸ÙÞ¹DR.óŠžEöì	¨˜Œš Š¥•ˆ¿lOöza>E¶ÏçEæ¹!ªjÇSîHp	'HSÏiM£s¼¢|/’N2ç¢9!qFa¶Áäò5:P/«…iå½®àDÌò¸sRaÚ
-TˆÍ6.PbP’OìÞ,]?tdxr§u ‰]nÃÍo²"Ï<íŒOØ6\pÎÝeÁ‡#é	ƒŒ&ôµü”Ñ;ùlã‰'"’ph¢u@@ÍAÅ:¯AKð¤óå»-±ãœFÃÄAb~;fUM“ X•ÞûÙÜ+Yå÷tò0þ…k^?PMïÛ•W>KåuëÝqCÞã-OCðÐãîã»·>ªüpÿc1ˆôW½(ó8uã3L;õ½øuêCôShqj<Ô׉SÊž·kqì^Z€CBL'—*ŠŒÇ¡GzAd'J4%åw:~.‰ð¡ÛU
-p±;yŸ¥E^Üo;z'¬âÝ;ÊFØÈX,ÿùŸ"1PÓ\%é¥ÐÓðï¿\¿Ü2+uÃ]ÕÀ¼‡ÃClÅoIS*˜@[­&@µ8Rz=÷Ô·p@Ì”™ôJf›K')hÜÅ‹¡ˆãqÝ)Ä•s¡„N?ÁïŒí×2}ž$ê€6,â¡â¾-6±#z%Qƒ‡D.³/)â¼":ECt ó–h)½údð—v6Á%5SëŒØÒÍÆÛUCî÷(ÊÚã)’PØlÔÅ-ÚeO)ºc´Hæ>u4χò¹“?Z™CÙ•ªüÜÍïÊòsõgr™´½Þ×2cú~…çzC#í*
ÿCÈ-'QJÂÑ9áà¦óúô˜ßhô3=pª¢á¯Úð–*7T¥ 4϶Åñ¹2aˆû8•)Æ–*ÊwÙ=³6ËÅÚ/MéqÎì°ô!õëªãz
$(m_Z¯š¬–vTq‰§I¬¨ÔÃ&ð@h^…ý>Ûä€I·±d
-•“&J-Ù²¡1%6%=·Çƒ¯°¢Õ ï¹ÚáØB¨(v-PÏ~„J ¦e%Ÿ1ñ¹‘¯˜¶‰ŠŽ=þ»[én!Is‘1ídWv®¹ÀäE•´…„ù$Ì›F‘]ibºnŠ`J‡sÏPSG¤[’¼*þvÒ?£P*ý:÷÷ FÃv)õXvUµSÇšß³0¯ÄÅNxàBÛö€iíå]–ÓÙaG@Iéõ9ßmÖièÚ½ï14_¾Ç;wzEëjJ5¨F÷T:›l{S¾}iíßi_FÐó9sw"‹?(ÙÐ+ª…óºKÙЪá¸Õª!¾î^»¹”w»ù²/뇴¸÷K]´ãPœ ).襧<×´GØÒ‹­ÒpyvŠfžªó%0IÕÎ’øæ.uŠŸ§;bU[¬_^ù sXC—K¥UOÜÌnäxÌVtós¢ŽÀk×dx{•ó舶'ÍIDBž›Ýù«‘`Üèæú4C•4íÑ9@r7 ËO‰Þƒ:L `Ö‘ ¾IøŠSÕñÓ¿³µ'º–žß½ÿH³}QØ3<¦EåzN*ä
-,‘‘킺rWè&.tÒ.Ë.wDN]@Ö’HîûôcÃê> endobj
-1402 0 obj <<
+1418 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [393.041 737.8938 461.713 749.9535]
+/Rect [364.6945 258.1821 433.3665 270.2417]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1403 0 obj <<
+1419 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [402.9837 708.0059 471.6557 720.0656]
+/Rect [374.6372 227.3968 443.3092 239.4564]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1404 0 obj <<
+1420 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [320.374 678.118 389.046 690.1776]
+/Rect [292.0276 196.6115 360.6996 208.6712]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1405 0 obj <<
+1421 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [348.05 648.2301 416.722 660.2897]
+/Rect [319.7036 165.8263 388.3756 177.8859]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1406 0 obj <<
+1422 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [488.512 618.3422 561.5676 630.4018]
+/Rect [460.1655 135.041 533.2211 147.1006]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1407 0 obj <<
+1423 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [390.4905 588.4542 459.1625 600.5139]
+/Rect [368.9978 104.2557 438.8121 116.3154]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1408 0 obj <<
+1424 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [321.49 558.5663 382.69 570.626]
+/Rect [293.1435 61.5153 354.3435 73.5749]
 /Subtype /Link
 /A << /S /GoTo /D (options) >>
 >> endobj
-1409 0 obj <<
+1406 0 obj <<
+/D [1404 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1403 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F48 890 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1427 0 obj <<
+/Length 3405      
+/Filter /FlateDecode
+>>
+stream
+xÚÅZÝsã¶÷_¡G¹c¡@ûtI|×K›Kês¦ÓIò@K´ÍžD*"eŸ3ý㻋ÀQ–“óLçÆìâ·_€ÄŒÃ?13šqiÕ,³Ši.ôl¹9ã³;è{w&ü˜E´èúêúìÏoe6³Ì¦I:»¾íÑ2Œ#f׫Ÿæ_ÿíÍ×—Wç‹DóyÊÎ:åó¯Þø†Z,_ÿáíûw?^½9ÏÔüúý÷¨ùêòíåÕ凯/ÏÂhóOáÈ„·ïÿqIµwWo¾ûîÍÕù/×ßž]^G^úü
+.‘‘_Ï~ú…ÏVÀö·gœIkôì>8Ö&³Í™Ò’i%ehYŸ}<ûg$ØëuS§ä§´a:Qél¡fx2-dθ¡-2%Xjm'äDL	9ŒB!oöë¶\lò¦-vcŽ…’,5ÆÌútV£&–—½å…2,͸®ÿ±(Hêí½¯¬Šf¹+·mYWÔPßâÆFÌØŒñDYØ£¥SÁ„âÂ.«1£Rì`FŸêÛÝͨrÕã8?ÁðUâwÙq† )û1Še<ÑÏ>Ž:µj¸v€o¢Lf„HO@­7ꨅQîÜñüÌy².·õn“·ˆKK‰4Ïo"ŽšØÅq) Žëd¸/Cœ	ˆ›ff´#Ïô3ÀÓ3VØ}x~ø	¾¨žoH%–i}êâ¨9¤‘7îB*ðB§’	á]î3QLçœÏ¿yªòM¹$~Ü®òÖŸàõº\–E3q|¶
+V	å(zÿ¡Rç? höÛm½küÒóö±¦æ|
Ç[åmùPPæhïëUCWÞíòª-Ïżº£†åº,ªÖ"€AeWÞÝ·¾­¦…¶ÅQC«È|ì_M8l9C^@V¤‘—ßꪸ ,ë
+±x·ß3/VÔzóÔ!ýPæ‚R¯×õã‚VŸ²¡èT€r^­¦(ZØS~‘Zlñlž¦(j¦3™úѵÓ?ÏqÑl³Åúé\A¸Ó·i¬¶ ‹ŒY™dnúõ4‹–eR¿AÉd&¤¼\çûŽOòlþXï>5TuGŠ•&ß„Þü‰*¹je:ße½÷=Å®&ý‚K„$£êû–J‡+?ì$PQ5 ËÉÁ€žðT!màkS6MÔx$(÷=­É«§¾¸—µ+WÑUŽc¬•ÕÈ€"YDèéS1ÌÚ,y9LOìè\)çeCeU<úܘL‚’C‹¥áJÄ€Ÿ¶!~=1TŸªX€ä˪ð£A«Z7¦^áNºïó–j¾"}O’N,çbxBnÅ
+<‘ó7(@=o
+$¦•—º‚1óýÚQ…nÇ(´¢B”¸Ñbå%…m€ñ)"0¶È—÷¾¹„ÓÚQG@—[pGý«¢*ßÖaÇ7܆QpÎÃiQ†æ	ƒŒ&ô5¿)è›d¶òOÔHı²£ŽÞAk	[lËv	²s>KÆ0¢3£q	Ad~ÝMK°±&¿ó½¥ßdSÞÑÉCýg®y{O>½ã‹œRÙx+U¶A–ëýŠ¤Ç{’å¡âúãûw^«|4àþS:ˆí#-óxêgìvÛ÷ä—¹WÑ›â´x¨o §Æ±tå±–fÁî£8lHIÃÒì˜G’ñ4ÆH/ÐlIƒKùΈw® ^u‡\­Ÿ¨ySäUYÝÝî×ôMXÅÊÜp¤°‘©˜ÿ뾨H?EfÀ§9O22¡¬¥˜¼è—sf¥£›oàð[©Ç[üCÈ«Õ¨Þˆœ>;çžû‹Y¦}ÛæØÉ$
+wñbG(Òtzï¤ÈâʉPB¤Ÿ™d¨ =ÆPæYvÄ@n›ðèq_‚›Ù‰}eIÀC&çÅçqÞP;i4GíÀÁ·Ô–Ó§7í[œQS0µ,hX¾Zy¾Pú5ªºõxJ$86›ñD“ÖÅCŽâ˜t’¥7¡¼¯ö£gÉQ•«*»h~]ןš¿È¤ž–anŽë Á9_¤G;@ÕÿR¦å‰jd‘°ÖÙüBkÞ>m‹î‹j?Q]
U9…ãNàüp+—ä¤@3;ÖÒ´sL¨á^£cJ1¢*ÊuqGº¬Íüûjé§æTt†¦Þç~^³_.¡lY
—·Ëû`ÔòÁVœÝ	v7î0è-›)_Wn6ŪHºŒ%VÈ›%µÄËŠêd× RÕTÞîwÞqÀŒžÿDZ´àA¨$u´vr„²¦Ç%4>¢Ýs5ï0mPŠ	G3]’…<Æô=4;¿°v‘ôÅA>NTYŸHìÏb¿	¨ÙyhÌ—Áæt¸Ð÷.u‚
+Á±GÉoÅ''ã3ŠžÒσZ·Ã¾'õXvNuà§bߎ˜ßÄÑ@ø@„¶/Ó[Ë‹,§AÀŽ %§ÏÇr½Zæ1h÷²GÕ|þï$Ö>uº y-YÜÆðT‹ÜŽº|ôÒ[½LHúSáR";‡P}E5t¸-„œo¡TÊÆH
ë½H
ñ
vîÚõåT\ÿýòßT+>/ïóêÎOuÚŽK€o‚˜¸¢Ñ \ÒqIO¶¹Ïcîì6ZøàœIª¾•Ä/—Ó)ÞuȪ>Y?½ñ`Ïqå–PË›¹«‘àUd[QâçHíaÌ]ãýYN¢F È—atN"²‹1tßÆ[Á¸Ñ!û;=t
+ª*ÑQ§@y¨äçÔ>‚:t `Ö‰ °Ix‡]Íþæ?ÅÒ7ºˆÊo>|¤Þ1)¶yÕ¸“ü¸Nd2Š—A½ÐYß+;]\Ss¾Ý:'€Ckjr×ÓÛ0ÔIæ·M¹Œ„¼ñzR¢°9¦R•œ©æLšTˆ–Ûì]ÖÛÀt6'FÆÚœO\üºÏ×=3’©7¹»×òw.
áïA‚÷|Ú?àFXˆ+c
ø43BL0ýKÇL*ò5ØŠ©ØÇ&e3o‡+aÀ†o94èb‚ŒbÖˆ€i–L5µi	á©IN‘
+ky®¦Ô#c&áÙK)5Åúö(kê÷Pö¦¶#˜QRDBþVh5A1Q s“öH"›'YºÐ˜2…d¯Žésʺw¾~<6xãÀœ5Má ºsø²£EIŽO Aë^-R2ÈuÒSp=XÎÕIC5ÄLH>E߉~`,Bæ5t"^‹¢1ds*ÜŽS‘Ô&/ã³ÛÅð–ì@_€ aã*Q¯Š ÞÙ¼„¤f&Õúw3ŽBHX¨Y°á' „eö”{ãgR[a·Jd'D1}Ê”²,c 'ñʱ¦FÈaeÈaK/[H›ÅDpþÆBì14_”
AŒÐ³†ªo
¡Ç[C•„h9ñÐÇ‘úØ¡ß‘øè^N?ßAìRz‹7~än·Ïêq4öùË Ó¡Ñà;Òäw3Ž£¢ZÃOú?a ^L”~.È™²e …î@…M»Å:P¬9áb?6ùÅÆx Ø> à­ËØv¦H&ôŽƒå´)J-–½ ¬‡DNtlŽZ&G4® \;©yBÚÍKè-Ä•w•|Y…¤È*fòÃ7{§òÜzOê«Ý£ƒLC¤Ps	-”GL´âLk£_$…{&ÕªÌ0Ú4ñîúxO‹¢]‘ˆô0Ñ¡{°jó`56uÓRdÛîý¡o1]³{c¢±pØæÓõ_ܦ0å
	ÞJ£ñ3á±ñÀ–ÃÅ 7×X!²0š®Dú]þ$ŒìÑî:òŒ‡›©»£¨©zã›ö[hsšÂèÑûHê'ÆMü©Áó‰,jŸ$¦Ü‚x§CÕáœt :> endobj
+1429 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [317.0267 528.6784 385.6987 540.738]
+/Rect [317.0267 737.8938 385.6987 749.9535]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1410 0 obj <<
+1430 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [356.8967 498.7905 430.5501 510.8501]
+/Rect [356.8967 708.0059 430.5501 720.0656]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1401 0 obj <<
-/D [1399 0 R /XYZ 85.0394 794.5015 null]
+1428 0 obj <<
+/D [1426 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-470 0 obj <<
-/D [1399 0 R /XYZ 85.0394 484.6014 null]
+474 0 obj <<
+/D [1426 0 R /XYZ 85.0394 693.8168 null]
 >> endobj
-1051 0 obj <<
-/D [1399 0 R /XYZ 85.0394 459.8194 null]
+1056 0 obj <<
+/D [1426 0 R /XYZ 85.0394 669.0349 null]
 >> endobj
-1411 0 obj <<
-/D [1399 0 R /XYZ 85.0394 84.3175 null]
+1431 0 obj <<
+/D [1426 0 R /XYZ 85.0394 293.533 null]
 >> endobj
-1412 0 obj <<
-/D [1399 0 R /XYZ 85.0394 72.3624 null]
+1432 0 obj <<
+/D [1426 0 R /XYZ 85.0394 281.5778 null]
 >> endobj
-1398 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
+1425 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F53 967 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1415 0 obj <<
-/Length 3076      
+1435 0 obj <<
+/Length 2887      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZÝsãÆ
÷_¡Gºcm¸$—}»Üù’Ëd|­¬L§ùx ¤µÅ†"‘:Ÿû×X`)J–,_}™vežîô‰=¤OlyÙb?iI¬O$öúDúÞì]ÝØÎie¼ñyÜ¥¹€û,ãm“—ëœB€ØäúЭNXÝX£ÏZžÔO
ö[òþËûºñhs‹+² 	¡œÅ™÷ <ÛzãL¢vÙlÉz#>CdÐ*ZzžpÑ&Ib“	Æ ä“&f'˜=X@_œ…CŸÀÓXŒ!Á¡ïéÅØ=®½MË(8UÓvDÙ¶în[í;¸ùªªy`<½¯hjžéw÷H”µÛÃûkÈ÷YÍ°ïf¤Ç2éˆy–Ü i{éÅ=ìbMX=˜{ÈtÄKñU¯Ó¨»”QCÍ“¶k yKáë8=J)¤$±}bÁ‰¤Á2S~AX‡×l×n^z•û>ª§úÎSaã)2£É‹üå¨Ê“\ĉ1è¡È,	RI\°7.ÚÎmÊöw ILêàŸC¬;/ZwÚ1=Þë¼èŸi&)Lnò3‘f[³¹Ô½!Á-ýÒ8’ËAœ™GØ–«²*6D°Ñ'\mÚªçí£·<
þÃ}ž»uGtË¢£Ùûؘ—n&¥Eñ©» ‹™÷À©ZÎyfn/Oz)üç$`/Âè\ŸA
-˜VÎ…!F1/DŠŽ‡QYÌ‘<{¤àËq¤@œŸ$æ,Rr8êRüœ)Øjêê‘`Æ÷ÃÌX*#ò,ÑûNü¨ö‰F˜—ãd €¯…“]må¿«š¼®Ö"!*ÒÈh¬`CJçÃ"Ï“bÊ,@@3NlŸp%Êä™È¬!•|èí³Úyïöê¹ìÌÒj©¾ ú´ˆ½ÒÁqæ9sO
-B´¡É„c?.H@¯Ã·§ìS$©H+¹R)L%À]G·`ÀŽ¨´[°ÞÎÀ}¯”`ß1<éÈÐGV	vˆÅC¤×Lx©eñ‰§Ÿ¹°!ÊLرqD½¾ËÕºr+`î‹ÞõAÉæÝÍ­è°°óÅ{á!¹*¾ï=`÷p¢¢rðAGöˆ=ͳ`{ƒ^Çö¶9Œ³¡Zê+˜¥Y8Ô
dפ8&R‹²Í{ë:šÐë(.hR@-kp
«"à]©àS±Ó;~l̘ýß㥔2Ç€6]rjM‹CÃ/nä±ÅM<\œ“öGÄwòˆ¾‡ëbÓ•ó-… Föµ¾PÀ¢ôjÝ´a‚°~ë`dÑ1/€Ë8 Ééñr[™ÛÐý@"̼Рµ‘¥Ê8È:ç09µ0¡-ïk¯L¸ž˜äA왜[°“œóhÍòr›OžGÒëy)è© wÓ^QÍ(H¸К°ÿnyXâ 8£8Ñ—Æä|T.šØÒ÷àéðNÍL„·‘Ì¢¶ÙðÕ1¹ÚV]¹®x¸—•b™ aí6«²#‹…Wº‘psë’Š3
-<çvƒ*ly±žÓ}.Ði,øý½/¤}¨7„ë\±™13‰s?è6eð0¨ÄMÛ	ÒÆ­s‡É80a%lGAöª¥õ-©ss?¢ÆdC÷üãဧ1ôÓyñ¼·nÞõëT(!S!õ“=YH³toKO‚ùÀtnÞ4M÷÷ÁWÎ^–gA˜—Ê!°ŸYþɬ'¥`žl²•Üû¼z®sy2£”PÚî§ÓÝ3pNõÓofÅ0Ô	²¿S!ß`=­­m]v\µðëóeÕá›Ö9”BÖ›rUlJªšd>K¡Öì1ÔJÁ‘|šs$ä£â +sì4„ø-hH^„ؤnøºl¨r]5>JéG~’0oMãå¿l¨›¸»fèpÊP¦âïyÃXdQ¶áôs¥É!Z^‡À?÷g5™@?é\ã×(ò<ó
-rÀ´6†]O>t=vàzòë±½ëÉ+ì+¨ƒ‚í¦kæME”»b…`;‰àþ2uÛuð:—ùpÚg~ÃÒËáu’5q,2•¢‚(ˆ*Ó‡!NÜß2¯þEàîW‘m­:®I®kü¡Î…ÂËÒ'¿WÄO:Uk°õÿYendstream
+xÚÍZ_sÛ6÷§Ð#=£øG¼77±ÛtzNNVçæ®í-Á6ç(R©8¹O»ØEÉ’Ü^’i›™Z,€Åo‹Ý¥ÕDÂ?5I3‘º˜ä…©Téd¾<““ûîL1ÏEdºs};;ûæÚä“B™Î&³ûÑZNHçÔd¶ø9É„ç°‚LþýîæêüB§2¹~û#ô”±©N^ù~v5¥ŒY¿}{ó†(5¯ßÝ\¿ýî§éåyn“ÙÛw7Dž^]_M¯n^_ÿ:ûáìj6ˆ<>–’åýíìç_åd§ûáL
+S¸tò?¤PE¡'Ë3›‘Zc"¥>»=ûÇ°àh4L=“6Jä©™\+l?fzÎœ;aÑjZˆÌh3€
+Ý Z"
 ¾mèüe]Sg^v¾{EýþÑ#ß\§ãu2'œQ6ÇšrÉL;›éLX©˜ç)µ¯´èrÓõÔëV~^Ýb¨¹ßÔõ§‹ß6e]…Ywɦöĸ,ûù£ç¨Ã6¸òܯz"O§·o¿{Eô›ÛWD¼}wɤ²Yéæöêµ Úì¼IX
)átJiªÃé–eL%wžÚ‘Ø„Ï3 N¯¨[5óz³¨šúù‹Ööòæ_Ø0A¦¬ áx0Âv¡†ãAw80£Ø¼ÉÓc5¤î¼lXÿÁ¯yg³Z”½_€
+Nod‘Ü´=žÌ"ü%îb,íê……a¬ì{¿\ñpдËrá©×·Ä¶ðµï™FGÁ¼
í¢ã»®W(oYõ<šgÌÇ•‚YÄ%غvŽI¾ÿ'*è¾]SÇ—ô>V]Ïú‘{ò]ü_45QV›i¼i°“•BgÆE/	QJð’mãÙKVµßN臩FŠ,WÅà`OÞÚ`X¡½g7é»v³žûød\0Y2tþIÊB™[jêxÂìÑ/8C[QXeƒ³píLZ$0Œ©¯Ú7.KjÂøÁã¥EŽ»v(í¢kR—ÜÓï%O¯_|·åE¾›¯«;ßÑHÐ&òÎÛ†©xb$–ô“Ž+Ï™{:RràšNÑy"àqÀÐë€+ý•fÃ6Ê°- ­â±Mçp'l‘'·p=QIZ˜°ÚÜû*	CKG†N<²v$Üò&zãŸh‰é”·z,?ðòw>
+T-|ÓGÇràæú®–«Ú/9ÚwtÔtM óææVmaë‹ÃóÓµq2º*„/tHmtS•ŒX$´MË„®zh‚2áybR0âÀäýbp.’ãå×¢'6ð²¥ §‚ÑuÔf„ë­òõXR‰¾T’óÑ2>4@à¤ïÁÓá›
+Ñ+¾F*OºvÍOÇhærS÷Õªæé+͘ aå×˪§?éEBáV}µ¬þËV87kTaÇ›
œþc‰÷þÕ¡“D¿¿àñk¾
õÆæâ:_®ï˜™àäx†¯t¿®¢‡A%®»^6n½ßÚÁ	§@x$!D„äBb\?L¨3ÅÐÿÅxÂóúùºxÞ[?gÀBæ¡…Ê„2Ïdr©°y¶#Ò³`>2½$‡ƒ€7˲]9øÉoje.Àú~/‘ý…ퟭzûL ÈV
+gÝi®—y¶JÂÙÕ@+ ¸ÙIfñU
+Ω¿ã”ãP'zÈáM…dü‚ýmÿˆJðHÉbb5tL^üž¤ÑX'r™ï%ÿ߬(ÈèZ•€æIX‹»qÆîRá., ©œ>¢¥À€]g—"Ï
+C.ü©‰·™\¦vÕšØÏî¨÷„~r"ÑÄ”Süª‹áô¦¡paÇÎÒ\XU€ #q?^‡ù¹(Nž-gEÕFèîÔiT%$ßÊÒÈ)ÁùEf³4¹DôŠ,ñÍ‚´Ï"MTvqWõ4ð¡¬7žºìˆa›:vq(ò„¥‘'ÜŠñéä"\1g¨÷zÿÚìf3Ç5FàóPÝ*ÊæÂiùGtgW”U¤êó7bLÉ9Ùlö#è)-$›|pVKï¤J.êêÖyÄ:OÁÔQ(%BÒ¶–äH,é§Ñ¬p U?„K‡|Í!uqÞT=×-ÂþÐv ­fž|; ÇbÈj]-ËuEu“<ä)Ô»û«%£ð‡H!Ñ9ÜÁQqR†5ƒy8vCBc5ã¤!vFÉþ|lŸ°#“º
!P¢SZ$®ÛPçp"l+'þ¾»œ*ªÛM½ØFU7/92=eÔ#kù<üºÞG+‘bJtÚ¨M.¤3\Ò¨!A³6Ö²û)ÆîÇÜO±u?np?Å^v…c%
PÄÝöí¼­‰r_.ÑÞŽúœXQĺ/›èyö^ôñ²'46‚âK¹!b°_RcºÈEª8­0WU®ÉMßPÍÿw‰u…Ìr’èô¡œ¨‹²/á&æ2ÝrR–Hý‹9ÅE	ž@½}AK/	ö°@‹"=Q×.=úE~׃Q=eH&Böv\w#P¾”ê¶Uú?#‚SY!Lº7.d¾û¹àÄ—Ãr©=ý!@§kevÃâû¶®Û§¡9*j~smÇiJì×øûX°Þÿ`DªUÆ\ñF‚?¨1œëŽGÐ=NêôŸAo«ñZZÊŽ_^­È\‘Å2U–Û,”«´g?¢`¯\,øî†2Š.Â'¡K	·7Ô†õŠª.ôi©ÔÚP>Ÿ1†ßدon\ß7ü2ïUC9;IzâêŽ0ùRw÷+$?Z*à|)ùÑÒŠ<çäçþwk•@?d|­vÔ†UŒás.;ßH®/•å€º\–¦`É8ã(|*K$âú4|p8˹Ä2
¦<ããðý²jj§ÚTÖÏØ~cÆnsCøÒ|ܾ>\íVøêè
¨šEÅÙ—QSŠa¡¥Ï:
S=ÎpMª¶,[O¿èKÄhé‘€Ò÷‡‹§\¼Ÿ $ @‚–sèP ¼ú¸òáClVÖLÛ¦ÍÈ6¡%Û„Žv€ÇQÛ+ýóé«ÆÀVƒ¼Ù^YÁëY¤Ž½òõí›oánk'“Ûø1F§†:‹DÀÈ认6–‹^­ž!¤-â'¬mßC(«Žkat¼¿°ƒUº6{)½VÆ	¡iá=ä†ijTr¹{¯åŽù¥®†ºñ>ì['iùQ?l”>…òHü/凿Ê*©ÌÒP†THœï½¾šž‡?NÀÌA&ß·õðå7fÄU=ìܯ{þÖÒû^8@;‚7Åw$õ_¸”W@ÈP¾€­äÚpÀöæòïWRf!|ÛÍŠ!YÊAà¶Û¦šŒÎ¥Òœ‹t@	nëAuUçâìêÀR1Úó×Bº>ªÎ÷yY)E®3ÐBê„âÄm?«‘“(ÙgÿéÕöÏÏl.ŒsGTÄi”ÁWÖ"Hr÷ì/ÔÚdz`	ÿ?Å54endstream
 endobj
-1414 0 obj <<
+1434 0 obj <<
 /Type /Page
-/Contents 1415 0 R
-/Resources 1413 0 R
+/Contents 1435 0 R
+/Resources 1433 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
-/Annots [ 1419 0 R 1420 0 R ]
+/Parent 1376 0 R
+/Annots [ 1439 0 R 1440 0 R ]
 >> endobj
-1419 0 obj <<
+1439 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [312.8189 214.5127 386.4723 226.5723]
+/Rect [312.8189 458.4281 386.4723 470.4877]
 /Subtype /Link
 /A << /S /GoTo /D (the_sortlist_statement) >>
 >> endobj
-1420 0 obj <<
+1440 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [406.3277 214.5127 479.981 226.5723]
+/Rect [406.3277 458.4281 479.981 470.4877]
 /Subtype /Link
 /A << /S /GoTo /D (rrset_ordering) >>
 >> endobj
-1416 0 obj <<
-/D [1414 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-474 0 obj <<
-/D [1414 0 R /XYZ 56.6929 424.823 null]
->> endobj
-1417 0 obj <<
-/D [1414 0 R /XYZ 56.6929 392.7174 null]
+1436 0 obj <<
+/D [1434 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 478 0 obj <<
-/D [1414 0 R /XYZ 56.6929 392.7174 null]
+/D [1434 0 R /XYZ 56.6929 668.7384 null]
 >> endobj
-899 0 obj <<
-/D [1414 0 R /XYZ 56.6929 362.8617 null]
+1437 0 obj <<
+/D [1434 0 R /XYZ 56.6929 636.6328 null]
 >> endobj
 482 0 obj <<
-/D [1414 0 R /XYZ 56.6929 306.2038 null]
->> endobj
-1418 0 obj <<
-/D [1414 0 R /XYZ 56.6929 283.8925 null]
+/D [1434 0 R /XYZ 56.6929 636.6328 null]
 >> endobj
-1421 0 obj <<
-/D [1414 0 R /XYZ 56.6929 197.5762 null]
+904 0 obj <<
+/D [1434 0 R /XYZ 56.6929 606.777 null]
 >> endobj
-1422 0 obj <<
-/D [1414 0 R /XYZ 56.6929 185.621 null]
+486 0 obj <<
+/D [1434 0 R /XYZ 56.6929 550.1191 null]
 >> endobj
-1413 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F53 962 0 R /F21 658 0 R >>
-/ProcSet [ /PDF /Text ]
+1438 0 obj <<
+/D [1434 0 R /XYZ 56.6929 527.8079 null]
 >> endobj
-1425 0 obj <<
-/Length 2926      
-/Filter /FlateDecode
->>
-stream
-xÚí[[S9~çWø±©Š5º_vŸ—„™aTÍîÌ<4v]1nÖÝ@2¿~ÏÑQÛm»“ÅÔò°IUt¤–dé;wIÅÀÆUÐ43\˜Áèv‡®áÛ»‘úÛNÃn¯·;?)7,XiW¹<ãÞ‹ÁÅø÷lÿýÞéÅáÙîPžY¶;4–goO¨%P±ÿñäèøݧ³½]§³‹ã'Ô|vxtxvx²¸;J	¨4Å¿>žR§£ã‡»^ü¼sx1_rw[‚+\ï¿w~ÿ“Æ°»Ÿw8SÁ›Á#T8!ÈÁíŽ6Š­TÛ2Ù9ßùÇ|ÂÎ×8ô)˜4LH£CÙbý¯Ò/pøÕDJÅ®sùGaÓŽiãy­|¼Tä…VÌ+eÎf|CèÏNügow¨ƒ…ÊM±;T^f³]á³¢®î#1J­ã¼É`ÇÍ¢çU5»Í¢«+,EÖÜtUÖT6_ïÒ·?¸áùtŒ¼xØ 1¸%„Œ¬«Û¢)o‹š9šäu
ƒUë»bTþÁ¹±Uöj௳Vº°<j¥=S µƒá‚Ã}"ƒcw+"óßj"l`ʇÒ1î–Eí‘SÜ2/ƒ–Y¡ÖH«TÓzî#ü‘ÈôU5™Tåôšª9É‚þÓ‘^Òp\²‡•ÇñÈéšz-ý l$	ê…"ƒ³>ä“rœÔú¬þÛ*Kç¢nATŒpîÅÈGÑÛÔ_‹Š‰¿¹Y­3Lè@¦tÖ:m±•Înªº!*“úÖh
eÈŽ§ô…ôˆã*£N½Z£ÒF…V*u–SUÉáe™æ>>}â7Pƒ~BƒŠz4+/‹ÄØrš|´O`bÖko”mi/­îGlo»Ÿõ¼ÓŽY#eïŒ`RyÒ­=ø&W	ˆ>ؤXK|S‚÷ãç½Ý€_gaÏÛì?à—·æGj;b=~ð£Î[ׇŸ
-Lze	?€ÌJþõè	0`eë:ò„Üe4i%«wù¬)óÉ7P§è ’³¹¿ÂOèn¾,\z/šnº^Ê鸤yGMY¡"B ÒT©Œ
-	Ä4¿MÔãM‘,TÅ¢GZ[Cµèi»,­põøÆ‚Kº£žÝÝ”$(¯ªûé±ä!;ürWÌÀO›|’šºÂ	½Ë4š„éõÂÙáúó$i!œ/`˜wÌ;Ûk˜¹‚.Å´{GçoA»¥çÙ‡j”Û!òKÎNcjÀøè2¯j®‹ÙC1‹â+Å7CÓò
â¶j#x̵lèîïÛXŽ/HÑgc€¸dcO?€÷3Jd{˚͗€Z&eÝ$£»ŠûÂïŠl­)VBn‚¹³þm™â¶Ã6a¶À[kûP¶ŽÁ4d‰÷!yS²L xö¾šŒÈÉtŽËë²im쨃ƒö¼)zœ Ý‚ªâ7€»Xõ¶°me|›–DsÆéssÆfˆàžìý
-i¬²b¸1HdÄ.&D´EÛ/AË]MËQÚÉ—à‡ho %Zv¨CŒGóâõìÐ¥L]P ×—ÍñZw‡Û²%ÂxÉdÊvÄZFè !ëK•Án@*äÈ¢$>Àí¬¸›ä£Èƒà²¤4²èqu›GN<jž§F¤¡á±lnˆ¶5èíWF@p°–è›UÙ¤ª>ã„*¨ìþîMô6Yƒ”+4ŠÉWêy“·X›Ò”¥y˜íõýeCõ‚:Ä#P€±BÐ:æ{åª]9v—
-jœåik5O]óÔÖ3i;RlTÅrLßóš¾Ñ/´’
#ô•OD4mÙ´9kÒJ'}Ñ´´N®—îŽØî)Ë8Œˆ½;ýüÓò£ó¹c¨WŒ×õ¤ºl#¦»ª.1HÀžßßa:«‹qîeÒÆ÷7@ÚYë+’4÷Ìh˜¼RÏu)}|rô0^®IÂ%PØ?ýDeí 8È	l¸¯#”@E(áKNU#Zênu»&j«P‘YåûÂ%ÍaBÏiãǧç‡ûÑ¥H§tvÍTõPŽÉTÍíÑmÑÜTɲ\1#sf-†+X9>­‹…Áš7ß‚¹šÅƒ¬!3’qzò,R|×Y¤ær·º0¼b‡¢,gNú>“¤œeÒ†@Ü:?8D™‡±mr)˜ýÒ¹…‘tÚdðô—ºÊ¥ã¦3
-! þ\ÉœcÛ3\üæ“‹îV·Å‘8Ý„(zȾœZÉ”	&ÂU0ZŽÆ [<‘‡¢uäHGG¿u9ÖÉ‘wFÅ	Øã=©É>Õm÷rº^w@#¯ËitI4è÷ß©BË‹)јZ¢¥ndhòÎÐËï¤òÙå}óTvQ7å$ù¿dœJÑ%PçÇïðt“ãÙeoÀQÏÌÒ©-4ÈñÖËW‡qÛ= Ü®}Ã@7ûäKX¦Åû¿ü¤PbÕ[‚ˆg6¾ð±_F»]ÇDªÑH#Ѥ£uŸÂzãZ¡Rjùhºl’¬Eò%ßÀŒÎ._qD(½g!¸>ó+!•4^QDa¨"D/ÙQDlæÜJ b<§ÖrzUÅ£wµ0t‰Ò.}„w6u]¶Éëðí.ü_3Ü>c*=gVz
-i‡À÷iG'†…‚h¢œÕŠ;ÕHÚÛkS0?õ€ÆdŽ¤j§–®I‘NnôjƒïK·<Óx`â^€ß'Û¤zŒZçy¼ŽÅæË¢°']Ø@îå£àׯTÒba]cS: 
-ùævžx$$€j‘øÎ|.8ýæ‡îv»œÜ–u}	…Ö‚	guŸÀAŠ—(æÉÞéŤ#\ñì„€G§s¡î¬l¾¶Y]9^âÓ›8b¢´TóʯÀ<1)EŸ¿’¯zî(B=9ß;DŠiÑûp³+ÛºH09g~ä(©±V„ƒcNè¾c¡R$;òÛEŒdU`í)4Õ¾`jCéÅrYz©wËáØ/r©(½Hô"õéýné
º•^­eâ
6Ò]¥êf÷кÈ’ÝCK3¡$s•¦yâ§çë;•óóõJÓ‘Æç	ø‹ž¾9Ð
-®û|¯LiC‘MU!¾âÔzÆ
-™y½¸'Ž=òYCT¼¢Õéâ‰6=A:=(ÓéR{‚zÖiÜF¿ÜÙúóÐăd'-æÀ)ÊHWß5óAï£ï}¸¿øÏ`d•÷k^ÍR8ÂåÜ*øJÅx9ïÕYúÇ=’endstream
-endobj
-1424 0 obj <<
-/Type /Page
-/Contents 1425 0 R
-/Resources 1423 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
+1441 0 obj <<
+/D [1434 0 R /XYZ 56.6929 441.4916 null]
 >> endobj
-1426 0 obj <<
-/D [1424 0 R /XYZ 85.0394 794.5015 null]
+1442 0 obj <<
+/D [1434 0 R /XYZ 56.6929 429.5364 null]
 >> endobj
-1427 0 obj <<
-/D [1424 0 R /XYZ 85.0394 695.8713 null]
+1443 0 obj <<
+/D [1434 0 R /XYZ 56.6929 249.4119 null]
 >> endobj
-1428 0 obj <<
-/D [1424 0 R /XYZ 85.0394 683.9162 null]
+1444 0 obj <<
+/D [1434 0 R /XYZ 56.6929 237.4567 null]
 >> endobj
-1423 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R >>
+1433 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F53 967 0 R /F21 662 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1431 0 obj <<
-/Length 3069      
+1447 0 obj <<
+/Length 2929      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZYsÛF~ׯà[À*	Á¸6OŽ,ÅÊ&²–b6®Mò’#k`P²òë·{º‡iÞX®r©Jèé9ÑÇ7Ý
ŠAbF~”Êt§Ú¦‹³`0‡¾Î¹pƒ.ú£¾Ÿ}{­âA꧑Œã‡ÞZ‰$‰Œg¿y‘¯ü!¬xÿy{{5¼aà]ßü”P:”Þå›Wwã«uD<ôû›Û×ÄIéqùööúæ‡_F¯†±öÆ7oo‰=ºº¾]Ý^^
ÿÿxv5^¹ÿZ"PxÞ?Ï~û#Ìàí~<|•&áà	/ÒTg:T~¨•rœòìþì_ë{½vê>1é@øB†
-øZˆÃ»ÒìʤT~ŠçÜÞôB©/àH^k?Hƒä¥êI^ˆÐ×I<ˆÃÔt¡äïÞ
/"8Žw×EâÕÅÌ´ ·$öÙrYTsnML÷dLEÑõ%‰”DdÕŒˆw¾æÍfvQÓ¶¦õQúƒXûiJ8´ ÏðÚ´Ó¦˜˜髨Xov ¤ˆ”¿«<Æ ¾^§÷ÒŸ'H¥_M.Ü€—Ô„‘I OèF…~,Ejå2º³º‘ÞMõP7‹¬+jM,=÷\š¦­«–,ë%0ŠIiˆ	‘P^—3gV/²¢Rqì]}€%pÞÅ>õsSuY‰3DpRYB$ǔՓÂË*K¿¤²¢4òe”&'”RJ„ˆHY£û›†:Œ”wYƒÀ
-Ô‹N„÷úöþþêrRئôÚb^eÝŠ´E¬YÖe ^a_¾Ø…òÅ'Ê÷ é@éÃ2ï¿ÌKÉÌ4‰ÂÿÇçÜŒÃ2­ŽËÉ`(‘/â€äxÿöÔ¸™ç¿´ÑP,6÷gÛeMÇ×ð=3òW]™ŽU—ƒÑtÏC!„gïÜ-„Ç1ßåžì
-Þ4<¢‘Þ«~Å!PG~,’!P˜J_†)…@÷w×èƪïÆ:H¼n(}I7ã°áRJµ<
-‡KÁPŽßÑÓ@Ìãa*=ó¡#yp8ZÛç¬ýÔ$îèuÓ?Þç½òõ*ˆOÝ6Îa¬b DÌ–·à*”¡ƒ+$Ÿòbš#1r!“‘É5rá‡\ç‡-¼]ár6ãìþçñÝPÈÔ;§6§(8¢Ý®–˺éœjßm!ÇÓ†C
-ìIæ+F2%E|\:Ñ~)mEùN†.„±72KΩ0…âk'Q62Ãç;‡"µ¹h ±›ŠÅAº“Šýí*ÖñL¬ÿ²/¥“MòTYçÄA¼SÖü{³ÜA¼‘ŠAgÝúpon•C?*‹ÂÝꛄkHø‘ÖÔîj¶?7q¡llcsñC]–õ¦û ço¯u¿ði8e¢a;œ2-3T1ÛÚA¦¾T g#ù5Ž¶5ÝhS³]ÙGÝ¥‡
¸©YuxW"ë1+‹#éÜ@ø]Y{’¡>–x}YÜzÁËN¥‘¦ê”›\8D¥ÜÜ/"FÅßTiÀ“;X›—º´¾@©CEËS9dß¾”|\¾ÌK¼.ó¬nA盬íŸ^áw›	뮞Ö%q¦\“ê,haPÞQÇÏ7cbX(‹bvâŽÕóGìÖà…¢²P®
¬ÂV߀È××µ—«fY·_ATA6-¸g!üôM»¯(2Yew±¾%á6óº~9˜¸·|×îŸ,¨´/úÔ
-‚X«…é>V÷`H,üX	{Ä&{ÊþŠËoJj!Ox¨‚üH…œü½@*`@oÈi†²M´—ÙRÇN*ŽŽ’¨13¦¬—TIlÍŸ`“ß´Dr’ò_,³´ÂW`³ó Fön0Õ”ÒÃ"¼’Î$‘cÓà´ù·íÀ­|ú]¾
-}YSÔ+^©}nwʲä•Yð}€5ÅIÖ®-ìãxNÓ¸Þ9ׯ—Ža³èߩѵ5=ÁÛWOq/e__KP€sûÄ  Ëd¢ŽRÉ‚4Ù
-@{D$«lÁL2$è|èLŬŲ,¦Eg¸‰×d`€<x„Ve?G`Ã1QÁó![K[_¤ÅÝtÞu4ò‰¸®yeó!ƒm
ï¹Èªç}XHçF$´ßtC»oSe¥jèÄÃÕ‘/gÁ¸y†)>rZx«©«ž·ëx~ÎS{;/³©ÅõT¹¯ÅÚ›æ”Ç$XçEà­aÉjTõÌâZh«‘=/G'À„ˆ¾óhkáSZQ¶ÄÚDeÚs5U†Âû`ÁÚ¹Él-a™©{^Ú3kE#ÓãñOXW¢qœâô‚7›â7Ø,££6Éd˜/Ò	ÝZ$mË&8Ñ%Ãï·{@…LÝ7zM¿tÀ¯ø<[Ù"¾]×•1.RuÁíºo”;1$XÄ2—äøîxÜÇ"‰z.§Y˜Œ”õnkÅ1Û2@zıõõrF
ëQЛñèbÁÃËbQtÄ´`ϼ~⾚v¡»9¨zlO3;áeÞ›%¯RT[;M³inÀÄ"¡Æ¹;íºÇÜfµ­ŒÅ‚¾ªüx¹´…°˜«cÈâÊ?Ü †ºð ŠÀqÇwøx÷ñâYÙòR(‰1á
-:Çšµû<½·1I×éðU™³„·ÄÒxáÎŽ¹ïÖ²«¤Ú
ó_°Ë±ã‘ÞRVºq‹ŸÐìáRþ¸•êÍÙ ÜÐÂUÊS·6"ê)7ëx³Œrrë(5_ù5/ʽ˜Ð‚ðÑ	§n‰²&ÄÄГãÉ„Ô†O<ð¢ø˸	S”Ÿ^RZä¨ðø‹Ž[¯·!‚Ã켘PûÑ:Œ‚5Ù`Wi=ž.ŸÙ÷nKÓØؤšr¬Ò®æsÓrpBÞO”iyšP˃ózUrì3ánŠq¤»g¤Ç	-]_’ï!üÂ3¯BzìO¤¤(øyݧØ
ÏÍè€_Í÷b9¬LùT(ïv‰Ù	^o:q›¥l‰@|4‰d:[Ñ'W`@øDgM9Ôë-Çéu¦=ÀVQ­¡?+!k¶jø'UîÑ­{¾±a<ê—yµ®\4ɦïyv…CnT¶K]³rõQ­cÃió|{u’(`—BŠ×ïœbÀáŸ8øòz`½f†3ßðÁŒ}<qÎQ3é¨;ëÛ냿ž);ð̧2\ßvÞåwN®'¿$'ß_]Ÿ¤áIÊLÊ“oÏ/>P§ÇÉåÅÙùÇOÃãC«“ëóËêžžO/NN„ÒFÂT|Å¿//NiÒÙù§‡¿]pzÝn¹{,Áî÷÷ƒ_~ãƒ	œîûΔwfð
΄÷rp bF+ÕôÌFo_Ø
K_b“æ‚	iðI3%ÅŽŸ¥Ÿàð³‘Ô–9ÉíƯ©-ÓÆ"ë%Ìt\¶¬—ªÃz¡sJ™5ž¥
+Æ÷.Ž&)ãt2̳lœWÀ3o“úP$ÓœèIyŸs¢çÙ}ì­ù¸ø•s™O¨ã©¨§Deó²žæËÍu‰RÀÙ½1¸w„;¹9ÊËdV–Ÿñ…Ê«äañÍá‘–.Éo…Knóq]<æ³gš™ÍŠ¬*æw±5§5ù¼.–8;¾¯z¸©©Ó„ò–`ƒa7|}íY¹jvÎ5œ8CË,
ºëi§fqìgÖL¿:.ÃsBãYEcô:l"tŒ³jc;d¸[Tašˆv@º?dD|È«ñ²¸	r€fx9ŽŸ!S+Ù¦h°›¦rÐÕ›·é¢ÒŽ)°ëÁ‘TÌ®ÿÄ+i…Ú®Þ©O™L½ëSoàž"ê=úáô_ oåy2ªIAõ"ƒÇâáfVŒ‰þœ?Dzª*ÇEV–Â@TíÕªª¸›7ü†_¡Îÿ”óD¢Šäh»®ï––æJo—V—
ocí¦´Ô^¥§Œ7=ÒJež‹èŒ€©”fMRÂG+Þ$Ó¬š…vÏŒf4BÄ® Ä0Ö"N"!¶«L+D¤Qˆ[¶&Ø7I¯Ã–}I¯Ùèë_Ù¬Ø.½”3͵ê“^
+{óÜ}¼ºùi§ÓdÔF†jÃ{ÝÍÊ›lFô¢¬Šº(瑱£‡„œ|Y哆¹7Ѽ<ÙÁÒÎ^ßvþ¯k*eÚë>Ž	°Ä¸ÀÑïÎ/Î.¥ÂÉä|‚­å©°‘§@œ\}""›#ßÀnPØñPN8	#5§eUcìð~MŸa$è3LD}ÞjpP³C «“¾g%$3Ði@¤CĦùϯF§'! H«trœTùXLÈQµÞè>¯§eô+·àÊÈÙ€ShçWU¾rWm÷=8«e‚-”EtMl»0ú’Ü%¬ö+­½ãK­êuH\3)"t:}€$ÁpcÚÆ€V”¡Ó)C1R5S¡'›LâÌ*¯ÀD„øyúeb¹Çµ³¦ï
^§¶K¤{Ô}IÌÕ¥æÏDfÅv‰€§rÜöÁ1ãàG¸&‡L®c1˜††ƒ&Œ#Âxë„qlSï¬
+ø	Äë!ù3ɧª™ìß*'°È»b½ìûoÔ í…ŒhB=Á‡Ò4òôòÎÒ›¢úÛ.¹y¨_J.ªº˜Åè}3P[5:ÿø+7œÃ¢nÄÐ
+Ù¤‰˜u'I¯ÄýêîmÊðUý³Çë¼íFk¦!#ýú¤Pb3Z‚ÀÀg\ðA²_ƻ݅DšÁK#QO‹Š(BõÆ6Z¥Àã¯IÃmQ-ò>«äK*¾Cc¾c@hDʼ–}þL›Á‰j[ô’œî‚Ólc ”ãˆz‹ùm‰†4¸Ë`˜Ô]ºÈLèΦqêºSÞÊßÎÆ÷…¿‚7ÕN0nÓ^oÊ3¢5ò÷'ÐvãÅ´£>À‰bFT£îÔ"m‚0$,h«Ðý‘TÍkDztSÔDÇ8z»#øå4e
+&N$Ùì!’èÝfåS°:Þ¬¢î›¼܃^Ú·ågMâè3=i³°Ñ+uÅ
PÉ_¨ž´yGäP
'^™Îy«¿Ùß;ÑoW’ûr¯_Á uê׊´Gá4ä«–;ìÅñÕõò®xrAœÇ°ó`wYÔÏMVWÌA˜X¥ía1d{­ôbK;{Ý—
7Z²O–ËDšöE,
ùª5Šôbt|µ.MŽ‰ó¼~*—Ÿ©QåËÇbÜ0z<TÚáòŸ[§åéþv6¾ßz¯9€VŠI“Š>þ¬·>òAê’ëà	”mÕ5ÃR2uE/ò;8' ÉI*ˆjÊà!ü˜5­Vn'Ê|­çèœo_P€
+µé>¯ìW+Ó«æR3Ñ:Šáô$Ô†\Ìu`Yx¶Ø™šuIOH(’„‚X0)ÆÄyÓ¬&j8ŒKcfT¶ô?ÍQÆZ6ñCCÄÍ`OFq¾¬3ê“í,‘×öˆù‚A3¾¥¬‰È¿U½ù¾Ò,'â¥KJ˜‰ÎÙ õDgj8¤gý¼¹BÙözú;y-uµ¥WÓ3lêè¥èHH}ND¸o.ovuc_W	Æ3kÿ¯¤n‡
+KÃRãû‚Ÿ²–ñ4žäçë€fUÔ`ížj×h0õ¡úâs]}iv#â0/ˆ© ¾Hú"õ^ÕW¼õ•õõºQ_­e”
vÒ}¥ê¦øлJñ¡±‘âCO€šð$_óÂO·.ë•VƒIú«é¨ãÛTü«fäŠfµïË•°ð©JŒ&UáÒº…‡¡A®^¯®‹ÃŒlYnju¼þA¢ÉR&­F*ÜÍbÙÇ«7UåvçîáßqU[‚ËrÊ÷ˆì‚)Ç)¼Â¢	(èF9[:YÓbV[¥=åùœÄ6 œ”DPù	ˆŸ™æ<ö­WSÿç6€ÿÓΡßq	X̼t}AGB²£-§‡áULÎçàïcåZZ™4ÏE¾¬ÊyEÈët7á3è$k›dßÊŽµ–Ê(¸n‡á¬J߯qv»ËÛ]6¼gCRœq8HŸ´´a†0îp8:ÿQ¼]rRÎ1þ†¸.ºW;n³ú¡	ƒØ5Éê/øzbC„1ä¶9r³»QY÷,ïøFAà—XFöÕÀ¤,Õžœ×ðò²k4X>ÔùQ=%?öp7u{'+¨´ÉêÒPDªˆ$(†B"|Hfe”$⤼ˆKm·•IüúhŒHJ!¨›äDEàƒMwòü0´qëäÃ\Yž³«;§
<ösì2}_媯¡Æ1(}æ(ðXN“$‚9ç}Ç­ä-ZGzñ«±E¤	N"…lµˆ[8¹=–5S‰Í[$%bâHtØ X¿DRJ„K¤0!^áœpmô‚ÄŒÿÓRWïøI€W„ק4:…#‡2º<Æ4ÜÆFUÝŠU­ê€QC¾¥gFS(5ZhË£BˆPµëÅ#K>Ÿoøè¢sÔwŒ„àL§i2eœ;Â@£«34cÕ5cÍ]û*Ò£|>	I1ÐWå¬?}¶„,!ºYNM-ŠÂŽ`5HdÛù~W<æÑbòÕ5Â
+C½¦h?±Ct¦¼cDäRfÛô‰ŽKÆ=]÷†‡Æ$ÿÀ0ÕëV¥Ü”ÁÁ¥.yʃêó£k Û‰X	¯¨…®ãZ«íÒûç£è	_õ¡¬u;>”ípàÛX*™¾Ð:./ú¼Ñwgx0s=	Ä(>²ÉSöLí´CG(p…Ò,4‡ÕtmŪFÝÕ”¤CŸóç¿TD¢ƒïÈ=îòåbùÇËŽ­¦&Í®¯V¼y»!ÃeV¦(Aˤþ¥Ïýù ÷âîµ\°úm!uw[>òW> endobj
-1432 0 obj <<
-/D [1430 0 R /XYZ 56.6929 794.5015 null]
+/Parent 1449 0 R
 >> endobj
-1433 0 obj <<
-/D [1430 0 R /XYZ 56.6929 420.9025 null]
->> endobj
-1434 0 obj <<
-/D [1430 0 R /XYZ 56.6929 408.9473 null]
+1448 0 obj <<
+/D [1446 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1429 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
+1445 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1437 0 obj <<
-/Length 3129      
+1452 0 obj <<
+/Length 3340      
 /Filter /FlateDecode
 >>
 stream
-xÚÍ]sÛ8î=¿ÂÊL£?ôÁ{KÛdÏ;Ý´çzo:·ÝÙ–m^eÉgÉIýï @Yv䶷ۙk3SA$ B€Å(‚?1Êâ0RFR£Ã8ñh¾¹ŠF+˜ûéJ0ÎGºéc½œ^ýí^¥#šD&£é²G+£,£éâ·àÕ?nßMï&×72Ž‚$¼¾‰“(x9~xM#†¯Þ>Üúur{ê`:~û@Ó»û»ÉÝë»ë¡t,€bÿ~ûpGH÷ã7w׿O¾º›v,÷Å‘B~ÿ{õÛïÑhÒý|…Êdñè	^¢P#G›+«0ÖJù‘òêýÕ?;‚½Y·tHM±ÊÂ8“逞¤ÒSlÂDIåô„’‰P‚ QÓk!DP|n÷yIRŸ·»¢il]Ñ{½dM¶P½-¢ÑÔ¡ÑB;âˆt#òݵȂ‚^ÞÒ£)ª¶Xà„lE3[å»ÁËz·!ˆfEЮ™Î6Ÿ*ZÞÁñÏnöõÃ{§궞×å‹ë© ¯xǾö
H]¾È¤cäFI…MK'éÚ®Önib‚¢š×‡/ÌO뢢±¦­‰.ãXÏéQ囂–4Åî±ØÑhÍOæ¨.q¬ìR%i0®h	É\|Î7Û²hè•ðhç›Nî_ÑJ°WýâT6r¥•&ëCY0h7¶ݹ—¶æç:o HÜÇp|nò¦-ÿcIǾ<åÀl}8_GzZ'[‰ Y×O~Sfi^ÃU-SCkÀ' èG'‰Ó-°ÍÐâ9å-؇”q°©EÂÖdÁÂô,¸E óAg‡3¶Z•
•¶*Aäe»®÷«5M ¯¶Úç-y,CÔ†ÀÞFpl5¸Þ¬äm÷H'­4éEJC£dæDš’)(8¹|×èÜž­ŸÃ’ÁÊ>’µôfAL²¿•“IHÀ˜gr¢ã)ª`V¬lÅ$Ÿl»î¡Ád™WŸP=p8-»ÆðΖIäM³ß€…˜(F¥YAO"@C¾M¡™öCY‡ÌÞþhë}ã£\HÀKä–@VH³;+G®-8HÚj^îÉÓàmé\ÂÎùÌ–¶=¸X;xr÷uYÖOî°Ñ·ÉÈ ¥€Óc3IðÄã¥E{=ANß¼à¡Ã¶`|÷pl^‚2™æòl¥“WG¤n!#œülá¦*6ueçÍÐ	-
-ôûŠ¢hnV?:çH|4NòL³tâ€UÑ„ß^‘9à/ëN`‚xC·*ÊÊ¡…F@ì‡^ÓpþX[ÏÕffW{<bƒ‚³¡ç1»n›Bb(í•‹àQ%îõh/ð²°Íjɪ…Âbч•7!© ©{›á[L:DjåS~`kQ)‘æàxã‡>×åó¥ãà1/÷_szcÛ¶óº}6>¥èn¦˜•Ü÷B”˜/¹¶9õTàqwÁqÒ~ÈÓÝ-¹wÀœGy›D·©&¯)õÃÿni¨)æ˜oIÏÖžLèy”^0tò£üTÕOe±XHÁÉٹ˳:†{ùÝÃ7Õ™ÆP¬AuÜ{TVùz{âuHZ8ÒzB•®>Ôz¾ÛY”þ¸r&¹a¾êBìßÏb¡D¨!1÷¡ˆcý-)±J¢0Id|šÿ¹Už‘^8ºÈ­‹€ƒ^í§¤n:¡nb…2¢DŸ>LL/*
³86#ÈàÃ4KŒ;”ñûqx÷úWðÃDeQðˇë›T¥ò/ü_ww“Û°C;Ó¨6"Lµööþkò æÀfö=5$³PjÒús
Im`n½dJÙ>WÉí‡N!—õÑÛéÖ‡HB™ó5‹&ÌÒ$vú8µÌÖÁn Z¥ub›X’—5ƒ{š\/‘•ÒÙ×ì$‚ð&ùó²Slˆ¿ õWÚÈP¥&ùŠmhÃ`B·Á‰k@’×·àÔ"Ó‹jéoø«%‹B-µþŠièL‡‘§–áC]ÖQ¿£ŽµšÿÇM'Ò8T"ĉ0JO‹FÏŠG*JÂLšÔ7´Ñi¯x¤ŠGZ t/ÝRR¹ˆ­¤¦œÖù#Oaï¦N3-œê2-|yZÛùšPáû¸±.ùÃ	÷"Ýw#NŠäff[ªö›™«
¼tßL®€X³Co‘
-õ&·Ì–W¡Äjê3Ÿ|±à<¬9K…ÜGO/ý/ëjA© çGãwhPs,þ\ÅB@~–Q)Iòu©pU´ÏH~!ùùãê$ñ;&yÌMc?w¢ù¬¾Ð‘½§úLnÏx‘Ï×çÏÄ“OEYÑ£¢‡+ï©~ä
-fòÑ¢xžKÊ$4 5cßæ`æO9˜ù–Tò{D9/“‹Qg—‚¿
-•(d.ÀÂ7¯Þ‡¿Œ§œQ‚#ÓfMàeI,Ü=€Z?`ìïýWc ùÞ÷ÀQC:…Œ.\Â(4CdRÉm€¾.DpTŽÂ½]VJo»ï¤”ÿåbøþv+RÈ)ébˆC$Ù7^JÊPƱúòÅ 0Å’8æB‘m¾€ºÓ‹jÅ1TRoáÔÀë…‚Žl ‘£d‰`ô—‡Ý…]"ËÂ×U»ŠG[×L鮋%*13aÐ.ÃÔÇ`l§øfÊkÛÌ÷­¼,]t-æõnñ
m”[W…“Á¢hæ;;swÖ͸†¦Ì1îâ8u
xM×k 9[Ñ=D×.Ì猗wkmÁCTTµœ¥Ñ9ÕLJ`ýöWÓ½>pÝòåçJSƒr¥¶ÖÎ÷®¹àÞmáŠ7:õ)q*‚[:«÷x\*òT|=ÀîB˜+}ŒâˆG’™ð ¬/½ òØŒHÃâš*¨]ì”H~ꦅ¶LÊYŒ7ÖÕ½0yØú8аëjךÀ39å	é	bÑ	_‘O|Ïý“¶Î&`d›Û
	åŠCx82óè­À,©!Ð(¨Cž¥´ËÀéÑñ—Åcî\E»âÚ~ƒZÓ1×að¤ÕïœdàLí ˆOӕ´òM­ÏŽ\âÏuQn™Ì¡i‹MÃ,/m¨ÿ€›Q[ASÍm@ˆ	÷‡}°ê5˜b¹<làÌøi°+	*ÕõÀrÇ«(Ù£:hI‹¢;ÅF§bóÆg‡Sb³9Vl9ˆê
-—5[<£¹u%nÞÁ¦âJøsöÉsIíÎÖ®–JƒÕÂϨ©3röìnOâÆz´tÒ—³¡ùÖ#öÛyðJ4“.õ‡!'==õ nC¸yǽm‹Út*¼™öwÁÏp²Aü÷ÖÛQ;.‡'ÔÃR†¯%˜f™\0Ä÷^Q>óÅwCí%ŠšcXvìÚ‚ååsˆ	’²`Ú®7¥/c÷öÏ Ê0aÃÝÞ-?éÑE7sÔüP0ê8κ¾­«w2º^y¦R:âµÀ`¹v!¼æ+º	3ôÜ’q–9Að••Ï?ñºšŸždU|f%1²r§:¦Y~-¢à]gB¸„Ω!ôE=x”.CP£/M)
ñ†òYS—û¶ ·M‘WT“œR¦4œzôNQÒœÇ5‰Þ’½ñ³ÕoêG, ·#ÐÝï©^ÀIªÞ»ýݱ»×ìlR²³Åú茱öÑ;î::O‰¹Ï€ÀîdÝhMOïs§ˆÎ÷bØÍü¶äË™§qK¹‹îÿrÁ0Ò©Ï»6û¦Èp ½‰"“0W`›œô6‘…Qœ¤g&Ý4õÜæ]_éÙGöyàÃ1¼ëo9ãvÈ-üÚÈ&ðç@·¿Ü^	dg˜»î]‚ˆacn‹g÷CÖk¸$äªÉÑU¤sCÏKá"_Ò 3ßGʸššå©§ãK²ç"ânUÐÓ™à3dÞœP—°ú¬¤Ü…éÅtß~–)5nG
-ÃíxxÚUUMGƒÍ+¸¶sÄ#ßsÊŒD& rb4DQÇøýô~0ƒð¶wM:.*^åÒ‚
-Ì€áÀØ»³½­tv8kš¹ƒ
-/ý,LÁw—RC?âŠF_ý`þÖŸŒ6§ÓPe™þnë¾ï˜)'5çœw¿-{Îúð{¼£endstream
+xÚÕZ_sã6ϧð[•™
+‘%Þ=¥»I7½6íeÝëε}eÅVW–\ýI6ýô ,;rÒÞ¦s½Ù™	’ €Àt‚™ÿ‚Y¤…6ÒÌbŠÈ¢Y¶9ñg+ûò$à9gnÒÙxÖó“Ï/U<3Âh©góÛ¯DøIÌæË=-”8¾÷ïo¯/NÏdä{—W_C+Pa$½×oÏ¿›_ÜЀæ©_\]¿!Š¡Ïëo¯/¯¾üþæü4½ùÕ·×D¾¹¸¼¸¹¸~}qúóü«“‹ù òøX¯PÞ_O~üÙŸ-át_øB™$šÝCÇ1r¶9	#%¢P)G)OÞüs`8µK§Ôúd¤fg*a%Ç·¥-|Ø–›A LîzøFð¨Žä‡Q<¨^ª‘êƒ aÏâÈ­`U??GuªÀ›Ÿéå;ÒZs$^žÕö»lAç*ð½7y›5Å"_Ò¤¢b_¾¦¨1‡zDÜx'Þ§Y…‰Pà>³3©„yÒxXºǵ¨¤T>£Å0:ŽÉøÇ;ТŒ•wUÝÖÍ&튺BJ䥋ºï¨y¿.²56µwŸ—%?Tõ=O­òî¾n>ÐŒ6oîŠ,o_¡:a7ÒÙSîÚöÈõž¶ô}÷Íü»Ó@ïõ»uÊöL鳬7©³ZÛo·uÓ9Û¾-Ú®nŠ,-Ÿ°àH5Ÿ¦îC†/jA?RFÏØÄZ'V•ïejO¢Ø»É·äûm^ulG•(¯¾¥ï{S±5˜;érÉËÚ5ûÆ»ø¸Í›bƒ|H§Óf|öR‰zÂ$»³¾”Eváë¹xˆkb?>ˆ‡ÿÝ*'H P`ðŒXøñ~}Oea4Q Rø"“i£»X¯µIqì[ç¤áÛº,ëû¢Z¡–?¿Ç	KCr0I»á’¬LÑÀ4ooi„T`š‡Þ²£mÝÛF–OW¾¡D¥NÖ7Ô­ºòHwiY¸HçðæúÝß=d¸#U$åÿÊ þÎÝ_0×iÈ4Ú<“ê´«$J[›\ €Uzg÷«ªË¸ÆÇo×h——ÊXÀ1Ñѹ°nÅQ]DƈDÏ<
÷IIpeTÆë·ï®×ë´nA˜1bi󄎽¯Ï=éÄ£`XwuV—DÉÈ1ÓÎ,˜kS|s5'‚uO {BcS,Ï@›~ûD¼aÿ·î(¯o-ÿ@ÂílˆTt-5ÖCª¢þ¶o¶u›ã¤ï-0ß"™N0Bèø™½Ä;ç¤D¾è‹²;2$äà¼qwn”Ø‘ð[]av¶í\¬Ä+
+
+ÊŒUƒYBAxµ°\,Šj9Aâ@Ä*à¹Ç]rlìOs ?×'5¤­ŸvÉÈ"Ô—ñÈoCéüçmjZ¢j“ÐKQÝqr  0@¢Î2¿ËËzk-
ÝÅ}Á%?k©ù9ò/yÖwÂspÙ*ÅC&Þ¸‘’Ò+Zü:DJW¥]AÛN‹ˆãŒýpì.mŠºgNíC{6å}]¾ád°L»t‘¶ƒƒ=†z MãFWt¶~ëÛ¦ÀÐæ2KÅy£­é>xܽvv{)ïúÿÄ‘ÒÐ2Oã‰(HDi¹Ã
+" zجÒ
É`ð¶Ë+&m¶e‘{•J¼&÷ãu€ÜyúBÛqD4ïªÁø‡½mÚtŽ¹[λÞÜj\ÖÌ9ÿ˜Â¶9ï¹I«‡)W$¹ñRDWJ"»oS¥¥Ò0ˆÂQ«£›Ó<iºNÛ5QZ˜x}ÖõŒ‰¼~ÍKG;oÓÌu£Ø‡˜­©€™77ÌN
,o©SÕK‹Àà ´Ù;Š$ÀJÈ*V†𯴪l‰´dÐ!ñ`ÂO¾/Oï£
5Ð_çéÒæ˜ô“ùÝÃÖÊ*‹ÜžÏ¿†Ñ€æq!ˆËÞ,««²à=ê“^`BŠ…"Ièx‘.PBš‚±%]”“G%×ÀKÂݼ¡ÇüïœåÙ+ñt]{€.«'£'íó•ÂUw.#a/©©”M@]sÎÀy6]k
+XHÈÒ¦)¨Šd\«é¡ÇêÍ/.s	.Hmx›ëVÌixã„U&Z1¥ñá`ü$j§O<Çplüµ½Çôƒ%$ÿIÊp[òÆö¾ujwÝÉ\#¼	Â+•Õè“@ÈS¨·|4>Ý÷¶ Æzôã¶ÉÛv¨U]ÚF<.<¹„jUâÖNFŽTjÞFíé
¥&œ0ÆHäQç-Vö!ïx+—‘»Q8>Í¿;à]öì1Á¾\}Û3=.¤c"€¬‹ÕÚ.Õƃë
+ÀqI–rã=]A á“…
+êLOéð5½µæ¯ƒI%ŽÀ=AP•îUEKø.Î[ê±îŠåá¦ô8Û_\ÂWSgÃèéCðîÊœ›¥Ê´¡Ž
^þü}—ÚfÁ|7)D1žÀËÊ…û”9[?®ç‚a«óȽ۔E‚P‰—¹Ù¤_p@ÄïZ[ýЂbò¹†êmûîy›ºµ?	{p`FžÜ¿¢¦½ÙG Š”9‘Ê¢¢‡$@#% ²~µ¦”µ¨z’`Nm©9ÚÌVÃÕ[”¼mßRÄÅÔ=êb¢mŸŠ¸
+,GÐ]+Ž}ʹ‰²;cKz+‹íÁ(—Ÿ“+m=ˆ+I‰ã¨ /bb–÷E·MƒÁ2­> zÀ8œŽì\0@|=¢Ñ©çŽÚUA°¥»4
+­»
+åQ·ýŽžW(Ê	j|ÒRÓÙê0²s5Î9¶ì—.¨S6T8é2]€»l¬´Üå.½âÝ&'‡).=Æ1ƒ¿ý½,,O”òŠITFâ|÷fëIæy{°’ê|h¼ÞM"3jõm~°pS固*²v²rÉñÞWCŽ^Ôwörhµƒ±ÚÒzʹ׾Q; oëAïcô@²a‹k;HÇP¡S.6w*±Ý¿@gY´¿`ŠG¶*q¥Âá,>º-ØU¼Û„N
:õh3ìE¤CäVÞ[äŒm¡±òC0ËØI=þ†$ó8 ø̨¡‚í†@Ùgã Å™¦p‹E=”亃·±9rqâqȧ€ê gÈÙ4|Œ8Ã1â9ê9uã‚úîÎ
¼ÀÅhhâïñe¾\åGX
UËNàG?OØc'ƒÆðXGâH³§r®
+îyÝ@ÇBʨ{\)õEcp=2£N¹mºBìÄO‡/•R³@J…að»Þnµ/´–Ñ|»\õçütȇ–¾ˆ’ÑÓîþo6¾‘oBàŠ Ž"úñðÝ•¸xó=>ú¨Ä÷¾yz«Xþ
+`ð]\_Üœ‹aÚáóºV pµ{›øA.ø§(È$B+•LëGJ_$FÃQ|) CEÃc…œ¿ÔqT£þºÚH´Ðq¢Ÿñƒðeßwûû“*6¨ ™#@ yT-£ÿºj‰CC
+zÆIâD(Ê´Ãùa8~tüø#Î/züà%¯¥ˆu¢žñ
+
•zÒï›{7ÝØ'@NЉŒêd´Ý§ ôµˆý0´?‡)©©?SôgÏ:Ìïý£È݆†°_’ÈéÔ†ßÝT$*,ñýÉ&*JéaÖHôÿU­lmendstream
 endobj
-1436 0 obj <<
+1451 0 obj <<
 /Type /Page
-/Contents 1437 0 R
-/Resources 1435 0 R
+/Contents 1452 0 R
+/Resources 1450 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
->> endobj
-1438 0 obj <<
-/D [1436 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-486 0 obj <<
-/D [1436 0 R /XYZ 85.0394 769.5949 null]
+/Parent 1449 0 R
 >> endobj
-1439 0 obj <<
-/D [1436 0 R /XYZ 85.0394 750.0533 null]
+1453 0 obj <<
+/D [1451 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1440 0 obj <<
-/D [1436 0 R /XYZ 85.0394 564.5091 null]
+1454 0 obj <<
+/D [1451 0 R /XYZ 56.6929 660.0058 null]
 >> endobj
-1441 0 obj <<
-/D [1436 0 R /XYZ 85.0394 552.554 null]
+1455 0 obj <<
+/D [1451 0 R /XYZ 56.6929 648.0507 null]
 >> endobj
-1442 0 obj <<
-/D [1436 0 R /XYZ 85.0394 384.3846 null]
+490 0 obj <<
+/D [1451 0 R /XYZ 56.6929 345.1443 null]
 >> endobj
-1443 0 obj <<
-/D [1436 0 R /XYZ 85.0394 372.4294 null]
+1456 0 obj <<
+/D [1451 0 R /XYZ 56.6929 320.442 null]
 >> endobj
-490 0 obj <<
-/D [1436 0 R /XYZ 85.0394 286.7057 null]
+1457 0 obj <<
+/D [1451 0 R /XYZ 56.6929 134.8978 null]
 >> endobj
-1444 0 obj <<
-/D [1436 0 R /XYZ 85.0394 262.3661 null]
+1458 0 obj <<
+/D [1451 0 R /XYZ 56.6929 122.9426 null]
 >> endobj
-1435 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R >>
+1450 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F47 884 0 R /F39 868 0 R /F21 662 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1448 0 obj <<
-/Length 2766      
-/Filter /FlateDecode
->>
-stream
-xÚÍZÝoÛ8Ï_¡‡}P€ŠË/QÔ¾uÛ´—Å6é¹>`qÝ>(¶'K^KnÚûëo†Cʲc;éµÅ"j8’Ãß|Q‡?¥†™\æQ–k–r‘F³åî ïõ™ð6L±sÀã__]œ'2åñ«Ëß¡%”NeüâÏßN/&Ôa<믗W/‰’ÓãÅõÕ«Ë×ÿšÒW–2žjeÊÀarãôåÕÄfí@c”Öñ% BIžÇoþp
~žd06^UÍv†ìiW糩€CÙ®äëö†Z í»¨Kr–¦ÖÖ¨€deЯ¡
-Û×N´£œväÕC3ç?¸~8´88§Gô#$Èãêˆ~äX?즘ýg³bíúî„vFóþ¸Ú198 mÓG¬£7KÉ‹?´ŸDLÎÆÏái¦þ‰£*Oþ«ÈjðÑJV‘±–É,ÏíQ"³:’ÇuD³S'´[GÐ@“³\§¨„ñl7€>¤2³L[\µI3&…ѧ©Q9“VQ`xçš—2ž—uõ±\Æ7ßWµ§ß”ô,ú¾\®úrN¯}‹²wÔ"s`ü ЈE¹C„ EŠf~HjJ0#™ò¡Ã0+­ôCþä)¯¿‹ÆoaaÓkèÏfÃôQ¢2Á¬#cA9Õ-åMYõ‹Ò' ­'ö‹¶+©Ùmf³²œ?£·‘^‘í Ú A”GjÛ:ÐCZOœ>ˆßŸH¿ñ+ΊùÁb€<ŒN¤ÌX8¦D¥LŸ#`î© ÑäœÇïʾ¯š;’6þÞX¤61s-(bNnr÷Õ²Lú6Ám…t”ŽUËçF?Œc"ÃV]|¬.îUËcE°ÆuÐrµÀE?L•38s‘gÑ_‡0IJâP%Rlþ%"È£ …Cgò$f¡ŸqI?*ö'ç%4d#¤cA˜hJfàèüf¤Rì,zzöÄ
!¥]ýŽ#9ä>°EQÙc¹#쀰ƒÔ;˜´ó³‚°wšåm±©û=Ÿ7¢ÜFþ‰¿µ¹‡ä¡Ýô;®®[•³
-—9ÛÔ•ý	PlÕýu¸	ý-17F˜Ó Ð/žÈ‘E¹´²ÛLÅ`I˜¢¥Ô)S¡±(œ¹A« éß;z’3“©O¨½uˆðR5{œ“‰ËÁÿ,ª0sȈӱ—;îÛ(ŒÃ6‚“ã['ÇÇNŽû½x‡"jhT§0Òí·BÀÓ+ŸïKE‰wùÂÊGs(2­6§+e3È›U Ïñ8U.ÈsäUŽ<’zHœ—ç"ö&î˜Zâð9&’h¼å˜Úù¡vs·ØctÖ8êÆOU~ZÕÕ¬réÒWà
-
tλ|Ñóì@±°ÄBñC…TÖf¡Î8RxžµöµÁeƒÐõð|S¬VÛçq|ùö£~¼`˜”^ŽÊ!rL•Í·Éõ¦¯Ú†zÑk÷çü£"ƒ½®‹¦«Ï=ÛpŽ£.ßµ˜Ï½ÐŽ:Ü!BNê~NÚ±CÔ†¥Í‰Š9?R—%ÌE$:p²Q·K?ŠªIÜü™ŽY±^ô’*0…4T«!«°R¡¢¬‰ßN'ÔðÑW¯XTd’Çà*­`
6>¬9ÂÞ\÷ÎG¨(½èm©ý›nSÔ®HÁÑëªO¥†}Ù0—ÁÀJ7ˆKÅ)ª#d\þ‡âr
-ûDvÞÞÃSîÃSz|a‡É$ÖäN€¯ß ÃǼ|˜	ð°Muçdˆè/=ꇉlIÁœxÃö‡»kL9¤û6H‚Šy¨.êW*yKàÅ÷`Úט•Ô½iâ¼·)@)ú‚ˆ£"Æ·>PŽC%¨
ö¹ŸóŽÅá“€©8"
-]‰;u!QU¼ç_­j?€6=K$¢»"Êì á&ƒæ[žs¹­Ò?¡Ö8q?-eü×®qpó<„È9¼]’}ðwQÎæ9VHK,¤ñ6î﫤¿Ùåô€Ja˜ÌÓ#_Ë|*±’¶¤ÀŸ®'—¯ñ:ŠÇ»¶0¸ðƒùØxª¯[ý6û
-áš)Íåi…ðŒåÒXòç‰Í@¨þÍÙ6nÛöô‡°A3£9¿•f~ LÕrúÂ|æ:°ãÆúe9OýÐÖ±èŒ)°ë󡎇’eáñZþàWJáCžk´ôÿð˜ÉÏendstream
+1461 0 obj <<
+/Length 2987      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ]sÛ6òÝ¿BòL…Ã’÷æ&NÏÆé9îLæš>ÐmqJ‘:’Šãûõ·‹]”L9NâÎ4ž	@`ö{R3	j–X!MÍâ4V*;[nNäìæ~:Q³@‹1Ô×'ÿxcâY*R§Ýìúv´W"d’¨Ùõê÷ù«ýz}~uºÐVÎ8]X'ç?^\¾¦‘”šWï.ß\üôÛÕÙiͯ/Þ]ÒðÕù›ó«óËWç§e"«aÃ[üçÝå9½¹øåüôëŸOίû#¯¥¤Áóþ÷ä÷?äl·ûùD
+“&vvR¨4Õ³ÍId°‘1a¤H•mrâX+ÕpÔ«lµjNU2ÏÛ–µñŠ;»6€PÓvYµÊ<ðŠF.~=²ÇmÝl²Žú]M-\´óçmi4ÝûEÕåM•w¶Î‹Ô€ôïŸÿ¦þÄÝüs¶Ù–üÑ®ë{>M[|î¯öõî‹nÍÇ»¯îžgK†A®xØ5‰QBc	}xÒØŸô}±)ʬ)3/ÞwkFÔæù?UVi'R4	.Š…³Z?OÃÒoÒ°ô	
ëåF¿€—Z€V	—1sÊa,¨3`ïã<?|¿¼z/Þ^\‹ó׿E¶óð!NJÔ2gA)ð/ŠÛ@¶làõ÷šÀ”Là_AmÀb«äˆ°9«±“BÍJá(ø
yœ&#t/D”¯ñ//µ*NEò
~Á"E\”<ílœ€—ÕÁ’íÓö§71#£––¹r¨±ʃå„èüþÁŒp‰SþÃ1ûÅVwUÜâ)ns:LÅfhYfllawÕ3¶‡i+…!JI2l¥iÙ$H×ë¢]îÚÖ;¸1Fô•Þ¸æ˺YµGû¢#‘FŠ„ø¡ÓóUÞ.›âÆ»8gÈÊýL:˜]oóæSÞ𚶫éF4WTä†ÈëÂ|ÆpY¿¶ÈyÈû]cöÔ;ßYæ4K£KÚ}Õús(¦ïx5¹õ	o˾yn”g4Û¬éŠå|9"Ä®'´{WðKoê²ËÈ°Ë]ñ)çÉÞAýõ>J+9Þð[ò!ví.+Á))°(0ÆÎohkX\s'+ﳸïÞ•´¿QAìS·`P`e¢4æ 	ÆÛU¡Åج2ìBÃà@·.ª?iÈOé°áÕ}â9ñ;-/|Øz™€‘mV44H[@ä“u2G'¼—˜%’`(
+äòN
–‰«ûËüSæU%ŠÑnƒT‹,Ä|+ìÅ¿9ÆÀ™Ú3z`
+äfVâ·ñס™}VÀ› ]çå–·yh»|Óòr—6EÅËï×yX,˜Á+N΂±_j2Âòa.ÈÀðÓ`Ö+š%OHèyöŠõiO×Gþ0äoOÝy¶%جvo»|…2« ¦c,˜€’Mð;¤Ú$s$`Ó›ÑÓÍ/¼qIÙ-Á4ßÉCü‚·¨>d+"¶a	Û_(xùl™¤dÞµë
›™=ü	XÞ8Øp»ã–šÞº¥姌Q⤷áÛºZÕž7Õ|$šÑ®ƒÃTÓÑgvGž0AÍ-æ6£$YÙòO^Ws¶¬òϼGI¹ó†§úCóý#%ç¿ö"„KˆO-¯ê©Û‘9£F‰¦Ö)ñ
e7m]¾6yVÁ	æ£Ö1
ÃIxO(8°k0]W%"bÖú‹#ì×P×û÷~«‘‘ÀIŒm¿g+À±zMÉ++›Ö¬l6”ÑFÁzCe»^SlÄú`‘»Ëµ·‰~´¦6èÜ> ×=˜½›€–´‘l9Ÿé¢£Ø%— 2ŠCܵٵÝD„ᔩc .šŒè2‘i]| Òm[/‹¬ËWGrìCÇcèëÏ8k¨=ƒè €dkq—goÏ÷]ÉÆ®; ¢ÙXù#ÿ@áßÁ‘ªºAU¡K|CÍ‹Á‘ßÒ >øôH¡½©½—tqØ'Ì%¯ˆØª¾C­ÁGÀŒœtô(Ôø(d£ñ;oȦ7X¾ñvB5ÙR@TŠÂƒmqWÕƒèD ó¸íÌq)ƒÕHƒ!JåÄ&{HCduR^ŸÊÁôb;r“þ¯òaõ=	Ò	Á±må—ÕÄUoB$Iàêl7ÎÕ3RHà mÌ4È¡žS«Õ©°±Š¿.1œ^õ¨œ¡¾?×
w‚ÈQ‰ÄDæH9CIefFYY8•™PbYoÐĈܰ–a´a…¬jþ?”<]Ä’M–Ø[v@c«œ7‰fãó|ß‘˜*6ú‹=Õt
+9zœª#5ƒ96äœÉç,&QÊEXè0yŒ'~}ƘÿÆôIÀÚBäóúèT	«¤=B=¦À(f·us÷uFx_–:/©s:¶@‹$ù‚Î鬵T\x¬AŒkõ‰*_ETÇi4Âþ7– ¡‡2îK4r±€$G÷4:P# õDÒlj4BÿRDz~Yñ¯ð P"‘‘ýÚ²¢6NXãÜÓeE
 ƒ¥ßh=JµV!X€q,@Û§‰ôIÞû×V	%]"ÕE˜ˆZAˆ+CÔÊáÏá®)Á¦£MõvE™Kt¢y	Æ«>TÁkT|Ã>sÆ°õÎ[8üÂ> endobj
-1449 0 obj <<
-/D [1447 0 R /XYZ 56.6929 794.5015 null]
+1462 0 obj <<
+/D [1460 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1450 0 obj <<
-/D [1447 0 R /XYZ 56.6929 756.8229 null]
+1463 0 obj <<
+/D [1460 0 R /XYZ 85.0394 660.0058 null]
 >> endobj
-1451 0 obj <<
-/D [1447 0 R /XYZ 56.6929 744.8677 null]
+1464 0 obj <<
+/D [1460 0 R /XYZ 85.0394 648.0507 null]
 >> endobj
 494 0 obj <<
-/D [1447 0 R /XYZ 56.6929 609.3337 null]
+/D [1460 0 R /XYZ 85.0394 560.3373 null]
 >> endobj
-1452 0 obj <<
-/D [1447 0 R /XYZ 56.6929 582.0292 null]
+1465 0 obj <<
+/D [1460 0 R /XYZ 85.0394 535.9977 null]
 >> endobj
-1453 0 obj <<
-/D [1447 0 R /XYZ 56.6929 540.5567 null]
+1466 0 obj <<
+/D [1460 0 R /XYZ 85.0394 336.1431 null]
 >> endobj
-1454 0 obj <<
-/D [1447 0 R /XYZ 56.6929 528.6015 null]
+1467 0 obj <<
+/D [1460 0 R /XYZ 85.0394 324.188 null]
 >> endobj
 498 0 obj <<
-/D [1447 0 R /XYZ 56.6929 359.8869 null]
+/D [1460 0 R /XYZ 85.0394 188.6539 null]
 >> endobj
-1455 0 obj <<
-/D [1447 0 R /XYZ 56.6929 329.8975 null]
+1468 0 obj <<
+/D [1460 0 R /XYZ 85.0394 161.3494 null]
 >> endobj
-1456 0 obj <<
-/D [1447 0 R /XYZ 56.6929 240.6043 null]
+1469 0 obj <<
+/D [1460 0 R /XYZ 85.0394 119.8769 null]
 >> endobj
-1457 0 obj <<
-/D [1447 0 R /XYZ 56.6929 228.6491 null]
+1470 0 obj <<
+/D [1460 0 R /XYZ 85.0394 107.9217 null]
 >> endobj
-1446 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F47 879 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
+1459 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R /F21 662 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1460 0 obj <<
-/Length 2195      
+1473 0 obj <<
+/Length 2590      
 /Filter /FlateDecode
 >>
 stream
-xÚ½YooÛ6ŸOá{¡3'þ“ÈáÁ€,u:‰³ÇõÖa]_(6S°¥Ô’›fŸ~G)S±ÒtOŸ¢IïŽw¿»£é(…?:R’¤\‹Q®‘)•£åö$½ƒ¹—'Ô¯‡EãxÕ‹“ï.x>ÒDg,-n#^Š¤JÑÑbõ&9ÿéì—Åd~:f2M2r:–Yšü8½ÀóëÙÅôå¯ó³Ó\$‹éõ‡ç“‹É|2;ŸœŽ)’îYüq=›à¢‹éåäôíâç“É¢9V‹¦ÜÊûþäÍÛt´í~>I	×JŽîá%%Tk6Úžɉœ‡‘ÍÉ«“ÿv£Y÷é™$WD*–؉Ñ¥DKÉz†’šdœqg(«š=Ó4M®ÛµÙ¡vÔ•ñz–O½(wfÙ–Lcõî<:…tkHN¹tlkû‘RÉUÑ´Ž)О•ÒÉE½Û-ŽÞ
eU¶e±Ù<àëÊü™¦¬2«0‹ŸÎ/Îq,‘**¿f¬tÒìoó~oª6p»1¦BÊ|lMµ2+8QÁdòzm¥…¬
-µ@…víõîTèY£Sè²mÌæÖÓ
>—›¢ñd	ÛÝÙ=+¿”DbwJA eíž«n¹_õ©í·ûÆ3»ñ#µ “»)¶&’…tJ*"¤Âãf'‚ái{©–›ýÊø£§ÑÑSΉÊ3ë–å7×óéËélÀG„ Š{âºoX	¢åÑtv~ùë‹É'ɈÌÙÚÜà˜%„s•ž‹Å%b̲”HBqaåâP‹`Ë T?žƒWU[|ü~@..‰¤™2šì-'œ2æ×­êmQVãÊíñæ™"Lˆpo¸q`–»-ëíÖúäÀIQ¢ŒÞˆ?¦:#Œ4yÏ>èÁD8‡Æ´Î¯hpWêU³4K*ïºvƒŒ&÷%F
õÏ’âÎEÕʯ¬ñYTHì«÷ûbSZÁ5ìq¼pʌ߷À/ÿòèG}4ÓÄ2Ù5-zNPÅÃfd]بÀ†§CT;á‡-;رðÓåönS.Ëv(ª¨$à\†@“¡ôöúõkð~rç³³+[ê( ¯Î¦³ñ«Éü7¨Á-Þ/È™¶üPl:ÝàŽe~ô-lO&¿Ÿ]ýr9!ç×W…ö¢d}IúÏXƒo(NEáìÂC:ùjÞËW=Ø•PzAÉåÞB¢}Á%z´Ë€Ï"x½+ß¡{?â’©LÊÀÎCìÀ™Ìÿ—„F┤ÂVžq
-˜#òP—ñ<¹sî_/«ˆ`ãx3à.|U
-¡>ËdTuðQø\|ÁÖ.¾àýþ€Ãv‹/^Y9ÜËMm˜,=ó»>±É#Í’éíPÑA9ô"Œ?{L)ëÓ€}I˜pR¨P¤ÎŸ(P;a#‰L€í¾l׃‰N‘wPõ¹¼‹v—¡,Ø_”Õ6Þ—yTœ~:%ÐN?ÿT¦ ü¾±å=‚~žC™’ª~Ù‹  T8G£»ŠàB÷„t3]´¯Q€Â5Ìίr9ðQhyÂàŽ®¿ßÝ®¬wÇŸàMFIÞÿ§êcÀ!‚_ÕÕÒôØ‚GAQÐpö=*v$ì¥\aª¸[)дC}/ç²#ûs_ʈÖR7¾ÁšÆ2ý4/ü.^ž_ôYî ¶ˆ¶áÖõÇ<îu
-˜¯èˆS»,E4‹NfP[[ï„Æ
-@oÝkÈW4YÀ–Ýh›ò@4–[¨„ʶ½¹ÍqQD;]6pßM·lô¢F‘Rñ8æì”ÊXH,'©
$¦¡4c¢m-rí{h¡ÒsœÂpFÊà.ì¨õX*;Ьëýf…+m…nÇv¦iëñ£Å­ë5íDáÑ0ë¡!¸O&Q@¨ÜüDÏ[#çïéíäPzh…ÉÍ)\°²‹Ì%;hñÂ>›‹K×®¹_¼±ƒh &€—€v9¢cìt±ij¿¿¼ \¿wðf²U—þžŠçÒÞSñ\„ùoS‘²-¿}‚x[ÿíÂ%);¸D1Ü&UM‹ç¶7+ä]øå> Ãç€àe1¼)­yX®’Û]½E
-/dr¼ùÉÂ/²¼LÑîwæöô“ëàiõ8‚¡s’qp‹8X¿,þ-ÒH
ããÃ-Ú—¡SR¤€uÑ•ÛñÕ$K¾)‹ÊS~Tž.—_¯4µÌ‹?I@èînÁÜûM;nÛÍ¿|·N–ƒVyÊûiú•«1t(€ð2âËâTBoMxÓ,©‘¾´ÖsÔŸ©LAyxP¸uîÄáŽßïâ´¯™µ¯âI»ßâÒ^ pñßìÖŦŒf,E}ßçEqtºk,ÇÖ®¨Þy_Hm6ÏDîïò@°jÕ<Ñýôn`º£fÇGMJ±JQë‹!
„­œ{F¹rø¡©V”ßÁµ3ï؇Ëöá;Ɖ½†mO¾·—0QeøÍËÉl2?³&]üÿ›µ®xêírìÌð)ñÍfÝ_Hª”}npG͉æLýÓžÍÝ3¸&Ðéþ^¿)‘»ÛžöáÎ+¸TÐ6Øÿ_%üKI(W8úÁ#íüð‹^9à¸í#”bqewiVyh¿¼PVpEKÞýs,úßÑjŒUendstream
+xÚÍ]oÛ8ò=¿B÷ 5—’(.dS·çE›ô\ïØn[ŽÈ’kÉI³¿þf8¤,9JÚ½¸Cj2‡ó=´8üAœ°ÄHh±˜‹8XnÏxpk¯Ï„£™x¢IŸê—ÅÙO¯”3‰L‚źÇ+e÷E»©nGFŸf—/sy¨É[vê6‘¥
+ªìéûûL¨Œb
+¢!˜x‚èS.Ÿ÷
+3-…±:õš-€¤Ö*œfË
€2¦Eø.³Š€M†ÎPFRþÝÐ×Ú&_ÖÕŠ`Ôv^º?Šê„r>@Þo
+ò}Q–îìºj­Õå˜gPNÙÔ÷t²®n	ªÿÞv®ÑÐt,­¶(žó€žn”sÇ×’îÑ\Ÿ$£ÿn—DÁR
.vg\“Ø£d&uÊ¢Tæ!‘Wõ„—ùL›èˆiÍ#k 4§2‚R‡‘¨ò&'¹"Wù¹]Œ[¢š(UÑ:Ú/œ{5/0£a"ª·›bA¶Æ]7î¨üË®,–E[>¾ËùÊrJ(›àRþ%ÛîÊüú”5Ó»!:ŸØ(¾%²"¤aiª
#s vŸÒÖ TG3˜‚ë®BFP9çá¬B×uîù6Ûí
+ïà…óãÙ»»hätRFÌD‚0ÏexXe[„RRjnêòÐuE«˜¶ÛÍþ@QŽ!^÷YÕ”™£ƒ•5…å–vÍÞ6[­Ó†¬au°EãÈ—›D[öæ°ÛÎ"œbÔÞ2ÒO›¢¨&ö|è	X¶ße#z²-L,UVõ6+ì}t˜aºRi¾[Ì	p%‘
+ت^’@8…„TØr›hsâêšEœˆ`—çtõ¶Ù*r*ó¬i'm=ÙÖMkSÞÄË<¨†Mq[QË*¬p)	šÛÓ1©‚ËÓaÙŠ(Ê|mi•5böÅí²Þ$âú4bé«\fDÖ»]ÝmNèãAvÑórÔ*¼Ïƒ^ßžWäŽu§\?4‡¬,Üî}ÑNìÍùðÊm^1Û€¤ôKÅ©¬£Ë 'a"
Õ}BÛlïÜSžº§tþ…R$“L9õÁÖ+Xp5Ït'?8;HAèÑ/×w
®D«àL);ÝUJz“Ä©çë°Ù8éë¤lFë¼ø·íƒ–9-]š(ï7uã–WY›òX³M2h_(ûÂXýÅ©ÏS“õÌbý“Sqô(L%ÖêBªpÉ¿Ø•n]€“H$d±¦/I€=Jˆ?o“9Êm׃=yÈà)ñ>èZ*	_Ù~²_¬`žcé;‡Žš-ëí'BQÌÿ|ÚPøf-1K¡Rþ¯ªï&ßÞÑøO5 1Ç–':Žƒæqÿs
3#Oh*¹žÏ^Ï`z‹…âá0º>ÚõŽú>áíØ×Gdx?§ÈÄ0JÆT¨!¥T:I ½Ù@`]׬çdO7ªý3”fþ_UÅatQÉóªLŽÔ’EFëoöØ€
žŠ•TA´¦e„÷;N”Ú½()#
^Òk£{½aÅH‹$ˆ OžRkxÕëhâ$H+¹Žæ¼zjø_†^A€'×RJsftdõ|ã‘1Šˆz°½ëQñÓl+ƒ—5Ü(è]Ê3žô9ÛK%²ïð)˜=Ó±$_øÎ.tÏ H,ü­|š º>KPbC2!ºjk‹êØ8Z ?‡°¢r$ÙÞ-­q‰:îöõ¹ˆÃ»‚j;¢p¥ím¯©}’¹mÚpPå'sj]ÙÉC@“-¥&Y@Wéð«š¾UÝ: _B¯ÍÒd*üvrÄ)¨œö¢ÂË‚‹Ëº)‚Mv›ãu°ºEÜ*ûx)€£`‡šñ‘JÓ4–:R·ßšŸeÖz¬r¨žNÜŽ†¾û爻s˜*Nxv{Ë¢iq*@¸v—¿-ªÇY/1ú¬4èGÓ÷(¦‚Ø$æ¯d½çÓÇ0æ!PŽr8z:Å#qbºq0vãàõñUãwj^ðõ´(ô²ØÓ^óÄD˜@ü%²;hQS˜*AÕ{‚+h\¡
ÚZ‹öÞöQ)š¼hߨã€]beídWiëüÕ%!W1Av¶B€Z2 j7MþùW­çv“çAùèôWùŠÑäùaƒR=×}uWh£»‚}Ùiòrí`ÿTfMã‡éU¾Ã3+ÿXhߟxÜyöfïì¹ã·‡Æ1»q˜z}òÞÔ¸6ÚɺK&"ÚKŽ3Ù¯í¤Z–‡UÞ=4M/¸ºNÄX6øfS)bG÷b„U-‹PžÑìêòÍo/§cs6‘–GN¤¯j5ÂRFLÁìy.oHà®PÚÇND3‘º‡lL¸ˆXx]vä ž‹b÷þ¡j³/?È¥ -I<¦´x 4Í”Ã'…‰ž¤LF‘7ÄÇnÐr	í…Fo‹>9b)h‰"å}¼(aR)åýIÍøpy;4ykýJxwÝ+†Œe7
+Ÿùr¯¶‘ÇK[§0’eM߬z àP}†Jå^àhÇã7%¤€Ü›ÑÎ?]ö.š…X÷þÅÄ_e.zO!"¢†¯Í¨n8D4²ƒ3·\léÉp,ª 3S:5c"1“°ã“ÓßG^5Ó´ÙD€Wë¹Ï€Sm²I=«Œ5`ÅÆ“E±ñ~CÑ×\Ü£F5vSæT#ôiê_”4õ}Õ]wj'E;§²fS
+`È
_ºŽ¯´ÃôÛ½	„…Ž@h“|]ØAØÒsÔíaÛ•€Â—‹vX6lkf³Ù}8ÍÙˆEá	f'…3­4Ãq'ºÓiî´¼}øðÁ>qñðòêâ-þ@šüöbv5y?ÿ{:Onýó¼ÌPi‹»¬ìîVxâRHzø«æÈÏ™<øê|ü­?ž"4Bš>ñSB÷“ƒ
+o”ÊG’Ã3¡ý?_b/endstream
 endobj
-1459 0 obj <<
+1472 0 obj <<
 /Type /Page
-/Contents 1460 0 R
-/Resources 1458 0 R
+/Contents 1473 0 R
+/Resources 1471 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
+/Parent 1449 0 R
 >> endobj
-1461 0 obj <<
-/D [1459 0 R /XYZ 85.0394 794.5015 null]
+1474 0 obj <<
+/D [1472 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 502 0 obj <<
-/D [1459 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1462 0 obj <<
-/D [1459 0 R /XYZ 85.0394 752.162 null]
->> endobj
-506 0 obj <<
-/D [1459 0 R /XYZ 85.0394 685.5532 null]
+/D [1472 0 R /XYZ 56.6929 647.5054 null]
 >> endobj
-1463 0 obj <<
-/D [1459 0 R /XYZ 85.0394 660.2382 null]
+1475 0 obj <<
+/D [1472 0 R /XYZ 56.6929 617.516 null]
 >> endobj
-510 0 obj <<
-/D [1459 0 R /XYZ 85.0394 468.978 null]
+1476 0 obj <<
+/D [1472 0 R /XYZ 56.6929 528.2228 null]
 >> endobj
-1464 0 obj <<
-/D [1459 0 R /XYZ 85.0394 442.1289 null]
+1477 0 obj <<
+/D [1472 0 R /XYZ 56.6929 516.2676 null]
 >> endobj
-514 0 obj <<
-/D [1459 0 R /XYZ 85.0394 217.1462 null]
+506 0 obj <<
+/D [1472 0 R /XYZ 56.6929 321.0565 null]
 >> endobj
-1465 0 obj <<
-/D [1459 0 R /XYZ 85.0394 194.0979 null]
+1478 0 obj <<
+/D [1472 0 R /XYZ 56.6929 296.4844 null]
 >> endobj
-518 0 obj <<
-/D [1459 0 R /XYZ 85.0394 110.3497 null]
+510 0 obj <<
+/D [1472 0 R /XYZ 56.6929 226.88 null]
 >> endobj
-1466 0 obj <<
-/D [1459 0 R /XYZ 85.0394 82.4166 null]
+1479 0 obj <<
+/D [1472 0 R /XYZ 56.6929 200.5523 null]
 >> endobj
-1458 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F53 962 0 R /F11 1304 0 R /F39 863 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
+1471 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R /F47 884 0 R /F62 1000 0 R /F63 1003 0 R /F53 967 0 R /F11 1321 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1469 0 obj <<
-/Length 3190      
+1482 0 obj <<
+/Length 2221      
 /Filter /FlateDecode
 >>
 stream
-xÚåËrÛ8òî¯ðÁU+WY¡åpzœ¤£IUÑ€ÅWâ%D‡@Ì—…Ÿö ›ÆÁœšœ¯ê¦lËóL(c”çx3`à÷ÉJŸ„PnªH*ÌnË>A“ŠA òÂ& ÈÑqjq¯æÍ+Å½•wlMÇG¯—PàØ2_øÁ»UÏ£œ~îµ9#ÿíÔ-êc¨"h“&KŒcàz¹¼¯L pI€®Y¦J'!¤Aý’Ì-ø%¬¨«*_{¸÷Kã(ølÔ<-¦uÕÐÔcÙέ‹‡	ÄõùÙ<–Qš2;LsžF1‰[Ó”…!ð9¡N𩿪ò8™"*²m²¸`IöaýNtcÐ\Çzt‹qFMã÷¦¥NN͉ۼ¤¶ƒVoÚÕƪì}ª74º4]I]Iàõ,_™~ósÊìhbˆ-Yˆû({ƒü€BÛ;B3Íg4DÍi+‡[9è`êÅxržqŠ˜è>
-i¤¸Èv€ñ]`ñ	Û:
«Xr…èŽS3v–%‹_°ÈŸˆõ
-£Ä¼ªÜo«?ÐÞ(×–?¢—´':ŽwÂÙE]”hÙ!ê%‚<ÎKÌdJ;·ŽÉ“8ÄÖ cÖa-7þîÓÜÒ-¦Hj%­1UáŽ)‹vN]4â-Ÿæ
Š­‚ØïW¸ä)õ÷ԪשSÚ–®Ql¬®àLvp.°—ƒéd)÷Âr$¹–<ˆÊܵqº$û€•‹…)J°V•;è?v4WF÷ŠJ‚̱‚-b±GSb%<‰Ú/‰)>-È›âà'„܆±E…-	½Û'ã~AÏøOg–{ŸÎEŸ? k8;M”Ûyÿ
-íL.lDD1_òŪ2g+AÜÄe’¼„UüZ¬Æ‚ɳ"dt$å¶8Ù¤c¹ÿ¬c®vl3ˆf°‚‰‘`ØÊaÂ΄‹³`x¶Y“hÛÌf¬\ŒVkõfg‡sµ›ÊmÈÝ‚œ¦3+yEcÖwõs_
]bÒÀU^>­í”Ø Z§Ä"á#¬2¡·e‡¼¬òieÜjë@¨oãQêö®¶÷w´g%,h&!Þ]a¡•"–)Þ+-?sW˜µœø£À´³Ll«äž#!|ãÊ[8¢x©Åà@4iŠâR´‡så7œÙsP¦£Xv
-ó%hâ¸ÓfP”€Â‹(ëaüŠ: ´„;zÝ°Üi³Z‘Ì@Ÿ	›ÜIë­ì‚ÂÜåVºðGï1Å2d|ÆãNŠº]-øn+ÄÎXX[!ƒ–lìµ8ñÀâ$Â%9ñ+,9V¿’¹DoÕÞ²n©“O›ºÚ´V}ûd*ÞRò'QB{l|‘'€“‚Ó…Ú9=~.QsIàŸJ=kWV™;-ÅP>X°VYŠd4««¼-§eU¶6âˆm4L“&_W¥	ÆÈBœ+eZw¾-äܸŒ0ë±Âš¶Ä¤áû,â~Y~¥0'±FÛrY”Þû‚bz·|9¬÷EDMe£g}N¶ëxÈŒíO‡éØw¦x}ÞøãËRÆQ&y0k”©ˆ¤NTÚêŬñfFÎZ”ÁØå¶S.̸­ÇäÜ4b½GÌú%¾æ[ÐÏÑVUa–T:Mwdá$S´ëÆ­Ü §ÆóvnÖeë}›Ë3¶Õ•—$Àp_¾œ¹UëÓl´©L½œíÌ°ö £ˆ#–hod\,¼«3Š$Ê«L˜`ýãXŠaÕ}ˆ2ÓŇòmJ÷>€"N$7ýƒ@XÒ"ô£
-$?^Ð…†Ø;чË#R ýNÕAõÄÇa‰tûíEHƒ¹¡ŒÃx@ƹò%>XîªX°r‘·ö%[È<¼¯Xó{wà°‹ÒJ{ùÊú@qþ¿äv(?Jn…Øì[TÁïØ+·*‰X¬“ƒr+4‹Í~Z½\>ž´$c+—-ØôBrŸ²Ã=-â{(³®&~C3}Ö
ão¯ÏhØ>œÑèÛ®Ÿ&gÁúü9ÿ»t\½º9À¶A¾Æƒz¬»Î7øj·c/ÛR	ÁF|دŠ–g°Ü–ý! „8;c¶÷œ½d@Ðapׇ,E½È½*PèfÓ¯Ë]'n×3Ó4^šrÙÙÚ>#Ó»Å@óæÈ}½zô/ùÿ‹§Œ
3½ÆèÌx6ü¢àÙ—BAö•I$…€èU©S‘/ËI®\AÝ„M#D]…ú¥'u ?“Þîy{ÖRL5à·“Žþó¥5KÆwŽÂ(”|Ýngõ]Ô@¤SÆ»]_é¥ÉÕ|‚I}N‘1(„ˆ¸âsë(Q)9‘þ>™_Óì\¤{ߎº]“~ÝÞ¾ßÁãÍûÉÍÍV‰bŒuFÇzµâs¦Òî³u:挱Ѥ(Êá!¥GìÂ"Ö„­Ad’ÄÜ%Í%\Ë¢_¶2.2ØÙ&¨þllm@z:¢éìXˆÃÚm&ú4;0ó.œèPÜ!6ƒ¶Ø,VÛ눟Ø#~ãgû"ÐH‚]º)†-‰Lz	ßz›Ú‚Ùî
-òëü1Ep”–¾ ±Àï\lçÒ¹A¢LenÈôúòÒ0ñËÝ5ó;û»º«^î€Ï©™–Ë|ý4\ï2H¸ŸàJlĽËôŽ´KNýÍGaÀt²Uämî•Ë&³vÓ×ÁØ@µ[Îùè¬Óš˜>ùÌ-òõ@	7V.œ¹xžÏTu^ô£å0×è)U`5•µ-7.,a„æø
Óƒé
-ú¬[äŒô:£ ]¡Q
-ÜÛ¡$„}sÛ# Nw¤Ão¨5_ òá£ÅÕxZMíÔÝbvÃÏAÉr÷ït0ˆŒ«$Ä‘ÈøN%ÁN®aý8î*Õ裋1–PÀºøà}×áÇQš
-oåaíÌED´&Έ¸ÿ lV£-yê¾/{ð_yÕþƒ°-Å\¢œÑ¼Ê–tùÓ	»|ÓBpÑ–3û²´çË>Œñs¼ÀwxìøÅàêµ_ýõ_>ƶÚ.Ân·sÏîRH½L<»¹ÿ<ðùÕÿäoendstream
+xÚµY[sÛ¶~÷¯Ðƒ¤™Æ• û¦ÚrŽ:¶œ£¨Í™¦y %(âŒD*"×ÿ¾, ‘ã*Íéd&X‹Åîb/`Ö£ðõE¨HeO§’(ÊTo¾¹ ½Ïðííó´‚µû-›…´-4´*(CRªþã€CY°ºËØõ;iË…+Û\ü\Y ÏÓÊØÊ…“è Ž.€¡Xv,NXðÐÙº*ýþ>ï‚rÞÄBÁM	åÑ¢ÐÊ¢EѯpòJ*RåGPoã×Î\²“sTí0aª¨j<·½Y ì̳g8,Ì@@Ï3t=}Ñqr뮓þrWnrÁd	LoÌ<“•e²z¿3ØÓt¥FkÇI%‘)`DaÑÈÕË~[gT
+óÑÊþXmjàÓÉ÷¶ªu`“*ܵöNÅ	8Íîþ=`j…ŸB?-@¦!Ýf™í×uT×ëŽã„p)Ù¹¸ô;$,„¾÷ߤ4Ï!Œ4€ ¼Žøc6PÂ~¥¼_"}g½ç¨?¨¢`<'–.ú€¨ö•ù²ÇΞ†Þ6/ݸ¨pÒ!&Gí‹…±å±p`Êî7»« ç$Døovël7¾XŠõ³ä„i›¬Á˜VjùŸ},Ј3©e"b©q¦ÅŠEõ»OÓgÇ£æ§GÍ^À¤¦I:ú6
„ÅMÇ=­2
+ò"4Æh|íØöñÆ{ŸU®ì»«kÐÅèÏÚ”“Ÿ î°.¼|;šŒà^.ýÿ¯jèÔÚå4˜c€ïT„üiœÍzUuÁ-NÊÏMŽî§ø7¶uVuiÄ¡Ý':m¦ÙË+)¨œëç­7p×i „ó†üÿWÒÿÅAÁ¥*…ÊŸ¶{ǵë'ZÅ¢à\¹{RWó¸?÷¶68ŸáP™]nü"—¨0"gUîá48­V:^}ìâbýŒÔn À²t±¿—x!Û “ÍW~ÂK>ú¥Yc‰“Aç·D]¹«[Múo]%	‹øhn7qŒ !ÖÞgvÆúÌŽ&€ôŒôgSX<¯ËZ;
—Á
+)‡IàÓ‰ŸìGœü²Ï‘hí£¡$o·¥½C9‰ûG$®¸l.†[Vå±T0¤eý¬ÍçÌ•C‘«æ»üñ•"Ç´/B×6™ÖøH_on¦d8}g9ò¤ãÙ‚¾[qu/Zp×8ÁICîtÁ,‚3ÿÆ"îà0y#>Ž]^ÇÎ7$/O^Ü.	í®°M‹Bï°§×ZìŸø
+ðŠ7°9Yt¹ Ã*ö
«Ø÷
+⯺‡½&¨áä;óøø™BùyBÑdBº
°¼óLðœßد	ƒ–ª´„ë#L
öÌ,kª_¼'ÿ³UW€ðyþ= ¬xÚFE	•)NA;ãŒ!8A€š4Àirh‰'Dý«’ËŽ8Áªj	[UíXŽÐØ]`¢~*‘Dº©l‚[dUg»:‚ËÞÖ¯Úáxœ¿0µµ/±°/(jå7±hnWÕ]ácw±ø3ņÑÖù7¶î1+Àª›Ú̶͆Ï|@¸
+#³¨WÅýázlSTÒKô&¤áQÍ}¢7ûÊË|4]1½-«Ü½“¸TGy—ýÆ	þXPHî.I/RêM»þÐAÐ÷‡ÿ¬Ò¸:j"’„7ߢšÏÂo¥Úª-ý_5qâŽð÷ÏÕPý/î?n5endstream
 endobj
-1468 0 obj <<
+1481 0 obj <<
 /Type /Page
-/Contents 1469 0 R
-/Resources 1467 0 R
+/Contents 1482 0 R
+/Resources 1480 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
+/Parent 1449 0 R
 >> endobj
-1470 0 obj <<
-/D [1468 0 R /XYZ 56.6929 794.5015 null]
+1483 0 obj <<
+/D [1481 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1471 0 obj <<
-/D [1468 0 R /XYZ 56.6929 586.2823 null]
+514 0 obj <<
+/D [1481 0 R /XYZ 85.0394 720.5366 null]
 >> endobj
-1472 0 obj <<
-/D [1468 0 R /XYZ 56.6929 574.3272 null]
+1484 0 obj <<
+/D [1481 0 R /XYZ 85.0394 694.4596 null]
 >> endobj
-522 0 obj <<
-/D [1468 0 R /XYZ 56.6929 166.8772 null]
+518 0 obj <<
+/D [1481 0 R /XYZ 85.0394 472.8118 null]
 >> endobj
-1307 0 obj <<
-/D [1468 0 R /XYZ 56.6929 140.1236 null]
+1485 0 obj <<
+/D [1481 0 R /XYZ 85.0394 450.5356 null]
 >> endobj
-1467 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
+522 0 obj <<
+/D [1481 0 R /XYZ 85.0394 369.5968 null]
+>> endobj
+1486 0 obj <<
+/D [1481 0 R /XYZ 85.0394 342.4358 null]
 >> endobj
-1475 0 obj <<
-/Length 1085      
-/Filter /FlateDecode
->>
-stream
-xÚ¥VKÛ6¾ûWè(Ç(QÇÍÖ›:(vÛ{i’mѶ°zU’³q}‡J~¬ƒ¢(ÎŒ†óüfLPøc’„Š,Ò,&’2lª
vðíÃŒyhTŠÎµÞ¯fïDd$Kx¬¶g¶¡J±`•ï¹ûmµxžG\Ò0!óH&4|¿|ü%÷OË<ßÍÓ8\-ŸQü¼xXÍ~Ÿž}uWo•I
-E¤âé:qq«N2#‰€O¶N;S›N&ŸG"‰Ã/TÒb‹ô0gá¾è‘Ù6]¥¤GYßšMñ…R>Þ^í)ÂaoleÀ?;óéÙèRˆÚz®t?˜Î^/MäÍ㥋 9áTwšv(š‚dèðuoêž’˜P'þR­+ð­i“„¥Êk凪õyÙðñwS»D‚H(h€â*ˆ#™”ÜÝÙ4õ`ê¡G@è-䃤»è¨¡Óu¿å?]Üx©mËcQïk»bT9´9´¥'Î?¿)É`ý.¡CœÆ¡ÆÃ{£¶}¶šHõ…Òº¨uwDzl¦¥kcòÉJ×]zºÉ]k7ÚVü'2ÃÉM×{¦:ŒÔÚy–¶,ß;¦s°²¥IÎ`¾“37qœòuuÆaþž`*ÓDžw9Ú4U[”flÜUÇa<2Å„¿ºqƒ-
ïJŒL¡ Ó÷X+`/²~ßÊéÍK&áÐ ïÀãÈ)슭¡TÐúb³¿0ãÆ _!Ó+€
NÖO¶¶ca-¼îý÷©Í@û²Zéñ¤vk0ÉbÊÿc%™—•ôˆÞé¢FØF\)¢$lkßÔ©ß•d¾ÛÛ³SL";aNT&˜wÐé×ApF¸ c;§
6½éOÖQ›áµé^Y/†qc*Ìí€ZÖeáˆoM‘{ÚélöÅ`6ÃÁ1&ÊMkê¦u`Xµ×.‹]aþ
-~¸ˆ/›Z¹K<æaßà9ìµ—ãiG2¡î‘¯4@µM7èµràÆïmÓ÷ÅAÇWf¸Ý+•îŠòˆ¬ù›1d½û(ÖÞ&Ï)ê¾ÈÍ£Áz€‡öVi.Sì°Û+˜¬$IÂem·©º(u’9·VÁ@J(Ó(Â…fãB³Ò¢öov‘0Eÿ†˜„ÆoF›TúÅ\Ärª·®õæåÐú|¶§xœ`šsø©v-°_¡8
-<%ŒÉør³!˜ìüX0]
µŸõ«	Ÿvü­ñï@0âu46-Z`Ð]‹G8tKüè#$±oø÷íþßOœÓ3/Ná7VñÛ¯A¢x–ŽAÙê)qùôzú?ro«³endstream
-endobj
-1474 0 obj <<
-/Type /Page
-/Contents 1475 0 R
-/Resources 1473 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
+1487 0 obj <<
+/D [1481 0 R /XYZ 85.0394 134.5831 null]
 >> endobj
-1476 0 obj <<
-/D [1474 0 R /XYZ 85.0394 794.5015 null]
+1488 0 obj <<
+/D [1481 0 R /XYZ 85.0394 122.628 null]
 >> endobj
-1473 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+1480 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F21 662 0 R /F23 686 0 R /F53 967 0 R /F62 1000 0 R /F63 1003 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1479 0 obj <<
-/Length 69        
+1491 0 obj <<
+/Length 3327      
 /Filter /FlateDecode
 >>
 stream
-xÚ3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream
+xÚåZKsÛȾëWðàª@U"2/`0G­Wv´µ+od¥*¯ ‰(ƒC€’¹¿~»§gð(­ãäé€Á`=ýüº‡|ÁàŸ/¢8Œ0mT1-ÖÛ3¶x€oïϸ³ôƒ–ÃQ?ÜýõÔšXÄ‹»ûÁZIÈ’„/î²OAÊðV`Á¿>Ü\/EÄ‚w×?C‹K‰àíß.½»º¥±úÃõÍÔcèñöÃÍ»ë÷ÿ¸½<×*¸»þpCÝ·Wï®n¯nÞ^¾ûéìê®#yx,Î$Òûï³OŸÙ"ƒÓýtÆBi’hñ/,äƈÅöLE2Œ””¾§<ûxö÷nÁÁW;uŽMJÈ0‘\,¹‘a¢_Ø–¶`°­kòX‡R5Ùv™ÀA8ÖÇŒÁâIÏzÁ¬7"4‰^èÈ„±Òr¾Ü4È)#µ
+MáÞ8ænS4çKÉYåÍz_¬rûʃv“SýTå{ê«Ò­ï¼ŸŒÚŸó$È›ú`ëœ>SﺶÏÌmÔÖô\¹Ak•¶y"½@Ù’s"I¼¬Ž8PMQ=”¹;Òðð•V±;Ò›™C' IâüÆ"–Õe™îýºôq÷vܮ겡—§¢Ýµñ¬Ï÷æ
+\wüœç9ñ8‘Ó´{8	-šÒáé…Ú»2]ç™åÄR+W|Ì‘0D脸/´Š6ߧ-°Ùv?¦å!C’FwçF5õ?ä-5Ršõ†Þð|£ÕêC»;´ð’DÁ±>Ðç*¢ì÷Ö­
+“îò~òsæt’ä/HFÄ`ŸÄ™CCŒiÄÇ*]iÊ´ÙÐT®†Sy˜Ä±ç|5³8¨zÂýâp ©L‡áÌb"5Éd1>]L½ d£ÝБ)
ö5Ç¡CØzQa-~À6=7ê][ÔUZ–îÝš<ïA›ë'”í=’ò K1jª<Û:+~cLäû†ò´)Öl‚ÝnÒê!§n2mh€­ƒZÞ7¨=ø~oÕ´ÞÒ”nX§ƒà ‘ÕZv›2sÛY»¡fZes†¾JT[
~ý òœ=FLÅÄ ´-‘‘ÖöÜ0Í¿¥3âåš…,æ^YîgYn$>¢Ìï[Zqµ“t.6*¶Û<+Àa•nGàÿÒñ\Ã2ôh¤ø «ØB‰–¢Lñè%€ð€!•¤Íœ+â*„¯1âÂHCïOé¸ÐþÓ…•Þ§ÑçÏ3+Ø;Ž´›ùð'¬C2¼³.˜’M·»2¿˜!)ŽB.;ßyòTêÏžj)Ø…¼Èæ\€	¥|á#	4‡•¹€m×cenAeZÐ\ÁD >åÀr°—ü-t¯{Ríª¥/Ö£ÿå"ØA¬ðët3\´=”nBê¤ô9Ë×Å6-©Ïº÷þÛï9±œ³À]šeÖ˃	vÆ‹/ïñéŒXD<@T‡aü#ÌcZ”éªÌÝh@¨}_ï·
5;Æé=v¯ˆÍºI„<ܳ<›‘I@SóÞhù…#aÝÂâ$
®%bl’'¶”¡äÚ+[=³aFÒˆÁ†èÒ´uiÖn@•»³á—%&T²3˜¯³þH©ÎšÁPf^„I¿Æ?瀠K ÑÛšÒtØíH
Ö`Ïx%Da­ì€,¿O­váK1èˆÅœóYr0ŸXƒ¡Ž4êû½»`óÖÊC&;Ý8éqÔÀã@¶qŠŸs’‡:Š£×°œŠŒ§Ñ3®WÕ-5ÒUS—‡ÖšoìAô|N’ (aüiÞ|¸½~}3w&
»=Ù=yVYAžZ÷1È9¤š,ƒ(‚¢ù	à&Ó°^YŠ(X×Û]Ú«¢,Z‹8ÓÇ<Ý—…U	è~„(
Ȥ™sà\ë01¦‹msÁKÈ‚†§Âš¶(KZß'Uñ;ÁœÈ:=|UVøèaˆ™XŽO¾†3Øè‹>ˆ¥E+Îû¼¡‡u”C‘§©¥Ò@7R;ÌȾ3˨JÌP@IÔFß²¦Ÿq*qŒbêX¾˜7Fð‘1¤)mùjÞøq>Î:TAå2AÛ(¶ù²­—eñèzlðP¬òWˆm¤QϲD‡
¬¥ÂW²,h4Ý–™ß’<Ñ4Š=YµA	®r/ÚM¾/ZÚ\š1¶ˆS^!îî~ÍK«µµ?O‚C™7áëÉβ–9ÿ!TÈ"ã}ŒƒÂS“$io1óò篔ôòX§ÕøÈàgÈÅûC{õÎÁ‚Ñl­†ËsÚO+ú@ƒ¾O'ÿ§j.p3úåúHA¶9Ñ‹zIÓ#Â"éæÛ>ÂGƒoC‡þçÚ_pøöд4r›¶ë
u¶ùõ~¯«|N×;@À£y®`7ÿgj;Јÿ–Þ
+	k³o1?ã¤Þ2Ä)Z¼¬·€à8Î?wù«j{Ù’Ží\®`“É}Â_êʦ¯ÐÕ¬÷VYñ®ßЗAyJ¿ÞÝ^P÷Û›Ë_®.¨÷Ç®—³<øsÑ·rR½ùø‚Øù>÷bóä|C¤v3N‰MÁÚL¾,5ept[.ìMÈN˜m=@—ø9Dv=^Éêmê-p›Í½®'¦N®×yÓxûiŠ-¤f{µw¶=-ÁÙ¾[½úªùkexœ£™ž”áÿ³YžÄ… Q€!IIm†åûge|¡!õJàüK‹P«(î¥,g®;”Ra‚µC*¨çóž ŸñøýÕÍÕ­Mœï®æ’Z`?“Þf…‹-!ª¼vô·%ù×6¯‰Oì@jHºoÇ)}‡€À9¼›eƒNWðÙ=fô)Áb°rÍpëÐHHL➞īoÞLq>g
+¹]s‚ús¼ýùòãÇQ}bÅ:Ÿcƒ¸rΙîî ôù’3Æ‚Ë,+†›¼+üÁÞÙƒÍÙ&,ñÏ(NÀáo$å–¢7{¯!Ýa°1f¨ýò9Ø€ô|DÏÙ‰»›Lüi&k¦]26ØÑ] ¸MlöÏì°ÝÇ‘<±Eòlæ²?{ÝiUMñ›D)¢–HF½†K3ª4°©®¿OŸæ@Gmé«°ªËá\.7È’©Æ
i^_[f}©#3ˆ³§Õ‘z=Y>¥Çª¨Òýq8Þ¥@ŸàZŒÃ—»•éãh—<n)ÿâAâ—N·²´M½qÙÔaÝú"˜6œ–s\tö@VGŸwàÛ6ÝN¸¾bëÜýãól¦¬Ó¬ï-†‰þÀN©üj¨6hl­qk#¤[ùþ1ïªù¬äœ´:§`\•ÑªÛcåÐP_ÜN(ƒhâ‰vØÅzæ_øð`M°w«é¹rTQ7¼ê­p Ggƒ³‡qeŠ„Ë™[7ИùÒUW¦Æ-±~ÞÅc÷iÀWaïåaìÜEH¼&Ée‰ÆRäèKŽþÕÊƶk÷¼ŸLÉŽ@D±¦$uKºôÀÙ„~h\´ÅÚ^+9;°Ï \Î?`®Œ•­kbÊm›©X#ƒ—ή¡íûF¹;vØ»šXžºT5f »û¯¬Š$´ì
vZ/¡`‰ŸC‘ÄhaçM>w©cZÓ][±Í,-AT\ûËAt¬î\ä—¡ÑågK™>I¦7@ >ˆÌ­Û÷­ÏeúÛîÓª¹ä8TqGºiÒnW;£[õC;ð3®&Ñ›8Á[Ea¤LùݘêÚtEÐ
òîÛBo€j‚ª’
aÛ•‡±ÌVWöÚB’–¹mö{qY.nawÆ
+cõº“Sò=¨J559½Á:zÜǹ\ã„>á}üÆ9¨AŒ,è’ÊK‚H›xé	#¨¯ÙÔºDÑÁƒÅÞ±ÃàÚ{kmOH-’Š‰¿˜,CÖ	ç…4{¢`m§'>•FÞzÆ#:1;Lçzý°9ÄLK1ñœä2sÒiô$5¡¿Eƒd=’z¬¾—e'À’³ä'‚`ôÄHþðß'§ÈÖ<46וþ·,Шòö©Þ¡—Õ±uÝ}ÕÁ¾Ò6ë"skÚ[oŠ6ïBý2Ëmu¾r;(°£Ëâ¡r¥ëD…\æ	uKW‚JMíoS×Sø§-ÀJº„÷íÁ*
´?ºK9%ºï»ºiŠ)™R“e<(,ÈPr]¼U.Þ*oáyhü—²Ž,ïo¸-Iý½%¿ûéÎÔ`›#øö-Þ?Å1ë8±:6„_¡ˆ±)ö¥Ôå -tx‡†½ÃÆæ„€o	#Î_Õ˜˜©g‹Z|
›lÓ/ùˆ–žß؉¿\9ìÜyî{zlGgçÉZàWW͆¨¬!u‰ÔEû¡«ž‘Q;[ŸXø0k{fþÏÓ½ÞÑvˆs€z­SOýβ-*=÷³8¶ð*ýÝ?Â눨ìe¼˜OÌ»ÞS…üKÔ3Ú9¯‹9âÿ–2:æendstream
 endobj
-1478 0 obj <<
+1490 0 obj <<
 /Type /Page
-/Contents 1479 0 R
-/Resources 1477 0 R
+/Contents 1491 0 R
+/Resources 1489 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
+/Parent 1449 0 R
 >> endobj
-1480 0 obj <<
-/D [1478 0 R /XYZ 56.6929 794.5015 null]
+1492 0 obj <<
+/D [1490 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1477 0 obj <<
-/ProcSet [ /PDF ]
+526 0 obj <<
+/D [1490 0 R /XYZ 56.6929 408.8853 null]
 >> endobj
-1483 0 obj <<
-/Length 1368      
+1314 0 obj <<
+/D [1490 0 R /XYZ 56.6929 384.5457 null]
+>> endobj
+1489 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F14 689 0 R /F39 868 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1495 0 obj <<
+/Length 1371      
 /Filter /FlateDecode
 >>
 stream
-xÚ•]oÛ6ð=¿ÂÈ“Ä)ês}jÓvëPCã>­{ eÚ*‰šD%͆þ÷ñx¤,Ǫ·À0t<ïŽ÷M¶ æÇYL(Ï£EšG$¦,^õ]ìÍÞÏWÌÑD1'qĹYÌì®bž‘8ÓÅjÊäÍúêö}È!%IÆ‹õn”•¤)ÉÒ8_¬·wÑjÙ-WaLƒtùçúW<‘4K£FDB²(Ïì7~{‹Ô9~îe1t¥~ÂÕjúr+;¡KüXDx”„Ž_‘Œå¨@JØrÅ(¥Áë¢}?²Ñªpñ±ìµgÅ9É“0qœ8%!Óñ|Œç—,Gäxؽ/4¦¯ï>öæËn•ÂÒJÜÛ-.‘YÔBÜ«ŽlôAhÜR¢
-Ñ ÐK·5´Žg³E )‹¯¨¨ên7èaªÃÐ; lFž\œ1’Çqh/.ªJ=®¥ËÝÓŒ™Œ÷¢(MÍ) ¾™á‘G\ú}u[ÉSê›RãU+»Êõ%Ѷçþ„1Áó³v’G	¶“Û[ã/
-ýM#I_P¾†c[¯7j?ôÔý5"°KôXVB›J_üôþŽ™‹ã¢oE!OÓ¨bc)d5@´æÜN8Ü8y‡º€`Døª®Uv°÷éý±²ñÇ•ÚÙдÒЗd® ˆÂßÅß—ÿXâÈ!MNPb·Ù+$eÏÖáóý0æFžÄŒ%HÄ_ÍÙ‰ÉHM‰N,Š…¾,É™ ŸÕ¬ÆßG!!'9£ü…qQ˜²ïMl¢f"Îï²­ÀÙ.F¼ƒ°t"nt°p¦†‚iÃm¨7²û¿xyÞ-öóØßÑ #‚9Ä÷Ws\U‹ÓÜÄÅÞì'ö'dV© §ƒÆTK¯úTb³ƒÅ\Tê8_L9ŽQ~Q'ÏrõÌ8—¢éoÕ8Q×®´“¥×LÜôSëÎÕ¢7{öŽ»Òß㺾²¿`ÒsˆæéôÚ—î7;¢5um#3>NDc½·ž„IP …ía°€2ÏY„9ˆ±-x‡¥¾ÆÕH2vDXM…MöT„
 Âím¤lP”ï‘%aC%ÐÛ²_͆òÆ$úììò^¹®W«“¶Ö˜Ñ¿¶$×Êš´2÷§Éó.§eq¡ÇÞx„c:ŸxÈ̃/Ý@ôúóýÝ»OKóþXÏ
O¦XæÔObûPöªó}VÛÖzõn=¾Pý»“Ç^±soXO²:Òàv*–Só
óÔ3áYü\Úø>÷/“ðô¶endstream
+xÚ•W_Û6¿OÜ“4:Éòßõ©½¶[‡bÚôi݃â(‰QÛòlù®·¡ß}¢(ùì‹›í¢hêGŠ¤H‰­¨ù±UÊóh•æ‰)‹WE}EWGóíç+æd¢˜“8âÜL¾nbž‘8ÓÕf
+òz{uó.d«’$	ãÕö0êJÒ”diœ¯¶û?‚Û“hµìÖ›0¦Aºþsû+.‹Hš¥–Q£"!Y”gvÁë÷¿½Aé‡O²ºR?àìV5}¹—Ð¥¡F<%¡ÃK"’±
H	[o¥4xU²ïGÝ©
+'Ê^{(¾ÊIž„‰C┄> endobj
-1484 0 obj <<
-/D [1482 0 R /XYZ 85.0394 794.5015 null]
+1496 0 obj <<
+/D [1494 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-526 0 obj <<
-/D [1482 0 R /XYZ 85.0394 769.5949 null]
+530 0 obj <<
+/D [1494 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1485 0 obj <<
-/D [1482 0 R /XYZ 85.0394 574.5824 null]
+1497 0 obj <<
+/D [1494 0 R /XYZ 85.0394 574.5824 null]
 >> endobj
-530 0 obj <<
-/D [1482 0 R /XYZ 85.0394 574.5824 null]
+534 0 obj <<
+/D [1494 0 R /XYZ 85.0394 574.5824 null]
 >> endobj
-1486 0 obj <<
-/D [1482 0 R /XYZ 85.0394 544.7049 null]
+1498 0 obj <<
+/D [1494 0 R /XYZ 85.0394 544.7049 null]
 >> endobj
-1481 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
+1493 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R /F47 884 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1490 0 obj <<
-/Length 3343      
+1502 0 obj <<
+/Length 3356      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥Z[oÛV~÷¯ÐÛÒ€Eñ\x+¸Óº»Hº‰ŒÝ¢íEKÜP¤BRVÕ_¿3gæP”D7Š æáp8ç2·o†³þ‰YùQ*ÓYœj?D8Ë·7Ál
Ͼ¿Ì3wLó1×·Ë›Å[ÏR?d4[>d%~$b¶,~ñb_ú·¿-\¼Æ¼2ðC©@<ò|÷Ç÷ï—Äu&Q'¾‰d¶ûwo¦$E¾TB3ÏLJåÓã›	QBÀ¢´Š†)ïZ>|¸Ë0€5ÞÂïÛG˜ÁRRº||øîéÃãògºûîý»o>ÜßÆÚ[>ÂÎsó°Nj|š"PxLŸo~ù-˜p¨?Þ¾J“pv€›Ài*gÛ*?ÔJ9Juóñæ߃ÀÑSûê¤vD'É	õ1¥ž0õ#‡çð÷Ë-DÚ×ZÄ'.;%=ý4s£ž¦w/ÌÇoq¤£Ù¯äâìÏýî›ÅþúÙ¾ËMÛûM»†ñb·_-˜´ÈŠ—²kÚãâþ_sÐSàÁ9¥~h¿¨»Ëåkçòlý_ÒôÓ$I¦50$~aƒ %_„Ç[4×+…¤W'|¡ÔëzÖ3¥^KÃiÿA ÅLh_i°
`+0Ø|‚{òµBç ·s`ß›¶iz²õ¬.ØL¿/–§F3 0ðƒ(Œ¬˜÷5ð'¡÷ôîñ¿8Š¼Î´/¦íîà.Õ^Ùµìˆo×t]¹ªQû†¨ímâík¢±7µdÙ-CŸ¹¿ˆ}Ô¹u¾ioEâÁ6ÌÔšUä‡iì˜MýR{½5uOsü„Á¾+ë5/lc†³“ ò=įܾ	ÿÅÔ¼‰/£ eöç}÷eS[f;éêˆ/¡†R_RÏæBøiJËßíL^>íš”RvM0Þ¯RjucKŒ?‘±‹tó~bA$^0‹•cE7;\†Ã0ñ–TN”g5=ߘjG£r»£³{1DèŽ]o¶Äß™|ß–ý‘ž¬øº«²œ7!Y»VËÎN›êÀüVÍï8¼£“I¤æÜÁPn9lÊ|Cfz(«ŠFU¹-ÙˆíAá È¶ÙÚ›šGå3Û:]È^ùQG×¼qÛÜ–)l&Cˇd’Ä9Ð}ÝÀDø¢¼}gž÷¸-¼g“õ{û¶¡‡ÖŽá­ì,@™…×ÁáÓ}óLì@±KÒnS@ÈVeeÏØRº4ž¦ÈÌÖ	ÎXLÆ÷ûz×–/eeÖä1vw#ãƒ
ñ™ }OX›„¢âÐYÛžXÂ3kÃØ:ó·¯Mò¸‹×+T"ðþs›J5Öí×kÓ±vi«5¹*ª±s¡‹®g;#Ê°—ÃÆ8®n0íë2!=ˆäÌק|\ø2–‡Œtï³oƒ¥’ȶ|?g J¤VÇxµîWó{¶ÝUülqkÃ2ÞTeÍdÔ¼¥4?c×±%Ëɦö¥ a¤Z}žÒ0uúeϼ›I%“·xÉÚEm'ã0(W&±c½CǼaonGlË×3’	“Ľ>LyMJ€Ki|?_Ka¿â²	ɱ.tf%2ßpÊIF¯ÍÝ{gš\ì»vQ5yV-VeÍ[ŸGWÁ'ìÄ1¡§ëÕ‰Ù°nJ°˜7b5iÁ™zé[>JÙ˜Î8•M¦kð0%ãØJ{ËÐ2ök~îXËÈ{nZ¢OYLC^â‹v †Üx•dQ:5NwhÚODá(»3mu¤geíVBYÛ—ù¾Êx¥I5yÐX0@
`×¹›ˆX
-¬$ ƒU‚3åGax‘~_3b™úI§£ˆ…†Kï؀•N8)á¨6h8²Æ
W0Jì1¡ê˜|î¯̾µÉxTÖyµ/LÇÌ7Žý†²*ܳëƒ8œ±;Ÿ’üÉGÛÓÞ[Nk´s·—³ôŠÂþ†A5M®•v-`|65é¥4ŒÍSG8&NRñ5± ‚ÌÆ.n–<aœ£<á9"»¹)µÁà× •!ì;Ó[~ÆE¡
-ð9«‘
-ìË
]³âû®¿˜ï%«ö¦f³§#"+îÏì‚°RçPÇ'3];OÛ”‘;°^¶ÜëApŽ“'FÅ	šúêth»²˜ÓAL¹cèGItã²'Î21¼ÂÚ©¶	±ßQ¡Czê6;7ŸcbÁå2´Ì&ÌÝ`>õº»ô‚óÒRˆp	wQ˜—Ŧm¦‚òãtèüL…¨LEµà+Ð.CL!Fé/	ScaU³žòMLA|.®VžÀÅšàË4}Nè /·Snš(tS·a
-€M)_ÄQr
\	ÿtŽf¹®±ðÇŽßréùgêùŸÚ²iÇn$Ï7××.•>¤Âèk\*uŽGŠ
-ñÍ7-?†bBÊS@ÛC	8‘œAQQà‚è¾J%aa‚ÛR¾ÉêµqtA-â£é:®˜l+ˆÛ¦(‘)Ïú¡NCmv®ê‡”`jJ_fŠöOŒ”ªTÕ¦´£¤ŸÊH]í‡ë2ן´B³Î`?·¢5çÁeÁ=	7µo3,‹m\ý4TÞ8–¹„rê£ümÙS!4Õ.U?"¬¾¦_*à$RÀh“Ý:0b1aE¯Ë¢÷ÅC÷ÆEãoèzËPúAYÂuà@3#·p b0x% ‚Õ’°Ó»‘ÃHêù¡*Ä÷€Ã„·„¿Ò{¸êÂâŒ23áA"pêÙç™ð¦Š˜Fc»×ÓXÂâq+goØÑl´)'x>–l7±gäÄ	 ( ƒA ‘T3¼kz’´ƒ£0Â
-QØ´£³À›ÐÉ^Å‚³É¡H—g±€¥wtká{’Ù'ŠP3Üc±o™N¿%£õƒýÝQ/¡äU;T¨- °ƒ•aà@æQJ{p¶º•ÔЧbÔx…:¯8§@Q|ºiM×ó¢òÞ0çÎ(àÝÛ&JØ°pë¯
-€è­=B	Áb+Ë|nDu•£àÔ±±þ5ûGO:8ÀéãÃ_óαK	‚lƒKµªŸÀJ­9Ï)ÎroŽ`JeN¡åiWd½qÍjî;~±]}Ï^	Åý×WÒ+œ|¤îY>ŽŸ³œ/Þu›f_4^ñ« qPvŶ‰Úšƒ«Úš©`ÆN€!`Æ+æѪàY]§pØÁ¶Tq]£½¢áû
US`ï¶7¤UÖQ¤(¾§Ú•RÊ{ü‰YQFíø%*º”ãÔÞ¦¡²I&5Ÿ¡bbX9f£“»cÿâEVåÀª©U÷ÊÔ;¥¬…^ÖSç@†P™Þ
-\Tü·”Ã'ºm¶†É«üØ×qêðÀöæ0gUOÖ¨I2ı?¸ƒœœÚåJ…Ü.GòÖô›¦àe0
Š4N×

-@µÜœÖh¹»†X܃s]àŒ®$Áý"pó³Šå$ƒÑâøé
žnˆ-”üáƒdX–ɺÒ20~¦fÐÚ,väï«®áoúa©™ñ|¶ø˜´x¾hÃÓØó¥6lB¦ðªfTª|)høÍÌö‰Ú¦±$Û1¡Z,ÎOÖÊñ]º*{aÖáÃv¬ø`G
-ìÍ´phÛŽ0[4A™=ÔÇ]–³cDøµi]_):bÂbbùññ{þƒlKòxxXZ“ôk15µ8úꘚŠÁ͇…i\^ÅÉ1]Õ¦?Z¬hŸÌ‘5ø"8®ð¶è”´ÌÐu‹n¤-/¿«NØ–«s\}4Ê4÷¨Í1¦ãÏS÷cùb`}B×l8UŸN(פcšïšªÌÓ-Œ0~½2œ–u¬N_ñz©úøs’‰ŸCMó—µrÂy@[’Èqå4®Ñ_' „…;K¢«•»Ÿ·\/ýÿí-JOendstream
+xÚ¥ZmÛFþ¾¿ÂßN¬eÍ‹ÞŠÃÛ&i·wHz‰ƒ»¢íYžµu‘%G’wëþú#‡œ±lk›EÕˆ¢8œ¾<¤,fü³8	“\æ³4×a‰xVîn¢Ùž}#˜gî˜æc®o—7‹7*åažÈd¶|ÉÊÂ(ËÄl¹þ%HCÞþ¶üqñ&óÊ(Œ¥ñÈóÝïß½[×™D…Zd’Ùîß¾š’”„R	Í<^/?>¼š%(¥U⧼ÿiùúýí\ÆèxkŒ‚o`KÉéòáõwß?,¦»ïÞ½ýððêõûûÛT˸Ãyn^/ýNwSD
+·éóÍ/¿E³5lê7Q¨ò,ž=ÃMŠ<—³ÝŽUk¥¥¾ùpóo/pôÔ¾:y:"‚HäÄñ1uŠ.‹†æÛšzO£j·§³xâÅõÇ~0;zØ›òÐUÑîVGâØ×Eé7…¬ÅJbýÚSðÝTIÝž
+¿äŒ|ÕþŽÃ;2öçmUnyXÕ5êjW±WØÇÁºØ7nUì±þ°Ù˜žO—–Úïã1ö.ÒõleDñkyÞÇÕ{ÓÁC¦1ä‘)¡L¥6£³9X€¥²Ä¶|?g JäöŒñjý
®æ÷b·¯ù!ØâÎÆy¼©«†Éxò–ÒüŒ}ÄV,§˜Z—‚”kõëÊãÜ/;áÝ„@ÈR‘Œœ¼ÅSÑ-^Š7p¸2K+x³RIà×æVĶ<Ôâ,S—A
¥”€¿òô" ¿”!쥤'’c]èÌJd$¿á–^›»÷ÎNrqè»EÝ–E½èWUÃk‡H¡SØ+ÈcÂ@׫M>ÔsÊÆL”*Íçþ¥‹lå¼ÆÉÉq€‹)™¦VÚ˜†–B¬ý­qÉZ&6‹Xú”É$i˜I!¾h1`ÊgÛ«´Òq¯qºç¶ûD³{ÓÕGzV5Nb(º¡*uÁš®Iª)›Ä‚Ê/€}çn"d)0“̃{Î~T˜ÄñEBÉŠefYšBZr*ƒc{ œFY	GAcÀ‘µnL˜f ÁSjÁ‰ðjÃì[Û‚GUSÖ‡µáÔl q‡-çÕl”WqÆþ|Jr(›Þuð†ó­Ü­å,뢰¿aTÍs€•ÕŒÏæ& =UæƒóÔ2J³\|M0Hd˜Æ©œÏG¨)Â0O‘ÈnnÊm0ø5Šdm}ÀÊtœ?£RxøœÑØ—[ºëÿúáb¾§¢>˜ÞÏF $Á¸ùþÌ.}õv|2£Ñµó¤°L™¸ëe˽Þ„û8qbXœ€´y¨N›¶¯ÖsÚˆ)wŒÃ$K.‚\Q–í¡áÀa}†2`Õ‡‡AŒÙêcÃËàð\
[‚¦èêŠ2=ïŠfS*ZÒ
­sXÈrÜW-룓5Q0hP?Nÿf2âàI}>áƒFĨa\U¿p*±Œ¿ˆTb¾ è‡bkÞ´ÃwðˆV¡¢%ÉE.Ú¶PÃóøª+ºÊ\†˜ÅFb|Bž¡Ý>Åy£<~hŸÑû±»[›¥Å÷¦Yž~ù@ì8ËÄð
+ºSµ1f¿£Ò‰Î¨»âHܼ™E—ÐÐF0›1÷Þ|šMéçŤá2îbmž˜®‚*LsßKš
+1a™‹êÀW( ]†˜BŒÒ_¦ÆÂêv3囘£ô„\\õ=Œ5á=–i†’àÁPí¦Ü4Sè¦Ò×`€lJ…"M²k`àšÏá,6ÿØñ.fÿ P‡à§®j»±ÉsÄÍƵKåQ©0ù—ÊãQ…b#„BFóMËO¡šòÐPN$g8¨$rAô0øZIX˜à–Tn‹fcÝFPK‡øhúžK&Û\â®]WÈTƒ/Ôð4{×G€”`jJ_fŠîO+ŒU{TÕ>OŽ’a.uµ.Ì\\÷>éOÿg
ÀzN£
çÁÕš»0n'ÞfXÛ^•Þ8V¸„rêÌzþ®¨šjÀ*€	O_Ó°9`´Éþ1„˜8O’—eÑ{Èâ¡{㢕èûè2–a”B–p==8™‘[8P)¼PÂjIØéíèãDêC…±ò%â;Àa"XÂ_¼¾êëâŒ23áQ&pêÙç™#犘Fc»ÖÓXÂâa'g¯ZXÑl´('x>–l±gäÄ ( ƒA ‘T3¼m’´ƒ£0Â&
+QØ´“³À›ÑÎ^Å‚³É¡lùŒcKïé
+Ö*b{RØ'ŠP3Ücµo™N%¿%£õƒýÝQ3¡b­*ÔPØÁÊ0ð‰ ó(¥Î=¸XÝJHjèS)j¼B·>§@U|ÏtÓ™~`¥ÊÁ0çÞ(à=ÝÛ.Jزpë¯
+€è­ŒBÁb+ë|îDõ©“àÔ±±þ5ûGO:8ÀésÆ_óαK	‚lޥΚߎOF`%‘Öœçg¹WG0¥ª¤Ðòq¿.ãÚßÜyübüž¼ŠŠk!ƒµ“ÔËÇñcQràÅ»~Ûê5Wü*œ8vͶ‰§5Wµ57R=`ÆN€!`Æ+æ‘Vð¬©S8ìÙ¶\q]£ƒuË÷[ª¦ÀÞmsH«¢§*HQ|ϵ+¥TððŠõš0jÏ/QÑ¥§¶-•MŠ0©ùÃÊ1íÜû+YWžUS¯î…©'VJY½l ÎŒ¡2½¨Tü·”Ã'ºí¶ÆÙ‹ßÒP§¹Ã[ÛÛç9õdše>ŽýÁ-äŒK@ä*æ†9’wfضkVƒiP qºv0Pª•æ¤£åî[bqÎÏg|<õÉUn~V±³œÌ-Ž?¾Âݱ…R~"|yµLÑW¶‰é̵±!0¸¯û–w¼¼ª…ñx¦|J§x®´áiìþR6#SxñdT®B)=4üÂÉÌ=ûDmÓØF’í˜Ð
)ƒó‚µr|@—¾.ž˜ÕÀŽìH½™6m׆ÏTÞq6’êC
+ÞÐjì·6%N*í
+¨Çº)Ã/©©MaFÆà´ØÚæÈÅ0àÙ®éኩ½¯cçæ±™†fxæ\vÕw4öOùÏ+z¼FzD[&Dñjø}Û,ˆñÃâ…g“á"è%{æÛTtéPÓ‡‰Zç4é	{ûÑ·*‹r÷ÑÜôÀ7ÃЙ'¾ñ¼imN¶æÓ[”rè+zˆÝâ0íb¬oûw›> endobj
-1495 0 obj <<
+1507 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [63.4454 757.0719 452.088 767.2337]
 /Subtype/Link/A<>
 >> endobj
-1491 0 obj <<
-/D [1489 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-534 0 obj <<
-/D [1489 0 R /XYZ 56.6929 739.5018 null]
->> endobj
-1496 0 obj <<
-/D [1489 0 R /XYZ 56.6929 704.7645 null]
+1503 0 obj <<
+/D [1501 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 538 0 obj <<
-/D [1489 0 R /XYZ 56.6929 563.5308 null]
+/D [1501 0 R /XYZ 56.6929 739.5018 null]
 >> endobj
-1497 0 obj <<
-/D [1489 0 R /XYZ 56.6929 535.7626 null]
+1508 0 obj <<
+/D [1501 0 R /XYZ 56.6929 704.7645 null]
 >> endobj
 542 0 obj <<
-/D [1489 0 R /XYZ 56.6929 418.2412 null]
+/D [1501 0 R /XYZ 56.6929 563.5308 null]
 >> endobj
-1498 0 obj <<
-/D [1489 0 R /XYZ 56.6929 389.5504 null]
+1509 0 obj <<
+/D [1501 0 R /XYZ 56.6929 535.7626 null]
 >> endobj
 546 0 obj <<
-/D [1489 0 R /XYZ 56.6929 228.1296 null]
+/D [1501 0 R /XYZ 56.6929 418.2412 null]
 >> endobj
-1241 0 obj <<
-/D [1489 0 R /XYZ 56.6929 194.8993 null]
+1510 0 obj <<
+/D [1501 0 R /XYZ 56.6929 389.5504 null]
 >> endobj
-1488 0 obj <<
-/Font << /F37 747 0 R /F67 1494 0 R /F11 1304 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F53 962 0 R /F48 885 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
+550 0 obj <<
+/D [1501 0 R /XYZ 56.6929 228.1296 null]
+>> endobj
+1252 0 obj <<
+/D [1501 0 R /XYZ 56.6929 194.8993 null]
+>> endobj
+1500 0 obj <<
+/Font << /F37 751 0 R /F67 1506 0 R /F11 1321 0 R /F39 868 0 R /F21 662 0 R /F23 686 0 R /F47 884 0 R /F53 967 0 R /F48 890 0 R /F62 1000 0 R /F63 1003 0 R >>
+/XObject << /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1501 0 obj <<
+1513 0 obj <<
 /Length 533       
 /Filter /FlateDecode
 >>
 stream
 xÚ¥TM›0½ó+|©¸6Æ`³IÚ²RÓ4a«ÕxT‚Ó@6Úýõµ3·¶ôTEóÆoÞ|x€"b~	Ž	“1JeŒ9¡•[ µ9ûêQÇ	Ϥð–u—{Ÿ¿°I,“(AùË–ÀDŠòêÉÍóé"#Nü!Oˆ—Í&à‘ðXNÇ‹,4þ1[f“éb¤±Ÿga,ˆ0ñÌ)Lg£ïÙøó	P§Ôžó{oš_¹m–f»øí==T™žï=‚™
 ˜J¡­s†yÌØÙÓxKïçEðæô:4<Îæ"J¦±¡éq‰fŽìô–z«lO‰ßÕ½êÀ,7ZwÎÝkûäþ/¥và)šŒê­-¶uið[xØUE¯*8˜ØyžE_€U· ã`wXUz[€×H¶.²RZ!—{Sô7üÐŽÛôRŠ%çÑ©'ÂTÊä)…Ú{2è]·ÊÜ,#‰Ÿoê˜Çâ- ”úŸŒ‰I§Àßë]بWÕ\cÁ*uÛ›|u»vx_÷v溵¹å¬Â¥rÚÂÏæî ªö¾ê:å8úe¨ÁÝaÕÔ%ìÝQ­Àp#¶ý¬Ní_Õ¾Ð*å­î]HÓè#˜îâÀÍ9Ε‹ÿµÛŒc»›hþ®îÿÞûë!6¯¤ÑðJ›ëÄ"’é¹(;/‘~¬üò‚ü]úÑqÏendstream
 endobj
-1500 0 obj <<
+1512 0 obj <<
 /Type /Page
-/Contents 1501 0 R
-/Resources 1499 0 R
+/Contents 1513 0 R
+/Resources 1511 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
+/Parent 1499 0 R
 >> endobj
-1502 0 obj <<
-/D [1500 0 R /XYZ 85.0394 794.5015 null]
+1514 0 obj <<
+/D [1512 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1499 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R >>
+1511 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1505 0 obj <<
+1517 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream
 endobj
-1504 0 obj <<
+1516 0 obj <<
 /Type /Page
-/Contents 1505 0 R
-/Resources 1503 0 R
+/Contents 1517 0 R
+/Resources 1515 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
+/Parent 1499 0 R
 >> endobj
-1506 0 obj <<
-/D [1504 0 R /XYZ 56.6929 794.5015 null]
+1518 0 obj <<
+/D [1516 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1503 0 obj <<
+1515 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-1509 0 obj <<
+1521 0 obj <<
 /Length 1964      
 /Filter /FlateDecode
 >>
@@ -6604,84 +6653,84 @@ i	
 ¥Ìrcø-Š¼ûãËü
 “¤%œ¡i±Iæ² —â~ÚøÑŸ/¯6³Âv¡ám’rá÷Î.zïá°ú‹EØûÛxà8KQ”×ñܼÍBw1\­ýÎÆð»•s^ÀÍQŠ’säjMkç/Ú,ÜÚmR¡ÈEzís³ã¾‡êÁaWvEÊPæâ—öD¤p}ÉqQüë›2kl—*÷»roÙõÖ¿x|<ŸÏ!ïÊ£/ËGFßãn²pÇ71ÞlÔ,u×U>î­ý·­Â·ÀèªA§jW\†=?í„·Aû‡ÄD†ø,¹±Ù^dèEr\Ca—¹7ä:ŽòÖÛü¾yïî?ÃŒûendstream
 endobj
-1508 0 obj <<
+1520 0 obj <<
 /Type /Page
-/Contents 1509 0 R
-/Resources 1507 0 R
+/Contents 1521 0 R
+/Resources 1519 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
-/Annots [ 1516 0 R 1517 0 R ]
+/Parent 1499 0 R
+/Annots [ 1528 0 R 1529 0 R ]
 >> endobj
-1516 0 obj <<
+1528 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [348.3486 128.9523 463.9152 141.0119]
 /Subtype/Link/A<>
 >> endobj
-1517 0 obj <<
+1529 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [147.3629 116.9971 364.5484 129.0567]
 /Subtype/Link/A<>
 >> endobj
-1510 0 obj <<
-/D [1508 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-550 0 obj <<
-/D [1508 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1511 0 obj <<
-/D [1508 0 R /XYZ 85.0394 576.7004 null]
+1522 0 obj <<
+/D [1520 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 554 0 obj <<
-/D [1508 0 R /XYZ 85.0394 576.7004 null]
+/D [1520 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1512 0 obj <<
-/D [1508 0 R /XYZ 85.0394 548.3785 null]
+1523 0 obj <<
+/D [1520 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
 558 0 obj <<
-/D [1508 0 R /XYZ 85.0394 548.3785 null]
+/D [1520 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-1513 0 obj <<
-/D [1508 0 R /XYZ 85.0394 518.5228 null]
+1524 0 obj <<
+/D [1520 0 R /XYZ 85.0394 548.3785 null]
 >> endobj
 562 0 obj <<
-/D [1508 0 R /XYZ 85.0394 460.6968 null]
+/D [1520 0 R /XYZ 85.0394 548.3785 null]
 >> endobj
-1514 0 obj <<
-/D [1508 0 R /XYZ 85.0394 425.0333 null]
+1525 0 obj <<
+/D [1520 0 R /XYZ 85.0394 518.5228 null]
 >> endobj
 566 0 obj <<
-/D [1508 0 R /XYZ 85.0394 260.2468 null]
+/D [1520 0 R /XYZ 85.0394 460.6968 null]
 >> endobj
-1515 0 obj <<
-/D [1508 0 R /XYZ 85.0394 224.698 null]
+1526 0 obj <<
+/D [1520 0 R /XYZ 85.0394 425.0333 null]
 >> endobj
-1507 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F11 1304 0 R /F39 863 0 R >>
+570 0 obj <<
+/D [1520 0 R /XYZ 85.0394 260.2468 null]
+>> endobj
+1527 0 obj <<
+/D [1520 0 R /XYZ 85.0394 224.698 null]
+>> endobj
+1519 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R /F11 1321 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1520 0 obj <<
+1532 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream
 endobj
-1519 0 obj <<
+1531 0 obj <<
 /Type /Page
-/Contents 1520 0 R
-/Resources 1518 0 R
+/Contents 1532 0 R
+/Resources 1530 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
+/Parent 1499 0 R
 >> endobj
-1521 0 obj <<
-/D [1519 0 R /XYZ 56.6929 794.5015 null]
+1533 0 obj <<
+/D [1531 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1518 0 obj <<
+1530 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-1524 0 obj <<
+1536 0 obj <<
 /Length 2543      
 /Filter /FlateDecode
 >>
@@ -6696,796 +6745,791 @@ R
 ÝD‘øñðñ^=:\è±æí
 ®o¬ƒñ+ñ'E\2}8Ç’;i%Ò‡ï&ª°Wõ\~jÀaÛÍ{³˜¢GË!zeoA_^†NmÞxš^Xð”Ð;’ù‚Ïr{z8Ø'"Hóȃ…×UØNÑô©|hÑçò+Å™X‡¬Yzœï_wEî”b8Iù‹Oï×WHÎÄšæÝǧñ#þði>ÀoçÁâgþe5ñÐ7þùçìÀשŸ%ÃF¨gæ½=mü‹Áßûi5¢Rendstream
 endobj
-1523 0 obj <<
+1535 0 obj <<
 /Type /Page
-/Contents 1524 0 R
-/Resources 1522 0 R
+/Contents 1536 0 R
+/Resources 1534 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
+/Parent 1541 0 R
 >> endobj
-1525 0 obj <<
-/D [1523 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-570 0 obj <<
-/D [1523 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1526 0 obj <<
-/D [1523 0 R /XYZ 85.0394 573.5449 null]
+1537 0 obj <<
+/D [1535 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 574 0 obj <<
-/D [1523 0 R /XYZ 85.0394 573.5449 null]
+/D [1535 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1527 0 obj <<
-/D [1523 0 R /XYZ 85.0394 539.0037 null]
+1538 0 obj <<
+/D [1535 0 R /XYZ 85.0394 573.5449 null]
 >> endobj
 578 0 obj <<
-/D [1523 0 R /XYZ 85.0394 539.0037 null]
+/D [1535 0 R /XYZ 85.0394 573.5449 null]
 >> endobj
-1528 0 obj <<
-/D [1523 0 R /XYZ 85.0394 510.2426 null]
+1539 0 obj <<
+/D [1535 0 R /XYZ 85.0394 539.0037 null]
 >> endobj
-1522 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R >>
+582 0 obj <<
+/D [1535 0 R /XYZ 85.0394 539.0037 null]
+>> endobj
+1540 0 obj <<
+/D [1535 0 R /XYZ 85.0394 510.2426 null]
+>> endobj
+1534 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1532 0 obj <<
-/Length 2893      
+1544 0 obj <<
+/Length 2810      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ksã¸í{~…¿Õ™‰IÔ3ÛéL.›ls×Ë¥‰;íÌíÍ”–h[]Yò‰r²¹__€õ°•½›i“&Ê›¹ðïÍÂȉR?Åià„®βݙ;ÛîÓ™Ç4K´R}·<»¼ñ,uÒÈfËõ€Wâ¸IâÍ–ùÏókÇw΃;ÿtûpûtý·ó…ºóÏ4xº½»}º}¸¹¥éýÃÝOO?^ŸÇÁ|yÿÓÃù"‰Óp~ýøxûðñþ_Ds]×BonŸÏY~v»ì$žÊsŠûëÙÏ¿¸³÷ý™ëˆ4	g¯0q/MýÙî,…BXHyö|ö÷Žák–NjÉs_Dþ„š|1¥¦0u"(TÓw÷át~2Q.ê
-'é<%Ø«Ô4hνd®J%µÊ‰¢¨ó¬ö­Ú­TCSßu]"UN ‚yH‚ïäêfÈõµ)ZE¸zMˆJɦ|ãeeÉõ^e-3³”í–—ª\~4
-hfáyN†¾9fùVT²"ŸFÒÐg[Ø>k$ŒÓ­%ya4P’~¯$œø#Ìùp
-"‡Ï®ëgýFÐ\í‰s&[ÔÂŒjp`‹1ãÄ.}Qe½ß©ª%€Ý)«+]ðq‰§µU«*YejRueêd9ø]ËcmzÂê ½7À$Ç÷ÓdþPÓ\æyÑV–4	j¶ÐŒ¨+Eœ-«wvXŽæ=ª‰%dÅ\ ¡a»•Ö5ƒ´Êà_oö`2bö²Í¶JÃà>¨u|4Ì_ëæ¡Ì!æsE¸}­u±*ÁÛ:—o4\½y+ôLX7z[ì	c,€د1z…IV7ûº‘¨j} ˜oÕË‘r(üµ…½²ZÓyYp)㨠¢–Qfsø­;rªúÀ˜¢Ê‹—"?È’!Å›y#ˆ7S`× t’Tؘ{¾ð Ì?©Š1Š¹j­Ê1·væx=ok`Ã[ÇDÚtÙß?¾D|‡ó¼#*–÷³º×ð¿ó†@`éÇNà‰Ð°d6IlØ}1«$áè ïùÉbU´„«WµÅ¹gî:ø'AÉå€ïa³–YÇȘZ…ÃÈ(9Hãùë¶È¶¬(z`ÖúÏéQè„žðŽv¨r;˜
-±AiÏK:·úCÛÅÂñCa×R¾_~à‰-³¤üœö
-É‘9R P)0¦†Œi‚4`(M§6ó'óÃ^S(Wr7dg51™hïŸÏ=¨m/̹?5YŽ¥ÚlË7“ìÌ(Ø… ¾È5o]÷"L¸6xc0¡q²m
-©—´¦5õÃD 	œ$ŒlH„r«å&Âçݳ5º?¾·hdµÁk+ §/-UçI0>
-è¾ÏÝG$”uf,Õ­DC¡Æüx¾;˜t
-(–"—ÜYi4¹B™º¦qfèY'ÉíŽÑ–\z
¬nÌ\³&ÊKŸ	‰•v(Äð1“‘㣓Æ|ÒØŠž«Ëˆp}µ6eè£[SWöj›ŸMñ¢Âú`K@®Ö j]¼©VP%Ûc4ºãê#‘œ*Õ-õNB'V½S“ÖÂxl˜gr/WXÖà=#’qcYaç8êò®•õ•Ëö0î$3£–F®ÁØÑ‚𪕲€¦)¨Ùˆ1|L7eX¥s*-qPC+a©÷Ö> XúØö±°ž WÓgÀÀ´ëð{SJ­¹ô‡©©í>ÖØ"à©g0Áhrsÿñ	ÃÈó1‘¦ß,°Õd0\>M„4Ê‘Qƒ+KŽ\”c.¬ŠhÙdEÛ¤Ašäèe<à‹uÝ«²ä~É°?Òì¿A{É”Ôøø¾ÿˆ8"UÐ%1t\éÁî`ªŒ˜‰HÒ¿˜Þtè£}VÕÐ_àrÉhÓ±#}à'nLsD¯€“‡¶Æº$ë) kL蘌‘¦Ö¹aTìö¥ÚYu›ºÊ£²Ýbf`’–5ýv¢àdб¦œ)à·7En¡vÛ\­%””4é-„¼×ô[)¸ìZ6oçÈõX˜Ì¯'ûÓ·}‘ÙeÜÎJ©]±ÙrUQÖ57°eñE]u-ã "‰„“aë_ßu½«|•\ùð›^I×…õ¾Wk•xWþJø)mÑñ™*ÛÒã@;L/ʨY'²zÝššbb™Û—¢ÏÞ’9” Cfb‚ã\sÂ]¨	ÏvHÆïV¼×V¾("+ª¬ÛÀ8«KsÕaˆWýßWW¢K
=ÉIøô¥;^4@%(SÚÂdà†¸¿ÑʸSî”bÙH^šÉÉÇ!4F{\Zf6ç¬8€´}
âç13êêʪ«Hó›!¾}°ü\ñœ­¨7Üoßú؉õ|Ø *¬(OJæpþÁÆä³H`7é^EžÄ)Û-t/`7õÄàÚýÇHžÇ~
, KÌëì`9B»EœLçsyÛÖà&Ñð\´Md½•ÌÙ|4o.hÔ¿4~^Wè­QâX†½lx7ã/Ñ»ÏbŠ„rSƒ^E8©È@´ÂŒLcÓ’Ã/ܽmE!§UÝš&7!'\×JÌæ(ÎËñ.iU¾XvÝép’›ž¢2‰¦Ø;ðšÉ½W3ÜðÛjÕ“jº˜¼ÒÙ¿Ñy‘7Vĉ#EhîQÿ¾YúÅ`Á©s5eBÛûj×NÝl.›uvâ:¾;©+ŽD:òœŽèDŽ‘Nx½ç7±I<|à9NÍà¢	Dš4§è~ïK®üü:q
-·KÊÿóWÞþCw;"Iüé¸~œ8Ô¥V({žÿ‰ÙÁ8Ó±c
+¦!;¸59¸i"»ôÁë0¤r‚”Aà/ìºÒé”á¡~‚ZÇgsnœn28%£u¿N8¸¸ë
ãÍ3=Ê6‹¨+
+˜5†îszB8âè[]¤ÕTtˆœJ^ÞÒyÕwIǤÝKé~á{¾ãÇpS††YRzNzýÉøH°8ÒŸP%óJ
	Ó„hX¡,ØÄÏ{M\¥»!9³©!ˆÉ#€{÷ôp. ä» 0§þÄä8æj³-_Mª3 ^`‚ò"×|tݳ0Q(€3ú
+÷ ×&2a¥eMù0F|'B5˜\[{\º
+[ºzã[‹€&­6xi%dô¥Åê	ÆGá!šˆR²@YgÆRÝN4j̋滃I¦°Ä<@ÜJw–Mž@Þfb¬•žQJ¹0Ú2KÒÀêÆLÀ3k¼ô‘Hi‡‹|7I±¤‘e=>Væúbm*‚][ÿ¦ô³)žCX w¶äZ
‚ÖÅ›jE²/mmwjDi»U\Œ·Û´cïRhP*¥§ÊqRZÍó,ݧ+¬iðš!‡È¨‹°¬Å sÕ}ßb'ÕW.Úƒ¨cÌŒZ
¨úW`FON0»VÊš¦0Q	ÚÉÎÄ-þœêJÔÐÝ¥°ÏTû1+˜ûÈv‘´Ž ÓeÀÀ4±ðû¡Lµæ¦¦°ûXïRKí±‹f0Á`òáîã#F‘¦cM˜oKIþ°|œ’„4ÊQƒ'§m×`ᘫbZ6)ÑÀ)sð2ðÅzŠîU9r?ÈcØiöàß¡-ä
ЯàZÀà›î#£4AW@F`Ïq•»ƒ©0"²#B Cÿv`|”aTŸ€cÂÊ¢úêó].÷q}ÏÐÐj‰¸1Q«rZKm5IÖc@ΘjèŒ-’Äú6ŒŠÝ¾T;«mSÓ@iT¶[ÌŒÒò¯¦ßŽœÚÕ„óüÖ â¦È-Ô›«u
+å$Mz!í5ýV
+®ºN›×s|`-Äóë©PýA‘ÙúdÜÊʨ]±ÙrIQÖ5w¯eñE]uíâ 	¡W”ÒÖ¾žëŠ«|_yð›\¥®#j|¯Ö*WÞJz	mÑÑ™(Ù’ã(}¾Ö'ʨQ'´zÝšxš`V™»— ËÚâ9Ô B&bBçþ[_Ð[‰®iÍßrø¬mú¬­¨²ò@ÅGBQxÐ:ýÉ×¢m×™v½«‘fͯH±9x‡¦„ÔIQ`y} ¯qV—æ¢Ã/ú¿¯®þDWÚ“ðåGw´h€JP¦¬…ÉÀñ|£•q“Ü)Å’IykFµâ±XhŒö¸¬ÌlÂYqø8ПI…æF˜QWSV]5zì›ß÷"ù¥â=ÈVÔ›&Ýo_û€Ø±õtØ *,+*ÍAþÁëÅ·_Dd÷"ò¨ NÙVam½>Ô;ƒÇhuô÷=Ž<H@‡˜×ÙÁR„V‹8Ù6ô‡ÏæⶭÁO¢àºhœÐº+Ù;´ép Ý\Шe€õ=¸]¡·FW¸Æ<ìÓ†O3úo=ˆt*’^À
-zál¤"Ñ
+2M;¿pù¶…0œVukÜ@œlp_›b2GþsÞŽ—I«òÙ’ë¤ÃIn:ŠÊ$˜bçÀ{&Ëö^ÍpÅoª
ÔNªébòò<Á
+÷Ín©äÉ8† Œw7Ë[ν‰m-’xe¾Mÿ©ígñüw#{Z$úOŸ¾C¨RZ|ãÎÚ[Y¯0Vnfaß~Ÿ.Uo—|'Û«‰l¿n÷W——///¨§Ð…£òÃeQ-Œ•.±Õ7®]_ø	\«ÐöÏ_áoâ‚xÒI„k‘œö+?¬ˆqrBÙ¶øÏÇŸN¼Àw¢$ˆMË.Âħo´üefG?öß=º‹áú<”¹;¡ð§gpÓ‚MØ4-9#ð÷ýÖN8øYrB·KÌÿó×Ïþ00'ãØ›þ°éE±ãCij™B	ï„sû™ô”õÿ"‡ðendstream
 endobj
-1531 0 obj <<
+1543 0 obj <<
 /Type /Page
-/Contents 1532 0 R
-/Resources 1530 0 R
+/Contents 1544 0 R
+/Resources 1542 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
-/Annots [ 1536 0 R 1537 0 R ]
+/Parent 1541 0 R
+/Annots [ 1548 0 R 1549 0 R ]
 >> endobj
-1536 0 obj <<
+1548 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
-/Rect [253.7995 146.8976 417.685 158.9572]
+/Rect [253.7995 149.3637 417.685 161.4234]
 /Subtype/Link/A<>
 >> endobj
-1537 0 obj <<
+1549 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
-/Rect [63.4454 108.9117 208.8999 119.0735]
+/Rect [63.4454 110.455 208.8999 120.6168]
 /Subtype/Link/A<>
 >> endobj
-1533 0 obj <<
-/D [1531 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-582 0 obj <<
-/D [1531 0 R /XYZ 56.6929 652.1213 null]
->> endobj
-1534 0 obj <<
-/D [1531 0 R /XYZ 56.6929 614.8935 null]
+1545 0 obj <<
+/D [1543 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 586 0 obj <<
-/D [1531 0 R /XYZ 56.6929 614.8935 null]
+/D [1543 0 R /XYZ 56.6929 662.0717 null]
 >> endobj
-1072 0 obj <<
-/D [1531 0 R /XYZ 56.6929 584.5024 null]
+1546 0 obj <<
+/D [1543 0 R /XYZ 56.6929 624.1661 null]
 >> endobj
 590 0 obj <<
-/D [1531 0 R /XYZ 56.6929 289.5256 null]
+/D [1543 0 R /XYZ 56.6929 624.1661 null]
 >> endobj
-1535 0 obj <<
-/D [1531 0 R /XYZ 56.6929 251.3901 null]
+1077 0 obj <<
+/D [1543 0 R /XYZ 56.6929 593.0972 null]
 >> endobj
 594 0 obj <<
-/D [1531 0 R /XYZ 56.6929 251.3901 null]
+/D [1543 0 R /XYZ 56.6929 294.2701 null]
 >> endobj
-900 0 obj <<
-/D [1531 0 R /XYZ 56.6929 222.7156 null]
+1547 0 obj <<
+/D [1543 0 R /XYZ 56.6929 255.4568 null]
 >> endobj
-1538 0 obj <<
-/D [1531 0 R /XYZ 56.6929 53.7852 null]
+598 0 obj <<
+/D [1543 0 R /XYZ 56.6929 255.4568 null]
 >> endobj
-1539 0 obj <<
-/D [1531 0 R /XYZ 56.6929 53.7852 null]
+905 0 obj <<
+/D [1543 0 R /XYZ 56.6929 226.1045 null]
 >> endobj
-1530 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F53 962 0 R /F11 1304 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
+1550 0 obj <<
+/D [1543 0 R /XYZ 56.6929 53.5688 null]
+>> endobj
+1551 0 obj <<
+/D [1543 0 R /XYZ 56.6929 53.5688 null]
 >> endobj
 1542 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F47 884 0 R /F53 967 0 R /F11 1321 0 R /F39 868 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1554 0 obj <<
 /Length 2824      
 /Filter /FlateDecode
 >>
 stream
-xÚµZ]{£6¾Ï¯ð¥ý<-’ KÇö¤É4™4v·Ûα›g0¸g&ýõ{„>äζûä" ôâóžO	<òà"†<ÊýQÈ}Ä<ÌFëý•7ÚÂÜíV2×ZèÚ–ºY]ýó
Gñ€£Õgk­yQ„G«ÍÇñôéiñ8¿û÷äš0oŠ(½@‘-5L‘‘ÒñÐá3N䆡3è~†ZØqš©Xœª4ßv8¨v‰¼°©\¾•U²ïs1Òç¼ÍÇLiÿ)>‚æ7ÛDßÇù)>¾ÕH-ÙŠpׄøˆG Z*~€O꥟ŽÅ¡(m)—^@Eäw–”ƒ;-eÜ‹s‡{9¡-òºØäÙàwùú8ÁÑXzâñ?E®([M0Æãcœ—ŸµkçË>ú|ŒpªnÑ÷ èû°«b54=mOe¥‰ãÁ°Ïà…äR=`K9ô®¥,½½» -½w±ônƒO•b’õ.ÎÓr/o?JÉO5)ÅþPéSÙa¬+>wÙšÁZÛÞDAAHœAŽ±qú-M¾›Od7ï?–”ƒ-¥ù!˜ºøqA[üt±ø±Áçoy¼Oדk„㟛¸™‡Qmÿb°kâB‡5q-2”p;CŒƒ†ÊƱŠÍ…˜\ªñծؗE®F­}SM='_v¸hèëëø+¦îkê@!øÚ„FÀ¿)NùFs~8êP”§1ïûÔM¹-5L¹‘j(ð0åNè†ò3ì~Ê[à³,>ZN¦
-ªèf1ˆ{²¶À,@^C-·{FæBþ¿9•;yµÈþЉ픽ý&A$¢ä–”ƒ	-e˜ ^ä`Âm1ÑÅ`ÂL¶ ÒWÕâõÎT:è~:%Dz›r„I@úSÑ4ßÈÄ÷U×qq=°Þ½GÃz‡¦CP½ wKÊ¡w-eô„.pA[zïbèÝ_|«’¼4	Æ$§²“ŒòE?¼€;Ow½gF¡€ùŸóŽÃô1|‰KÊA–²( 
-\Ð]ì
-lðÇ"¿–EWrܧ¹®ÈŒÆe‚©£G²I¥¯ÃC$d´ßfÇø«`VØôëžêÞ^"ˆ|nÝÛRú7RF÷‘洞ÐîÏ°ûuß_&ª* lü>y“M¯UýEÐ䄼JMM’ÒEàBÂEVË»Û!„"/bØâj<nÀCüq:Ácå$”?¨©ÛÓfé»”E¡Ñx®fqY]˼o Zy?‹¿h—£-#0}Û2”_&œŒ“,ƒ\Iœ:XªôD<(›í$QQ~ÁN,)‡h)c'œz;qA[vÒÅ°¼e' i'"}—Uü’¥åN4S®˜¹z¿P;ŠÏÏC¡3âÈçAgÓh®8ô2¸L•µ#áfÈçˆr‰!KÊÁ–²r$2'´ÅP{€!Ü(û9ùý”èf,»ÇŸ…ÚÒmW'ImÙ%׫s\9äÆÔ”ðÿ7[#àKlYR¶´”f‹z^è`Ëm±ÕÅ`ËRZ?ß'jòj¨-ÀqM†|D·kâF¶k½Á#ƃ6IÎ0×ÞÛssƒ)è7–”ƒ-e¸	œ9ÑmqÓÅàÆ¿Mr¨¯…bÃP•V"Ú…Ü_Óu"§¦Ù¶€©Ý^ÎÉ°'ib%ÜËX	=>(–éæT{-éÕp!è¿].e~ót^“§<®\ËÏüN9´Tô¿ÿç}õé­ì
-¶º/ÓÃi&·hÞêß¡fÔ_¦/Å«=sß²²~e|–pu?øCœejîú*ló£ýû›<€æ©»¿Ù4ª
mõÖÒwm{RßCKqšµ-5lÖFʘ5!³vB7f}†ÝoÖ-ð»|SÛ˜n+Ÿ“²È^µ¢—§Ã¡8Vgçr1ëËԃرþØ?+ò£¡zž¬Ûá†
-±ŠSzIï–”CïZÊè=¢Ô¡w´¥÷.ö€ÞmðÕNFƒ”/]xœ½•i)Źµfk
®ÕÖ\éL ®íLÐð©p’f¯M¬Šxõ%Í´Ü-ƒ‹g=	P’Šàã@wFªžV‹¶êi Ó$“pŒ"^Ø#µ¥†É4RšLßs‘é„nÈ<Ãî'³^Ìí¼€y¾UÉ|\lN*²‹ÑZÁBX”disæлsùбØÅ”ÕĈç§òYèzº†11ú FŒª;òdw$^æ!.ËDGn¹9ª [œ6LjHp•IÿnÐφé0
-=|a¿Ô–rЯ¥,ú1Ô	mÑßÅ ßWgU±.Ä.øÌC±él FD¥oíÕbD&&áÈMb‚;¹û}nýlŸ3C¯îs;s,“&,Ú63a;²}PâÚ,”G«•[ìëÞ2–Îñò_´¨‚™èÌÝvaI9ìBK5vá;΃Ж]t±ì¹TÖó¢8„È#ëB”õMm”F*ÊSU׉‹ÆÄÙì5,>}ñ­}ʸÞ´#š‰È21ú ÄMŒƒsu\bZFñ÷ÃY‚©À²¸ ¡£ùÈ
-’Xï*½ªA¾§ª³ÃÐù"bÀø0‹^h%-¡aÓÓBæP•¹"’·1¼.p¿ÝÙÈÓÉ5#¾eCâNŨ—LÔb fËšQ¥°™G{?µûeB¼1´5öÝ&ÉÔêóäoúùZÿõ+Ÿ«¯’ùõØ.…‚1¤•ß‡ð§ìÎ̶ìî6~•/œ÷u˜s:e0‰ ×&S[ÊAµ–²¸vÐ:¡-²»ØlÛà³b¿—»®Xo¶ö|“Éjq,¥ŒôW˜Xž¶[èÄêNÆߥßúÎiˆBŽíc$êןŠEÞŸö±>uû®uŸ«=°r¦gjð1i“tôº-ž[½ç<ÎÿH·Cqæ!Í2sâû}&Á#Dü p[„%4lZ¨ù "rœ¸psè÷[ƒ¼LŽ©>*y<5Ö´Þ’HªtÝWeB0fþùé¬9ŠhÏÅqí÷~$ybþBýo	
+\5iÞõÙ—·Qx¸_á6²ñ>¨óÒò%Ùů©Èú0Yv][­˜–Î	ú¤¶‘U!ŒÞ=½òjºQ'²a{1 (€æÃâ‹°æ+ˆúUŠcZîÒ*– ’:_	/Q2÷i¾ORí„zÍÖ’}¸1\½AªŸàö¨Ö3¹ý/ék톈FÑÀaõê—¿‚Óî››O‚Ï_ý¿:¸bŽendstream
+xÚµZ]{£6¾Ï¯È¥ý<-’ KÇö¤É4™4v·Ûα›glH
ÎLúë÷} 0’;Ûî“‹€tЋÏ{>%ðeø2a( <¼ŒyˆX€Ùåj\n`îæ+™+-teK]//þùŽÆ—ñˆD—ËÏÖZ	
+’_.×G“ÇÇùÃìößã+‚ѯXèÑé|1¾Š#.&¨˜Š‚Ñõíõ·nž&?ü*ú-`Áäa&o?ßÜÌ˹º}šOf·7 ‚ÇŸ–wó¥ymû§á€Šwþýâã§àr
¿ðî"@”'ìò+ÜsN.÷!£ˆ…”ê‘ÝÅââ'³ 5Û<:¤*FÄèŠàKŒgŒt”Å8Š(¡²uZ¬Óúrþ"ÊØ9š,)	M‡hÒRùãÓ»)()üÔGÆ,@	‡w÷B©SìÐ6ÌJbʺà³rŸæ…$ô!Ýg•âX^MËb•½Ôjt$/Þ¥«|—×yÖè«÷3q Å	¼ Àø‡|äqŒ	¡Érì¾\}I_²úWJê¡|ÍöÏÙAÞažÄÈÉŽÀVÂsŒXRF´”Åó0⃶éc;±ÁÏ2r»Ùeû¬¨Ó:/‹/‹—l•ÿd%gOÉ!˜ýAf€ƒÏQ`Iy(ÐRÄCÚ¢ í À(‹+Yte‡}^èŠÌh\&˜&zdë\ZðÊ~"1£Ã0=¤_£°ÂzX÷Ü©ûxI òùuoK¹uo¤Œî“ÐS{¡[ÝŸ`ë¾¾ÈT-,T@Ùè}ö&/Ú*8]©ú‹F -È	E›š$¥‹À…$.„‹,·7!„¢ aØâj=nÀCÂQ>Æ#å$”>¨©›ãzé»’E¡Éh¦fæiU_ɼo :y—~Ñ.G;F`ú¶ke(¿Œ9e»ÄàZâ4ÁR¥'@Ùä´“(FQBù;±¤=¹BgÂQÈ£Þ¦ÑLq"èu2¸È^jkGÂÏPÈ#äC–”‡!-e1äId^h‹¡>¶ƒ!Ü(û)ûý˜éf,{ÀŸ…ÚòM‘ÖGImÕ’%7hr\årãj
Jøÿ›-Šð9¶,)[ZJ³Eƒ ö°åƒ¶Øêc;زÁÁŸ”ÖO÷‰Ú|§*CpÜ!Ñ횸‘íÚ`°Åˆñ¨K’7Ìu÷öüÜ`Š@ 9Ã%åáFKn"oNôA[Üô±ÜØà7YõµPlK¢òZD»8‚»Ãk¾ÊäÔd·)aj»—s2ìÉGÚX	÷2V‚Ä€Šeú9Õ^Kz5\úo™ß×ä)/×2²°W-ý￦ÅP}z#»‚îËôp¾“[4oÍïP³?j‡¯òçòÕž¹ëXY¿2=I¸ºü!ÝíÔ܇U]ÚæG‡÷7yÍS³mT[Úš­¥ïÚö¤a€–â5k[ÊmÖFʘ5!³öB·f}‚=lÖðÛbÝؘn+Ÿ²ªÜ½jE/Ž//å¡>é8óéP¦ŽÄþ„
ÇþiYÕ³lÕ
'ØN(Ä*Né9½[R½k)£÷„RÞ}ЖÞûؽÛàË­Œ)(^ºðt÷V啼ªÿåÖ\˜­5¸V[kp¥3¸¶3ÁpÀ§ÂIÚ½6±*Ràõ—¼PÐr·.žô$tBY.BBˆ#Ý©zZ-Ú©§ÌÐI&á%8>³GjK¹É4RšÌ0ð‘é…nÉ<Á&³ÞÌí¼€y¾UÉ|T®*²‹ÑFÁBX”dy{æ0¸s“„бØÅT4Ĉç'òYèzú†11z¯FLª;
+dw$^æ>­ªLGn¹9ª ;œ¶ÇˆHpUÙðnÐÏÜôGÅ>³_jKyè×Rýžs?/´EÛA¿
.b¦¬ÛD#«R¤’æ¦IÛZRéÍTåoqÑÚ‹¸3»NƒX|âZý1e\:)íÙB;‘X¶ F±18SÛâ¡C}ÇBzgÊÑ ôe¢÷ƒ%å1-eƒ'¡z¡-cèc;ŒÁWVu¹*Å–ÐûrÝÛMOˆªåtˆ#²JQ½­RàNÅ\vAb”„Ü.æ8–,ÚfÂŽêbô^‰k»Pá]­Ü±Îÿ»8)àbÐ=6hp@Ió‘$©ÞU¦Uƒ:y.uo‡¡÷E„Ã1KPŸi%-!·j!s¨Ê|FèÃmm°*y8¶Ö¤Ù’Èê|5TeB0fáéé¬9Šu´çâ¸ö{?’H±¦þ·„Ü
+×BmÆ÷}öåÃmÞV¸l¼êüû¼zζék.ªAêk][£˜–Î	ú¤¶‘…ŒÞ>¾Fòj²V'²a1"(‚æÃâ‹°ö+ˆæUÊC^mó:• ’:_
+/Q2wy±Ïrí„zÍÎ’}¸á.ä U‹OpT˜Üþ—¿ôµvcD“Äq˜Fƒ%„Çú¥Ä¯à´ÿææ“àÓWÿ/øVbendstream
 endobj
-1541 0 obj <<
+1553 0 obj <<
 /Type /Page
-/Contents 1542 0 R
-/Resources 1540 0 R
+/Contents 1554 0 R
+/Resources 1552 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
->> endobj
-1543 0 obj <<
-/D [1541 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1544 0 obj <<
-/D [1541 0 R /XYZ 85.0394 752.3015 null]
->> endobj
-1545 0 obj <<
-/D [1541 0 R /XYZ 85.0394 752.3015 null]
->> endobj
-1546 0 obj <<
-/D [1541 0 R /XYZ 85.0394 752.3015 null]
->> endobj
-1547 0 obj <<
-/D [1541 0 R /XYZ 85.0394 746.3107 null]
->> endobj
-1548 0 obj <<
-/D [1541 0 R /XYZ 85.0394 731.5461 null]
->> endobj
-1549 0 obj <<
-/D [1541 0 R /XYZ 85.0394 728.1497 null]
->> endobj
-1550 0 obj <<
-/D [1541 0 R /XYZ 85.0394 713.3851 null]
->> endobj
-1551 0 obj <<
-/D [1541 0 R /XYZ 85.0394 709.9887 null]
->> endobj
-1552 0 obj <<
-/D [1541 0 R /XYZ 85.0394 651.9592 null]
->> endobj
-1016 0 obj <<
-/D [1541 0 R /XYZ 85.0394 651.9592 null]
->> endobj
-1553 0 obj <<
-/D [1541 0 R /XYZ 85.0394 651.9592 null]
->> endobj
-1554 0 obj <<
-/D [1541 0 R /XYZ 85.0394 648.8377 null]
+/Parent 1541 0 R
 >> endobj
 1555 0 obj <<
-/D [1541 0 R /XYZ 85.0394 634.0731 null]
+/D [1553 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 1556 0 obj <<
-/D [1541 0 R /XYZ 85.0394 630.6767 null]
+/D [1553 0 R /XYZ 85.0394 752.3015 null]
 >> endobj
 1557 0 obj <<
-/D [1541 0 R /XYZ 85.0394 615.9121 null]
+/D [1553 0 R /XYZ 85.0394 752.3015 null]
 >> endobj
 1558 0 obj <<
-/D [1541 0 R /XYZ 85.0394 612.5156 null]
+/D [1553 0 R /XYZ 85.0394 752.3015 null]
 >> endobj
 1559 0 obj <<
-/D [1541 0 R /XYZ 85.0394 585.7959 null]
+/D [1553 0 R /XYZ 85.0394 746.3107 null]
 >> endobj
 1560 0 obj <<
-/D [1541 0 R /XYZ 85.0394 582.3994 null]
+/D [1553 0 R /XYZ 85.0394 731.5461 null]
 >> endobj
 1561 0 obj <<
-/D [1541 0 R /XYZ 85.0394 567.6349 null]
+/D [1553 0 R /XYZ 85.0394 728.1497 null]
 >> endobj
 1562 0 obj <<
-/D [1541 0 R /XYZ 85.0394 564.2384 null]
+/D [1553 0 R /XYZ 85.0394 713.3851 null]
 >> endobj
 1563 0 obj <<
-/D [1541 0 R /XYZ 85.0394 549.5337 null]
+/D [1553 0 R /XYZ 85.0394 709.9887 null]
 >> endobj
 1564 0 obj <<
-/D [1541 0 R /XYZ 85.0394 546.0774 null]
+/D [1553 0 R /XYZ 85.0394 651.9592 null]
+>> endobj
+1021 0 obj <<
+/D [1553 0 R /XYZ 85.0394 651.9592 null]
 >> endobj
 1565 0 obj <<
-/D [1541 0 R /XYZ 85.0394 531.3128 null]
+/D [1553 0 R /XYZ 85.0394 651.9592 null]
 >> endobj
 1566 0 obj <<
-/D [1541 0 R /XYZ 85.0394 527.9163 null]
+/D [1553 0 R /XYZ 85.0394 648.8377 null]
 >> endobj
 1567 0 obj <<
-/D [1541 0 R /XYZ 85.0394 513.1518 null]
+/D [1553 0 R /XYZ 85.0394 634.0731 null]
 >> endobj
 1568 0 obj <<
-/D [1541 0 R /XYZ 85.0394 509.7553 null]
+/D [1553 0 R /XYZ 85.0394 630.6767 null]
 >> endobj
 1569 0 obj <<
-/D [1541 0 R /XYZ 85.0394 483.0356 null]
+/D [1553 0 R /XYZ 85.0394 615.9121 null]
 >> endobj
 1570 0 obj <<
-/D [1541 0 R /XYZ 85.0394 479.6391 null]
+/D [1553 0 R /XYZ 85.0394 612.5156 null]
 >> endobj
 1571 0 obj <<
-/D [1541 0 R /XYZ 85.0394 464.8745 null]
+/D [1553 0 R /XYZ 85.0394 585.7959 null]
 >> endobj
 1572 0 obj <<
-/D [1541 0 R /XYZ 85.0394 461.4781 null]
+/D [1553 0 R /XYZ 85.0394 582.3994 null]
 >> endobj
 1573 0 obj <<
-/D [1541 0 R /XYZ 85.0394 446.7135 null]
+/D [1553 0 R /XYZ 85.0394 567.6349 null]
 >> endobj
 1574 0 obj <<
-/D [1541 0 R /XYZ 85.0394 443.3171 null]
+/D [1553 0 R /XYZ 85.0394 564.2384 null]
 >> endobj
 1575 0 obj <<
-/D [1541 0 R /XYZ 85.0394 428.5525 null]
+/D [1553 0 R /XYZ 85.0394 549.5337 null]
 >> endobj
 1576 0 obj <<
-/D [1541 0 R /XYZ 85.0394 425.156 null]
+/D [1553 0 R /XYZ 85.0394 546.0774 null]
 >> endobj
 1577 0 obj <<
-/D [1541 0 R /XYZ 85.0394 355.0758 null]
+/D [1553 0 R /XYZ 85.0394 531.3128 null]
 >> endobj
 1578 0 obj <<
-/D [1541 0 R /XYZ 85.0394 355.0758 null]
+/D [1553 0 R /XYZ 85.0394 527.9163 null]
 >> endobj
 1579 0 obj <<
-/D [1541 0 R /XYZ 85.0394 355.0758 null]
+/D [1553 0 R /XYZ 85.0394 513.1518 null]
 >> endobj
 1580 0 obj <<
-/D [1541 0 R /XYZ 85.0394 352.0499 null]
+/D [1553 0 R /XYZ 85.0394 509.7553 null]
 >> endobj
 1581 0 obj <<
-/D [1541 0 R /XYZ 85.0394 337.3452 null]
+/D [1553 0 R /XYZ 85.0394 483.0356 null]
 >> endobj
 1582 0 obj <<
-/D [1541 0 R /XYZ 85.0394 333.8889 null]
+/D [1553 0 R /XYZ 85.0394 479.6391 null]
 >> endobj
 1583 0 obj <<
-/D [1541 0 R /XYZ 85.0394 309.8192 null]
+/D [1553 0 R /XYZ 85.0394 464.8745 null]
 >> endobj
 1584 0 obj <<
-/D [1541 0 R /XYZ 85.0394 303.7727 null]
+/D [1553 0 R /XYZ 85.0394 461.4781 null]
 >> endobj
 1585 0 obj <<
-/D [1541 0 R /XYZ 85.0394 278.3282 null]
+/D [1553 0 R /XYZ 85.0394 446.7135 null]
 >> endobj
 1586 0 obj <<
-/D [1541 0 R /XYZ 85.0394 273.6565 null]
+/D [1553 0 R /XYZ 85.0394 443.3171 null]
 >> endobj
 1587 0 obj <<
-/D [1541 0 R /XYZ 85.0394 246.9367 null]
+/D [1553 0 R /XYZ 85.0394 428.5525 null]
 >> endobj
 1588 0 obj <<
-/D [1541 0 R /XYZ 85.0394 243.5403 null]
+/D [1553 0 R /XYZ 85.0394 425.156 null]
 >> endobj
 1589 0 obj <<
-/D [1541 0 R /XYZ 85.0394 173.5556 null]
+/D [1553 0 R /XYZ 85.0394 355.0758 null]
 >> endobj
 1590 0 obj <<
-/D [1541 0 R /XYZ 85.0394 173.5556 null]
+/D [1553 0 R /XYZ 85.0394 355.0758 null]
 >> endobj
 1591 0 obj <<
-/D [1541 0 R /XYZ 85.0394 173.5556 null]
+/D [1553 0 R /XYZ 85.0394 355.0758 null]
 >> endobj
 1592 0 obj <<
-/D [1541 0 R /XYZ 85.0394 170.4341 null]
+/D [1553 0 R /XYZ 85.0394 352.0499 null]
 >> endobj
 1593 0 obj <<
-/D [1541 0 R /XYZ 85.0394 144.9896 null]
+/D [1553 0 R /XYZ 85.0394 337.3452 null]
 >> endobj
 1594 0 obj <<
-/D [1541 0 R /XYZ 85.0394 140.3179 null]
+/D [1553 0 R /XYZ 85.0394 333.8889 null]
 >> endobj
 1595 0 obj <<
-/D [1541 0 R /XYZ 85.0394 113.5982 null]
+/D [1553 0 R /XYZ 85.0394 309.8192 null]
 >> endobj
 1596 0 obj <<
-/D [1541 0 R /XYZ 85.0394 110.2017 null]
+/D [1553 0 R /XYZ 85.0394 303.7727 null]
 >> endobj
 1597 0 obj <<
-/D [1541 0 R /XYZ 85.0394 95.4372 null]
+/D [1553 0 R /XYZ 85.0394 278.3282 null]
 >> endobj
 1598 0 obj <<
-/D [1541 0 R /XYZ 85.0394 92.0407 null]
+/D [1553 0 R /XYZ 85.0394 273.6565 null]
 >> endobj
-1540 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
+1599 0 obj <<
+/D [1553 0 R /XYZ 85.0394 246.9367 null]
 >> endobj
-1601 0 obj <<
-/Length 2889      
-/Filter /FlateDecode
->>
-stream
-xÚµš[w›º€ßó+üh¯Õh£·G»‰ÛÄͱ“ž½WwˆMV0¤·Í¿?#tA`Ý笳ò
֧͌ÀþðÄõ’pâ‡¹v'Ûý™3ù}WgXÊœ+¡sSêâþì÷ÔŸ„(ôˆ7¹2Æ
-xr¿û2E3Á™^,/n–Ÿ®ÖÑÝõ_³sâ:Ó¿׉Vsq³y¸ºZlîòv½ˆæËÕˆàÙ¹ï…Î4º»[¬æË?EÄGutëåb3ûzÿálq¯_ÛüiØ¡ü¿Ÿ}ùêLvð?œ9ˆ†;ù	7ÂaH&û3æRä2JUKv¶9û—Ðè­í*ì B=Ò3WO0F¡ë’Öd¹!ò(¡õd­“²8¶‰œ‚d[vâú~3ðöš”ƒ¿’bä»ÂÐ/Eû*)þN_Öï/1è×®fLL‡ëÛUk©SÝÌ\<˜øÈ%~[÷*ù	?Óé|µëµlHþv’§UZäõœt~
-vL+õà%ø@ïà)âL/ÑûYH¦HŒ±ø‘f8˜>LJªÀÓÙÕÿÉô6ÞÇ/E){ײ÷!ËöqžËAã|'šïf˜„jðÛbû¿&Õ!…§áý`&Ô+‹e ìãÓ¶*á=jÊ°è4DØCxl„°)5LXKi¾ã
¶ªnŸèî%ÜÒ-ÀÂO_m¢;µì¹p0mCèÅºýÐ
Ì Äÿ[€”æßÄÀÄG“½—E–dY,Ÿér`Ã|ÐO±?ÂÁ²pPRšCàÛ8ØTººû9˜º#¾–ýémƒ9Á¥7}*¢mñ뵦‘”¥˜Lè¼)¶17=!±ÌAx¯¼i*;ªçD\Ì‹}œÊÎU¼—­›·²Jö=X©ƒ‘˽hƒ•b°^9Xü#-e[csÐñyæºÓôWšH‹ÓÃœkÇ£ÝÏ|6Eï:«b)WÅ<ݾ¤yYäRàCœãÛ^Þðº`°í1:fŸ†”e]()µ.ˆã˺°©6ÖEWwÿº0uú ØfJ1«ý/o¨W¿Ø¼&Ûôé­^ü¾FÎ%›%›‹')ž~¤Û¤D=Ô‰"L‰AaîŠù“WÇìñ¸Ê$
-jt¼G¯~c¬úqe×õ‚ÐZÂN{»îH`dJY¨*)M{–}ÕªÚ ÚÕÝOÕÔý ,fBò‚‹e^%‡<©ÄÎûÙ–°—=+)~»üs±——…°ÿ\>{•q&®£ÝN9ù\üúÊ•÷=ÃŒø™ˆóê²siÔJ¬Å0+¶Ûç´0Ú`¯0D<ŸÙñšRÃxµ”7ÆkUÝà=ÑÝ‹·¥›ï ÙQºcêÕÆG¨?}ÈSJ4v¶YhYî’¼Jy\•JÑt”.Ÿ*_mÚ—SíË©Õ—Sä.5}y(6a>Xœ§I&†¾o‘òßòÑjØ£²^K±>æ‰íƒv	¢~HG@RÐJJƒ&Ô±€¶©6@wu÷ƒ6uLä_üÚ>Çù79ó$K¾©í¸“Hˆm.O.½ÚôEV‰mV*tŠªÖÙ,(AŒyc)%¥)À^o¡`SmPèêî§`êžo"ñÓ?.þ*;aÅfy%›Ò¼;ïÊŽxô+ìˆ? ìHçÇ@§Î{¶KÊPè{mBsIh—U¿$²™Ö†¾{§âba÷ÏšX8LÃÌ`:æ 
)1%eó-Älª
b]ÝýÄLÝëMôÇíÜ…ÅWÔ¨eDá+jüŠâÿÅ6	2ŠoÔê$5~=BÍ‘ÏœÀØå|n`cŽ‰ß5ØD0£Fjå“V˜,p“n‡iJ
ÃÔRLËngUÝÀ<Ñݳ¥{S‡z—Â!^&±…Að™”¼Õy_Í7(†¼Q0äWŠ!—aH(Âv6ùóœ!Ö4=ÇU…L½ÂøÅ')|uÜíÔÊàFÜbÚxÚb¹âxŸúd¶!e­¤Ø¡¶Mµ»«»¶©›ÃŽÅ>ˆ¸Æ
!6}ª£–ó뤮̈^ØKÑŸÊézÃõ†Úõ†ë
ǀϱ´ázézïåz=|bÃr `ÂÇ,£jHY¨*©†*³Ä1VÕÕ®î~ª¦îyRÅÛçd÷ßlŒ"{7*=¸`v)eîÿy«¤F†ØAcJ
£ÑRX
-VÕ
šݽhZºëÐÆWuº@`¡AÆ‘Á´4
-¼C™ÏS2ƒ*[õ§¥,ˆV	RtmÖ¼2óyÈæ˜$ð&D_ja £:Д„\£$t#eª|­°•]<?fcµHÞ'‡Y0m²Iâ8Ã%Zê¹È!Y†”e()½BìZV€Mµ±ººûW€©ûžeŒq[¬)3F§Ñ±z†m·z]wEÊË¢C]Ew÷kaŸ¼¿fÌûÚY'ï’ÉI¿“õ\ÖðoÁSÃú)•®‘Wä‘ï¯ÊŸlyÕMò
-þC§)vŽ¶á‘·‘±02Š ÅØâ^-J
~m­ýô­<ÐÝ\GçX`Èl„ÈP—Â%D‹L^àJj±ªÞ£z‹uõ7®G¶Ëx8›‡1Xø_ÒŠyy×𿼠¿I¦jŒT ˆ‡)BqÇÜq#dá(…ÄR·³é5Hv÷£4GMº.’ñµ>$üh°“ßߤe%SOá{v1Ž7܉[<ýJJãPöîFé] ààö–j¸^È«ŠíóIÆ
-<¢8´3„†)!
Ì
-¥›ÞXWq/0S±¨¡þª’¼¬O*avDMþ—Ç××âP	¡åhü‘JQ6‡F¯¯2ãcäx¡±2âN7H8`ù,ä8Έ6¥†™k©æË3·ªn˜ŸèîeÞÒ­çc‘o‹Ý	üURý,/MÓ­~‚é;üd'@Äñ‹›ýlÞ´¾:âõf*y	†“ì†(ÀcÕSÊBII5”lû¥UµA©«»Ÿ’©{|?¦bÛ'¹ÚõÙyñ»ëBo˜çjî^³tkÒ›²®ôÜ}féCòÄ:…ó‹C¼KÊå6(~LÀFêu¦”Š’ÒPÜÐf:6Õ”®î~(¦îñô~SŽÛJ¸É¤3óÆÙFÏÖºÈó)kOþiw˜ç‰ýðƒ
-w,!0¥,””Në(¶ìZVÕ†®î~¦îË,.ËL‡‚ËÕy4Ÿ¯Q´Þ%úé†åw&ûZUUÒ]ž('t%w’æU=÷EQu¿Âèx¶æ(¿Ùð¹.†ìÎÁÁȱ½)eA¦¤4²€X¢I«jYWw?2S÷2ºP[/Q$ÛçÜS¦>gÚs'÷¡îaÓCž~?&Ý`ôn:®ç·Á¶e$Q@XÙ±Ô‹"îTÐ~§rÀÏƾ²0„†i)¡¦lB,•j›Þ†UWq/*S±öq,P>Ž…ÜÇÍ ­®Ý;UL\F«H\]B®î’C<ô}#/iz¤uú#Ö)5> endobj
+1601 0 obj <<
+/D [1553 0 R /XYZ 85.0394 173.5556 null]
 >> endobj
 1602 0 obj <<
-/D [1600 0 R /XYZ 56.6929 794.5015 null]
+/D [1553 0 R /XYZ 85.0394 173.5556 null]
 >> endobj
 1603 0 obj <<
-/D [1600 0 R /XYZ 56.6929 748.5056 null]
+/D [1553 0 R /XYZ 85.0394 173.5556 null]
 >> endobj
 1604 0 obj <<
-/D [1600 0 R /XYZ 56.6929 748.5056 null]
+/D [1553 0 R /XYZ 85.0394 170.4341 null]
 >> endobj
 1605 0 obj <<
-/D [1600 0 R /XYZ 56.6929 748.5056 null]
+/D [1553 0 R /XYZ 85.0394 144.9896 null]
 >> endobj
 1606 0 obj <<
-/D [1600 0 R /XYZ 56.6929 743.7078 null]
+/D [1553 0 R /XYZ 85.0394 140.3179 null]
 >> endobj
 1607 0 obj <<
-/D [1600 0 R /XYZ 56.6929 719.6381 null]
+/D [1553 0 R /XYZ 85.0394 113.5982 null]
 >> endobj
 1608 0 obj <<
-/D [1600 0 R /XYZ 56.6929 711.8197 null]
+/D [1553 0 R /XYZ 85.0394 110.2017 null]
 >> endobj
 1609 0 obj <<
-/D [1600 0 R /XYZ 56.6929 697.0552 null]
+/D [1553 0 R /XYZ 85.0394 95.4372 null]
 >> endobj
 1610 0 obj <<
-/D [1600 0 R /XYZ 56.6929 691.8868 null]
->> endobj
-1611 0 obj <<
-/D [1600 0 R /XYZ 56.6929 665.1671 null]
+/D [1553 0 R /XYZ 85.0394 92.0407 null]
 >> endobj
-1612 0 obj <<
-/D [1600 0 R /XYZ 56.6929 659.9987 null]
+1552 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F47 884 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
 1613 0 obj <<
-/D [1600 0 R /XYZ 56.6929 635.929 null]
+/Length 2889      
+/Filter /FlateDecode
+>>
+stream
+xÚµš[w›º€ßó+üh¯Õh£·G»‰ÛÄͱ“ž½WwˆMV0¤·Í¿?#tA`Ý笳ò
֧͌ÀþðÄõ’pâ‡¹v'Ûý™3ù}WgXÊœ+¡sSêâþì÷ÔŸ„(ôˆ7¹2Æ
+xr¿û2E3Á™^,/n–Ÿ®ÖÑÝõ_³sâ:Ó¿׉Vsq³y¸ºZlîòv½ˆæËÕˆàÙ¹ï…Î4º»[¬æË?EÄGutëåb3ûzÿálq¯_ÛüiØ¡ü¿Ÿ}ùêLvð?œ9ˆ†;ù	7ÂaH&û3æRä2JUKv¶9û—Ðè­í*ì B=Ò3WO0F¡ë’Öd¹!ò(¡õd­“²8¶‰œ‚d[vâú~3ðöš”ƒ¿’bä»ÂÐ/Eû*)þN_Öï/1è×®fLL‡ëÛUk©SÝÌ\<˜øÈ%~[÷*ù	?Óé|µëµlHþv’§UZäõœt~
+vL+õà%ø@ïà)âL/ÑûYH¦HŒ±ø‘f8˜>LJªÀÓÙÕÿÉô6ÞÇ/E){ײ÷!ËöqžËAã|'šïf˜„jðÛbû¿&Õ!…§áý`&Ô+‹e ìãÓ¶*á=jÊ°è4DØCxl„°)5LXKi¾ã
¶ªnŸèî%ÜÒ-ÀÂO_m¢;µì¹p0mCèÅºýÐ
Ì Äÿ[€”æßÄÀÄG“½—E–dY,Ÿér`Ã|ÐO±?ÂÁ²pPRšCàÛ8ØTººû9˜º#¾–ýémƒ9Á¥7}*¢mñ뵦‘”¥˜Lè¼)¶17=!±ÌAx¯¼i*;ªçD\Ì‹}œÊÎU¼—­›·²Jö=X©ƒ‘˽hƒ•b°^9Xü#-e[csÐñyæºÓôWšH‹ÓÃœkÇ£ÝÏ|6Eï:«b)WÅ<ݾ¤yYäRàCœãÛ^Þðº`°í1:fŸ†”e]()µ.ˆã˺°©6ÖEWwÿº0uú ØfJ1«ý/o¨W¿Ø¼&Ûôé­^ü¾FÎ%›%›‹')ž~¤Û¤D=Ô‰"L‰AaîŠù“WÇìñ¸Ê$
+jt¼G¯~c¬úqe×õ‚ÐZÂN{»îH`dJY¨*)M{–}ÕªÚ ÚÕÝOÕÔý ,fBò‚‹e^%‡<©ÄÎûÙ–°—=+)~»üs±——…°ÿ\>{•q&®£ÝN9ù\üúÊ•÷=ÃŒø™ˆóê²siÔJ¬Å0+¶Ûç´0Ú`¯0D<ŸÙñšRÃxµ”7ÆkUÝà=ÑÝ‹·¥›ï ÙQºcêÕÆG¨?}ÈSJ4v¶YhYî’¼Jy\•JÑt”.Ÿ*_mÚ—SíË©Õ—Sä.5}y(6a>Xœ§I&†¾o‘òßòÑjØ£²^K±>æ‰íƒv	¢~HG@RÐJJƒ&Ô±€¶©6@wu÷ƒ6uLä_üÚ>Çù79ó$K¾©í¸“Hˆm.O.½ÚôEV‰mV*tŠªÖÙ,(AŒyc)%¥)À^o¡`SmPèêî§`êžo"ñÓ?.þ*;aÅfy%›Ò¼;ïÊŽxô+ìˆ? ìHçÇ@§Î{¶KÊPè{mBsIh—U¿$²™Ö†¾{§âba÷ÏšX8LÃÌ`:æ 
)1%eó-Älª
b]ÝýÄLÝëMôÇíÜ…ÅWÔ¨eDá+jüŠâÿÅ6	2ŠoÔê$5~=BÍ‘ÏœÀØå|n`cŽ‰ß5ØD0£Fjå“V˜,p“n‡iJ
ÃÔRLËngUÝÀ<Ñݳ¥{S‡z—Â!^&±…Að™”¼Õy_Í7(†¼Q0äWŠ!—aH(Âv6ùóœ!Ö4=ÇU…L½ÂøÅ')|uÜíÔÊàFÜbÚxÚb¹âxŸúd¶!e­¤Ø¡¶Mµ»«»¶©›ÃŽÅ>ˆ¸Æ
!6}ª£–ó뤮̈^ØKÑŸÊézÃõ†Úõ†ë
ǀϱ´ázézïåz=|bÃr `ÂÇ,£jHY¨*©†*³Ä1VÕÕ®î~ª¦îyRÅÛçd÷ßlŒ"{7*=¸`v)eîÿy«¤F†ØAcJ
£ÑRX
+VÕ
šݽhZºëÐÆWuº@`¡AÆ‘Á´4
+¼C™ÏS2ƒ*[õ§¥,ˆV	RtmÖ¼2óyÈæ˜$ð&D_ja £:Д„\£$t#eª|­°•]<?fcµHÞ'‡Y0m²Iâ8Ã%Zê¹È!Y†”e()½BìZV€Mµ±ººûW€©ûžeŒq[¬)3F§Ñ±z†m·z]wEÊË¢C]Ew÷kaŸ¼¿fÌûÚY'ï’ÉI¿“õ\ÖðoÁSÃú)•®‘Wä‘ï¯ÊŸlyÕMò
+þC§)vŽ¶á‘·‘±02Š ÅØâ^-J
~m­ýô­<ÐÝ\GçX`Èl„ÈP—Â%D‹L^àJj±ªÞ£z‹uõ7®G¶Ëx8›‡1Xø_ÒŠyy×𿼠¿I¦jŒT ˆ‡)BqÇÜq#dá(…ÄR·³é5Hv÷£4GMº.’ñµ>$üh°“ßߤe%SOá{v1Ž7܉[<ýJJãPöîFé] ààö–j¸^È«ŠíóIÆ
+<¢8´3„†)!
Ì
-¥›ÞXWq/0S±¨¡þª’¼¬O*avDMþ—Ç××âP	¡åhü‘JQ6‡F¯¯2ãcäx¡±2âN7H8`ù,ä8Έ6¥†™k©æË3·ªn˜ŸèîeÞÒ­çc‘o‹Ý	üURý,/MÓ­~‚é;üd'@Äñ‹›ýlÞ´¾:âõf*y	†“ì†(ÀcÕSÊBII5”lû¥UµA©«»Ÿ’©{|?¦bÛ'¹ÚõÙyñ»ëBo˜çjî^³tkÒ›²®ôÜ}féCòÄ:…ó‹C¼KÊå6(~LÀFêu¦”Š’ÒPÜÐf:6Õ”®î~(¦îñô~SŽÛJ¸É¤3óÆÙFÏÖºÈó)kOþiw˜ç‰ýðƒ
+w,!0¥,””Në(¶ìZVÕ†®î~¦îË,.ËL‡‚ËÕy4Ÿ¯Q´Þ%úé†åw&ûZUUÒ]ž('t%w’æU=÷EQu¿Âèx¶æ(¿Ùð¹.†ìÎÁÁȱ½)eA¦¤4²€X¢I«jYWw?2S÷2ºP[/Q$ÛçÜS¦>gÚs'÷¡îaÓCž~?&Ý`ôn:®ç·Á¶e$Q@XÙ±Ô‹"îTÐ~§rÀÏƾ²0„†i)¡¦lB,•j›Þ†UWq/*S±öq,P>Ž…ÜÇÍ ­®Ý;UL\F«H\]B®î’C<ô}#/iz¤uú#Ö)5> endobj
 1614 0 obj <<
-/D [1600 0 R /XYZ 56.6929 628.1106 null]
+/D [1612 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 1615 0 obj <<
-/D [1600 0 R /XYZ 56.6929 601.3909 null]
+/D [1612 0 R /XYZ 56.6929 748.5056 null]
 >> endobj
 1616 0 obj <<
-/D [1600 0 R /XYZ 56.6929 596.2225 null]
+/D [1612 0 R /XYZ 56.6929 748.5056 null]
 >> endobj
 1617 0 obj <<
-/D [1600 0 R /XYZ 56.6929 569.5028 null]
+/D [1612 0 R /XYZ 56.6929 748.5056 null]
 >> endobj
 1618 0 obj <<
-/D [1600 0 R /XYZ 56.6929 564.3344 null]
+/D [1612 0 R /XYZ 56.6929 743.7078 null]
 >> endobj
 1619 0 obj <<
-/D [1600 0 R /XYZ 56.6929 549.6297 null]
+/D [1612 0 R /XYZ 56.6929 719.6381 null]
 >> endobj
 1620 0 obj <<
-/D [1600 0 R /XYZ 56.6929 544.4015 null]
+/D [1612 0 R /XYZ 56.6929 711.8197 null]
 >> endobj
 1621 0 obj <<
-/D [1600 0 R /XYZ 56.6929 529.6968 null]
+/D [1612 0 R /XYZ 56.6929 697.0552 null]
 >> endobj
 1622 0 obj <<
-/D [1600 0 R /XYZ 56.6929 524.4686 null]
+/D [1612 0 R /XYZ 56.6929 691.8868 null]
 >> endobj
 1623 0 obj <<
-/D [1600 0 R /XYZ 56.6929 500.3989 null]
+/D [1612 0 R /XYZ 56.6929 665.1671 null]
 >> endobj
 1624 0 obj <<
-/D [1600 0 R /XYZ 56.6929 492.5805 null]
+/D [1612 0 R /XYZ 56.6929 659.9987 null]
 >> endobj
 1625 0 obj <<
-/D [1600 0 R /XYZ 56.6929 467.136 null]
+/D [1612 0 R /XYZ 56.6929 635.929 null]
 >> endobj
 1626 0 obj <<
-/D [1600 0 R /XYZ 56.6929 460.6924 null]
+/D [1612 0 R /XYZ 56.6929 628.1106 null]
 >> endobj
 1627 0 obj <<
-/D [1600 0 R /XYZ 56.6929 436.6227 null]
+/D [1612 0 R /XYZ 56.6929 601.3909 null]
 >> endobj
 1628 0 obj <<
-/D [1600 0 R /XYZ 56.6929 428.8043 null]
+/D [1612 0 R /XYZ 56.6929 596.2225 null]
 >> endobj
 1629 0 obj <<
-/D [1600 0 R /XYZ 56.6929 414.0996 null]
+/D [1612 0 R /XYZ 56.6929 569.5028 null]
 >> endobj
 1630 0 obj <<
-/D [1600 0 R /XYZ 56.6929 408.8714 null]
+/D [1612 0 R /XYZ 56.6929 564.3344 null]
 >> endobj
 1631 0 obj <<
-/D [1600 0 R /XYZ 56.6929 382.1516 null]
+/D [1612 0 R /XYZ 56.6929 549.6297 null]
 >> endobj
 1632 0 obj <<
-/D [1600 0 R /XYZ 56.6929 376.9833 null]
+/D [1612 0 R /XYZ 56.6929 544.4015 null]
 >> endobj
 1633 0 obj <<
-/D [1600 0 R /XYZ 56.6929 350.2636 null]
+/D [1612 0 R /XYZ 56.6929 529.6968 null]
 >> endobj
 1634 0 obj <<
-/D [1600 0 R /XYZ 56.6929 345.0952 null]
+/D [1612 0 R /XYZ 56.6929 524.4686 null]
 >> endobj
 1635 0 obj <<
-/D [1600 0 R /XYZ 56.6929 321.0255 null]
+/D [1612 0 R /XYZ 56.6929 500.3989 null]
 >> endobj
 1636 0 obj <<
-/D [1600 0 R /XYZ 56.6929 313.2071 null]
+/D [1612 0 R /XYZ 56.6929 492.5805 null]
 >> endobj
 1637 0 obj <<
-/D [1600 0 R /XYZ 56.6929 298.5024 null]
+/D [1612 0 R /XYZ 56.6929 467.136 null]
 >> endobj
 1638 0 obj <<
-/D [1600 0 R /XYZ 56.6929 293.2742 null]
+/D [1612 0 R /XYZ 56.6929 460.6924 null]
 >> endobj
 1639 0 obj <<
-/D [1600 0 R /XYZ 56.6929 267.8297 null]
+/D [1612 0 R /XYZ 56.6929 436.6227 null]
 >> endobj
 1640 0 obj <<
-/D [1600 0 R /XYZ 56.6929 261.3861 null]
+/D [1612 0 R /XYZ 56.6929 428.8043 null]
 >> endobj
 1641 0 obj <<
-/D [1600 0 R /XYZ 56.6929 199.468 null]
+/D [1612 0 R /XYZ 56.6929 414.0996 null]
 >> endobj
 1642 0 obj <<
-/D [1600 0 R /XYZ 56.6929 199.468 null]
+/D [1612 0 R /XYZ 56.6929 408.8714 null]
 >> endobj
 1643 0 obj <<
-/D [1600 0 R /XYZ 56.6929 199.468 null]
+/D [1612 0 R /XYZ 56.6929 382.1516 null]
 >> endobj
 1644 0 obj <<
-/D [1600 0 R /XYZ 56.6929 191.7053 null]
+/D [1612 0 R /XYZ 56.6929 376.9833 null]
 >> endobj
 1645 0 obj <<
-/D [1600 0 R /XYZ 56.6929 176.9408 null]
+/D [1612 0 R /XYZ 56.6929 350.2636 null]
 >> endobj
 1646 0 obj <<
-/D [1600 0 R /XYZ 56.6929 171.7724 null]
+/D [1612 0 R /XYZ 56.6929 345.0952 null]
 >> endobj
 1647 0 obj <<
-/D [1600 0 R /XYZ 56.6929 157.0677 null]
+/D [1612 0 R /XYZ 56.6929 321.0255 null]
 >> endobj
 1648 0 obj <<
-/D [1600 0 R /XYZ 56.6929 151.8395 null]
+/D [1612 0 R /XYZ 56.6929 313.2071 null]
 >> endobj
 1649 0 obj <<
-/D [1600 0 R /XYZ 56.6929 137.1348 null]
+/D [1612 0 R /XYZ 56.6929 298.5024 null]
 >> endobj
 1650 0 obj <<
-/D [1600 0 R /XYZ 56.6929 131.9066 null]
+/D [1612 0 R /XYZ 56.6929 293.2742 null]
 >> endobj
 1651 0 obj <<
-/D [1600 0 R /XYZ 56.6929 117.2018 null]
+/D [1612 0 R /XYZ 56.6929 267.8297 null]
 >> endobj
 1652 0 obj <<
-/D [1600 0 R /XYZ 56.6929 111.9736 null]
+/D [1612 0 R /XYZ 56.6929 261.3861 null]
 >> endobj
 1653 0 obj <<
-/D [1600 0 R /XYZ 56.6929 97.2091 null]
+/D [1612 0 R /XYZ 56.6929 199.468 null]
 >> endobj
 1654 0 obj <<
-/D [1600 0 R /XYZ 56.6929 92.0407 null]
+/D [1612 0 R /XYZ 56.6929 199.468 null]
 >> endobj
-1599 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
+1655 0 obj <<
+/D [1612 0 R /XYZ 56.6929 199.468 null]
 >> endobj
-1657 0 obj <<
-/Length 2544      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZKs㸾ûWè(U€ øÈM¶l&3¶#y²IÍî–`™ŠTHʳ³¿>
âA" É¦|0	4ñýu7º›ÂxS‘$˜DIàQ„éd{¸B“=ÌÝ_a)3WBsSêúùê/w$š$^úáäùÕX+öPãÉóîÛtñôtû°\ýs6÷)š.¼Ùœ"¤Fon7³y&|‚ð©M¯WןW÷ëÅÓlj‡~E-–âfóõþþvó|+o×·‹åêáDðì·çOW·ÏúµÍ­aDø;ÿçêÛoh²ƒ~ºBIb:ù7ÈÃIâOW%
Q#ùÕæêïzAc¶}tLU”ÄýhDW>ž`ì%”ú=eÑĉOZe-6b[GV¥MVµuWÃ[\ Kˈ cd	Žþm}wŠ"¿
11E^œÀû;@µÌ50MSêÅ¡&ì²<¤Y!öîY‘Õ
l¾¬j1Vvºhï÷§lÇ<þŽƒ-ázAÆðB|ÝBü‹'þ.Xsjâ¡|g‡V‰;œÄ‘gU6çKr¨Ûr(\Ii•S9Tî‚6”>Ķ¨Ý¿)‡R*^[Þ2mRqu—åL\ݔůùû“àAÞVÕÇSNÓ Ì HŸŠ§ö“©äãš±ªa‡TÎ=n›Ò #!V2ÂúªL);ZJ“‘`ßN†º#ã{œŒø(:¤¹ôb÷g)ñ1õÂ8öû”,ieúÆ{©fñô”V?4#¡‘vNQ|CÊÁˆ’RŒø##.hƒ‘!¶…üLù7UÖ°*“îñZJc]—e##Jz³aÕ;«êÑ(Åà‚qØçáZòð%-Š¬ØØî9Î?f”N³ß3fñO 0Âhê„,I!M’I\ƒ£°…"ùk-Õ]¾g‘giÍêS¬ù^Vÿî(ʶlœ£0ö"?ÆO’é!Ëåtš¤µœþ…ûQ•íßA‘‚ì%sŸ$¥WÌ߃V¸*Àæ
-i‡ÙL‚™‡&7;kž@£Ä‹¾)˜RvÖµ”¦=ö©v'tÇûö8ñ=ðì<§Ï3Œ10°Ï[½„(ßGSöò×ÙœþtUקÖ
-`¦µxf…ã‡âR+¦[%òñHQ
-ͳpUÉç[BX#îŽ"â6å¶ÌÇ¢.ñ¡Ä<`µ¸ëj¤uk“¹–ŸÓ†¾L3Ø¢2ÃTÆd!dõuD^FhK!E:	G@vᜀ-”È?1’ÐŽCHGh‡Å.ŽÇ<ÛêôFx5±Z>,TÉ0<&	`&„ÁC]†›»4o Em‰?´Q_à#ØL¾Ò¢Ž%Ïü}$Ïf®C@›Ô
ËóR3Ý‚lß4ßö¬ˆÂñN‰!¸›RÆ•”A9vPî‚68b[H7Á9£ÂÅØ|šÒ„»>»i*°5ÇÇ€%Á	OŒxêÊÅÚØÏçFâ(ŸWæÃEtšDœÀ‰múp€ÂŽq¾ŒÁ¸X«%œÏ|Q„«Ez„_çi±}cÍŸ <ˆ	TP—NsSÊN¸–2w¤ÁNèŽð3ìqÂ{àO§âǶÜ1ÀiÔÆùˆL¯!Ū[Âù}0eÈÈ;"";Œ~-2þ¨‡>ŒŽ 0¯ãFÔÅ
VC2nÌ[òP?µè…`[D¡õÓˆ…§RøŸrö³<û ¸Ò™'ˆQP"šW,O•,¡Öü €3„Fþ…üÀ”r˜‘’ÒÕÔ€3rAf4Ķ˜‘	þµn­ƒ @œáPeu®Ž™©óÑÍ`á FE:QÊ	Þ-àÁEÌ-ª—¬©ÚzHÌVaÑÀÍË©±ÈCfÕE`Mž*òUÖeÍŠ—ôtãüh—ÑB<ÕΪ˜@Ê%˜!dgQ	i#ìh	¹p;‡ÀãšÈ’žUõ“ø®SÁ^Nû=ga$G°™x˜À+Ï[ƒ%”–.PØU@åF·Ž
)‡’•T§åÄá*NhCÍCl‹žMp­ÏÍéx,«f îÏeºS-~XYôM/ŒÉ ßóÌ+!Õ`¨²z«”¾8VY®5Ní÷cEñ…V)åи’êjÖÀ‘Ç:¡
±-7ÁR³l¯:×iÙù ÂS…m^Štv´µ@àšöIxÔmƒÄŸ¦§ý›HJÇLßÞ%(‚
ÇÊ	SÊA„’ÒDÀQE:¡
"†Ø"Lp}"„:à—"wƒ‹›òpL‹€¸Z3ˆ÷ìÈ¡ ñ½ 6»;$!ÓOžxòo9+àdjG}í|æÎN™¿Êô+ÜËùG¨ÿê—mP”ëÃBcO‹ØʧQ/
-/¦”O-ÕñIÉ£ºãó{œÏøB÷FßYѵEï”Kɬ`à|*û㽜ÚÑ]9+áU}ŒÖÛtÙî&6Fãà/ƒ)¤Sz9j8®AÊ؉¼fP¶5rfE‹h®ˆýƒNT¥Žh‚?[ÞÐîKð¼zÐôkÉ¥ˆ/ƒAþýIRÔ9ãhÇpl§‰P/@Á…TÀ”r¥¤4Sp6;˜rAT
±-\™àKþåg²­›$œ.Nͨ¼ç‰!ù•lró›húÎûâíè›(dxñÁïyU–Ö\o·“u=êTt„GT‡:Pò>ŠÕwmû›OŠ\B4ÏÔÓ½@Dúv"¡Ê‚ê—=SÊA¤’ÒD&Èår.hƒÈ!¶…H\çt«§÷Påbüè¨Ò¢î’¼³/÷üÓjžlü›ò~tŽæÔËS¥=U_(W[½	Ö•³mر1R`(°ôÄ)öbHžú=ñÇ—ºÌYÃh`i‡cÎûUå{û;l1ã#j‹<ÄXl8GÁXܶ`JÙmAKU”ãPtBw¶p†=n=pa~8½íš&p×FOøÏÊ}•ßÀIs1òÙ‘`†¾Sš˜ÍQ<½ñăw©øþÈò\δ_L|¨–·o§ü&G7Rþ)gYS0ýÝ‘`É%Ì-¥»²È>ÈLGá÷ú1ÿC	‡/¡ÜÝ”rP¬¤tÞFŽBÙ	mP<ĶPl‚_g…>¶>§/LÕÌÙÙI;ZSȈ¥žH‚dü3ØM•~=’
-§ý©n4‰•%ˆtÓ`ÙYPBÝ'©ÈQG»p;†Àã˜ÈÂÉb§áY…Hvà¾)ù³¸†A•áÊ8åÀ~/öê»~¬¼VY³âÄ-}¼'`(ŠÌ¦Gœºâ>]ݲòÜ”öÜêF}îòŸùüÄÓ
-2jëHøÿûYF2òHlë¹B¦žDê¥øæ:|sýË­óWÿ/ÿ÷Ãendstream
-endobj
 1656 0 obj <<
-/Type /Page
-/Contents 1657 0 R
-/Resources 1655 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
+/D [1612 0 R /XYZ 56.6929 191.7053 null]
+>> endobj
+1657 0 obj <<
+/D [1612 0 R /XYZ 56.6929 176.9408 null]
 >> endobj
 1658 0 obj <<
-/D [1656 0 R /XYZ 85.0394 794.5015 null]
+/D [1612 0 R /XYZ 56.6929 171.7724 null]
 >> endobj
 1659 0 obj <<
-/D [1656 0 R /XYZ 85.0394 748.4854 null]
+/D [1612 0 R /XYZ 56.6929 157.0677 null]
 >> endobj
 1660 0 obj <<
-/D [1656 0 R /XYZ 85.0394 748.4854 null]
+/D [1612 0 R /XYZ 56.6929 151.8395 null]
 >> endobj
 1661 0 obj <<
-/D [1656 0 R /XYZ 85.0394 748.4854 null]
+/D [1612 0 R /XYZ 56.6929 137.1348 null]
 >> endobj
 1662 0 obj <<
-/D [1656 0 R /XYZ 85.0394 743.3452 null]
+/D [1612 0 R /XYZ 56.6929 131.9066 null]
 >> endobj
 1663 0 obj <<
-/D [1656 0 R /XYZ 85.0394 728.6405 null]
+/D [1612 0 R /XYZ 56.6929 117.2018 null]
 >> endobj
 1664 0 obj <<
-/D [1656 0 R /XYZ 85.0394 723.1655 null]
+/D [1612 0 R /XYZ 56.6929 111.9736 null]
 >> endobj
 1665 0 obj <<
-/D [1656 0 R /XYZ 85.0394 708.4607 null]
+/D [1612 0 R /XYZ 56.6929 97.2091 null]
 >> endobj
 1666 0 obj <<
-/D [1656 0 R /XYZ 85.0394 702.9857 null]
->> endobj
-1667 0 obj <<
-/D [1656 0 R /XYZ 85.0394 688.2211 null]
+/D [1612 0 R /XYZ 56.6929 92.0407 null]
 >> endobj
-1668 0 obj <<
-/D [1656 0 R /XYZ 85.0394 682.8059 null]
+1611 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F47 884 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
 1669 0 obj <<
-/D [1656 0 R /XYZ 85.0394 668.0414 null]
+/Length 2544      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZKs㸾ûWè(U€ øÈM¶l&3¶#y²IÍî–`™ŠTHʳ³¿>
âA" É¦|0	4ñýu7º›ÂxS‘$˜DIàQ„éd{¸B“=ÌÝ_a)3WBsSêúùê/w$š$^úáäùÕX+öPãÉóîÛtñôtû°\ýs6÷)š.¼Ùœ"¤Fon7³y&|‚ð©M¯WןW÷ëÅÓlj‡~E-–âfóõþþvó|+o×·‹åêáDðì·çOW·ÏúµÍ­aDø;ÿçêÛoh²ƒ~ºBIb:ù7ÈÃIâOW%
Q#ùÕæêïzAc¶}tLU”ÄýhDW>ž`ì%”ú=eÑĉOZe-6b[GV¥MVµuWÃ[\ Kˈ cd	Žþm}wŠ"¿
11E^œÀû;@µÌ50MSêÅ¡&ì²<¤Y!öîY‘Õ
l¾¬j1Vvºhï÷§lÇ<þŽƒ-ázAÆðB|ÝBü‹'þ.Xsjâ¡|g‡V‰;œÄ‘gU6çKr¨Ûr(\Ii•S9Tî‚6”>Ķ¨Ý¿)‡R*^[Þ2mRqu—åL\ݔůùû“àAÞVÕÇSNÓ Ì HŸŠ§ö“©äãš±ªa‡TÎ=n›Ò #!V2ÂúªL);ZJ“‘`ßN†º#ã{œŒø(:¤¹ôb÷g)ñ1õÂ8öû”,ieúÆ{©fñô”V?4#¡‘vNQ|CÊÁˆ’RŒø##.hƒ‘!¶…üLù7UÖ°*“îñZJc]—e##Jz³aÕ;«êÑ(Åà‚qØçáZòð%-Š¬ØØî9Î?f”N³ß3fñO 0Âhê„,I!M’I\ƒ£°…"ùk-Õ]¾g‘giÍêS¬ù^Vÿî(ʶlœ£0ö"?ÆO’é!Ëåtš¤µœþ…ûQ•íßA‘‚ì%sŸ$¥WÌ߃V¸*Àæ
+i‡ÙL‚™‡&7;kž@£Ä‹¾)˜RvÖµ”¦=ö©v'tÇûö8ñ=ðì<§Ï3Œ10°Ï[½„(ßGSöò×ÙœþtUקÖ
+`¦µxf…ã‡âR+¦[%òñHQ
+ͳpUÉç[BX#îŽ"â6å¶ÌÇ¢.ñ¡Ä<`µ¸ëj¤uk“¹–ŸÓ†¾L3Ø¢2ÃTÆd!dõuD^FhK!E:	G@vᜀ-”È?1’ÐŽCHGh‡Å.ŽÇ<ÛêôFx5±Z>,TÉ0<&	`&„ÁC]†›»4o Em‰?´Q_à#ØL¾Ò¢Ž%Ïü}$Ïf®C@›Ô
ËóR3Ý‚lß4ßö¬ˆÂñN‰!¸›RÆ•”A9vPî‚68b[H7Á9£ÂÅØ|šÒ„»>»i*°5ÇÇ€%Á	OŒxêÊÅÚØÏçFâ(ŸWæÃEtšDœÀ‰múp€ÂŽq¾ŒÁ¸X«%œÏ|Q„«Ez„_çi±}cÍŸ <ˆ	TP—NsSÊN¸–2w¤ÁNèŽð3ìqÂ{àO§âǶÜ1ÀiÔÆùˆL¯!Ū[Âù}0eÈÈ;"";Œ~-2þ¨‡>ŒŽ 0¯ãFÔÅ
VC2nÌ[òP?µè…`[D¡õÓˆ…§RøŸrö³<û ¸Ò™'ˆQP"šW,O•,¡Öü €3„Fþ…üÀ”r˜‘’ÒÕÔ€3rAf4Ķ˜‘	þµn­ƒ @œáPeu®Ž™©óÑÍ`á FE:QÊ	Þ-àÁEÌ-ª—¬©ÚzHÌVaÑÀÍË©±ÈCfÕE`Mž*òUÖeÍŠ—ôtãüh—ÑB<ÕΪ˜@Ê%˜!dgQ	i#ìh	¹p;‡ÀãšÈ’žUõ“ø®SÁ^Nû=ga$G°™x˜À+Ï[ƒ%”–.PØU@åF·Ž
)‡’•T§åÄá*NhCÍCl‹žMp­ÏÍéx,«f îÏeºS-~XYôM/ŒÉ ßóÌ+!Õ`¨²z«”¾8VY®5Ní÷cEñ…V)åи’êjÖÀ‘Ç:¡
±-7ÁR³l¯:×iÙù ÂS…m^Štv´µ@àšöIxÔmƒÄŸ¦§ý›HJÇLßÞ%(‚
ÇÊ	SÊA„’ÒDÀQE:¡
"†Ø"Lp}"„:à—"wƒ‹›òpL‹€¸Z3ˆ÷ìÈ¡ ñ½ 6»;$!ÓOžxòo9+àdjG}í|æÎN™¿Êô+ÜËùG¨ÿê—mP”ëÃBcO‹ØʧQ/
+/¦”O-ÕñIÉ£ºãó{œÏøB÷FßYѵEï”Kɬ`à|*û㽜ÚÑ]9+áU}ŒÖÛtÙî&6Fãà/ƒ)¤Sz9j8®AÊ؉¼fP¶5rfE‹h®ˆýƒNT¥Žh‚?[ÞÐîKð¼zÐôkÉ¥ˆ/ƒAþýIRÔ9ãhÇpl§‰P/@Á…TÀ”r¥¤4Sp6;˜rAT
±-\™àKþåg²­›$œ.Nͨ¼ç‰!ù•lró›húÎûâíè›(dxñÁïyU–Ö\o·“u=êTt„GT‡:Pò>ŠÕwmû›OŠ\B4ÏÔÓ½@Dúv"¡Ê‚ê—=SÊA¤’ÒD&Èår.hƒÈ!¶…H\çt«§÷Påbüè¨Ò¢î’¼³/÷üÓjžlü›ò~tŽæÔËS¥=U_(W[½	Ö•³mر1R`(°ôÄ)öbHžú=ñÇ—ºÌYÃh`i‡cÎûUå{û;l1ã#j‹<ÄXl8GÁXܶ`JÙmAKU”ãPtBw¶p†=n=pa~8½íš&p×FOøÏÊ}•ßÀIs1òÙ‘`†¾Sš˜ÍQ<½ñăw©øþÈò\δ_L|¨–·o§ü&G7Rþ)gYS0ýÝ‘`É%Ì-¥»²È>ÈLGá÷ú1ÿC	‡/¡ÜÝ”rP¬¤tÞFŽBÙ	mP<ĶPl‚_g…>¶>§/LÕÌÙÙI;ZSȈ¥žH‚dü3ØM•~=’
+§ý©n4‰•%ˆtÓ`ÙYPBÝ'©ÈQG»p;†Àã˜ÈÂÉb§áY…Hvà¾)ù³¸†A•áÊ8åÀ~/öê»~¬¼VY³âÄ-}¼'`(ŠÌ¦Gœºâ>]ݲòÜ”öÜêF}îòŸùüÄÓ
+2jëHøÿûYF2òHlë¹B¦žDê¥øæ:|sýË­óWÿ/ÿ÷Ãendstream
+endobj
+1668 0 obj <<
+/Type /Page
+/Contents 1669 0 R
+/Resources 1667 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1541 0 R
 >> endobj
 1670 0 obj <<
-/D [1656 0 R /XYZ 85.0394 662.6262 null]
+/D [1668 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 1671 0 obj <<
-/D [1656 0 R /XYZ 85.0394 599.7666 null]
+/D [1668 0 R /XYZ 85.0394 748.4854 null]
 >> endobj
 1672 0 obj <<
-/D [1656 0 R /XYZ 85.0394 599.7666 null]
+/D [1668 0 R /XYZ 85.0394 748.4854 null]
 >> endobj
 1673 0 obj <<
-/D [1656 0 R /XYZ 85.0394 599.7666 null]
+/D [1668 0 R /XYZ 85.0394 748.4854 null]
 >> endobj
 1674 0 obj <<
-/D [1656 0 R /XYZ 85.0394 591.7571 null]
+/D [1668 0 R /XYZ 85.0394 743.3452 null]
 >> endobj
 1675 0 obj <<
-/D [1656 0 R /XYZ 85.0394 565.0374 null]
+/D [1668 0 R /XYZ 85.0394 728.6405 null]
 >> endobj
 1676 0 obj <<
-/D [1656 0 R /XYZ 85.0394 559.6222 null]
+/D [1668 0 R /XYZ 85.0394 723.1655 null]
 >> endobj
 1677 0 obj <<
-/D [1656 0 R /XYZ 85.0394 534.1777 null]
+/D [1668 0 R /XYZ 85.0394 708.4607 null]
 >> endobj
 1678 0 obj <<
-/D [1656 0 R /XYZ 85.0394 527.4872 null]
+/D [1668 0 R /XYZ 85.0394 702.9857 null]
 >> endobj
 1679 0 obj <<
-/D [1656 0 R /XYZ 85.0394 502.0427 null]
+/D [1668 0 R /XYZ 85.0394 688.2211 null]
 >> endobj
 1680 0 obj <<
-/D [1656 0 R /XYZ 85.0394 495.3523 null]
+/D [1668 0 R /XYZ 85.0394 682.8059 null]
 >> endobj
 1681 0 obj <<
-/D [1656 0 R /XYZ 85.0394 420.5376 null]
+/D [1668 0 R /XYZ 85.0394 668.0414 null]
 >> endobj
 1682 0 obj <<
-/D [1656 0 R /XYZ 85.0394 420.5376 null]
+/D [1668 0 R /XYZ 85.0394 662.6262 null]
 >> endobj
 1683 0 obj <<
-/D [1656 0 R /XYZ 85.0394 420.5376 null]
+/D [1668 0 R /XYZ 85.0394 599.7666 null]
 >> endobj
 1684 0 obj <<
-/D [1656 0 R /XYZ 85.0394 412.5281 null]
+/D [1668 0 R /XYZ 85.0394 599.7666 null]
 >> endobj
 1685 0 obj <<
-/D [1656 0 R /XYZ 85.0394 388.4584 null]
+/D [1668 0 R /XYZ 85.0394 599.7666 null]
 >> endobj
 1686 0 obj <<
-/D [1656 0 R /XYZ 85.0394 380.3932 null]
+/D [1668 0 R /XYZ 85.0394 591.7571 null]
 >> endobj
 1687 0 obj <<
-/D [1656 0 R /XYZ 85.0394 365.6884 null]
+/D [1668 0 R /XYZ 85.0394 565.0374 null]
 >> endobj
 1688 0 obj <<
-/D [1656 0 R /XYZ 85.0394 360.2134 null]
+/D [1668 0 R /XYZ 85.0394 559.6222 null]
 >> endobj
 1689 0 obj <<
-/D [1656 0 R /XYZ 85.0394 345.4488 null]
+/D [1668 0 R /XYZ 85.0394 534.1777 null]
 >> endobj
 1690 0 obj <<
-/D [1656 0 R /XYZ 85.0394 340.0336 null]
+/D [1668 0 R /XYZ 85.0394 527.4872 null]
 >> endobj
 1691 0 obj <<
-/D [1656 0 R /XYZ 85.0394 325.269 null]
+/D [1668 0 R /XYZ 85.0394 502.0427 null]
 >> endobj
 1692 0 obj <<
-/D [1656 0 R /XYZ 85.0394 319.8539 null]
+/D [1668 0 R /XYZ 85.0394 495.3523 null]
 >> endobj
 1693 0 obj <<
-/D [1656 0 R /XYZ 85.0394 295.7842 null]
+/D [1668 0 R /XYZ 85.0394 420.5376 null]
 >> endobj
 1694 0 obj <<
-/D [1656 0 R /XYZ 85.0394 287.7189 null]
+/D [1668 0 R /XYZ 85.0394 420.5376 null]
 >> endobj
 1695 0 obj <<
-/D [1656 0 R /XYZ 85.0394 272.9543 null]
+/D [1668 0 R /XYZ 85.0394 420.5376 null]
 >> endobj
 1696 0 obj <<
-/D [1656 0 R /XYZ 85.0394 267.5392 null]
+/D [1668 0 R /XYZ 85.0394 412.5281 null]
 >> endobj
 1697 0 obj <<
-/D [1656 0 R /XYZ 85.0394 252.7746 null]
+/D [1668 0 R /XYZ 85.0394 388.4584 null]
 >> endobj
 1698 0 obj <<
-/D [1656 0 R /XYZ 85.0394 247.3594 null]
+/D [1668 0 R /XYZ 85.0394 380.3932 null]
 >> endobj
 1699 0 obj <<
-/D [1656 0 R /XYZ 85.0394 223.2897 null]
+/D [1668 0 R /XYZ 85.0394 365.6884 null]
 >> endobj
 1700 0 obj <<
-/D [1656 0 R /XYZ 85.0394 215.2245 null]
+/D [1668 0 R /XYZ 85.0394 360.2134 null]
 >> endobj
 1701 0 obj <<
-/D [1656 0 R /XYZ 85.0394 149.4956 null]
+/D [1668 0 R /XYZ 85.0394 345.4488 null]
 >> endobj
 1702 0 obj <<
-/D [1656 0 R /XYZ 85.0394 149.4956 null]
+/D [1668 0 R /XYZ 85.0394 340.0336 null]
 >> endobj
 1703 0 obj <<
-/D [1656 0 R /XYZ 85.0394 149.4956 null]
+/D [1668 0 R /XYZ 85.0394 325.269 null]
 >> endobj
 1704 0 obj <<
-/D [1656 0 R /XYZ 85.0394 144.3554 null]
+/D [1668 0 R /XYZ 85.0394 319.8539 null]
 >> endobj
 1705 0 obj <<
-/D [1656 0 R /XYZ 85.0394 120.2857 null]
+/D [1668 0 R /XYZ 85.0394 295.7842 null]
 >> endobj
 1706 0 obj <<
-/D [1656 0 R /XYZ 85.0394 112.2205 null]
+/D [1668 0 R /XYZ 85.0394 287.7189 null]
 >> endobj
 1707 0 obj <<
-/D [1656 0 R /XYZ 85.0394 97.4559 null]
+/D [1668 0 R /XYZ 85.0394 272.9543 null]
 >> endobj
 1708 0 obj <<
-/D [1656 0 R /XYZ 85.0394 92.0407 null]
+/D [1668 0 R /XYZ 85.0394 267.5392 null]
 >> endobj
-1655 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
-/ProcSet [ /PDF /Text ]
+1709 0 obj <<
+/D [1668 0 R /XYZ 85.0394 252.7746 null]
 >> endobj
-1711 0 obj <<
-/Length 2122      
-/Filter /FlateDecode
->>
-stream
-xÚ¥YKs㸾ûWèª*Bðà37ÙÒ8žñÚŽå­d33š‚%–)R+RžÑþú4Ð J$µ•”n ?ôQø±‘ç?âÑ(ˆ\âQæ’Í­`ìöŠžIÍ4±¹®_®þöI£ˆD>÷G/o–¬Ð0d£—åWgJƒê\ß]ßß=Þ>OŸþñÛxÂ=ê|£>Ì°³øõöv¾x™›îó|:»{¸6ž~DéÓÓüav÷oŸ*©´¡ÞÌãï/Ÿ¯æ/Ͳí­1*Ôš¿úúŽ–°ÃÏW”ˆ(ôF? C	‹">Ú\¹ž ž+DMÉ®WÿlZ£zj§©%\ø¼ÃVœ#‘çñ–±¼ˆø‚m¬ÇײÈd%—¸ÇÙÃÂØF&û]ZŒi>Ý”½›.4htG‹×&ºp¬¹ÔÒ¾‚VN}ïû©fÆ9XņU7\çº]û1mݳb§ùxârê<Ä©ZÌYÊJnz4™ÿ¬d^¦E®Ít²;R„ëR²ÿ
-S|á̈™—U¿Ë1Ã×»1%ê‰sÓ¸1ü_âýÛ&ΔÏq¾w¥¶\+š4°ƒ>8WéEº$Ä£:Þ‘i;ÃÔ@ÇD0Ý€^¹ÅÝÀYŠ5*ÊzÒœgƒ£j#Žúp5Ç!7i‚_·Ë¸’]FŒ¸<² Ôs	~k
ÙàgzÓí.Í°9ˆ„ú$(†ÂæêÇ¢ájÀðÄ€
ª>¢q¦»Ž–îËöoša?
-‰"ïÀà—Xw“uƒCÔƒ’Hò’Í5€CÍUã (
pRmápª»[wƒCƒƒjÕ8èvƒƒ'!,æ7˜5GºÊÓ|…é¾Zšÿ'î3HW‘î8w®	Nü×8âŽÌ2T:Šqá<ró*wÆêù­(Æ)¥ý˜‰ˆP7º„™Å5€YÍuÄ,¢˜
©¶0;ÕÝ™­»'7.‚Ý›,Þ¥ß(åI\5ÄúûŸ"¯]®Š«}—Sqð°íUsãU÷òGZv;ÂúáŒ0懱¸©¹@\w(˜
©¶9ÕÝ
ˆ­û>ݤzdéj­¼Rð")¶iÅ’̘ë|™ÿ†”gY˜™3ô,“b·Ä¶r·çgíjÁ¢€[qOMQqO	þ%.Ky@š®ô’ˆÑQ”* 
-p¹™Ll«ežúï…ÔƒÈyx¡Î³¹ú!m¸H}oÒAÕGHÏtwBÚÒý,—R9Ož¢óˆ€!ˆðÕþ'ªcÌ«ù³BëB®øZ\ϳéØóœå™S$}*v›¸3ú°ò»mçÀqº_íËê«Ó‡±‰€á2ª!áA¹Gýæ‘'.Î]rsi$Ívñ[ÕULSHÊ.Dæj	֬ЫgA¾»Yi¬ƒqc$èèv±_­'K5‰?ŠÝ».>Õüe‘ì7P“”8¦JõÕu§okžç«4—rg¦cÇå;2ƒ¹Ñ…ՃѵÄ%Úö"³F]¼„Ž¾N#¡þ̤FøRt¿ÇZ[œžA«'+M,«x%Klcáå;Kù!³b«ö+ò#æÜm¶™Týbg¤7öR“x¯g“•Q]´·eÎ\Åõ+‡ãX`#Ö_áÔwô#ÎÔY
-ë˜èÊÿ€\åºØg†ªµªÆ«ÄïïûßUQg5 %©!¹Ú>Zcn„½©SŸ!Ñƺû<3þ$)6“.|¶qžjéŒ:¯ü≀Æ2-“,N7:‡ê¸jXóñBçç®:s%võrá‹(+d-K¢øpuüa„ÄøÉÒ7YÂò°§O+|Ëô'66E^­Í\8ïõ¬S¸lvlԬسW¥´^²“©¶~Ö3¯f*IM=ëÇŒ²38Ðó  LPxuµbá¥ÂÎk±7±âúîav”ëB±ê7r)‰X}y“;åF½Ïì<„RïÂõËæ:O&°lâ(LgÖŸGµóÈ™ÚÎ<ÒÒŠy„zÆ­¨o[Ê^´5Vć9Oñ>ÃIÓ.\œHºSá¤É»ŽпO÷j"s¡âÜvéj­“ˈ!lÀ
Õß+Ô¼ '¸ˆàÇ%L8	üöiñ}£ÌëºpØbXWŸ,ŠB\ÛB¾ÆeUlM ÈÞLÿŽ#y†‚43OøÜSºN®tM52…kE’ÂY.{‹8¬ê£¼hs¬ÿïÿ¥¬ê% "컊p°¯‚³(µ—È?[yýÖùÒÿš¸¥endstream
-endobj
 1710 0 obj <<
-/Type /Page
-/Contents 1711 0 R
-/Resources 1709 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
+/D [1668 0 R /XYZ 85.0394 247.3594 null]
+>> endobj
+1711 0 obj <<
+/D [1668 0 R /XYZ 85.0394 223.2897 null]
 >> endobj
 1712 0 obj <<
-/D [1710 0 R /XYZ 56.6929 794.5015 null]
+/D [1668 0 R /XYZ 85.0394 215.2245 null]
 >> endobj
 1713 0 obj <<
-/D [1710 0 R /XYZ 56.6929 749.4437 null]
+/D [1668 0 R /XYZ 85.0394 149.4956 null]
 >> endobj
 1714 0 obj <<
-/D [1710 0 R /XYZ 56.6929 749.4437 null]
+/D [1668 0 R /XYZ 85.0394 149.4956 null]
 >> endobj
 1715 0 obj <<
-/D [1710 0 R /XYZ 56.6929 749.4437 null]
+/D [1668 0 R /XYZ 85.0394 149.4956 null]
 >> endobj
 1716 0 obj <<
-/D [1710 0 R /XYZ 56.6929 746.6461 null]
+/D [1668 0 R /XYZ 85.0394 144.3554 null]
 >> endobj
 1717 0 obj <<
-/D [1710 0 R /XYZ 56.6929 722.5763 null]
+/D [1668 0 R /XYZ 85.0394 120.2857 null]
 >> endobj
 1718 0 obj <<
-/D [1710 0 R /XYZ 56.6929 716.7581 null]
+/D [1668 0 R /XYZ 85.0394 112.2205 null]
 >> endobj
 1719 0 obj <<
-/D [1710 0 R /XYZ 56.6929 701.9936 null]
+/D [1668 0 R /XYZ 85.0394 97.4559 null]
 >> endobj
 1720 0 obj <<
-/D [1710 0 R /XYZ 56.6929 698.8254 null]
+/D [1668 0 R /XYZ 85.0394 92.0407 null]
 >> endobj
-1721 0 obj <<
-/D [1710 0 R /XYZ 56.6929 684.1207 null]
->> endobj
-1722 0 obj <<
-/D [1710 0 R /XYZ 56.6929 680.8926 null]
+1667 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F47 884 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
 1723 0 obj <<
-/D [1710 0 R /XYZ 56.6929 656.8229 null]
+/Length 2122      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥YKs㸾ûWèª*Bðà37ÙÒ8žñÚŽå­d33š‚%–)R+RžÑþú4Ð J$µ•”n ?ôQø±‘ç?âÑ(ˆ\âQæ’Í­`ìöŠžIÍ4±¹®_®þöI£ˆD>÷G/o–¬Ð0d£—åWgJƒê\ß]ßß=Þ>OŸþñÛxÂ=ê|£>Ì°³øõöv¾x™›îó|:»{¸6ž~DéÓÓüav÷oŸ*©´¡ÞÌãï/Ÿ¯æ/Ͳí­1*Ôš¿úúŽ–°ÃÏW”ˆ(ôF? C	‹">Ú\¹ž ž+DMÉ®WÿlZ£zj§©%\ø¼ÃVœ#‘çñ–±¼ˆø‚m¬ÇײÈd%—¸ÇÙÃÂØF&û]ZŒi>Ý”½›.4htG‹×&ºp¬¹ÔÒ¾‚VN}ïû©fÆ9XņU7\çº]û1mݳb§ùxârê<Ä©ZÌYÊJnz4™ÿ¬d^¦E®Ít²;R„ëR²ÿ
+S|á̈™—U¿Ë1Ã×»1%ê‰sÓ¸1ü_âýÛ&ΔÏq¾w¥¶\+š4°ƒ>8WéEº$Ä£:Þ‘i;ÃÔ@ÇD0Ý€^¹ÅÝÀYŠ5*ÊzÒœgƒ£j#Žúp5Ç!7i‚_·Ë¸’]FŒ¸<² Ôs	~k
ÙàgzÓí.Í°9ˆ„ú$(†ÂæêÇ¢ájÀðÄ€
ª>¢q¦»Ž–îËöoša?
+‰"ïÀà—Xw“uƒCÔƒ’Hò’Í5€CÍUã (
pRmápª»[wƒCƒƒjÕ8èvƒƒ'!,æ7˜5GºÊÓ|…é¾Zšÿ'î3HW‘î8w®	Nü×8âŽÌ2T:Šqá<ró*wÆêù­(Æ)¥ý˜‰ˆP7º„™Å5€YÍuÄ,¢˜
©¶0;ÕÝ™­»'7.‚Ý›,Þ¥ß(åI\5ÄúûŸ"¯]®Š«}—Sqð°íUsãU÷òGZv;ÂúáŒ0懱¸©¹@\w(˜
©¶9ÕÝ
ˆ­û>ݤzdéj­¼Rð")¶iÅ’̘ë|™ÿ†”gY˜™3ô,“b·Ä¶r·çgíjÁ¢€[qOMQqO	þ%.Ky@š®ô’ˆÑQ”* 
+p¹™Ll«ežúï…ÔƒÈyx¡Î³¹ú!m¸H}oÒAÕGHÏtwBÚÒý,—R9Ož¢óˆ€!ˆðÕþ'ªcÌ«ù³BëB®øZ\ϳéØóœå™S$}*v›¸3ú°ò»mçÀqº_íËê«Ó‡±‰€á2ª!áA¹Gýæ‘'.Î]rsi$Ívñ[ÕULSHÊ.Dæj	֬ЫgA¾»Yi¬ƒqc$èèv±_­'K5‰?ŠÝ».>Õüe‘ì7P“”8¦JõÕu§okžç«4—rg¦cÇå;2ƒ¹Ñ…ՃѵÄ%Úö"³F]¼„Ž¾N#¡þ̤FøRt¿ÇZ[œžA«'+M,«x%Klcáå;Kù!³b«ö+ò#æÜm¶™Týbg¤7öR“x¯g“•Q]´·eÎ\Åõ+‡ãX`#Ö_áÔwô#ÎÔY
+ë˜èÊÿ€\åºØg†ªµªÆ«ÄïïûßUQg5 %©!¹Ú>Zcn„½©SŸ!Ñƺû<3þ$)6“.|¶qžjéŒ:¯ü≀Æ2-“,N7:‡ê¸jXóñBçç®:s%võrá‹(+d-K¢øpuüa„ÄøÉÒ7YÂò°§O+|Ëô'66E^­Í\8ïõ¬S¸lvlԬسW¥´^²“©¶~Ö3¯f*IM=ëÇŒ²38Ðó  LPxuµbá¥ÂÎk±7±âúîav”ëB±ê7r)‰X}y“;åF½Ïì<„RïÂõËæ:O&°lâ(LgÖŸGµóÈ™ÚÎ<ÒÒŠy„zÆ­¨o[Ê^´5Vć9Oñ>ÃIÓ.\œHºSá¤É»ŽпO÷j"s¡âÜvéj­“ˈ!lÀ
Õß+Ô¼ '¸ˆàÇ%L8	üöiñ}£ÌëºpØbXWŸ,ŠB\ÛB¾ÆeUlM ÈÞLÿŽ#y†‚43OøÜSºN®tM52…kE’ÂY.{‹8¬ê£¼hs¬ÿïÿ¥¬ê% "컊p°¯‚³(µ—È?[yýÖùÒÿš¸¥endstream
+endobj
+1722 0 obj <<
+/Type /Page
+/Contents 1723 0 R
+/Resources 1721 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1541 0 R
 >> endobj
 1724 0 obj <<
-/D [1710 0 R /XYZ 56.6929 651.0047 null]
+/D [1722 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 1725 0 obj <<
-/D [1710 0 R /XYZ 56.6929 636.3 null]
+/D [1722 0 R /XYZ 56.6929 749.4437 null]
 >> endobj
 1726 0 obj <<
-/D [1710 0 R /XYZ 56.6929 633.072 null]
+/D [1722 0 R /XYZ 56.6929 749.4437 null]
 >> endobj
 1727 0 obj <<
-/D [1710 0 R /XYZ 56.6929 609.0023 null]
+/D [1722 0 R /XYZ 56.6929 749.4437 null]
 >> endobj
 1728 0 obj <<
-/D [1710 0 R /XYZ 56.6929 603.184 null]
+/D [1722 0 R /XYZ 56.6929 746.6461 null]
 >> endobj
 1729 0 obj <<
-/D [1710 0 R /XYZ 56.6929 579.1143 null]
+/D [1722 0 R /XYZ 56.6929 722.5763 null]
 >> endobj
 1730 0 obj <<
-/D [1710 0 R /XYZ 56.6929 573.2961 null]
+/D [1722 0 R /XYZ 56.6929 716.7581 null]
 >> endobj
 1731 0 obj <<
-/D [1710 0 R /XYZ 56.6929 558.5914 null]
+/D [1722 0 R /XYZ 56.6929 701.9936 null]
 >> endobj
 1732 0 obj <<
-/D [1710 0 R /XYZ 56.6929 555.3634 null]
+/D [1722 0 R /XYZ 56.6929 698.8254 null]
 >> endobj
 1733 0 obj <<
-/D [1710 0 R /XYZ 56.6929 540.5988 null]
+/D [1722 0 R /XYZ 56.6929 684.1207 null]
 >> endobj
 1734 0 obj <<
-/D [1710 0 R /XYZ 56.6929 537.4306 null]
+/D [1722 0 R /XYZ 56.6929 680.8926 null]
 >> endobj
 1735 0 obj <<
-/D [1710 0 R /XYZ 56.6929 510.7109 null]
+/D [1722 0 R /XYZ 56.6929 656.8229 null]
 >> endobj
 1736 0 obj <<
-/D [1710 0 R /XYZ 56.6929 507.5427 null]
->> endobj
-598 0 obj <<
-/D [1710 0 R /XYZ 56.6929 477.5928 null]
+/D [1722 0 R /XYZ 56.6929 651.0047 null]
 >> endobj
 1737 0 obj <<
-/D [1710 0 R /XYZ 56.6929 453.2532 null]
->> endobj
-602 0 obj <<
-/D [1710 0 R /XYZ 56.6929 369.7201 null]
+/D [1722 0 R /XYZ 56.6929 636.3 null]
 >> endobj
 1738 0 obj <<
-/D [1710 0 R /XYZ 56.6929 345.3805 null]
+/D [1722 0 R /XYZ 56.6929 633.072 null]
 >> endobj
 1739 0 obj <<
-/D [1710 0 R /XYZ 56.6929 310.6805 null]
+/D [1722 0 R /XYZ 56.6929 609.0023 null]
 >> endobj
 1740 0 obj <<
-/D [1710 0 R /XYZ 56.6929 310.6805 null]
+/D [1722 0 R /XYZ 56.6929 603.184 null]
 >> endobj
 1741 0 obj <<
-/D [1710 0 R /XYZ 56.6929 310.6805 null]
+/D [1722 0 R /XYZ 56.6929 579.1143 null]
 >> endobj
 1742 0 obj <<
-/D [1710 0 R /XYZ 56.6929 310.6805 null]
+/D [1722 0 R /XYZ 56.6929 573.2961 null]
 >> endobj
-1709 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F14 685 0 R >>
-/ProcSet [ /PDF /Text ]
+1743 0 obj <<
+/D [1722 0 R /XYZ 56.6929 558.5914 null]
+>> endobj
+1744 0 obj <<
+/D [1722 0 R /XYZ 56.6929 555.3634 null]
 >> endobj
 1745 0 obj <<
+/D [1722 0 R /XYZ 56.6929 540.5988 null]
+>> endobj
+1746 0 obj <<
+/D [1722 0 R /XYZ 56.6929 537.4306 null]
+>> endobj
+1747 0 obj <<
+/D [1722 0 R /XYZ 56.6929 510.7109 null]
+>> endobj
+1748 0 obj <<
+/D [1722 0 R /XYZ 56.6929 507.5427 null]
+>> endobj
+602 0 obj <<
+/D [1722 0 R /XYZ 56.6929 477.5928 null]
+>> endobj
+1749 0 obj <<
+/D [1722 0 R /XYZ 56.6929 453.2532 null]
+>> endobj
+606 0 obj <<
+/D [1722 0 R /XYZ 56.6929 369.7201 null]
+>> endobj
+1750 0 obj <<
+/D [1722 0 R /XYZ 56.6929 345.3805 null]
+>> endobj
+1751 0 obj <<
+/D [1722 0 R /XYZ 56.6929 310.6805 null]
+>> endobj
+1752 0 obj <<
+/D [1722 0 R /XYZ 56.6929 310.6805 null]
+>> endobj
+1753 0 obj <<
+/D [1722 0 R /XYZ 56.6929 310.6805 null]
+>> endobj
+1754 0 obj <<
+/D [1722 0 R /XYZ 56.6929 310.6805 null]
+>> endobj
+1721 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F47 884 0 R /F14 689 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1757 0 obj <<
 /Length 1944      
 /Filter /FlateDecode
 >>
@@ -7501,42 +7545,42 @@ xÚµX[
 Yô¦?ÿûãçOþóš^·œA4‚h£ùè/Ð)ˆä~UŪ¾kr Ã¹¨H9:…ÛÊÏ%‘ŒŸÕ#öŠž¸Ž›´-äÏUÌ:Î\ÇÅË9æ)8ëlÚ¹÷
&”¬Û;übWƒwñ‹¿7ø–Ù唩
ÄtU´8	µFÃU¸¡i¬²O¶B¾²?L/3“|(±ÉrtìÜÂ3?+À[FA|œO®7
Lg¯ÔÐ
 ž{äÅ\Äî6]^ªŠ\Lªb(‡Óòúp,¿8p¿øõà0Íê¢Wõr½f9$
5Jöã¢d1|ÆsO¤GêøHƒ±³~¢	E;H#|ú¸½‹	VÆú@¨ÂÙYíß}ŒüàŽ¡	5»-÷a;zs»icŸì½Ä
ƒ—ówøñyLÜϲ³íÀ’yðÙÉo#TÃó,9òìü´ñ÷Ý—ÇýóUžéendstream
 endobj
-1744 0 obj <<
+1756 0 obj <<
 /Type /Page
-/Contents 1745 0 R
-/Resources 1743 0 R
+/Contents 1757 0 R
+/Resources 1755 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1764 0 R
 >> endobj
-1746 0 obj <<
-/D [1744 0 R /XYZ 85.0394 794.5015 null]
+1758 0 obj <<
+/D [1756 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-606 0 obj <<
-/D [1744 0 R /XYZ 85.0394 769.5949 null]
+610 0 obj <<
+/D [1756 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1747 0 obj <<
-/D [1744 0 R /XYZ 85.0394 573.0107 null]
+1759 0 obj <<
+/D [1756 0 R /XYZ 85.0394 573.0107 null]
 >> endobj
-610 0 obj <<
-/D [1744 0 R /XYZ 85.0394 573.0107 null]
+614 0 obj <<
+/D [1756 0 R /XYZ 85.0394 573.0107 null]
 >> endobj
-1748 0 obj <<
-/D [1744 0 R /XYZ 85.0394 538.4209 null]
+1760 0 obj <<
+/D [1756 0 R /XYZ 85.0394 538.4209 null]
 >> endobj
-1749 0 obj <<
-/D [1744 0 R /XYZ 85.0394 504.6118 null]
+1761 0 obj <<
+/D [1756 0 R /XYZ 85.0394 504.6118 null]
 >> endobj
-1750 0 obj <<
-/D [1744 0 R /XYZ 85.0394 432.7569 null]
+1762 0 obj <<
+/D [1756 0 R /XYZ 85.0394 432.7569 null]
 >> endobj
-1751 0 obj <<
-/D [1744 0 R /XYZ 85.0394 303.3232 null]
+1763 0 obj <<
+/D [1756 0 R /XYZ 85.0394 303.3232 null]
 >> endobj
-1743 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
+1755 0 obj <<
+/Font << /F21 662 0 R /F23 686 0 R /F39 868 0 R /F53 967 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1755 0 obj <<
+1767 0 obj <<
 /Length 3825      
 /Filter /FlateDecode
 >>
@@ -7555,62 +7599,67 @@ b
 "BV˜ñI§ë†¾xÀfHÏqàÛw/çï^%cÁ8`–Y(bOud)ú	O¨&y¢álD
 ×Tˆc÷Âà)†Ì‰HÉ´õ0QÉÓÁù âþ“I‘r5Æ|Äï4K‹0ANEÞóTS_Q-ëÁ'ïÑþ´ôŸõnx’»¢ÂK2œvE”'0«
 ‚ÕrœÀ4d‹VM}­°¢Æ¾ÌáK‰ÿù{éã×àÚDÊÚ‰o|bc#mafʆìé§Lüaõ)ëÿÜÈûendstream
 endobj
-1754 0 obj <<
+1766 0 obj <<
 /Type /Page
-/Contents 1755 0 R
-/Resources 1753 0 R
+/Contents 1767 0 R
+/Resources 1765 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1764 0 R
 >> endobj
-1756 0 obj <<
-/D [1754 0 R /XYZ 56.6929 794.5015 null]
+1768 0 obj <<
+/D [1766 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1757 0 obj <<
-/D [1754 0 R /XYZ 56.6929 752.1413 null]
+1769 0 obj <<
+/D [1766 0 R /XYZ 56.6929 752.1413 null]
 >> endobj
-1758 0 obj <<
-/D [1754 0 R /XYZ 56.6929 501.191 null]
+1770 0 obj <<
+/D [1766 0 R /XYZ 56.6929 501.191 null]
 >> endobj
-1753 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R /F53 962 0 R /F11 1304 0 R >>
+1765 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F48 890 0 R /F53 967 0 R /F11 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1761 0 obj <<
-/Length 2980      
-/Filter /FlateDecode
->>
-stream
-xÚ­Zmoã6þž_áoç µJŠ¤$ÐÙͶHÑnÓ&‹ëa›Š%ÇBl)µääüïo†CR/–”ÃÝa5EŽ8Çç…
-_0ølj
-˜Ðrk(ÆÕb½¿`‹'ûñ‚[™•Zu¥>Ü_|÷ƒˆ:ÐQ-î7¹’€%	_Üg_—W··Ÿ>_ßüq¹
-[~.WŠ±å/WŸ¿\ýL}·—:\^ýøé#ÅBâ(±åõÍ—÷?]|º÷Æt
æL %]|}`‹ìþé‚B'jñ,àZ‡‹ý…T"PR׳»¸»øÍOØ5¯Ž D¨$ŒGÅJ‘€!DàczlŠª¼\	/ëmuÜeÔ~Ìé·IŸs;ü¶u­c]”Ov|›#
-€¶îèâ‰’„)°µ¬N$Ó³‡ƒ=\p+R½´v¸ßýq׫c¬}§ºÉ÷5=¤uk€i<ç'lDËuZö×ðZÔÅãÎ>%Ú²XÚA¢E-h¥Bc†™-ŒÅ²:6/ÇÛr¹9\òdYíiä¥þ“Ê𷢃™Í³Ÿ£Þæ»ÝßjzØuSN$ú'cá."‰„-ÿapE‹+6ïï€^FvšbB8úV4[)ï@*tH‘„Ó¬xÃ]„¬Ì·8¡nm.Ó}NI8WØ‹WÜŽPá;)¤’eQSÏ_ÇüPä=”yžÕ4ÞTÔõ\VoîÝœ†Ì®aOZÚ÷ÒÝSu€õíí»V‹öZsB	¢(¢åMI£n>_ë”ußÀ¬*s;‰¡$€`—Gá…vúµÈ¬
-¶L_lçË¡H›|uÎX ­-¢¸¢ÔuÀt"¬.vd";õùT\EEN¬«ö@šì%~Îcj&í+¸ÇY°®ÊÍÈìàbpV4ðfzl«Pƒ?ŠpºB2–±‘ýí˧ß/•Zþ“ùõöþæ×Ïw#ëÐÃ(HT¬çh<ä±µ£Ý˜×É&ø“,ËãþѺª
õ!
O¶Ë¸ûÊÛ¶¸äËõÖN°Á)7ùº¡g¢$t½¥öes ±c[¸—vUõ||q&£ì[û4Ëm·a2OÜŒzIr5¸³Ú:»¸ÞÙÊŠúe—žˆÑàÇîª=¾/Z˜0¾®¶]uÞرY®<ŒHŸ¨ýXrˆ˜V$œe¢…
-ƶ9¬àp	dËÚëÏò&?ì‹Ò>:<à¥à³{;†§+-ë7rlùd…«²É³oíi#/À–Ìq°”Gë; QìóêØÞ$ ³,x¬›§"¯o“Àvilú”ÒÖÆ-kŒ°Û¸èæFÇmŒ‹ÐP,ƒDF²OX‚ɨQË{ËM&á(à:™2;HàȉFh/¡¶	]îH*I‰se5æ+¸·Ð¹7m`î2B‡m¦·zÀ¶<-É·C¯á«±ÂÄèé@d×õ+‘Äzø\B–€qœ÷qIkÚO@mùšîŽè²Æ0ìóN	;wÅsNÝ”É`ÃñÇñt`0Gêa>ÑÀ6}¾¸©û1òð(ˆíÒ‚ohÙ÷ƶ8DIúà“^:'6E`àþ•ìóÖçⱤ­ÿûYªÌ¦ 
W2ÂBÉhno…V])“ÙÊd$³õRf•_Ëê¡Y¿sTŽØ;š½Ô¹êób8| ûž«ÿšá–KH†ª†z cy ÖýÇ[³y5th)µÆw03ý”
-€[ELÛ,ߤSHæ1BxŽñ	½ŠÊ‘Zj|¹¾µÔõœèc¹Ëk·s%ý^ýñÃïÖ'[ß}ã{œÏ´[÷uëÕ;•Ð\§µõâ)ý8ÌHU–UúS®7E#&¡¬cÑ;4êHÍÐÈIy½®ÏX„	LªyÅ^ê\ó€EØ9yO5±Hz1Ë"éY$=‹˜c‘ä=1Ç"Ùe‘‚ªã~K
؇)«4b§²IÿEíÆz[ÕË?e…O@»m’x2íJ¼Â:Mò@q¡úÔëdx6oßÓõó[Ú.C’ýÔCÅ®hN—œstS‚3:(ñgÊ×5þïòÈêÁÌF¨84Çtgç-Œšõ±hpl’o3jêy¾u¥¦ùæ¥<š=ªC~Æ9Å‚X‡É¼r/u®}P~+Hô%ï«¿AÍ.«e@€Ã%TY¥«=¡h¦ÃÌÈ“˜›3¼€Ï7É9ç?Íhœ¢l'1³ñ—QkdÆ<Ô¸‹8ðáDÝÖááÎEtf‚¤ÎRJI˜ð_¦™ù£ãŒ‘”Ç	Ä°ù-íHÍl©“2[šUû´(¿Ç|Ú•×½}…É£„Åóx©súû
-6D¼{&ÜaB'"—*@£Î	ôÇ"Â4¤v"ý‚nRÜìþ{°y;Û¦uxˆC2ª¥+"»XQ3	YÜ^FÍèjæ/6d[ý’¯}æm¬UéHq¹P“*HyúII×Ö~52Ò‘¿2±©jS˜ì*âãµ’à…+Õ¿Ë›õw‡¼®v¯Seµ†]Á<¡]hb+E\ÀCT ¯¿3¼³3ÖE®!D“{‡Ñ>V¼½SýÛ‡$€ZÀÙû
êXoG̳ W<»óñ¼{®ž§ròLe@Ú0œ?S]©é3奼›lW1ê&g•·nòLû¸›ì©7¡]’	Íã(4c…flÙšC÷vhGq$Ë‘Ö%Õ‡ÌÖ‡£oÚw¸ÍÂà×2šæéÓ‡Gi1ÚÊÝËZÊÚo°ótn&è‰d¼-6ò²Æ“­={ѸòtÒ;Ðæy6îŸ\ýo¢À4Ë8žx©ÞaYGj†eNªeÙ¶z›`Z,ƒ˜‰wðRç.¼4F{&ÜRÜ" ˆm]°lX{è¥ÒC°qþ>ÓÔ“ª}Ænn§&!Èù$'ßéJMCì¥<Ä°Á£Q#c&çµ{©sõ}|#ÄŠÇ}ý×¹»œHÛz¥¡.ì±ÀÖ}€OeUžöm29âq#HýÃPw“äqyˆUp©Å;w¤f vR^wšVåî4é+g•·¾òLû¸¯ì©‡Ü£\Üaj¦mnî/+;µ¢¦“Rü)èBÈ7T”¼]Gj:'Õn³KŸ¦¡›SÞn¨}º®ú«ÿ˜n‘†EúþÁŽtE J	Õ½á/ÞâH¾»»RÓ z©ÖºlÔYå-¨gÚÇAí©§\X)[V+é.g^‡>På»ÐuuMãü—8ÊÒ&¥¯€(ðXØILrª”›Bö¼ŠBi/p`„&Wî]	uç\OÙìN4¶54Ò™RÇ·©»|Bµ÷œø`ˆ`¾’ã §W³a6ª"ƒP^ˆ>çÑp¼|<ÚaZ4R[~SoEÌÝqOŒV×™×Øë#cX=ÿ=îìRovy“—
Osj(âïøÔ®Ô‡”çðúÏ)ïpx¨}‚Ã]õ†ÃÀ›@ƒ2‚„[c‹<(4>^Ó/rx½Í×Ï”@OVÔXxdöc6ô˜Í†ñÃÝYz4–LØ$êÜù™ž°}Ë0Æ©ª
-Sz¸þ|w÷é#µ_Ó]‘¥m!Rmzùqy’
-:¢K§Y&t„¦‰à„Zì&¯ç´¶·ƒCµã—ƒ]½×ô­p*-´Ÿ¡ôãÏWwwî*6/;à|zèemVä?†LÀ
-ÁD„ïÜ™´2Ó Z™öB±Í>ƒUÊ á@˜­^f¨vðGŽ_¤ºzÿ;Lïïþ?!ê*à_üŒ¬ùðÿóµ6%ñ¯<’‰j>;†:vF!LZ-÷tnú¿1W@endstream
+1773 0 obj <<
+/Length 3109      
+/Filter /FlateDecode
+>>
+stream
+xÚ­Zmsã¶þî_¡o•'|CgòÁw¾dÜIïœX7Mçâ´HYK¤"Rvõﻋ]€/"åNÛ¹™,°‹Åƒg€åLÀ?9KBO(Ìbx¡álµ»³ghûùJ²ÌÂ
+-ºR–W?ü¤â™ötäG³åº3Vâ‰$‘³eöm~sÿéóíÝï×?óÞõ"bþ÷›Ï_o~¡ºûkíÏo~þôŸQ(|’(‰ùíÝÏ×Ë¿]}Z:cºK¡Ð’?¯¾=ŠYvÿíJxJ'áì
>„'µög»« T^(ek¶WW¿º;­¦ë˜B•xaâÇ#ðÕ˜BíE
+šÐÓcSTåõB‰x^oªã6£òSN¿Mú’sóÛÆ–ŽuQ>sû&G/€·uG—L/ID¢–ʼndzöH°G*É"Õ¾µÃþîŽÛ¦XëüÀöê&ßÕô‘Ö­¦ð’Ÿ°ÍWiÙŸÃkQO[þ(J´e¶o{‰V”¤§ÃÐ7f˜ÑüXÍ«c³?6XæëõLæÕŽZöõ¼ÿI=Œl¾Ýõ&ßnÿRÓǦ¨›êp"Ñ?„ð·9I%bþãW”a¿bqùð2²°B Ы”<„­oE³a—ÊŽK•ö½@%>û4+žÇüx„Xæ{P·6—é.'"öp¬ž`-^q9üû¤è 0™5ÕüyÌEžÑG™çYMíMEU/eõfûæÔdV
kÒ’û¥ÛçêóÛq_Ö¢–§œ¼€½¨¢ù]I­î>ß~o•ußÀ¬*sÄ@œÀÓ#BØÓJ¿«ótÏ•ûC‘6ùˆ×¥žN´fâŒF¼®=¡Å28Ù‘´§ÂØÊ°«Ï‡R@QY±¬Ú@j²—ð=ØX¨EÀ]p3oU•ë‘Ñb õœ™ëÙÂ×ÀGq¤«BÏ÷a¡ì¯_?ýv†ó’!_î—w_>?ŒÌœîµ¼„ÒØ“¾ŒÙŒv]rœ¦”àO2/»'ƒG¨ªÖT‡(8}‡ç²¯þ5Û¬V×pÈ*íÑÎÌ´™1‰©àœaœo’svšQ;EÙNbÆñWÐ)ÖÈ Œ¥¯q±áɪ™áF¤¥ˆÎHÔ1¤€|ýDÒM7L3óFÇÀ±Êãð%íH]XR+e–4«viQþˆù´=]÷Ö_¶ÀI›Ð_W°!‚àÝ3á:ÙT
+uNîA>V¦!µ©èx¸Iq±ûý`ñ¶\¦y0„/!Õ=Cv'>°6€(䋸½‹PZÐÍŒ_¬É¶zŸ¯\æmتtäl¹PJ{!¤<}zéÚÚ?L'^éÈݘpªÚ&»Šäøy:€•=©ÿ7«y]m_§NÕVó„v¢	Ÿq"ຟ}ý•‘•aŠ\Aˆ&z‡Ö¾¯d{ö/ÎÖÞïPÇj3b&˜¹âÙ­˜;aÏ»ûêüTNî)G^à‡ïì©®ÔôžrRŽ&ÛYŒÒäEå-Mži§Éžzš‘’Lh†G¡k(4c‰Ïº·¢Ø@+Š-YŽ°.é|(ø|8Ú“ûHÎÂà—Mãôa‹Í£°…˜åÐ^Ë2dùŒ7ºòp†Ä&²=l
+Äe'>{ö¢qÏ¡sA'½#ržÇqÿdÏÿ&
+L£L^$Ñ;(ëH]@™•jQ¶©Þ&^,Ô;8©s^>û&ÜSÜ"GÚºÎâ°öØK¥‡ÎƸëLsž„8XÐÙØeìævjÚÅ"ð"?~Çíгó/¬îhTŽ±.ªvBgºû®¤‡2î)¿ÍíµDÚžTªÂviÝwí©¬ÊÓ®M#G¸6‚¤ß÷u7=ÇuœoªËÞíJM»×I9ÝiZ•ÛÓ$K^TÞ²ä™öq–쩇¬£\ÙaR¦mVî®);§D'L§KJî§\€¾D½³õ»R\g¥:®[oÓçi×]RÞqÝPû„ëºêoþc¸E&énö+>ЪP…Ý«ýQ§Â)4‰¤~Ç©©NµR­uÙe§^RÞqêPû„S»êM,uH<ŠãX¨óæ‘J}X¸¹¥_Œnî	Žª²´Iéù¿ž
+¤(Ct¼ðµÏ‡nlê\“Ôƒ^ö‰ÍTV]ñæx(/xÞ69_Vú1œêñHëó¥¼Ï臘Å^ÛrFR8C|u;Q}ç^¾èªÑˆÑ¨ø´jÞ,¡ôšn‹Œ	Ó§gY”„Ž.QÄúÕŠïN)¡E‰ž=H~ÿ‚Ø¢d¾¯¶×Œ¯NÝY%í¬Økq`n„‚õûQRSQføxš×¶‹¹ííúˆAçr¼7ë‰É&ÝÉ‚qù&­gß{Ñ’r ø¥°…΃³¦Ø•_î—øº¶øòuI‡´|Æ7ä@™Ù
+ŒgK_U]`•a®I·Ÿ>}ì-·;!Vë^bIC“P€“±¼—Zv„¦`…Zl'ïm/im¯m‡jÇom»zoéw*_ç7ÞÇA¦óñ—›‡{Gž——Q—·;Ù>WMºb½òßyVie¦Ê2íMo‹}æVÈ]	€¹ ÕÉÕþ8EÃö‹Â®ÞÿΧËå/ÿ'Ú“Kèá_bÌM¸?ŽøŸÿà«ýs¶ÿú&™x10ïÁ¾Ž­Qè&­‡–»¿;7ýßùܯuendstream
 endobj
-1760 0 obj <<
+1772 0 obj <<
 /Type /Page
-/Contents 1761 0 R
-/Resources 1759 0 R
+/Contents 1773 0 R
+/Resources 1771 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1764 0 R
 >> endobj
-1762 0 obj <<
-/D [1760 0 R /XYZ 85.0394 794.5015 null]
+1774 0 obj <<
+/D [1772 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1763 0 obj <<
-/D [1760 0 R /XYZ 85.0394 674.4719 null]
+1775 0 obj <<
+/D [1772 0 R /XYZ 85.0394 679.319 null]
 >> endobj
-1759 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R /F53 962 0 R >>
+1771 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R /F48 890 0 R /F53 967 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1766 0 obj <<
+1778 0 obj <<
 /Length 2837      
 /Filter /FlateDecode
 >>
@@ -7627,22 +7676,22 @@ lh
 ®’ñÌÜß.äPŸøÛPðƒ®­ú8‘äF&+¶ˆ'	7øû·­Ö\ëy9-é° 0(Žd0‰ÝdYpØK¹SQ—°2»{›±=C¯Êì˜õâ3´ \פUìSnçö-Áu ?C]C-.Ô?7.¤ÊjµŽÊ^xײŸÃvôì-ÎkOY¯øvÈÛB×Ýt©†?†±×mzÔéè:ûÔª†Æç÷7¦áî‡"2ncúæÀ!œ¦Æ|éá¹%¨Û~e5‘Ï	üEpLÕ#X®ÎË\6ë9¿È×Ý‹Õöâ¶f^ßÁ¥ß|]¼”ßÏe—g?¥9¸šn¸À¬RÃ\Ý@µí6áfªsëÏÀôevÀ
¯b:ËR’‰Ûå€hã/H–Hú$€Þb;âyÊwÎ!c‹fê8ð¨Qh›3ìѬšyÚÍ”93ÁÓÐ1{L›¾%LCš±b[$+f…t+öæ”'$5Ç>ŸÕ¡OS[:uO@iÎ
 Óš8³tüÌÕÿoœ'xL:´Uœnþëvßœ«éᢾŠsPÿ~µòÇ;à«þ-·€´sÎõÿ)oüË!Ë cædO$ã)|,œPJ¡¹ã ”PH»sÙÿm˜þŸendstream
 endobj
-1765 0 obj <<
+1777 0 obj <<
 /Type /Page
-/Contents 1766 0 R
-/Resources 1764 0 R
+/Contents 1778 0 R
+/Resources 1776 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1764 0 R
 >> endobj
-1767 0 obj <<
-/D [1765 0 R /XYZ 56.6929 794.5015 null]
+1779 0 obj <<
+/D [1777 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1764 0 obj <<
-/Font << /F37 747 0 R /F48 885 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R >>
+1776 0 obj <<
+/Font << /F37 751 0 R /F48 890 0 R /F23 686 0 R /F21 662 0 R /F53 967 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1770 0 obj <<
-/Length 3317      
+1782 0 obj <<
+/Length 3321      
 /Filter /FlateDecode
 >>
 stream
@@ -7656,31 +7705,31 @@ hG
 q•”áÚm‚,_<¨#‹R¸W¬‡ŠâIu1÷±Deu™ï´«CwV•ªBKcWÝ´»E³bø¢€*¹í‡ÛUCÔÖžV>ÔqÕé :ÕYP‹ÜƒkhG
 ð`ú:¨1Öâ
 {;$ᢅÂuƒÉpDžBEàFÊf³ÊžyÑ1PH´ètÆqV9]nhæ…É^LF¨l…ίÈþ°ÇÂþà¤lØBÊ®;Ô	JR¹4¯£&ŽÉUõis\¤ uQÇ/ˆ´uB¤ª)„î¦XŽÄiC¨DTry5Æ>'¤5qläýO$
ÊHBÕÿöê[‚—¤²Ú=×p+Ï~…s%œ88<ðã÷¼£ä­¿†6¼üÿKšcd”i´ßýñænŠ’¹±"Q‰F¾QŸåyÙBêÒÙ6u5Ž(½DŒRþ#Š ÓP@M~R
ö0Ç•€a:hʇåcÖLä8JÄpÂ	¼äïPüPCÆ*Õ}Äß:„s9…”RX³>TY»ëÌQaÃ{!h‹°Qg¸ËÐÐk·nàÒV…Í·õ¦\9ãêRÍ/'šÀ&Q¤ÚôîøRXAHK’éð¼;ï$CH UŸ!·×ï¾ýçÅíÕqéCÚ
aé%ù÷ Nh€‡r:ÐnwØbšÿ^<¿þ
-þŒô ‰Dd}š„jLÃPR)"FC"\í…Ì™»«TðK«‚ÆèÔAØÔÁv¶çI°£îÎ~ÞŒþŸÞ¹k<ŒÓ‡‰†§6¦]ëìë¾IÐo!í…¤¦kFÍ{å’TDÚüýÕ|ƒÄ’¤	ÃaëB\cX}yGQ¶¾ä÷ÌkE—²¦P¿2¯Ñ§¤œÊ(ðfMÇÔ|*mM±­_J[}çœq°ªëß	ÁýdóÐÆP„wuŸëïõTLÀ¿)LJ	Æ~øÅÉÆ4ÅÊÓüò©©‘ìJUç¢SßHú—äi¸ Ñ`¼1„„©Š¦ê¹ïqÖ}w}(Š?å6>ÜóS6ô~
-F“~JÅèBM:ªñrúo{ªîÄyÿȱ¹*p-±Ôñóÿä­T!?J_HZúPǽUÕE¬¶Þ¸ÆÙ(k‰ ÏÍiìÔýAØ’"¶2âÿ*æ\¹N~Æ¢L÷A^1éƒ7ÅÓ?šd´.4çV tí¢2ÏZ×öñ¤‡êØ\±Ihã¡‹ùk:&±¯ƒ’¶X¾û÷uÌŸ8ï9¡chÖFÙ=æ‘Ž9ßÕ]ñkÑü…v)€(BÒùáÓ{,î®oÞ_ÑUütõÓõÕí„oQDbãtÿíMA¹÷æúÃ%ŽÒ ¥…r½Y¹oPçoƵ£Çëc)ùb'@¦¾_Þì6(§ÂÔP’´
-°¸¦ÌfÅ„aŠX:@*Z$_Øg¡V·Iêãà3Ý’‰ÆŒ”}¦äi"õÐ×Ñýt¨©,§ÏQäÖ§¿<…,:ôás>õG‘Æ©çÍ"k1b"
-Pç2À[â´Þ ˜šã7½XrlEäî2€´®m…KOp}™1õ‹bOýªtßFa•ô×]Pu'~®Ò}º&Ä ‰P¥…Ъ³‡æÉŽÔÆ—qù¨¥ÊÓÑ…¢µÿª£%$x²Ž¨é5þ[ÐyÿáŒðL|”SB…‰g4•¶;þ†
-hÈð×Φ[Θž²Ê˧2ß¹²E«î:î•'¹`ŠIç¸mˆ+Í3˜ÉçE³Ü–þ2—!Di>yg‹ú©À_i€ScI«¾ »ÚgNî¿ä<÷WO8hZ #óÂv²Á×N68ØËoÿ3Xv¿ kÚ¾à9æ:oÞmxŸS3åÅ›­¦>ôôëÏ›â@G–«¬9Ôw»iê¾ôpÒ<Ö»U>Ì'2¯êý^þ~ËA}y¨¤w«zA‚É$ÿpŸ&Dž.§­i×IÁMž2þ9>÷”ño%Ü¢Ë&ùT°`>jIjˆï›švøc¼1»Rеe\	LõD—IÖØ)î¿.ßÖ®ÓÌÝļ W¤ðýÒ–À`u·Yñ:y!å”B'QÚnh{\Â=݃©d¨Ž’×O6¦™—Æp°>˜~°\'ÀYIpáT:ùÂ{/Nczjf¨7R|Y®ÓfÌ—¯’T„²ûMŒKË–ë|ª`
-…²‘Ü»w&9ãK,øà¶Û2Ï‹Ê÷\AM£$š×âyðAËÝeÞÕ;Kßqi‡Ý–)×쾯¾õßc‹/Fûûµ˜†Ê]멼2ìÒ“¿ýK²ýïäL,4~}ŸL› n	àŽôD!_ ’n1+ITI×8Ù›V4§zñÐ,2ŒÜ9阣R¿$_Ã%N4° 'jšªå¾ËY÷ö¡0<•Ûø0qÏSÙÐ{*Mz*£5éL¥ÞMÿm_Õ8ï96XÎ%–:ÞcþŸü•Š èGéiK긿꠺˜ÕÖ×:å-d¡9½ƒ£?\RÄVÆCüÿB½œ+×ËϸF”é>ŒÁ‹Ã0&}£ñ¦ØbH“Œ¶Ã…æÜ”®aTæYë žôP`Û+Öb"	m^bŒDˆáh`X@«Îšo8(;R_È壦*LÇkŠÖþ»Œ–ràÉ:¢¶×ø{LlAç}È&<Ÿå Œ†‰g4·;þŠ
+hÈð÷Φ[Θž²Ê˧2ß¹ÂE«î:î•'¹`ŠIç¸qˆ+Í3˜ÉçE³Ü–þ2—!Di>zg‹ú©Àßi€ScI«¾¡»êgNî¿å<÷×O8hZ #ó9Âv²Á×N68ØËoÿCXv¿ kÚ¾à9f:oÞmxŸS3åÅ›­¦>õô[ëÏ›â@G–«¬9Ôw»iê¾õpÒ<Ö»U>Ì'2¯êýnþ~ËA…y¨¤w«zA‚É$ÿtŸ&Dž.§­i×KÁMž2þA>÷”ñ¯%Ü¢Ë%ùT°`>jIjˆï›švøc¼1»bÐ5f\
	LõD—IÖØ+î[¿.ãÖ®×Ìýļ W¤ðýÒ–À`u·Yñ:y!å”B'QÚnh{\Â=݃©d¨Ž’×O¶¦™—Æpðù,,ôb€åJÎJ‚§ZÐÉÞ{qÓS3CÝ‘â˲p½6cŽ¸|•¤"”ݯb\Z¶\çS%S(”<àÞ½3É_bÁww°Ý–y^T¾ë
+j%ÉмσOZî.ó®âYúžK;ì·L¹f÷…õ­ÿ"[|É0ÚÿãØïÅ4ÔîZOå•a—žüíß’í)gb¡ñûûdÚqKw¤'
+ù‘øt‹YI¢â	Úÿ	ãÓsendstream
 endobj
-1769 0 obj <<
+1781 0 obj <<
 /Type /Page
-/Contents 1770 0 R
-/Resources 1768 0 R
+/Contents 1782 0 R
+/Resources 1780 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1764 0 R
 >> endobj
-1771 0 obj <<
-/D [1769 0 R /XYZ 85.0394 794.5015 null]
+1783 0 obj <<
+/D [1781 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1772 0 obj <<
-/D [1769 0 R /XYZ 85.0394 204.5196 null]
+1784 0 obj <<
+/D [1781 0 R /XYZ 85.0394 204.5196 null]
 >> endobj
-1768 0 obj <<
-/Font << /F37 747 0 R /F48 885 0 R /F23 682 0 R /F53 962 0 R /F39 863 0 R /F21 658 0 R >>
+1780 0 obj <<
+/Font << /F37 751 0 R /F48 890 0 R /F23 686 0 R /F53 967 0 R /F39 868 0 R /F21 662 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1775 0 obj <<
+1787 0 obj <<
 /Length 2180      
 /Filter /FlateDecode
 >>
@@ -7695,87 +7744,83 @@ C
 ¬Íõ1¿?Îò{NŠîU~ªçG-ZzŽË£/³jd—CVeò8¶‹f:ŒN´ {(°U2G¥Á·Ñ *Lâ0h\ß,Þ}šß/çw·#ya$,Ž·JGÃÒ/–4øk‹jƒéHÄQ'Í„©%Øä[€+S¬áØ\gì;$MC®ìëø×°&)KËCÂzÿ¶<¤M9z8?¿·rfÅ@ˆä­-tí,IÕ1”OOEj1|~HL
¦¼?¨Klmk@
 ­;,Z[ymíŸçΰ½Çâ)¯ßŒ˜BB”àÚw>óš)$„Jß]nÓå¹]lí¸6e†wU•˜Pû6¶„,½{<"…„ø¾xÜ1Û'¥>‹¼QF]'IÂ?Ší”Õɽêñmï1LE#¸-[è;!ìE é¤#¨_Ð̓¥@ç2ÝÀæé@Æ¡ñ1DP{@R¶Gë·m×åÙ,ËÓ¢2=3àæ÷Ošˆ>ESÆð/«Ó¦vUü%jØ÷˼,ª¢3¥Ÿq€?dlÊmèÉkš±oHž&m>ÖyA9«e|Ö|!_çÞ¶ÉòU²Ã‘öæÒ !‚Ç9À÷sSÿÙçèD쵇gXøZ<’byáþïGé—7wzô’¬BôŒ¶B¡š §=Ý=_ŸÊþ_'PûÔendstream
 endobj
-1774 0 obj <<
+1786 0 obj <<
 /Type /Page
-/Contents 1775 0 R
-/Resources 1773 0 R
+/Contents 1787 0 R
+/Resources 1785 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1764 0 R
 >> endobj
-1776 0 obj <<
-/D [1774 0 R /XYZ 56.6929 794.5015 null]
+1788 0 obj <<
+/D [1786 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1777 0 obj <<
-/D [1774 0 R /XYZ 56.6929 626.4701 null]
+1789 0 obj <<
+/D [1786 0 R /XYZ 56.6929 626.4701 null]
 >> endobj
-1778 0 obj <<
-/D [1774 0 R /XYZ 56.6929 517.4334 null]
+1790 0 obj <<
+/D [1786 0 R /XYZ 56.6929 517.4334 null]
 >> endobj
-1779 0 obj <<
-/D [1774 0 R /XYZ 56.6929 438.0429 null]
+1791 0 obj <<
+/D [1786 0 R /XYZ 56.6929 438.0429 null]
 >> endobj
-1780 0 obj <<
-/D [1774 0 R /XYZ 56.6929 376.8269 null]
+1792 0 obj <<
+/D [1786 0 R /XYZ 56.6929 376.8269 null]
 >> endobj
-614 0 obj <<
-/D [1774 0 R /XYZ 56.6929 339.1376 null]
+618 0 obj <<
+/D [1786 0 R /XYZ 56.6929 339.1376 null]
 >> endobj
-1781 0 obj <<
-/D [1774 0 R /XYZ 56.6929 306.6767 null]
+1793 0 obj <<
+/D [1786 0 R /XYZ 56.6929 306.6767 null]
 >> endobj
-1782 0 obj <<
-/D [1774 0 R /XYZ 56.6929 271.6646 null]
+1794 0 obj <<
+/D [1786 0 R /XYZ 56.6929 271.6646 null]
 >> endobj
-1783 0 obj <<
-/D [1774 0 R /XYZ 56.6929 207.5268 null]
+1795 0 obj <<
+/D [1786 0 R /XYZ 56.6929 207.5268 null]
 >> endobj
-1784 0 obj <<
-/D [1774 0 R /XYZ 56.6929 137.3205 null]
+1796 0 obj <<
+/D [1786 0 R /XYZ 56.6929 137.3205 null]
 >> endobj
-1773 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R /F47 879 0 R >>
+1785 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R /F21 662 0 R /F53 967 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1787 0 obj <<
-/Length 4062      
-/Filter /FlateDecode
->>
-stream
-xÚÍ[Ísã6²¿û¯ðíÉU#>ܪ=8“™¬wgÞØÙÍÖf”DY¬H¤F$í8ýëF7@R¢¢™ÝË›9j‚@£Ñ¿nÀòZÀymM$t_§Y!Íõrw%®ŸàÝwW’ûÌ}§ù°×7Wo?èô:‹²D%×ëÁX6ÖÊëÇÕ¿f·?¾¿ÿöî盹2böMt37BÌ~¸½ÿéö{¢}¼ÉÔìö»÷ø3QØIa·DÌþòãÃãÍ¿ÿzõþ1p3äX
-¬|¾ú׿Åõ
-ÿ땈tfÍõü‘Ì2u½»ŠŽL¬µ§l¯®þ78xë>’€Ñ62V¥"0zJ&‹­´ASž‹®ãí5ì­³HÊTÁØ­lnæZ%³¼Âg:«÷mYWù–©‡igOÝ®¨Z¢¼lÊ冺úO‹²ÝÀLŽ-"VùŽ[5¿ºûÈc®VnÔ¢áïëõÙoyü:oy9r´X½±¯gS7íĢ籆Kª”QfŒ"!mên»"ø܇Wj–UÓ9Ó‘=|:ö°á™r/CZC?¶%|¾òC7:p£t¥:ó{ð¶h—oESoŸ£e]­'ø‡E&±ÔüA„=®çZ«H[a®ç
-iJºÿ|žN)aדÔKižOÌ!ã(Žå.¿#òí’—ê4ƒWÅ+->wås¾uÚádT{q´mY=õ‚›`(eaIóç‹
È+–oÞüŠê…U‘ÔRý±Z(Y“ú	<÷»üWÞêüD5‚6¼î¹Ïíý?o¤”aS`Ì$ÎìxSþ±)ÐÀ¤>#8Tž‘ù»)a€ž§2>éž]S¬ÞLˆ$-”–D¡¢ØƾÓK¹ÝÒ yÛ»}ËÌ×øT³UÙì·ùk¿"×xøñ–dßËÚ=WÌÝÚ9hü^W,3f@F â)sàœÀ›)¬%x¯µ›¡Þ1«žg–1X½€1aíÞêi3¼}jÏò®ÝÔ‡²ÍÛò¹ ’w?¦·j$ÿÐpŽÈµp%4´vVçh88}M~­/GîÓÌVÅ/B¨Ê3´xõ³ðG÷ÔïX¨¸@1vgÄ™S\êM?ÖuçÍeíVðf´ì‹üH–z-™/§õTÅÙ±šjé¼êáÆκe‹K×ä.ð
Rr"|ë

´¼9{¥_N¢ð\nó¦™R!)¢·›&tëPY|!n Q°Ü’¹ZæÌð¢ 'ÚÕ˜ám]ÿÚí‰ö—¢)ë3x ½S©‰¬j¼=ï6yÝToqçšëÎ5–Å6}x'-ÓEb~}2Ñy‡‚œÜ~¢ºÃWH^‰HdÁ,ç÷ÓˆK§ærÅó05±‡“@ªºÝÂ¥Ô@tx
-h«ºïæ°-Ð(9Æj.xŸÕxÅZ]Äï:ô!Hãµ]‘9®çø9Æ5ï-\»d‡Ë8[Ù°B¤ÿmesáXú°…&|ƒÙÉ~’«ÙOßb…-ö±¡=”EC¶3åÒ+xlÑ¢9ƒŸ”ð@ƒÌ‚×&¯žÈÞ뒧ыÊñ˾ó錇2'èåÔ…è4’* pvU“%L•„ô¡¬V埻©_Xˆ™„n}òOz±Ë+c™žµån-¼µÖê‹åeu2*—à $û}á½JNd_AÂiÙã Û-Øp«šIO7ò¼x¿vkËñ¿ú4ïÏñ…+N&Xà½ä¡îÖŸ§ ýTyŒó›`qOå ŽŒVQOyo#Þ”~§¥ÔoŽL/0?¨¬™÷8Ðú+½Í0?#›¹¯«9[nÙÍ3ǯÏÝ
¦»l Ú[€<
-´dÅ]ŸK6š3Ø=K¢4µ¡rw8£ý§ÐÝX;{ðuRš dvúƹ÷ÄôÖ{€Oßá@ÝD,ÒçT
-’''±)CweP"x]¶oø„ s§«R8äŒO_S9©õ÷%.òÞþüáS\çç)š¶ùºú¾NC‚6§+‰‘'µ½”p¦+`OzI\>…I˜ÞYKŠI”µJ}6
¤»Ï1‘|l¢“ɾ>¸L&Uç–èÎÃB9lžü?^câ±ÂkÉ„b‡Ò¨_ù×lµ‰­÷ìóvZV%'°–ÓGkùlDYòŸH!s 6E^k«H{ÝSØ_¦I$ÒPu¬Â¸e¥÷2·á ž‡À½
¾¾~ªÊ߉Ã&þ„Þ<½»¿ýáý"cM<	d"€‹²±Í=üxë:ªÙÃÝwÜúÛ{:þu?åß@î‡þD>ýEšKÚáXQþ$ÙrM(}½lò8Tr{ÙÕË4ö˜áÈm¹YÜ>54uÎüå{>fØJH©X™ŽâDeÓÚ‡[ï¶tCVþ
“9Šp.‰XÜk¨Ii<¼#‰f3¬£r“êÐøágêsTìÄnY6[t<¬«ˆØìÜq…Š#-{swFÏOÀùâ
-À€†Š'öž/ad‘4}ÌQC ©>DL|F-ŠРórm&Ö§
—E°_¹ž4æb¹Mõ‰7p&tÊš`!ÂÖ|ڶ˙]ò«®ÓèžpéÙ^Ö[c«bÂ}ǾJf)ÂŽ2íÍä-ž(ÍÒËà%¸Ô×Cl’d¡áJúØ8=C!Ìß­ém~2#¶jîsM-'=x. :ìá˪@lÚüÀˆS¸‹eÎüõ	ôõÄÙƒ
-LÇ_“F&ÉÌ—³,÷ÜQ_"!>ƒÿºÛp´CZÓ]‰êœYšpj½§=Ž
-¹j¶W9»3&›.;
h,œ}ѨäÇôl˾ÉÕ*j\vþÓÛ&úu¹õ3ù:†i
-~M×;Üþ
²ÏÜó.­ÏBM¤cmÿHIæq,#ƒ×TG> 9	£€ôüm.É$¹ì+•:r–8x±F«YS›@ê-Ó&ÜTMa‚ë“ÓïÞTùJA,36zèÄFýí9½áh°+áo<—)£¹ÄmŒó›™ˆª]§ñ¹ôVYé‡âg|ã†ïOð=Šâð·r×íø† 
oRy7Œºõ䧗\µýÍ‹¯9íSq¸=5o¦“h£Ô1&GÀÐÛídA[GÙ^ŒÓ±Æd:öÃbùkbê$²q:ªü¨†ûØðiõèäÝÅo-‘Ü¿á¿Çðyõ#÷/{}q
-?œr0òPÑœœ>¼ÿtcÌìï0Á¿½û~tåÊ©W¥ùjóèw3º‹ÅçÔCýªêÃÎѦíã]ÛpQ8Ç\•áôÖÝÚÝ]¼Ïr&8?ßÍ=ZÜ®ØÕ>‘ìšü)knß"ÑùÓäµ;H–Œ
-.é€xkêR6‘Mb}31RŠN’ˆ•‰aPjAC¼£ã,Ò&õ#¹‹Cç.ÚáÑÛÔÇÚzꆾ¸öŠö_ÿ=@ÿçq
-¾ÎªpÕ¼vɌΤg
-—B³þrà”÷ÿúž¹øendstream
+1799 0 obj <<
+/Length 4058      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ[Ksã6¾ûWø¶r•ÅÁƒ À­Úƒ3™I¼›8³c籕ä@I”ÅŠDjDÒŽóë·Ý E‰9›ËÎ5A ÑèÇ×
X^
+ø//‰„NãK›Æ‘Ò\Î7âòÞ}u!¹Ï4tšî÷úâáâÍ{m/Ó(MTrù°ÜËEÂ9yù°øyróáû»/oºš*#&_DWS#ÄäÛ›»ïo¾!Ú‡«TMn¾zw?…vKÄäëïî®~}øçÅ»‡Ž›}Ž¥ÐÈʧ‹Ÿ—`üŸ"Ò©3—ÏðCD2MÕåæ"6:2±Ö²¾¸¿øw7àÞ[ÿ阌v‘qÊŽˆÀè1˜4J´Ò^u¾{Êw¸Ž7ïÕ~oFRZS`·¢¾šj•L²ŸvRm›¢*³5SwWÒMÛM^6Dy^óu
ŸæE³‚™<
ZD,³
·*~uûÇ\,ü¨yÍßWË“ßò"øuÖðrä`9°zãR^Ϫª›‘EOc
gª”QjŒ"!­ªv½ øÔæ»jeÝäÓ‘=|zö°˜ò/wû´š~¬ø|†"ntºÇÒIduöàMÞÌßìòºZ?Eóª\Žð‹Lb©ùƒ{\NµV‘vÂ\N4¬%Ý>§”°ë‰
Ršf#sÈ8Šcã¸Ë/ˆl½†‡ä¥zÍàUñJóOmñ”­½vxUAMS”½àFJ@YE·¤éÓYŽöÈJ–oVÿ†ë…S‘ÔR}^-”Œœ±a‚Àý&û·:;RN^¶Üçæî?WRÊnS`Ì$NÝpS~\åh`RŸFœÀNªÀÈôí˜0@Ï­Œ„CzC„g[ç‹ëQ€¤…ÒòŒ(T»8tz.Ök4kš|³m˜ù
+Ÿj²(êí:{éWä÷ßÝPƒì{^ù点[zG?ª’E`†ÈTÜ2Þ	Œ°ia-÷Zúª
³xfƒÕÖ¬ž6#اVñ$k›Uµ+š¬)žr"÷cz«F2ñ
ïˆ|W‚ACkouž†ƒÓ×ä×úñâáxä>Íd‘ÿ"„*C³—0twOý…ŠCwFœyÅ¥ÞôcYµÁ\–ÁauÞŒÖÀƒ½Ê¤6hÉt>®§*NÕTKïUwWnÒÎ\º&woÈà’áK¿hh å]ÉÉýò…ç|Õõ˜
+IYÜnš|¯ÛP‡ÒȹÎâË-˜«yÆÏrz¢]
^WÕoí–h_çuQ-˜Áé²&rR¨áö¼]eU]æ¼EÄor<¬ZߘçûÔnÃ#ÔmAŠ†¯ù2k×ǃß|{GOtä·e“ï`fôæ›í9ûÁ{°|7«j?:à€¶Ù¶
µiD;yÌË|—qh³¨©Ç¾F¼0Æʳ~7U®s6Þ9â'œ£ŽAéã‘ÂÈ$(ÝnLqaJm’3á‘GᦗjBD[ÍûMµH'·ƒáò§¢jk]SÆk¸&ÊøvhC°Jô™ýˆep:Q¼õsÑÌW´XNÉQ3q 3È"Ÿµ=Øeó¼îÀ1k©MQéë1E^f³uÀjO½6Þ/)‚L;ôßxW¯›nªEN-¯)ð¬óu>'SQÞTüóÂA%à8f{=ζ’É
+ù
žË³~´ÃB	`ß4>k“‰êpô6ßzmhÜŒ>pÓ:vYY/=VAC‡c·,Ñ€•HÎDv¥RĽWök»JÁòdÒAA\’$ÃNáÌ’y„ÖvW”BÑ3{g®çÝ=j98ð‰B û)
+Ž
ѱ޼¹äV=ñvIO°¿Yáƒ:þ_Y’EeTÉT®Œ	Ûâ!ÎIŽgzÃ*Æ…ýÓâ¬ËÔMêm>/ä ñB.Ì8_±Ï“"kM?0ÞcÿÛO	Qöv&çN!‡ÃŽmÆï26n?$ÑíÝýXT›¬(©kÆŸ÷ð‹á;¤ÜBÚUpÖññý[éÀ˜>‰Cø
ÉD
+rró‘êBòJD"íÌrz7Ž¸´5G+Ö˜‡!¨‰œRÙnf>¥¢ÇS@[T}7mF!ÈÓ0&Psƃ„¬öÀ›(Öê,~×]‚Ô8^ÃSUô{ÆSC6\C¼£-_лl‰rÛxàÊ 5%¨¼½?!ao@îƒ[Ü
øÌo2Ck‡c‡¶&ßáûäÔ(IPج!cÈ©,â‡Mób«Ìÿšæ_“ôÞ¦”ô(–4eY35eE6:’€Æ†šÌ+ÇÊP{póéÉì¿ô~Ë·–ù3¹{ÇÚ‚­äà€ˆ1y4|deø’ÈkβRö³ßõÓy÷¦y*xÖ9ÍÁˆ©va>š"${¹ÙúxEæ°žæÖt‚·ðí‚./àdelÀ	aÿjesáXû°…&|…ÙÉŽ~’«É÷_b…-±¡ÙyM¶3åÓ+x¬Ñ¢9ƒŸ”ð@ƒÌ‚×*+ÉÞë’ÇÑ‹Jñ˾óñ„‡2GèåØ…hIÕ!pvU£%L•téCQ.Š9(>/vU=³S	ÝúäŸôb“•ÆR=iŠÍ(ZxëœÓgË%ÊédP.ÁAIöÛÔIi‚‚ÙéC8çÜÓ›à>~I„_ueo‘!§R´È89
+ˆuÑÅS%$¡„˜Ì0#É{=öIÈN}¡I#‰?€|ëÎ×[uÒ%_>]AÜœÆ!‰I»š†þ¥M"a»:¨?b.'CµÃ#7tÆó¼w·¯Ëââðˆ‰¿£?·“·w7ß¾»&2VÉ“@.È(ÚÜýw7¾£šÜß~Å­½£`ÿSNÐù
dèO„áó_¤ù´ž+*œ%;®J¥¯˜è‚j@öá’³Z&mÜñÛò³ø}ªiêŒù˶|аÝT±0RʼnJǵÏZÞRH¹E*ëúHòO‡ŽXß«©eò@ó"Å'ü»¦wTÚ·?Ñó ÞÉ£Î|Uúû¢ˆ=U`¿
+ZlÔg×ãÈJwtøc>gÌð#‡’g¾/b¤t™g +:t‰IÈ* E1tf®Íȵa9`¿b9j03ÌÙ’›ê“o:åLè¤5Áb®éôm“1»äY}§Á]à2°=¯ÖÈùp >úŽ½•L-IJ7ÚõèMžÈ¦ö×Dw¼ðº	ºˆM’-4|aÇ'©1„úÛ%½ÍŽF ƒÄVÅ}nÁ¨©ååÏ9ÂD±Cqˆu“íw
+} È˜¿>¾œ&€ÁÄD!?fDW£ßsü‚=h^.ºC±ðúlù×ëêùð»¾ÞÕ1É ³î§ãˆ'òè‘kÝSNºQÿJÇ&±nä4y¯R|‰…[=Ÿ3ï	4ߧÀFF®œxç?I šjΞP•
y¦5ØiLˆ‰Ò>®xšñüɨÈ&qwÀöã‰sן³Œ/â%ªÔvÃ<ŸæàÙ݃Œa@¬&I_ÁÛQÖñÉ¿DBL^y)îàšm‘Öteg¤Hç@˜¦;¼ÇÞãNü$wªÁøJoxƤãÕ'£’uµòWJ®LOÖìž|m­¤`fïBƒq©_—/U?‘»ÓÝ0uί閇#¼Aö™{¾Ê¥õÉz¨‰t¬Ýç´³¨È8wàzx•0°§/u¹H&‰=Ÿí©Pq!
Ï—h6K*g°Á4]nNE&ø>ýîm•oÄ2e«‡NlõÐááо‘Ñ[°þ&piÒ%~c¼ãLExí@]CJýÙ¢"+ ýðqü„s\ñ5
+¾N‘ÿ­w/6í†/
+ð9Òþ…ªà‡Q·Ãôà“˦¿€ñgýTÜE¹i=^ð1JúÄM¾^Öµu”ŽÆØ5&Õq«`#S'‘‹í $dõ{¬bóc#„T¤Uƒw|ç¿7Dò'A᢯!,GØç%ŒÜ¿ìõÅß+4áŒÊÀàC;:¼÷ñʘÉï1Ë¿¹ýfpóÊ«§ù†óà,w5¸’ÅÇÕûúUV»Mˆ¢uÓΆ÷ºÖÝ}á®FæK
DZ^uywsöZËšà$mxE÷`q›|S…l²­³Çît{p	 ‰ÎGoßAÆdTç’v¸Æîi¹¤­×##Å ¨Ý±22J­Sç.`ricÃHþþЩû€nÿnìê¿ÆÓm=vQ_\EûËÐÿÕClÁ×9ÕÝø®]Ä$20…ŒK¡Yïþ€à˜÷ÿwv»zendstream
 endobj
-1786 0 obj <<
+1798 0 obj <<
 /Type /Page
-/Contents 1787 0 R
-/Resources 1785 0 R
+/Contents 1799 0 R
+/Resources 1797 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1801 0 R
 >> endobj
-1788 0 obj <<
-/D [1786 0 R /XYZ 85.0394 794.5015 null]
+1800 0 obj <<
+/D [1798 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1785 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F47 879 0 R >>
+1797 0 obj <<
+/Font << /F37 751 0 R /F53 967 0 R /F23 686 0 R /F21 662 0 R /F39 868 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1792 0 obj <<
+1804 0 obj <<
 /Length 2137      
 /Filter /FlateDecode
 >>
@@ -7789,48 +7834,48 @@ V̳
 3ñº±¹—¨€ýfæ.3;åî`ˆbÔJio¾±½x‚£<À€µ©ˆÈj§4õÛWËÜ(+±ŸÑÍ=Ù|$ ME³§ƒê×zm‡ÑàC\²÷ž›Î
JBG¼äƒ¿¡ø©(¿©Ù8v0…we‘WÕÃÙx‚áDø£G-*ò-y3 dP¨^ÁŒ×˜ÑsMšÅ	fÀ¤¤xÚ,N%м¨ÛÀåQn‚L’ˆñdª]¶×Ei¢E—[¿¢>îîÌß
†6ùižweçØtøÀž`všÀFPV½¤â¾)=•d'CXÃ-µÖ{-'¿éå÷B&8è  ”6¨Z&0#A{$Ü¥Á[|<¦jP–€²°dŸÝOü#
’q$0ú€€á?uŒàwß´ÀK-Þë<ÿ‡ &ªÑå°€AÚ}õ‡ˆªØ1âåÆ7˜Á°ç®=Ø*¿`´
 '8
åÑ£àÉKCàSÿ
åÉݱêJDX8‡”‹#âËãÇ~Ãi)ïåØ÷°`gyZËÞñÏük
§ù«×“+th)þï”ÿ9‡[¤é3eš'’Àá¸WÊxf™§ äþ{~ªûÿSÆÏýendstream
 endobj
-1791 0 obj <<
+1803 0 obj <<
 /Type /Page
-/Contents 1792 0 R
-/Resources 1790 0 R
+/Contents 1804 0 R
+/Resources 1802 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1801 0 R
 >> endobj
-1793 0 obj <<
-/D [1791 0 R /XYZ 56.6929 794.5015 null]
+1805 0 obj <<
+/D [1803 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1794 0 obj <<
-/D [1791 0 R /XYZ 56.6929 751.8114 null]
+1806 0 obj <<
+/D [1803 0 R /XYZ 56.6929 751.8114 null]
 >> endobj
-1795 0 obj <<
-/D [1791 0 R /XYZ 56.6929 637.809 null]
+1807 0 obj <<
+/D [1803 0 R /XYZ 56.6929 637.809 null]
 >> endobj
-1796 0 obj <<
-/D [1791 0 R /XYZ 56.6929 571.6272 null]
+1808 0 obj <<
+/D [1803 0 R /XYZ 56.6929 571.6272 null]
 >> endobj
-618 0 obj <<
-/D [1791 0 R /XYZ 56.6929 530.4875 null]
+622 0 obj <<
+/D [1803 0 R /XYZ 56.6929 530.4875 null]
 >> endobj
-1797 0 obj <<
-/D [1791 0 R /XYZ 56.6929 492.9536 null]
+1809 0 obj <<
+/D [1803 0 R /XYZ 56.6929 492.9536 null]
 >> endobj
-1798 0 obj <<
-/D [1791 0 R /XYZ 56.6929 459.984 null]
+1810 0 obj <<
+/D [1803 0 R /XYZ 56.6929 459.984 null]
 >> endobj
-1799 0 obj <<
-/D [1791 0 R /XYZ 56.6929 390.8804 null]
+1811 0 obj <<
+/D [1803 0 R /XYZ 56.6929 390.8804 null]
 >> endobj
-1800 0 obj <<
-/D [1791 0 R /XYZ 56.6929 303.7532 null]
+1812 0 obj <<
+/D [1803 0 R /XYZ 56.6929 303.7532 null]
 >> endobj
-1801 0 obj <<
-/D [1791 0 R /XYZ 56.6929 225.6163 null]
+1813 0 obj <<
+/D [1803 0 R /XYZ 56.6929 225.6163 null]
 >> endobj
-1790 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R /F55 970 0 R >>
+1802 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F53 967 0 R /F55 975 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1804 0 obj <<
+1816 0 obj <<
 /Length 2916      
 /Filter /FlateDecode
 >>
@@ -7841,24 +7886,24 @@ R
 5⛿R-Ú£HÓ”lì[·P’%ÉXñŸéC”U\¡ûwi¢‚µèÓŠˆO¬/Ž"Ÿ§Ú¡NÉö]7‡>ØI,žç°ÇoY.—kƈÙ𸨄fÊ\úECˆ:#*º,ªsTQ“UH”~HRÔ½ûØ}"*È“ò]±o„¨`ËPÜ@eO.û²ò±ÞíÓfTÀ)x¡’óò
@ãâõ ‹Ò=Gò Ücšƒ²
iŽùÐT'ÑE=fÝ@¥dÃ)ïÿ6™&Èendstream
 endobj
-1803 0 obj <<
+1815 0 obj <<
 /Type /Page
-/Contents 1804 0 R
-/Resources 1802 0 R
+/Contents 1816 0 R
+/Resources 1814 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1801 0 R
 >> endobj
-1805 0 obj <<
-/D [1803 0 R /XYZ 85.0394 794.5015 null]
+1817 0 obj <<
+/D [1815 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1806 0 obj <<
-/D [1803 0 R /XYZ 85.0394 181.7045 null]
+1818 0 obj <<
+/D [1815 0 R /XYZ 85.0394 181.7045 null]
 >> endobj
-1802 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F14 685 0 R >>
+1814 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F55 975 0 R /F23 686 0 R /F39 868 0 R /F14 689 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1809 0 obj <<
+1821 0 obj <<
 /Length 1934      
 /Filter /FlateDecode
 >>
@@ -7877,45 +7922,45 @@ oq
 ðú2àM²kÎÝp%PÔ•Ô¦=ŸUÚÉÏ¡›Ê¿?Êýõh«¯XB6“²²Žµm°0Üp§BÞÌ-žÄPŠô’ÉÍd~ý0½_LïfžúöíºÊ“Á¦4dî^jFkK{hÿõgª\NFÓÆ\{kg&K‚i€ôð0Ÿ~4´þ“m)´š\¥û¥êo«QVÚ³ÚÕm“¬ª•}m°z÷°5=‡ŒÖŒÛÎHé: ±FcD¹O^²loh’¥}£p°Øª{b… ßE=Uî.ÑÿýüúòÐù‹ÆqèYL£h•ÒÇ$X¼RÝ=Ô¾Öý¿Y9·endstream
 endobj
-1808 0 obj <<
+1820 0 obj <<
 /Type /Page
-/Contents 1809 0 R
-/Resources 1807 0 R
+/Contents 1821 0 R
+/Resources 1819 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1801 0 R
 >> endobj
-1810 0 obj <<
-/D [1808 0 R /XYZ 56.6929 794.5015 null]
+1822 0 obj <<
+/D [1820 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1811 0 obj <<
-/D [1808 0 R /XYZ 56.6929 635.5323 null]
+1823 0 obj <<
+/D [1820 0 R /XYZ 56.6929 635.5323 null]
 >> endobj
-1812 0 obj <<
-/D [1808 0 R /XYZ 56.6929 476.3563 null]
+1824 0 obj <<
+/D [1820 0 R /XYZ 56.6929 476.3563 null]
 >> endobj
-1813 0 obj <<
-/D [1808 0 R /XYZ 56.6929 407.9215 null]
+1825 0 obj <<
+/D [1820 0 R /XYZ 56.6929 407.9215 null]
 >> endobj
-622 0 obj <<
-/D [1808 0 R /XYZ 56.6929 365.2162 null]
+626 0 obj <<
+/D [1820 0 R /XYZ 56.6929 365.2162 null]
 >> endobj
-1814 0 obj <<
-/D [1808 0 R /XYZ 56.6929 326.9947 null]
+1826 0 obj <<
+/D [1820 0 R /XYZ 56.6929 326.9947 null]
 >> endobj
-1815 0 obj <<
-/D [1808 0 R /XYZ 56.6929 293.3376 null]
+1827 0 obj <<
+/D [1820 0 R /XYZ 56.6929 293.3376 null]
 >> endobj
-1816 0 obj <<
-/D [1808 0 R /XYZ 56.6929 221.9809 null]
+1828 0 obj <<
+/D [1820 0 R /XYZ 56.6929 221.9809 null]
 >> endobj
-1817 0 obj <<
-/D [1808 0 R /XYZ 56.6929 108.6903 null]
+1829 0 obj <<
+/D [1820 0 R /XYZ 56.6929 108.6903 null]
 >> endobj
-1807 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R /F53 962 0 R >>
+1819 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R /F48 890 0 R /F47 884 0 R /F53 967 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1820 0 obj <<
+1832 0 obj <<
 /Length 3191      
 /Filter /FlateDecode
 >>
@@ -7935,24 +7980,24 @@ Yw9
 ÿLLƒí2fFo“Í.t»5 óQ ‡ÖqRÝL3ýçå:”a	ÿ”3gÎS€kƒäwtg0©\„g5Méæ‹jaÒ]V£:k_Y¨®²ÈižP×e¬Û¹¦ÏQîàû®õar!h„Íf²Û,/ƒ½·LæÑ4b¸7“ºçV¿OeS»iÊUA#W¼rM¿·¼ª—’®Và©©ëÊOæ<4Ìå.íñ{–Çu¾ä*Ä…PK´ëÏ2	‰Rw¤H§‚Þ›Û?5ÄÀn¯£¿wq ñq
{ÛnÒ’Ü·[-™~[´OEÙ€{ôª‹H*T]vˆÍþ2ªk%
âÞÑrÅ—ûñc- …Ô_«	<B†?{'Š¸/.jCÈæa¿(ð´¬ ©O[Œür Oc­º´)ÔK
¯5z³îðó–Ëi	…›R“rºV§tK„Í„ëa aªŠLUÑisâ	ñ”˜@‡?
 …<põ	:*¯-ýjØäJæ_+á°¢¿šrÎ\|1ìiÆV»¢;wýoÝ-¶ÿ]Mw3v—Ѭ:ñ9xªwáòõ`°ÎÊo¾¥=‘2
¹Ê—?”_ŸJ»ý1¶åoÈIÆyw™2„ÃQù:®Gs*c9÷X›R³Ð6œoÛ>ßæûètF"å¢>6ÑûºiÊÛuAL4Yùsï{IV§‰‰ï(ÜÚâs‹¿3§@qÎö/>¬`|¥"¿TÈÑÇ.c‘i3Xe›?ZÒy™©i:Ÿ@’ŸLÒy¾Äu¶?ïíq[BrZ®Ÿ™Aéß´ù'*©òRx¦2[ôÐX=C–_.é!¤Gد\ótˆ0ÜâW»Í#H¢dÓH$b¼§t†àÄàÅlµ@SÐSð
lë+°{\1üa§ShÜò´àÀÙ¿?¥à—…¿¡fÐ5Šò  [}öF籃üû×å]G8Âw>Òz8S`Ôþ™ýeÓì´ÞÆïÇ“è&Þy¿Íî·’ºiâŠßá—
yUø¢¤óQ—Q~œ…êÆòþ3¾”JY-ù
dß°©g"Sø\¶û«|ç¼® ÷@„óîGme¨U_õŽt7Øô7*Üc)úè	Ü(5‘-’‘Ⱨ×O7Íbé!ÿTŒg¾ågb\{‰XŒü¶î$zߘäû7äý­UŒŸÃÍ8³è>uû¿¿ºë¿/4ÌeÙÌ´0±ÖN¡PûR¤SÑ»ïóöeÿí£endstream
 endobj
-1819 0 obj <<
+1831 0 obj <<
 /Type /Page
-/Contents 1820 0 R
-/Resources 1818 0 R
+/Contents 1832 0 R
+/Resources 1830 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1801 0 R
 >> endobj
-1821 0 obj <<
-/D [1819 0 R /XYZ 85.0394 794.5015 null]
+1833 0 obj <<
+/D [1831 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1822 0 obj <<
-/D [1819 0 R /XYZ 85.0394 751.8312 null]
+1834 0 obj <<
+/D [1831 0 R /XYZ 85.0394 751.8312 null]
 >> endobj
-1818 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F55 970 0 R /F39 863 0 R >>
+1830 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F55 975 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1825 0 obj <<
+1837 0 obj <<
 /Length 2975      
 /Filter /FlateDecode
 >>
@@ -7974,24 +8019,24 @@ U
 ¿öˆÖšÑX9ø*øåfCbDk7•ùGÅuSž/…ËSæ4¹öÓ=[®ZÄ?G€NÖæÏ-Ï7hÁú'¨'LJM_ÿvõë§_®G"8„ìÃ%kœà“Òv[=7 þ§º#&Âî_S³	ý‘”;$oŸP
À%³õh´Œ~Þ$4²Ø¢y Í›@ÔÛ›+jQ††
§ãóòÈËú
 c­ß!+kÈ_W°L
wáŽÆ&¼–aã}ç$ì{pß
ž‹˜OCN%C7å;Œj!K}ö?vǺ!ȇ¢áHæî(wí6’0ÊkfâÉgwlžßFA^˜tÞƒN´û¬vIÁâ(}åcµöÿy€OŒÛªúË¿F¢jžfñA-¶§°¸Î›ñt	®³n	Â×þ´({¯¬qÿ~©(¿_8µ®ÂTWZƒÖÛúžÙ·pê·rb…;ªåŽ^ú‡°„a)±g€Ê]ð‚AT=U”"2Ê[«û1ñ€,Ý“ÎÄ)¼·jÌ+ñÖ"üßÿ5túÿ(ˆ ”™*pJC<mO/¸9wãþÿ‹Îiÿvï*×endstream
 endobj
-1824 0 obj <<
+1836 0 obj <<
 /Type /Page
-/Contents 1825 0 R
-/Resources 1823 0 R
+/Contents 1837 0 R
+/Resources 1835 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1801 0 R
 >> endobj
-1826 0 obj <<
-/D [1824 0 R /XYZ 56.6929 794.5015 null]
+1838 0 obj <<
+/D [1836 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1827 0 obj <<
-/D [1824 0 R /XYZ 56.6929 119.3275 null]
+1839 0 obj <<
+/D [1836 0 R /XYZ 56.6929 119.3275 null]
 >> endobj
-1823 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F55 970 0 R /F48 885 0 R >>
+1835 0 obj <<
+/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R /F55 975 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1830 0 obj <<
+1842 0 obj <<
 /Length 1542      
 /Filter /FlateDecode
 >>
@@ -8002,45 +8047,45 @@ J~
 gAè˜%T A}¦_ž2BóM”·ÌU×ù&ÝÅKµó§Ê…¾Ã¤‹0a¤åý*T¿É"\*
‘†3P?Š+•ê¶º
“¢+wºO"€ˆ¾ô´ÇI°
—°ÇdeÙ¤ˆJ)´¨ÚRŽSâ"&!5Zñ6¯C[ÞP½Ÿ*|úq <«'û(ÝåñA=ÒXW×f‡tð#*6jm®‚]\hA(Â,¯ çàæÖsí%ö=<ÃÊ¢Zò|·í’[… H„OaÒšH‹]¦Ã£A_Fê~Q¤ÙaH€È'AtX<ÛRÚÐΖí—/“Kš¿ ÐV= ýzµÚ/s¡à	Uðf“‰Bkôivg¯T"e´™÷¾u˜|…eþ]/x«Ùı)oo¦WÊŒ¯­-·QåE@pÔÒC3¿ÔÒmì‚Ø–åÒ+Ajõ6ûù1eàáz¬4r̘E'ˆrAê¢aÁÍ¡¾@žï¶á}ž¿¿{ø=n7	¤DjfÎ9T]‘Æi’§Yí¶G³1.M¸8E®•·	èÂxRÕ	g±	ßM±¨b++…[	OAäŒk~©òXozT•¤ÔUWÕc`iRVœõ‚¥‰¥ž’"ø©…K…Q²ÖIš¦ñKÈxHÒç*VgŽ00hCkg©¥ïØ %ᬆXÀÄã4UœŸ	j)+Beš~qöæê[}U¨MŠW]ó¦hCUÒé´	Ž$­i¨µ®¢8,]06~=ÚéÉÜ€ž¢W“Ùøáæ~~s7µôôI-”êPÇ*R˜ÊtS/%»ý\‘àµ.Ö;Íø$-ºrá6HŠh‘kÑtÕj¥/ã=S—-$î*f'#ª&‘>¢˜ÓËìiJUìiÁiØSK•vkNˆæ0…`NqmŒhúF¸o@K¿è\-eñ®ÅCA‘Ϲl»7ÞT57-ãð_¶ÙS^r˜©<éÚÜ2"$‚Nj$óT+ÝZ}”,âÝ2T7Çí˹°€a41oi¹”‹¦ð”×õQÞ¨&]„ЩT[ˆâ²3Óš¹‘&^6ô;Í®§C‹Œy´â ‹¦¶ÌEÕÐv–[dKön5¤.pËHUÜÚwMúz”üI#d1ÙŒ%œ=×혼Ϣ¤›Ê{˜öêÄ4y\>=­8p
 DœcÙvÿCÅѱ]ÃŒ©”è„?£âl sC†ÈËø7„ÎÃo„*ôYÐgÌ£í™S{ìñEËÞ}˜­ÒlÛb&œ§t4â4Xv*i«‹mãFv<¢hâ¯Ò]r<Çœf=…lÁB²—LàíÂAº9@Ùg:FÉå8e·AËTQøv‚¤Ëù%cFäÄX+@{µ¬aì¯M˜á®Ç›Æñ¯9é3ﲓ.ßÒ]–q»úDEÍã¼Èѹ/)0Þ•Ÿ?,{Âuüß_YŽß“ µ0Ï;ÓP†1•ùÄ8UD°ßu½þsêû¿²»œ,endstream
 endobj
-1829 0 obj <<
+1841 0 obj <<
 /Type /Page
-/Contents 1830 0 R
-/Resources 1828 0 R
+/Contents 1842 0 R
+/Resources 1840 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1851 0 R
 >> endobj
-1831 0 obj <<
-/D [1829 0 R /XYZ 85.0394 794.5015 null]
+1843 0 obj <<
+/D [1841 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1832 0 obj <<
-/D [1829 0 R /XYZ 85.0394 562.7154 null]
+1844 0 obj <<
+/D [1841 0 R /XYZ 85.0394 562.7154 null]
 >> endobj
-1833 0 obj <<
-/D [1829 0 R /XYZ 85.0394 499.03 null]
+1845 0 obj <<
+/D [1841 0 R /XYZ 85.0394 499.03 null]
 >> endobj
-626 0 obj <<
-/D [1829 0 R /XYZ 85.0394 459.6249 null]
+630 0 obj <<
+/D [1841 0 R /XYZ 85.0394 459.6249 null]
 >> endobj
-1834 0 obj <<
-/D [1829 0 R /XYZ 85.0394 426.4105 null]
+1846 0 obj <<
+/D [1841 0 R /XYZ 85.0394 426.4105 null]
 >> endobj
-1835 0 obj <<
-/D [1829 0 R /XYZ 85.0394 390.6449 null]
+1847 0 obj <<
+/D [1841 0 R /XYZ 85.0394 390.6449 null]
 >> endobj
-1836 0 obj <<
-/D [1829 0 R /XYZ 85.0394 324.0377 null]
+1848 0 obj <<
+/D [1841 0 R /XYZ 85.0394 324.0377 null]
 >> endobj
-1837 0 obj <<
-/D [1829 0 R /XYZ 85.0394 263.3171 null]
+1849 0 obj <<
+/D [1841 0 R /XYZ 85.0394 263.3171 null]
 >> endobj
-1838 0 obj <<
-/D [1829 0 R /XYZ 85.0394 199.6317 null]
+1850 0 obj <<
+/D [1841 0 R /XYZ 85.0394 199.6317 null]
 >> endobj
-1828 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F53 962 0 R /F55 970 0 R >>
+1840 0 obj <<
+/Font << /F37 751 0 R /F39 868 0 R /F23 686 0 R /F21 662 0 R /F47 884 0 R /F53 967 0 R /F55 975 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1842 0 obj <<
+1854 0 obj <<
 /Length 1880      
 /Filter /FlateDecode
 >>
@@ -8055,76 +8100,84 @@ x
 cØ¡Qø”—â’7ÂQó·ééœh„aª2ˆ»°+s^7ôÝ5^cAß> endobj
-1843 0 obj <<
-/D [1841 0 R /XYZ 56.6929 794.5015 null]
+1855 0 obj <<
+/D [1853 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1844 0 obj <<
-/D [1841 0 R /XYZ 56.6929 687.0104 null]
+1856 0 obj <<
+/D [1853 0 R /XYZ 56.6929 687.0104 null]
 >> endobj
-1845 0 obj <<
-/D [1841 0 R /XYZ 56.6929 626.5588 null]
+1857 0 obj <<
+/D [1853 0 R /XYZ 56.6929 626.5588 null]
 >> endobj
-1846 0 obj <<
-/D [1841 0 R /XYZ 56.6929 566.1072 null]
+1858 0 obj <<
+/D [1853 0 R /XYZ 56.6929 566.1072 null]
 >> endobj
-630 0 obj <<
-/D [1841 0 R /XYZ 56.6929 528.949 null]
+634 0 obj <<
+/D [1853 0 R /XYZ 56.6929 528.949 null]
 >> endobj
-1847 0 obj <<
-/D [1841 0 R /XYZ 56.6929 496.7215 null]
+1859 0 obj <<
+/D [1853 0 R /XYZ 56.6929 496.7215 null]
 >> endobj
-1848 0 obj <<
-/D [1841 0 R /XYZ 56.6929 461.9427 null]
+1860 0 obj <<
+/D [1853 0 R /XYZ 56.6929 461.9427 null]
 >> endobj
-1849 0 obj <<
-/D [1841 0 R /XYZ 56.6929 398.5692 null]
+1861 0 obj <<
+/D [1853 0 R /XYZ 56.6929 398.5692 null]
 >> endobj
-1850 0 obj <<
-/D [1841 0 R /XYZ 56.6929 263.2909 null]
+1862 0 obj <<
+/D [1853 0 R /XYZ 56.6929 263.2909 null]
 >> endobj
-1851 0 obj <<
-/D [1841 0 R /XYZ 56.6929 125.0477 null]
+1863 0 obj <<
+/D [1853 0 R /XYZ 56.6929 125.0477 null]
 >> endobj
-1840 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F53 962 0 R >>
+1852 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F47 884 0 R /F53 967 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1854 0 obj <<
-/Length 2946      
-/Filter /FlateDecode
->>
-stream
-xÚÝZY“·~ß_ÁGn•ˆà>ײìȉÖr´‰U±ý0KÎ.Ç&9kÎP²òëÓ8çr#U*m•ˆÁôî¯Ý
†?²ÐaføBŽ&b±Þ_áÅ#¼ûöŠšU$Zµ©¾º»úÓ7L-2’ÊÅÝCk,°Ödq·ùiyóöí«Û¯_¿¿^Q—_¡ë•Àxùææöï7õ}o¯
]Þ|ûêÝõŠ(I	IK&ñòöæÍ«¯W/ÿüêå_þùýí«ë_î¾»zu—k3O0³\ý~õÓ/x±5|w…3Z,>ÂFĺØ_qÁàŒÅžÝÕ»«Ò€­·îÓ1ap¡‘ \.Vf…UŽJ#,àÝJqŠâFb”ŒI,RY‰­>ô×iÒF’E{°Á”‘hdJÖšt£•êMùöXj¯z›ûƇüXåÁ?”Í[`®·=âK`ÄŽvÈöùfµÞæëßþUâm&4ù2蟎×D/ËÇc¶÷³d‡oä5h=ÈVa
&Ï( E5£€Håðë@IÅùü”‘hdÊŽ$’B¨î”?nó é]™mŠÃcONŽ®õ3ÆtÚNny¶éÿZžŽ‡l犠¹¢N"­êjR¨R)¤´TóBmSM5Q9¡®=„èQîÄã`½ËªªÏ¡¡õ«=–Þ¼÷=GëÒýnªvçC~ô´ué»oücyðolOe±t_Ö[OQVñÂïˆn¤S½*Vq_… Ä.“°.¶`9v®,&ƒŸš“ÛŠ©î«{J-€eF£PËÃ.8Í(1Û~ó¾½;µäd;?n‹õ¶ýÞ‰ÌùÖ2xǸnûÞ…Sq4è4ç Y_ýTGõCëÝß®…XþÃ?1@MöÓÒÿÞøŸ2tñc´0
àÁcÀŽ4ÀÄt°þa 	ë¿}TJ}1 œU=(P=r¹ÉwùcV‡èX,oßùß‘…ŠîêdXóö§ÝÃA|_ƒ
-ûÔŒŒ±²p¨pPˆ),"|8 lpÖ¯kÿ.ÛU¥o%;€v°h=îNa”l³ñÌVhhÐYâî3ºlØØgµÅ€[ViXH=ê¢ÊÝ&ŠèÀú~¦m‹Ýæ¾R\‘gá›ÌâÛküC;Äš‘6À
ÊrŸGÔ¤¤­‘øI~?¾¢N¯§&äѶHìÆÜ#ÉÔ±“?D¾#i³–èÛqÔ×EÎs¬žqD5çç¢¢9y~øBeŠ~7E•¹’2¶Ú…ÊXƒè½?Õ¾3Ƙ®ì5?~,ªð®„ë)²j,®#ÚC†n†qݼÛ¡Ÿ€]î惡CjSr0	–|±¦6ûç—ê’Kc@Èé¸&]¥Tó÷ÁÿDÅaŒÏ¤P-¢é*¹êa4’šÅÀÚf1`hý
-ÒOÈRù,[‰hÈW7•HH£:Œg²™éT¶]Z®´É£šbÞ:IA®ÃqǬëüz³f<“j*AÃi æ…¬Ú³S“(DHÑ4N0ƒ=‚œ©æµ©f©T¾«{ĸbg°B`€³¬%ªÞºhQœè2—àÂ4´f	.¶ÓÂÅö…—.y:Õ¾3Ö¢l«êRàZ™x´òÄÓ‚1FÌeKašL"ÈM5Š H`4ý¼é(Ñ%g'ßÀ~=b’höŒ‚(0)OYy0ѸïnÊè÷R•iª<I0øüÁŠõ|t >vy¬aÅàæ´ª&}Àº<Ôùa¦@È$¶åšy;iM›I$rVòÛ¸•h#Ø\IŠb¤¹˜e*Ò™ê–£äP²ËU¬FÔH`¥„¶÷1§Ý•ªÇá£`›$ƒƒ&Ë…Ë÷4VFº5DÛñ»SŒ.l‡‡54Ì;†FRɆ›+yq¤•î”¼`†	Îoä÷­¥±·´KŒyk°hˆ$º¶P]>a
$E›|t¢®‘„Ñí¬îcvÏt.ÒÈóÎÏÜ:.¬ø™€¾M5
ðDåþfà21<pŽ”=Fe,QpÖ8
ÃîÓaí¥E¥?Äp´‡ö'‡ÕdÖ”Âù‡/I‡OÙò¥=[G~˜ö™	»ðÌÄ&}LËç ’Í R"ˆPÅ…ˆ”H¦úÌ0è³|O}«‘ ïKø^
-ѨôÌÑi›jš‘ÊAóðYÁÑ,_):ò5uk²MÆœç½&Kç|í³+‘16R"c49_Kpª!ÉùºjIóP5qçØŒç;(¶ô/â²è|;_Ž_`ÚÕ2úµ—t+d¸øÁÅ—
-ŠÌ3<»0ÿÿQÑ
-I†ÏÜiSM[f¢r–YžOîA£VJëäQpñóÌ%ªî:öÉmÙS«.{?^+¾<õ Ë‹I|¨I»50ӳǯbd
½‰¹¿nþ„œø.%®ñwêÎêòøiZö1ÿ¹MLë_HÄ$;ã™ÛT3úTNÿÕÙK-Uýi—O^j™å¬¹Ô2dmôRK‡·Æ9k2}ƒ;®ÏUÛïleÀù_èXѦ©
-rnW€—÷^5ŽWyʹt“øKO—Áñ,#N;Ó¨ó°™»2íä˜ï2[¯ž˜È—b²{É \«èîw.1gziÙ­X%ƒ¶…¹ýÝ—Uè©NEíÏ­o„«nkئܙ‚íËNu	#ëlgšl×}øÍÂ`ùSvÌê0Xµ>Oµ½î¢Äòûƒï¬#ƒîÔ¡{pæk}[Ú ñ(ŽÅã)/#ßÓ¬Š„Uñ–)ÍÞí	Œy¯žÅ5†K{íÏêí©ò=Õ	 ÓȃDyàe¾)ê V§vy‚NT×zG‚Ý7”GÏêjÊĺ´|]MéTWS&ÔÕ Ñ­«AGª«A»ƺšŠ¥’A«©«­˜‘î°ÕMá[+þ8%0Û]c¬ûm³ý²ß>ÏéÊ`ѯï·}}û  èWmuú²%$ÜJž»ìÚÍ\µDξû¬ÈvŽ©Ø˜kÛ\Å|K„”~3ÿÓ܇AÒ%zI褫ù>%]¢“t‰:Ú™¤KÚ²ãLº¨`—']Š¤{ìË2>u1Â{÷>;¶‹U*X%ccÀ‹h@Ÿ}/¼¹ñÓšŽ£‰aŽ3$2e'„ôYL#¡!‡òþo-Àxendstream
+1866 0 obj <<
+/Length 2947      
+/Filter /FlateDecode
+>>
+stream
+xÚÝZY“·~ß_ÁGn•ˆà>ײäȉÖJ´‰Uqü0KÎ.Ç&9kÎP²òëÓ8çr#U*m•ˆÁôî¯Ý
†?²ÐaføBŽ&b±Þ_áÅ#¼ûU$Zµ©¾¹»úÃk¦Iåâî¡5–FXk²¸Ûü´¼y÷îÕí·o>\¯¨ÀËoÐõJ`¼|{sû·›?û¾w׆.o¾{õþzE”¤ˆ¤%“xy{óöÕ·«—|õòOÿøáöÕõÏwß_½ºKŒµ™'˜Y®~»úég¼ØÀ¾¿Âˆ-Ÿà#b]쯸`HpÆbÏîêýÕ_Ò€­·îÓ1ap¡‘ \.Vf…UŽJ#,àÝJqŠâFb”ŒI,RY‰­>ö×iÒF’E{°Á”‘hdJÖšt£•êMùîXj¯z›ûÆÇüXåÁ?”Í[`®·=âK`ÄŽvÈöùfµÞæë_ÿUâm&4ù2蟎×D/ËÇc¶÷³d‡oä¿5h=ÈVa
&Ï( E5£€HåðË@IÅùü”‘hdÊŽ$’B¨î”?nó é]™mŠÃcONŽ®õOŒé.´ÜòlÓ#þ¥<ÙÎ?AsEDZÕÕ¤P¥RHi©æ…Ú¦šj¢rB]{Ñ¢܉ÇÁz—UUŸ1B"BëyÎÕkmávÏ1éòöþ)_Ÿ{bôìàŸô>Š¼|ÞÊ áÊŽfÕ”o^QÊßÜÚÿƒ.°0þ	LeZ\"AŒ>£ŒÕŒ2"•SF1¢ƒ@Š*èb_nò*øu%ø<_‰j„±Ž*(ƒ€:œ½ËåüãlùTVõÊ„ôFÀ8_‚·ÊEýÙ¿p®¦²{†6ËweU÷»@i×QyªÌ›Ëˆÿ¢J"cLÄ¡UÔÃi·s
+:/
+MÕc7ùCvÚÕÐ$/F†ç¶CÃz£¯,—`é³HM]äØ°+N%€Y:™##MãïÊu6Å>#°Å%›åMx‹]7Ü9~
âÌ„¬Ù&bBµ>€F§Ø¤à&±3X§P {ÀÌÊŽEˆ7ß·«}­ …¢—+Õð(n(6ŸÕKo?ø£ué~7U»ó!?zÚºôÝ7þ±<†Gø76ˆ§²Xº/ë­§(«ˆxá·D7Ò©^•«¸±Bb—IX[°»
W“ÁQMˆÉíÅT÷Õ=¥À2£Q¨åa¼f”˜m¿ýÐÞžZr²Ÿ¶ÅzÛ~ïDæœk¼c\·}H‰喝tš¢ŒóЬ¯~ª£ú¡õþ¯×B,ÿ¦ƒûiéoüOºƒø1ZŠðà1`G`‚:ØHÿ‡0„õ_‚>*¥¾Ϫ¨ˆž€
+¹Üä»ü1«Cx,–·ïýïÈBEwu2¬ÎyûS†nŠá ¾¯A…}j	FÆ`Y8T8(Ä>‹€6¸aË7µ—íªÒ·’@;Ø´w§0J¶Ùxf«@4´
+è,q÷]6lì³ÚbÀ¿-«4,äuQånEt`}?ˆÓ¶Ånsß)®È³ðMfñí5þ•¡‚ÍHàe¹Ï#ê
R
+òÖŽHü$¿
+ßù€×Só¿è[$vcò‘dêØÉ#ß‘´„YKôíˆ8êë"çŒ9VÏŠ8¢šósQÑœ€Ô§Ã.E¬XÜœöOÕ¤X—‡:?ÌT™Ä¶\3o'-¢i3‰DÎJ~·m›+IQŒ4³LEš!SÝr”€Jv¹ŠÕ¨‘	¬”Ðö>æ´»òAõ8|l“dPbÐdù©pùž¦ÑÊHÛš|ÇCVìN1º°VÖÐ0ïI%/n®äÅ‘VºSò‚&8w¾ß·–ÆÞÒ.1æ­Á¢!’èÚB¹*vù„5mòщºDF·³ºOÙñ0JH#‡~âÙ|ŸµáVapv³k)Ú
+(åq2‚Ð
+Svncܼ‘ç̳E5cŸ‘Êè~Ì@9’’ëYeH.çKT#œuT#a„é²Ölb˜ØdƆÝöúŠËK¡³Ú–'›½Øö}î?pêÍC§«ßXÂ<¼µg)îÅ6³¥xß=4é°-S¬¸ì˜&àMÓgrInz1þ´½a+Ôæ2shqÁù¹/û2Ó¹,H#Ï8?p븰âgú6Õ4À•øÛ1€ÈÄð<À9Röu–±D5ÂYà 4»O‡µ—•þÃAÐfØŸpxV“YSzç¾$>eË—öpùaÚg&ìÂ3›ô1-ŸƒH6ƒH‰ B"R"™ê3àÏò=ôq¬F‚¾¯á{)D£ZÐ3g§mªhF*ÍÃG³|¥èhÈ×hxÔa¬É6sž÷š,óµÏ®DÆØH‰ŒÑä|-Á}¨†$çëª%e ÌCÕÄd3œï ØÒw¾‹v
+Ë¢óí|9V|ujWËè×^fЭáâ+_+(2ÏðìÂüÿGED+$>sU¤M5m™‰ÊYfy>¹Z)
¬“sDÁÅÏ3—¨F¸ëØ'·eO­ºìýx­øòXÔƒ,/&ñ¡&íÖÀLlÌ¿Š‘5ô&æ
+üBºúrâ»”¸Æß=¨;«Ëãç9hÙ{DÄüç61­!“ìŒgnSÍè?R9ýWgoµTõç]>y«e–³æV˵Ñ[-Þç¬MÈô
ì¸>W	l¿³•ç¡3`E›¦*Èi¸]^Þ{Õ8^å)çÒMâo=]zÇS°0Œ8íL£ÎÃfîÊ´C’c¾Ël½zb"k\ŠÉî%ƒp­¢»ܹĜé¥e;´b•Úæöw_V¡§:µ?C´¾a›rg
+¶/;Õ%ŒT¬³=j²]÷á7ƒåOÙ1«Ã`ÕúX<Õöº‹Ë¾³ŽºS‡îÁ™¯õmAh/€FÄ£8§¼Œ|O³*VÆ[¦4z·'0æU¼{×níµ?«·§Ê÷T'€L#å—ù¦¨ƒ HX5vœÚå	:Q]ë	^táPj=K¨«)ëjÐòu5¥S]M™PWƒF·®©®í"|ëj*Z”JV­¦®¶bFºÃV7…;lM¬øã”Àlw±î·Í>öË~û<;¤;ƒE¿¾ßöõ타¢_Q´uÖéÛ–p+yî¶kC4s×29ÿùþ‹"Û9¦R`;`j4®msó-R~øÍüOsI—è%]@ã’®æû”t‰NÒ%Rtêhg’.iËŽ_1颂]žt)’îE³.ËøtÖÅïÝGøâØ.V©`•ŒA/¢}ñÅðæ
+<Ä;Lk:Ž&†9bÌÈ”eœÒg]0„†jÈû¿¢¸¤endstream
 endobj
-1853 0 obj <<
+1865 0 obj <<
 /Type /Page
-/Contents 1854 0 R
-/Resources 1852 0 R
+/Contents 1866 0 R
+/Resources 1864 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1851 0 R
 >> endobj
-1855 0 obj <<
-/D [1853 0 R /XYZ 85.0394 794.5015 null]
+1867 0 obj <<
+/D [1865 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1852 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F55 970 0 R /F39 863 0 R >>
+1864 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F55 975 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1858 0 obj <<
+1870 0 obj <<
 /Length 2056      
 /Filter /FlateDecode
 >>
@@ -8133,45 +8186,45 @@ xڥY[o۸~ϯ0
 âëÚqݼ§ôÔû¹‘ǽÁ`í†øÊ:ÍÔGíÌ„C=pSÞU —@Ð#mÍy·˜yÊîj
m&.+8´äv|ˆ6Ö§YhÝú)ÈjèEÇê	DTv‡.·_¡{B-&jèØ›ÇÕ??œó¨©öwôÂ,²Y¾ÁdœÚØßæY™U\§{½C.©•Þ!D´·(aØF£í+`fpÑ,›Þ{2Fö¶¹F©g¨¡‘îWFÅKT¸<„ ÷–åÏe\–Ì—lD`*“Z¼£Ô@÷WTèpŸ-}æE9J`ÇÕÛ·~òï-%;*´£Ú`´íö §Ño§›8‰Ç	s`mËîä®rÁ]¾„¡ÐžÊ¢§z;M¢—(ùu±›ŽÚvTêPµ[rÒ~¾I‚­ëÄÃ÷|r¨#sÈ›2Ÿ"ÂôEHBû-|®K—d…|ßS‡’Ÿ/:å2Ã%AgÁGÞ(;jé3e?Ee~ÒÍZ?Ím¦ÑhJ™ÇZ7™ø©¶wc°²1Üj»[Þ"C}hNK@¤ù~º÷ØÝ²&Î̹ڴøì`2‚\·õ×.AO-»¦Ê®;’_Œ
ºç¢îS­ïµ_vQ£G_¾ä?L?ðáüSíòº2¿˜£É¶N£¬*¯Q$ÂCÌ÷dÿ8îŠ"CÂÃ-XሕùÆ7Um÷«Æöäb^Žî$5«½w8F+ñ0⬫
ï¢*|wöòÆWHJæ÷‡}OM YRo˜&}kµ‡ßÚ{¸ŠÛÛŽuP‡!H6Q¶¿Õhˆ¿ë¨ˆ£º—‡¨éËtGÄ]êýßwöûÿIpGŸºgzêAZ+ ­QÚ„ÐãF”Áàrlû¿òböendstream
 endobj
-1857 0 obj <<
+1869 0 obj <<
 /Type /Page
-/Contents 1858 0 R
-/Resources 1856 0 R
+/Contents 1870 0 R
+/Resources 1868 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1851 0 R
 >> endobj
-1859 0 obj <<
-/D [1857 0 R /XYZ 56.6929 794.5015 null]
+1871 0 obj <<
+/D [1869 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1860 0 obj <<
-/D [1857 0 R /XYZ 56.6929 499.6076 null]
+1872 0 obj <<
+/D [1869 0 R /XYZ 56.6929 499.6076 null]
 >> endobj
-1861 0 obj <<
-/D [1857 0 R /XYZ 56.6929 438.3307 null]
+1873 0 obj <<
+/D [1869 0 R /XYZ 56.6929 438.3307 null]
 >> endobj
-1862 0 obj <<
-/D [1857 0 R /XYZ 56.6929 377.0537 null]
+1874 0 obj <<
+/D [1869 0 R /XYZ 56.6929 377.0537 null]
 >> endobj
-634 0 obj <<
-/D [1857 0 R /XYZ 56.6929 339.322 null]
+638 0 obj <<
+/D [1869 0 R /XYZ 56.6929 339.322 null]
 >> endobj
-1863 0 obj <<
-/D [1857 0 R /XYZ 56.6929 306.8426 null]
+1875 0 obj <<
+/D [1869 0 R /XYZ 56.6929 306.8426 null]
 >> endobj
-1864 0 obj <<
-/D [1857 0 R /XYZ 56.6929 271.8119 null]
+1876 0 obj <<
+/D [1869 0 R /XYZ 56.6929 271.8119 null]
 >> endobj
-1865 0 obj <<
-/D [1857 0 R /XYZ 56.6929 207.6131 null]
+1877 0 obj <<
+/D [1869 0 R /XYZ 56.6929 207.6131 null]
 >> endobj
-1866 0 obj <<
-/D [1857 0 R /XYZ 56.6929 125.3906 null]
+1878 0 obj <<
+/D [1869 0 R /XYZ 56.6929 125.3906 null]
 >> endobj
-1856 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F53 962 0 R >>
+1868 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F55 975 0 R /F23 686 0 R /F39 868 0 R /F47 884 0 R /F53 967 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1869 0 obj <<
+1881 0 obj <<
 /Length 3024      
 /Filter /FlateDecode
 >>
@@ -8190,25 +8243,25 @@ P
 OÛôßH¨•7ö3ÀÈ´F4µx¶TâaB÷b1±}XÔçöV‰÷np pRã°Ù¥#|ÌÜ›MjÃh»n7ó˜-SDHæoD¿~snSEëßw _Ùå¾,¦D^fÈ@2ÏZBóUäÛ¼	Wsðw%™t½ÊœÆŠ¯îzÞÖ_¡ºÝ:‚ëû[âfoç,jÜUâ×ÙgÞ0~Å:küR˜'™ç
êIRí…€ÁÊñp•*NîÃæPðùñª¯vc§‰
ÌÞÛýÑÞ¤å^/½Sìšjï¿ö‡Sc:£@ŒaöíOÑ~l 9cçûªÜÚÆ)­ÀË¥ÍÂÏ¥›¶4L×ín‡N)iä?èÖhK\Ñ7tVˆõ”Œ€“(ÆGüðÒ;5”½Ñ]ÕX3@ÅPÔxÕÊâp‘sÞèðr‰9àÆÏùÖ-ë&ú2à³³5ÌWÞ›ÝßX>î§È›¦È¦lmÍš¡œÏÈÕvVöª1¨‚UÁA!Àé27‚Çâ¥d@#Æ'µ.AmëŽIëÌá‹‹ÝÚËáî®`\Ç}òW_œhc3rë_¶šêà
 +­¦%WãZïÈúNµ—Ê,—UØwHTF™%IBµ>&*ÚeÁ?ü§t‡?”†€h'º@¨ø Ižy#/4
cb¬âîî> endobj
-1870 0 obj <<
-/D [1868 0 R /XYZ 85.0394 794.5015 null]
+1882 0 obj <<
+/D [1880 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1871 0 obj <<
-/D [1868 0 R /XYZ 85.0394 752.2237 null]
+1883 0 obj <<
+/D [1880 0 R /XYZ 85.0394 752.2237 null]
 >> endobj
-1867 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F55 970 0 R /F53 962 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R /Im3 1108 0 R >>
+1879 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F55 975 0 R /F53 967 0 R /F62 1000 0 R /F63 1003 0 R >>
+/XObject << /Im2 989 0 R /Im3 1113 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1874 0 obj <<
+1886 0 obj <<
 /Length 2332      
 /Filter /FlateDecode
 >>
@@ -8228,25 +8281,25 @@ l
 ›¯Ž0ßd¦³ô¤ª ^ñŠóšVTGõt}sëêJ·Wïßá9¯5:;+FOt,ÇHsPc[Ž8dÝFÈ\VåyõÀïié“CðZ¥EÊn¨îºáNݵ+—ØÐ	ÙÕSü
 ÇÄŒkïtþôjZŠ0."Q[ö½Qrê¯lPù?MhŒöå›ÿ·ÿc¦!E7|Z÷ 5¨”`…òzƒêúØè f	ˆÇ²ÿbƒ¼žendstream
 endobj
-1873 0 obj <<
+1885 0 obj <<
 /Type /Page
-/Contents 1874 0 R
-/Resources 1872 0 R
+/Contents 1886 0 R
+/Resources 1884 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1851 0 R
 >> endobj
-1875 0 obj <<
-/D [1873 0 R /XYZ 56.6929 794.5015 null]
+1887 0 obj <<
+/D [1885 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1876 0 obj <<
-/D [1873 0 R /XYZ 56.6929 175.2854 null]
+1888 0 obj <<
+/D [1885 0 R /XYZ 56.6929 175.2854 null]
 >> endobj
-1872 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F53 962 0 R /F62 995 0 R /F39 863 0 R /F63 998 0 R >>
-/XObject << /Im3 1108 0 R /Im2 984 0 R >>
+1884 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F55 975 0 R /F23 686 0 R /F53 967 0 R /F62 1000 0 R /F39 868 0 R /F63 1003 0 R >>
+/XObject << /Im3 1113 0 R /Im2 989 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1879 0 obj <<
+1891 0 obj <<
 /Length 1937      
 /Filter /FlateDecode
 >>
@@ -8261,48 +8314,48 @@ k
 î•PÈ«¿Ÿú½À` ñü«“†Â\õëºÄoõ,«ÿTSMv?Ì•ç¤S“-Ñ\Œ‹ÞHä*R¾N³‡ÛHlc½ s¯
§g0Í`54OZY½·yÈ»êÅÒí¸ÔÆIëˆ;Çæ¯lpµ >®k¡	ÀÛ¶_lžÖý‹Z?vÛ»±O
úÐíë—
 d¯®pƒ]3ófânPìêòiæšûBëo?¢žÞˆ¡‡ÿ“g†áâqÇ+¥wHˆ˜ªÞ?·žëþ_'x—êendstream
 endobj
-1878 0 obj <<
+1890 0 obj <<
 /Type /Page
-/Contents 1879 0 R
-/Resources 1877 0 R
+/Contents 1891 0 R
+/Resources 1889 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 1901 0 R
 >> endobj
-1880 0 obj <<
-/D [1878 0 R /XYZ 85.0394 794.5015 null]
+1892 0 obj <<
+/D [1890 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1881 0 obj <<
-/D [1878 0 R /XYZ 85.0394 751.4893 null]
+1893 0 obj <<
+/D [1890 0 R /XYZ 85.0394 751.4893 null]
 >> endobj
-1882 0 obj <<
-/D [1878 0 R /XYZ 85.0394 670.0469 null]
+1894 0 obj <<
+/D [1890 0 R /XYZ 85.0394 670.0469 null]
 >> endobj
-1883 0 obj <<
-/D [1878 0 R /XYZ 85.0394 556.7566 null]
+1895 0 obj <<
+/D [1890 0 R /XYZ 85.0394 556.7566 null]
 >> endobj
-1884 0 obj <<
-/D [1878 0 R /XYZ 85.0394 475.3142 null]
+1896 0 obj <<
+/D [1890 0 R /XYZ 85.0394 475.3142 null]
 >> endobj
-638 0 obj <<
-/D [1878 0 R /XYZ 85.0394 431.8777 null]
+642 0 obj <<
+/D [1890 0 R /XYZ 85.0394 431.8777 null]
 >> endobj
-1885 0 obj <<
-/D [1878 0 R /XYZ 85.0394 396.8929 null]
+1897 0 obj <<
+/D [1890 0 R /XYZ 85.0394 396.8929 null]
 >> endobj
-1886 0 obj <<
-/D [1878 0 R /XYZ 85.0394 359.3568 null]
+1898 0 obj <<
+/D [1890 0 R /XYZ 85.0394 359.3568 null]
 >> endobj
-1887 0 obj <<
-/D [1878 0 R /XYZ 85.0394 286.9477 null]
+1899 0 obj <<
+/D [1890 0 R /XYZ 85.0394 286.9477 null]
 >> endobj
-1888 0 obj <<
-/D [1878 0 R /XYZ 85.0394 208.4702 null]
+1900 0 obj <<
+/D [1890 0 R /XYZ 85.0394 208.4702 null]
 >> endobj
-1877 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F48 885 0 R /F39 863 0 R /F53 962 0 R >>
+1889 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F47 884 0 R /F48 890 0 R /F39 868 0 R /F53 967 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1892 0 obj <<
+1904 0 obj <<
 /Length 2634      
 /Filter /FlateDecode
 >>
@@ -8314,42 +8367,42 @@ xÚ­Z[o
 Y¦ªÂM0‡0¢XÙ„-çÞ×>¹·d¼†î¾âi“9/%j?íLÃÂ,viD6añáu¬ÇaÐnRÅþBŸx7ÏÂÌSÖO\.·y‘CÂNëx’¯Ù*h³X„×¾¤Å”æÕ ì”°‘˜s*ï(FNe†ÿL§¦›$Tƒëî¥úãCaà)þ˜ØXÆ•u¶yò£PMH#Qç«ÎLa§	ÔfM¨I|þ|ýåzî>SáÍ'žÁqÀ§¹ £åÏwžáò¨ë˜¯YôfïÍÇA‡Ü‘nOç–ÏùÒ1‰éVzù‰Û>΀gŸœ9ÞæŒÜ’+KUúÄ“¨—‰À¦Z±_€ð<¿Y‡¡ÿÛ•q e&i¶=…ïøH0Ày÷•ÇWܶÊ:Ìý0ÙAÀ¬1Pã©í[ð>{n3bæÍ£9DO°I¸ñfd±É‚‰ÚofÃ0£1¾|zuåß½ü|;rê&²T{»ŒW´ß©¢
 þc¡kÇ….@Jǵ¤³æ`îèä(+àÔ!v"ÉágnJiŽÎÅC8É ‰ÂÔ0‰ÂT›D‡vÖ`­u÷ÍA®’Š"‘í+óòÛüŸ·_OiÑç§ë¢ÎvEL6÷¯€Ÿ`Õ€? óäûm»/v:O2¼>6ñ/‚~’.8¾6²‹0»ß¢zg‘vu„†q7XëCa	£RŒòýëž4³ðsÓzIstôÞïÈ#`¥b¬}§mþö*´Á!ñs÷±¯˜Ü(/ë(“1}xeþ¤áPöÿ-pUbendstream
 endobj
-1891 0 obj <<
+1903 0 obj <<
 /Type /Page
-/Contents 1892 0 R
-/Resources 1890 0 R
+/Contents 1904 0 R
+/Resources 1902 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 1901 0 R
 >> endobj
-1893 0 obj <<
-/D [1891 0 R /XYZ 56.6929 794.5015 null]
+1905 0 obj <<
+/D [1903 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1894 0 obj <<
-/D [1891 0 R /XYZ 56.6929 752.2728 null]
+1906 0 obj <<
+/D [1903 0 R /XYZ 56.6929 752.2728 null]
 >> endobj
-1895 0 obj <<
-/D [1891 0 R /XYZ 56.6929 348.0801 null]
+1907 0 obj <<
+/D [1903 0 R /XYZ 56.6929 348.0801 null]
 >> endobj
-1896 0 obj <<
-/D [1891 0 R /XYZ 56.6929 250.1909 null]
+1908 0 obj <<
+/D [1903 0 R /XYZ 56.6929 250.1909 null]
 >> endobj
-1897 0 obj <<
-/D [1891 0 R /XYZ 56.6929 188.746 null]
+1909 0 obj <<
+/D [1903 0 R /XYZ 56.6929 188.746 null]
 >> endobj
-642 0 obj <<
-/D [1891 0 R /XYZ 56.6929 150.8976 null]
+646 0 obj <<
+/D [1903 0 R /XYZ 56.6929 150.8976 null]
 >> endobj
-1898 0 obj <<
-/D [1891 0 R /XYZ 56.6929 118.3669 null]
+1910 0 obj <<
+/D [1903 0 R /XYZ 56.6929 118.3669 null]
 >> endobj
-1899 0 obj <<
-/D [1891 0 R /XYZ 56.6929 83.2849 null]
+1911 0 obj <<
+/D [1903 0 R /XYZ 56.6929 83.2849 null]
 >> endobj
-1890 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F48 885 0 R >>
+1902 0 obj <<
+/Font << /F37 751 0 R /F53 967 0 R /F21 662 0 R /F55 975 0 R /F23 686 0 R /F39 868 0 R /F47 884 0 R /F48 890 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1902 0 obj <<
+1914 0 obj <<
 /Length 2930      
 /Filter /FlateDecode
 >>
@@ -8369,30 +8422,30 @@ _Pj1
 -!£IÍM„R<ÃU½Û|öv‰¸Àq¨Þl'XâùàÒé¤?×W·ã¹¢ž«{ㆻ¯‘´¸i†—’ª2üÅÁDUú¨CUw<0ŽDWŸÃ¡¯_ÝvE¼Äcï©D†5*Æwß*¹Ì½ÚÆÔHåÐ7ˆ”Oœâ¥Qæ´"ˆÆü
YR¸ŸÒåîÉ_+„³sÂ4PüËXÝ~1…XÍœèEGc”X÷öýUù‚+fuß4á¡r|¨û©I“NÈITéYNê$¯)Síp ãMö6ŒHSh†”]†ã‡]ð•avÁ#Ñüoä‘#™C/•Ê—{
É8wöpF‘r4Í;?¡ÀµŸ-B™Ï½™ „ÃÛgŸ @ÉK˜˜rJÁW¨
 DÐo!KaÀ›YKqØðÑÝSÛD–™tbÐqlr(,¶¬Šf™WwÍn³™Ÿ£¡ú9Ú¾õÅü¢B(RJâ”vûë\ØØ#õGæé”L¶ïŸŽ
 ¤ïùjNùræ
Öui²ÚmÉ2ê®z¦Í¦¦•Lþùáübùás2§¡úRr){›ý µàÑNÖŸØ÷,Åž¡9=¶ÅŠøè܇DX÷µÂpÐ…¡bdy[,MJPf³…FF.;<Û÷›vn <ÔEî³ÂáëMôÇ=I?ø•
¬Ë6ÎeãèÝCºu³ó%®ÿÜA—ÕóÁ~Œ-Ãþ!ó†Ûw6ÔødÉSþ܆¨!È]Q[j|‡QÏ7B#߸¾õS·ý˜ÎtâLJ2”°>ÄÀaG€Ð‘ÝmóÍŒ©†AŒ˜êxD3‰8(öç;ó&y-SÐm¦)I÷Rðº'àBh³¡uÔï=Rµ™í+è±Ï9Ë$ï»BüܶVÌù¾dÒòXDÄè„OÈ@Ý<Õ½vŽ&·,UiDµ)_ ª˜P=ѳ b-×øYô0c›P1ô-B¨rCÑe4ëÆã½Ù›AAû·tÅ
íÄKù™Òîc3“F3Ý'ì—e™Â:ö”
•r8ëˆv{_>ˆ®ÈDq×Îw]œ9[Æœ‹c˜:ó²Ê{a`“×qÈÿÕ¦
ñàSQLõå¯ç>þxcº8¼‡yhŽPhÝ'⧛vr¸€ZŒ}ÅçßHw&cA'a°?‚ÎNh+G_–†óä?^2÷ÈP&_–BÂùªYå¶ioæBèpðÑÇÃó›ÐêŽ)‘þÛ#ÃŒÌÇŸaÌê™ö”3{@yî@:ø3_îyüÿþÿ…ýÿo¤SÖîÿ`Þ8~#w"2…w"›²Þÿ§Ã!ïÿÄ+â«endstream
 endobj
-1901 0 obj <<
+1913 0 obj <<
 /Type /Page
-/Contents 1902 0 R
-/Resources 1900 0 R
+/Contents 1914 0 R
+/Resources 1912 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 1901 0 R
 >> endobj
-1903 0 obj <<
-/D [1901 0 R /XYZ 85.0394 794.5015 null]
+1915 0 obj <<
+/D [1913 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1904 0 obj <<
-/D [1901 0 R /XYZ 85.0394 749.0409 null]
+1916 0 obj <<
+/D [1913 0 R /XYZ 85.0394 749.0409 null]
 >> endobj
-1905 0 obj <<
-/D [1901 0 R /XYZ 85.0394 687.8191 null]
+1917 0 obj <<
+/D [1913 0 R /XYZ 85.0394 687.8191 null]
 >> endobj
-1906 0 obj <<
-/D [1901 0 R /XYZ 85.0394 186.4649 null]
+1918 0 obj <<
+/D [1913 0 R /XYZ 85.0394 186.4649 null]
 >> endobj
-1900 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F21 658 0 R /F39 863 0 R /F23 682 0 R >>
+1912 0 obj <<
+/Font << /F37 751 0 R /F53 967 0 R /F21 662 0 R /F39 868 0 R /F23 686 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1909 0 obj <<
+1921 0 obj <<
 /Length 1762      
 /Filter /FlateDecode
 >>
@@ -8408,30 +8461,30 @@ ND
 ê8IÓBpvW|…ébŽ³‘áÒ¹’uQ\!¡uv†Œ=h4bðʘƒ‚潆$oÀP[õÅÃà¦Ìœ¬-Ÿœ0ˆùfFV«æreQ‹"æBéÌò€C(t{±j3ÄaÔöMHȺt0è3 G.â–Ç`β*ê!¿B¼@oÇØAh·m^-„G!nµM5ÖÙ]a‹aQÔ²¢·ÚËŽUF—ËܸÄ%
g’PÓ_Lšý•¬‰ˆ2vê™Ððê;BE$eòGCUDBÓžoè­Ó‹
 û´/eµ.]ÿ[$Æäï®	6n¶ƒÄu³¶kÛÁÉ¿øÚRŽv½!æ]È	Œ&pæÑôpí>Ý;™@U~/;7ŸHÏÞžL7gÇGw$±$‚Kìélå4rE™SÑ¡§¡baFgnõ¦ôÛd¸jÓÞIšêË9±xªièjÇVfÈÓîCaiu^æ×N!ÌDà±l(õ¥Nssx{j^ÕH×Æl§LD”id‹€“Æ·°ˆ3ÕVNy«Çì3ê›´”^§b¦y9¨Ü"!&Éà‹*_«9 M¨”wªõ–uÏÃÜ–½vy‡(‰yß ~3˜lö!½f¬×x`Ù4ÞGOq¤ð5Íy™×
$¶ÉC:Ñsq/S·í0)WIqNØÍh訊šü05„UëtÏeÆôÕéñ.¿ê.ù*ækà+ν¸½Öæ¨ý’@:EÿM)c-&þž#n[@#i 7ênÀS|ÂçtÑ›¸1};{~|r?$t-Ë[O¯jˆ´+»p¿ qÊW‹»~žÀ‡£éˆ~uŠ¿ýcåæSKÖý3Ù¬¤± °9j•2ÆQ*o©Þþ‚¹­ûÿ”GÝendstream
 endobj
-1908 0 obj <<
+1920 0 obj <<
 /Type /Page
-/Contents 1909 0 R
-/Resources 1907 0 R
+/Contents 1921 0 R
+/Resources 1919 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 1901 0 R
 >> endobj
-1910 0 obj <<
-/D [1908 0 R /XYZ 56.6929 794.5015 null]
+1922 0 obj <<
+/D [1920 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1911 0 obj <<
-/D [1908 0 R /XYZ 56.6929 253.0811 null]
+1923 0 obj <<
+/D [1920 0 R /XYZ 56.6929 253.0811 null]
 >> endobj
-1912 0 obj <<
-/D [1908 0 R /XYZ 56.6929 157.3292 null]
+1924 0 obj <<
+/D [1920 0 R /XYZ 56.6929 157.3292 null]
 >> endobj
-1913 0 obj <<
-/D [1908 0 R /XYZ 56.6929 85.4876 null]
+1925 0 obj <<
+/D [1920 0 R /XYZ 56.6929 85.4876 null]
 >> endobj
-1907 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R >>
+1919 0 obj <<
+/Font << /F37 751 0 R /F53 967 0 R /F39 868 0 R /F23 686 0 R /F21 662 0 R /F48 890 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1916 0 obj <<
+1928 0 obj <<
 /Length 2868      
 /Filter /FlateDecode
 >>
@@ -8447,39 +8500,39 @@ E
 É)~ìm[%$fí_ºµoõªÖÅNÍÐ~w~jëÑöÜTµŸÈž÷£éé]U?¿ûÊ$1êtÂêzKpµm'B¦?~Çú`Ñ,j×Æë+_‚!Húµ/]HÇÓ¯¼	··¶O×6[ŒÎ«bGÈ|h}ºáºÙlÉìÒØÿÙ8gºe g¾²H¹gÓi>
 Ù!g7G£å:o´(wþy¼q1¢CŠ	!zzT¾Mª%"íÈЬ]•©©Ï^øŽ0Ól€‹y姽ncÙãìã,A|«á³–Ū;«
ìy¨³—Óýe¿·¨ò§ñð«tN±©Ü1d€èñ ddC¼s6ç5¨taÄõá@ÁƱ‡ríÞɹýŠØ+ÚLÀ éNèÿþ· ã¿?I{lÎd3AÑXÛƒz¡ì†+Ç¢§ :•ýÚ
5½endstream
 endobj
-1915 0 obj <<
+1927 0 obj <<
 /Type /Page
-/Contents 1916 0 R
-/Resources 1914 0 R
+/Contents 1928 0 R
+/Resources 1926 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 1901 0 R
 >> endobj
-1917 0 obj <<
-/D [1915 0 R /XYZ 85.0394 794.5015 null]
+1929 0 obj <<
+/D [1927 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-646 0 obj <<
-/D [1915 0 R /XYZ 85.0394 769.5949 null]
+650 0 obj <<
+/D [1927 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1918 0 obj <<
-/D [1915 0 R /XYZ 85.0394 744.3535 null]
+1930 0 obj <<
+/D [1927 0 R /XYZ 85.0394 744.3535 null]
 >> endobj
-1919 0 obj <<
-/D [1915 0 R /XYZ 85.0394 712.0918 null]
+1931 0 obj <<
+/D [1927 0 R /XYZ 85.0394 712.0918 null]
 >> endobj
-1920 0 obj <<
-/D [1915 0 R /XYZ 85.0394 645.3077 null]
+1932 0 obj <<
+/D [1927 0 R /XYZ 85.0394 645.3077 null]
 >> endobj
-1921 0 obj <<
-/D [1915 0 R /XYZ 85.0394 572.4552 null]
+1933 0 obj <<
+/D [1927 0 R /XYZ 85.0394 572.4552 null]
 >> endobj
-1922 0 obj <<
-/D [1915 0 R /XYZ 85.0394 472.7274 null]
+1934 0 obj <<
+/D [1927 0 R /XYZ 85.0394 472.7274 null]
 >> endobj
-1914 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R /F55 970 0 R >>
+1926 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F39 868 0 R /F53 967 0 R /F55 975 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1925 0 obj <<
+1937 0 obj <<
 /Length 1422      
 /Filter /FlateDecode
 >>
@@ -8492,37 +8545,40 @@ a
 #GTUNN‡¾ŒŠþ˜a¼øp€@ýþ²³®`÷J¹)]H8Ô`jB“ Í`à.`§íƒ)ŽŽÂA¾cÿU2ñÃ2Þ7EÕÙajmºÛ—Á‚NczÌk£9Dl‰€Ÿòº×`*ªlêÆYöu•ÕC¨õa†ÎV «kê²
ÕL`mB}y2J»ÁHßÐÃ	iÎ"ñ
 Û2p—W†¦sç™C0´-SP'$˜P'nØ癿[­¬žåç»›ËÉfvÿ‰VðG> endobj
-1926 0 obj <<
-/D [1924 0 R /XYZ 56.6929 794.5015 null]
+1938 0 obj <<
+/D [1936 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1927 0 obj <<
-/D [1924 0 R /XYZ 56.6929 591.7686 null]
+1939 0 obj <<
+/D [1936 0 R /XYZ 56.6929 591.7686 null]
 >> endobj
-1928 0 obj <<
-/D [1924 0 R /XYZ 56.6929 465.9632 null]
+1940 0 obj <<
+/D [1936 0 R /XYZ 56.6929 465.9632 null]
 >> endobj
-1929 0 obj <<
-/D [1924 0 R /XYZ 56.6929 405.9112 null]
+1941 0 obj <<
+/D [1936 0 R /XYZ 56.6929 405.9112 null]
 >> endobj
-1923 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R /F47 879 0 R >>
+1935 0 obj <<
+/Font << /F37 751 0 R /F21 662 0 R /F55 975 0 R /F23 686 0 R /F39 868 0 R /F48 890 0 R /F47 884 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1134 0 obj
-[650 0 R /Fit]
+1390 0 obj
+[654 0 R /Fit]
 endobj
-1930 0 obj <<
+1139 0 obj
+[654 0 R /Fit]
+endobj
+1942 0 obj <<
 /Type /Encoding
 /Differences [ 0 /.notdef 1/dotaccent/fi/fl/fraction/hungarumlaut/Lslash/lslash/ogonek/ring 10/.notdef 11/breve/minus 13/.notdef 14/Zcaron/zcaron/caron/dotlessi/dotlessj/ff/ffi/ffl/notequal/infinity/lessequal/greaterequal/partialdiff/summation/product/pi/grave/quotesingle/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde 127/.notdef 128/Euro/integral/quotesinglbase/florin/quotedblbase/ellipsis/dagger/daggerdbl/circumflex/perthousand/Scaron/guilsinglleft/OE/Omega/radical/approxequal 144/.notdef 147/quotedblleft/quotedblright/bullet/endash/emdash/tilde/trademark/scaron/guilsinglright/oe/Delta/lozenge/Ydieresis 160/.notdef 161/exclamdown/cent/sterling/currency/yen/brokenbar/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter/onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]
 >> endobj
-1493 0 obj <<
+1505 0 obj <<
 /Length1 1628
 /Length2 8040
 /Length3 532
@@ -8532,7 +8588,7 @@ endobj
 stream
 xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä000Ì ÝÝÝÝ’‚R"‚´t	ÒÈ‹>ïÞûüž³?³?½¿w¾Ìÿ^×Z׺î7¶‡Œ5Ü
 ¬‡¹rðpr‹t´P(ÐWç…C­fL9g0ЇÉ]Á¢#°5@ðòxDDD0rp'/gˆ­+€ù‘ƒ…ý_–ß.+¯ ‘.[€ññÃ…;9‚a®ÿã@=0àjØ@ `€œ–¶‰Š¦€YIÓ †P€¶›¨C@`˜˜`w@ÿ:@p˜5ä÷Õ\8¹d\@€‹y{‚ÀN¿!v€ØÙââòø
€¸l0×ǸÂê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.Su¶ÿöª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.YMEc¶ÿöª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
@@ -8555,156 +8611,156 @@ $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>è.òY[a-³ZyÏ•px9ÝØÜ>穾„»*|,4°ç	Žð=Ï	añŽ©{ZwLVqž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ìŽ
ñâ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¤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Ñ¥³äƒ£DKXôžòxÇ(žÏÑã
©¨“{ÏçÉšj¿dqX·ã·ŸP¦Üv£ä£Ï€³i¬¾AÕ;³@øyŠ*œoLœ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è-ebtxÃ]€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è-ebtxÃ]€s<—ÿ¢:XÝQ…¸w¶²-N;N¾?Vl¤‘vG‰…,Å%ë9êçöË'bìη9|1.…±!]¹¶DšÏó=RԌݬ¤Iˆg‰=Åh_ìŸ5rÿ/˜ÿŸàÿ	tv…;0ÿõ˜endstream
 endobj
-1494 0 obj <<
+1506 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 67
 /LastChar 85
-/Widths 1931 0 R
-/BaseFont /AUEZLU+URWPalladioL-Bold-Slant_167
-/FontDescriptor 1492 0 R
+/Widths 1943 0 R
+/BaseFont /BINIFX+URWPalladioL-Bold-Slant_167
+/FontDescriptor 1504 0 R
 >> endobj
-1492 0 obj <<
+1504 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /AUEZLU+URWPalladioL-Bold-Slant_167
+/FontName /BINIFX+URWPalladioL-Bold-Slant_167
 /ItalicAngle -9
 /StemV 123
 /XHeight 471
 /FontBBox [-152 -301 1000 935]
 /Flags 4
 /CharSet (/C/D/E/H/I/O/R/S/T/U)
-/FontFile 1493 0 R
+/FontFile 1505 0 R
 >> endobj
-1931 0 obj
+1943 0 obj
 [722 833 611 0 0 833 389 0 0 0 0 0 833 0 0 722 611 667 778 ]
 endobj
-1303 0 obj <<
+1320 0 obj <<
 /Length1 771
 /Length2 1151
 /Length3 532
-/Length 1712      
+/Length 1713      
 /Filter /FlateDecode
 >>
 stream
-xÚíRiTSבª¡¬2©¤j=,Œyn4„„H!
£soÈ-ɽôrID¨¤*Ë"]2ŠŠRaU¨J-±
-¯€iáËg‘ªUpêëê*ýÙþzëóçìogïï|g3\Âå,1Œo@¤8F² 6$þ2Y0Äԙ˥1þ¢ QPˆ@B¡X­ÓÞ
-Àˆø+D|üñT&«IàæÏœ$	€X‹¨R™‚T#Zª†R¡r\‰"¤
Ä
X;y#
¬EÒ"Ù40ª$Á$ÅhœIMÁ˜
-‚70¬K}›JGˆ4Jp›’É”HÇ4#*'§º!”–BÖôâRF¦ÐN–Ÿrê/y…Õ~gàÚT‰@†ÃM§F#oÄÉÕi§gƒI…UŠ±d
XÐJ6wåM“¢zGI¥¨š4d
-G0xºÊ¿)œPÿ@™4Ìý÷¯J†+PŒŒ0¤"€û{*†þˆ)“Tâ¸l.¢ˆÔ~{J˜ÖL‚)qÅ’ï¡0Ш!¢">È„ŠÁˆ zJ1‡á$uPÎdNÐ&ÿÕƒ8$-m}ð'yrö(÷&±¿>ÍÏ×g²Vð‹Ç§ZqWzŸ›ý'¢RGFNeÐÛX…Rž"ˆQÒÌ7p¥×–÷žÚV“#©êÌlçÒ­¯~fr‰U¨¿¸KŠ}ƒzmVÛ´ÿöíÏj“áõ\§G>s5óh÷DãÚ½åÿ’­sÿºÉ´;^¢·Æ^Ä>ì¯|øóÅã~^¢Ô?®7éLÄM÷Kµ
ç«kóg&˜š¤Òª%M³ñž¿ù.>Ž½æÚ‰ã#€z§ùB·¾ð¾úl–b|Ñ1‘Çî^C?GšG{,ʱÚ¼ e'û~ÄòLÏ_¬Î…Ô&:=kO˜¾Ÿ·l/‘ÅZ³7åXMHÍ6­á‘pΞ£Âú‡UyÖÙ'â¦ïTeD!¨sÙøt9³±þrí#Ò®0üye›ˆõ=ÓÒŠØàññÌtÞ™Öó½â“_uû^{°:s×Æn®\´}=MdÓß3 ¤§J>-Îy½e´'Pgc/ij3cw–Üþ¾l>{Ð^çêóÕRŸzÝùÿŒ­ZÃâÙ«"2¹šX÷Ëþ	Ü\©­ubÀNƒ—üÉnfg“ÌñÛà'Θ©9Õ¸MJ2½m³ˆÅB«Y÷>¸ûé7IÕ‚±ó’–„«=Ÿ®Ù!xaNà0
-Y
-rU7žyÓŒðCyUôÚ~îß\´ÿøŸ( Ô 
-‵
-"…ö#FŒ‡endstream
+xÚíRkTSW‘ª¡¬òRIÕzX%2$¹Ñ
+ ±hxÊCbî
¹%¹—^.4€ˆ*©Ê²ˆE—-0×¼Vp—Gµâ¬ô|'çODeA 95>”AïbJyŠ :DI3ßÄ•¾[?Ýwz{m®¸ºë˜-3}aé‘­ç·*õe
÷ù:]'š~ŠD>úÍq›ã§èq‡’‘°oØ°Š×O?-Ê6äìm½Ž&{få~ù¬‡Êᄤ—ËÛÛ>ÐÜqϼؒÖäùðg÷gw3ÏÛև߇øUô‘™µ·n¾z’›º©³ßl÷5ì>TBK,?¾‰þçÝ¢«BðjÜ\sy~ÂþgίÍô¶;=©·íKÆr™ÍR¿—s8Lj “H]lŽ-¬–g/ô¾]Q
+¬>ôs+õoi“ý:{°›)t+}¿GšŸS#]p¬ÒIY»@ãRC·FÚÖ·jý±‹–†µùN©
]\¿b(­i/c]òø+ÆoKvÎ|šøâEßó7FzëC¥ÁÍÊõÄŒOŸ™žÃÌÝöÚ&·8…ú«{¤( ´Ïn•±]û÷€ì–1ˆÜÈs¹yôw3—v_8®ÝWñ7ÙzÏo›M{Ä:+AÜ%ìãªGÿºÔj<ÀM’Å÷%Ÿ¼åy¹®ñBu°s]ÁÌDS³DR½¤y6Þ;8ßÍßy¡ï\Q‚%¨w™/ö芨Ïe;ñ&Æzìyé;ôSI”©iäˆ÷¢\Û¡-Rw±D.7øüjs>¬.YßåSwÒôã¼eûàÈl¯µûR׆Õn×êæì=&hxÙTdŸ{*jþAUNz°MÏ–3Û®Ô=&Š"^T%³ˆ¸€³­mYNŒ2¹g?ÙÀóMHyÝãdÝ¡ÃîMßZ¹hÇšÐn wP@O^’ûfëhoH†£¸¹#ÞŒÝ;VzçÇ~T0¸åÜ!Çw¿Øo–ú·Òë/üclÕZ/®£*ÒÀÑÄyZL0à–*mv±\T¤x˜]M2çï¥O]1SKšq»„d~u²º$šké]uÊÛ«bò¥ÒÓšåV3îÌ{RâjyFl>x-”ßX±¸]±~´rÂïn÷DFžó•‘ÂÎ_ά©doâå{“竲ôº®yYÍÝe*tA^[Ï|bø’ûÕicÓf«yÄiüµºcûuç«¡ÑöZhKŒ@Ç}~4¶3ßæýœÂÕtúg˜qiý˜n}h™¥ÿèÎKYQ˜îzD»–‰K^[ÇE×uX—'æ
+š”M
Æ=«Ší?ŽÖe‘ùÊöÛI[VËêOì¶ÛRgwÏ-h™µpçæŸ]/Ë”W~½Þÿk§/#_¾Ž?µÜå[}rÜc|ÒžcGZñ`û5}MNí¬¼ÿ.¹†?8vAÜšx­÷Ëѵ;ù/͉lfb‘—‚\ÕÛgÞø4+âp~5½n€ó.ÚÿüOPjAâZ‘Jû7+-Œˆendstream
 endobj
-1304 0 obj <<
+1321 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1932 0 R
+/Encoding 1944 0 R
 /FirstChar 60
 /LastChar 62
-/Widths 1933 0 R
-/BaseFont /LCGMFN+CMMI10
-/FontDescriptor 1302 0 R
+/Widths 1945 0 R
+/BaseFont /TLGFFE+CMMI10
+/FontDescriptor 1319 0 R
 >> endobj
-1302 0 obj <<
+1319 0 obj <<
 /Ascent 694
 /CapHeight 683
 /Descent -194
-/FontName /LCGMFN+CMMI10
+/FontName /TLGFFE+CMMI10
 /ItalicAngle -14.04
 /StemV 72
 /XHeight 431
 /FontBBox [-32 -250 1048 750]
 /Flags 4
 /CharSet (/less/greater)
-/FontFile 1303 0 R
+/FontFile 1320 0 R
 >> endobj
-1933 0 obj
+1945 0 obj
 [778 0 778 ]
 endobj
-1932 0 obj <<
+1944 0 obj <<
 /Type /Encoding
 /Differences [ 0 /.notdef 60/less 61/.notdef 62/greater 63/.notdef]
 >> endobj
-997 0 obj <<
+1002 0 obj <<
 /Length1 1608
 /Length2 7939
 /Length3 532
-/Length 8789      
-/Filter /FlateDecode
->>
-stream
-xÚívgPTݶ-HPPÉ™&çÐÉ™–œƒº–††î&K(HÎQÉH’sÎ 9#$ˆ€øÐïžsn}ïüº÷üzõvÕ®ÚkιÆsŽ¹VmVF-]^Yª„p@óùž4`ö–Î(]°ƒ¯ÜEXYå‘P0†pP£¡O†P@jÅÄÄXòGw$ÌÆ
àÐ×1ääææù—åwÀÒýžÛ(˜€íöÃ
-G8ÚCзÿãºP(mXÃàP€¼¦–1HCÀ¡¬¡P†:@‘`8@ËÙ³¨Á¬ (('ÀÀÿZ¬ØïÒP|·X²(€r„ZÁn·Aݬ Ž¿]<G(Ò†BÝ~`(€
쀾í€9XÁ!¿	ÜÚ­9"·ö·¾[0-
-²BÂÑ€Û¬Z
-JñDÛ‚Ñ¿s£`·nÂú6‚°rþ]Òß-Ì­
†9 h¨úw.K(C9ÂÁî·¹oÁ‘°?4œQ0›1à ¡6`$E¡nan±wç_uþ[õ`GG¸ûŸÝˆ?QÿäC£ pk> àmN+ômn˜ÿïA9X#@¿ìgÇø\ È?
âø=3œ·$À„ÜZðk з)ÿ3•ùþs"ÿ$þü‘÷'îß5úo‡ø{žÿ­ä‡k€íoà¯p{àj€ßwÌÿ¶‡ÁÝÿMôß
¡1üw  4ø¶
²6·Rð	üe„¡”`nPˆme°Ão{ôÇ®ï"á0è­–ÚàŠˆüͧg³²søÝôÇb\PÈß™ßÊó‡7¿†Š¼¢¼>÷ßoÓ?QZ·ª£õÜo‰ýWêÈ?¿1äänO^ ¨€WH@ôö°	ĄżþM¾?@À­ÕÁh$Ì
ðü¶hàŸÒÿëý×Êìo0ŠVÈï9ÑEƒ ·£õOÃo·•3y«èŸÓ~[ò?Ö†
-uƒZ|™BX‰¼LLIB—Qdt
( Ã?V1ñŸx£+w¿³^õ9’e‡Ð†ŠÚ¥ÍäÊu””7œœ¸äN­Ñ÷ˆ¨/ùŠõ.‹ú…'Ð)á0äPùÝÚ…ke
-¸éÛR§ö
-]8sô&sß±­|*åŸî#>cÕ¯‡‹úœ‚œEëÑymeê÷AÆ€>8m„1œ4¬jõõr¦XÜâd8„²³¤¿V>M¼çÀ7ÁÜ&N\€*ÄJÒÜOµøï8•^Ýçôáö¼J%qõ‡  ‘®.µ&у;ìXBÒ0ÊÚcVKŸ0-SÛ·ߌG?óí·Eƒòñ(€(§¸Ëš’=´øô•ú+y\J6.æꔋ‚œÞ»ó^eúÞ‚·V„(õb*$Ã=AÁžéÌmEéïa9žoñ€Rý3™ÙÑS×!÷8ÎãÒ9‹ÅÕçÜrƒÅ£‘C™Äù\‹-ÕÕ²k±ò¡øáÃÍ8
-ušÅ?Ó<–“G¬dtü®×ö¾ïùZélf
-hEá$=k
-jK‹ê\ô#Œ²Ô_j$ø>Û}~';Äë08~Ⱥ:{¤j7l˜ŒEÖÉ/‘ÕØô 5³î*Tô#ÛýêŒm¥(Ÿ¡\B½MÈb\Zk³u
-ÂKJ^'W²Ù3FÁå¤éÉ.ðÊüÊÕúìðã‹’c=,®¬3jÉ/Ì ¬}橃”.‡Ó6Š&	êÝîU¸¨Ûkh•kgݺKÙ!ì`M«a'x0¡ƒÌ	ùts«,t-¥§†ìC+µýÝû¡ÝÒ^aâBý" ðf°Üpûš±›õvV¥³ƒÃ÷Ì
×pJs®a¯—ÀœÉAgÔ6tå„è/ZÅkQ^î›íF“’Ô¯[t#¾]°rÛÅ‹60^Ùý”ðzFYËP’OI*ÄmÉ×d«òñ¦¾âWfÖòûé!ou¾qÊÜCZhµÐÞ“iQ'÷|(D¦¶xÙ*ª÷d_R½˜Ñ%8Z?Èb+
-à‹)קw&¬š>òÕäø° DxùAt€næ£`öVkøqvëð1']/¸t¡yô8,TÎ.a Os%/i5Bk9ºÃÂqóêò?¾*vO›7…›<ë]¥].>náJAž´AÖ	7MÈTk‡è´±ìŽsḢ—ê>¯ŒmÌw.4…ôí
-ÉzY`yÖP@-ª¤9¯ŸÇæžÓçý¤>Vo€Ì¢éªd>Í/ˆöõÏ}êYÎàá&¸ÄÛøøsc cRí(æ*©.%Ѧó(á^áU3Ö€Ú~Ÿ®EU×:3у¸cé‚u6d'¶K<¢šæ2(Õ<>Í´®x¯¶óÙÓ8'~_R³¬šžn]LKû"îà²f*Ã.ñW
-³¸~h—•¸8˸ƒŒFF¹õ•Šû?ih
-vžj ×`­Ú[­›öÇ|-…>°ë=].žàŽJ,}”›­ûÈi±ð!æÛ‹õÛ‰ÌJ«—–r•øœEk±9,ð”ˆO’ܽ…n®Ðq!páxÓ“1¶¥©~à]ÙDXÞÑTtÿXwd‰–¸rϽ”T…³k«eÛ?ƒ6òg¶òõPªj~«YÏZš{JÃÁp´hü@AÓœlú)ÿ€úBè×@aS‡ž”Y2(õ¡r‹¼û^*84å¹uÞVi¢¾¡HÑÂé…ØÊÏ–)ŸÃ;c4¢ž/{Ž¬Ûe/HìEˆ…jŽÚ¼9CÖ•Š‚ŒüsB—W¨Èòè!&÷E*l.\ÙÈL4´ÚËÚ÷h„¢Æ·GñZÍŽ<çYÎz9†CÅŸäá¦TKñÅ3c/ÕQYV;Ò+Q%_Vªdá¸ô¿ð‘8ܳ
v4e$2iä*õ Œ9csõ3k~YžØaí¼zf¡äö•Á’±¥;Éb1ª"(GO_XLô>ÅGçë%:}¨=Â[#™µ¿Nôp½vCžªÂíu>N1
¬Ê¼íQù„8¬ì¨`æWn-aö­§m+´Y¬~5A”XĽh§"hV לÞ_9æJqB—¡Ìh'·ïžrs)¤<ÃÑ!]‚ŒšÙZ~\ÍHÒzU´NÏh“[€Hái3
-RgT­$vÊ®éï9‡á׺ù§ßWŸa|…psØ´"ÀÅÑÁñgð~¸¿Õxy¿oA‹z¾Â¼âÕëPúí, +ƒ"aª
-GZ÷±Z6ÂlƒÝI§(²‡2˜Zδ!|Ñ?-IO“d×´–ÒÉ5(ÿà6÷YJã[u'·û²«€<±¤­åº	ú$„whïÀˆZ]À3W=K‹g¸2wñÙàZ)’ÅâK«fE™í›˜9½œ·•*(m¯Ö¦ÑúAÔD%Wãj‰r—þôÎ#gg…ø渆"ÂÜWüsU”·ýBãK9œ'Ž²Oû,U•Ì‰É÷3N®î‘Úµ}¶Ãä9õåiæøHª³²4	<ß¿8++¯Vìâ·§4u6b`´˜ÿR	7ÃÅ·)Kæ÷X?¼É~ôÈ[oü¼·çúgšöì=Óbnš¬¹DÒûÊÆgÚØo–òÎÚ^\§’=Κ‰¹”ãÅžvô0páV[hNHOW0Öz<ýPlpИؑ¤õéylv_ióÔ”½Düñœ˜º!aKfÔô–}#Ëd@‡ŸÍˆuÿŠœ}¾<»Qp5Ieëò*']7÷B¼iØDòÛç£èⵓº‹`u#²ëd^‹Ýrs‰ó…–‡‰A6¾×SûjMÇ|:»NquÞÓÃïÌK!j±eÕ±8É“¹
«±¶~ò&ï|ŽH¸—¯¿ÿ2y”2eÆéžE½ûþ
[€hó’ŽÄÆe—Ô;o‘>	$øÖ­ð`-£ñz³ýe.¿š(W {"·ýÈ0	'+_è>
åg혌ÈT`‰}ócÅVMú:DKÏ—_ÀKe<~"SE„|Yø„”cöÍK7Í‘×Ì û`‹ñWý	Ï&“Œ½-òÆqS\šeÛ$ÐÞ*À(¹+œ0)u•QÕ”9Ò={îüyÍëê¾€©¦{ý\JtoeD¿8zK%QR&!k(éËZ"Л¹ÑðØ4ÿ§V0Ò¹È2\û½EŸÉztã;ÅÌ6ú+ŒŽŸrCfEc)lîOÚÕ†8i'|±»UŠ……òï–ëÓÑ ÜDÈdMoÅÏØ'53×Áœ§áLweOª”ÌÂüwͶˆ+»+Ã]ý›õhM.IâµyC]Ó|/ÍŽ™¾õĪ÷¹È”‹ß7ÔeSù°&»¹æ’+±•W|ÿ(̸?ø6|Kú‘œ™µÁ46<6zlDÌ%¡VésF¢¹¦GfôZ¤è)øJâ
P1H|Æ<¼H›8ºîeg©õ/öND-¾ú‰”÷c Ó›UêYœq‘Õ1ºüeÅgÏp™šÂd„@ŒwÓ'vU6Vš4¶¨ž+iÙÚN9dB>
+stream
+xÚívgPTݶ-HPPÉIhrM‘œirNlèZº›,Q@¢ 9G%#A2HÎ9ƒäŒd âC¿{ιõ½óëÞóëÕÛU»j¯9çsÌ9æZµY´tyd K¨"ÂÍäåЀÙ[:£tÁj<²8pk&`a‘CBÁhÂAŒ†>B!y¨@@%`È!Ý‘0[4€]_ǃ‹‹û_–ß!K÷xnw¢`6ÖÛ(áhu@ßBü7êB¡´-`
ƒCršZÆ 
%»’†>@	êE‚á-gK8Ì
+ ³‚:  kÿk°B8@`¿KCñÞbÉ `Êj»Ýu³‚:þvq¡H{
+uû
€¡6H°ú¶hæ`w†ü&pk·Fü!äˆDÜFØßúnÁ´(4Ê
+	sDn³jÉ+þÅmFÿ΂ݺëÛHÂÊùwI|·0·^4怠¡nèß¹,¡å»ßæ¾sDÂþÐpFÁlþÅ€€„Ú€‘8…º…¹ÅþÝÕ	øoÕƒáîv#þDý“‚­y	€·9­Ð·¹m`|¿ä`ùÿ²Cœÿás"ÿ4ˆý÷ÌpÜ’CpwjMÀ§@ߦ°ÿÏTæýωüø?"ðDÞÿ¸×è¿âÿíyþ;´¢3®¶¿€¿.Àí
ƒ¨~ß1ÿW,Øwÿ7Ñ4„þÅð߀ÐàÛ6È8ØÜJÁÏËÿ—†R„¹A!Z0´•-À¿íÑ»¾Š„à·Zþi#€(,ü7Ÿž-ÌÊÎáwÓŸˆþqA g~+ÏÞ|ª
+*Zº\¿MÿDiݪŽÖsw¼%ö_u¨# ÿ\üÆ•E¸jDâ~çðerÉö%e>w$ò¶J¨ˆ$k|X‰A\–³³Ëóõû9[GowWgó1Në:
Wz$>‹˜6!k˜¯S:”‰~‘g„e.0¦ãclKP«>»àÂÌ1yÕ’ ÀdÿS¡Õ¬çn9´éçï©|e>·'ëC‹›f§—ЛÙq€úYšµ«„8ë$fÚõSëÁ·RÞoÛ@*¾«ʹAÔguG…*|«eB‰;}ƒv©¢]ùßÖÒï6”‡yÛ}sx/Gj¢T«$Jñ£•H
âQ–®‹B~RlEÛ1w.ì*Çbr|¬½}$nÖ‡·Gs]> Ã?V1òx£+w¿³\õ9’e‡Ð†ŠØ¥ÍäÊv””7œœ¸äN­Ñ÷«/ùŠö.‹ú…&Ð)âá0äPùÝÚ…k¥èé¹éÛR§ö
+^8³÷&sݱ­|&éŸî#6cÕ¯‡‹úœ‚œEë=öÚÊÔïƒ.Œ}(pÚéc8hXÔêëeM±¸ÄÈpefI­|š
+8xÏŽo‚¹
Lœ¸Uˆ–¤¹ŸjñÝq*½ºÏáÃ'äy•JâêA@"]1\j-L¢3wØ°¥`”µÇ,–>aZ¦¶où¿-Ž~æÚn‹åãQQNq—5%
zh±)è#*õò¸”l\ÌÕ/(YfÿY½wç½Jt½o­QêÅTHú{ò=Ó™5Ú
+R!ß1Âr<;Þâ$ûg2³£§Ä¯Cǥs‹©Ï¹å‹E#‡„2‰ó9[ª«eÖb	äBñÇ›;qäë4‹¦y,'XÈ.ó¹^Ûû¾çm}l3S@+'éY“W[ZTç¤ay þR#ÁWeôùì¯w<Ààø!ËêHô‘ªÝ°a2Y'ŸxVc[ЃÖ̺«P‘|m÷L¨3X´•¢|FSp	õ6!wˆ¥qi­ÍÖ)/)y4ž^ÉdÏ—“¦'»À+Oð+Wë³Ã/HŽõ°8³:̨%¾0€°nô™¦RºNSX)šÄ©wo¸Vá"n®¡U®uë.ýe‡°ƒ5­†âÁ„v0äÓ=Ì­²Ðµ”ž²­ÔÂtwï‡tKy…‰	ö€À›Á²Ãí/hÆnfÔÛYÏß35|\Ã)͹b€½^s$QÛ<.'DÑ
+(^‹òp߬h7š” ~Ý¢ñí‚…Ë.^,°‰ðzÈî§D€×û3ÊZú’|JRA.KÞ&[å/0õî¼2³–ÛOy«óCúÒB«e€öžt‹:¹ïäCA2µÅËV‘ÀP½'Ûz”êÅŒ~,ÁÑ’ØAkQèoL¹>3a…\Ôô‘¯&û‡EÂË"g>1doµÖ‰g·s<î÷‚Ž!4ž„…ÊÚ%ôi®ä%-#£`‚h-GwX8n^]>ÃÇWÅîió¦p•ÞUÚåâãÎäIdØxÓ„LµvˆNÀî8‡Ä|x©îóÊØÆ|çBSP߮ଗ–g
Ô¢Jšóú¹mî9}Þ/@êcõH/š®JäÓü‚h_ÿܧ^à¼n‚K¼?71$ÕŽb¡’êRm:î^5c
¨íÇðêZDQ%qÞ©39ˆ;–*XgEvb»Ä#ªi.ƒRÍãÓLëŠ÷j;Už½À9ñû’šeÕôlëbZÊq5Sv‰¿P ÅùC»¬ÄÅYÚd42Ê¥¯XÜÿÑHC{€T óT½{bÕÞjÝ´?¦Ðàk)øeXïÙr™ÐWTbé£ÜlÝGN‹…1ß^¬ßNdVZ½”¤«ÔÀç,ZãˆÍaþgD¼äî-ç
+Çö7=s`[šzþáÞ•MåME÷¿€uG–h‰+÷ÜKI•9º¶Z¶ý3h#`+]¥J¢æ·šõ¬¥¸¦4G‹Æä5ÍɦŸñ
¨/„~
2…°ëIš%ƒR*µÈ¹ï¥‚CSž[çm•&ê,œ^ˆ®ül™ò‰0¼3F£!âù2°gáȺÝYzñ‚Ä^˜X@°æ¨Í›#díQ¿¸ ˜ßÈ?'ty…Š,ÿˆbx_¸Âæ••ÌDC«½¬}F0j|{¯Õ\þ˜ßsžù¬—}8$QŒáinúAµ$o<½öR•eµ#"Uòe¥rÞ‰KÿñÃ=Û`GS"“H®bʘ#6W?³æ—å‰ÖÎ+ëíø ·¯ô–-ÝI{ˆQeY:BøÂb¢÷‘>:_/!€ÐéË@íáÞÑȬýu¢‡3èµ+òLn¯óqŠq`Uúmò'ÄaeG-3¿rk	³o=m[¾Íbõ«	¢Ä"îE;A{°<¹æôþÊ1gŠº`F;¹Ex÷”‹S>EG‡t	62j"hkùýI5IëUÑ:ƒMn"A˜W¸Í(Î
+òÎqE„¹¯øç*+nû…Æ—²;OeŸöY:«*š“ïgœò'\Ý7"µkûl‡ÉqèËÑÌ'ð9‘Tgeix¿qVV^­ÐÅnOiêlÄ&Àh1ÿ¥n†	Šo-R’È!î±~x“ýè‘·ÞøyoÏõÏ4íÙ{¦Å\4X²‰¤÷•Ï´±ÝÈ/åµ½¸N%{’;4u)Ç!‹=íè¡ç"Â3¬¶Ðœš®`¬õ0¼f»åæ6ç-#vƒl|¯göÕšŽùí:qÄÔyN¿3-y„¨Å–UÇâ${Læ6¬ÆÚRøÉ™¼ó¥?"áZ¾þþË\øQ>È”	§{õîû7l]¢ÍK*;”]Rï¼Eú4à[·NhÀƒµŒÆëÍö—¹|j"œl‰\ö#Ã$,¼¡û4”Ÿµc2"S%öÍOZ5éê˜-=_~/•˜ñøˆLreá’ŽÙ7/Ý4w„_3ìƒý-Æ_õg$¨L&{[äã¤.¸4Ë<±I ½U€QrW(aRë*­ª)}¤{öÜùóš×Õ}ÿSM#¶ú¹”è>ž6ʈ~1ô–r¢„tBÖPÒ—µD 7S£á±iþ1N­@¤s‘e¸ö{‹>“õèÆw
+™mÜtW?e‡ÌŠØÇRXÝŸ¶«
qÐNøb%2t)(	æß-Ö§9¢A¸‰Éš2žŠŸ±;Njf:¯ƒ9NÃïÊœT)š…ùïš=l“'v!V‚»ú7?êÑš\“Äk=ò†º¦ù^š-2~ë‰Uïs‘.»o¨ËªüaMfsÍ%W2b+¯ø¾
+(Ì°?ø6|Kú‘œ™µÁ86<6zlDÌ)®VésF¢¹¦GfôZ¸èøJü
P!HlÆ<¼H›8ºîeg©õ/¶D-¾ú‰¤÷ ã›UêYœqáÕ±ÇøË
+*Ïp›Â¤AwÓ'v•ù7Vš4¶¨ž+jÙÚN9dB–?qhYêJÁoȯü¸"Š˜‰œñµŠýVw$ˆÇÑ5-C¶Ãö&šgŸI}2Ñ»5ãùáö¶DăuéBÿ;¤»¥ªïÕ\rþhüæx€Í?‚^z:“Å„ê!Ïå¨Úqn\*$þ²2RAרêÇ"Yþˆ§ò¾_Zp%ý ¤|r(ÒÚpÀ£5§HêDžæÔà¢èE=$‹a”WXœoäž÷[§	-'å\’Äö	Çn®u>ãÝNí:“‹&#¶Ú(DMèŽ:ïùSŸ}eH÷é-ü™§QìNV]"äéÿ£ùaÛ÷}é¾æÞ<Åä˜÷íŠdƒ‹^š¯¤,²ë^îL±¥«·ßåñ8#Ðx˜ 5ñ­#áÚ;ŽÅÃ\)³–âÐø|4l8•gQÌ%¿×]Ðì÷Q<îEï’Å:猼³Shpã’¤Z¡6bVš¡Q? ²‘«¼EÔÑ}÷’MgŒÄUb"yWVÝô¨iÆ…™®Àô’è¤øÆqÎë]£´¤ù0ŒjÏÔ•‘éf2ÿRQ¾×€<ÜÕ't,>þÜÂÆbª—EW+pLfƒ$ý»ç³{Sã–f"Q)¨Ï¨;Š­u6¡1ï¸mÜ?„½|³íÒb°ø¡ýú‹iÃi³½­æ¼gmîg»}Š!½„cÝcÝØF4ã!mjJXο`ŸÔ)W2júK²õ^}®nl»*Í4ô(Æû‚ú6§º%ü£äœ’SÜçYýå&º˜ÌpÃ'xÂy±—2öå‚ÔSBg×^¯ûíê¦ðجTçFœêJYoŸ7&Š*\Ô~ð6þ/R§ïŽÈ'1ð»uefÞT×즶×}¢{lA õp½
-DЃqB[äßTœB*«ic:5uª ÍÐåS;ùEÑÎÙÀHoÑÏWçx	×ØÄИ0uÎlPÎ5—¢ú½»<>ÕW:‹ƒoY2’˜HJyf€ÇòTcª§Y½ªÄæ'Jçx{êI_Í[¾ÆuE^n¥ñÙ±pmËISDx°ñ¸U
-JŠ+Y–¾^#Y%ÿ	GpXŽÒ0Nãˆ&^-`iªiðŸ;ÐNU‡UîS’7K±Åüð[Žç&“vñ;ÁsZ§â§u‰ö´{§¸àôò‡ëòÔˆBW
×B‹CóáiòT£ÊÚÿ“±'ŒÒÞÚ¾
ZwÕ¢‰?UÛ.[
h‡)qŒÐÇ
-¯5Áƒ ¨“¹Ýa%µxkÐÏ_WÃp)ÉâüdÃSY]K¢þäWOk‹à0É3£¶×ÞGº?úða‚f—ŠTfŒ@Ó\a„¬™âˆÁÜþK ÎÉ?µ;U6±e‹oÕ¨ÓîÅlé¥Âç+D~Y=÷m쨴¤8™a©f¦ÒÑí¸ÆWKð¹û“4^)½_ÓC×Í]µ¬oÚà¾õ)£Ü~ðM ‹/;…G¨¿?7ÙûŠ½ÚaAUE‚EÎ'èö¤t)®yïÞqŸÑŒž`2OÓÏß0”‡F…îý(r.mV")ã€1ÎÖç}~í5¢oèÑ"{€6@æ8ÏÇqCâ~žm+ ^ݯ˜g©SÌÜ’ñ/Þ˜,ƒ0F•Ë÷Ž#ÍÉqFÕúÉ«êv®W‚ÀEßæw°vöJá)ïŒûðD5{$†/~ÝÆúLb“ó¶j=ü8A~íkÑþPw5W-Dgã…SE˜ù‹Ú”ÁvjŽÄg¿™A£zî„}MmTýöÃIÁëÉñ®^ÂÒ¥·
‡ô¹v«¤ÅÁͤý
-m›Hi‘œô
d„†q. „WôâPløFûÐÀî±Ü"“­[¹É`¬?sòŠô£NÙêqüiv	Ž&#‘ÑPb6G¨4Ùpòã¹>¼¾_$”ì¹J‘Nx?~«=!ädœGû¥ªw³ù‡<§=øÓð†T9ºU˜µZ6áa¸•:˜ª/‰rÈÖò12Ê=ùëBB"ûª~fs¸WË!Ó¤˜MÙ{‰ë
,Ïïœ.¤Òp%ü¢ã„õ”/.!ËÐRl=šFb›Hk]~lKÂþk¾ç%˜ºè&!ìi§‘²‡šf§ZÕGeÙj½îgeµÍ’©×O2nbïÅâ¶d\—@9}%Õ
-‡¯0&;ì8u¶IýÚ¼ü?"¦ûø}¶lÞK©#«ÞÓBüFçõ'Ã÷bc-~Žò8îêÜÕ,|¦,kÏ%äq†Ö‰~^÷ŽÓ×™E°~r¥¡˜[©¹Ùéù _T¾lÌâÍÝÛ'6t˵g™ÿêd‘dç}šÕ<æá©íR²óþs·Žx¹
jRZáï†ÉyƒäVåã æ¬
-ù¡M½Þöxhá,ÿ
-áHQ þY»BåÕjªâD^ûÐ."ß·ƽú5Zï°Æ溱@²¬®fµ4ðÎ^‚›M²¸©ým|ÿ	¯©‰É«ê4
-$L¦nW`6»SN™’h܉¥::`í ?ä·¾:*Q “ן”„y·±,ˆÅ’·õç?‘²}ùT{·BV°£3ëÉZmmsÇBkÙ-’Ãøá+@™d׾€ËM¥Üšô³lŒ~‹ûÛ«/xôñTpïÅM~âÓ¶•˜IÓAéoc_3¥KNI/6Và&âûßÕ{´adÂ{Þ@:C&][°A=Ûe¾¶5YØøJ>ªí®(íPãHš(b"»,ŸÚšíÑ)„Ï\˺_ºw‘©¿cð>b»¨Oœ»ÛybôÃ$N`ðöL~kñ^óÛSïž]ÞÙXƒ‚AW°}´e•!]¨µØìà×fÏHÍ·Œš’ ƒGïa:Õsg«1ì8ñÍÑ –äiöÉñhCìò´g¯Ë8ßêô-Ì–~‘9V|T±&Nn·äML†‘§ÚDü”¹Ú>I^Ž”[û•ÞJ¶½ÕÉò<
ë•Zv·yÁ<ü0ˆ¤5ºŒ„hO!ƒÈ÷sÿððd‡åÁúÌ´Jb+"ä(2mfƒ77Ê¿”Í@5'çѾë%eˆýÕ0©ª¥îò{d„þº„”ÇÚtÁïå7M
…Ö¦ª´}s¢ÎŸGÏ’U¤fÉu'¼ˆ6íãÕ°³ôv‹Ø^,!2èöh§Ûo­£Þ`iÓpë1å·¼øê”ÁßÛÙVaðL?ñ5à²Q‹KÚÒ
-‡á{__bçâ.°ßþºæó}<¯½kb¶Þý9\¥™àpDË\TL[\a·¿«NüÆW¨œµ>¿¥t®tÉQÀRD‚!$Dr£G¢1¸AÌý¾¥Y í–.ç#_©ØÉ#¬w¥Å¹ò«|Sþ?Z:è:”—fÆ×’¸ʵhúÏÈ×XaÛfÚœ¯Ú3™B¶“—£Ìü¤‡uቇôä·ÏÔϾʉltãp)’&ÿT+p•°e –íZ­M31I¡ÒÏL«êÈcýªG’«ô"Hx¾çS•ö$Û_Œ*[£n~OYgÚC¢ã® ø
-LóÃI8GU–¿Bã¡\‚–Ÿˆ{éõ´Sû›7M‹Š–…;ûÛ䃵h¹0GQœ&÷
<‹"œ_ý¼ÈAze‰ÀN2ÿPÜJ"u]©¶ÕLòs.}æQùü‰iõHö5¨ñ‹‚‘öqLðëƒýUj[’	=Á®…1Ñè²YÆHOŠåoq ’„!¿‡RÒ¯¸ð%ê«~u¯³¿0Š×·6î;>nE=m½aÔ\{\ÄcïQq”&T/bµ^þü‹}m“¹ò
A’ü陈×O/ÍI>c×b%ÒÌ&ìýºªú· ¶mJ;û7žb{ª6eC‰Æô_è<@ÀbW’+Q'‘šäçÚU›‚ݧ/ˆ+ƒË°a*¦Ûåõú/5
JÔ†½ó'lï	0Kf›/Ð^‰ˆÖ½žO¼¡M	[If§€ãC
`æÔbï1}ÚU*÷ig#™HÓÄ+¸"î2X|F#êLq¶ÀØÙªþr#g
-<¤þdÑ
_IÒõ.˜ê¢Ï\9¾§é-xÚÖ-9?›ìÐv_wóý}¾éH`…Ñ'>Êß4¬>äŽT‹¬ÌÛúGäµGÔà…$Í	ï‚7LI›u`žUJ2ì„΃79ç¯~f´lá­ÊΚìïW5?|¸':U—.ûrJoÇÓlÔË5áAÜçxE ³º×ا‰3Ç•ÚTñ#åKþtâ•.iKW@ö/É›ÔÑ÷ ûj&Q ¦Œ²È˜¥t°Èð§Äh-ؤ1íý b?e¾™F	Š– ÉXrÙ/&Šjz©¨rAÁM°re.2Òe%ÉÍ£™6"5[¹(H4:\mdb“™[i:ýP½2“¿Ýä÷ö0JÑ»pÕh¯QšQ¨ý±Qó_»Ã7;mþã«÷Aú^ÁÐ;Óèvñ¡Õñ¥ã«*’Hóß¹,QëtT½}…ÁbWý€g”ùxÔ$Ó¬GÞ×™®'}¡uÞói õ´’D§ùõ; ¼xðÞÔ¡Æ°~.
°öâ%ÅÅ4O”˜»ª¡Þ»Bï­\ÿÆÈæ 
-†ìvm…$t§³ÎLd?莑ˆ+í–«I&VñZ"-¿35MGöÊìä§7À Ñ4‰>ÅauA×W¯½r‚…`Hã×W{Ûw1Û®­¹E¥^["W¬%BŽ… >«íÜMÑ#nNCuy‹¼Hû%Tž,TÜþ0]4.ïdîžk0œPañœ„5ðYÓëF–?ªU'?Õ‹«žäfü¸Š·Ö¤qCr®až1j,†º¿÷2Ó“=²õáÿ¶D4ÏØeÊÀ¿I
Üóv¼vþ´b„dîÿ¼ø)xý)\+"oÜ´¦ÜD1å[|)h$úØûeGUeŸ?õ¾†Ó<åízznKB†Éd–¬ö…Àÿò!øÿÿOXÁ¡`$aFÚüGÇ)Òendstream
-endobj
-998 0 obj <<
+žä²5Äõv!.[7$›\ÉÌù ö)%Ü-DÇ9øÓ\¯äͯø7F Oâ×ÏžÅÚÅ8i“£òÅf&\†
+-â×6™…ÈXÓØø,ï¾ÆÇ„Ék}YÆð”êA±<‘‹?qâoYêLÁoȯü¸"‚˜‰œñµŠýVw$€ÇÞ5-M¶Ãú&š{ŸQ}2Ñ»5ãùáö¶xĽuéBÿ;¤»¥ªïÕ\rþhüæx¿Í?‚^iºÇ&‹	ÕCžËQµb\¸THüe%¤¼®QÕE²üO¥}¿:y´ÀJ ÛAHù åP¤-´á€[kNÔ/ˆ<Í©ÁEÁ‹zHÃ('¿8/ÖÈ><ï·NZN,±$íŽÝ\ë|.ʳ4
+Úu&IFlµPÈ‹˜<>ê¼çO}ö•>ݧ·ðgžF±;YuQTˆ §ÿæ‡	¬ßôtD¤ûfP˜{s“cÞ·+J	.>xi¾’²È¦{¹3Åš®Þ~—ÛãŒd@ãa‚äÄ·Ž„kï887Kp¥ôRXŠCãóÑ°áTîEQæü^w~@³ßG±¸½Kë3rÎN¡ÀK’jùÚˆYi†Fý€ðF®ÒQG÷QÜKV1Wñ-ˆÄ]uÓ£¦¦Ç¦—D'Å4Žs^ï¥%͇aT{¦®ŒL7“ù—Šð¾äá®^8¡cññçî6S½¤(¸ZÉ€û`2$éß=ŸÝ›·4Žânâ%ÝÄ5Ì&¨¦ȇrŸšÉPjÔj©VÝJ%ž8#/Ô+¶tt:WšœÁcÓ0¤¾öíjMö“¼úŒº£èZ×aóŽÛÆýCØÛÉ7Û¾!-6‹Ú¯¿˜6œ6ÛÛj~ÁSis?ÛíS`¡°è%«èëÆ6¢™hSSÄrþû¤N¹’QëÔ_’­÷êsucÛUi¦¡G1ÞÔ‡´é<Õ
,¡7%ç”b>×Èê/7ÑÀdú^ÉÀŽ‹½ì±/ߤžâ:»özÝoW7…~Äf¥:7âTWÊxû¤¸1RTùã¢öƒ¿°ò}‘<}wD>‰ß­+=ó¦ºf7µ½îÓã'Z׫@='´EþMÅ)TÀSwú‹-Ñl:m‘Ÿ“¡ä÷ËG¡;r­ÒÐ/Ã*Ž¤fŠÞó-xz
+}~ÏLcÄçt>í	ÔN$c÷¬¤úœ ú=nÆ©ngþõžåÆIE^ÕÖŠdÙh›•™&|Œ݃Ûtmðp6ðQYMã©©SÝ;h†.¯ÚÉ/Švö˜ È6èDz‹~¾:ûK¸Æ&†Æ$€±sfƒr®©X¨Õ‡ìÝåö©6¸ÒY|CÈœ‘ÄHRÊ=›Ð<Ž3 S=ÍêU%6?Q<ÇÛSOújÞò5®+òr+׎™s[VŠ"ƒ¹ˆÛ­R@BLȼô½øóÉ*ùOx<‚Ýr”†a¯@$ñjKSMƒï”Øvª*8¬rŸâ¼Y¼ˆ5æ‡ßr¿™”‹ïÔØ	žÓâ8»­KÔ°§Ý;…§—?\—§Fä»j8‚\šO“§•×†øžŽu8a”öÖömÐú»«MÌø©rÛvÙjÐC;L‰C`„>Vx­iôALí+©Å[ƒ~þº†KIoä&žá2j4+»,~£7RQÅV$èÃL|‰<ÉœÄÐÖzÜÒýÁÏßo„˜0»T 2chÊ›îà
+!dÌFæö/¨˜õpŽI^ø©Ý©²‰µ([|«Fv/f»H/>_!üËê¹ocG¥%ÅÉs5“•ŽnÇ5¾Z‚ÏÝŸ¤±ðJ©ýšžÇÝ\UËúö¡
î[Ÿ2Êíß2û²Qx„úûs‘½¯Ø«PU XäxŠnO
+IÇäœ÷îÍóÍè	v ó4ýð
CihTðÞ²° ÇÒf%’2Žãl}Þç×^#ò†-¼hC¤ó|7ÄïçiжràÕýŠQÉH‚d.à–ŒñÆld„1(_¾wiNŽ3ªÖO^U·s5@p».ú0}¼ƒµ³W
+Oyâ|g܇;Òðh¬Ù#1|éôë6Ög²›œ·UëáÇ	rk_‹öw€º«¹j!:/œ*¼È_Ô¦¶S+³(#>û­pKÕs%ìÛø“hj£ê·ßN
+\O–ˆuõ–.½½h8¤Ëµ[%-n&í—o{Ø,OJ‹ä k ƒ$4Œsz!¼¢‡bÃ7Ú‡vçˆemÝÊ5Hcý™’W¤uÊTãO³‰³7	†³Ê;B¥È†“ŸÌõáõý"¡dËUŒtúÀóñ[í¹0!Ã<Ú—(U½›È>ä9íÁ;˜Ö€7¤ÊÞ­:À¤Õ²y£7À­ÔÁT}I”C¶–‘Qîì¹È\·ÞWõ3›Ã½ZÆ™&ÝhÄlÊÞK\o`~~çt!•†ó(à'¤§tq	Y†¶bëÑ4r3ÛDZëòa[ö_ó>(ÁÔE7	bO;8<0¹8Ô4;Õª>*ËVëu?+«h–H½~šq»x/·}$ãºÊá+¡V8|ýƒ!Ù‘`Ç©³Mò×ÎàåÇøQÝ'ï³eò^JYõžâ7:¯?¾kñs”ÛqWç®fa Š’Œý4>§ ÇZ'úy]Ü;_GdRÁú	È•†bn¥æf§çƒ\Qù²1³7›^voŸØ4Ò-מyþ«wýE’ñ$-¤;k3¡j¹õ½³"í§¬kEŸÄ¼ÕSíÇ»õ7ó´ÎˆÏÖ1ªÉœÛü¤¦Ð#,õ÷9ïÓ¬æ1Om—’÷Ÿ»uÄËnP“ÒZ}7LÎ$·*1e¥PÈ
mêõ¶ÇCgùVGŠñGÈÚ=Êïà9’"ðfÙ°ÙèRÒxªú;ø®^í,‚£åzOirŠ>׳wÈÍcÅ¥˜?!wÏÇFNyÆ/^€Â(Œ’‰‚SÌ—òñy`LÿâÅ”ÎàQwѳˆ.ýÌéììç ²7L‡²m³‚Ô-Ôc—†\ÂýÂ
îãE>`­X|úZ-‡ŒØ3!lüqÆ׃팚ˆfrMºîôaúKãŠÌˆxè¯Rnºí®{ɼD£?ø&´ÌFóŸ´T%ɘZ8­U6
+3ú·<Ȉ›h¥=¯`·C-ãZ*¾•‘Û3ØJ`+>…p˜;w	cÁ¿ù\åµdf؆:îÉVÂÊ£QÏ
+Ló¶Ú±{iC¤üD8þúñ7.4ß=£Nƒ~ØA·™Y¼ŸíQíì
+;dÕÚÞùYÌú.ëÅ3¬m
+Œ·Ò'OܧZM•ÈkÚEä»óÔAøV¿F+áÖØ\7H”ÕÁ¬–ÞÙ‹s±
+A7µ¢¿ï?å151"yUF„I×íòÏfwÊ*Q;1WG¬ä‡üÖWG9
+dòú“¢Ï¡ã6–±hò¶þ|áç RÖ/?‚jïVÈttf=]«­mîXCh-»E²`?|(“躃Øçw¹©”]“RÉÆè·¸¿½ú‚[O÷^Üä'^m[ñ™4]aÄ‘þÖ9ö5QºÄ”ÔbcÅ‘n"¾ÿ]½GF&<ç
¤3dRµ°%‘	”Ê.Óµ­ÉÂÆWòQmw)‡GÒDa™e¹ÔÖlNA|¦Z–ýÒ½‹Lýƒ÷ÛE}b\ÝîL» &épƒ·gr[‹÷šßžz÷ìòdÈÄº‚íüë£-«‡Z‹ÎîpnöŒ´Ð|˨)	2xqô¦S=w¶Æß
jIž6a›6Ä.OSy]ÆñþS§oa¶Ô«ˆÌ±â£Š51r»%ob2üpȈEÐ&â§ÜÈÕöIòÊp¤ì‚è¯ôV²í­NæçiX¯Ô²»Íæá‡A$­Ñe$D{òD¾Ÿû‡‡';,Ög¦•k\Ü Gái3¼q¸Qþ¥L‚¨99ö]/9(C쯆IV-u—ß$#ô?(Ð%¤<×~ü^nsÑÔpPpmªJÛ7'êüyô,YEj–lw‹hÓ>
;Ko·ˆíŲ"ƒÞhÆðÇû­uÔÌm:n=¦ÇŠX—N7ŒÐä£Ïà‘Çžßi®1zUL-íµf½+OGÅŽF÷Ù*v|­FO]ÆvGÓÙŸ¥¥>Š?$¡$ï.ÇpHSî	4ó¢1Ž‹,V‰Æ;…Š¥"mLôWµOËétoÕÛu_Ý„fhJ#ʯ\ü¦CÀ¹÷)O!òiç¸SÔD3ŸJ6IÐëYåÍW«;Õ9#%“UÔ…ò@KÁÝDFjðc¾®=ésË‹¯N|½Ý‘m*ú‰¯—œœR–Ph<ßûÒøºà;wíöÐ5Ÿ÷ãyí]³õ–èÏáÊ͇#
+Xæ"¢Úbò3¸ý]ub7¾‚夨õù-ÅsÅK>ˆ<–!!’=j‰Á
bê÷](åÏi·t9ù
+KÆ.Ha½+-Ε[åòÿÑÒñx Ciif|-is \‹¦ÿ€|6±m¦ÍñŠ =“1ä`K^!y9ÊÌßIjX÷žXHO~ûLýì«œÈF7v—")òï@µW™[zb™®ÕÚ4“*ý÷L´ªŽœ0–¯z$¹Š/‚„à{>UiO³ýE©²5êæ÷”t¦=Ä;î
+€¯À4?œt€sTeù›!4J%h¹‰¸—ŽQÏ:µ¿yÓ´(kY¸³½M>X‹–
sôqÀirÐÀ³8!ÂùÕÏS€¤Sì$óÅ­$R÷Ñ•amPÍ$?çÔg•ËŸ˜Vd[ƒ1ËiÇO°<Ø_¥¶%yÐœáZ.›eˆô¤Xþ*Iò{()õŠ_¼¾êW÷ºÛ£x}kã¾ããVÔ³Ö–I͵'EÜöGi‚õÂV;áåÏ¿Ø×6™+Ý$Éž	{ýTö"1Ðœä5v-V$ÍlÂÞ¯«ª›bݦ´³ã)º§ÊoS6”hLGñ…îÇ,v%¹u©I~®]%¾)Ñ}ú‚¸2¸ âoJ°]^¯ÿRÓ HmØ;Âúž³d¶ù핈`)ÑÑëùÄÚ”°•dv
+8>ÔfN-öÓ¥]¥rÆp4’	w0N¼‚+à.ƒÅf4¢ÎfŒý˜¬ê/7r¦ÀCêOÝpñ%\ï‚©.úÌ•â{šÞ‚§mÝ’ó³éÁm÷µp7ßßçŽÆQ}⥜ñMÃècFn°ãH¶ÈH¿­D^{D
^HÒœð.xØ´Yæ^¥$ÃNèR¾äK'^é’²td?õ’¸I}²ß©fxaúÁ(‹Œ™K‹ŠÖâ€MÓÞ*ôSæ›iô‘ h	šŒ%–ýb¢¨¦—úˆ*äÝ*Wæò(#]V’Ü<ši#ÒY²•Š‚DÁ°¡ÃÕFFV鹕6ÁóÑÕ+3ÙøÛM~o£¼Wö¥Ø…Ú©5QÐ8ÿµ;¼³Óæ?¾z¤á½³0MñÇ€nZ_:¾ª"‰4Oñ÷
™Ë±NGÕÛØW,vÕxF™GM2Îzä}ézÚZç=¯‘ZO+Itš_¿Êk÷ïMjëgàÒk/^R\LsG‰
+²©
+3ã½+ôÞÊ•÷aˆlª Ïn×–OBw:ëÌDöƒ^ቃ€¸Rn¹šd¢¯ÅÓò;SÓtd®ÌA~zM“èRVt}õÚ+'˜	†4~}µ÷°}³íÚš[T:áµ%|Å’Q"èXê³ÚÎÝ9"áòç0Tw³È‹d·¿Pô@åÉ@ÅìÓEâòxOæî¹Ã	åÏIXUb_4²üQ
¨:ù©^\õ47ãÇU¸µ&²ðc
óŒA«`á0Ôýµ˜—™žÌ‘¥ˆß·%¢y†.Sz¾M²hàž·ãý°óg
#$SÿçÅOÁëÏàBø[yã¦5åž Šq(OÜâƒL#‘'Þ/ãØ«*ûü©¯ð5X1œæ)ol×Ós[2L&³d´/øÿ—ÁÿøÀ
+#Ñ{0ÒŽàÿ",)ïendstream
+endobj
+1003 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 36
 /LastChar 121
-/Widths 1934 0 R
-/BaseFont /NHCECU+NimbusSanL-Bold
-/FontDescriptor 996 0 R
+/Widths 1946 0 R
+/BaseFont /KVEJPS+NimbusSanL-Bold
+/FontDescriptor 1001 0 R
 >> endobj
-996 0 obj <<
+1001 0 obj <<
 /Ascent 722
 /CapHeight 722
 /Descent -217
-/FontName /NHCECU+NimbusSanL-Bold
+/FontName /KVEJPS+NimbusSanL-Bold
 /ItalicAngle 0
 /StemV 141
 /XHeight 532
 /FontBBox [-173 -307 1003 949]
 /Flags 4
 /CharSet (/dollar/hyphen/semicolon/C/D/E/F/G/I/L/N/O/R/T/U/Y/a/c/d/e/f/g/h/i/l/m/n/o/p/q/r/s/t/u/w/y)
-/FontFile 997 0 R
+/FontFile 1002 0 R
 >> endobj
-1934 0 obj
+1946 0 obj
 [556 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 722 722 667 611 778 0 278 0 0 611 0 722 778 0 0 722 0 611 722 0 0 0 667 0 0 0 0 0 0 0 556 0 556 611 556 333 611 611 278 0 0 278 889 611 611 611 611 389 556 333 611 0 778 0 556 ]
 endobj
-994 0 obj <<
+999 0 obj <<
 /Length1 1166
 /Length2 8264
 /Length3 544
@@ -8712,194 +8768,203 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xÚízUX\[Ö-4Á½p'hpw×*(¤€*Ü!‚»înÁ]ƒ»kÜÝ/çôºoŸîûtßîw«öZcÌ=æœcÍýíz(*r%U&3[ÐG[¨+3 ±1q„«Cå˜T@掀'Ó“ŠJ
â`
úú‰ƒŒ ¶Pqc‡'^Í o°¬@> 'ëÓÈþW -Œ ƒØغ”@ ˜5úD‰Ûš:Ú€ ªŽvvÖ™
-në3Áùà§Êþ3+@ÌÖÎ1·pЪ«hÒ100þaåå嘸þÅÄApˆ9@ý´pYÛÚý‘éIBÁžŠ6û#V	l,aqø£]­…ƒƒ‹Øô„1ÃÁÌPÝS¡P31[›?à˜x&LŸšreù»oVP[g¨ûÀ`ÔìÏ–ÌíXÔ¡{G´øÿ?A˜ÿÂÌAN ÈÙ@.¦,¤TsµýI²þCÍ<Ýílí`ck8È=]0ÝáÆN €Ìäéþ¿ÿ¾Ãde˜AL& ó§cø—úÿc/o샸tÌ@ +øÇ÷Ÿ+ý§5³…Z»þ+\ÁØ`‘TP×”V`ø{ïÿŒµ}’dbåæ0±ñp>MÊ“"/'ûßÿéÅ_>ü‰*Cþ§Nà¿$¥¡`[ï?Úyòñ¯–œ@0øÓlhÿc:À¿ë+Ø:@LAÚŽø45OÖÿ:RÿÆÿ×Áú{ŽŽÖÖºBû;O~Àr€?±6†ýG¸±
ÄÚõ¿Üð÷@MÐ?¦ÿÿ #í`l
1š[ÿÓ&ü#Äd¦q0µøǸüå²ÙŸÏ!HÉùãI0±r²þS³€˜ZAApøÓYüI fK)5µ5ƒ@ͪOSi3û'ðmêƒ=Ùóç=Ýû×y*r™bÎMÛšòû[Vú7]•‹83ýfïäR¿xt|Çf¸ÁŒÔ¡ðÚª€„#ãœ'Ò¡R]dydÄ€H‰0ng+^Ñff4|‚ÏøHRAÄ{ÌU
-|ØGè´£ÇÀNâ¨Ð×	éÛb®=R‡äEÚTBbCøª¶DÞ¤W:›[öŠ¨$dEY%Š[Ót¼/oü¥¬½”ùP'û[Ä–~	X2­µc×42:Xµ{—%ÍøFSÓ]¢8œÞ“’˜•G&$ÚÜ|-C­l7…à›ò~»,Nv}»Æî,@HíŒÅfMè\ƒ•jLw~˜,rÿMüF]_©!Ìçªu¶KD]ÅîÅÑO¹÷šÕæ%SSJd2N„ì1«Uòêm!fÕá†ïÆ /ëÍ•‰×Ô8ê.Õ›O4E¢6:UB 5
žÍ..7’M%¼Ì¶#M´-Û\¶1êh߉PÕ;þSB%•N’ek!_>”þl€ýHåQ·8ÐmÕRëp9Þ”Ô3áØš`— ùÅ‚ÁZdžÇÑTæw÷RüÂR#Ö\¸å%u± œÝ{WܘòÃ`rRç&ƒæ°ÅPýþ‚9Ú=q…«yì†,ÝŸ÷4^¾ÿ*»Hg½
kt”PØLrœîZ`n#úíÌÁë5&×Å놄ØS~¡RÎyïþyœkô²Aªl–O#ZÏ6±ÚÄ®Z8JH’ð>â.¤}Þ<•Y8R¹j­år"e¡“@nª2i‰6r–·EnX$:ФBLÅw3[Y©]Ê’TɽÈ|ØZoóY*˜1N1.5"Ÿq}|Ã7ÇDaq*áüqdŸ«AåRkD6–*u!óÔ¸$&³^´ È
-ýÍ8¶öOáÏoëÓ‚úïLîÓ¼¿œ+è¶kÎ6ÙAÝ$=43Žºoô°Jü¨rOwVsr¶Ê¬ðšz¾Ž~ÿ²ºþëÁ‹êËõ-!蔄Wd=R9‹ò”l:VŽhÔïÀ³¼LôÃaìtþ8QIVæyU&Á¡û«ü\žj_E‘{<óéYàôDËæúløa½ê£D–Îîç„xô?¹é$Ì|’"Xûü"rø—Xu[ÊÚ6·èNâ÷AŒ»®qmƒ½Éý¢¹Hx7žMxÃ_Õ[±½z
-¼*K«™Zú¹úÕ°×Wý¢Øø¹.ÔR¯æESúLkéDÐ?«áäv%.;#•ûc~¨¹i
-šI-b´zŸŒU íÑ—þDÅyMß\…‹ÙCó«ïÓÖSätRR˜…$ùÛˆFy/Áê}äYeOÈZñ¸ÕÏ«¥¬øïc}͹ü<	ÂåŠ^úRX¿T[ÅgÝñF/yo\ky“Wb“Ë·Ú{že”Ã_¥b1‰¯ç(17•®LsT/“ks¸àýÄR–Ê8à׆h0ƒÄcsâð]€¡í"Z°p¬Ì¥`ÓTÚÕ¼V£ˆ™×Þš¥”¾Îé;»WžÄi%(¶ØÄ5œ™,—»ì>N*Yƒ?åïyÚóíʈfüλ»²ɽø7ãáFWqÊZS>M…ùdT„Ǫ;£Qס3˱_‹§ÙL_¥Ÿ€(U}Üh-²CöF;5œ}ó.T²¶/0žyÖ]±!3f\CÕ1WR|#¯o‚Ǧ?}Fq?¯ÓfÏ ‰²¾RŒ2Á	œðäÞ"#±ÒŽuXéKS‚ºãµãõðÄ{¯¶©F
-hŠÚ?åðP‘­||èuæsSQ2¨•PbHRóŠêÐ8ꎜ¹MS^MýÜÝ´Ó›û¶ÈnØU´]IÜl(óš–ªÉô˜ÔpXò,Î%0Œ1µky„Òæ®qú§°Ä	ßÉ`hˆ	Y›½	goû[rð`jϾªN¸tÇ\®»–ü»bIBj¬÷¯Âµ^‘•HÝ{”é·ÄÞê>µê9ÙY•Ó¯BšË‘!õõ詃W/lë²(»óT²œEÄ$
^î·lý"Ÿ»É¼µ÷/µ³ÃÚ…/ò½ŠBº¹Ë)E†…å(xˆ¬%ð©»O:Ä$¸]g¤Õ
¾JÑóæÞö…ÕѨ¶EŠŽH¹ïØϹÈGgÔgΨyîDŒg.uøò¤å…MeÕ.…î8ã ÃCK±(Ö.f5i@«v]Q„ƒ¯Å=@Ûp»CDlë£5e…„°
8óMù½€KöVò¯½hŸ’•±¨cÎÔlÊû%±È™‹•3V°°‚`÷b,ˆu®mvÎA“&­ÝTY–vÛ:ìL$cØÜxcšÊï• £\\ª^æû@Ä›xBÐeøü;ÃDÐéÿ˜	Ž*‹ÃA‚¥¼MJ$ˆ¯;ÌPïý47Ø0HïÞ#XýÑôš>ÃêÙ©8„2È^Ï|Pø¦~Œ@ÎtÐCvÅY
÷º÷±ÇØœŽ¸ÍÈëš…^¤Pù]¶B¶š)3iy=-;¤ßÿ¨çÙK%¿ûÉï÷£K}P^å—]èë$Ã;4׺´ˆy¿8¤×[)4±ÆÜ ²T§‘^±"©*
-Ô
+¸'º]÷ñ@f̼ÀÜGgìdô—éËùêÛðFÔ!k£«Ã*.$|™/mßFàŽùyAO&—2Ö…Õªõ¾1Ù«<Žø+vˆý–­Dce”­µEx`Iµ5úÐçK:™¢¦ïÝOÜtó‡ž.erƧbÛ,H/«äíuåí™RrŠò–WW“OF3³gÃ)‡¬Då"\ßžâjèßÓ”võVسïuÔt2C
«Æh]W*é„g̯%ä"‡È@Šr¤Bqf„•4†Fóó<ÐP+]°¹Ng…8à„q/•ãȼ¹b–Òdù&Ê´ºdVNšùÞÕç6bÎNé?ï…çPÒZWïn›vÊ
-bší‘v\aۺΤ:×}¸½øÚ"¤#"tl~–ŠÂó5‚ws¬@ö|KéêyÏ’4%Óù|ô}É=ƒ-RK¨Ö{Öˆ“¤‹xwwa@­â©Ûæí‰ûÂŽKˆ0oýwËŠµºÕ6©M8³q¡ºïˆoâ³·àßYF¤i{#ØHjî˜/„†HP,9;]D»¢ôc¢bÓ*ÃzøüÆísüe¹ÔÊâ°?»ÔÎTùw}ãΗÊâÜšTÆýjy¡1(`ãóŸ©3;çó~•…jffl¯©È{>ë²SÕ†¬[ZÆ€ñí^m5
-îlúôü4 
}ª9Ã¥jj:ÕÂŒÐåÏG‡®ù<Г¾TÄ.ê…H›Ÿ¼IôhÔ?±·!—,ssÝÒ´6¡Ø_KiYˆ÷)|“Ûú£a¬>S±I"(.‡±ÇŽ’¶®îîCî>`™ïñ´Ö³=gL”Ä0·mþƒÝ®•@ !á¬ÃYf‚bÂRò=ñT®Î鈶×Æp·ô6/­¼Ï•ñQfÚð^…|_äb	õm;à×]1Lð–ùæˆùFóYKïÍh¿µS [ÍÚ«²þÒ`’ùQ­"ƒž‹£ÈñʽÊ¢@ÃqØâÐ.Qô™óÊÞÐÖW³_~È‹Q5)Ãæh¥_ç•ÒI¸tò±‰ð¾ØÇ(ŽÊE([~ ×ØÚísqÓÛ9êŸ٢Œ™4¤D£l̾½¦Û²úµ9EŽ6Bp,¢Êòé²êG;òƒâ¨¸²µðÆ&;Ì™µ¥	íKk4[ß#½_mú]–T¯ÙFÇÖÃÿPò.€;4'.úU~ëwÐGA9Aá±Õ*§¬ÇAWö'Æ4RIîHkˆÎZ+{Ö	iùay±3_¼ø’ƒ‡ÇêÉÁ]£¶ÎGBˆÓ
-¸iÛ¬[tÁA°Âü™©÷‡¾ú€µÕÚ…i‰È>íï—{Óût{‹s¹"”C/Óçš²†Vn¥‰2$ò v’+X™gh
tò‡ê’ž0䶷KW0N¬e"HNY9úóÌŒ¨hA®¼Öô‰óÏß_ÈßHã›
§ˆ(X#;B×ý‰Œ\%°üÄ炶zÖÉ7(™öJÇgÄýb-¶ÕÀ$ÉÖ3¡ùzAÎåùv…s¼÷[Jêâ½QÜ<ãF¦=Ç&ÿœl¤rPΧWV€ntBcÈs%¿)œ¬ Žß™(ö׬%¥,R<†H—¢¤‰y]rÉá
MèŸÙªž'b¦§¼±¦æ-o½‹”ÍòË›’Ö¿¶g(>Žó–õM6!ÔX¿JdÏÙ=‘¬ðÜÙðM‰-¨u7¡F#]ÊHtæ@¢î{éÂ^¥‚ÜY”1(öó¢ÙHaè¸zÜÛ™ ììÎΕ›!ócÅWH™¶²ny ÈxtƲ‹5‘mtEîúÍ´¨	ûØ­bñÔŨA÷
-AEÂiæ·Ü¾^Ápš¡¶²S‹q”)ä—®}ÀÈ™’X¦‘Ñê	½ž¹I|&åYöd§œçI»Á~hÜ%i}ºZùñfǤXÂx,¯ðçÝÀŠÆTÀ;=ÝJi×î^‡É¦Öèz,€h?R9Ìó;@Öÿj—þY) Ƀp9:•Iß­¸ùG«
-gwoÔЇ¼V}ŽCsg@ˆÑÕ†šÒm
^©‰iÙ;4
-ú‹®fºÐ61^Ô˜±õƒøåiBž•1•ƒ—ÛÉŽ¸ïõ+üèªicöe	3+âòÖÛ'˜–ÍN¥ê“7ðÉi˜ì§ï´½~2¤bêó²ãò½õþ•`×Êê¯áÞØC?¹ÕÔÌ=u¤ÛˆU¸…Í"â#øŽ\f£N2ú-aäÀoŒâÕþÙ`S6¼T z¿Êqˆêëà5À¬³DÕÓÙ÷“G‹sRç\êõ/0+A¬£6àÄZ{Xv#¾K,,Wx§[~ð윲‹T\Æ…Ñѱ1n“w 
-wŸè’¡µ¸§¶”¬Õ¾Ï®HÁ=ˆÒT“³šÌ6X’>3¡6º­1•üVŽ mjƒ3/7¯=Íôþ
&!nIy<`e%aŠ{ƒ#0SÌ=²\:×Ñòz¤ØGàU%˜YMçËá.žÜÃ_bÔõ~¬›ÖwŸXöçÏ×{7¨‡¬MÅ6ê£BÊæz‘×´‡ïÝpä÷¹QØì‡G2n2ªDö.×hE#£“	Z½¼Y‘ñ&ÐëE\(ÃES¥cùlgK„ŽT@â91D±èc™×Àj…¤ÐiÞÚDÅëÁ»ÂЯ0Tµµ£bÅ$㪌íéyÑdö¸Ì„ýn&¢›\ ‹Hè^¶ÙôX\JÆÇH?!Ê¢ñ*zTD#Äßǧš¿¦3\UƒX¤~d«mNl›oåbã-ÙÜùUÅRù³ž’¹JÖj/3i‡Z+¸V=˜5¶1Jmt•÷êŽ'o›IT/Ãöí©Z'\?¦=0"÷Ñ4¥HíøeA(2½Ø$B¼?ƒíϪE†³FÑ|¾_DÀžûºAqeˆæŒœüµX\K9§†µkÞúšs»¿JÛViS°N}¶²»$|}Ôˆ<4­œ]Z¼´BdHØüˆ^œÝ¬$À½=N²	[¬žgr9Í~[$·*È$#\8GÖiËŽ’'BÃW3Þá*yÛ&ÝôS‡‹p=˜vPbyB^Ûœ;¬·§G¹ª3vipº";ªÚ§TáF8€Ì'HÔ÷«Žee`h>|7x gZ–ÅÒËÔ©}?‘[^æóN^Ö6“/ÇÄ+Ƕ³©…¥>3ÆùR¶¥L@¦ëû1µèÄþÔôe㛚
-F‘PÖçhé!ÍFµù„複ì‚4ãE¢Q¢ªÈŒêË¿$Æ£}IÅD0I>àÅlPól&ÕFXÞáÅâ‹×Ž^ì÷êÑ!W‹ é·qV`ç¥Óz"!׌_j¯Ñò«E’µeä—QúŸŠGÌå«P•['ïkÈôZðÛ5%K…š†Â¸ª¾àÛ㼿°è/©äGZ­Ö¸µ²¤Ë›w f§þĺ#7^•Ÿ?<Žàa¶Úñ9"	ç*‹æz]à•Öˆ·Ñôv–ý £-ÉTqÿ.åó%‚8Þkeÿ3¿[M£6ò¢@Gò‰ƒXúÞ¥çˆS&2ØŸjF[fzØ.½„ø'eCL`KI
-g.£Êù5õ\Ïc¯ªO]ffå,§m¾¼@+¬—q[¹ ,<¸¡ÎIPŸ©if8§”MIe({—Jœ~À$:­`š‘-éé;±‘¬y~`²ŸâÑjr+Ö-±˜…>IEƒfçl±¢ZV­®ô
ÛûUM½5
ßOÇRòˆœN@Èd£èF_ó³òÌu³Gö–l0êYiQ¶ˆrœÔÑeY$î9Ùq+SÊbÁ9+²ÀYƒŒá—)mdA(Å”µˆm;ÞUÓ
ŠÊˆm-Œ/=ŠÉ?ˆ)CHÙrS¶Ô-“×ìª0Kƒk}öW­jõ‰9‡ý@F#iÍKû½D;¦$*µ±¯ˆ:vÍuš
- ¢6G4ÚWó÷mq£Mo’¾íü0zt™žà[ΛÙóïÄ3ÕÝZsÆÈP:dVÔ/fyŨV³Œ§²·ÞŽ%ŸðG5¤ÆA«ÀÞ«§hÏ}Kœ¤=ª4¢a3¨˜– xMPn”ªÇ#qp´ų́çxk lƒ<¶ä¥ùÁãÊ¿aLÆòË+&ç0qwl$^dnÜðy(ÙBÓ¶ûo‘#@¹×M±®@S#8±CjQðç}ékŠ»*lí,¡µ=êïΘexí¬„¢h‹®•ëö¥°gЇ™N¬/U
tùM-w*Û¼¿<ý\ɽ~,($ۥDzÁÏ5dèrР®Êº=¸’+•"‹~tó%Ê"â…,iãä,
-û
-àÑè.šoÏx­g6åëÚ†ÇËVDU±N…;ZÆÒ5oùOhú­—Ð>IîÌ:h^$¼Ôlz×ÚÁÓT	@ÿ}&YƒHõEŒ(=‹qåö6õÙ¨ôW=wš’xsDs‰¼:ŒëöÊ-¶¿{´1öFi”"}±FêÃLf_ÜÅÅ;FO5æøþ|y~U¦Î ‡ëÄCš¢Õ„’+ê´Èø–u{Ó&d¹¿*¯’E牊ô‡Mâ‰t/&%Ï©H6ÛÒ¥Š‡¬GJ×:Ìøö•¿ÒÒ•ß:–”eˆº	—ýq«É(LdOÅ"^$·u1§&j¶ÀZ¬
-Ú=;ˆðá:ØÓÏäÁÏ/én¼¡,*¢`\ÜäK}["ÊHTÆÞˆo`ÝÙýz„N¢&j¸'µ2ó‹|K×c6Qén)'	üÖœëv?.ßüê´–®PÌ£§åZ]GOŸIªvIbŒµ³ÉЄH\Ô‡óÉ}vÆé¾°å1ù{'¾ógâ݇ûmœ‡½*œ‰VákÑJÃÙ9ÿ¾<§µÈi¥ßgCL‚¶áX±rX¯=Gó‹Ûìö.BÒÓ	oû~o‡´~8:_ª˜WzåHTº{‚,×d?u-ôR,ýá²ÍþcQk®‰î•üâŒ'ÄݹQ쪡³¾§Æç‰g\&ÚQ„#J©Yð#Õ²á[ƒËEßE(@˵¸x†üœ³/ö®:g]!$…US	](%v¨	åÑÜ팼`‰jî&^Ûœ?-ó@öùàjÙ÷<³ïlY?XRr$Š™£-ÑTù†~ŠÇ/0‰ÌB¯7Ù×ìYSB{@&A^UEs	$DH@
-٦ϭÓ%"Òð9ÓPëñÞç}ž¡œb
--ý¸Bçhµ0ÊnnL¿ñE~„éMÇv¡“LYd< gñÕ¾ìQ±íÅ EþoÉ|Ľ„\cvê´
-Y	
É4j"¼ÒÜçÞ»6ð¯ø»(~7qBËb“½L*&=¤ö4P'©ð·@Xáѧ†÷§€R§ ÙiîÌ#k]3§&M<~èêÆŽ¬y×–=¶÷.Ö}ìh"rr²Ë«À±æ<³$wt•°CnEÕ@¸*ùwN.߆Z r™LŽ:øõŒªOâTãPêŽ".!ÉMù?dð<Ÿ½h·Õð¯=B­›B]	oº×dûJèoÛ°Æ°­TFØQêP¢úC@qSÁÅùÖ÷¥7_±¸Ôˆ²»ÞÌ3å³_Ž¾«š’ñ #¼Ì‚
¸~sOsÔ|ùƱ-J?§>8_@1.æXIg5ßRic¹RcÔŠª¨Ûý*GÆKVJ°îŠ<íãÞÐèHïñúa˜ô0ÂAYêÎÈÈ¿Ô-U@®—‘ì»Be×âwª\ò“C’.US>˜ôÓ»,Ø "mY)×ÿ»	%´Å§o_)5ݘñÊÇNÑ÷`AG‰Ÿ9PÙ6R‚stñ¥³e›è©ü[Ueï¬ÐÆ9ÆWúÞ¿ë­QW!'M(gÖG}ú1ö%dyÓõz¹þm¤)9adz/°jE/5Ϧ`†€wƹc:…@Å“|_9,ÑçpSþ˼ËËg;VˆÁÆvÓ[¨™5–`Ú¢!¸(횈݆jª¾¯Òº@–î¤û ðÛ`¶ª&ÂU\ôqŸaá|\+.oø."—Þlˆ“Íèô‹qQõ»6Z7ZíBÏ‚$¿Y휅xÁ¬„×ez¹¦b ¼`<¤tI¥å}Y:½¼ù¼ØÅ„ÝB¹ÞVõ-¦»ƒ¹-†p¸•÷IŠËÔíò»Dmä¼CB˸hB®ºåD™¤L.ŠXG]GbK/aµT”Ú¼_¯‘p (5w»0|2¿}¶ºÊ5i¤™Ø×ùîIJŒ*D-dtš?Ý£üO<*$çŒ7}_Ø´·{MF~F~Aµüž è‚Ú;nU•nÚ—sûZ˜7ûÎKø§Ÿ‚%g¼À¢Œ[Fð}‰X]Â¥2ý¢–ä•z‹8ŽÄ¤5üµòDoÅ2µ_¯âÔ¤°mÿ¢šüj	Ýîå]¼@¤FÝÎktdÇjJ×yÇ8x­öàvËÕ’í&jÏõžÇQL6¬w=ÄŸÂËUdçHßÌÜn
t¿”è®þÝüÖv—ü³)¦h	?„K¤AØñì¶,á: á®ããÛ
Nàÿåóÿü?!`j
2†9ØÚì0Ýa ¸ƒ-ì>aþ/¤½endstream
+xÚízUX\[Ö-4Á½p'¸»»WA!T¡Á	àî‚»[p×àîšw÷Ë9ýŸîÛ§û>Ý·ûݪ‡½Ös9çXsµŠŠ\YIÄÜÎ$iudbeò!¶¦Np5¨<“*ÈÂ	ðrš`RQ©Cm@ÿA?b0‰#Ä*nâøÄ«[:L`6 €Èäáãd}ZÙÿ
+´ƒñ”a[»e#f>QâvfN¶ ¨£š“½½
d®
+‚Û9ÁÌ@p>ø©²ÿÌ
+³³wƒA,,´ªZtŒÿBXyyy¦n1qbP?-œA6vödz’AA°§¢ÍÿˆU›H˜Cÿh@kéèhÏÇÂb6=aÌp03äÈB÷T¨Ô\ÌÎö8枉C` ³§¦ÜXþî›5ÔÎêþ05ÿ³%s'{
(ÄÁ	$#þ?ÁOæ¿0#€Èä²@«™%Ë)ÕÝìA’¬À&PsOw{;{ØÄò„€AOLw¸‰3àsyºÿïÄ¿ï0YYæ3G€)Èâéþ¥þƒÀÿØ+˜8 ®= 3È
+þñýçÊàé@Íí 6nÿ
+W4±XDå%uEþÞû?£DEíž$™X¹9Ll<œO“ò¤ÈËÉþwÅzñ—¢Ê&ÿ©ø/I(ØÀûvž|ü«%gþ4›Ú?ǘðïúŠvŽ3€ö_££ä>MÍÓ…õ¿ŽÔ¿ñÿu°þžCÒÉÆæOWhÿaàÉ8@ð‡#6&°ÿ7±…ظý—þ¨úÇôÿtdMl f"P›ÚKB\AæÊG3ËŒË_.›ÿù‚”íà?žd+'ëß8uKˆ™5‡?ÅŸjþ·”P3;sÔ æø4•&0óÐfN0Ø“=ÐÓ½íÁ§A WæÜ´¿¿U¥ÓU¹‰Ó¯aöN.‹G§w˜a6ˆÌHŠ¯­H82Îy⾊+ÿ°*ÕCV@Fˆ$‘ãv±æmfFÃ'øŒ$D¼Ç\% È‡}„N;zì$Ž
+}¾-æÖ#}H^t¡C%$6„¯`GäMz¥»¹å „JBV”U‚¡´5MÇûòÆï@IÚÆK…u²¿Eh嘀%ÛZ;vM#«‹U»wIPÒŒo<5Ý%ŠÃé= …éXydJ¢SÀÍ×2ÔÊvcYؾ)ï·Ïâ”e7°_`ì΄ÔÎXnÖ„Î51X{á¡Ætç‡YbÁ"ðßÄoÔõ•
+PÂ|®Zg{°D4Tí_ý”¯UmQ25¥|AÖ)ëLȳZ¥ Ñb^nônú²ÞB…xM£îR£ùDK$j£sQ5RÓà¹Ð,àêz)ÙTÆËl;bÑBÛ²Ëe£ŽöèU½ã?%TV•t–*[ùêü¡ôgìG*†å^«¶z‡ëñÆ ”¾)ǖлuÈ/Öš ó<Ž–
+G¸»—Úä–Ú±æÂ-/é‹-åìÞ»âÆ,ã³ÿ3™4ǘ(¾€Ú÷ÌÑî‰+\]Èc7déþ¼§ñ
+ýWÉØEºëýhÀX㣄ÂÀf"Ót¯ÐƒpÑo^¯1±¸.öØHˆ=åªåœ÷îߙǹF/;¤Ëfù4£õ?Ò&V›ÚWG	IÞAÜ…tΛ§2GÀ@*7­¢µ\N¤,t(ð£šlED¢­|€ÕmÑG,]hR!¦æâ»™­¬Ô.)ªä^d>lí7Œù,̧—š‘ϸ$ßðÍ1QXžJ¸¼CÇçjP½Tä‘‹¥J]È<$5)‰É¬-²F3Ž­óSøóÛú´ ¾À;Óû4ï/çŠzíZ³ÄFMöD@7IÍŒ“Þ}¬?ªÜÓÕœ\Ç­2k¼¦ž¯#Fß¿†¬®ÿzð¢úrýA[H‘:%áYT΢2%—Ž•#õ;ð,/}Àh;?NTŠ•y^@Ipèþ‡æã*?ׂ§úWQäÏ|z8=Ѳ…~GX¯ÆÆ(‘•‹û9!}ãOnú	3Ÿ¤	Ö>¿ˆþ%VÝ–²¶Í-º“ø}`ã®k\ÇpoR²_ô 	ïƳ	o8à«F+¶WO¡£We)cÕ SK?W¿:öúª_?×…zêBBãõѼhjAŸY-úguœÜ®äÂ`g¤JÌu÷!-AséEŒV
+ô¢=úÒŸ¨8¯é›«p1{h~õ}Ú:cŠœNêC
+¡b!Ñè¨à%ØC½<«â	Y+·þyõ¡”ÿ}¬¯—Ÿ'A¸’|ÑK_
+›—ê«ø¬;Þè%Ïák-oòJlsùV{ϳŒsø«T-#ñõ$æ¦ÒUhŽJâesm¼ŸXÊRüÚð
æxlN¾Ë0´]DŽ•¹l–J»š·Òj1³âÖ[³´ƒÒ×9}gÿÊ“8­ Å{ƒ¸†3“år—ÝÑÇYµ3kð§Â=O{¾}ÑŒßyrwA¶¹ÿf<Üø*NåCkʧ©0‚lÊ°ãX
4ê:tfyökñ4Ûé«ô¥šÏGZ«‡°ìÄý‡ÑN­£<¤‹Õì†íŒgž5EWlÈŒ×P
ä•ßÈëÇ›à±éOŸQÜÏëtXà3H¢¬o€£LApg<ù·È@¬´c]VúÇÒ” îxx}<ñÞ«mj„цš¢öO9ñ&žt=?ÂŽÅ0tû%3ÁQeq8H°ô·I‰ñu‡½Ÿæ‰@ãÃ{«?š^Óg8R";‡P9è[ŠâßÔÈ›
zÈ­¸¨ã^÷>ö˜Xз{]³±Ð‹ª¼ËVÌV7c&-¯§e‡ô›àõ<{©ìw?ùý~´c©Ê«ò²½bdx‡f¸àRo‚1ï‡Ìz+…ÖØG¨Õi¤W¬Hª¥ª"uÃ
+î	…^×Æ}<3ï°÷Ñ;ýeúr¾Æ6¼uˆÄFQÕøê°Š	_¶ÀÇÐKQÇ·¸cq^Г‰Ä¥‚õEq5‡j½oLnÇ:#þŠÝâ°¥K+ÑX$mgãEXRmƒ>ôù’D–N¶¨éÆ{÷Ó#7Ýü¡§k™¼É©Ø6ÒË*‡@=&Å”\Å¢¼åÕÕä“ÑÌìÙpÊ!kQù··§¸Úg#÷4¥E½ì{5ÌP£ª1Z·•ÊA:ᙋë_	¹È!²¢ÜéPœ!deÍ¡Ñü|E4ÔJ·„0l®ÓY!8aÜKåÀ82o®˜¥49¾‰2í.Ù•Ó‚f¾wµÁÁ¹˜³S`úÏ{Aá9”´6Õ»ÛE£r…˜æ;E¤WØvn3©.un/~ ¶=½û[œ¥¢ð|àÝ+;ßR¾zÞ³$CÉt>}_rÏ`‡Ôªýž5â$é"ÞÝ]P«túqóöD™}aG›%D˜À·þ»UÅZÝj›ô&œÎŤPÃwÄ7ñÙ[ðï,cÒ´‚½l$õwÌaBC$(Vœ®¢]Ñ1Q±i•Fa	=|~ã9þr\êeqØŸ]kgªü»¾qçKgqnMªà~µºP™»ÜwŠŒBeÞ§GPñô…¦ä»÷_ãª*H+1,x¼ñLa¼×~X45<D·â+¯Ÿ¨Ö$J;ÀB<ÄÄ<¶3TåT_L|6¦ë—Á¦Õ9U	N¿šû,§ïÙD_Råù-â(¹ŠØhˆØ”T«´º˜å~}'$ŠÝ’*t¦Óè”áÕYÙH’·Ø¥÷»ƒAÎ.•DÜûrÚâÐíXÞ#÷î£DR}eùY{ìKÅxág”â[ï^º©âL‹bàbw©Î'Ä*\•ÕáƆ_îßàø!Ô[7t¿mäxîýqt¹$=+çË$¤v}¸‡c
+Ô!ó®£éÞn¢ò¿ŠM¡[òã¶%¹é!°	ª[ñ‹ÆÚ²1~cX윿Ú´ˆ­È—EÆ¡Õ)™K¦¶æEº Øà Û
KÛJúú¼)^^ºñÑœJ#D‘
+Nf›@‹JìžÔD÷ÊB:]µõ>“UÏ ãÙ™îÖÙñB=4@ŒKlÅÞ6ÂG&½øKzFäX1çl¸·’ÆE·Gs'06‚ð›õ[&–O–·ÚÁ=üœ{€„&™&÷Ú×]Bó¯Fqƒ(›¦Ï0w!rF¹âå‚Ȫ1»,%÷>o¢›d‹Ö$9ޥɼ&ª†Œýà°é$!òƱy/F³tñžŽ~¸Áàò«ýK'ÍÎJ¤@­ÅÏþg„èá×Þ]…µ dOÞaéU¯ŸÎ¬šølò–¾ö˜¿	ó”¹ÇÇPƒ™‹ÀZ¨Œþ¨GÊŸ±ñƒùÏ4˜]òy¿ˆÊÅBuvVÂ×T<ŸuÙ«é@Ö­¬bÀøö¯¶w6}z~Ò†ƒ¾Õ]àÒ
µŠ5êa&è
+ç£C×|h€I_*bMWB¤ÍOÞ$Æ4ŸØÇÛK–¹¹néZ›ÇP®¥µ-Åû¾É‹ÀmýÑ0VŸ©Ú&—ÃØcHGI[Ww÷M w’X{<­õlÏS¥0,ìš¿Æ`·ëÅC%HˆC¸¤êp–™ ˜°„”|@<Õ+ä„s:$¢íµ1Ü-ýÍKkïs|”™6¼W!ß¹XB}Û8ÇõVŒ¼e¿9a`¾ä|ÖÒ{3Úoãø±fíÆMÅ`i0Éâ¨ÆN‘AßÕIdŽxå^e
Q á8lqh—(úÌeeohë«ù/?äÅ(É@D-Ê°¹Z™×yå‚tD®|lG"¼/ö1Š£rÊ–È5·vû\?êïõŽâÜ	‰ìQÆLQ"‹Q6fß^S‡mY‚Úž"G#8QeùtY÷£ùAqT\ÙˆÚŽxc“Ì:2„¥5Z­ï‘Þ¯¶ý.Kª×j£cëá‰(yÀŒ}‰ª0Žõ;HRP^PxGlõ‡ê)ëqЕÉ	´¥a’;Ò¢‹öÊžMBZ~X^ìÌï¾äàá±úArpרˑ¦âFÀ´"nÚ6ë]p¬8fæýáE` ¯&`íEõƒNašp"²O`ûûeÆÞô>½Þâ\®e¥ÐËô¹¦¬¡•[¢‰<ˆ½Ô
+VæZ¡ác€†”'¹ííÒÌŸ‡k@…’SVŽþ<3#êZ¯
}â|çó÷
+72øæÃ)"ŠÖàÈŽÄuD"cWd	,?ñ¹ íŸžu
+
Êæ§=„2ñq¿X‹í41I²õMi~†A§^sy¾]áïý––¾xo7Ï8£™éÀ±É?'©ˆ”óé•5 ÐòÜGÙÖo
+'+¨£À7E6Šý5kI)‹4Ò¥(ib^—ücr8GCúg¶ªç‰˜é)oì…©yË[ï"åF³üò¦dîƒØ#Ê‚ã¼D}“M	uÖ¯ÙsvO¤*hÄ,?Œÿa<”ª6
+*ô
¦ßFòÙ9HÒHØS"‚Á{&í\ÐJ
+rý-Ñ_dg0%0kü$´J¥ó4Ö Åy¿ÒEn@~U±Tþ¬§d®’µÚËAƱÖ®]fmŒR]彺ãÉÛfÕÏ°{;AªÞ	7ˆiŒÈ}4K)R?~YŠL/6‰ïÏ`÷³j‘áǬq4Ÿï°ç¾ÞcP\Y§&¢#'m#×RΩ‡Q­dÍ[_n÷W©ãoÛ*m+Ö	 ÏVv—äà‚¯‘烦U²¢K‹—ÖˆÉÛ‚’èÅÙÍÊÜÛã$›°Åêy&×Óì·Eò«‚L²Â…Óxdvì(y"4|5ãnR·m2M?u¹׃i%Ö‘'´±-¸ÃzqzTª:cg‘§+²£ªPpJo„È|²DÝx¿êQV&FÃwƒòfu`9,ýLÝÚ÷¹åe>ïäì2ùrL½rì:›ZXê3c‘/åZÊd»¾S‹NìOM_6¾©©`D	e}Ž–R0Ðl\›OˆNêqÈ.HÓ8^$%ª†Ì¸ ±üKb<Ú—TL“ä^Ì5Ï6aR}Dqñ€åm .‘q,¾xíèÅ~¯^rµ’Agv^:­'rÍø¥Î-¿z4!Y[FΠI¥ÿ©xÄ\¾*U¹Mò¾¦l¯%¿}S²t¨ùi(Œ[±Úñ¾ÎûËþ’J~´ Õúø`Í[k+º¼y·	bvêO¬;òãUù	ñÃãæ«Ÿ#’p~ r±a®×^ixOog92Ú‘L÷ŸáR>_"èã½Vñ?ó»Õ2nÃ!/
+t"Ÿ8ˆ¥ï]zŽ8…`*‹ý©f´e†¡‡-áÒKˆR.Ķ”¤xæ:Ê1¡’_SÏõ<öªúÔufVÞjÚöË´ÂzqÙ+„…7Ô9	3•"Íâ”r)©£eïR‰Ó˜D§Í2’¡%=}'¶R5ÏïL÷Sº,‹Ä}#/7 nmFY,8gM8k˜1ür!¥€,…¡˜²±mǻ²jºAI±­…Ññ¥G1ùQC“#‰[nʶ€†Uòš}fip­Ïþªu­1gà°Èx$­yi_ —hÇŒDµ6öQ@Ç®…nSô€BÔöˆF‡ãj¾ñ~¢-n´éMҢƮsÁ|Ëy3{þâxfz[k.˜ʇÌJÅ,¯Õ’b–ñT÷vÁÛ±äóžá¨FÔ8èaØ{õí¹o‰“tF•G4m•Ò”î£)ÊS5ãx$N˜6#CŸ÷o
m‘Ç–¼´>x\ù70ŒÉZ}yÅä&®ûŽM“Ä‹ì#7üCJ6„Ьíþ[äPþuS¬ÐÌNì˜Zü9ÅC@æšâ®
+ÛCg‡Kh FýÂPŸúû£&FÙ^;+¡(Ú¢[åºC©Dìôa¦ëKU]~SKÅê¶%ï/O?7r/Å*Éö鱬ÆðsMYº4¨[†Ê‚^®ÔJ¥¢Ý|‰J ˆx!KÚ89‹â¾"x4º‹æÛ³^›Ù„M…º¶áñ²Q5¬S'A᎖±t­[þ“š~›%´OR;³ŽZ×#	/µšÞ5†vð4UÐ_E†IÕ R}Fc‡ÊÌb\}|›úlT櫾;MI¼9¢µD^Æu{õ1¶¿{´1öFy”"}±FúÃLf_ÜÅÅ;FOuæøþ|~5¦Î ÇëÄCš¢Õ„’+ê´Éø–õzÓ&丿ª¬’E牊ô‡Mâ‰t/&%Ï©J5ÛÑ¥Š‡¬GÊÔ:Îøö•¿ÒÖSØ:–’cˆº	—ûq«Å(Lä@Å"^$¿u1§.j¾ÀZ¬Ú=;ˆðá:Ø3ÈäÁÏ/én¼¡,*¢`\ÜäK}[¢pÊHTÁÞˆo`ÝÙýz„N¢&j¸'µ6ó‹|K×c6Qém)'	üÖšëv?.ßüê¼–®XÌ£¯íV]GOŸIª~Ib‚µ³ÉЄH\Ô‡óÉ}vÆù¾%°å1ù{'¾Ëgâ݇ûmœ‡½*œ‰VákÑJ£Ù9ÿ>IžÓZ䀴Òï³€!&A»p¬€Xy¬×ž£ùÅm{!éi„„·}¿·CÚ?/UÌ+¿r"*Ý=AVˆkr˜ˆºz)–þpÙæ YÔškªw¥°8ã	q·An;d„jê®ïé¤ñÄyâ™”‰váˆÒEjüHµjøÖ äzÑw
+ÐöD-.ž!?çìK‡½«ÎYWIaÕR@BJ‰êGBy´øxF^°D5w¯mÁŸ–y ÷|pµƒì{žù÷@¶¬,)9ÅÌÑVŒhj|C?Åã˜Df¡×›ìë¬)¡= SŠ ¯ª¢…¹"$ …\ÓŒçÖéiøœY¨õxïó>ÏPN1…6‚A\¡Ë´Ze77¦ßä"?Âì¦c»ÐY¶,2гøj_î(ØîÇbÿ·d>â^B®1{
ZŬ„†€dš
+u^îsï][øWü]¿›8¡e±É^&UÓR¨³tøÃÇ@XáѧF÷§€Rç ÙiîÌ#=sç&-<~èêÆŽœE×–¶÷.Ö}ìhrr²ë«À±æK<ó$wtÕ°Cn%µ@ݸ*…wN.߆Z¢r™NŽ:úõŒjLâTãPê".!)Où?dð<Ÿ½h·Óô¯=B­›B]	oº×bûJèo×°Æ°­\FØQêX¢öC@iSÑÕåÖ÷¥<7_±­¸ôˆ+²»ÞÌ3å³_Ž¾«–’ñ +¼Ì‚
¸~sOsÔ|ùÆ©-Ê §>8ß`@).æXIw5ßJyc¹RcÔŠª¨Ûý*OÆKVJ°î†<íãÞÐèDïñúa˜ô0ÂAEúÎØØ¿ôc:ª€|/#ÙwÅÊ®Åï>T¸"ä'‡$]jf|0™§ß²`È´eå\ÿ璉<2–Ÿ¾}¥ÔDüÈŒW>vŠ¾:JüÌʶ‘œ£+ˆ/“-×DOåߪ&(wg6Î1þ¸Ò÷þ]o…ˆ†*9iBy8³æ8êÓËØ—åM·óduû]Ã
9Ü8#΋´“Á&¦Î&‚(KF‚Ó·zÄ2ê¹:lÓñ$¼!ÁRÄ_Ù{•ü“l®W!ežE^X’)ý›¹RVÌÍ—^Ñ>ŽDLßäTíÁx)X\|ÏšF;¾Á¶:_wS#s¦›Ü9}µ‘àWú¢÷©¿“]üÔªârŸé†åFݳxUàÍÀ([¦Ü©Þò|ô "rýÛHSrÂÈ&ô^`Õš^zžMÑïŒsÇl
+Š'ù¾r*X¢!Ïñþ¦ü—E——Ïv¬ƒ­Ý¦·P3k,Á´ESpQÆ	<4»
ÕR{_5¤},ÓI;÷Aà·álUM„›¸èã>ÃÂø¸v\Þð]D.½ù'›ñé“¢êwm´¦ºo´Û…žI}³Þ9ñ‚;Z¯ËörMÅ@y=ÀxHéRÊËûrŠt$úyóy±‹	»…ò½­[Lös[ápkï1’שÛåw‰:Èy‡„VqÑ„\uË!ˆ²I™\±NzNÄV^Âê©(µy¿^#á@Pjîvaød~ûlt•ê²2I3±¯ó݉åU‰ZÈè´&~#ºGùŸxTHÍ™lú¾°mo÷&šŒüŒü‚jø=AÉ+´wܺ*ݬ/çöµ0oö/
+–ðO?}ÿJÎxEY{¶ Œàû±º<0„KuúE-+È+õq‰I{økå‰"ÞŠUj#¾~Å©IaÛþE5ùÕºýË»xHͺתèÈNÕ”nóNpðZíÁ+ì–«$ÛMÔžë=£˜l†xžlÜ8Ž×:(n
v#¹ÐWƒt@
+`Lᆫýó”5]ÿQ¸5åð—“/>ßà‰õ¡SÒLrÞð
š‹a¶ÅŽ	jé9Z	ç„ûc휮qövpÕw2™šŽ_
+™]Á·ea~šåè-q#Øt˜Q’0ÚŒ¯ÞáŒ:
Q
+f¯¦Ùü#K#üñàFÄ×`Ä÷ˆÛ7`Ë$‚ñlj9Äé“ÂÖ$(?¹Nùe–à%¨"Kä­^Ë«£¸EŸÇ÷!Ý”âû¿B&ôJä“g]œlùÅÞܸ!&B‹Ê樅ùÞë~ŸÙoE?/猛åXxÃÕò“×Ð*®j­Ø¶eJK}› ÉqAµ­×¹Å$øÙ4F;&ÿ¢ÎÒ³ô3]C9Â>¬w=ÄŸÂËUåæHßÌÜn
t¿”è®þÝâÖn—ü³¦h	?„K¤AØñì¶,á: á®Còí'ðÿòƒùÿþŸ0³™ÀílM`Ö˜î0ÜÑöÇ?Ÿ0ÿ\¡endstream
 endobj
-995 0 obj <<
+1000 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 2
 /LastChar 151
-/Widths 1935 0 R
-/BaseFont /GNUWIN+NimbusSanL-Regu
-/FontDescriptor 993 0 R
+/Widths 1947 0 R
+/BaseFont /BLFZAM+NimbusSanL-Regu
+/FontDescriptor 998 0 R
 >> endobj
-993 0 obj <<
+998 0 obj <<
 /Ascent 712
 /CapHeight 712
 /Descent -213
-/FontName /GNUWIN+NimbusSanL-Regu
+/FontName /BLFZAM+NimbusSanL-Regu
 /ItalicAngle 0
 /StemV 85
 /XHeight 523
 /FontBBox [-174 -285 1001 953]
 /Flags 4
 /CharSet (/fi/quoteright/parenleft/parenright/comma/hyphen/period/zero/one/two/three/five/eight/nine/semicolon/A/B/C/D/F/I/L/N/O/P/R/S/T/U/Y/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/emdash)
-/FontFile 994 0 R
+/FontFile 999 0 R
 >> endobj
-1935 0 obj
+1947 0 obj
 [500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 222 333 333 0 0 278 333 278 0 556 556 556 556 0 556 0 0 556 556 0 278 0 0 0 0 0 667 667 722 722 0 611 0 0 278 0 0 556 0 722 778 667 0 722 667 611 722 0 0 0 667 0 0 0 0 0 0 222 556 556 500 556 556 278 556 556 222 222 500 222 833 556 556 556 556 333 500 278 556 500 722 500 500 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 1000 ]
 endobj
-969 0 obj <<
+974 0 obj <<
 /Length1 1624
 /Length2 8579
 /Length3 532
-/Length 9443      
-/Filter /FlateDecode
->>
-stream
-xÚíwePœë–.îîNCpwM‚»Üh ±†¦qw'H°à’àAîî48A“Cö¾gÎÔ¹ókæüºu»ª»¾w=k=KßõU3Òi¾á”²†X‚ä!Î0N^.1€:ØÉÒÝM
â¬Ê)
q´Ö°tžAFF(Cœe0@d
Yøø¼¢¢¢Œˆ‹7lk°èjë³²³süSòG`éýäÙÒ
lë`z~ð9B\œ@ΰgŠÿ±á³lÀŽ €Œ†¦¡’º€EA] rAŽM÷çT¬ª`+³ˆ`ÿ>¬ ÎÖà?©¹q=sI¹€7øÙäerùq\@P'°›Ûó3ì°…aÏ5€A`g+Gwë?<Ëm ä…´†8;z¬A6ÜêسKËÿ¬Ë\ÿ¾&ÿZüoið¿¥½ÿ»æþkþË%þßÞ祖wwtT:=ÀßKð¼e UÀŸ=ø³h\ÝAÿ—
Ð	ìèýßXý«¢>èïHÿý+¦>—CÊÙö¹%œ¼|\<‹Ánò`/µ&fe°:>Wë/¹®³5êv=wõ¯‚>ñðü¦c¶rpþS~Á¿!³õ¿Æþܨ¿"ç–—SRÔÖbÿïvë_ššÏ3Óñvþ}5ˆõþðHKC¼¾œB¼N>a€ˆ@D˜×ÿ¿ñø
ï?Ïj@ì0æáâáá<ÿþãûÏ“é¿ÐÈ9[A¬ÿÌÌÐÙúyÌþSð¶r‡BŸ»û×ÍNúç¿òYa,ÍC¬ÄÃì3²2aµ¤y£²Æ=ݼˆá.%
:Å…AÕ®ÀŒ¨MÑ
-‹ß5á\ãb­Þsß]v”Ùv»I™»Ò@§Tþ/X¿â¯1µ³ï†p›•`géÇùžÍªn 	ñèínji›}üB=ÞÎE;»e
záQDÄpã‚`•^ÿ–¸¯Ž ¶èûSÊÁí
sßÐ×þ®ä/;”ì¹oÑÅ=°™bƒ\s)%Œt+|£^Ë
àcš¤HÓ¯øbD{ˆÂÓ®hå_ãO•Ñ8V§%Ål¢¾Æ3Ö`éT¤¼‚cØÄÍùÉDF͸wvÎ%™îåH%ãc×ÊÎrYÓÀfhجس_Ë7åCüUœB>þ¾o¤²:ØÏ Ô÷¾î}'CL!Ôk‡»Pôë*/Ìò[!
­â‚Y?ËSR]¸½ní΄Ê~ŜŽ#DiþqõÒi!Oï
-ùÊaº5BOsö;5¤²nÛ®”‡1?ß×!¶Õ¼Fä›`¾EïÎf%¥üÍNJ]Ë`|
ü^VÒ#5“Ù>U¶,lT*$A6	/WÍo¿D)9A[ßÞE»¯oOäÁçeˆbAÔ²²O,m£a’ «>+^¾1AU«Ôsi¦l›sÚ(,ÜØV¹ZùF§­#â=Õþ§‚[Fª½Ph7ÆM&âCo#ù»¤ø²ù2y=õ)êilºGôÙO=?-íw¡ë#Ž'a²—¥¦
4#¶š™5-+3>S¯áŒÌͱæEÆÛÚ?W«EAì/6sRI~ߟ¯òÒË
-g©ùX½—ÿˆN|)ãÆs"•AàÂøžÉ&?®}߳ݚÀG¦ãkx%cqµˆ*Ê„þs#Ñ öàH_líÛòþЭDò.SÍò2µ¸‚¶cô~r×Ý&¼¶aËnàbAˆëàö‘·hàm|¢MæHvsºhkõ«Õ‚%ÍÍsu¢©¤¡Ÿ“=l¤´É¡¾4Ë_œœÅ¨””Ò8n“91Vh½#àÛµ-ÞTöw?Y¢Ô§¾LÑÜõÐop+–¹?µ­ªEzƒïê'&éµ'	´™öZ2VõzIÁ¿Ò$¼yíîRÿ}LÎáPŠ3”×/”})WCÄç^<"Ô¾±®ïÚáÆHýôbºY‘)ù O1€öúÊø½:†æ‡tУ+ÕÖ7v†îv™€ôü£FŠÛV+àŒ1ò^@+œÙ³AÉDèöû°‘Ìër;…Œm
¥S…(-ÎŽ¹¥…”›Ñ”*Ì”’îWx€ÖÇÀD‰}œ>sWw슱›ž¹¦§ª%X]{­Óõ(ýÜø¾duʃÊ(­¨ëFÑbÑd-];|Þ–B¯¯ªBH®ígs³d¸|Síqb÷{„3HÄ{lxýû¼Úþõ‡¸€1»ßÌÚœ&^^0*Ò7w:è¨}eëvjg˜MaY‚Ð%U7Ξ¸ˆ1]ñÔÒò<‡ÕÉ‹!¾Ô«L¬5m÷2fmû<ãí?S¦çŽƒŒ×‚ëWÕ‘QÛ—6‚ø‡ã!­Ã©bVBÑËwEçòn9væUŸì«B÷sÅ[º'®SöÚ@+¥ïn85ÒýŸHb–
-\F	P2ç´¢•ácƒÑ‹Ù‘…rò‹'ŽÔZOêÞ£ÐËT5ù„–ämýÂÆ¡\ƒO¬nÎhY¯ÊT£˜(3‚'Iáq&ÝàL‹x¸8'`‹r›—¸]kãï²—8x¯ô6»ŠÝw‹®A3‘3hÉÂä'O,˜G9¹5j v@Í¥×b*’ÅIœOb?¬ÐÔP
M%gxWªIVÈ!ñhÅÒø['¯¼¿.:°ÅλÒ6ù€@š<.œ»M=b¢³G<Éžb©ÎV逖4–Hº·ïK¤ŒS»7àâĺq›™ª””Óx`Ð@[{ù®Hš€@8ÅïÏSAø²ýäʲ½e#óòœ‡)P'dÖŒno¸”]`ú›Ð/ý»„ª6.˜²;NVßn81—hL°g/#³†õ½T5N•È&œ#kXÒ·Z‰[¦ZO¦íVñ¨ÖŒ[ŸÓƒá~‰ò¼/×èa¶î^"’]d³¨ˆU?c«<œ)´ NGWŸÓJª"Z!ÉÜžo½¥I´¼½g:>:ªk{ˆëçÈ	Žœ}ÊÌbÒ¡}Åó~@ó±F|íƒ-˜(2.°p{¶šIĨËq
þ"AßEðI ý¼Ë¢oÒE±ã‡¢÷§Ðú0r¿¡þâ°åÅKŒh—W‡ÃégäËC²},7Øzíå¶[D“ð§Ý÷3ð­beÖz«ë{çòCŒⲯÍ-kÛÓ~µ‘ñQÔ;¹F׌~Z¯r[Ÿ¾ÖcOSô•Üše
 O4CwT(„¨]§kfž—zëd̹:E.g3G5Õ_üIA…nµ>Ĉe! ªÐ½×~sýücê{?ê…s’.âÈÑ¢8é+û3FX©wvÝ*—n~	,!PÁzc³ÐMÕÁ—=®“@
®±&Ó/C¦ì>š#ö¥X÷Þ•ß|/"rÈÏÞJð‚WXhÕö13/¾¼v"sõ]8«{¢5¬•n/ÁîÄÌÖZñÛÕêÇDßõÓ'R
-­)ýHF	º6Y~Ûé»n{0òiSÖ^q _±ð¦ÀO¦îEþ‘”8¢±7_'š-CØ¢bùu]<ÉeA$o4¬ÒÌ)¦hÔ?úõt’†:öª^m™]IçoÅÙY?¿î(g‡$
ÀOÆs[ìKÍ÷\!xóI‘s/}©¥¸{•Äb’Ó½ä>‘b;’|†_};ËÈá—´nTÍûÚ£™HGÌ<¦à\0ÊdùR#À:[áo½fÝÈ·!)=æ×é×jk4íH_íD§KÂ_C77=r7ÍZÃ…tšŒ÷4wɉž\¢kf%³˜&§ÅÌù¯ž-}øå1(i-ïÿ(ªÈ÷3~;ÿTO𕚆!»´ìÁözš0»Á¯-ö¹c?Ë,þÅ0Õ‹×}ô‘[qÎ|HÚí‰Þn$/?µÅ¶Á^ôÃO¨:‡øg‹îXéÍt	ÞÕ§kÝM•.@)%H‰ê>±_œJ´ë}Ç$e¾!¬PH3èýP
-ƒPÒ€m\ûVO~LDiåÍå¿Làæñº[{Ú2ÛÊ«ÃÔM–7P)‘uJl¹!{øXq£‚ʵ3f+ò¢,˲“§eg·î+lê
šÂãEfqrqv±ç|ý{EMË5ƒ,IËrévÅä›ß‘¿öoXH°íxBâ‚Æð’ESyŠˆ»O‰Ú0r¨Ð¾/é¹Kš9+¶“Ò/J½[Snø¸›°F]Sç?…)Vž›r3WKn'ÂS¢Bp?o‰ËÅ„¶DkŸxͦ;é›!dœ\Ø)ª+þAáÓý¼+I§…Ÿ Â1/ÒØO±}¦Lhoañf¢yÉYnÙó7XîÙu®DBÈ_ÞI‰^nù¤úóÓÝ2«Áé
-hãÓ‡¦øªB“ÞÉ,
-M…ߎ9_³œü§Ó©7\y9LàbfLý”Bãôžå˦fð(iÚB5ö±¬r/Ö@¦•
-/ôÙ°úQw.#EœêhüYУ„%UÛ96‘iYÆ·ŒÌï\]”¬®)”ÏâõŽê£p¯ª, ¹ESIªfs èLü„Ü#€˜ð5õ|ºóXŠÜ´Ñ;1*ýó$]˜o4^|œÖarAG–´@îõ´\ph®«`­ëúÓPfÅ©¿ØHéÒ©1AGRkwpe,Ûö=B@íÑZKŸ}{ï¾þ­…k	­„õŽM£Ñžk—ai»Õƒ©9«ïX×’”PR!ª‚-‹¤*SèÉýu¾!µóûæ5´8ì²ôyÅ$,¨Ž‘	Fõó™êß¿ˆ±ÏD±›	á7èv,FÀÄwoXèÉ*O€‘\±‡®¡ÀÊê¹ëzÅM:í¯r$(YU,“(‡±~±jÍõ(çÖ
¨¸ï¸Íù;Çô<F‘¨˜Æ6Ž™æád;@u•iƒÕ%´·$«lÒ¦Íu§»/`S{)ªž|‚³%«ÌGw¢
-ãDáð£ìÆU¦1*]	ÓýQ„dl¯}ߨ¨7(cKqÞ9–ã¨[kwOŽÌ|ö$·¨íŸí«æ|sŠR¿
-ÞgÔ h¥%Ñî›!«RèPêé]å’qh”ö$Õk<©6–ìùŒ“=Ý°ãs8Ëqçsïï>®ê
še{Þ1#ìgŠ²8egç~¤’+J˜gÑ“¯©²j>-Z’µ×vi™4/CTÊ´Š]±‡|ë‰}¸=¼\Æè½,²è”®>×kýH&«Ÿg9‡*xëI79j»Wj}üÚ1`’ÖÝÿc#¢¸Îù!øV¬éwþgb~½|Ÿ£Œ?»X´•äßó—V™ttõ—œ²Òû¾”ÜÂ|ä]y¸ðð·ìŒY»”d:¡F	Íë$ëÇjNµ<`±ºé†gWa딣hU¾Âåï²ùfÌVr@±œBâAéÊúµÂ?,ѨÈ_­5±˜ÍÆq•Ðµ#Ú,HÉõuÜ¢y¤Ë›RÁ¶?âr6ÔŸ	­Œ7ª›§E¸lÛ6¿õô8¼¢ÈH‚yX&ÑÜÆåZ°·ñÓaÎ~ÂR
-)¯…=ղŻ†â	&И2Ù‘)„j‘^êK¡„4“°ÜD•.")M¸	îo[¨j´"¸ìcŸ8§q	cø?ž\Ø—:mÀw
-uHöó¾¤Ç|X(ÂÎiá—0åÁ¯ýîׇ%ɸìÚƒ]~2¦ˆ8­¢3¤PBþã^äK,l<0‰”¡ÄºwRÃÃRù‰Ú—ÉÂ	I³OFAãÃI•B„íŒ	Lõ¾
b­*ÒW{pͦa¦öùŸÙÞâdW-Ë'ŸÜH£û´Í`7$^¤©W‘8z.êЋü;*Ö&>0A̼I™µØú‘‚ø3àU$NõŽoíeá—·©E¥¥Ë°‹c¸3¦)fõwÖ.=£5f–MmB]7{¾ùP5/‚–Žè';n¬·ÍýòøŽ—D¤ë"‚ÙV+Œ)r‹U˜5ZV
%En‰y\kºsóL£¸;s2¹c:ÅeCÜñ—D³Ùyò뵊²:ä¹iKg(Ç3æxb6^<§a’
êÂ¥\9$Ä>Ša(Íâä£mˆ#ô}ˆµ˜±®uS%aéA²çÉF<ôÄt0côz¸
ô(é²Oè=wÈF£>yN¬F0‚®w9¹ê	Ñ!ŒüâUȲ­Áô7ø÷ó\â‡[äÝ,—PÞ\]Qé÷·¨ÈŽëªxŠ¢é‘t¾£ã‰£ò;:2öø²x‹{e@
-ø6Uu^˜ç|:¥ÔËíäð%X8ä—@ÖONÙ™¿°
-SÒ±H]^åí?ÒS”:j>ù^±$•MËÔ°Ö~¨ù®Ó›¨òëŠÖhé¸Zêî @­!5“Ößꦶüþyö{¶=êÇ{§	9¶$â[Ùo„5òѨÛç³-ïoGóù/.	ÈR+¿”Ûû²W}˜x÷aî¶bK‚+52gõK䯰’Oß󅤧d0ð¨3”âK9ìºXÃø¹Ê'=ñÜdÇY–µBø
Üc‰­’ÞRNªzcÐØ2•¼eཙüœ/ŒB+‚YK°>]3çÚàÔô‰é(±œÌ×üq]ÔÒ•h»¦éyù>¬oG{åM\4Ù™§©	ÌÔîå«îTäfo¢d¥SʆuÓµ‘´F”T/¤*ÜÄ"Úé‚&‘v”gHæÅBY+*z âÛ“kȺªñŒ¯W¾q ¶Nr1=æÁ{F³N·>©)‡kêøW}À{×.¬´;UBòœ•$‡3/ïtwG¤òt$qËoGćâ·éçë][
-‘mv¿`€÷˜¶”¬d檥—ˆT®•¨U~Ì:¼dLTФo*`›ð=Csì„	:Ó‚$G£C‹*zÒÛüªˆÇzY]R?Ž§iÊ­6&ldr¹á}Ö¢ç2D’©cŽ–RŽ½4õ1@@Üzå©jF
¿Ê%™RQݤóvš•7Vi4(Á¦¿ o-ÎË C
-ÈŒ./–ûš¡`¥ßV¬åÅù=uësôŠæò‚~ÃñQß‹?{Ù*.z{ö­`!ŒOÍžE¡â‹ù'™ÏmQ5%ä,fÝOýjïøÖî—_e^Š¬›GöŒ”"°‰»\ÃDnÂßCå^)›\íQ#l6 ²s™|lÄ=ý~Ðwÿ€Šú¡†Ê¹`Ê›V©káÇyùÛ[J•œû«9jn¨ûWN?°™âÓÕ#­µ§íGd©©,¾uÞ7ÑV"¸åµ–¸ËîÚ~ø>bNçØO!d¨ÂÜk¿ütÞ	$t~ÍI<bºÞíÛŸ——¤Y¹–vÍŒ·…t0nÔžAƒS-L]~ýö¨®ñvÀi¤çPc3lwV¦ªt1¤ˆ´>8¬0±n!²ï|Ä»c_/dǙ߰Nè5]·ªzŠ§9¨eS’ôêöjUÄ“b.doA&ò 1Þ˱[RßbG}ÎRâ²QÊõ6kŒlyhÆ*môãîOŠqÚWŽ°<˜;õ´ÞUH7$ÞO7#1Y‰jÜiÀOáA‰àûYT)®„ꯅÔ^ü„¶[m3#ªê!5÷?U˜'l(~1¾©Þ	·?lí)‘õ¨&Ýãùò[Mï@°ð»óH\Ç›xïÓ£¼äó¿ÚI—yÎ/vå)‹'±M?­šj)µ>Vå¢aȼ.íÜê9šº*ÇT÷QêƒcR	F³ur7Œ4}¡ò‘ÖTrAØagdQ;I˜ûÚçÊõ)¯„6/k™^æ™65‡OWØY•—¦Ç“'^ûzâ¾Ú´FOìª1ô)•ägÊ3IÙq<õû!›0¶ä¿ѧ*ª]Fù¥O²Ð®˜Ñ(î«-†'óÊ^UŒ\¤€¡gó­µehôf'MzÂÌ[»•ÃW¡Þ]õ±îÐùꢿ:åd³a
—Üý‹|š’6¡%kô¢@ÔÚÞŠ‰i,[J&im›Y¢¬ö03³Šþ§}õ+'Õ>-ï3ÁtÏM$©Eõ‹z¶K=ùkj¢š›ºùžÓ¦ÖÈà i]™"Á×m£ÇÓTH)ïÃ-!½¥g…ï°ùdYÎ2€«–Åù’åÕ ?Ká¯Ú—…V³ôö˜–‹|¸²…~1®/‘ܳ.bñÛ¾v"Ü!+7‡Y;´~±wÑýᢳ›î1,Œ)×RU°*{Ø	¦è‰ã /Á^>3˜3â8T¬c—}ÁcŠ[¸o×5bgó+WFø­E(šÍ…ÛåÚR»sIrèߌÀuWÎw%ËGÈÆ!~vΉs­-ÓNžs“o{Øs/„çÓzFƒgUdˆÁŸ,ºï¯–¸nµpØ÷iÍKŸ_0Ü2]BíèÑ77k÷I_™v{ƒêÅšæY|ÕA‰ÉmÄ„Ðkm =ʲV¯o¼³¢¯õ‰R)Å;DG–›-õ	)û&a²M¼ÊýIûlXžæü£=¾ƒ"Tt·wc¹)öçöO,lyb¡R8K´ÆÏþcRÅÓt&ò®?1#ã+:=°µÑ(|UH5ßÁßX¼X™ªŸ_¾,¹LÒ íÏJ	/°ñ¦°ðÉé2KJ맰‘0ªÎd蹇·` ý»6Vv¯|å âdzs‘@®ö\½®h‡êO´îÇ@²Ã$5Îëtys§\MsþO¦\CŸá§2íôè¢íeQ©úùy”†¶2Ú‚@ñˆÆrqªwYvi3¾q
ïÎ2\Y±÷ÚåkU+ÇÂPª¬çø£ýóêÈ
-ÒÆ°9QðÙsý‚v9êÎu12g‰j=I^Û¸å<¦¶±q;~?”,
-:Ö¯}‰÷v,}çx>¯‡j+’¼ ¨XRÔi q8;­‘½–„¿¬Ÿ6mF\©%šÆžéƒàÉÒi?6‡/9ÒiHö^Å’ÕÃ&y{&Ìe$66Úr‘oMí’ÉÉ*Ëû†±	õR¡ð•Á¯k7Î[ì…$"+•zSàCz¥ØöUP‹µ;«3ËP:1Ž.ÿÛ{‘q.ŸI´¬o^Ã{ßH¼÷ê£LMëV¢Z@eð»¾Ô•w^6'þƒ¼¾z9–9ºB|`žB_úÓ­_!_‘ëÖxæL²b‹¨Fíã®F46<Ç~­½:1haFgØu•
ü`¦¡i$úf©=wl†åQž ‰ÿÁµ5FXéFõüÐÝö¦”ysw]2_5.`kÕšQGB3ôpk­l·–_ÁKm°+Eâϲ¦þý<“¶†QwŸ}¾»L‚LT™Ñ§®ñ£[æmðy‰Í{Yñ‡Ç!ºÇ†Nî&…ÉÞ·Àí{_/&¦œÃ|eDòkæf§¯$/nœ­0³yü~öƒã4Œ3z¡RÈm)zí¯Â“‡è[XTÉ9ms¹Tº…äƒV-‘¸¯^qs—,HOï~öù{¹ÚLZ»¢Ý%…IhØ3Vß<9ïk¯Ã0÷›(;§˜¾ëXˆ`õQÔr[¬4ÎFRåS^Bãóx©Q÷(ò˜E)ò"|õãáÜk€áÍr¶S±|ürœeæ²èÒhÈ[m^
-ˆÒ—³AÕ÷Üì4*‡ËGFO„’P°Áñd‡œ¾×vu¼v£¬}  J6J(c8'Nj×mÕ‰kݸBgdî?PPÐuȈŒG/ýTø›!ž|¹$dKX]ò6ÃÑb~þÝäÄðå²W/]\î¢ã¸;cùb•zÿÔ9¿ßÊÍ^Ð`ö¶¨«QíÛ$ÂÐ2Òn«Ã­+³Çø/Bîr/–YÖmí‘×…¯ñ™I"Wâ}-è¨>¢×6n#°Öӧ˿ÏT‹YeFÚ@ìT‰¨Ç¶&TGŒN·p/SòÖŽgzaN»zµú8#Xáü=ö6Œ¬ªˆ§)xû#YÄ)´9pÍd™"üF‚š¯€ÉŽ÷Ó±ü—j" F!m:™­•0./1S¿Àþ4×<¼ý@(°tÈ£^ž>
+stream
+xÚíwePœë–.îîNCpwOpw‚o Fº¡iÜÝ	,¸$¸C‚ÜÝ!h€@p’Cö¾gÎÔ¹ókæüºu»ª»¾w=k=KßõU33è¼ä–µ…Zƒ” 87?Ÿ@ìbíá®	…hpËAmµ­Á€'@‹™YÂÁPˆ’l
+ €€€_\\‹ uõíà6=#vNN®Jþ¨¬}þ® Àÿqc¤	µýÏÃ99¨7À[„À- *∉òü7ÿ¢áÿçY‡½¦|<||ü€§ß|ÿy2ÿEˆ
ÔöÏ̼„!¶OcöŸ‚?°öÔÝ¿nþSÒÿ8ÿ5ð 7Èkij#¯#ÏU0íéæGˆp-mÔ/)
+®veFoŠWZý®ài—xhõ™ûæz¿£Æ±;ØMæÌÚ•ú^HðŒýsáK»(çn(¯E)nÖ‘Q¼ßé¬ÆŠ‰ŸáîÖ¨®žÅûßh´ãí‚0ŒÓöàgžEÁ$L×®x6
¯I;šˆêŠ¿±¤Ü\³ö
}èïúúy‡š3ï5&³¤'
+.K\°[µ´‰A¥_ÓÅ¡Bl³TÙqÆ?ÜÀOqDú!Ý‚+©r:çšôäØMbôfÃÚlƒ*Ô—L›@“à9ù¨è#àÃÎΙËŠ"¹LBÜZcùi{P:Ø—W¨#pöó«ŠM¥Ðu—ÐwÄ¿ïšè€œANŽ3H
½/zßÈ“R‰ô:à/ÿÆù#·þZDG¯²`Ñ!Èö˜\aÌè_wÁ8Cݯ’ûC%×ð‡	²œà½¤VÙûôû‰Ð Ç7ÆEpƒZ‘ÀÇ9ÇZr*÷m7êÃûØŸoë‘Ûj_#Ì°_cvç°“Sÿæ$§­c2½~+/í‘ÉjŸ*_5.‘fĘDT¬t\¢–¤ohï¢ÅÛ7²N ñð~EjEÒ²²O*g§i–¨ 5«Q±1AS§Úsn¡fŸû½IT´©­j5¬ê¥~%FGä[šýD7Ìt4Ɔa°n¬k»,äûÞ&Ê7É	åóåJ† Ûïèßã2	W8?(s2o¤±×ɪmY™±òzhbi‰3/6ÞÖþ©FÓ$êøc37ì÷Ý)é*?£‚h¶¦¯mð[¥÷x¤WQòî|‡¡²™D®ÌoYìR	ãÛ÷½Úm‰|å;¾D”ÃÐ2W‹i¢Í?5‘ê
ŽôÅÕ½®èÛJ¢ì2ש(׌/l;Æ\¤tÛm&h&²>à.†º
ÞâùˆÝ$$ÙeäT²fˆ·Ö<_-\ÒÙ<Ó"™J.ù9ÙÃANŸæG·üÙ"A‹ä< ªšÎu“Â
ÁZ¡÷‰Dl׳zYÕßýhÖ&•ª³ëiÔè^"÷ݾv¨å%¡›¿„ŒΞÐnÚ{uÊTÃ[ŠJp¥Ytó04ÆõáÛ…¢Ó¡d¨pÏó‚„”àåŸB¿Þ€wF'˜N¬õD¿ÍY–åQdÿ)í%ig²qFlªjæ'eÑ<¼²ò+êŒBÅ=ø6YææVw´SôŸ/’Åçm3¨94¦µƒ‰Œ?6(¯öçÙod!¬4‡¿‘1WÃaUcÿÎÛMÃœ,Ù§	n¬åÝk[nø½SG¿.\èxʉ£3ÜäGkh+Q×#KVI`÷»p0-¢Så´’rX=ÁBÝàËB¥Ô¡ïöå
+8G…cDùcì‹¡ŸˆpÏw¬W°{÷¾qSv9Íš©@ýª…?ÏTé‰8aUÞX"ß ­Ù1IG N?öÉ; a½Þ6Ä“¬Í2þ*>Q'Ñ
+ùjêÆ×'ùæ¡y©Ãm¢•N{µÀÕ’¯+ÙÄꦛõóK¼âIR'¹èºGcSCê™ïßzÚÓ>Ñ€Ò;,búñÖú)®Ö‡ÒŸG Œ-Ò<ÌõOE,ÇH£òfd&¨³	:Šó¿0s[jöµMáÄk‘É ‡+ûv­el3¼)IZýU+Nšßø^’©‚´a¡üs…&2¡$ïâ±ÞµmC×/VÚ‡gÓUXRúTé¯.Mßjaé¼ËÐ;ºÔh}éP`ên—Ì(8j"¢ºiµΘâ î%Òàt#—½UÍDn¾
›È¿¨pPÎÜÖVý®­ëÉÝ1·´z(žZZÚýœÐúï¿ÏŸ`ØÉÈ\ÆS“ÄÊÄ9áæìðòðKîTÿ˜Šð.ŒnÔ1Û@žòÎìê­Á˜™?óPbJFªlY„¿•€œ‹±Ó;¸8©¯Ë'ÞšŽ]	NóS·Œ4ÍD›+՟¿Àçì.ù0yÕ-ƒhzºì“+§OÛ²˜
õ"ÕH)u}’1k¦ó—5ž'¿G¸ƒÅ|Ɔ0¿Íûóaì_½‹s¸øh)Ôæ2i"õƒY…±ÑØ´ÓI_óèG·K;Ól*Û”!¹¦iöÄUü0	Û@K(=ßkX‹²JåG»ÊÂ^{Ðv'oѶÏ7Þþ3uzî¸(Øt-¤AeU½}iÃ8X0i8Ú:œ&a#’³|[|V©äžë`Yý¡Ñ±¦0l?O²Å©{â*u¯
´Röæš[;#à‘,vù ÐÍi”-kN7F
1.³„U$· XxRÒ[³õ¤áxá-£|uã‘oøaiþÖ/\<ê5Ĥš™-ëÕ9šTå–ˆd©|ò
îôÈûgDÑ.óÒ7kÍb‚]ŽÒoU_çTsúm14ê$q/YyšõäK„ð©¥t¢GÔ
hBØz­¦¢Ø\”ÁdŽÃʽ@í@°4JV¡7e:E\Ò6|¡M¿õó+úëc‚Z|ªìSˆä¨Àã¢yÛ´#fú{¤“œ©ÖZUNɃáIä{û~$jxu{á®.ì7YiF(ɹMVHôuço*€ä‰HÄS‚|•¤AR}Œ˜ÐKëö–M¬¬ó3>– ýÐY†½á2N¡é¯"¿Œn«ÛxàjxÙ}»¤L<a±!^½Ì¬Ú²`ô·²5x]4b›ÎTìá‰tª_ë¤oXê¼X¶3Ù%£[3ïí}¿÷KWä¾Â·÷ð“题EG®þW}à	¡ÒK„¹]~ÊX(­aŠl…þHáõzí#G¦ëSä33ÐñÞYKÏSÒ(WQxäôÝPV6‹>ýs¾·:µ’kïìÁ$ùÔñƒEÛ³5,b&]΃ˆ?\……2κ¬ú&]U:.T|>„5„[Q²ùõ”„//žcŸ>?Î8¥\†Rì㸿ŠmÀÒ[n»A6‹ÈtÙ};ƒØ*Qn‹”i¸º¾w¦4Ä,-©ðÂÒº6©=ýW…•qƒ‹Ç'L˜Çõj÷õé+CÎt?™­Yö@Æ$Lgå"¨æU†NöááY™~ÎûÜË猪èæF‹?©h0mÖ‡˜q¬„Ä•»—Ú¯¯y—/¦¾ ÿ€$ -J’?wÇÁ¨qŒyöù……»¸ßÂiý#ý«:¹öRÜNìC‘ÿ]= QÂ@âi?cU‘ÈšêÑE
+Zð•ÙòëŽ(¿uûƒ‘›
+Ž**E×…þòõÏ
+>‹¥Æ“Œ½ü2ñ1É:”#:N@ØÀÕë—b6TæZçÈ&Ý’jŠNë½O'y˜s¯Æå–Å¥\Áf¡èñP¼ƒ
øÓ‹Ž
+NhŠÉâ´p¯Õ¾ì|Ïy1ꈀ,%ïÒç:ª«±—ÑÁÜ¡f¹ÝK©ö#)§„•17³Ì\þÉë&…°ü/=:ItÀ¬c*î“,¶ÏµBìóø•¶k¶M2rcþÐ~ݶ&óŽŒÕNLF‰dÂ5LKó#óì5|h§ÙxOÓp—¢øÉ9¦¶PQv
+›yJzìÌQÀêéÒû_>™ƒ2¶Jâ*?¶¾
+?×Ô~Å)§p°½ž.Êiük‹óDñØß:[p1\#ÓêEãDÔV<DE¯=ÉÇLêC[\üY?â„$4 G‚¤hÇÆp¦Køš¢¾$C÷vªlF-MNRÿóÇwévÃoØä¬×Ä•šéÆý/îËàPj:°ý½[ßêÉÅÄ@´nþ\T"/Ÿ÷íÚØã–ÅV~=¶AŠR‚±z©RÂèKRË5ÑØýûÊkutž™p{‰ÐgåÙÖÜ|-;»õ_àS/1”~d•¤ôç’æ”xÍ7¼õ,UѳžR×4Ζ±®—kWI¹þõkÿšýˆ×/4>xŒ ¥I¬)¯˜äU÷w’6¬\Œo†2•vrÆEÙ7kjïw×hkc린%*óR¯çê(ÄñJÕ‰îæí¡ñyØ°–½ïÞ³i¤.†ÇæÅH™'?T´T.äÑ>m§ÇÉ0èb &ªsÍ‹5õSmŸªÑ&9Z½‚ú°ÐIqWX÷¼ÆOV¸Bw!U(HË;I#‘ÃË-4~>g¹]fw0þ¾Úøð®9¡ºÈ¬wr#›JGù·sî—l—€éÚ
7~.3„ØYK?µÈø£WŲ¹"ZºžH­c»â³5y•ò3#œ~ô]—ó(1—zº6ÌhQv®MTz¶ñ-Ë[7WU›+*µÓã†hüËj«…h^1ÑT²†Å(&‹01ï !z`K{€˜y/TWœ6y#ActöŽ¬û¥ö³÷ÓúœÁ®˜¨2V¨½^ÖNë+Ùg+ÁFÂtÔÙñZÏ6R»†ôkÍ0Q4Ûܘ˷‡ýŽÐ{t×2f_ßyìÅD|maÂY‚ª $½£CÓôgzå8zî
`Z®ˆš[öµdU´4¨F§0RË"¹úf
+ÖF½_hÝü¾e-=§c~	:‘sT¢IƒÐ|–Ö·oÂÄœ3Ñœ"x!‹‘pÉÝk6FŠª`OÜ¡[°ªfîªAe“ŒAï‹"Zv5ÛÂ$ÚaœœæÇ´3ÛFtü7¼–‚c†ž£Â(4,c›÷Ç,ó
+ úªôÁšRú²Uc9óõßwŸÀB掾²4=D§Kú6Y\$•¦I¢&9M«,c4Òæû£H)¸Þû~ÑÑ/ÑÆ–â}r­=ÇÑ·ÖnYÉn&ÐÛ?9Ö8Íùå§}"¿Ë¬EÒMO,¦ß·@Õ|E¥Omhx™RDÁ¥]Ös˜Ü g|_¬ÑTºç{0NñxÍIÂQä-àÝß}X5´Èñºe)AÚÏgsÉÉÉ{/L£Xœ8Ïf¨T[7eóñ,®xiHÁQÏI¾eÒ²Y5Ë&tÉúµ'ôî~/µŒÕ{^lÐ/+Z½nнH¡h˜g;‡)ûÊ5;ëyTé¾üÒ1`–ÞÝ1€YR9C
+¹‘hþ]ð‰”OаÀóç(óÏ.6=5¥·‚eÕfÝÆ]ý…ß9_1úIÉla?p®Üÿðô·îŒ];—a9¡EËï¤èÇù˜f}ÀfsÝÈ©ÎÑ©HÕªv‰/Ø/b÷Õ”£ô*‘j9•ć֕ýkEp&Dž+IE°"Æ(ff5›ƒç&mà@²Y˜šçç¼E÷À?¥ŽëxÄy¥>&3Û˜nÔ|œã±nÛý64äòŽ¦ ác›ÄHtWlÁÝ&Ì€CüEe•S_ˆzi&æHvß%;M`°dq¢R‰Ô¡<Ô?–Em&'⸋ÿ*[DQpÞ߶ÒÐnErÝ?Æ=¤ó˜~cÜüp,sÙ@ìééç—bľ_(ÆÍm”6ç#¬ûæß‹€#üìÖƒ[q2¦‚<­®?¤\Jyq'ö9>ÄBÎTjÛ;©íimˆúHëÇbå‚¢Ó'¯¬ýî’¬ZD9Ò~Æ®qWŠA8±Vå§78ˆa×8S÷ôÏloq²«Žíƒ¾ï=þ;iO”Ñ}ú`w~”©ç‘Qx†®Z°·4ìÍÊ`¢Øyy²r[‰õ#eyð'Àó(¼š¿ºó¢Ï¯ÓŠËÊ–áµVÇ',S¬Zol]{Fk-¬›ÛDº®÷ü
+`šÞD-1¼8¯?ö+:Ÿ“¯‹	çج0§*.Vc×NèÙ4–f2»'yæó¬ÌͳŒâïÌÉ¿çí”T
+õ&œ“ÌJçhçSE*­×©(péSæ¥/¢wÌXaIØyó}—iÔú!ZÆ“KF:à«ŽöQrƒr´
y„‘ª¹;nÁ­~ª4<#Xá,Å„‘”nŠ¹Ãˆ°-Wþ³çÕdTÈ7ß…ÝNÔõ&7O+1&”YP[²U¡5„ñšðnžGòp‹²›íÆŸg .÷öÕy]ƒ@E<#ŠÁot\;iT	iG¿SžÉ‘P`ña¯ü`H…ئ¡Å÷äžïÑ¢–Ýc»™>‹†þʾøà’“õ§(
 ‡ÒÔå]Ñ~‘‘ªÚQûÁï’-¹|Z¾–½îËDí7ýÞ$õ_—ô&KÇ5²·šiYô6×u§ˆW¨³ßrÑßß¹L(r$“þ°³WøJ\«ƒ¾}6ËÔòö7ðfpô·@À2àœˆ"­ês…£iåл‰7_™æn*·¤yÒ¢ðV?Gý
+/ýð­@DnJ‹€6S5¡ŒË¡‹=\0ˆ§œxÒ‹À]aœmY7TÐØã0ŽÔ&ù
(õ¤&©7ƒcÑ)KÕGqÐ{ÅòÃ$¬2„½çÃkž^mŸ„¾*ÛÉ|=`(ß-P3CUÙ‰¾kš‘_àÝúvŒwþÄfËtM¡™º½Ê܃ÜM´ìj%âðn†VR Šîˆª†©ðÙJw‰Èv†àI”µ™{ò¢9T‰0öÊʘävÇ䪓F󋕯\È­“<,€yðžÉÂì„ËoZêášáeðέû²¹'ýVƒ˜2÷]ÙáŒÔ]“‹òîˆl¾¾~Åâ͈äPÂ6ã|ƒ[KªÝîg,ðË–ªü\,ò‰úU*­úŬ“s’²cs!Çt ß)†s'¢èTšƒ	+®ìÉhó¯&5ëewM{?ž®£¸Ú”¸‘ÅãNðI‡>çŠ|=kŒ¬Zܹ¹¯1ò^ðs/
ZÄU™ÔÊšfý×ÓìŒøqª£Á‰¯ðáF„F¶’üLúDi€ˆ¬SÍ@Põà8™zŒäô6žéP4Á¥d¦]æP€úŠÎ´`ZH¹O\Ÿ4ÙqÌ%ÞLòÀÅ4}{Åd	:Rå«Úš!Òè.½Xf†‹"B§c¼2Œ†‡ÈÂîå+F£î	ç`“fbŒ§é¿GJ Â+ÙYeá–[PyÖ´O༱B­˜[ù´ZJ¨¾´®ÛØ0tÀ Gkd™eÆìɾ>5mý»Öñ(S¿fÆV·Rˆ;ÛN>NšßXG$Ês2.ýág’7Mš¶íεD·q¢/‹«‘Ý­UVÅÃö'ßô­hùŽÔ”d"pµMä8´¹ða]G“d°ú÷C.GaÌ3ÃŒþB¶ø:d‡±?ŸGtù¹PkªˆÇ¼¨ŠaF)ƒéà›Àógs±/Àý´¼‡
+ØÆïk©1Äïi0]ëQy,ö*`uy³ÝÕ
„¨þ¶a¯()è©_šcT±R>ðNˆþVòÉÓÄ^eÑÇ«Ï4xi|jö¤8jP" Ùræ~‚ä¨×hSÜ«Âu3«Ë·s}·µ¹|MÌÐK ïÛô3Äk@0ýNnŒÍ'€ >ŸOR}»>©P_ºÅÑØîôæØï+àq&|¹\K¯3¬¼§Y0,͉÷B@>9ýX¶°üÍ/0Å,…`ÐHÓ´í[ÿçpûÖuäñSܼ˜=»„›Ä+Ñ.º1L’ú¾POBÉ=.jÊ.Ì«“¼òÅ ×ü›:.Yí¯ñrøàxË$®™»îˆ]~ÍB½¾ˆW¥14
@žhOÎU)Y¶Æännƒ©À-~’×±ª1Þî}&H¶ïÊ×$A&ηëoâÑFÊ(¢ùèsÁ¦’µŽC¿À‚×5²OÙÊf5‰yvÞhþ%ÊâŽîžáí¾(3·õ5¬íuÏoÅb‰Nc©÷ä†Å^}.¯\Š¦ór£Å†|vRâuV¢¢õ¨ï´90
¥§>¨’ÞvEÊ.#Í2.P™ò ÏmÅí…@†"3?û¾î¶GבV´šõøî_w+¾t·ü<ë\løqdÏD5—´Ë-¹Qì:â-4Hñ¹šÙå-Òf#:'Ùû&üïßúîîÑÑßÕÒ@Šˆ¦µbïGí‘-O8Õ~üýI‰`nǪŽ‘{óc—žvâÛJ¹Æ¤»é(,6âÚ·ÁÚˆÓC0Ä>T6
ªÀKÑ@Ո泟°J›mVTb
C$Šý•–‰ÛïJžoju"ìÛzIgß'é†ËõxI}M¤ë}³q…ï|àóý(?ålÀ¿nR[*"¸«D]2Ñ„kþaÕ\Wµåð¡’"Gåwíè¥â×ÌÑÕÐ8§yŒÒ>“M4™­W¼f¦ëSŠ²¤QÆÅ
+?¥ˆÞIÆÞ×;S£ÚhH}~ ²y^Ç"•oÞü1bºÒÁ¦¢,#2éÊÏÿù¦-fRWí«±âQA–|³Ôáïþ
+‰cK‘}âzåÔŸûdŠJ˜Mâ¿Øcy±®ìU·Á)ÅÚ‰˜z±_K0ÑZ‡ÅŒ`wÒe42 ͼvX9ÌtéÝÕ뛯)Qö¯WK±Öv
ÁßÿQ@WÚ&²d‹Y„^×[¹ =ãyCmÅ&¯k±HRÐfeU7ú°¯ué¢Ñ§ës*œáµ‰"»¨õ£ãÜdù‚–¤öº~¾§öUèIskÔa°œ‘|±ð§Ž¶ÑãéN”Ô·ÖÐÞ²ÊS§¢7HƸ
+l§™ÀUë’‚™Š¿µè—	½ó"›YFGÏlëE|…"ÿX7)Aäìq„m_:QGnQ•›MÃ캿8»˜MA19Íw¦XV¦Ôkiê8U=œDSŒ¤ñ0)°·ïöL $ÍûÓy_ȘÊþëuí¸Ù‚ª•[1êûfbKÑv¥ŸöÔ¦<2\†!· pý%ä¶tùÕ4ÔŸË’4×zß2íâ57ùº‡ƒ9ï‡èÜCzÏhȬº<É+ð«î»Ë%ž]<Î}z˲§¯q¡|W—H;fÌõõ’ö]ò–ÝÞàÉÂæy6?-PRJ)ñlÅV舶¬Ûkì—‘Gö³=Q-ã zƒìLÜr½¥¿>!ëØ,J±)OPµ?é˜Ï$Йp$t²S‰ïVâo,7ÇýÜþ‰ƒ«D*R¦oÑô)`L¶dšÁLÉí'2vTRBe§'®•Ÿ:¹ÎñK«g+S
ó«€"©ÒódmúþìÔˆŠ·/‹Š]γeuŠšˆ¢ëO†Xz:ð
+1¾icçô.P&Ma´âiÏ3ìŠqJ¤ý@ïq¤8LÖä¾Êðœ·ÄrÉÓ±ü`Î3ô	y*Ë1\—!ÆQ¦_Iuh+ë¾-”Pˆlª¯q›í>ãßøvá4Ó'h¯]©NX£j,­ÚvN0& ¿ž¢0}üÀ—[3Ï?x×”«þÌ+kÖ™¤Î‹ì…{îCZ¯ó·ˆCÙÁâàc£:)‚×ca˜;Ç«ˆ	=4[Q”…ÅÀÒâNcíÃÙi휵ü`¤„­„ôiÒ*]ñtÎ,_$/¶nlDZ9B™‘ÎWoÕ­Ù=íR¶gÂýÑF’àá£-?
+li]³¸Ùø_27£Ÿ+×¾0ùwâì¦!øH<3„Ff'¡Ón
+½Ë¨’ؾn±õ`WÆaeÊ Åó•ÇÁ<"bãx+6Îã;‰‘ýÕ{xï+™Ï^C´¹y=ÓJt¨q—ɶêÖÛîþ$`ð÷×@@/×2WW’/ÜK$ðs†-àôjý¢òßœYŽr,s1ͨcüåˆö†×دµç'Æ-¬˜L»n
+Aï,´u€$_­õ掭Á!ˆ |jÒOt	<[cÄUî4O/ƒm?Qjù—·W¥óÕãBö6Ma‰™õdtC÷7¶jVñk•ü´Æ»²dlkZ_é0ϲèk™
ö9ç»ÛÁd¨$U™}Zºñ‘¸ò¯CÎJíÞ*HÞ?äŠ0<4vò6+?Kñ¹nß	ùy³°ä¶¼*PCæzu¡°ÆUhiñ½ã¹4ñë{ˆ
vŸàÏ~p¼¶i–r/Lµ-Õ°ýyDÊc›%·}z·ˆRðª5
+ïås^ÞÒ¹éÝO¾ŸàR«ÉëVôºd±‰_uà5|œœ÷sÔgšûM’“[ÂØu,B´‡þ n½-Qo'£þ!” ±y„u¼Ì¤{u̪õV±æ‘ùpîàÕÝrŽK‰RÂr¼uÖ²øÒhèk=~*¨Ê7ĸú[^N:Ó€õ³RiØøx²CDÑÈ{»&A¯IÁ1HX=-Œ¹™A’/­ë¦úD–½~\¹3*ï^(¬è:äç@%`”{,	úÍ”@	>_±'®)}élµ8ÿfrbø|Ù»—!>oÑy܃¹b1šF«êbÎÿ·ÚGoXg[t‹ÍŠ¸™ÞM²ñ	he·Õi‚Þ“Õsü—1o$¥·Û,û¶ÞÈ‹¢…Ì„¬dQ+÷	~VB4ï1ë>~j#²5Ôg(¸ËÔŒ]eEÙ@îTlÀµ%ÖBŽÉ°ò,•WõÑ‹–dyfI·z¹ú0#\	ùwNQ]Ìײýž"ò;ìcКÙ2Uĵ4-	,A›“à§sÅ/$@¬rút
+G+q|~R–Q¡â÷<ˈö‘ ²!Ï%ÊȉëÙ}»CÈ©}ŸzT szÈ‹$:î>iÄ+Z¶>–sk÷±N<Ö)SÅ“¸¶Å¾­]œUf‘i×8¼’“¸ž9qÝ[¡bƈf¼¯Åرٲ­üM˜W:o³&>`M÷·^Ä··Ÿ£luÆØG,V®«Õ«ô“r0}¦mR"ݱöÑÐëhÝö…²ŸsÛK.Ó¯3ÄÛ»[ŤÊØ‹¾'„Òì‹ã|1Äu äû_~°þ?Áÿ6Î  uÂœ°þ_–*4endstream
 endobj
-970 0 obj <<
+975 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 35
 /LastChar 122
-/Widths 1936 0 R
-/BaseFont /FEIHRQ+NimbusMonL-BoldObli
-/FontDescriptor 968 0 R
+/Widths 1948 0 R
+/BaseFont /VUTDPO+NimbusMonL-BoldObli
+/FontDescriptor 973 0 R
 >> endobj
-968 0 obj <<
+973 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /FEIHRQ+NimbusMonL-BoldObli
+/FontName /VUTDPO+NimbusMonL-BoldObli
 /ItalicAngle -12
 /StemV 103
 /XHeight 439
 /FontBBox [-61 -278 840 871]
 /Flags 4
 /CharSet (/numbersign/hyphen/period/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/r/s/t/u/v/w/x/y/z)
-/FontFile 969 0 R
+/FontFile 974 0 R
 >> endobj
-1936 0 obj
+1948 0 obj
 [600 0 0 0 0 0 0 0 0 0 600 600 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 ]
 endobj
-961 0 obj <<
+966 0 obj <<
 /Length1 1630
 /Length2 10420
 /Length3 532
-/Length 11287     
-/Filter /FlateDecode
->>
-stream
-xÚíteTœí’-îîNÜ%¸{‚»k
4ÒXãîîÜ Áƒ÷Á	,œ Á!—|ßœ9³Î_3ç×]·×z{½Oíª]UÏ®·èiԵإ¬œ,@òN(;7—0@ìháî¦âQf×Ù¸«Y8€/=½Œ+;AdP0@dYxxÜBBBhô'goW°-À¤£©ÇÌÊÊöOË€…÷?—H7°
ÀðòârprvA /ÿã@-µ¬Á €Œšº‚êÓUÀä
-t¨»¿´b	P[‚ n f€µ“+ÀáïÀÒ	bþӚǗ”psY‚_Â@^– ç?Àäêvs{y€Ý6®@ôå N0ÄÒÁÝêO/vk§¿
-rvuzñp|Á^ÈÔÜ n–®`g(à%«º¬üßuBmÐ?¹ÝÀ/0ÀÉúÅÓÊÉÒýOKa/4/(†¸  /èŸ\ €ØÍÙèý’û…ÌÙüWîn`ˆÍ?+`¸‚l€®V 7·šî?·óÏ>ÿ¥{ ³³ƒ÷_ÑNyýg
`¨ÈÁš›ç%§%ô%·
‚ÆùgX ÖNn®¿íVîÎÿÀ<@®]ÓŸ™a~)håqðX¬Ñ8U /)Lÿ3•9þ}"ÿ$þ·üo‘÷'î¿jô_>âÿí÷ü¯Ôòîª@Ç—ø{É^¶Œ@ðgÏ8]v‹;èÿ
-:‚¼ÿ›ÀuÔý]ìðý+¬¾\ŠÄæEvn®¿Í`7y°ÈJµ´X^îì/»Ä
-äꆀ^´ýëZ_‚¸¸þÓ¶[ÚCþˆÀ÷7‚Xýkù/rýU<§®¼¦4ë·aÿòT™¨¶·3ðiôTœ¬þóð‡GZÚÉàËÎÏ
`çy-àrsûÿ7ÿ¢áþçYu{Œ¸8¸¸¸/ÿÿxþy2ù9ˆ¥“ÕŸÉÑ‚!V/ÃöŸ†?°¥»«ë‹Æ}ÿ/Mÿãü×؃@^ K´¯‹N–"av™9YÐâ‚áϲFý½ÜðÃáÎMÚ¥ÅAuN=™Q›B5æõáÍSÂϽŸ¾+²ìŽö90öd€N‹(üi™ûŠq×:XwC8M+0³Žôâ|Ïæ•7ù¹tw·>khš–?"QNu¾vE9»a¢õ(" »vÆ
-°|טHØ…Óƒ×PrxĺsÍ8862<ÔsŽØ÷œ5?•^Ä“!6È%Ÿ\ÂP§Æ7šuîÃ.uB_J?ÏúTþ.=Œh28s¾ºPÃQGû‚? +ß/WI¾<½[óJ¹é¯<;ÂΩ˘zŸÁmúB_
-;‚Ÿ­û¬’»SU*rUO(|ðþï~«m¯ÿÊkûõ”ódS
ê܉5I&Ù‘­J
z &WÒpŸøºÇÿÈ+cr¾Mo»À8„<¶o˜:b;ö!ÖöãUÿá UìœÓÞ7=ïQ”|ôh‡ŠxÓaŸœS…~v¢Ñ>ɼ{,O뢹Ž‡D¯ÈõM·*_Ö}¢õ$&ˆ\¤h…*Úe[gÈ}üæ#K'ÙY•§Ì¾©l•+‚â‹ãºI›"¨8®¢iñH]® .â³IgË$ ÌÞìè¨Á±•Ìˆ×3F$èóþ±:ˆžGÚ¹,nÖû¹4‹Šx9€Š?Í‚ÉH}½áwskŒ$Ê=ü1ïfòw…¸…3
-#®Ð‚K½!ß…—-ÿ—Z³.•ˆzdÉ~ÖÓ0&·fžïMQ_ò‘½{JM¹]ÁÚ7bþ~”Á.«sB4g
-Ë“›V2báJÄíŽÃá4k£„kܽx:exÆ墖¤ß>$æ¥×¾ÿž³gѲC‘6)õ|{ýn÷ô~ú®áë”$%žEw­¿‚áLxÒÊ<¿¨7åAð£?Œy¶\«Ì´³qwß}¼}¼Ziév63;íªÔWc~ûô Dqz˜´ˆÏrÔ´N²¥Šêsßa)QØ
-Æ=Ûw…gúѺà6"€«ØXiø-ðgE:
-A["Ïb—#='%}BY4óK`5·GßmD.•ÿarI/iT,Þ,[Z©}k“^M"‡'*øÆðúåŠQòП_ÕWf/O¨úO^;zåô5¡qž.,Ù)úm—#É;=ØÜKIé·…s¯Æ‚w7ÍÙ€IÍ­ÂÊ÷;ØÅ~žÒ³×Ÿ}b¿P`žÚUÅÑ	Ú,?œP<%F}v«ik>6Í’D¬Ÿ‰ÿåÄݨéì§CœˆÁy֓Ŭî’kŽÇbÌ=s´½w-+çùÚâ:7{\h#¦Ú`¬ç¿4©‰Ñµê^ÿ±×ï½Xøw¾l~ÉwÃüË|[DxÚóªZ7¥ÇÍO©ì©zí¨ŸjVVcÈ-XÐõ‘Ê•ÓõL…X5=€švÔ9qZA]·àÇùR„!¯ç'ø›“dYªõöÑà‰¶[$uÅz³-.*óÃ2”XmÍÙSÎ~" lœÂƃXfÎ%C킲!¤æ³åQv_EŒar¬é'µòSÙ®.ÜÁ±üZqž2óã¹»qÍÝò±aT‡Ëï[3íížBÙ1Õì*{<£Í´q.‹êŒÉ`jÛP’õR°¦Çk‰UK+úÓ@pWjaÝVçoC×õ:„÷-dr¬M³
-…š)ZP~§‘²GÆw¶:è6‹%ïHkxš*òšç$z¥‚²'Ku†Yê7꣇®ÁÂY€kìÁ˜¬®·V'£9Àt#úGB-6ûÉ7š‡FÈbfd½ß´‘Ϩ[¹ØUóàçÃ{k8
§¼9ùò>dDî"^W/艞hq«¼ŽD$j³Ȱ#²§Ýâ_‡£u¼á$=Wx„i\/O/b“íªíPœõ.§K©¯Š³Öføëßrr¼­Ö•1TzÔKR^-ïäláW§ïnk*ô9sÂÕcùwû½{—ŒÂ¬¹¿ùÐùæHCÌ@[é’¬u†²*ºhÔëŒÍIήŽ‘H‚B¬è1agójwÿÚNãçP…!3o¥t¶»H;H¸Ù¬–AvX-Y¸˜2š<npêÐvòöÚ/•'
kì{kþô‡^¨”ÆÖÜ‚zÏ`.ú]´ãSæ;^ÆØöØÉÌض(ÃÕô÷öQx¢`*E¼+‚Í+GzÑ)QØÜlÉpkeeŒOW¤þ3冀dù?{µŸNüìëc2Âlå2­ÑÈœ˜?%’3>ä8…¿¨ê4€—4ÿ¸›4•PÞÌ÷£ë'G5ò¸rŸ’=1³ë-G(z(·Æ;ñªîý‡DÍÅæ:_ûP»Q›m¾eªr]-ibŸs	u°Ñt¿yÚsˆ$é‘©–ÅòeÄÉ­[ɽ/ðì86ã/¢óÁ³ÈŒ#1Ï‹ty•j@Ög¡@[çØž¥2¿Š)DZF‹²i6{Ãœ+¥PV§ªÆ7ÁËLR
†¿°¥V¦®é«€nVâ—‹”hK~Aº–9Œgê!ÌRÌ.´âLÚ­š,ü«Âßa¸Ö‘OÙÄêP5‡ïNèžI6K‘È=—ƒB:W=*–M€žÇsš}û*rê‚ÿP–r>jž_
—ðŸx¬<D†®¦bD†#£Ÿö?½¾ë25Ì
-vèfÆŒ²§²V	äLÕu £=«µÆ0åQh0ÞÆjâKw¿Œi
-ÕÈo‰‹™ãÚ“Vt+%Æê
Ò0jtƒŠ!H”œæi†BôwíqßÌŠÛt5ÇYeC¤ùÉ¡ëYVPu9¹u6rOSåº÷”¥ÆÞŒð™ºøe‹b»oð¢1j¾SÑØ”×i!#a®MÒ:4Fô–la4¬ªûïÑÚ"RwV~_ÈxΣGì?~(ú²oU
-ùÌÉg¼¿Ž>º§V‘ŒéÙèðýö…5”ÌËíîFöÀƒLáÎdº6g‡­ï.üÎ2Á5¥7¹T§¯hj„þÎù¹Ó>"ÆÈeûÛ’õ
"Î3‰Ý}1¸áb“šÅ-‡âEŽÑAOÑ>Οdo	e¥¿´vÖ”œú­µ‰,ƒ/Dr£á…©ôRx_=ÜàµíŒCöo-P¡“dà˜‡S:’%ÎŒ¾6Ÿ‡'ð¿µqÞEþ`§û¤¤¼ßœpwÅ>ü
ÔT™"3„afé`f‚†ó"STâ+I®N! Fô
-³ßk9ø‡jÕÖ—'è Á̹5Üue§wº—ÚWÚü#FÁ²°h»UÚ¯ÈDçC²¯LX£	#VKÔââ•å:Ã$ßÞx!jCZJ`6¥æå6íÔì|h1e§,p¶Ý«GRñ™¯­7î`­T„cXŠ„³ŒK«o
|sg>â>uªp¹™Z¬¿ïÏÃ+Çío@<´En…sÓf…ë~›¤â*ÿ;ÐSsÇô}=3ûpãzö,¨”VYqI0ÙûÝs¦â[m† ìi6ÕhC9m7ŸšI»‹ñÓéïgEOöDVûêwYj%ÖQu4´ñ=ˆ\|ãUWìÕ›F1a)^BûKÁJxȤå8ï#çç–½RZQÏ~ÁDøLAZADÙ™¹Aÿ·¨’4<ÓÉgPèۢĵŠÇ™Kþ6j®w#îÊüöõ‘”ÞÄ¢RdÄß,?ÁLã)6?ñ¾RB]a.¸¸ÌEW7±½A³Y¡qv+Úc÷Ö"¦52Ò½òBsc0!o>]˜NÕð‡Hæ-@„eËÉ×IZ¹-ó¡)ìžW³ºŽì\Dyœ­?×(}ÝqGaçu‚ï[£µü9EHRõò+ã$¸ÿ—§ZA+1×-¼9':5öéaÀ¶‡T<ã¯ñå]·t„+…fÏOšqü6?!CorPèÚýÞì?©›—Ù’¨Ü°Mª-ælï	Î|Gn}g…t‘(•üc>.íÚ÷		kú³ûçÂâ±[ýÖÉâ/¬÷í¡ÈÖp®0#$e«”LGgˆic›gá-à‹º÷>ekL¦%ØTEuˆÑ-(þ¡KSirÈÌ` {Õ
7Q2Ä@9ì$žÚN¹lÒs÷;ÿ}“3U©ÖÏ:z'=Ú#šÓ7(kuÜ,üVÇwee¦‚^ÔôÖLÜtUwÔi?»øH+¸Ï0\Ñ//9l7´’/à¹eã:©hi<û|t‰¬üoT‚YÌĈx¼¡í—ïWš˜7Ñ\ÍI‡Vû6ù`—Ùm	ªöu'YqèýBÌ&í\¡ûñ+ú„N6û^÷~-_¯x¸û-FÖwV¸­–Ý]D}EŸŸ9`~H#¼Žj˜
ž¯2¦ï¦QÂ\®î˜GÚß8ç[…E08"Í'âœûE |áûHÓZ¸Ã·1˜mK‹xŒd7é2P1äŽŒ¾ÛU¦.p🤘E0¿H·¬R¢Û‘ê÷l“x¸ž@jùٌ뙴1óȽù<æ ʶØU®o[?áZø`&IzËDûv)Y¨™`mÈW1£W¯!_¨Àj–wç?¨[p`€œªûQZò‘5²iuN…M3@*
Q8)Vkküֵ׉CݵT²ÄM‘Èê÷:smj†b»¨g,ÞüÖX‹*|^í÷gcH‹/«gD³jvfMµ,¤7„”»MUÎËà¤~‘ÊÓ–Ö©·”KAñ3Ýw¸|ÛØ!4A.@Hš…¹*,Dúñ;býÚÚ÷®-BÁ]áÀÉĆ_`m&”†FÅ‚‡-L!ž0ëÇn öIÖñd¾‹‡óFüð/&©(ã}1ô¥,ªÚµ»†>bþÑS’«e'o¢äȺvµDy_¢™»!©lGUO¢Ù$~ÏÍ«×Õ»‰œ¡S7¥†+Ïg[ÒH}ò)å„gŠ„ÌÎñ°¢!§væXTFî`‹ì_X]7„„Ø=æç6&R.¿‚{*Òe?ß”ÏO–E´Ì““ßw|g]/¾¦_;7ø8b†o¦Ù*M0è°žš2HzÑ)â(îà(ãtgûõ‰Iº<ÊŸH	á9P•FÊáX#£ s¦QÓÊ!Á'xãK=’aDñÒSÒžËù}Xßž(É‚¾–È)Ù&j\&±³Ie1ƒ³ðÚ’Ôü?럚79¼ÞxÂöX|Mt?Ë&\þü~ñ´Š‚hM)»¾H8Â`‚ô2¹à†^æ 3X;Dy•W`›^˜]Ë‘î&å.6†xwŒOi(Ng‚fŽõЊƒFØAgcK·ñÝéZ*>ƺ„±ûŒŽUÔŒ\Ì#w…ÕJ‡ck_±ûbFøÙ‰Jÿ"&§°XC.c.1ÆÆKy€ºü¹®“^‹Q0@$H6ÃÚn¥ISRP-™ÀÌ:â,@„?mNÆä
ðl‡á(f4
“¤	jMtåA$u¡¬Ûbã&wC†Ë6+™…³Ó[˜R¤Ø5ƒÆÃÁfy]Y¯¸¢%ÀÜHăJ~—Æ;Å#7Ñ*ŠÄΉ€95÷*µEæ/,ºl¹)‹a!B’D_2^±÷ƒ7õö¡•õ5éØ13XWÒ´ëÎ룥ÔÛ°\ç]þF[¾âBa{R¬ÛÍ–¬ŸEàÂkÎ$‚¾;4›)í$0€UW—1”QÉIÕ÷fÆÒ1–ØkíÒ+ÛUõK§ø°Õ PÈ:ÊüGÓ-‘ÈÅA«ó¯pê¾Ú¯ní€EKiØLã¬\)A;¯(ú~Ñ÷!jæ¸lŠaT¡çZ™™2Œ©ÁP‡êÒlG¯P¬Üý†á(h>q²¦3ã*ߪ’CN«³–ý…w½~Ž&ho2æ—m¸L${¯6o•yõª.F”Ÿ¤[Å©ülMã,™v\ˆJ
-CÍŠHV†*t2GÂØþG³ìŠmÜZxGe·bîBáÙãÃù»‹çRבb’Œh¤9W¸–øTgR¸Ì(”ø¡5kºà›É¤¹µùÛbþï¶-Ê~˜;”7ÑmÆ
^T˜‹vÐí­&•3özÑ/JÁŽˆ¹ËM6¼ÑH*­›Š=Hœ¶CPHÅÔª’.UJòûõÆP©ãËŒè«Qû¸œŽd»7x‘w8™‡™rÁ`"d
-+ìöù[Õ2š
-ÒñW:NF1R„§ŽÎ)}ß0
-í>Ö‰†­õçl?ë&ú]ÆÙ-Á'†â¤ª?…²Ò0$¸	iú]÷·ñ‘™ì-Ëö’]ç¼w¹8Óœ¦aé•«S¼Û¦;èò#.	ãm^kZ_†Žg#(¢X¥ò“º·ŸA¬Ö›"ÓŠ‚Kæ³buëK¿ªwöVåÞ#§-÷Ü@VM<˜ÖÊi7´Â£„-v'È,ÜbtL%!5--IŽ»W¾l‹ºbÂÝ{dÞ™áð0Œ¤\ÏR׳?½z}:CZÏÒþG÷ä­¬þ±Ï›pÈ:§lÈ8ÕQµ1íåðaòj/‰±m¡HMlê—ç,Ú#cl•ãZÀ„´]äI~›]O踑ơ|Gàjz“šÊ,ûckÇ$±	ZäÐù+†´Í?‘Ja#ñü/ÛùÁ|ìJ§Ü.̤pPë&ƒã—)¼Ái¤UøJÛÁöSùOq†eT¨
-=èŽ
íóÀ„>zß¹‚¶ìüœNžé¸i+h:“¶’IðWþjQæMýò©†4#{µ8<Ô2Ì^þ¯™ZçóF—o£ã¤[¯Ÿ&l´-æ„ÆÉ„l^»ì#K,yaÂÓŠ	ô-®k‰<+ꩯïƒ,ƒÅSÂÊ°&£²¹íjXºEéÆŠ™8?%ùŠ4<7K[_"Ú•vŽ³Fk“¨ÝÏaMY§!‘ÉšS·“7¤4,­,ï2Í¿¾pæ×rGð?òåi%h¬ÒÉ´UÐ5ñýq5Ò8¦ »=¬óÙWÑù0YL \-síaœ3;Ù„%ñÐwæœ~ðbE†dUÁ&ö	½D"ë}‹ëI§«‡AªS‰<ç'Âo'rX.®!oö>QÇp~R¡/~™©Ü\?ý-3³Àö„¾¥ãÙaÙ0Ú“5ÅpÎ1¥¬¦¢1Ú®¾S$Ë5&fy¦´vZC_p|ÐÒä
-P€{åN¢4­DŸÌ5ßv‹ ë
+ãR×uÓëM>«YVB°éHŠdŽÈÙf?+ð6±§}1º,B-¤Ylùö®sJÏwŠ:—(Ëë·‚ÁÑ!š(|â÷qáôÑûbóþÛú—
yƒˆ-0¨Ý—Ëhak‹f¶xU¤ÓyëÈL6²—ì–®ý|붘êcÈMOÑå9ÄìíaB¨?š¿´ƒ¸[	Ò½µè>x©WHíG6ÒÃêÀ+¬ÒðTã‰ù±C¢Þ4ÚèÇ×¾l›t:h²(¨”ð&‹a5ÈûæóéÄØ­K2=1Z4Lx¤¸ù`¹$õšé\òîô=ülqð¼è¶^Y•=ü"ÄéîÊD³ÛÜî­w¡ÓÕCïoúGíµ-˜謷_yà"Œ5é²Ðä…v®M
2úò0s3t¿Š#TO¡fØÙè=ƒ~Ûé+ç“Oâʼna.Ú2²­¡\F\Ò¿BçW¹D+þ-™úÕ½ƒ£QÑOF¹p±%¸ôC!œ.>Û!j²ÑÆ2`N+±ÑqœÎ‡v)¦rÍ'(,h/íšxŠ…m—é¶iáP¢ï1å·/Ì
-™P9ʃëu²‡2†Fƒbtnh–!jTV>Ì×A}ŸÁt=Lo–Ä¢Ë9þòVôª_eá½ÌP~Îà_V©Ë°?SâßõWx¥J}Ûwÿæ‚[Ì)"óóoWΖêÔ(þ¥òvKÑÛÀº¦DcЛ~´o'1ð–›ÿ"·\ÌrÖÓœõ
-ðÈÅžŒ/)÷±^&·ÒL#0¢8yX¼ÀI¤¦žX½;ys1iUü3/çu´C`;ð
ªp
öln¹ß´K ˜¯&‚—D:¥ÎÖRB¬¸×g[é¹´ŸßtG¾Ûž&ïÒ—ûì‰çx±²GµpÂ@7í–ªÉúÉ@Í{ÕÀôü¢„S0[Ò/¡º¢«gÞâ•ŠJ¿Œ\ÆÓžžÖT³2¿ðˆS„‚í­úàL˜rÿ"@Sb¾•´Í³ìhÝ(Î%hØmšAûûEö{<÷væéúlX££œ†úà†ËT|AÅ}$Y‰˜E›•~´ý¯ÈÿØJ+~Þ4Û\×DW1âÃ
G¸s7mÌ%f'Þèä”øsÅß ëÉÒ¤^Úøv„H·à—^ó˜`vÈÞk‰-vžíÕ»ÙÖ0@®Å0‚ç
x2@äq«tø­V–._J˜Eõ«ÉAYçû«ÙÄåØPû‚³À73­Tð{µm@¬Þð88)´ð£µ$dUüüæswd.SJ*Ï£/3GôèFßÖB“ën4%Ãn-{‰MÿЂ>]úÚ|‚QÃÌ4â)DYJ%Ý”€H%ÅQXc1b@mÊÍæÞ±˜M&ëyó
-ʊО=ô
-k…H8M)¯‰fXý|:i¹²»&Œœû#Ñ“‚6~´”ªF5eûÎ+qbYß­	.-椨š÷9
>ú+ÙÒ‘c¬õ`ÎÐâšStz£q)

Ó7šW7ØŸâÓ4è’¨ëHUÓ×}PÏÚÒ%§S¨7Û.êOò¼ÑöŽ:Ñáݨ؅jé¼übs±åma¡}î'yŸ?ÿ†‹häEúÝǵÊ™}Qƒ~¸'ªÜñ–¼cuG N=óæ]õ2ú׫Bó¼0®Ó©M]oA'ÓÙÔÇÌÝ]Ì“ÐkUy‹tÚ½³7–pБ ²5‘#•¦§e÷µ..ØBeïçeÒÛ -Cµ<ª§yC½ñúã
¸òZ·ùu½1Ê$ÿ†HLõRæf‘Y½2ëëÐôYמ6j›Ï¤~6îEĤ88=wšêWVgéó;Ýó!k¯c`f8ýQqñJà½Æ;Ë—øn,Ò;n$}÷­·Le¸Íq½iYˆvè-™Íe †§2Ç4`¿DìÅBÓ@¢”Õ‡o´ˆKÄP1ùƒƒ†×‘àLÒ$5œæj—ð$‹Uë%&¼;¸û?åH£€h Š*{df”÷xuFYãîVÌ’‰Å0L´§Ë1]*EBìYT=ò¶ˆRZ†Â
-|)Ž¯âðœl\H˜ÝIC>–ù‡»…R©-/	ã–‡%Ü©Ù̺žÖ{ªûN{o6]”½óÚ#X1P™f`EŽ²=Ã(H¬ûO=CšÛw“ÑKÖß”s÷Ó“Ú7ª‰]ì„k+óJçmô/Ö³ôCû™)¸¦ñç‡ÝL*ØúÃ/:;<±á4Ó$Bo:€+?ÅÂìd/\:¢N/ØDR“à~«ù²¹á5LÑí©ÆÏÞw9‡ù¡þ Pz«×jQ
-s½vI½6Få½=QZ&Iª r¬­¿˜¬Î=6yþ•.Ä÷’¦Ô¾Œt›x}Zp–F¤]ùuãôÚ77ª/°¶‰ž –áiX6EöúY2«.̸§Aá{ÏƧ`-cß×zV¶À•¤f¿ëª±”
ÿ°IØ%?´˜7SsJY¶Äs}ÑŸ<'<±¬rù„ƒ³3í¶ÚÌ¡!›öˆÁP7KûC:Aiz¤öö˜ýSñð~ºrúsÏQY¾ƒ‚Š/ýthÊÕÔ±8‚Q-_:¥¶L+€6*£Ý0r’¡œ±ëDäª:✇'à
g‚Ç×T[‘–m\ù„|-9ÝÙ%¯e?µ•Ñ¸;ªø·•âìO¤»Ÿõèó<êÈ|ô¡¹ÛÛ6b•œšÄjijÇP`÷f›¯zcÙŸMÛ¼Ê	À‘[Œ}_|.ýÐä‡O•_‡Ìc–¼ûUݹ
‚oŸ–?‡@2u_{¶¢j¤ÉÊÂäk
!"¿{&ŒÍ•©ê6Æ›¢sgŸeœ™øjº=‹Èp³ªCigæõ”õˆ®Æ³?Ú¸z
ãûQïÓ\µêžëc{Ï( [ZHº¬‹éÎgð-ÆÅ
ïâ+ë¶æªõÜäï|õœJýÈm£ÐJUiª1„
-ßvÏ:¯†„6[–´_"%¸íÉ,z嬥ͦ©2ª‚KÁîø£áéÉjÜ0­ƒ¹*´;äšn·öRRêSàr4Žåý?41‰àÒÒÛ›úœ‹sâ*ìeÕ;
-ÍDãw§¸°:Mý
²qù.ûþGõ&‹F:ê1΃Ю,%†·¯(µL{vf‚¦ç¹(@´šdqˆ2onnôþ7ëc©„¿cì•î®úŽ¢Z^ÿ)Óax3'µ¹Ÿ‚e>u¿mðs§¤ü牥+
-ª³èì:œD^U3Œ»º÷ÅðRîfE$¥¤…~;,º-YvÎ$àu™‘·¬Áú[“l °Â°a7ÛÙ%w¬Û‚ÕWnî<Øíl¥»õ"YA~FÚå	âDëþôa’–H¸‚óU
-@üY¬öÌ_{½õN‡Ù$åÇ7ѯVxàK9>:t|3QëØñ¦É?ð?ÍÌà\6ú³_+¿¥§ÀÆ4…çf¼lŠl”0Ât|Lòâ÷0ÌA«œê–¹¢D fhtV",µÊK3óÅ
.IÄÕ x0>›µ@²åliØd‘žqÔö5£3=@ß2œï’XÏ·‹|B
•ÃT«õÄ8×AþwbCƒÙlÕÏ¿‘*>Œ¸¼—Ôb_i'TOHÙûÝéÊɆ}3®Ñôn×…wÍ…Dˆa@FÐz<ýkd?]‰ ¤Ë‚h8à[búÖIî£åƒ0
!Öú¶UŒßëÓö:vtÏê<­'ºb²/gH¯Æp3.Þ¯.µÐõPµê>µ¼ˆÅ½®zò-Ù2#Êle°§æK‘­t‰tîîÉõ½3cc‚	-s²µäéEô¤³Ÿñ nhR¡×¨a/ŸÎü{
-À/6ñü>pF‡)Ö“‡Q÷Ïõ·om1ùÞ^Nˆ–­Žz±5Ÿ~ÜÉzŸŸ¨»~^ªì®—Ö7\JTÂS!õÎßh^êG—×;(”;7Y¾¢™$ë±Ý+ÉÊ_`åuPèýQYð·õâE¼sÎ	[‡71Jš³VjÆ-ýôÕæÓ°QñdNk{VßH–œyåv	ŽÁØ›MÖ)3Û†þžÔ+wݘY­’Á¦>K;m¼kxó¡øxdGò{çDþ•Ox§WJ½(ÎçöÏŸ°Îáu3ÊäkŽ›¤ÞÓ¨öUŒ1‡å
ÜçcŒà¸ò UÀ/ˆ¶Têëµ±¹ˆÈ5W×±#àìJªÕ–Þ
-Tßl_µ›ëb+eÊ¡ýºžMDÁ¸ß7 ”¶cœå¸X®7ݽ›™7t¤Ý«‹Ù“ãS+I4f=Öçâ\™Fƒœ^­‹ñòðIö˜B¡é÷VýµXõÔ’8~ Vš±¨á‚±ûSDZ~’»Ág3÷Îó°—Us†C[Ù¢œW Ä“šHThôb£«ÎoŠrJ!KŒéðK££8ò²7tÍÍé{ÛÚZQW¥o^å«®x+"ácˆ#dÿkå¦Øåõ}ŸÎ©! ‹_
-”°+ÊØöÿ`ûSKhÖϤfÊúw ¼0ݲRŽXU§­b»£=á{_{X®/L$šÍv…0.=o3_5ý1Œ¶äIçw*Úÿ¨ÿm‰dýC¢[ÇÀJ.jUAoŠÉñ£
9^Œ}è'‰£‹Ýïn™î¹q–Tå<¢™õþ%½qAp¹[䌥E¹ õqøy¤IÜIŠ:ùb<ÞCm%Û»¦Ç@z­1Y¢8
eÓnÏŸ»¿Ùñ~èE*Úh—÷áS£ØB„—ßv6äÙd›âÒyÈnÕðÝ}ܺ‘Ka±ŸVU:ŠÌÕ76	¦‘¦Œ?Vù4¤ÃBÖ³·DÚpŸª¡{]ÞoŽ"Ã?–5s¶§S“ÎTµ˜,9wÝàýŽô‹¼{·[뀙®L} m9¡”aü¥ªÞ)-‚´É¾¦ÝKTLá‚Å	Üñ$iÐakwÖFdìrªî³ìbÌVIG&™`“`ùÍÙ–%¬0ö°²ò²:Þìøpô4Š×›se\α=£˲<•™Êοè¢8÷#áëÒSüNx t,3=:¶4nø8™!ñõâ=Ýõx–›î—ŸR…l{øsðÒÖ™Oïù›±E¬úCºeåªBTÈBsñ½Ç'DÓè6gÑWIûYr"C2¼à>}Ë6$Óóÿf²ûHıŠ•ú#Û>§-˜`æ³B³ܼà²ZtÔŒ9bJ•Ùˆ)œw§x,ò:Â<>ëò`o~ÿ
-ÕçaΗŒ3SxÃïéšßOs:û~NBÜÜ.%Qò¡Æ[즉}’åÉôÐéŒ,IÚ„f@úÚ˜ð­þ»X¤ì]ñÆ·‚:þhŸ´se»§gB„¾û.¹Öøâ•#’A_­+§X•ÑoI[Rh½ãô4E³¸­JLðïDuõÝ™ìEs«Ì—už7:èTÛ˜òÞ+êñ/¾4»üå{†–åt™Sy€ŠÚ{¯Úµ1ÇëóÈ ×ðÑVI#p
k51»i¬¯Ž>ìÊ4k,½}2årPky+HÝòöSÕwn»ª}¶¸°5­U¯¢é’L ðöÜžwK®aACsQÒœ,…ýê\–„å:
f®©0—Lœe³m\gSÅrm1aç÷6âóJ’Ýqj§ÅzÃó|8ýÆÐðo©h>
+stream
+xÚíteTœí’-î\›à.ÁÝÜ]h ‘Æww—à.!$@ð Á=¸[p· Á!—|ßœ9³Î_3ç×]·×z{½Oíª]UÏ®·è¨Õ4Ù$-ÍArŽ(;§@ì`îæªìQbÓY»©šÛƒ//´;Bd€P@d	Y¸¹\‚‚‚htiG'/°µ
À¨­¡ËÄÂÂúOË€¹×?—HW°5@ÿòâ²wtrA /ÿã@Mµ¬Àö €´ªš¾¼Ê[ã[mÀ[ä´¨¹½´bP[€ ® &€•£ÀþïÀÂb	þÓš+û—¤+puY€_Â@ž §?+À	äâvu}y€]Ö.@ôå Ž0ÄÂÞÍòO/v+Ç¿
+rrq|ñpxÁ^ÈÔ]¡®.`'(à%«šŒÜßuBm€Ð?¹]Á/0ÀÑêÅÓÒÑÂíOKa/4/(†¸  OèŸ\æ €%ØÕÉèõ’û…ÌÉüWn®`ˆõ?+`¸€¬.–ö Wךî?·óÏ>ÿ¥{ ““½×_ÑŽyýg
`¨+ÈÞŠ‹û%§ô%·5‚ÆñgXä!VŽ.οí–nNÿÀÜA.]㟙az)hé±÷X‚¬Ð8T¡/)Œÿ3•Ùÿ}"ÿ$þ·üo‘÷'î¿jô_>âÿí÷ü¯Ôrnöö*@‡—ø{É^¶Œ#@	ðgÏØ]v³èÿ
+:€í½þ›ÀuÔý]ìðý+,¾\Š$ÄúE6.nvοÍ`W9°'ÈR
µ°Xí_îì/»6Ääb†€^´ýëZ_‚89ÿÓ²[ØAþˆÀû7‚Xþkù/rýU<‡¶‚²œ¾Ë·aÿòT{™¨–—ðit•-ÿóð‡GJÊÑàÃÆÇ`ã~Ãàççpqùý7ÿ¢áúçYu{9Ù99¹/ÿÿxþy2þYˆ…£åŸÉÑ„!–/ÃöŸ†?°…›‹Ë‹Æ}ÿ/Mÿãü×؃@ž ´Å9GáPÛŒìLh
Q~ÿwÃîN.øþ0§ò:­’¢À*ÇŽ€ŒÈuÁJ³Çê0öú1¡ç¯^³‡NOÛ
+Ì;ƒ„öé ÓBr?¦®"ÜUúV~–`“rÌÌ#ÝXŸ³¥5>Nïê&eHc­o\PÎn˜iÜ‹ñi¯°ü-Þ×&´áÔÃàÕѧìß\3ô
ô÷uœ#vm“±ä% Ò	»#`ÒÇ:瑉hWúD±lÁ}Ù¡ŠïJÎçâYÊÝ¥…ŽeÌ|,PwÐÖºàóoËóÍQä‡/Kk×ØC)3ù•kKКM,y]íÝ»IWàCn‹ÿ³ÑžŸEbg¬BY¶â	EœÞïýoÕÍ%¢_¹
p¿ž²Ÿ¬?BûZ·bŒ“ˆ·d*RˆÈÕÝÆø÷@÷¯¾òðgŸoÒÙÌ2ô!í¤Øô‡~‰±ùÁpÕ}ØK³ç¸ûC׫F%=ʾü+Þxè7§Á½€Ö4šçBé÷e©mÔ×q¨%Ù®ñF¥Ëª/4DÀxá‹dÍÛÌss¡¢¬Ù¯?¼eh%Z+r•ØÖ•,s„Q|p\6“¦«Óò·—]=¦LéB˜®ê*‡ð^á„H¢[„%)ÔhÓλÿÔnýBõ¥Ãë8yÆŽTf@F.õ5Ó¶UWbË‘Ã`î“”	‚²Ã2š&·äåêÜ+V	¢,éx”©›ÝmUØ#ÖâI±j†ð¤/]^{˽èभˢzÝŸóS¨ˆ—=¨¯ÆùN0¨®×|ï¢oäB¸F¿æÞŒþn"·3wBaÀBp®6à½ð´á›X¢1mS¯–G–èf9
et­çÞ®‹œÈCöê(1árkÝØ‹úÍâûR9/ORŸÉ/Œ®[–K‹†)5;ô‡Q¯¬puâi—╉Xüø’›öùÓvö®Ax-ÈEʸÄÜóãÍûÓûñ»úÅyR(qr4<³ÎJw9™Ш¥=Yì«ÂÎä÷~0fY²ÒãNªDí]÷qvqª%%›•ZLl4Ë’‹F|viˆbt0©á=e¨_h.eJÔ¦·a)PýYó‡Ýz›w„&ºÑÚàÖÂËØX©¯àÏ
+µå7„ùŸ{D/kÅ:NŠº3©1fæÁª®ÖÌ>›ˆ0œÊ-~ýdžR¨X<™6Ú4’ÑzVÆ„öO”ðµaÕ=åƒd!?Õ–¦.OB)»OÞ8:eõ4 ±ÎÌYÉzM—I[Øù\ó‰i·Ó¯‡‚¶j×ÍX‰õ­æáBJ÷[ØE¾RS×ß½c&È1Om+bi¬NÈŸ
+"¿¹V6Õ›dJ VOÆýräªÕpê9£åLV±Bï÷Õ&JÀà»<ëÈdRs΄5Ãc6âšþ=ó×½Ó#|õ‰2Ìu÷Ñà	7$tD;³Ì/>ä…¦+²Ø˜±%œýD@X;…1OžK(„ØfAH̦Ê"m…
`²­èF5óRX¯.èÝÀ1_|qãŸ2
+òâ¸ÚqÍ\ó°aTúËî3ìlŸBØ0UmËç:<¢Lµp.«ŒHa>7÷ ¡$é$aLŽW*æ—ôZÇÝඔ‚ªÖß.«UŸHeYê¦äñ4’5¡ö|Ž¥òïm´ÑË­çŠß“Trו?äÖÏä‹wJf–h÷3»7P¸bF»`œ/[ŸLÏ>¿¦td#ø5‡ÍPÝ®gÊ|Ô«ÕCY…#4WÚ*€¿0Z^oÖ,F±ãƒiôŽ¬÷“Ön4
‘EMI;h!ŸQ5r²©äÂÏ †uVrŒyq ò…f~IØA¼þ8«+ö}¤&ØõÃu"ažyº-¡Íß*Ã
ɹü#Líj)¸|›t¿Wu‹ü4°s!MRmYŒ5 0ÉWýŽƒýÝGiÅGÝD¥å²VŽ>5ºöæw&‚ß3F\Ü~'²Ý»µIËO™ù™õ¯âÑG÷4•ÌËX¥+© ¬ŠD¾I_åhkˆÀ/ÀŠr2ûHïíæ÷¹Õè9D¾ÏÔK1Íœõ.ÂÖf:¥©_ˆú™4LT™M7(¥o3iså—ò»ºö½_ÚC'¿{drmcN~µG§;ÝÚq´	ÓCLs:l
‚DFLS¤ÁrÚ'»HíÚGtH”ÁòaÀÉ©ZʼÎ÷h96åË—¤õÆ3ψ%6Ëpx¢OÚe.OSåÐœ©<³Œ)˾F‹´®7}Ë”#)_Z¥¢Ê
+7ÂÃD
R	‚¿è±¡~HYÑ+RÝ,=Ä-*Òÿ‚´-°?MVC˜$™œiĵ5˜Ãù–…Z¶a8W‘OYE«Pj5úïNhŸüˆ×KÈÜœƒ[—ÝËŒÇÓ]ûʲj¿æ2^*î_5—ð߸-Ýg…û®Æ¢…û#¢žö¿ô¾¹ë0ÖÌò·h'‡Œ²Æ2—ñeMÔ´!ƒ-ËŸŒ`Êz"ýÑ`¼ŒøñÉUÅæï~Q¨’:Ü&1:Äú7'â/é|ªÖOŨÔ	,‚ Qp˜¥ÒÝ5Çþ0-jŠ×Ñf‘	–šã#ƒ®fZBÕdeWYÉQ”y1°Ãgè¼*Ýy‹…ñP¹MIm]V¥‰Œ„=¸2Jc_ÞY¼itP³¬æC´KcƒHÕZ~¸=›þœF‚Y}üR>ôa&Úø è=-—þé:êèžXA<¤k­ÍûÛÖT@"7§½Ù2†;™áRÓŸºº3û;ÓׄÎøR®¼	¨ò;ûçVó€(§Ío–·ˆ8oMÅktöEáú‹Œ+6ì‹‚çØ{=ðEº8~꓾#‘šhl­,>õ]i^_ÇçDÁQê&ó¾~¸ÁkÚûïßš£BGIÁѧ´Äóé]•¬ÞOà#>+#¼‹¼ÞV·Q	9ßi¡öò}ø¨‰yF0ýäüÁä5ÇE†ˆø=V¢l%œ‚¥4è5f·ÖBОJÅÆÄ´WòÜŠVöÆêC«Wº§ê"MÞƒ@0ih”´í2ÿçE|d‘ó>s™×Æ,QáËŪ±qJr=­¡ïn<µ 
Å0ë’3²ë¶ª¶Þ4˜2cæ8›n½R^1][­#ÜÁZ*E#1
+eÕÔ×Ì:8}L¸Õ÷aÈN˜üŠûÔªÌéjb¾ú©;¯·»ñÐA¨1ÆE“¦{øc”’³l
+¶§£âŠîZ<3ýrãrö, ˜ú¡ü´sÛ£¦üÇçt™-’,ÊÁš2šv^I4{|ãfg£!Æ-’ßÏ
+l	,vßgª[™GV©SÓÄu rbðW„_±}\7Œ]KöÜÏŸŸ=8RÄC&)Ãù13S³à™ÜˆzÖó&Ü{Òâ®;›{ºw/L=®¹>Îi%Â+06wIœ¢¸/óÆ1qx≓–^½Û‚ŸVæø
aF©kH£ ¸p”6œB¨EAb¶¼4ƒ"Ògå#ß–ß]ßÙ¬’ÛžâÀÓÇQ´ÝKçãëA”œ˜jô¾ð‚p?Ѓú'[yõ|#—Qb9rȾÃFNw®Å^™Ý~¹6”Ô™ÓEŠïábä߬í#Áæ#ÚWŒ¯*È•:ëè$4×hÔË×öÂnD¹ïÜšÇS×¢FD¸}¸ÐXëÏI¢U1Øθ3o8ú8J)u£e<Ô…Þóh|¬"=–gfíÎ1`[u˜ÅQAØÇyïóÎp%oZ’øqa’…aÜýËC5¿‘ˆó^ÐŒ
+ûôÐÓ]2Žá×ðÂŽk•|½Ç7X>럾·Ù(´Í¾o÷ŸÔÌJmˆ•oXGUç²7w&¿#7¶Ù>E"]$H&íÍĦ^û0„“•¶}™–ŠŽÓQ¬W7ó,žWïG²ó©O]k®<ž‰Ý™mH¾ uÉ%—œ)09ÅÁŠ§ŸÚšaQºÍ³~aµÝ°ó¨cw˜[K¦;ÿ
+ê(O“ùRtS63ZÞ0CFv߲ͳZ
+|C·r®ÿµ?Øô¼©F¨$	@¯ÍrjB/áH
$=@"¿ƒ£ÓžíW'$êp+}“'!€ëeGUú!‹cI„Œ‚Ì‘JE#‹ï~üª_ò‘#’‡Ž‚æ\ÖèÍòîDñLîôx@ÚPqÈ&É@ýê4‘UªÏ0+	œeˆ×”¨ê÷]ïÔ¬ÎþÍÚ¶ûÜÂû)V¡²çOs凜åEj¨KØô„Ãzã¥ÈÖt3zÀZÁJË<ü›tBlš´7Éw1ÑD;ÓàWb´ÆhfX8h-´Ö6´kێג™ð±0vÐÕ8$Œgt¬Âzä"nÙ+¬FZ»ÏÛ	ýP‚ïŽl”zß19„DkrrЈ0ÖnœËâ{ÔäÎuõuƒÂ2éV¶KŒ
+€ñLœ #Ž|DøÓú$LP÷f(.€RC¿7é@
+ÿ³±Ž“ˆ¸*„e³VtØø®Ï`Áz)£`j|S’»§²×¨?È4·¼-ó5W¾”8˜‰¨WÑ÷ÒhòµÈ~à&JYÈ)0­ê¶D©:Ç4Á¬Ãšž“<Á$ ŽFô!uæýÔK~Smò¡z­2
;zëJŠfÕiu°„j–ó¼ÍÏ}ÃGL0tW’e³Þ‚å»0\èœCå™xà¶}½©âV<=Xeys¯”òLV²º3#†–¡ØNs‡Nɶ¢»H*åÀ›õ³?òБ´¥Ôo0͉L´0[„SS÷Ñz}k,œOÅffáL¤ßzMÞõ‹®Q½ [ßy]£=ÇÒÔ„‰ÈPmC
v¬M£F½\áÃÎ³‘“½›I¹Fålºs=˜•ø¨	žÕêiêÀádùY‹z±¸úž)fë’\ä14؛8æÖÑ–áB½d*ãó¬¿ÎNô®¦sËÖG–.‰£qÕÄErÓõxš1'6á2ì<›¼”gÔ*ÚP~’l¥ð±Ö
3gØr"¶*¦Ë÷Õ+ YŽ(ÓJ	aûM±)ø7qùkâá•ÞŠº	†µd
÷çíÌ«K^Gˆ¶J0 ‘d_áZ¨¿¢<“ÄeB¡xR¹¢¾Mœ^™Y²é)âÛ¶iÀ¿PòÅÜ¢¸‰j2ªñ¤Äœ³…nÎjÖá+Ÿ±U‹L(9 ¶ä,ÔYóÜøµÚ6ò:Æ>{Wµã1¡ò:›ýÚßípõ“DùËDÐ2V†Iq0³’Œ™}&Ïéz/–¤‰—¥¬cžÐÑ‹Å3?5¸œ´º¸ë§8ËÑs|#øq"‹åìüv÷U4Ç7%úÜÄäçÑõÕÓßÒ“³¬OèÚ-f53¨™côçìcJªÊêƒÍj[…2œC¢gŠ+§•tùÇÁŒ*°y¨AÇiÎ(JmßRÔÉtýmk¿0²n¿.UU;î質ÅÈV--q!½ôñžL MÖ³<·@[êÑaÃËBÔṆï[W¡tÌp§¨ýp	2<¾Kì-r ±ü7>ogoÝ	ëO?V'ÖäôÃ7üÀ f*,ÃýÙ
ê©¢eáV§#SšˆNÒ[ÚæóÛ"zʯÁ7ñ„—çÜÓw‡ñ!~h~Röb®ùÆH÷¶øV"ûàù\AÕ½Bl¤‡•-€gèƒSõ'¦Çñj“(ýŮ,gë4Zh’¨„à:“~9Ðëæû
+ÉÈصM"-!J$Th ¸þ`1/ù†ñ\âîô­ÜTQ‡ÐŒÈ[ÖNåÝW…ˆãíñò	Φ·9íïCÆ?öaô|ºé´Ó2gz µÚ|펋0T§ÃLÒº2ÖËàÃÍÄEßþ:–@A,™Š`k­ûúm«§”G6Š+Š9gÃÀº‚r~I÷Où­è·DÊ¢[{­‚¯´rÁ\CPÉ#†|m\¶}äh;¢µ…ÿ´fB­Ã0=­7ÍRô‡/œÀÐÀÝÔk¢1fR´^¤ÛºÙCñ®Çäß>0c(¤‚e(Ö.×ÈîJêùô
+Q9!™¨‘™y0‹½zÞ½iº˜^Ì	/D—Ó|eæèù>JB»!|A¿,S`&ǽï.÷L5ü±ï÷÷ˆCXæçÞŽ¬
å©aÜó‡Û
/}WRèŠ"µ±gÚѾ­øÿ;.¾‹œ2Q‹)3–+À#'[¼„ì×jéXÜö¤êáEIkÀò YBUµ<ÀòÝÉÛ‹QË¢Ÿ¹Ù¨ƒ-*›žP¹KG}Ãýºm<þ@h9á¹5+3WgÁ¸g×TÅÓ_¦P¿PØG’ž³>QîFÛ_DþÇÎP\òýò¶Þúº2ª‚á\¸+WÝÚtBVÂv±7×â«5ÒnáL
ªùµGˆ´³¾i•ñ™p&û¬Ý†˜"§©NÝ›Mu}äφð<þúˆÜ¡ì«–¦É•dRþ*D²WÒ~ïözjq¡6Än¿ç,àíd#%üîç& Vç
xœRðÕJ²,v~ó½="„))™ëÞ•‘-rt£gc®Áy7˜œn»’ՃĪwhN—&um6 njþ¬$)ˆ’f‚ÏF¤”d/¨4Ч2ábukÙL%‘v¼}
eAhÎê{µD(”ª˜[Gݯö>
‹¤LI’MFÖí‘ðÉAëU”¤Šz9EóÖk1"ŸNM¦ÄÈÊOÙ5ÞzKYRC,Õ`Ž¢ÊSt:Ãd1Iuu“bWê×7ØßâRÕi)‘«H”ïŽù±ÒV½QÏšÒŽ%Æ“©Ö›.ªOr½ÐvéŽZÑfá])Ù?ÓzúÆä`ËÊÚÀB»ìÝNr¿ÿ
^˃ô»‹s™!"ë¢ýpWD©åYËò¬ZÆÍû蜯ÌrC™9OÇÖ©u¼M¦¢Q3vv0OB®ù—ùå”Í/ÐivÏÞZÀAIW„·é•ëžÜVÚ8q`Œ•¼:œz”Hn5
Ts)Ÿät‡«·ŒÖàÊ>»Î¬‚ìŒPFùÖ„£?Îg¬šV+±¼	I›réh¢²þNâkíVHD‚ƒÓq§¡vey6’6³Õ>¼ò&f’Ù¯Þs¸µqž÷Æ<ÍÞ¡åFÂ'lÓjÃDšË׋†™p‹Î‚ÉLbÐs*}L
6÷=AÄž+0	 L^þrøV“¨XÌ“/(°	Î8UBÝ‘~úóü+~‰"•jñ¯®îoÙR( jˆ‚ò.©)Å=^•aæ°›%“DBQ=#ÍéBt[­r¡ [&e‡œ
9¢¤¦ÐƒcàΛug%¯ÜæpLyTÆIX‘š£,Prb«îSàúæ„ÄZôâÕ·e\Ýt$võª¢[aZJtã!å(WcÇb†ŸyÓ(´¤4‘éÍ£ôem'ÂWÃωPq¸ýßrÄ»÷qŽU‘²jjÓÄv‘AÈV’ÒœœsöSšXŒÚ#‹~[*LýDºûY>à†ÌK’³¹i-úá‹chåõç!ØÝ©ú«Î¶g“°:Ï2|pÄÆCׄ÷¥/šlBÿã©Ò›àÌâ7¡¿J¢Z ¡}ðÍãrçH†ÎFTõT˜<Í>Dä÷Ï19="ÒíFØCc´nlS“#‹&›Sô7ËÚ¶¦žO™èªÜsqƒµË×0>_u¿MTyÀsylîdI	J•¶1Ãy÷þ¢áĸ¸á™{mÕ´ÅT±š“´÷ÞGïÁ±ÄÏ‘ÌZ ­P‘ªM ÿ#~ç¬õªOp
ÀíÈ„ŠŒ0aËãÏWK†'‚äwè¼cèª=äÊPð5×€êþ@%`pCo	N^³9)üÎ\›Iž·“S«ÁßR‘-‰ñÞ° YŠ§ã6'0#è–±”Ô›¤H«Ì¹½ì	kIKRå‚iìÍQ¦Ù Óp]Ë¿µ“”Tû¢—­~š…¢«îlô~â†õàØü-³er@ÜYŒÖäžîj«ýT"ŠÒãÛ¨×KÜð%ì_í[~«¶¬ƒxRåøž&'q.kýØ®ƒ”ÞÑ‘ccšÀs1\ÖEÔõŠbº<&zò¹d£}‘l—¾¢@ ¢¯uR$î-±ÌM3ñÆö΋ÇV"¸3<›6@2dm¨YežqT÷5¢2ÝA?ÒîYÎ7½C”BU*uE9VA~w¢}½Y¬Ÿ#•pþ$¡-È6;ÐL Ÿ¼û»Õ…ƒõôí°zÝûgžgbAúi«á´ÅˆnÚbH›+À Ç§$X?å£ìW‹!j¬8ô3lËhß7§ÍUÔlîès5Ã¥i‹H'Î^á¦_|Zžo í l:ÕyjÔσ{]ñäS¼d2B”ÞHg~´ê#n‡Ö7Æ
+ñ,(ZÃ
…G!½½,‹8yKæ;~ã)_Çzá8´‹öÑÊXÐ/â&_5º(Ƀ|s5š)ˆÒá+>úÏ°c²±lj×ú²ˆ%¯ñQ
eÃü²†‚w¾ÙÁÜUú7|Þ–ýö‹ç4Ï‘³·¾hB²’Œh'à¨]NåD¡·T±TÎ$nñõ½Cm¼:1
S’•ÄéEÔ¨“¯Q/nHbç A(¯öÌ'rÀ/V±¼.p:F‹	Ö“»aûÏÕwïl0yß]Žˆ”.z2“ÖŸ~ÝÊü”— ³z^¢ä&Ÿ›ÚÕ_BXÌ].ùÞ,y4DñÓY=õN[“ou1~KM“éýeülÝQЃ$¾®QJÖ\â3¢¼ÛÚ7²_ÞU2æ°(²89j¢è‘X(ÍàRêôâ&*ÔÞ—«ÿ½—R„Kó(P
+ïÝåJÂYsD,~ ‹j%ûÏ.Ÿ(gªbç7ú[([7™>"Ä«1íKIkJ°rÚ(t~¨,{|†xáïÒ…CWá
§­›ƒpK¾}AµþÖoX4šÝØœÙ5)köa³ŠGöfeÌƦ¦»#%ÝÅM'zŠX³¸·®ËÂV‹ïÞ,]0.Ùìëî9¡ß‡'¼Ó+}ÅNw§s»çoXçð:¥r•Çu’Ÿ¨óUºÊ‡˜BsûîsŽ1ðô]¸ÑÊágE>èé6±:ËÖªbCÀÙ‘Pý\rËÿñfóªÙL[1Ë@í×õˆL
+Æý¾> X¿ ãŒ0ÛÙêpµ~è~ñnrÆÀf·*zW–Wµ8ÁˆåX“7`i
vXìq|¹*ÚÓÝ;É}…ºÛKå×B@ÅSCÂHØjIúœº3NøÎOm‡êuHÎ&¯õHì{ÃNIv-%ó2þb*BÁÁˆµ.Ú¿ÉË(-0ÆÃ.™
bÉJßÒú×קínjiF^Aƒ½x”®8¤á-	…Ž!
`ܯ¥	LÑËëû.íS@&Ÿ$ 1~G„¡é!nó[‡:sHæÏÄzŠê÷ ÜPÒõöoaÇ"Û£]¡{;XÎ	Fb
úzÛçŽw¯ëö‚ôƒ
¹’Ey­
+v{Â~[ Y퉷kë[ÊF.Ëë®R2:|µ&˶ù&~t±³íšá–kAYÆ-Ò’Qíç^Ü—³AÆPR˜R†ŸAÅ%®’+Âã9ÔR´¹«{ Ó’!ŒUW2i÷ø¹ó›
oO7BÁ._«¬ëyŠ
D(aá]k~®u–	®Ý‘»ÌF%ïýÐ×ÙÐdf»qÅ£ˆ=#ã j)Š¸)…ào}Ú|(¤»ó$5÷)ê:×eÝ–\KÒ|ý`S';ZU©ÜóÑâs—5žm¤_|à»Ïö˜iJTR#ŠéFeðnH©á$uv•Íž"¢òÌŽà–'	ýÛ³&B#çS5ïg#Ö´¤ñÖñ?œa™C‚a?|¸ügz|8xÉãÅ1Ž2,ëÐœ^ˆeQ–ÂDi«ÿªè¬0½¿8ÿ÷„ ÃD‡Ž-…6Lj@t}…xO{=œéª3ñSÒ¿€u÷Õ4¼”UÆÓ'¾zlaË®ÃàvÙŠ`GÒœW^Ã#"©´5ëSèË$ÝÌ9ôÁéžpß~dêúý0Þ‚}$d_ÆJÙ˲Ën
+Ÿü._¯	7#° ôcö›ÐB¥×¢fÜÈ=°ŽÏÚÜÙê?½zêý0íCÊ‘!´æûtÍç«1žu?K+.®o–/þRi†-zSÇ6ÊüdrhŽtFš(eL³‚/umDðN”Vï}º3,RÖŽXí;m?´oZ92íã“Á‚?†}æ]*ý|ðÊI¡¯W•’­Ké6¤,È5ßsx˜ ™ßV$$öøu"ÛºîŒw£¸ÔfÚÏëö-´*MŒ¹ŸtùÞ÷š^þò9CËt¼Ìþp€ŠÚ}{¯Ò¶>ÍëýH/[óÕFI=`k9!«n¨«Š.ôÊ$s(­y4ùrðÙâV€ªáÝ·Šm.ÛŠ}Ö/¸°•åoâä£h!ðv\wþó.¡}Ó‘R#îÌÝjœeÚ5¦.)þ0—Œ¥SMœgcE²MÑ¡ç÷Öb3Ší±ªì§Eºý3¼8ÝFа)hÜ”äŒ=¸—"ëë]l䳃!Zj»©n<%Lèl›œÿËÚÿ'ø‚ÀÂt::]ìÐþ«£–xendstream
 endobj
-962 0 obj <<
+967 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 34
 /LastChar 122
-/Widths 1937 0 R
-/BaseFont /VYFYRB+NimbusMonL-ReguObli
-/FontDescriptor 960 0 R
+/Widths 1949 0 R
+/BaseFont /UJMFYR+NimbusMonL-ReguObli
+/FontDescriptor 965 0 R
 >> endobj
-960 0 obj <<
+965 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /VYFYRB+NimbusMonL-ReguObli
+/FontName /UJMFYR+NimbusMonL-ReguObli
 /ItalicAngle -12
 /StemV 43
 /XHeight 426
 /FontBBox [-61 -237 774 811]
 /Flags 4
 /CharSet (/quotedbl/numbersign/parenleft/parenright/plus/hyphen/period/colon/B/C/D/F/N/O/R/T/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z)
-/FontFile 961 0 R
+/FontFile 966 0 R
 >> endobj
-1937 0 obj
+1949 0 obj
 [600 600 0 0 0 0 600 600 0 600 0 600 600 0 0 0 0 0 0 0 0 0 0 0 600 0 0 0 0 0 0 0 600 600 600 0 600 0 0 0 0 0 0 0 600 600 0 0 600 0 600 0 0 0 0 0 0 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
 endobj
-884 0 obj <<
+889 0 obj <<
 /Length1 1606
 /Length2 16371
 /Length3 532
@@ -8909,7 +8974,7 @@ endobj
 stream
 xÚ¬¸c”å_“%œ¶í¼iÛª´mÛ¶³Ò6+mÛÎJÛ¶ÍJ[oýŸgº{V¿ói¦?ܵ~'"ÎŽ±ãœuÖ%#RP¦4±72³·s¡c¢gäÈYÚ¹:ËÚÛÉÐ	ÙÛ˜þÙ`ÈÈ„L
],ííD]L¹ê¦&Sc33€‰‹‹† lïàédiná TUR§¢¡¡ý/Ë?!#ÏÿðüÝélin ÿûáfjcï`kjçòâÿz£²©)ÀÅÂ`fic
 –WД”PŠË©ÄMíLm
-®F6–ÆKcS;gS*€™½Àæ߀±½‰å?¥9ÓÿÅtœL-ÿn3õ06uøÇEp0u²µtvþû
°t˜;Ú¹üí‹=ÀÒÎØÆÕäíföÿ"äàdÿ7Âö¯ï/˜‚½³‹³±“¥ƒàoV±ót±0tù'·³å_7ÀÞìo¤‰½±ë?%ýË÷æ¯×ÅÐÒÎàbêáòO.#S€‰¥³ƒ¡çßÜÁœ,ÿEÃÕÙÒÎü¿ÐœLÍ
LlLÿÂüÅþ§;ÿU'à«ÞÐÁÁÆó_»íÿõŸ,]œMmÌèa˜˜ÿæ4vù›ÛÜÒ†áŸA‘´3³01þÛnâêð>7S§5ˆòŸ™¡úKÂÐÄÞÎÆ`bjà gïò7%€òÿNeúÿ9‘ÿ$þøDÞÿ7qÿ»FÿÛ!þ=ÏÿZÌÕÆFÎÐöïüû‚ü½aì2€î˜ÿ_¬¡­¥çÿ!ú¿ª›þ›áÿ	DÒÅðoíÌÿJÁHÏøo£¥³˜¥‡©‰‚¥‹±ÀÌÐæoþeWµ31u²±´3ý«å¿Ú cbdüo>Kck»šÎöo—©ÉgþWžñfPÒ–—§ùï·é¿¢þªî¢âéð—ØÿªCÖÞä?ÿ`	Ù{¼éXYtÌœvN&'ÓÏÿC¶Á0ý×ZÖÐÅÉÒ ý·dF¦þ¿~ÿµÒýo0¢vÆö&ÿL‰²‹¡ÉßÁúOÃ?ncW'§¿zþë¬ÿ-ø?ÖÿqSSSc˜µe{cž`«´Ìt—:ÌÜáIíþ^&Ðá‡ÒF•¢ÿû¿´ð]®JƒÚú¦iî¯vÏ¥s‡ÏC)ê£Ñ^Šž_¦òñ~’Põ o‘wrÐ2è•Â§_¨G{_/Êì€i±3ªíM**é•|@àOw²8A]?Sù“¸ø£‘>9 ø§6Ä¡w!5¡Ôž_'>?QŽõÜ‚÷âÒäÄA“ñ¸Á“Gù;æàòk©VzGP/gŒOÚ`\0š÷Kr>`°o„3…ólU»ÿüƒyw*¯;b¯8LäziíäØ—4×ë3˜Ø¹ÐdFþ›è®ºóM<éÚUê\oé”Ï#/
Îl¹n8FÒ-"&»//Øfàä)†w·tIHb"”)èwàu„ÜgV²Ú™ƒ*¥
šìy#E¤Û7R$Ïî¾t®ª_ô°e¨lYèu>.Kg¡±DæçÈéóxe>[·ÝAêä¸ôž_%]âªîCOÁA¢]G1ÂJêÔÇ<ʾÝÇ/F‹#J5‡¼@S=ó#nÚ¨º†¦@å4з='ÉKÞµ%`©H8»hWå÷ÅùQÙæaxìr‚TkÙÍy7Žy)oö‚¾Öë˜êÿ°´«sÓc¶wúü8ü
+®F6–ÆKcS;gS*€™½Àæ߀±½‰å?¥9ÓÿÅtœL-ÿn3õ06uøÇEp0u²µtvþû
°t˜;Ú¹üí‹=ÀÒÎØÆÕäíföÿ"äàdÿ7Âö¯ï/˜‚½³‹³±“¥ƒàoV±ót±0tù'·³å_7ÀÞìo¤‰½±ë?%ýË÷æ¯×ÅÐÒÎàbêáòO.#S€‰¥³ƒ¡çßÜÁœ,ÿEÃÕÙÒÎü¿ÐœLÍ
LlLÿÂüÅþ§;ÿU'à«ÞÐÁÁÆó_»íÿõŸ,]œMmÌèa˜˜ÿæ4vù›ÛÜÒ†áŸA‘´3³01þÛnâêð>7S§5ˆòŸ™¡úKÂÐÄÞÎÆ`bjà gïò7%€òÿNeúÿ9‘ÿ$þøDÞÿ7qÿ»FÿÛ!þ=ÏÿZÌÕÆFÎÐöïüû‚ü½aì2€î˜ÿ_¬¡­¥çÿ!ú¿ª›þ›áÿ	DÒÅðoíÌÿJÁHÏøo£¥³˜¥‡©‰‚¥‹±ÀÌÐæoþeWµ31u²±´3ý«å¿Ú cbdüo>Kck»šÎöo—©ÉgþWžñf“’”¤ùï·é¿¢þªî¢âéð—ØÿªCÖÞä?ÿ`	Ù{¼éXYtÌœvN&'ÓÏÿC¶Á0ý×ZÖÐÅÉÒ ý·dF¦þ¿~ÿµÒýo0¢vÆö&ÿL‰²‹¡ÉßÁúOÃ?ncW'§¿zþë¬ÿ-ø?ÖÿqSSSc˜µe{cž`«´Ìt—:ÌÜáIíþ^&Ðá‡ÒF•¢ÿû¿´ð]®JƒÚú¦iî¯vÏ¥s‡ÏC)ê£Ñ^Šž_¦òñ~’Põ o‘wrÐ2è•Â§_¨G{_/Êì€i±3ªíM**é•|@àOw²8A]?Sù“¸ø£‘>9 ø§6Ä¡w!5¡Ôž_'>?QŽõÜ‚÷âÒäÄA“ñ¸Á“Gù;æàòk©VzGP/gŒOÚ`\0š÷Kr>`°o„3…ólU»ÿüƒyw*¯;b¯8LäziíäØ—4×ë3˜Ø¹ÐdFþ›è®ºóM<éÚUê\oé”Ï#/
Îl¹n8FÒ-"&»//Øfàä)†w·tIHb"”)èwàu„ÜgV²Ú™ƒ*¥
šìy#E¤Û7R$Ïî¾t®ª_ô°e¨lYèu>.Kg¡±DæçÈéóxe>[·ÝAêä¸ôž_%]âªîCOÁA¢]G1ÂJêÔÇ<ʾÝÇ/F‹#J5‡¼@S=ó#nÚ¨º†¦@å4з='ÉKÞµ%`©H8»hWå÷ÅùQÙæaxìr‚TkÙÍy7Žy)oö‚¾Öë˜êÿ°´«sÓc¶wúü8ü
 …$ØVW˃÷æ¹)Àõá}@Jš2»œœ$~P–D™ˆ‡…:Nq©ó#5ßì"	󧈼ˆÎQ僶J–©Èµôc“Êç؉/Wñýê›X²˜HO÷|¬®-“[ÿƒn2ç¡‚÷`ŒàõÉùKH}&¢~t–ßêÆ“-µZ•÷ÎäÒàMV]ÓYÚñ‰‘06Îó'ˬy?‚²9¼oºÝ²Ï—YzÉA€&s5õC`ýnXÙ°ðõɃ
í’D,÷gÚUÑ{MX8“Ž_ZœìÊø)“bzlS âz/ˆPr m¤–ÕýŒø86
]¬
 +½ÄGL~Ö§æ0GW˜RS4Œ–¢V˜,ŠÈZzU¨âè(ŠcÆÀXÙˆ-jà±*ç+êJ"ÈhZåðIƒ ïŒ
œƒŠñ]Ñîç/µÜhà÷ šEh3ŸiqÌVHXn´Nx-ÿQ9ƒ]ne£(‰ßU;aXSû¦Ÿæ¿rçG.môú¥»ÁÊ|a™â¡^>#þ»ˆ^驵]M»qÁO>Z6Úl ¯=µ)¢_¬¾rÔ—!U;:±å$z2»?Ô?÷,|gP¨Ö:`ÌG*p²Sí»Ï³œ.ÞJ;"8çÉK­ñs·Ìúe”%±¶ Ü-.EÊ’JÿLئh·ý,hïY«M÷s<ùi“©Ò£úþÕ›j2žE)mœÀî;Ÿ¡å×)× ÄãÜùšë_`Âý܃4¨G³0 œ{¢zÀñ®yÑ C‰ÁŸèP!“2Ž¨Ÿ*§_‹Z夻'ªá¯›ò
=2ç#µõ-»Œ(…’jáô˜iÜS$JbðuÓmË~~*öÓØ	q¦©ãÇ\EʧÉi"—ÌIG(ANë&ò²z.…ôû½S0ûÁÜ	^2¡2.|,†Î”HøF°ˆ‰DºFjEàÃì´791-ß¼vÝÜãßá‚3 bõȨÂ;÷Sù¥ŽpD:••û1ºµ	÷N¡¯Âv¿•€»‡ßЋ“f¢
 éèóQ.ž¾,Èv‹®Ç'Ÿ¤Îûz5+Éí.þÇÌHF.'_6®DWeN‡´¦j×I*92RÖ¾Ø.}ùÚu¯c†ß±©ŸoL¼`Åa\¯²ZÕãLƒÒË+-(þÍHUëO˵Íè|ºZÖe±šÜ.¢{sN"p6¨Wvg‘¨ÚTzVóeÿºŠÉßDbþ}fìkGa<ÊaÆ#sSs&ÓçQ‹Ö:“m€¦ý)®ý]ѺΈ¼ÂP€œ_—ÁJîY*ùEÇd@–NËoÀ*EëgšþÐ*Eì/5³jð»|ªPu?
<º…ÖË´u½²óÁјq½7Ú»ÝÎꀻüu-1ožÉΤåAúE¨÷ŸÚs,ªî_àboîT°q
ÏŠö‰Ï`ˆÇÉ•ž™î*å#çu=X„<ð0¾L…Çýü=ÊÔÛ`’õ’WVà´“ÁŠ™íGIòêY“ÚÎÝ&•>6è¾ä$‰N©Å¥`4E¾¥[?™…ŸŒ"STï,R2.
ħböMÒÓ£ªZàÉÃ9/	e”õ[ªgð/
@@ -8975,153 +9040,145 @@ r_
 WBˆuÀB="÷Mª†ß|j¤E˜&µ»“=W¸õNtéÁ¶5dPGŽj¿wj‡Sy®¾"‘Ê UW#¡4‚0‡©¸¿ô3‚´RÅÒ]ʽM§ù
Z–T‹0ž0Å•$í£[É‹Ícãu1ÞeEpv¡„(©šóˆí濸A·Â’ò·äûtô±(s¦“Fi2Åx\èE(×(9Å?UËÇ|O½¤2o{¸¯}a£ˆ²zŸ–δ€R"ô¥²¶‡ÀØßš)ë*m ôDs§úä}á·D
 À€èö}»!Xö&#’Qƒ÷ÄQo”Cþ¸G
FòñͳH³3ànGZ(ÎF_¯AYÔ%õˆøcŸ=ß0ßpMv¨ú¶Lbã1†ŽêÁ³†L	*öVt°Áëh-½m—œ(<ÊxSæN£X»œ$ÚÛع4›ŒbŸ…±´þÂÞ±Üã‹eõ”~ð^•ËÄ·¹©ëPXƼŒð;ö2nµ *’ç#i¥¥ÈÇNÚÝü…+3÷3ÌÌ^ët]XW¨²¸DLèi[Ó8OÛþ>M6¬˜NJ3ÆzU1nç€6QÐ19‹—Û¥ŒPÖáZvõ'P¶—YãšUrAIîžÅÅ€1›MejùzV+ÕÖù7¤¯¼/E^;æ{/ZÀHgâ×j\œÿ+jÚ¹U7ÿ1œ6Þõ‡cuªæ®öèT8ÀõÅXý]¿0Ô¦‹Y‡½ZybÅvë$n§ýõ£±#ù2 [*ÃwÅYårÄ9V@»”d5ÙKˆÙ"ûº°yóv	ƒ®'XiH!ó á3wIykÿ#J÷lÒ<¦s(sUø®û¤Tð|á:/pœs§Ô ëP’–<ˆrÞbL|}ä’0ω´üûÿÛÏgÌ_ögk=úÚú¥¯®®‚_{íÜíÿíü®Ò§à1ñƽœ[.I$Þhè
 ¶Ù½äÝîØðmŽR/´Ï8e°ûœ“|ñîëszC<’^'¬üš~xõ¹l­SÒ|úcä',ü~Ç+L`áƒm¡à¸Ô›;ΘÍfyüØbÏþ9%¼Wû^š¦ù¬ãFáuž©ªcMŸîVÿšW:áõdÝÂ}L“âÝK?ϼ|BóÂú–UvÞ•‹w|›&óyvÓê—šß²CÙvOË*|ð(-´zé>û‚Û\y–'$*·ñóÓÌ¿åÌoßoßîËÇ6Éý¯ÝI)–ö÷]³=ž+·ô»@siÿ–R¿‹Âs2š5ª¹rwö¤˜q	-¨
-¸wëB€tIÉ>NÖÃïÚ&ÇÚ4ä†11>Ú"³OzÓúv«_§ö°÷ßâW3ïý¿”é–7Òv(/z¼`ÖrËm_姷´—+vÙW²ÅÔfîK0庡û×2,¾ÝÜùÞºsÞÙÕ÷ïíK;b÷Ž9]„m/—èϵÏê7~ùp&,kÚÖŽ óKâ>„(vú^K¿{uYMd«WT~Ë5Û/Í}(ïÜnXªÃYÖðíÆ™þÙ®%|´<þ¯ÁuJx´nÎÖ×Þqr%M=6åŠÚ3ÆY·=4k<±;äã­ÿ]ßµâÜÙ“ŽI¢Éÿ­C—̈0Ø¢•–óñ‹õáü.Óëœùv%ÍÙÐ8³÷ eYU›ï&™·µg#žÝò¾ËuÉ5€Ã¤QÝ€BÀ5jÀ°0 9'5±¨$?7±(›uxÎendstream
+¸wëB€tIÉ>NÖÃïÚ&ÇÚ4ä†11>Ú"³OzÓúv«_§ö°÷ßâW3ïý¿”é–7Òv(/z¼`ÖrËm_姷´—+vÙW²ÅÔfîK0庡û×2,¾ÝÜùÞºsÞÙÕ÷ïíK;b÷Ž9]„m/—èϵÏê7~ùp&,kÚÖŽ óKâ>„(vú^K¿{uYMd«WT~Ë5Û/Í}(ïÜnXªÃYÖðíÆ™þÙ®%|´<þ¯ÁuJx´nÎÖ×Þqr%M=6åŠÚ3ÆY·=4k<±;äã­ÿ]ßµâÜÙ“ŽI¢Éÿ­C—̈0Ø¢•–óñ‹õáü.Óëœùv%ÍÙÐ8³÷ eYU›ï&™·µg#žÝò¾ËuÉ5€Ã¤QÝ€BÀ5jÀ°0 9'5±¨$?7±(›k,x­endstream
 endobj
-885 0 obj <<
+890 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 34
 /LastChar 125
-/Widths 1938 0 R
-/BaseFont /TBYCOO+NimbusMonL-Bold
-/FontDescriptor 883 0 R
+/Widths 1950 0 R
+/BaseFont /NLBIIA+NimbusMonL-Bold
+/FontDescriptor 888 0 R
 >> endobj
-883 0 obj <<
+888 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /TBYCOO+NimbusMonL-Bold
+/FontName /NLBIIA+NimbusMonL-Bold
 /ItalicAngle 0
 /StemV 101
 /XHeight 439
 /FontBBox [-43 -278 681 871]
 /Flags 4
 /CharSet (/quotedbl/numbersign/plus/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/semicolon/equal/A/B/D/E/F/G/H/K/M/N/O/R/S/T/W/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 884 0 R
+/FontFile 889 0 R
 >> endobj
-1938 0 obj
+1950 0 obj
 [600 600 0 0 0 0 0 0 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 0 0 600 0 600 0 0 0 600 600 0 600 600 600 600 600 0 0 600 0 600 600 600 0 0 600 600 600 0 0 600 0 0 600 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
 endobj
-878 0 obj <<
+883 0 obj <<
 /Length1 1620
 /Length2 20127
 /Length3 532
-/Length 21036     
-/Filter /FlateDecode
->>
-stream
-xÚ¬ºct¤]·.Ûv*I§cul'ÛFÅNÅFǶm۶͎í¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ú%ìí@,ŒÌ<5e
E##SK{Y)‘
௙’RÔ	h²´·3y@S€Ðð퀅›› jïàádinPÿå ¡££ÿ/Ë?.cÿ@þF:[šÛ¾þ}pÚØ;Øí@)þ¯U€@È0³´Dµ¤ä%Ô’òjI ÐéoŠ.Æ6–&YK 3`fï°ù÷`bogjùOkÎŒ¹„Fg ‰åß0 »	Ðáˆàt²µtvþû°t˜;ÙþÎd°´3±q1ý§€¿v3ûäàdÿ×Ãö/ö—LÑÞälâdéüͪ(&ñï:AF r;[þ…öf=MíM\þié_Ø_š¿(ÈÈÒκƒþÉe˜Z:;ØyüÍý—ÌÁÉò_e¸8[Ú™ÿWô' ¹‘“©
ÐÙù/Í_î¦ó_}þ—îl<þmÿ/¯ÿ¬Áä´1cD`ùö7§	èonsK;¦¶Š”™=€…ùßvS‡ÿÀ\Nÿõ?{†æoF¦öv6S “¼=èoJõÿÊŒÿs"ÿHü?"ðÿˆ¼ÿoâþwþ—Cüÿzžÿ;µ„‹¼‘-ð_A€ÿ¸c²€.K“ÿÍÝÈÖÒÆãÿðß=5€ÿ®RhîbcäôßáÓÛ™ÿU„›‘ýßVKg	Kw ©¢%ÈÄ`fdówVÿ²«Ù™l,í€5ý×8,ÌÌÿ
Sµ°4±¶ûgøìÿ†€v¦ÿ½ü¿2ý«x¦ïÚÚÚÒòtÿû½ú/?Å¿úƒT=€€ÿ?‰†œ½é.þa±wx1°p2X™Ùÿ»¿›Åçÿñ_D,ÿµ–39Yºt˜™™Y¿ÿãó_+½ÿF#ngboúÏŽQÙ™þÝdÿiø6qqrú«í¿Îýߦÿcý¯íºMÖWìMxƒ­Ò2ÓAu¸¹#Sb:},#?JU‹
-ükì{ýÒÂv¹+
?j06Íðün÷X>wø<”¦=ëñ¡êM^çùPÐô o}íä¤;
-dÒ/EN¿ÐˆòºY’ÝÒæ`V?Ú›RRÖ/ù€!žédu‚»y¦ñ§p-ðÇúòä€âk’Ú‹Ý…Ö†QWx~ñ5ñôù‰jh|td¸÷ºÿ.'ž’×
-ùk¤¿c¡ ¶Z…xUó«óö”ê&BÏØ>Ÿ¿ù‡PvE‘妷‚ïÕàO͘ƒá†Àl¬„ÔÈW"æþx² 
ãŽïIx%Q¼Kâf†Îo¿møWcwúŸò‚‘ßÄÎ׊ü;L§Ö‘;æT°£6®ãGvíÌÓ.õ=n¾Õ.7èX¬JÌ[ÃZUýùbªÜÁ+_®›xF»-b¨À(¥ã©ƒw¸ÜÄ$ÌÓ…
(_,Ó	¡Ã4ŒS4r-Ù“©¾ˆ3‚2Ž‰ŒŽ$¿ d­ô“„}¼Dä9%G¹<á¬;Ö6®£ÛA‘œ´Øpÿ(wßöìWŸ.S?62=ú0z‘ßãš@΀ƒëì˜ç3¹>9È%æÒðOÞ`zŒ—6"Aïܪ“³ÖSªÒ¼qRÉŒ!ÝMë–›Å/˜6 pöpò>ÙOBˆÁrêO<õlb­‚‡ˆà\jÑhŽ!··qè™•íº”…u=5±—ª——‡³ŸG¿:×KÎ{òɵÅéKœJC·ÒBµ¾/)qpgŸ”­µí‚ ¨•ŠgœuºœÚ]_ÕÞ´c¸Cûô¿Y‹ü	n¿3ÇaÉ»ðSr°Ñœ¨t3ýW	å
-o(:¨Ñ_‚å¤ñOFõØI)Q’l¤®‰Í;TÜ*kÀ2ñ´Ò(ÏË2+­Õ»ÐÝé¾›äAM¾×Q­?A"tto¯$ÏÊAœÇ;tÎB¾ã¢ü1jþUxq¨eÓÒäþtþcÉTI€3!š@X芆eÎ^í'a‚†:U+“òÀÅ$˜ ‹EÕùƨÉMæ[¡'ûnŒ‘µ¬æ•ÌCÁ^.í'R‰ÃÒ4†„dØh-yÅqC‹_·¹£É‘­5R^ôÑza°Òµ:zàø–AèÝgžÄP5Æ –¹x„¾SÈîÑ*¿i&2O-8(cóCݧ†l³2;.žúõC×
]zîW{r{]ÞŽQYz?4éZ_)gæ:}oãÄÒOaËa‘‰²`ü,³†ñëP¤—}SUÍç<[[Æ©ÅȦn沟„“5·³Ú’£Çô–ýõî„}ÇÐùsIŒ	|dšK®s¿aKŒ.|%€:GÉ”ÜO}©P¯z-$£×Wõý]1€´Ø.Y" T`Þ3oÞì¥>ˆ‘?­·ç?]£NA¦úAÃ"eåªÛöñ&uãµ4ØÝêçñ+)Æ/²ñßôê•ñÕ°ŠN$n›xye¾’‘–ãôœs®bŸhÁxE¹²ÀŽÀ½òÃ&ãç£ú«ò¥½Ú4¥ˆ¦ó²ªÇ!‰}IïNÍÖø­J¿È*é'ôƒßCãªÊ›vÝx Jä	Óc‰ú6¼êßs2¸µ3_„1õ4Å]°Ñ¯Sô_
-a®;?o®åü+L7O7¹uv¤ÓuÞ̸¶çŽNóæî™Éñ¢ÊÏC°¶ŠæЂÚ\„P¼®ˆ™ß¢’1âÊ¢Þ zO&É·c튩È—©7•Á¼G}Žúäñʬ!FŠd1‚_mÅ€th¬×Ÿ2°?X¶'9­1îî»(RŒæËÜF1”P (Ê·úí¼eôðÛgã‘Ûˆ}­H}öE÷2OöÑgí
-‚7I•{œP¾©3½¥Œ/Ä[Ö[ªp«Cƒ’½f±cB8|*×vÞ’(2M´:G‹çeƒÀü‘H7þ5'is=½ó{LXwÜëiì>Aº„ï=Ëo?F—Aµb©ÜħcL·¼ž…×›ÂY_‰g Ï¿¦©èe‘O5ÙÀܧâí/96]d±ÊPàH]~+B†<Ô•R–…€õ\ͯ©sðÑþrOŒ…[’½¸m+þ¶ø¶ý©>þ½ØRkn„´VÁÁE.ÉYSssF‘kÿ©Tââ.ŸŸ3hÈŽxÒµ¦ö–Ñ9õd¨HÎ6Šõ‹g :M6:mÇÉ£X€ÓIQ² þJ7»õÏ|³ý—9wŽ>«ža^\ƒlEuѺ…ùŸ“Y§7
-á]ô
-ØI:ý}Ÿð…îŒr\Òv-`÷’¶­»j³œ³·í}
-]rSÓ|¬U]Iƒsuoé$½9¢c÷U¹“äx°Ð¶¾Ø¤Û‹«bÜIÅQ¶?³…á6.S¼à‡n|ÑG{×BõwK¢»™(‡§òq°4Nqéåé»iÁ;í¶¹öU‘PÈœ¯æxÊ&ô•¤1S¶2ó¥w\·+zê›DJ´v¸$ÌLßòÈîk>^µ².L±¿²!ð4^¸“PÔ¿¦.¬äïŸ(¿'Ú¶£Pb¥i‘÷êzÝûDUoÀõQ
-0E†IÃZ^ŠÿŽ¦Ö‚0›2%“ýJ§^ˆVÄÉk"y
-4ÑÃ¥Ë2š=¥«UkW3G­{—ð̪K¦¾(ÞØ–WŽÓÓüý®9’ã‘<džâö—ŠäÓ^Rƒÿ°PŠÊ·Zl—›Tj­5¾9.¢"¥³f>89ùIÆvp3Ýé9çáCDq
	€¯¹/W4=¹¶dopso´‘‡À1¶¬´’møÚÉ6]ó|"쮘V»ÃJhO5‚°2Ó˱‡7Nß¼hC;—ŠZÒ›„ä?%	¼]ùc¤½¼qÈ	ë#h¹ilÀ²ô²XØæþ鞧äÓ%ùµ¢(eqB•çPÁì=Ý„ÜÁ9â‡Áœ%J
œîNRCèIªÍëKDQZ³Å u¥‡HÓ£zì¥üï3òt®§,P3Žü:]šÙâëIcª¿W±ÏzA~Þ CzzÎñ0¢®4 p~\+üø0¹ÿq}ñ~}é
-®@ê#^>«\×Ȳp‹Ç*,	A_ÓðtÅ
âqÙb1?&}=Ä2ãÒ]óð€ÆžoÑG¡PL.]Bª¢E3ý7z®Æn¸c<®žepNwd¶\ñú"¯kÑ;ïX¨‹ЀBgN}®²ûàóÃÌòhkrŸÀ¶Gâ{°l:&j‘ñ™û
^òÕPkNÉ«±LÖñü«DÙj‹+Y9‚dÌœòÖ„Ê—6<€ôVcŠ§‹Íš‘Ýþ³¥SÕsiÚÚ¤Ûò>vü[Âë^‚*žÝ½žVgªT=gêï@!»c)ƒ±FÀh…´1l-òZ±9±lH@±Ä˜¬_×m¦ŠæiwÖJ|¡ÔÆÉ’¹Æ¾x9›.šþÄ7oˆe!£cз¥Ý†B߬SÖûÄñ¹eéx­Ì-	lnœk
-Ð"$©p@zŸÖÐGƒ›‚·^_fñžtDPiÂñøËɘ.yÖÆÐó†·ÅDã^!¡¥ 1âóÜ,óšªiÖc.â4£÷LÛ}cN6\ÈÛÐC•Å?ÐÖÔØ5÷Ü tbgipO
‹¹shÛtƒt{J'uYÌ„ÕÑ’Z6è¬wßù/NÐÈy0¬Ö‚;g‹ÖZ0….R;
-*Èí­´âT¸žfWÓ3Õ'7)ÔYß=á!`ƒSé‰7ˆv¤U¿È!~{£Ø1Çœj÷àºßŨžG]¬ßg•,½[
W,{ukRÿÔj•Å‚èÒ<’…æp_íÖ©ÛRV·((þ22ߊvóÇÝl.ˆÏÜs/¬U¡¥&‚ko¾÷ñ@ÆÇÊ5V…jj¬a
`N}ÕÆêŽáOúŠž&#÷¦ÀuÓÛW™{päc³	<4Éó“¼£Ò7J}GáæÁ†TË$äðÓ01Kp"¨?¶Qø¤ô4d¿x}Ks¯c* ìh÷§‘Îþ#XiuÁ7nêîØŸÕ©è|ÓD†3¶•ƒ´QŠÞTGøÐæE®Í¯mÂæ°!ÀbXÉ´2–·±R›?hÝÜö=m¸7ë6†ˆ¹o'“ðlø¥gàëè”ÎözÊ8‚lL >Å\¥*ÁŽéѾß1‰àÚ¶"NÄÈU¶¡yÞ"åe/½üõ´9ÆhÓ¶ñ3+ÞÁÊ+3–”RÚí4p±}µ^säwö&òGN^9×t§Îíd÷âË÷‡y|ܨhͪ“m	ÛøŠY‘*gSÆŒ÷lZ1S™çÛà®2j™çꕧp„Nݽ™_î¿9™åÚ‘±£üŒ$4W‚ÒÜkߤ¾Zì`•@BñãjO®õVa’tÂI¡„[Lì$U	;"”¿¹B)Üþ”ÿpª²ïèîÈé~Øî dxpv’K#	AWE•\åuºïoŒwoϳˆ?‹]ÿyž½E™À·ÁÑRY£_ Ÿ4¢àÏ7©£•#eà«È¾oŽdÞh=g!…£0’H¿œ…lÖ)|ÿPíCð©ß£ÅOÄ…3íá±YQ¡›}ÜêëÏ
-–ÙýÉvuöù‹ª¥'NP˜eÏ ±è,aè™nµždØ
±Ð	dLÊ|tHo­œ„™—°Þ‰#ü]ËÕ2‰í8é”=lÎMK¾ü)Z­}Ù¼WÆYXõÞáŒK8~ÙÏ\F†='h¥‡;ùk/E7’r×y'4xözUZj
-SèÇ´FÞ¦…ÛÏΚ13±©É'æztƒÞm~ ¹Hº&¶Ñ~ñÍhŸŠpu¢h^Âc0xÆ(ë7\×[:‹¶q¢Íš-µj“’"z¾r§YJ÷-Ù6ÔïnnÔãõÍÌI·n ïS7ýö4¦¦ì¾•ôÈ@؈F9x&«sî|×`pu¡eF`{i~¶ÙƒË!$jmJt†œ/üaâ\èÎÅNià"û*±z˜Ãt3¬Gs€µ/Yn ~³1&¾âÆ0tYœVáqð(ê™w†—V†Ÿ÷ :·ÉóÇotxøí…*˜®ñ§õ‘á#Ms9½C¨9ðtIL³òXˆ×íŠçÝ€îWÞ«Ê.­’Âå݇Ӝ,7§©Ù7‚ÆQƒÄéèd`³Ú³“t÷¾k
œM÷ûx}Pïïo\5Ö÷ôC§Ÿ®Z*ïÏkm Rã̽oÙ°?1DêñeÄ'ŸÆ à6…©jb6LÒë¦Xšá|—?÷tKÒ:6™Ëühï;¬p€Gˆ*z µ-Ox—oÂܽš°¶çÈÝÔÆ	Ñb„,I­£±½é¸NiÉõÇ{^èd–PL[‘îc±Ø™Q¯dZÃÙ&ËŽA¯î/Ú;!òùpÁBßÙsÝO‘΃3ײ³2¨%ÖuzøÄ[cé‘Ù§‰ÂïŠRfUÔgçúW·­ºì;§Øø8ÍLŠ¨ék˜"­¢¬tµ2¹ešòK¬ Á¾9c$rMe©€€Ô˜6T¡Ð‘1­QçTè{O–ÅË]Ñ’f³ÕÓ9-©þR[0£Nk¾·ýµ„ŽÏߨNïçÂ"?Gw~\“¬…XH”ã\lã¼Å_¡’”*GwQQBÁ9+§ªÁ¤Â¥à(-n›_Òx3“mì‚gU‘wµéíâߪv6ºÈ¯pÓ[óæ¢I´2Ö6ß ‡×ÇëŸíIGûƒ—e<ªð1}xçªÀéž~ôá*@O€ô…¹É¶s—ê>‡Ú{#ØËz߈¹ç!žå<×Ó‹¦g=‘ÑGHö'²Ôe	ȱóŽõµ“:…Ÿ‚ëR,q@õû´ùüqhŽN\VeÆdh„ɘB™Ám*QZ!cJeåMj…Ïòá#éå8;¡H‚W¤ÃÉ¡Ûσy¿È§éÑÉq¸ÂÉOÀ¦$*¼”Ö”¿þCŽ¡ß—(]b]uHíØ;¦Ý§ÇÉE‚þK±ÛH]ØX‘IïifËS2phz¾‚ßA‡œóÖ	tÝب8ŒÙ„ljÏþqË»
*Ø‘Eæ6óø8¥”JçÂ?Kî7ß¾õ)NÏT‰"¨VÔÏL>+ö€Ã¥˜Ìþ†e-mί`$T^ÅìE¢¶p&¤91fXhýüúQó¸kc\#BÐ×îû&“ª~ö¼þ,tí]ª•wÄ1y¸ÒÍÕ:…AuÌÇ× ß2ó=—ûéÂ0ƒzV7P¦©O>©¡‘*‰B4ô¼&3ÖàïD×—–™iWí¿U+L´œ±§f¿Z=BB£¡s1ÛðþXÄòj€Y²÷¨isæ/æ
-¾zT…¢gôOÿ’‹Óo0-šÎ०²Š˜hÈ›9ÉÈ%m-ÜC7‚µ$©OãzAp9%mëƒf7ìÄîâºÞNÍíOKB¯Wˆà/°´e¡ìÔáo~f›]{ˆðEŠ˜*ƒûN·G®²ÎÏ«Eô[‡ðQðu1ªÑÃ(X²ÁZû¨Âx5¤ 6™œ¹¯$ß's.1߬)Ç^r‘au5nUG‘áŸÕÔ÷TÁzÀ½¦¬ÜÌ
léLdi\”aÐZj(ô ¬õ\œñ,ôS–W2ƒo³‡CÜ`e­æí㦃F$êuÆz{†ÂÎK!K#$
-bÉbðúuÙ9ðeÞWsS†ÚINñ­E$ŒcD3>ä:ÝÔ%žÐçIr<Û½;åµV}$1â°ðô£õmõ“¶)L£BòùP-PîÀ™ÑD|=ÜF—dã;õ…R^jºßsÒcþRÖ'šîϳH¥¹¼+jìF+ò˜ªB~ÈCgÙ5ûë	€UÓ(6û˜Ý#̼vÀ£Äòq¥þ…äž“ZrtjŠoe|‚+ gÈb
ÇXxÞÈÍGŸÆÜ/bøc§èüv+ø²òkbˆ BFÛ;l'a¡|E]éü×6téC¿×0q‚M™±I0êÇ`ÇsZ+£.ÌgŠÊ)ùcs³½-ãVé¨Ý³·††²¼&D̘ô”@¶Ý”ï³Oœöø]¥ÿ]ƒÒ˜,±Î
-qœp¨FÿØ°ºyóë+45Ä	â$½IWªÛo6sµPW‚Rýyª Ùéé8Mâ-lvrΨ$–³ÔÒ+ìLå×tåý‰c8¥nHÂÙ¼@Ò+iÚèÜHÔ‹¤³!«¸Çqz{­Æ{¤lï
-Çp\=Nü¬4··
-d;uÌ’‘ÜsÛ„÷_]e pxßÁÀ:Ïhâî|k±·¾ö'nTdÇ2å2fu·0¼e}XÇc*IÃoô}xFe6;acÑÈîXúúË¥áær,–êœh¤/º9;`©®GÅ–°
,ÓH>%Oà"û|?éJ3iὓQ!Efb«èDCõñd±Mðhˆ–Xµæϸ­6ô#ñ†l»È…±ûsLóæßgél;µñÌ#%
-‘¼GøCAÌÑð}¾€¶6Ç¢³V»þ\ƒ	diKB´«ÙQïè.§~Þ‚´ÈÌ=ìäm’yS$ý-Ñ¥ªŽ¹P‚´)keÅÓnM¡Gã¶Ëu·5%¬_ØEçMŠKÒcƒ†Œ8î5€Ã|5wìóµ Ô"öů£„²3ÇŸ³’œVÉ÷
-žóø.Ѩ\éd¥(š˜>¯–LãPÚ Ôš3,¿Ô16še¬»Û²˜BG»OåÜÏænPƵW‚®eoÁP×½'”@çßÒKLýº-/ÞJ[ýŒxw]öG8förˆVƒÉsvÄþh;Ìšé£HÛFÏæ8w&_a†¶j¡ã÷q´r©Ý}~9ÃQ‡³¹ÃñQËöš‚¸¸ÅÒRŸv7Ý/샃ð+B­gN2ãâjÒz	ÂE‡`õfQ•8{ÆÁ9û»¨½qN5mc¯
gÀ<Åj½`ž@.vS;눂DÊknDÔš™˜±ºOZÖµÜÑ–HJ”ää&¶[óX=
-<ÊîòÈYŸ­ØìZ
Ê£÷íé™ùÈTxÇSêhD¯Óe{Ð’ÖMÂÒé*’­D#ôTtهͼÔ<~WêšÏ¯,Äѵ—úHLÆücœcyµ¼‡ÅÒîÇ<Ï	EÇvž¹tú“H;:±[æ¥@B³CoјI3åÕŽ+´s«©Æ?™À“0”VðÍíÉ ¾¹Ùìʃ¼ãAœ'7¶ÆÁ&¢GL6öÝ¥
-Õ.¹YO¬êªœ©Û×™¥
o;åE0
+P|¯î ¾§ÐIëg°¥ªÔoKýd/&úÅÌgëVÕ”ÈýÝž¯Û#tƒ#ÖÓ^3Õ%Ns“€M”’0¨éa|Ê|ɼ}FŽ%x\Ëg¹bÓõ=¼í"…sUÏâ9̯ԫ{1K¼·ÉfU¡Ï7
-ˆçŒ¼™¬ï›»E|ÜÌÐðXuãý–üÂ˨µÎ¯ˆr ‰¯ûV™ÆZùHmQE,úïïYü(³»ŽáÚš&„—§Æ…óøtk±ò•Î¢AwÅȘ)ãæ^ú¢X©EŽO™æê«ï_•Ü”p8ý°³'W#§ñ~žõœÐÙø5;<’ŠÚæ_)W›/’É\x)wüˆ5Ú²w9Öˆ.Ѫ#yÛ2gF¼_úncóAºíç)F,ó“®ûM~e9û°Nsû£f쓵5ª:PK÷ƒµTÐ9oYö	€ª}$:tñ²ld$W%‘ȳWCxHáÃEO89!×hvß3Ó(¦#gŸåÞ[Q€Ír‚Ù†4ÇcððÎ÷­ ¸ÕŠ‰„ƒ>zLár—õÜ[ùíVU§“Ž-J
×ü¢õ¾‰ÍžÞ¦Ù×(ÄmÊÚ&®ÂÝ3È£žÉÓ#â»þð%²ê&Ý7ê56qã„öcI$¶Öu ©%ŸÛ¾µÕËVP¼	Õ°ãé™ØbÕgK/4Âþ}
iÅ0|bª(çÝX#Ïï,ø;ˆxšcRÎ8Lµj!î
»óúV¥@L&K!‰]°UÄÃûщ|ævYlNæ¼aš&¤hDA—ÚýmhsäÙc€¤³W"â{Þ‰569Lí½×Ë~´œ‡ͤÆ^¡˜Ê4eU³£´EÈ“&phŒÏîù?è™X}}¥„Ù8Ãm¿b;†±ë
×ÝIÀ»[t<Ž‰à„ºêF‡ÄÜ6GbftwþžT7$–äomw|[$EV¸M—g[úyœ‘é±øí³Öƒ%Õ‚CIøÓK¥]L }²Ëp¥pCg>ƒÿ»ênøÄê=â]¤põ‚j§Çýܨ˜öÏᲨ>¦ÙU·n¤'ð«¤á{ørùuU´…¿ƒ_4,U†°;~†¼õÑlþnî/®ÂßñX¬¶úU%~¤Œå½Þ,/0БwŽQ{Ö:ÈÁת•ëf\“ï0˜ÄÜœ$e³RÔÇè<[òÂ	X•Ž+ÈÀ'Ûæ]õÛû–ªiX{sV-#ð¯ò5²´Ã+›fø*¡O‰œ~EÌkɲˆÒ¬Ã‰õ£KëUb실]ôšjù-å*bA¥ù±‚iêk$-VˆçûG"]Î[I¥7Ö5ꧮq[ßÞ­+ÍðöØ/º÷ðÕ‚úðÓ÷ì2*Hê3Œ„Ž‡Ñ|_ÞŒDªrwúi¡."§ÖîªÎÝ/`8qÄ?
-ÙòsøeìÕÙÂ1Y¤tYv~
-³L7,òH
-É_AWš…*QÙk4‹†ÊSgïë}“æý
ÝH>•b5?þ‘ÄœbÇ‘þ[½²%?QÃÔu­2NѼ5¯|F„=ktåÂnïìÈòæ‹ô'†<³Ç‡_Æn|Vœ	“mpéU÷YX ­|NHô¥kÊ rO6ágÌf¶ØlhÈb‰Šµ°DŨx`Þzù¸³/;çöyjiIšuRç®3·žÝAZøÌ*îÇý±@>Ö,cIß’íÏÈ}-åEçJ<¯µp,IÈ[\puÏ©^ÌzüQ\®‹6m¥ÈˆgðÜÍ/|gÔY¥¿×XCõɪy9m˜°·r!>Z.
-SS˜K"
-Ï~~C®x®'ñ0yÉ#ñÚºƒ.UŠq/öÑŸ˜*Îö¥ýµ4Çï`àIm­Š´¦Ç”Ní.zßF6ù‰‘¡Dž³¢,t°Í(¸™8é±%iXK{Ëlò\‘Vñ}gx7wÏbðb¬½‰jÁ½`û'üNf ÌB Ì´Ð¯1fBÈŒ+%¹7¾CäKvÇÑŽŠ¨'¶,³jvZÛÚ•¢lD¤È½Å‚…U?/rªìuGш¤59+òúøF´'Éûu£÷ÁO^C.¶ºó×?D¡ú
-Ë!«O$!*_—‘}	qufÖä­2¿ÐAQ”¤ÂâWH,‘Z8gm­ÈÞ¨gA‘¸¶vaõÈ”YÖ¹›‘k (
-á„%F<5Ÿ¼K»ç´Åö Û3Ó΄ÕÁŠÂ~çD7/âšÅ	Œˆ¼êÇ™©E½ŽîûFí3vŽ,€Pô½4zù„Pp´_-¯³÷ç Äš0XR€©A÷?Jf¾•’{ˆÏ”4ÚRØlØöI¼¿®öõ~‚É…PĦxIÝâ/B²Bü¢=¿A'öö`£H>Hßí—¶œPxáü¡ZòñLQöLVg*tç1KÆ„ºdQÁåÚ)š¸|"Í·Ä´S‘¢ì8ûgþásóÍlðAÌCÛª¤^¬IêÙ¨·m‚åi—nqúĦj¶A«"¼±ç¼{H„#þS
½ÁêSG±L8úkO{dîf°©»ìOǽÔ/˜æ•wƒðáÇ`œÉµ'j^ëåé8Sx‡±
-Ôù´6Š8ä­ÔÔs‡ÎCý—óÓ:2±èë5/•l†%†ÖhCÓ˜]¨w'hX6Í—¹Sº†U¬Òú|“LAÒÁcçpÏ:i³ˆc¤ÖûúÆIX—m¥ù|(Ÿ:²zS¶ÃÁ˜¦ß–ãòßÆîÖjb-­
-ৗÛ"ÛX›?ÕSDâJªÌGú¬Ú‘o°Ùð¤®÷ÐȳžñÏKv×F$-ã`÷5=¾¿n¬ûë_I#0ð­7Êî]˾թ¸â¦û­]“áæîüêOuÍÒÈŽF~‡B g$dýý…i7u…±Ë\¬@ý iN~—×OÌÝ‹[ÆÌÁ±À]D/=]¯zñòÐÅas½¤ÃZ3×—Ú=±'.Kò÷·Œe 	Âi)»Ýh€éÓ/÷:Ä•óX¸’v¸IP®Î8Ý#oñÊjN%d½'8D£V=tàl¡5„4go±‰AèKoN!ä.˜·6
÷8b¿Ut?ãiÛCœ¨ô÷·Ø1ˆ¾ØÞãQÄ„_ºûH+RÚ>¤x3ýà‚ý7°™\
¡Ð—lšj(áŒ]UÈ£ŒdbÏ2GT/ö±t=À}üw`Q[ésøo/körë—#¶¦Çî[ý€D>
-a-‹PšêÊi^(5aò÷Þ8œÆ—†rmëÜ0Û™//UªŸÑbVPp©ûÉ`i.‰ –§Á’¤Þ¡áû	ÇϺ»ijì‘"f[ºtköÁŠ”È|^g†Í„ZÏš¥2ÝDÜyÓ—À>ü¶6•thâàoì\Á
-z¤ûŠâuÐyçøé›1irÝžã‘é£äX’Eßa›×ˆÕÇ“;˜/¼’>ì[ö±™³FcFÒªgãö‚á‹©G
-oL1MFr-ÍŒ™a=áÖVVFÎwÎ¥Xߪâs¿Ü”<¤Ómpö{g~ű³ƒ2ÊЈB),ý±ÓÞ¨£Ä°íó:šà¤x1ÍžÅMÂ6ÍQô²Ø©(‰¡¿Þ‡û¾ô0‚ZÜêä]µ.0‰íÏô"ì° è+kèt‚õŸ˜»4·7Ì%¼‰«ÐœN.êm¬gÂݶ@9úl›ÞÛrH!.¸]¢¤QŒ±Ù4ëgŠ{seªo†ŽCK?k…ù7qC+¤
©o±|ŠåZ­HWiý9ó‘qn¡Í½2$¹G-LEøbµ˜öbo…ç
m»7oÕ–7æWÀG»JáoÔbÐ5z^oDB°w\<à /r¸Š\רrRjþBõâÿÂèù!&†Žh„Ž6‹$˜WóˆB-3ã½ä—K`­¼ò‡‰”zó°™ò‹N`zd åÇB™£+sÕýN<‹-8‡òŽ0;ë)Eµ&Ì.P¹$ݾM€ñ’@ݸ¦/Ã2HœQ…„IJEzïe‚q™ŸÑzÆ-tàQÍÔ¤rÆ‚}ô˜8kí±ÊäXë‚ël²iÀDâñJ”FR‡AÏŽ-H›2²ãXÒç+Ý"ÃðûÍÓšÿ+;Wó¸_G±.OÒxè"ƒ%u°¯“¿>Wû^ï.7 åòƒ  ž0ôuS¼2 ©'w²áÁ™ãi¨šFNù6ýUv“-«>]
xñÕ—*æ®çÅÔv‘?‡Ýâ–Ü©.M +0·dæ´ëžÿÇTcz¡JÍÜæŒ.5aö$¿¥Ê­°D
ÜE…q3„f›ÊœÎ.lªdX±îÚûp}˜•7M“ÈœÀÓªkQ4N5Åç­-…@²!G©¢6š
VœiˆR7\ÐMj„dcäî€doû4~<”Òe6äm?Ð0I×€ŒÔK›ÛS£ò£Ê%Šv¥Õï^+„¬Æ³ÒÛø!&à1:¥Çã‚'„D=ìà«&€©IãY
¯€äÂWƺ¥„RÒŠHw²ˆsë.üÙ­gäè÷mïyoµ©ltxebmH÷fïêïo&Hì*âj]¦Î¾kÒrX›0 —
ó=ø^‡,›.Âõ˜/Z—[’áXýõ~™?4ÒdÈÅ7€äñq´¤ª^JÙ[K™†OøDÊW÷ãºò"îf/’’u.3éªZšœ˜­9µÀµ”…”Û±†mùlË—‡Ï³'´4/Éu×µF±‹gGŽ‚Ç;`Žøç:í·úGj¹ÃÊH‡Íi¤Î@É÷²ÇÖiFèÅžoºÃ‹…õXWAúŒF˜g	=çÇ$¥¶¸i\üh¸Ôè¢ë9ÃËñüw¹UÇüv"¢îjÕiÐS+4ã%⎩ñaoä{Zg=!$Î3åõ1'Éê\ªWä¼sÖ†Ílâ4,N9Ã4¼½þÄ‚;w ½'U‡z~”Š¡+É6ÉÎù¸©õ—õ€ðËÂT‡4çjôA¢ÞŒ Ó[‰ôïqWűd‰¶ÛŸ€¢Kªî1šÒÉ|Ö´øÐÉøKœ-`@XƲœ»Þj”§§¡øð©Öµ„ËÍñšüÀ¨ɯ¡žßÒ
#ZVöÏeÁr²lã[cѽ·aײ‡xþѿnÊí"p¯½6Ö8wK
-†‚™!Y5ª¬h›ÂøIŸsëâÏç	ùÕAu8᱇vQøÆt“M$N×Óå“y'^‘qN²ñÐEW
æáxº„˜ûA;W7·H	”ãWNª—g=p®Ä"n¯·4š©øZKGœòÍ£~O‡ž¯ Žù¦Ú&þ¼óØb½êÇý3ËÌ@1"†r=qoÃEó”ä×™v0™ºp½³³Ë„ƒ"´Å¡‚’¶ÉG$QC¹„ª»×âuŒâ‘ÛÁ.ÏkYMÍ¡ÙÄó ¼·õç¡ÝF´¸6Óod˜*º–'&a[TF˜µuOiÂ/k1ÎÌ#Ù'³áõ(ñ}:&ÌVS1Ho8Ò`þ0÷÷_"UUu¸!‚ãÝpwI¿glÝËîhaÓ¹£Θq¢â$8²»¢@¯oeÑÿí©IIkŒÒ…—¬©Qþ¥„›VÅØ\ãÅ•
-Ü`¹}ÊWÆÖý&_cWs£åÔlÓ¿›
-.«þvÐŽ–%u‰ ¯¤’¨]5H4Øe"›ƒhQ‰‰ôM“ªRM-D>í¡)rüˆ(Ëê­©è¥ÔYÇ9ÓQHŽÝ\(]
-Öð5,(x	J)ÜÀÞÁg0ý{wýçêŒx”
-Ô&‘#àfîÉ×kBq‚ÂõÅ{à1æˆè#žw­KH×\’Ëœ!w[‰‹Ë)ƒ?q[ø,YçÔYÿª²‡¶Ë•:Žè“tG½­3èÔ*þmèÊžÜ`m
-(¯-üü2ÉòFM:ãM¨sv¶Ä÷Эv"¥}kædJî
-×cºŸËã+DoÇ–ãÉ­)ýe¯¶ôŒã¢—WÖ™eBdeìºf|íö˜-Œ‹Zw4Vçvž&Ê=®ýÂ¥H‡,d|Làâ3N‹'¹²,šK°#L„Ô]øm³)n-@Ü´¬N&…¬$ÿÈçÃíKðt|]Øl‡¢ËJ>h–
-’9„©²Í¦i=ÿ¨nuþò©­'x¾N»˜4Õ07<±–¹ûIíÓÏÕ=Î)iÇN{à$dQñãTË0¿§h¹kÝçµùÚÒ9äóÌèÍï ¢ËG¢$éðf+vHÀÑ:ÓÝ&îûAoР`ž®³DGO?Ìd¨Î3ìŒ+Â̪Y¢ì'Y"-¨öíG3qŸZê…[|iøb£HÇß·¿lè t#æh'¯¶ßk‘¿
-ÎòÑÁÌûøjTL,
-gRH`\Âê‡%Aþ‚¸ÿ•LTa†ø¤6T:ùQè^·.¸Ê´DYAž£µ$À<ô{ÃiçŠKl¿XæŠÔÄ%ã»<ºr£²‰ÉÇI§ßðÒ÷®ó¥©XX;|¨‰êbuÊ	X‡jÂÕX£Ô†ØÒïI7Ù¡™
G;³*‡Òe÷ŽnInî‚(¿æ2ÞÅ¡æbE§4!0{šÕ?ÞñŠ”’nô0g™²ä}»O4,ä]Èhö3g"l˜\¡Ì±Óp•Í»6²Z“šÿêŠ/¦¶ƒûeÝ$³®"tÕ¤È:ôƒòõ
‰›îxÿœŒ¥?Àh[MND.ÇðL7|SɶtÑð„ö&øyDZÌû*Gmpr8\UÛ¬gTÀ­X
-h†“Ì]õ5ˆ%?»â'º˜M¾×ž/•[C2°‹ð}j…Ž.ˆ&•µ7ˆˆÁõÖ
ÿ‰r¸‰*½Æ¡rsC¥‡Áà¼qãl§ž_€Ôv¿vwŒSX~K™Ê”	Ç›¸´5"_¢»åzW‰8LB‡ôÚÄš+H*Ƃ߯@K„/ë·Á)¹²%Í%]Üå–=È«V,è
­{«RW‚:ik>•HŸSTÇÿÉ%6vô¾ö\áñ-R•@BêÔ“fÊø²øÕUrÇ–÷ëSv¾]õáåG:ƉÐì%*ípÑòÎwþêzd¾,¹~ÆVÝIý"’ù!k„­ð‹•ýžõ¾6ôÁSÖQ¥î‡ÍÌi¬Ì2×VþöŽÇ,]?§ðÒùûá>=,+ÒåE!ô#?6…lª¾¹*ƒšöß.‹+þN¹óücîs=A
Ž$—8ªËtÉhͲÁ%Mìï[rï?½>5˜‚sÁ©Z™â|ÆgÞϳë6 gê]`çwŸ‰
-ÖäJ¶$÷A­B:{~PŒ­|ˆÊ
©¸/N˜¼wéàý‰ØaÊ9ÕÒ”®òM_u*u~0Ã׊éào‰èX0Êr‡ÖÁÙqh[ýl½®ØÑîáÃe7æMà€;æ,—"íFóTIû ¹²ÐŽ÷_â05#¸.cœY‰]j˜ª:Ç¿ùö:Qqæ!å½¾iÀÁÈéo‹¡¾{£6jÆÑõ({öû^ÁèéWÝ{ƒHÈ%ŒéK!zþox
  µ˜˜¦°ÖûˆÄll¡Y:Ðÿ3ìvz6G0†Ç&QÚ	䊫‚n‚}uãaI#߃y>g—/¨`.n+/­Ð^q›‰t*+ˆâõa+uF¼ý} ˜Ž¥ï>à£jŽÄ˜;â¤ÏLUáÀ˜ÍPÒ¬ü“žÖkm",Á(\~éGP»Oªt[‚ÜŽŽ6nxf³lTÆíØH'ºSÍõw<²qs)‘‘Ç~*Ún¥
ÑBëRËÏ++¥È›!®)™øÄ•™þîêñþœCåaIyÃγ<–äxßsG²)¬•¢×®8zÅJäó`ãn©ÌsÌ™æEHœX-zoè=O!å™B?Êóíwö»µŒ›ô7CMûÕöî‚Œ“˜:¨’P'+Ð'¨MÖíéżAJNQbÆu:Vw^Ð(*mké«K櫬Ù)7,"[›cÓXåºÉªÌq…‡‘„gÂmb(GXT ,ùÅbo©ðp²©ï÷ÖnròΡUm° Cþ“væ$Põ`Ò匀V–cÀþu6®…ùqc†¬ó:†OtÎì•nôwØÒPÄv©*û&<û'½v»AhEñÜêŒ ‘—Á&!x^øí(nÜÂæ¥=YŸÓ“pì‚Eú–qEæØØíéÎVP¢7“Õ¹
-†»·=z/¢ÇCï¥ä‡`RðÏ!¤Ù·)žíú!Œ·zÍáí;LZ|FÕGì%«¯ˆÅÖ¤H6}+8ã¹ðú¸°ÐÀÑ/Žë)díˆz°W‚úXƒX¶¾m«Ø½•„»ù5gR›žF¹{‚$³*ú)u\=(Ñ-‚"Ð…÷±,â¢|]ǹý?9¿YÐOØ[L‹&ãÀŸrS*AØf­ši
-t)ÌXN9¥D±z¤‰-D0Œ8­àª;ÁEÎ+p“ùhJ½:–Éîföâ}©PýSücd?àó	<ÌÈ“|Šˆîç}®rw‚RÕ:Í$å·=„~mÉ]]˜RòöÖ„½®íX((—€¶Ä?Éž¸‹e»¿èœ¬ÛXÄ`]¹#ƒÝ’X—ÕoæQg	è¿ÏU„»7mˆ¥ä\’sõ÷‘Œ¢MÊw5Yl”ÓaM)œÂ]Gƒo\_¥BW¢É–Œ3
-ܯ*˜Œù¢V}ÒD¦ÿôð£ÎÈ
-}ˆ2àq=G/¦8õ1ÝüÍ/]Z?ó{P>yêU•œµú}éÇ2&@žÊå6Þä¡þ;TÆ
-Ý‚Æo9ÎÖï[f|t7ñC[,#ѼR'Ry\³¥»VXÀƒ±AA+w
-©õŠÊ§üyž+¾û™’i†2£]Þá­•\÷¤Mçó:µš•wbÕ‘…Ùˆ×hg¢Iµ#ŒºÛà@ïuJ*³É<¸S!ÙÖdNPÂD )­×cÅkø2æòò›b«ë#¸Î•µN² û›T“Z#¿FýŒSÄ̦ۻéz,³Ã‹Å¦ŠGªÖ\ÀV¦(Z‰šQ vQÖK>T«:œSn
-JÎtŒ.a½AöB¿×n
8b¦”w»VŽn$øÍé)4Üú¤÷VçËÌŒµµèN‰R£ëÐŪ—Ãÿ×>Y¶5(QD‰!%ÝHîfà¨Ñ9º‘n	i’"]Ò-Ý1ºKÝݵ÷þ‡÷Û}îùçÃyžã•”4|œ"ïñ`Ûý]_€ßÿ¼Ý²í\£$«:ê¯{¶F†Æ»lìÏ3¢?ÑL$G@Öóå×vmôãŠ#Žª×°tή4ËFIñê\é±¹†òã–ÊcLÏBÙðn¶²e™i¤ÿs;<¶ ¼ÿñÏ7JŸ¨ie/þ5÷“FàEZUuç!í¯îðœJMþ•³ŽôÓ	}Ëß–~¸
-Âòé€z{JE‰FªM Û„u–æG0iž³ÍÀ†^µYkúzþ'ôÍòH¬n“È([ÒKFR}ÿ^÷ôdk
-±5b$ßì}Cd%#vﱓ*š°ßÉ
‘ú°»­¥8hñÀÜ_Œ»Ð7¥U½2f
-b›oÒm÷ãÅY…½jãnQŒ˜fýÊm½­ªm&*þ8”Èç1|ñ˜a¬~– F‘«•¢ûÎòXQ;(_ÆSI0ü+p˜ý&á¸$BF
-ý1ì_v#ZâÍ,µgªìVØ
-*‹š@i‰úû¿ž8ëäCî3luRŽn£ÒsbX‰É ýÚNã0Lb£?yrK—Søƒ=ÕˆáÜá@Æ	žÀlþ
 ¦Ã<˜'•AÅ87gñU˜
-Üxäø›Š•XGŠyº'üá9vµ,Õ½OÓà¬KÏýØIC`­”¿¸9Âò§é¸ˆßcZ”Âh.RÕŒI8¬_$òfIKmÌXró–€àÇêŸ%Ŭg”ÆÂüˆßY'ºVR, ¨B~
ÐÔAQäϲ¯u£s¢€Ý_˜Œ\@øt-ò©Ÿ’>ö‡Q÷FÉÎUŽ«l$Ô.ËW(¦8*³Ÿ{>B7@-7쑘ôy™Ù7º!„³¶QèÌL}*Ÿ$‚WVÉÉ®š±Èñ×´//2ZA$¼§¥ªb;>~T6EÕ<Õ¿¿Vj3ps[‡Ú[ë#.JìñåY¯ª0ûì©'™„±ŸµQÖ8}Q¥ÞÒš½.HÒý¤ñ‘õ$=¨â¯oñöaZ]‹#6ž/¿¦Ðô¹e¸ÞZ‹ÇM{ªh=Hp¿œ¦-Õôš£åežÂúz‚€ÛÆ«ì(Onû÷söQY²æ‰Ï&¡I(Ja]U›-fø´Û[ˆÿÞóݦ6vº%š.[Íá§KpyJÖˆàêh2nösjJ,©VŽ&EͯU¨•x9øW+0éOžÜX‰3„\´å‚]:aFïz”* ^Ô¿Žààˆ¥A
-‚¾¡ÉzŒ:s[­+ž:[´‚r7À«_ó熈ÑFÂ2Õ:¨Ù˜-Aè
-œÆâO­Œ,Eß÷;XM«âU†æüìeçÎ&¾¸cë2“.D£T«h8&Ëe7nV"ÎCøpÁ¨Ö#}&_ot-ç2ÃæXL¦ºŠðï"’‚Áf&ѭ탔w¤éʼŽE9Ãê¶Y|t\dà=_©Ÿiµª¯9ÅÝU5½<}âoCʬe±É·mQJ_”–õx-ºDïä»3¦Ÿëï"‚_
-{8þFÑÇæ–éì	é–sEcø ôc/
¥Xne­£ß	Ip’XÌ,X§x©oÞC§C7}yñ8㟑KÓ•F<Ø—¶cÚùc§>É÷"ÊåæÔYxVì#³í³9y«bTjýé‰NÜáù„…ªjŽ\«WÍX!Ì[Ê뺧b'ÞŒÆ)<$1ôÊÚ[,à§	ƒ@ŽWÃc3/—°WnY"¬Æ4áé[_Šüå–#xÎöf3I¹[V¦;ñ²è2f’a_ÏãX;q)ö&Öö4FØ…È÷Ÿ
ˆMóK¶Ñõ‡ºé€‚œ»&nˆ°¤ý‹ëžÜ[}·R½™Ú¾Nò
-=X¤9ƒ:Ø•ñÒ¤áiÁáß”×ëùpj2ã¬#C÷€ù= Ë#;.§Yº°xB±}!ÝA®í×›< ûFÔ9OµX¥|½D;-^Èê-Èñ(õ8¶ºÞsžj‘ÿû_„1Ìo^}$å©ZR‚„ÒE!
-†*Nñ(ßc“À“
-ÎQÓp/6è~E”ª:Ý?ªúÚ Oæ˜%3=/4X ýÄÐuƒä–ŠžØ¨ûáá]°ÄDóÏí¼
G‹Æ˜; sL‘yø‹laÚTKcøþÙÒ5Ìg+Ÿû{Dü±Í9­M9îŒu.ÍÁGBLK¬O%¹ŒÔLM…•“–`Ov’TEíûÐÖ[ï21Êsd©Jéšp•˜éø#ÃYÝEö‰¨õrnâ芻‰…ë°¬&âè݃é3N^Árÿœð•ó+fd-9¸U0Ód‘ ´U¥A}ù®º"äöÔÝ©
-ê™ã2ú»‚îY$óµÉ•­ßª2^IÑPYm3ïÜÚ×Juý¼=ÕùÌ~9Äÿ	2©”pmPkDÉ	Ç¥)DcX¨Ù콘ûk*+ÇMCÆ{Ù´~­Íµ)²è5¿¯ÅL|yÿ1ª5u‡Êëñ÷Òc9„ÍrU¶óBDøò3TyÈ嘙	SzH1ß+`Îð¶+§`½°W5Ó㎎²ÁÑÃiÁ™,÷ò}cýö3!§ïÒƒŒ‘PuaÛ›”Ë tòÍ|T\ÅL,pÈBHðì9çÑô)8H-úäjj*ê=êOŽ<™â:õY9­ªÓ=iƒ‚h¾!‡¶ïh­ðç¼×îöÎWc?|8na|qží+¬A}~é{âV+gê7L7,ðt>ÓSÉr¢$˜@ZýaQ»²L=4›Eb”¶¼ú¨•ËÅ›å/Dj {h>UVÇêúÓ·×!JÞ£ëp‚FL¦DE8"¸FKËyŠRŠàïQ¶ÖÿcFö,nc$õCèÛn^ºËø}ÃÞ‰ÔÕÃìm{ebèÅß5|:¼ê6ÙÑÑçd®‡ÄŽæùƆ^Ý+÷/Ø:!\Ø°meCkn+?
äm –ùK'S| j&¹qýÉÆJ²¤µúže•xz2ÙÌBwÛÝ:‘C¤·¸:¥½`RÛˆë1ïN^‹r+Ú©:/cm1+Wã¤àûðó·ê÷$â{‘™à‰¾m©¡¯ÈlXCšyÆïÓ»,P°&Ä•–¤–6Aí³è¼XË4ì¢Ljn¢	ér:S#7v°£˜¬dd÷—“dZ«¼rQK¨ý>¯õ®lH}™‰Óüzôßa­ªëµjÈî`ê†÷Vš¬ŠÖôžÕŽopõÄh€— âc—mNá»’E…¡/—¯ñ­(À»¾£ÐgñKÂ¥K_}dÀç²çšøWNy´bJºœñýÎ^y{D¹¿áöøȯ×ÍóWV?S¢6y‚
D\ë †µÆ†ûÿ
-Œ†<\a/r¼ˆvÈxµfíÉCvP€ÕóuóföÈy§Åm4ÍÛÆajùlW¤JÕ4pñûZ¢Aÿ6Ñ®–B][¢µš×´B©®¦Ö{?q£Q4¢«]*ê
f1
¬Œ*w5#Ò”HðŠ¼ª¡–©ÖËCšŒñÌ®¾”ëÓj¯¼Ã'gE¸FŽ:í·²ˆ¯%u0Aü¼$°aXÂ/÷ߵƪÂú¬(ß™uklê..Úá¨etV‡rÓ*$ß;>wYp®Ûr¡£îdʈ†éñÇVéÃhKñ«¸óWCÞ.ïò$.¢oÂÞQ#»Å¹* q¦ûÀ6¸JÔ	àÇæOŒù[ôÏQ7óeø^ðÏa:iÄçºb¢&ÙgAÑV£ç\tj†yçר™<£È„ì3tçV(ôßÌh©×OѬEf›½	éÝK•X?`Ãþ7ØokÓÈh_y,Ü÷í½?á¬{®Mpóßù‚z¯–ž§ûëeò eÌtÞøa‚s{ú(5J<iKfÙý6ZilX'Å¢ã6ÉñÃëÓÛ)'´Y¬¼ó4a ³Ô4ǸÔ;ÁñUÁÑu]h‡ÎlŽÑJqz$KЪ@ÊÛ3§Üo%ù˜CS÷.õ„ŠuáDâ°YkÊ5N-¸àî
)¦uóñ×RÒŽ»—,â,Öò‘ù;²eõ'h=ö:©aCDcjÏç¾µg"ÁÌû'…@ä¡e;éL7FK@»,ƒýëdE’¹¿eÊu]þ¦&ãñ*çXêR\×|ç>¤}Ð8ûÅò´†ïZúI–-ÄŽwp­íô	|Mª›…ÞTõèË¥{E-5uyЪ(Cˆ­ÞF‡ÒogçüÚ3‚Æ?Sh`Õæ²2­£=‚II¥ñ“ÆñÎhÆz[ùP.ÍgN#w£é_á£ãäbJýè¦3eçø1Î?­úw–û’ë	zT4{…
BfA]qpeóD=>ö$”z‹Ñ”H"s›eª+è–ÆŽµz lSvöñ©…ï–YöWñǘÛFÆÉð& ëB¼´söÓn>³•Æ¨»VjÔŒw¥¿·x¬ I’ERH·
|MÄãzÅsz{o ß–ž›ŒD3e'lÁb=âßç95K7ÁœÃ'çk+'ÂæxAS5#]¡~ Ú§¾wÅäoV¬1¿AÃÍÝ4šïOFG,j‹`Ý8ðE¡4™üøìi–¢L-C^+ÔÜF«Uݱǭ„ŽŠ(û89Aû[¡÷Ó­f)­Æa|é]l©ì™ùÀ`§ª¶p«B8Lúño@}þÐ’F³’Ùa8
-åUÔwUMõ»gÕ"&ÛQ=Q¿Á²p,æŽ ðrÎfœÝ‡Qã³éîtÜt6.§>ôÙêð97›“¡ÞnW‡•‚ø«Ñ¿}‹!®N‡éi…@lã
-C•Á&ûA×"4ÂÌ]iÅÎ|,›ž(mÍ…pêÖ.‰ý³oRŽÕ]¸kŽ¬¢PÖ¡ZÛZŒŽT2Ê©‚pC¯–dô.Rn®f™7£žØærðk®–-!OõŽž1t¿9~‚ó–‰æ·q¼mxYæó”9gK’}ÃÜÕè×å HéÏAf™\pCÊˬM‚._óBâÚjq
À¶]qL÷‡Âa¯¡n—ˆ›´¢('â¥&Cv­pñf–¿‡OFÙ2ö
-# ð:øF(‰¥YäsäLèÆùxÂJßÓ%ÌgæÂîˆñe:‡¯#0®ÿëÊ»3¯‡óíLM¤\“wŒgßRkHäŽÅ_KØwÓªÂìni–ŠØ±
¨wŠlNþjsßÑ8v>
+stream
+xÚ¬ºct¤]·.Ûv*I§cul'[£b§bÛ¶mÛ¶­Ží¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ø%ìlA,ŒÌ<5e
ECkkC;Y)¡5௙’RÔh²°³3y@€Ðð퀅›› jgïîhafPÿå ¡££ÿ/Ë?.#÷ÿ@þF:Y˜Ù¾þ}pZÛÙÛmA)þ¯U€@È0µ°Dµ¤ä%Ô’òjI -ÐñoŠÎFÖÆYc ­`jç°þ÷`lgkbñOkNŒ¹„†'{ ±Åß0 ›1Ðþˆ`t´±prúû°p˜9Ú‚þÎd°°5¶v6ù§€¿vS»dïh÷×Ãæ/ö—LÑÎ	ädìhaüͪ(&ñï:A憠r;Yü…v¦=MìŒÿié_Ø_š¿(ÈÐÂÖ	ºþÉe˜X8Ù[ºÿÍý—ÌÞÑâ_e8;YØšýWôG ™¡£‰5ÐÉé/Í_î¦ó_}þ—î
íí­Ýÿm÷/¯ÿ¬Áä´6eD`ùö7§1èon3[¦¶Š”­©€…ùßvgûÿÀ\€Žÿõ?{†æo†&v¶Öî )“¼èoJõÿÊŒÿs"ÿHü?"ðÿˆ¼ÿoâþwþ—Cüÿzžÿ;µ„³µµ¼¡
ð_A€ÿ¸c²€.ãÿÍÝÐÆÂÚýÿðß=5€ÿ®RhælmèøßáÓÛšýU„›‘ýßV'	7 ‰¢ÈØ`jhýwVÿ²«Ùš­-l5ý×8,ÌÌÿ
S5·0¶²ýgøìÿ†€¶&ÿ½ü¿2ý«x&e
YYºÿý^ý—Ÿâ_ýAªîö@ÀÿŸDCÎÎä?ÿ°ˆˆØ¹<X8™¬ÌìÝ߃ÇÍÆâýÈø/"–ÿZË‚-ÜÚÌŒÌÌ,€¿ßÿñù¯•î£·5¶3ùgǨ€mMþn²ÿ4ü;;:þÕö_çþoÓÿ±þ×vÝ€Æë+vƼA–i™é :ÜÜ‘)1í>È‘`ûÒFÕ¢¿»^ß´°]îJƒÚ`ƦžßíîËçöŸ‡Ò´Gc}8ÖT½)Àë|"o
+šþô­¯œtGLz¥ÈéQž7K²;P?8˜Õö¦””õJ>`ˆg:Yánžiü(\
+ü°¾<Ù£ø§6Äbw¡5aÔž_|M<}~¢î½…î?$¤Ë‰…§äuBþéçC(øC­B¼ªùÕi{Ju¡glŸÏÏìC(»ƒ¢ÈbÓËZÁçjð§fÌÁpC@¶VBjä+s^"ò“£œŸpÖj×Ñm¡HNZ¬¹Šù—;Ão{ô«OŠ—©š}¾ŽÈïqM gÀÁõ@‰Î
+vÌó_ŸäsýðKÞ`zŒ—6$Aïܪ“³ÖUªÔ¼qTÉŒ!ÝNë”›Å/˜4ú#pöpò>ÙMBˆÁrêM<õlb®‚‡é‹à\jÑhŽ!··qèš–í:—…u>5±“ª——‡³›G¿:×MÎ{òεÁéKœJC·Ò@µ¾/)qpgŸ”­µí‚ ¨•Šgý´»Û]^ÕÞƒÛ1Ü ½û߬Dþµß™á…°ä]xŠ©9ØhNT:™~«„r…7Ôè¯ArÒx‹'£º줔(IÖR×Äf*®•5`™xZi”çe™•Vê]è®tßó ¦@ßë¨ÖŸ :º·WH’gå Îãí;g¡ÎÞqQþ6ÿ*<È8Ô²nir{:^2‘@àcÆÃLˆ&º¢a™³SûI˜ ¡NÕÊÁãɤðÛeã‘[‹}­H}öA÷4OöÖgí
+„7N•{œP¾©3¹¥Œ/Ä[Ö]ªp­Cƒ’½f±eB8|*ÿá´%Q0d’hyŽÏË9€œH7þ5'i}=½ó{LXwÜëaä6Aº„ï5Ëo7F—Aµbñ#¹‰…O[?ˆny=¯7…³¾ÏÆ_žMSÑÓ<Ÿj²¹O-ÄËOrlºÈ|!•¡ÀºüV„,y©+¥,ßê¹2š_Sûà£#üåž·${qÛF2<üm=àmûS}ü{/°¥ÖÌ:i­‚ƒ‹\’³¦ææŒ"×îS©ÄÙM>?gЀñ¤kMí!,£sê-Ð@‘œm.êÎ@ušltÚŽ£{±/¦£¢a?©8AŽ°KjðæêBQù–‹Mør“J­õ¡F7ÇET¤tVÂÌ''¿3ÉØn¦»3=æܽ‰(®!að5÷åñŠ&'×ì
®n612"à8F•–²£
_;Ù¦kžO„ÝÓjwX	í¨FVfzÙâ1ÖãðÆé›­iàRQKzó€ü§$·+,o@rÂð*šAnú³,½,¶¹}ºeÄ)ywÉG~­(JYœ…Gåy T0}O7&·wŠÖŸ D©ÓÙé@ê±=Iµ~½sŽè#"Jk6ÿ´µªt‰`úb˜B½”ÿ}FžÎå”ê¡scÆ_»K3B|=iLõ÷*öY/È×d@OÏ9FÔ•Îk…&÷;®/Þ¯/]ÁH}ÄËg•ëYnq¿C…å#!èkšž®¸B<.›/æǤ¯çXd\ºiÐØñ-z+ŠÉ¥KHõQ´ h¦ÿFÏÀÁÕØ
wˆÇÕµÊÉàŽÌ–$^?Bäu):pãuÖêShÏ©ÏUbŸ¼ƒMÝ(¶&gPð	\`{$¾ɦc¢¹Ýà%_
µæ”¼:ËÔiÏ¿J”­¶¸•#HÆÌ)o=A¨|iÃHo5¦x8ûÕ¬¹Ùî?[8V=—¦­Mº.ïS`Ç¿%¼à%¨âÙÞëju¦JÕs¦þð²=ö–ÒkŒVH‹CÁVÑ"¯•›ˆøKŒÉúÖxÞfªxkžv7`­ÄJmœ,™iì‹—³é éM|ó‚X2<».Íhì¾0úd²n¬ØÕ ŽgÈ-KÇkenI`sã\ãQ
+ï™°H¯Ñq<)XÍe.vUÀŒ‹Ææ6¼j÷(OóÈŠ¨ð"AÏ@ä_ÞžX$#–alxUeh[fdþ.Þ_lÔæ8-®(˜ÙÉë¾—©)ZóÕŸÐ-Ž¡ÀULµîu!lIã$)ùºI@ÂÁA5ØÀ4“î¬Y’ËËŒÞòQ€!I…ó
+Ôû´Þܼõz2‹÷¤#‚JÇ_N‚aºäYCÏ>\z…„–gĈÏs³Ìjd¨¦!X¸ˆÓwÜ2mö8Ùp!os´C?yTÿ@[Qc×Üÿq…ÒŽ¥Á=5(æΡm³×	ÔIìÑ/Ôa1VGKj]Ø w´Ú}oä¿8A#çÁ°\SêœM,ZkyÀºHí(¨ ·³ÔŠSñçöš]MC~ÌTŸÜ¤Pg}÷p€‡€
J¥'Þ fØ‘Vý"‡øíbÇdsªÝë~£vz-t±~ŸU²ôn5\±ìÕµIýS«Uÿ	>¢KóHšÃmµ[»nKYݼ øËÈ|(ÚÍs@w³™ >sϽ°V…–šü	®ÙÞÇ+×Xª‰‘†€9õUW«K8†?é
`(zšŒÜ›×Io_eîÁ‘Í>&p×$ÏoLòŠJß´/õý…›R-“ÃOÃÄ,Á‰ þØFáÒÓýâùu.Í­Ž©X€²£ÝF:ûL@¥å߸‰+¸CVçD§›î$2ܘ±­¤‚Tô¦:‡4Oòü?ŒÙì7ØC*™VBÆò6Vjó­šÛ¾§
÷fÝÆ1÷ídž
¿ô|ÒÞÞ@OBG	À§˜«T ˜Ã1=Úuø1&\ÛTĉº(Ð64Ï›§¼ì¥—¿ž6ÇnÚ4~ÆcÅÛ[zFbÆ’RJ»žƒ.¶¡ÖkŽãÃÞDþÈÉ+GâzƒîÔ¹m_C|øþ0/–­Xµ³-`_1+Rå¬Ë¸ƒðžM*&`*ó|ÜTF-ò\<óãT¢Щ› 7³Âý7GÓ\[C2Öb”Ÿ‘„fÊPš{í›ÔW‹Ìà±(B(¾\íɵ^*L²€N8)”póiÿ *aG„ò7(…ÛŸòŽUvÝ9ÝÛ”NŽri$!誨’«¼Ž×ãý±"ðníyæñàg±ë?ϳ· ÓøÖ8Zj"kô䓆üùàÆUb´r¤|Ù÷̓ÌÛ­ç,¤p†é÷ƒ³ÍÚ…ïßý«½	>õz´ø#㉸Pb¦ÝÝ7K"*t²[ÝqýXÁ2¢?Ù®Î>¿cQµôÄ	
+³ì$"½ƒd"<Ò-דº!ú!áŒI™o‚öé­•“0óV;q„¿kù ÚAƱç!²‡Í¹iÉ—?E«\6ï•qV½w8á’Ž_ö3—‘¡DÏ	RöpÓd‡á~.ÖàËR“Eû?ø¿±ó­šK1Ã
+v¿»1	ëæƒÙ(ˆ¼JCü
+à+N‰Ø5ÚNjÔÐY›€¨áàݵiï+Zf;ˆ?Çåe³ÙvWà·kŸÒÅüµ—¢I¹ë´“F4{½*-5	…)2x¤iÎ#§·5ž.‰©sVñº^ñ¼ëÓýªÀ›`õVÙÅ¢UR¸¼ûpœ“åæ41$ûFÐ8ªŸ8lV{v”ƒîÞw©³î~¯ìýý«&À꾃~èôÓEKå½ây­
Dj”¹÷-vá'†H=~€Œøä“þܦð!UMÌÆ‚qzÝKs"œÏòçžNIZÇ&s™/í}‡•‚ðQE´¶åï¼1àE˜»×AÖö¹›€Ú8!ZŒ%©u4¶7×)-¹¢þxÏÌŠi#Ò},V{ 3ê™Lk0Ûd±À1èÙýåÇN@ˆñ€ÖXzdöi¢ð»†¢”YµÇÙ¹þÕ‚ÅmË.»ÎÅ)6>NSã"jú¦HËèË­LnE™ƒ¦üÂKh°ï_ŽÆˆ\RÙßC*  5¦
T(´eLjÔ9úÞÓ…eñrWtA…¤ÙlõtŽcKª¿ÔL©ÓšïÃÍCm á‚cÆó7ªÓû:³HAÁÏÑ×$k!å8Õ#[;mñW¨$¥„ÊQã]T”PpÎÊ©j0)¤p)8H‹Ûä—4ÞÌd9ãYVä]mze;ûµª.ò+ÜôÖƼ9+C­…ŒµÍ7ÈÀaÀõñú%B{PçÑó²ŒG>¦ï\8ÞÓ>\ùë
+¾07ÙtîRÝçP{myZí2÷<ijœçâzxÒô£'2ºñÉþD–£,9tÞ±¾vR§ðSpCŠ%è²³O»¢‘χæhÇeUfL†öH)”éßѦ"¥2¦TVÞ¤Vx/>’^Ž³Š$pEÚŸºþ<˜÷|š‡+œüäî˜jlJ¢ÂKiMù	éÝÙ—áø~‰Ò!ÖQ‡ü{Ç´ûô"¹HПc!v©+2é5ÍlqJ®‚MÏWàï3hŸsÞ:®ÕýT‡1›ãð1QâÑ?nÑa»A› ²¨ÍÜf§”RéTø§qÉíæÛ·>Åé™*QÕŠú™Égš¾p¸ãù€ß°L£¥ÍùŒ„Ê«˜½HÔvN„4'F­Ÿ_?jw­í€ë`Dz?ú¾É¤‡ªŸ}¯?]{•jåqL®tsµN!CPóÅñ5ˆÃ·Ì|Ïå~º0È žÕ	iê“Ojh¤Jb§
=¯ÉŒÕÿ;Ñõ¥efÚU»oÕŠþ-gì©Ù¯–Ï‚ƒ‡ÐhèCÌÖ¼Á‹Xž
0Kvî5möAœáÅ\AW*£PôŒ~é_rqúõ§EÓ<ÕÔCvCX±
¸q`3'¹¤­„{èF°–$õh\..‡ ¤õc½ÑŒ â†Ù]ÖÛi ¹ýhIèuü–¶ô#”;üÌÎl²k¾HSEb0pßÂéôÈUÖùz¶ˆ~ë>
+º.F5|EKÖ_kßU­†Ä&“ó"÷•€äûdÎ…#æ›5åØK"20¬.Fí¢Jà(2\࢚z~"‚*X¸×”•›¹-=‰Œ!‹2ZK
…‹3…~`ÊòJ&qðmvpˆ;¢¬¬Õ¼}ÜtЈD½N¸Q/pÏÐ@Øy)diDÿD¡L"Y^ßî/;>Ìûjö‚cÊP;É)>¡ˆD‚qL¢‘hF‡\§›:ÄzPªÂK
b÷{Ž:bÌ_ÊúDÓýx©4—wB<ÂhESUÈyè,ºf=°jŦc³Ûb¤€™×Nx”ØBÞ.Ô¿œÃóoRKŽNMðͱŒNpt
ØA¬¡âϹùèÓAØûElÞn_V~MTÈüð
+ÛIX¨_QW:ÿµ
]úÐÀï9Lœ`]fd„ú1ØñœÖʨó™¢r
+EþØÜlgøÕ_:jûìe‚¡¡¬¯	3"=%…m7áûìç‚=~WéFF× 4"K¬³DÜ'ªÑ?¶úï…nÞüú
+M
q‚8IoÜ•ªÅö›ÍL-Ô…`€ToÞ½*Pvz:N“x›ÝžÜ™3*IŸeÀ4µô
+;S9Á%]9Ao¢ÁN©‡’p6/€ôJš6:7õ"élÈ2îqœÞ܃A«ñ)Û«Â!F—?+Íõ­ÙV³d$7ÁÌ&áýWW(Þg0 ÎÜ#Úž8¤;ßJì­¯ý‰Ù¡L¹ŒÙOÝ5oYÖá˜
+AÒà}…a™5‚>ÂÃNFØX4²–€žÞri¸™½‹…:'é‹NÎXªËQ±lC#Ë4’w‰ùŸÈ>ßOºÒLZx¯dTH‘™‡Ø*:ÑP=@[›CQƒi«m®þ²´!
+ÚÕìΨWtŠã?oAZdævò6I›¼)’þ‰èRUÛÌ(Á@Ú”µ²âa»¦Ð£ñ	Ûå²ÛšÖ/ì¬ý&Å%é¾ACF÷êÏa¶šƒ;öùZjûâÛQBÙ„ãljÎYIN«ä…{Ïy|—hX®t²RML‡WK&q¨aEPjÍ–_ê›Í2ÒÙmYL¡£Ý§ÎŒrêgsÓ¯NãÚ‹+A׃²„7g¨ëÞÊN óké…%¦~aÝ–o¥­~F¼».û#3{9D«Áä1;â´æÍôQôÃZÏú8w&_a†¶j¡ã÷q ´r©>Ý}~9ÃQ‡“¹ýñQËöš‚¸¸ÅÒRß
+nº_Ø;úáW„ZÏ(œd ÆÅÕ>¤õ„‹ÁêÍ¢*qöŒ‚#röwQ;£œjÚÆ^kNÿyŠÕzÁ	tjY×rCD[")Q’£#˜Øn]Ìcõ(ð(»CÈ=g}¶F`³k940Œܧk¤ÿe:ä#_tRáYL©£½N‡íAKZ'	KLH§£tvH¶ÐSÑe6óSò<ø]©k>¿2 GÇNê#u0UóQŽÅÕòK»/ó<'\`ÛyæÒ5êLZ íèÄn™çšz‹ˆÆL²˜)ÏvŒX¡[M5þÉž„¤´‚o®HõÌLg‡œQäzä<¸±5î6Ýc²±ï.U¨vÉM{bUWåL¼Ù¾Î,mxÙ*û+‚ikX‚â{uõ<„NZ'8ƒ,T¥~Xè%{2Ñ/f>[µª¦Dîïö|Ý¡±šöœ©.q´Ÿ›l¢”„AMãSæKæí3r,ÁãZ<Ë›¬ïám)œ+h¯zìÏa~¥^Ø‹Yºxà½M67­
+}¾Q@°ë_Â!¡nÒ
q£^c7Nh?–Dbk]z‘Zøù·Íà[ÛX=mÅ›P
:žž‰ÍW½G°tC#<áß×VÂ'¦ŠÒyÞÄ1ò\ðÎòˆ¿ƒˆ§9&åŒÂT«âÞ°;¯oQ
+Äd²’Ø[EÜ­°¿ÈÇ`n—ÅædþǦiBŠFtù£¿
mŽ<{töJD|Ï;±Æ&G‚iþco§Àå²-çaA3©±W(æ‚2MYÕô(mò¤	œFã³{gþz&V__éa6ÎÇp›¯ØalĺÃuwðnæc"8¡n‡:Ñ!1w‡Í‘˜Ý¿g•Ã
ˆ%ù[ÛÃÞI‘nÓåÙ–~gdº/~û¬ugÉp¡`ÁPþôTiHŸì2\)ÜЙÍàÿ®ºþ0æ‡zx)œE½ Úéq;7,¦ýs¸ƒ,ª‡izÕ­éü*ið¾\~]•mî§Æ Æ
K•!ì†ß!ou4›¿›û‹†«ðw<«^UG‰/)cy¯$Ë‹>täCÔž•6rеð‚jåº)×ä;æC'17'IÙŬõ1:Ï–¼pV%¤»Ã
+2°ÅѦyWýö¾¥jÖÎŒUËü«üÂ@¹,íðÊ&©¾JèS"§oóZ²,¢tëpbýèÒúc•û"i}„¦Z~K¹ŠX`i~l…`šúI‹%âù>ÑH—ÓVÒE©ÆÅU
…ú©KÜÖ·w+ÁJS¼=öËŸ.Ç=|µ >üô=ÛŒ
+’úC¡ãa4Ÿ—7C‘ªÜ݃~Z¨‹ˆÃ©µ»*‡‚s·@qp![~_£Œ¿:[8&‹”ŽËNp€0ËtÃ"¤ü4q%¬i¨•F³høð¡HÁ81äј=Þü2¶ã³âL˜lƒK¯:ÏÂiåsB¢/]ûP6•[x²	_#6}°ÅfT¬…%*FųÖËÇ}Ù‘8?´Ï›PÒ¬“ê<7í¹õìÒÂgVq_î½ò±fKú–lFîkÉ(w(:Wâyx­¹CIBÞâ‚Û¨[NõbÖcpq¹Ú4j´¥"#žþs7¾hÐag•Þ^c
QÔ'?ªæå´AÂÞÊ…øh¹(LMa.‰(<ûù
¹â¹®ÄÃä%ÄkëºT)ƽØGbª8Ø—ö×tà,D¿“¿¾µ•*Òš.S:µ›èY|Ùä'Fz„yÎv~lˆ²Ð…ÿþ5£àfâ¤û–¤A-í-³ñsEZEÄ÷QàÝÜ=‹þ‹ÑMTsî›?8á‡t2eVe&…¾1›B¦\q(ɽAˆð"_²ó8ŽvTD=°e™U³ÓÚÖ®e#"EîÍÌ-ûax‘Se¯;ŠF$­àÈY‘×Ç7¢=HÞ¯½~òp±Õ¿þ) ’ýÐ+PXY-x"yQùºì€ìCˆ«=³&o™ù…ŠÒ¿$¿Bb‰ÔÜ“Q80ƒÁ˜jU¥9Ãüró5½C£öñ²·Ëä—A<Õ¦¡1RÁgó[¼X-	?¼§µebÑ×k^6*ÙJ¬(І¦7Ü1)ºPïNଛ/r§tªX¥õø&™ ¥ƒÆôÏážµÓfÇH­öõŒ’°.ÛJó9øP>µe't§l†ƒì1M¾#,Çä1¾#Ü­ÕÄš#[ÀN).·E¶/°6~ª§ˆÄ•T1˜ôY¶#ß:a³áI]ï¡‘g=㟗ì26®HZÄ+ØÃîk
+z|~ÝX!ö×½’F`à[m”Ý»”}«SqÁM÷]»&ÃÍÝùԛꚥ‘ü…@ÏHÈúûÓnê
+c—™XúAÒœü.;
®¯˜›'·Œ©½C›ˆ^zºnõâ塳ýæzI‡•f®.µ[bO\–äïoË2@c„ÓRvÛQ“5¦_nuˆ+ç±Þ0p%í(p“ ,\íqºGÞâ•ÕœJÈzpˆF­zè€ÙB+>„	iÎÞbcýЗޜ:È3\0/¡4ÜcàˆýÚTÑýŒ§mq¢Òß\cÇ úb{OhD~éì#­Hýð&Åû˜éì¿Íäj…¾d›ÐTC	ÿcä¢Be({fŸ9¢z±í¯ãîí+¸ƒ»ˆÚ2HŸÃ{Y³ït”CX¿4±5=vßê„$òVëlY„ÒT PNóD©	“¿÷Âá4¾4k[ç†ÙÎ|y©RøŒ³„‚KÝOsOsN±<
–$õ
ßO8,xìÔÝMSc1#ØÐ¥[±V¤Dæó:1lž ÔzÔ,•é$âλ›¼ôá·µ©¤C}cç
+RÐ%åØWÔ糖Î;ÇOÏØŒI“ëöL%Ç’,úÛ¼F¬>žÜÁ|á™ôaײÍ4˜m?3’V=·_L=Rx;`‚i<’kav`Äóè·¶²ú0
+pºs*Å"øVŸûå¦ä!¥`˜nƒ³ß+ó+ŽµÐ˜-”a¦¿FJá`éˆöF%†m„lï×Ñ|GÅ“ˆ9€lö,Îh¶IŽ¢‡…ÿNEIýõ>ähÜ—ð¥‡Ôâ VG¯ªuIl?¦_a‡EÁX¬¬¡Ó]VbîÒ\ß0—ð&®Bs:¹¨k~`µ8î¶ÈÑgk[÷Þ–C*qÁí%b,ˆÍ¦Y=S„Ü›)kT}3ÐwZúY+Ì¿¸‰Z™ m@}‹å],×jIºJëÇ™Œs³mæ™!É=â1P1@\¨²5ãd £ÊÕ¢+3[9DŒ§Ý´º;A‘þsš-lFQRÒÀöÛa¾Övþ[A(Ïô䕨:>Üa$/)œ¦ÿâMU_q£ªÀX9ð(ÂÙ9Nø†Ó3+öš¸wQžugGвeŽd‹@ÂLkZÍöç@QvÛ˜Š!-+¬d±ëO%è \é¥&û)Ë£zÝ»èëvÁ10䘰²ÿø£T7ÞúûèÌ›ó÷ÏeN£Ow·OªCõ§{gW¸¦u‡3Ž«›°ž¯uÇ*/[ê7,›¸GÜ°”¿¤Z·R	®²¡Ï”ÊÇ‚À“É*ì5tõŠQ,öO^ÇHO‡^!VçnõYç†ã2?K0eXËk¦·zy*’"\ü®æj‰¸gFÓïiêC.Níe†Êë”–"—²a÷4TÔîÛϹÿ)ÂP~CMH” sü•cň$çi~}c5mDÍÚ64òÀG¬þ¢ÏsÒœ¸—Ò¸×õs† ¹žGîì¾íʨ	¶49×ÔüɆÿ»–21“膞„P1Ün`‡\¨_RðbèÖ‡èΑ6ÂdÙ.ÛNã²êü–û:ããœÀË<2¹»ì¼‹¶Q†.j”¤ãôiaŠ(«Ť{+ÚE
+çøx£ƒ®Ñãz#ú€½ãJÿy‘ÃEäºF•“Róª»ÿø†D¯11tü@Ct´Y$Á¼šGj™¯%?¼äX+å•?L¤ÔÛ˜‡Í”_´Ò#(?Êô\˜ã@¨nw"àYl™À<”w„ÙY)ª5avQÿÊ%éömŒ—êÆ5=–AâŒ*$$–-Ò{OcŒËüŒÖ3n¡÷j¦&•3ì£Ç€ÄY+÷U&‡Zg\'ãMnÿ@÷W¢4’:zvlAÚ”‘…‡’>é„Üo¦˜Vü_Ù¹šÇ};*ˆux’ÆC,(¨ƒ|ýÜñ¹Ú÷zw¹)ç`‚‚zÂÐg\ÔMñJÿ¤žÜɆ'Ž§¡j9åÛôWÙM¶¬út5àÅWª˜»ž›Eþvó[rǺ4®€Ü’™`h—=¿©ÆôB•š¹ÍjÂìI~•[ak‰¸‹
+£fÍ6•9í]ØTÉ°bµ÷áú1K/š&‘9€‡e×¢hœj4Šß.Î[)Z
+dCŽREm46¬8Ó¥N¸ «Ô6<É,ÆÐÍÉÎæi:ýx(¥Ët8ÐËn ÿ`’®!©›86·§FåK•5JíB«×½VYg©»,&à1:¥ËãŒ'„D=lï«&è©IãQ
¯€äÌWƺ¥„RÒŠHw²ˆsë&üÙ­kèàûmïyoµ©ltxebmHçfïêïo&Hì*âj¦Î¾kÒrX›0 —
ó=è^›,›.Âå˜/Z—[’áXýõ~™?4ÒxÈÙ'€äñq´¤ª^JÙ[K™†OøHÊW|Ý@yw³IÉ:—ˆ™ôU-MÎLáÖœZàZÌBÊíXÃ6‚|6å˃ÃçÙÚœ—äºëZ£ÇØų%GÁc‡0Cüs‰ö[}‹#µ\ˆae¤Ãú4R{ ä{ÙãaË4#ôbÏ7áÅÂ…z¬«@½‰	FC̳„…žóc’ÒNÜ4.~4\jtÑõœáåxþ;²![EâOB
ÆwkäL•1Ó-M‰Ë㤶@fõ$²&©U"Ë*uA½
+¼ë0å ®ÏØ¿îZïܪc~[Q7µê4è©Hšñq‡Ôø°7ò=­³ž‰’§™òÆú˜“duˆ?ÎÕ+r^9kæÖq槜a^NžbÁ:ÐÞ“ªC=>JÅЕd›dg‡¼]ÕúˆËz@øeaªCšs5z Q/FÐé­Dú÷8È«âX²D›íŽO@Ñ%
U÷Méd>kZ|èdü%ÎÐ?,cYÎMw5ÊÃÃP|øTëZBŒåæxM~`Ô•ä×P
+Ïoé†-Ë»ç² ¹
Y¶ñ­Î±‹èÞÛ°ëÙC¼aŸèß7嶸מ
+뜻%CAÌ‚¬UV´‰Maü€¤Ï¹uñçó„áÜêÀ:œð؃CÛ(|#ºÉ&ÇëéòɼÏÈ8GÙx被Š³p<BÌýÀ«›[¤Êñ+ÇÕ˳ž8b׈×[ÍT|­¥#NùæQߧCW;Gˆ|SmÿFÞÖil±^õãþ™ef C¹‡¸·á¢y	JòëL;˜L]¸îÙÙeÂAÚbˆPAIÛdðIÔPîÅ¡êîµx£x¤ÀvóóZVSshö†ñ<(ïmýyh·-®Í䦊ŽEʼnqØ•!fmÝSÚ‡ðËZŒóÈAöÉlxýJ|Ÿ¶q³åTÒŽ4˜Ìýý—HUUmnˆ øCWÜ]Òï[÷²;ZØtnh3¦œ¨8	ì.(Ðë[Ù_ô~{hRÒ¡tá%kj†)á¦U12Óx±g¥×_nŸò‘±q»ÉWŘÄÕÜh95Ýô릆‚˪¿´¥eI]"è+©$jW
 M vžÈæ ZTb"}¤ªTS‘O{hŠ?"ʲ|kêz*uÖqÎtR‡c7J—‚5ø
Z‚†R
+×·³÷ŒAÿÞ]ÿ¹:#¥µI丙û@òñœPœ p9EñxŒ9"úˆçFëÒ1“ä2cÈÝVâârÌàOÜ>KÖ>uÒ»jì¡ír¡Ž#ú$ÝQoë<µƒº²#×_›Êÿ~†L²¸Q“Îxêœ-ñ9t­@i_Àš9™’»ÂuŸîçrÿ
+ÑÅÛ±åprkBÙûCzÆaÑÓ3ëÌ"!²2ö]3¾v{ÌÆY­»G«Œs»Oå×náR¤C2¾&`ñNƒ§Eƒ“\ÙÍ9È&Bê.üŒ¶Ù· nRV'“BV’äýáú%h:¾.l¶CÑy%4KÉÂTÙfÝ4„T·:ùÔÖ4_'áULšj€žXËÜý¤öiûÃÆûêç”´c§=`²¨øqªe˜ßC´Ü¥îóÚlméòùfôæw Ñå#ÑÇ’tx³%;$àh
én÷ý ‰7pP0OÇI¢£§f2TûvÆafÕ4Qö“ˆ,‘XûÜLܧ–zá_ÐáVM¹‡¦OšdvÉDþeQܪ#éØ©èªmc…PðQh–ȳç%w"?/]]‡iîä-7.ã’ÿ¦VÆ|K‰bÆ”`ˆëF¡·bÈÑ¢-ñ1Œ¨y4T,}ueé'ÊÇõ»•ãNø0mT#?[½ø<ÿ=†C³)õðœC“$²h,™#O±Píe8ÒE(,–#s¼zMÎ)0Ý‚³0µÀ²DU4–;ÒðÕ…1¦ãŠ~Ç0W€/MY$g´™•A-5 Òþ 7ãnîS}Ž@N:°óï3ÆúZ½Fõkwy<Òð‹÷ÜhŠKÏ=s+8T¬ªÈáö@°on»ÕÜDükw¢ïž@8'ïop°ò›KéC©ºyϚʡ½
+H¦Ö¼9Gž¸M‡ôº„þP¼¡ïÒ4Š›µ.¾êJøiˆG•Ä$…hÎX÷lÕ-DÞßÍ›á/c;§Ü?‚Ë¥9‡l®Ñ{Ä­Æ»òni†n½$›B×:õÒ©~’Xvyx’9c…Y
+	w/¼ÞU·O§”~EÁÏAç8Q•|ðŒGÇ=gý9,?YÁ2Ë2L"ôÄEñK‡æPüÚ÷AÍí"I1„'{†§³
úº¿¯c¼NøŒß_lbéøûö—
m„nĜɫí÷Zäo£‚³|t0ó>ú>S‹Â™ÔRú—°zaI¿ î%ÕA˜">©
•N~ú‚×-†®2-QVçh-‰úó
ýÞpܹâÛ/–¹"5vÎf—GWnT66þ8éô^úÞu¾4+k‹O5Q]¬NÙ 
¡-ël_M¸k˜ÚûAú=é&;4³áhgVå°CºìÞÃ5ÉÕMå×\Æ»8Ô\¬è”&fO³úÇ;^‘RÒ.æ,S–¼÷ƒ`÷‰†¹¼3y°f?s&†ñÊ;
WÙ,¼K#«©Ù¯®øbj[¸_VM2ë*BWMŠ¬3@¿1(Ÿ¸éŽ÷ÏÉXúŒ¶UÑäDär÷ñÇtƒ7Õ‘lg
h/‚Ÿw˼¯rÔú'‡cÀUµÁªqFÜŠ%ÿÖi8ÉÜÕYýXò³+~¢‹Ùäûó¥rkHú¶>O­ÐÑѤ²v†1˜#°^:á?Q7Q¥×8Tnn¨tÑ#œ6nœlÕóÚî×îŽq
+Òo)³S™2áØ¢c—¶FäKa·\®ó*‡©‘@èž›XsIÅXðûh‰ðeýÖ8%W6¤¹¤‹»Ü²yÕŠ½¢uoUêJP'mͧésŠêø?¹ÄÆŽÞמ+Ü¿eB*£HH:`rÀL]¿ºH.âØð~}Êη¡>¼üHÇ8š½D ýâ.ºQÞùÎ_]Ì—%×Ïت3©W$@2?d…°Õã¾Â`¾²ß³Þ׆>xÊ:ªÔý°™9•YæÒÊßÞñ˜¥ãë^:?Ü'°‡eIº¼¨-„~ä˦MÕ7W¥_ÓÞàÁ¥MxqÅß)w¾€Ì}®+È Á‘ÄâGu™.­Y6¸D£‰ý}KCîý§WçRPn"8U+Sœ÷ÂøÌûyvÝôL½3ìüî3QÁš\É–ä>¨UHC{ϊѼ•€Q¹!÷Å“÷.¼?;L9§ZšÒE¾é«v¥Ž}03|­˜6þ–ˆ¶9£,whœ-ÇËŸ­×;?zøpÙÍ„y8àŽ9Ë¥H»ÑHîÍÄû-q˜˜\—1άÄ.5HLUcß|{¨8óŒòZßÔç`äô³ÁPß½Q5åŽèz”=ûŒW0zúU÷Þ r	còRˆžÿžDCh-&¦)¬u#Å>"1™k–ôÿ»žÍÌÃá±N”vD#¹¢A窠›`_ÝxXÒÈwgÞ„ÏÙå솋ÛÈK+´CܦA"Ê
+âc§x~XÃJo(¦cé;‚÷ÿ¨š#1âŽøé}SUx °f=”4+ÿ䎧õZ›…HK0
+—€_úØî*Ý– ·£ý7<³Y6ªãvl¤ÎݱæŒú‹Ù¸™‡ÈÈc?m·Ò†h¡ˆÕ©Åç•¥RäÍ×”»L|âÊLwõø
Ρò°¤¼AçYKr¼Ï¹ÙÖJÑkW½b%òyQ·ŠTæ9æ‹Ló"$N¬½ôž‡9ȯòL¡åùö;û¿ZÆMú›¦Ýj{wAÆILTI¨£%èÔ&ëö…ôâÞ %§½(1ã:«/h•¶µôÕ9óUÖô”‘­Í¡i¬rÝxUæ¸ÂÝPÂ#á61”#,*@Š
–üb±·Tx8ÙÄç{ëG79yçÐê°ÀCþ“væ$Põ`Ò匀V–ƒÿþu6®%…Ùqc†¬Ó:†wtÎì•NôwØÒPÄv©*û&<û'ývýЊâ¹!ÔA"OýMBð¼"ðÛQܸ…ÍK)	z²>Ç'áØóô-oâŠÌ#°±ÛÓ­ÀD/&Ësgk7/;ô^D÷‡ÞKÉÁ¤ ŸCH-²oS<ÛõCoõšÂÛw˜´øŒª"ØK–_Š­"H‘¬ûVpÆsáõpa¡£_Ì×SÈÚua¯õ°Ü±l|ÚV±{+	wókÎ:¤6=s÷(HfUôRê¸zP¢[E ïcYÄEùºŽsûr~3§Ÿ°3ŸMÆ?å¦T‚°ÍZ5ÕèR˜±˜rL‰buO[ˆ`×w\ÁU·?‚‹œWà&ó+Дzu(“	Ø!ÌìÅûR% 2ú§8xdßÿó	<ÌЃ|Šˆîç}®rw‚RÕ:Mp’òÛBÿÉ]˜RòöÖ„½®íX((gÿ¶Ä?ɸ‹e»¿è­ÚXÄ`]¹#ƒÝ’X—ÕofQg	è¿ÏU„»7­‰¥äœ“sõö‘ý£Ëw5Y¬•ÓaM(Ã]Fƒn\^¥BW¢É–Œ~3
+ܯ*ù V}ÒD¦ÿôð¥ÎÈ
+}ˆÒçq=G/¦8õ6ÙüÍ/]Z?ó{P>yêU•œµú}éË2&@žÊå:Þä®þ;TÆ
+݂Ư9ÎÖïSftt7,-–‘hV©©<
®ÙÒ]+,àŒA‡Ø  •;…ÔzEå]þ<Ïßý‹ÌɤC™Ñ6ïðÖR®{ÒºsŽyZÍÒ+±êÈÜôÄk´ѤFÈZ‰!FÝmP€×:%•éd
+Ü)„lk2'¨á"€”Öó±âµ|syùͱÕe€\ûÊJ;YýMªI­‘_£ƒ~Æ1bfÓõÝd=–ÙþÅ|SÅ=UkΫ
+S­‚DÍ0»(ë%ªUÎ17%g:F‡°ÞZ?{¡ßs·1SÊ«„]«
+G7ôæøÆnuÒ{«ýef‚‰@ÆÚJt'D©Ñeèb
ÕÓþÿkŸ,ÛšŠ(
¢Ä’n¤Gw3pÔèÝH·„4I‘.é–îÝ%HŒîîÚ{ÿÃûí>÷ü€óá<ÏñÊ@J>N‘÷x°íþ®/Àï^ÈnÙv®Q’U	õ×=[#Cã]6öçÑŠŸ‚h&
’Œ# ëyƒòk»6úq
+ÅGÕkX:gׂ	še£¤xu®ôØ\CùqKå1¦g¡lø	7[Ù²Ì4Òÿ¹[PÞÿøç¥ÏFÔ´²ÿšûI#pŒ"­ªºóöWwxN¥&ÿÊYGúéÆ„¾åoK?\aùt@½=¥¢D#UŠ&ÐmÂ΃:Kó#˜´ÏÙf`ÃN¯Ú¬5}=ÿúfy$V·‹Id”-é%#©¾¯{z²5…رF’oö¾!²’»÷ØIáMØïä†H}ØÝÖR´x`î/Æ]è›Òª^3±Í7é¶ûñâ¬Â^µñŠ
+·(FLH³~å¶ÞÖ@Õ6Jäó¾xÌ0V?K£ÈÕJÑ}gy,‹¨†/ã©$þ¸Ì~“Æp\!#…þö/»-ñæ
–Ú3Uv+l•EM ´Dýý_O‰uò!÷¶:)
G‚·Ñ	é91¬ÄdÐ~í@§q&±ÑŸ<¹¥ËŠ)üÁžjÄÆpîp 	ãO`6ÿÓaÌ€“Ê ‰bœ›³ƒø*Ln•OA‚+«ä¿dWÍXäøkÚ—­ ÞÎÓÒU±?*›¢jžêß_
++µ¸¹­Cí­u†Æ…¥v‹øò¬WU˜}öÔ“LÂØÏÚ(kœ¾¨RoiÍ^$Hé~ÒøÈz’Tñ׿·xû0­®Åψ_ShúÜ2\o­EŠã¦=U´ž$¸_N	Ó–jz͉Q
+Žò2Oa}=AÀmãUv”'·ýÆû9û¨,Yó‹Äg“ˆÐ‰$¥°®ÇªÍ3|Zí-Ä
+ïùnS;ÝŠM‚­fˆðÓ%¸<%kDpu47û95%–T+G“¢æ×*T‹J<Èü«˜t‡'On¬ÄÂ.ÚrÁ.0£€w=J/ê_GppÄÒ A߃Ðd=F¹­ÖO-ZÁ9†àU‹¯ùsÃÄh#a™jÔì‚NÌ– tNcñ§VF¢ïÎ{Ȭ¦ˆUŠñŽ*Cs~ö²sg_ܱu™É¢QªÀU4“å²7+ç!|¸`Të‘…>“¯7º–s™as¬G&S]EHøáWIÁ`³“èÖöAÊ;ÒteÞÇ¢œauÛ,>:.²
+ðž¯ÔÏ´ZÕ׈‚œâ^ž>ñ·!eÖ²ØäÛ¶(¥/J‹@Ëz¼–F]¢wò¿ÝÓÏõwÁ/…=£ÆhŒcsËtö„t˹¢Æ1|Pú1—ŠR,·²ÖÑï„$8É
+,f¬S¼‚Ô·Nï¡Ó¡›¾¼xœñÏ‚È¥éJ#ìKÛ1íü±SŸä{årsê,<+ö‰ÙöÙœ¼U1*µþôD'î¿ð|ÂBÕF5Ç	.‰Õ+‹f¬æ-åuÝÓ±oFã”’zeí­ðÓ„A Ç«á±™—KØ+·,V	cšðôŽ­/EþrË‹î ×öëMƒ}#j€œ§Z¬R‰¾^¢/dõäx”z[]ï9OµÈŒý/Âæ7¯>’òT-)AB鈢C•§x”ï±IàI稂i¸t¿@€"JUîU}mÐ'sÌ’™ž,Ð~bèºAòFKEOlÔýðp€.Xb¢ùçöÞ†£EcÌ9¦È<üE¶0mª¥±|ÿléæ3‰•Ïý="þØæœÖ¦wÆ:—æˆà#!¦%Ö§’\Fj¦¦Â‡ÊIK°';Iª…¢ö}hë­w™å9²T¥tM¸JÌtü‘á,H‡î"ûDHÔz	97qtÅÝÄŒ‰ÂuØVqtîÁô™?'¯`¹NøÊù3²–œGÜ*˜é²HÚªÒ ¾|W]ò{êîTõÌqý]A÷,’ùÚäÊÖoU¯¤h¨,Œ¶‰wnmƒk¥ºþ
Þžê|f¿â‰™TJ8‡6¨Š5¢äÇ„ãÒ¢1,Ôlvˆ^Ìýµ•Žã¦!ã½ìZ¿ÖæÚYôšÎß×b&¾¼ÿÕ‰šºCåu‹Îø{é±Âf¹ªÛy¡	"|ùª<ärÌÌ„)=¤˜ï0gxÛS°^Ø«šéqGGÙàèá´àL–{ù¾±~û™ÓwéAÆH¨º…°íMÊe:ùf>
*®b&¸Fd!$xöœóhú¤ýGr55õž?õ'GžLqú¬ÀœÖÕéž´AA´F߃ƒCÛw
´VøsÞkw{竱>·0¾8ÏöÖ >¿ô=Hq«•3õ¦x:ˆé©d9QL ­þ°¨]Y¦šÍ"±J[^}ÔÊåâÍò"5=4Ÿ*«cuýiÛë‹%ïQˆu8aA#&S¢"\£¥å^u›ìèès²	×CbGó|cïî•ûl.lض²¡5·•Ÿò6Ëü¥“)>5“ܸþäc%Y
ÒZ}ϲJ¼G=™ìf¡»ínÈ!Ò[\ŠÒ^H0©mÄõ˜Àw'¯E¹íTŠÀ—±¶À˜•«qRð}øù[õ{ñ½ÈLðƒD߶ÔÐWd6¬!Í<ã÷é](XâJKR
+K› ÀöYt^¬evQ&57Ñ„t9Æ©‘;ØQLV2²ûËI2­U^¹¨%Ô~ŸŒ×ˆzW¶¤¾ÌÄi~=úï°VÕõZ5dw0uÃ{+M	VÅkzÏjG‰7¸zb4@ˆKPñ±Ë6§ð]É"‡ÇÂЗË×øVà]ßQè³ø%áRˆ¥¯>2àsÙsÍ@ü+§hœýbyZÃ÷-ý$ËbÇ;¨´²*	#Œ6^ÿ´Œ‹Ä*jj¾}5™üÊ­tÿg ›­ûá=)ìGõ™;RVÛÚ½wV*îM\ˆšhßn`ÇPÙºzÇ'I~©VŽ;&븙i—wâc3:™S‹åa¥40ÏZ:	Moè¥Ø~ƒÐ#YcÑV„³IF^¸Övú¾&ÕÍBoªzôåÒ½¢šºˆ<è@ÕŽ!ÄVo£Cé·³s~íAãŸ)4°jsY™ÖÑÁ¤¤Òøɉ
cxg4Hc=‰‚­|(—æ3§‘»Ñô¯ðÑqr1¥~tÓ™²süçŸVý;Ë}I†õ„=*š½Â!³ ®8¸²ù	¢Ÿ{J½ÅhJ$‘¹Í2ÕtKcÇZ=P¶)»ûøÔÂwË,û«øƒˆcÌm#ãdxÐu!^	Ú9ûi7ŸÙJcÔŒ]+µ
jÆ»Ò_€[hI£YÉì0…òÇ*껪¦úݳj€í¨ž¨ß`Ù?8sGx9g3ÎîèñÙt÷:n:—SúluHx‹œ›ÍÉPo·«ÃJAüÕh€ß¾ÅW'ˆÃô´B ¶q…¡Jˆ`“ý kaæ®´bg>–MO”¶æB8uk—ÄþÙ7)Çê®Ü¿5GVQ(ë¿P­m-FG*åTA¸¡WK2z)·	Ž×?3Ì›QOl
+s¹xŽ5WË–§zGϺß?ÁyËÇDóÛ8Þ6<,óyÊœ³%ɾŠaîjôër¤ôç ³L.¸!åeÖ&A—¯y!qíµ¸`Û®8&ƒûCá°ˆ×P·KÄMZQƒñˆR“!»V¸x3ËßÀÃ'£l{…x|#”ÄÒ,ò9r&tã|¼a¥ïéæ3sawÄø²Ã××ÿuåÝ™×Ãùv¦&R®É;Ƴo©5$rÇâ¯%ì»iÕav·4ËEìØÔ;E6'µ…¹ïh;ž7\oqkÙñ*¯u¾+ÍNcýàÿOÃõÿû‚ÿ
+¹ƒ%ÔÕÝÙêjý±Uáòendstream
 endobj
-879 0 obj <<
+884 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 2
 /LastChar 151
-/Widths 1939 0 R
-/BaseFont /HZZZJN+URWPalladioL-Ital
-/FontDescriptor 877 0 R
+/Widths 1951 0 R
+/BaseFont /RWLLBB+URWPalladioL-Ital
+/FontDescriptor 882 0 R
 >> endobj
-877 0 obj <<
+882 0 obj <<
 /Ascent 722
 /CapHeight 693
 /Descent -261
-/FontName /HZZZJN+URWPalladioL-Ital
+/FontName /RWLLBB+URWPalladioL-Ital
 /ItalicAngle -9.5
 /StemV 78
 /XHeight 482
 /FontBBox [-170 -305 1010 941]
 /Flags 4
 /CharSet (/fi/fl/parenleft/parenright/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash)
-/FontFile 878 0 R
+/FontFile 883 0 R
 >> endobj
-1939 0 obj
+1951 0 obj
 [528 545 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 333 0 0 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 0 0 0 0 0 0 722 611 667 778 611 556 722 778 333 0 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 0 0 0 0 0 0 444 463 407 500 389 278 500 500 278 0 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ]
 endobj
-862 0 obj <<
+867 0 obj <<
 /Length1 1612
 /Length2 18760
 /Length3 532
@@ -9130,122 +9187,116 @@ endobj
 >>
 stream
 xÚ¬·ctåßÖ&›£’Û¶mWœT²cÛ¶m§bÛ¶]±*¶­[ÿsºûíqnß/}ß{Œßšxæ3ç3×c“)ªÐ	ÛþŠÛÚ8Ñ1Ñ3räÍ­:;ÊÙÚÈÒ)Mlpdd"@C's[QC' 7@h˜™L\\\pd[;wsS3'¥š²

íYþ	ütÿŸž¿™Žæ¦6ò¿.@+[;k Ó_ˆÿëD àd˜˜["
-ŠšRòJ	y5€Ðè`hPtþien57Ú8©&¶«F¶6Ææÿ´æHÿKÈ`p´™ÿMºíþqÑì€Ö掎¿æŽSC§¿3p²˜ÛY9ÿCà¯ÝÄö_„ìlÿFXÿõýS´utr4r0·sü­ª(*þožNf†NÿÔv4ÿëØšü4¶5rþ§¥ùþÂüõ:šÛ8œ€nNÿÔú	›;ÚYºÿ­ýÌÎÁü_4œÍmLÿ‹-Àhjè`lttüóûŸéüWŸ€ÿ­{C;;+÷eÛþ+êq0wrZ™ÐÃ11ÿ­iäô·¶©¹
Ã?‹"ecb`bü·ÝØÙîú\€ÿå?;Cõ—„¡±­•;ÀhÇ oëô·$€òÿNeúÿ>‘ÿ$þoø¿EÞÿâþ§FÿÛ%þÿ{ŸÿZÜÙÊJÞÐúïüûü}al²€Þ+C‡ÿW¸¡µ¹•ûÿ!á?5€ÿ&ùÿ#ådøwB6¦a¤gü·ÑÜQÜÜ
h¬hîdd01´ú;©ÙÕlŒVæ6À¿Šþk˜:&FÆÿð©š™YÚü3z¶»€6ÆÿIþ¯Hÿ¢Î ùCXKT™æ?ßÔE)þÕÞIÕÝî/±ÿÑŠœ­ñÿ:üƒ!,lëð¤û{é˜Y8ìr21yÿªý†é¿Îr†Næní¿-32ý«ñÿñû¯“îÀˆÙÙÿ³+*N†6Æ×ëþq9;8üUõ_7þoÃÿóü¯EÝ€Fp«¿mx‚,Ò2Ój±r‡'Eµû{™À‡ƒíJTøUÛöø¦…ípU¼×Ó7Ns¶¹/Ú}ìKSŒöbZQô¤/óñ½I¨ú
-P7É;8hôJÓÏ4¢<¯e·!´ØÕv'•”õŠß¡¾Ow°8À\=Qù‘¸ø¡“>Ú!ù¥ÖÇbt¢4‚|«-<=#O<~z¤ê¹ìÛǣɉ…%ãq@$ô³ÏÁÐR«ð§‚JoBÀ»i¿ú$ÔèöÔË##Å%°–}U4Í_³i—}O‚LoàM”slݯüy=?É+”8Í5—ûµîL&æˆÅÛ„?Ø;kI8“	]O0üvMÙïæYk]MýÚ‡”»02£ÔYRïÚµOÆH7î\‰$ÒjçH桳,,c|/ͳ‰M|\ÔøÉ×Ñ;gYs&kœ«ëP›‰­HÚz‚qÒÄ^hØx#:0%;Øt­%?!IRt¦äÞáséÒG_æóÈùC¾*íž¡±D­³EvAõ)i´»¨
¹Ío)([ŒÔ‡+!Œ4Ž	óçBÖx¨ö×éÀQ†Û–Í·´Š“çALb¸Ù…B ß%5Vy>©•õ_CäåwÍO?Xjb¸ËRˆ¢kŠìßFÆW‘¦³Âxýùb1£ôB:^‘átlØèöÇóžˆ}† -ß´Ç-_†‘À=DMá¢y;3pîÜÇ£àí	•"¢œÍ‰pGÄ/çk~ú’DÎv}û
Î|è8|ÔpVx{DžØæÁù¬(™è“‹¿ònc‚"©jȦފòJøˆÚfœƒ¡J÷ôy¼5Œ³4©aÆGD‰–îQHA²;§Oý|ÍJÑs{+ø}Ÿ£ù-0 
<¦L¾F{@ºK4@Ê84;/ 
y¥)ߢ•èöp9ãÁuaÔqLä
z?‚Dô°°Tÿ	½ÒHt<êƒÑ`4×Úú
-'ëZ;/€Ü
–^dŸ”¹\
ô0:ŸæëFVEò‘¥0\^ƒŽ	å³Ý1wé¡•>Rh’`ÛêüÁT~Ø	QaZ­d®ý:<_µ\Lä…5®£¿ºyÃRxy^Ù@I?ÂÄ0ï–~ÿà·à
-U~-UÙ1`¿ôB}èÿ[à|ýÛ¢˜‘èþà éz]n¡·†ätœÍOîø
-é+¦ÞâwªÉ"=ÖšTÂb.Ê;9§D¿KBr•ZDIé°É¬/$h-5…œë¼_àï_æE݈P`„‰ÆA/Xâ\¥$jœPSj9ìùîåIt·¹özîk^Çqô„êò´GËhžÖ=ëxõ\Se”ãÒx!÷©8aYf«qy·BýÞHÜö˜ãfM¯ocþÊù
-eŸCN[hÀÌ"¯5sß¡¶s«ÒVÛBfžáœD(˜Ü¤胢&BˆóáÛ§Œ—=Ü9bª©s ß¨nZîÉÄõn^’¡ïg^í*ªüdïfº×D°>M*|™vži­}ç`1;s~ŸNÀê~m©Ó±‡„æ\£"écã9D^ŸÍ1ÿ˜,F»9ÿÙªø¥só=Ê>çR³¿N§EUÝ£¾ÊPäý60|õ‘³9&x¿«é:d=ˆ“ºª¯’!êö9šu96¯¬|öu½nX—n/:s€fHë¸ã~_±›PªƒÍ®Hò£}&Eåæ«ëO¸éT\“Ö¤ÍoMç9œÇ!©Góò	eLOÉuA¬¡#_Ôáhr/Щ6ßïÜ:´ëÕÍ©Ï®$V‘ILJÓ]Mèž	µÎⲇ 
@¾áÓË9äøÇZ›¨6ŠŽ¯7Ï©"Öħ1Ê™‚b½ZôL’ADe2EV]¼¤X*Aþ8€?¸AÝÈ‚ªºØHüéuyHã”Âs*þ¶¤ÐÏW8=IŠ0Å
-
œÉò;Fª¥)Ò—³ö­nEäûÆÀ%g5HF¢´`Æ÷‘1ÌBTï7íVcUðíÏsÔ5#LðÆ}Ì Ó]Ô^žNkHp<¨‹7äÛ!”a¿Ö9âì-OhGô¢µÍæ<¶ªKt VèLUjŽÒ:Ø€ íÚ²"A9ƒýL§@•­ÕÜjF×/áóæX±a¤“á…sy鞆v_Íï[3‰Ó ‰°^¡Ê-à¬ßŒ!œÙl7¨¦ÍÌÊdnS;Ó>„|d¹—.Ú¬fnßY“ã|ø5ýòbõ"éM¬¢øBÍØ-P_éÀ'´
-S4DB~Öõ‚iJìÞóex1tk/•m›ÙƒlÐÈÍ#ÿ}7©ñ´¸jL¤NB¬O+ϸWEõ{ç$3W¨† ·°‰ñ6Szuß²]wTé‰2åº
-r€Ð5™'­§øÌ·¶YPNøÌHý ú†C¦ÝÖïLS]Ý(…3¹p¬Ï–z«ôtNzTD¨7KŒ:®žh[µg¥Ñ¤ë­‰ ¿ø˜¹Ô¹¶âÂõA?Â}ûŽ>uÝ'9*Ë25ÄÜ£ýR¹'«3Ir¿'ãƒz‡&ù#uf9¯*¡ì@Œ÷OÑĬyáw‚ÀÙÚÞœ«‚ó—o
-s%Ú¸üf„ŸËcɣ穜>V†	x*sžlKÍ?–‰N£“í³Þ;TÙ6qoam~gfÞÃá¹b:èÅ `Âî ƒ3öæùfÛVÓT”75"úzEÒ²4Yj©sÊNõ Ñ?±Šèqu""¸RϹ·ÖÏð­f†¼ÀA'bϧð!KI4@·Ã‡u&“w]!&$ià}ߊ½£ƒimói×Y
+RÀCÔÂÙ—ð¤ü‡Ö†8ó1…œ)ÛC0H Éª­ÀP[¹@SÝ~w0æOÍ‘àÝÔ´#Þ%ì8MÖ™E
-t.Û½«½DŒ/vÄ”õf&|aªŠ«-÷­c†ƒY¨}ÇEWùn¾ß¬úvtÿtšúgÓ±ÇFé…ÁI{>2›Ðø‡¨ÏÂØ#7nPe…cÄ\k¾Boq_„t˜V/|å|ªeE2óFm<Þƒòc):¥¢@y'¿v4œ¸}!™RkÃKnpÁÿ"}ÏHj/Æ*.@¶B™¡áì8³h¨ûÂò0:z$X(q»®%ù9ÞÃX*´ŒEŸ|ÆB¬-$MXÜ/ƒ°I,Ø iÀ~™3Ó	&"sÐöb“–ZÁéÃÝog„F#º¡séc¡Êöïpð{Ž‡Lã³EÔ]¥™PÙu`Jvqíªi‘0ñ}ÅóEëg2!­Œ:¾~¤ÛS¶ïgãÞ¨e}èGóíÜ+¶býÂW¦âEñ%,ðÑ„U|έR†÷Ó¸	‚“7|Y0¦¡ÐŒ`c”h"ï¥]$¯ÙDøy–¢U”÷³*Ëö;•»°žˆž½X€Vºi<„#ÑÅÒ8ù³‰·5òNéK#Û”îËÏNï‘r®[nXôf$AO"Ý–¸SVµ¼7ê^Y´]VsBe÷´g¬KI^¹A5Çr &&# zK½q*Ø"¥¸ÅSäVOlMš­åV:ìH™/*go¾|¿Û^B´÷£sä™Í/‚¬¨+“`‡™Dì	žº,Âe…9:Cf!3M¯ˆNïxnÀ>9ë·ÞxCaSB$È7{Od¤Ôt †ðˆÍŠcÅø»,Y™B‹áºoÛâUûà¸Í—¢§²Â‡W½`¢ñ"•oû›‹¶»í‹èoœSªÛ>¢UÍAÃo+«îÅ
—6/¿es^“Y?±Py2C™‹-ÆŒEöÏ´óŸ{.Ô&fÓAÄVUþDØ×™
-´ÂØ÷þÞŒ4à…÷r
Å› ‚$Œ¾£Q`ƒ-`¬×ðÇŽMéˆüyÀœJØ
ò`’…hQý)*¡ $ˆY
-5Ëñò­Àóv3.]”T'‘™×_ìÎ"ÀT'8±ìƒJÕ2,ί„q;§oék9ãñÙ^¼è½þ#±ª‘l VgÈDÝ/tHõÿ¨ÀQ—Œï±<=fYM[=€7
µ¡éPÅ°¯qdt³a³´Ÿ¸®‰ViÉ}Í~‰r¨È
ºC`%ÐÔÖòü¤‘ ¨ä=ìíÈ€°ø‚x.«å_dÃñð,öͲôpù‚­NŸÛ®}§ˆTÎÒ¶iÒà_/á	z¡±íRÒ*Ø Æ 3ýrI›½Z }z+§ðEU-8¬¿¢u6ìú xõ+ðsFúÐÎ3à"Áw}EýlMÚv…U=Iö1ä³Ò±çŠ:lú¡‰àâåŸm•ôònG&±O4 ŽÇ³rŽÏõ¬ß’Š@Î%R¿~W Ø)Ø×\„Ý=VÎáܨVbkcà6æŒ#°ÅóŽùI4MœÑb¸ï=pû{níÒË%ˆfcY¨¬×¿þécaöyqÌÝ1¯Æ ì—n7
-4?äÀYÜéV“yö2RS¨àÆ`{š,#JiHÂâ-ý»€ëbú@ùðsºÄÙÙÇ5NJ;Îið’s7?†™YJÂ’F4TïËý´äb„RêK,k"z’t&¼pwÛkßò1^šDFO²ÌÂ>1Ñk3V¾îÈNŽD{¶æDJ™¼oæà”1•±ææ¯\ÒeÖ/žôG};;’%Ú¨A{½Eì–6¿nn†  ê¢Î,%*îp5¤=¾š£Íi
-Yت^éιAÈ•Ë5í
-Ñaµ+Ë“º±\‹0ïdÅ C´Ð²(Ó©Öצpy§’éÛ …oû x#z–ÓŽú­iÅ6„_´'Æõœ¦?óØ&¢6ºT&V@t½E­B:3ç|¡7›Ãù)èq‘ y#釪sfWZâH«abzTÆcóY!ë>=ä€Ë„—ö†ÅŒÎF1-Ùòò}\Ò|3GŠXi
-TpndØtº7ù)åç«sç/4ƒ8ôÃNE#.VØjÑ6sÇþ·Šª,o¿¢N(Þ-Ú›:ŽoLªḻ9ö8èš?&f¾>©¾*æËäIâ~‹zÅ}HôäX|]ˆ…–5Ö‰¤õö3›‰ø/(‰[ï ˜Vîb6ðÀ—ˆ¨ÔÆ¿<—ªîïáõÑc{R‡vº±£¹ôRåpõ«ý—T6xÍtd=úÈKgû% º`I)„ê6…xVdLñK±¯“þO{e§Ré÷ù+Poõ šZyßÝb*óë6§ï½$¬ôG u\>Ì~ó²=]ÞkÃOáGùÀâ¼’þ4SËÅuÖ¦Ç5´ŒšÈN›Q;|8x
-ï‹i’6RNbl¨°›
(¾/`Á%àÁ¶åæõ‹¹ÙpbO$s™Ø¶€ŒÑ¾ÖÛw@‘ÖD“Õ˜‚ÍN"­K &.MæÊj©úŶžÔì¿(`\5ÛZ µ2kyD„¬Î[ï*¦à"þFp›aÿ
Xf˜¸ÎTb»}-»
ÎáÎB%½8ê 
U‘6J‡(ê¢ØÀµ–…Fíªãʜ؂¯ÀX-ô£-Ýñø>‚q'«o"ty’ЄP.Hòöf;¦—囦
-èýJÇF@´ø¢umŒ¯Æ8|‚…$³(ßUH§k‹ÖÐÓà	÷¹eeÕmÖGJ•#ðœ¶k%ââ];$ÖJt ‡Ÿû?`ö„i¶Iq~?•°©Âá/üªÄÕÎk‰ÎX¬Êù˜³SÜÛ¶‚ÜHvòÅ¿¯ö—Slöèeî‹*bN¿ÿe¾¢\h¦µð®ŽRöã
-oçë÷¤¸Ñ^u¯LÇåô¼ë‘¡—–‰È/º¸ïr£ìu_
-¹ÊGÜ.×÷ÂÌ?áw…_«DP×vÀÊîúðMEi‰Í;èÌjêL¾ÓÍç¸×l£ÖJáðœ4ݘ$í$©QøRdàdzFaÆ
-±aÆ°ö¤ûÐq#Ê õ;–>ußЂÑȲ¨ûÜ
î(x­Ô>|»zsÇöMïÜÚ
¡<£²€*¬R¶nè«jt¤g6ö!;¢nÖDJ®Jí¯/i·2»K’HŽc1äÄ¢):ÙØ^Ãô¢šù…Íí>ŒôkÏ\@¡fËyñ6“é‘úGÔPÐ艋ª£5nôXþ8…ZvOçkŠV7ûüÒ6'wÊÅrÒVrô‘àÔóµOoü@	”Ç}žìÃ3_k¥Wn~—	q°ê€Â¡NmHN¢ö.U¿_¤dNß9h‰¼¤‹8
@Qpù7Y^©Æž7RØ‘{ǵºÒ´±Î—ÄA¦WM¹	³xûû’×*îÞ¡Þxö\(ž§/2Ÿ@\ꩉãù>#ÞÐFÕ³«
iøMŒ”™?E¥´bC3%ê5îæ{ÓeR„Z)o
UE4´oÆ :[qt˜O¹èðuÙÎJ’ÔàW-º¤–yÃ*¸Ü,ºqï7ô/fÁC¬F¤œslÂïJc–R‰¬È3†›…ˆ¸î*\ª‘nu”Íooˆ[í)0"Ï„äÜòR‚zƒi"ÖbhÖ“
ÀI8ŠeC’µ¦½`ò6¬¬ÙÈØ—Éýüv¼ÏvB¡¹†5ÃÌé—|5˜,óë··'{Ÿ$ÿ0ØvYR~=2·NDá…Ü…´²ðAC£´ïK‰	t¾ú¤ÅÊ´Uäfsä)_©ËŸ÷º1Ó—ÃU»»bî¯41Ê„kÄßF(Ä
-AQé}lߧ‚>œ'Øoy=Û“õÀ!»šp£vSO`MÚ
-ÂEdqðÏVŽ<[^/à•‚³mQB(ÉJ4åïPÓ%›ù5`¦—¼<áN]´ÍrªuÓD…8#¯U…ÑxšŒŸžþØë$@Ñrˆ ¥åpT_ç6þ3$$mýñmmòkŠÊƒ!7gN?¥÷Ó
-4“R¥VU»4¦^¡ËþõúB–üLJ#£·nγsl€tŸh‹P¢ÀB¯B¡1ÔÏ’‡’ÀmA8onTƒ¯üàŸœŸ™@©5Ý£	m>è|Ìãé$Œè8L¢äë×RõC™u´„î0a\*;­A°0‰ì…ÀÏ?'ê=¤†CcÕ×ÇógEw{ñ§X<¬Ö«Î§¢¯‘Ö/¬+±]éÐf¾ë{Î"²Â.`W_‡—ú¸R2´
¬	ÑßèûnȨ÷„W:È%¯Qý#?‡uÓÌá†8p¶ÄÖKê"“`t@º^õÛ“TºXÔ+©eÝy,NÄ™‰âJcì³¾ýóiówh²i©1K½à#<í‹6uƵ(E
-¬Ç¿Ñ¦‚¤E(#ÍËŽâ~qõ¥]ïãDí
-zúÎ}™‹KŠcw|¤ªïhu•ëôSˆÆ¡ÐãË­„[ö:Ò-DqnFå†üô’êP>Âz^ʧÁÒÀ”¬Ì»›~–[T¸4عâXïîif%ŽE„óN˜¸þÒ:Í“dõ¡#d©ðº+†ðŠÊoFš{ÈY_5¡»$ž…Sr25Õ¼îà>Ó ë°+a“^r8Æz5³w
³„­JÚ%uàÏŠŒ²¥oŸP,ã¦8(+{(š\‚J)æ}kŒné?op¡Œ®_@U<º°4Êßo‰ÔYÞ<ìaÁ ŸMˆ§õcDÏSÆ)ÃêNiñZMEèG5­:—ÜüÂ.Ì{á¥Åu[R½Q0È›®iÔú#ÅU·@„ñ`lˆ-gb”Ŭ\ÏŽXIP'°(Gý³»`š˜º„€B@BÖ&íOrÒKn°ÉŽ‡{ûgÕ.V­„Óá™ÔëuVO¹©’›¦ic{b¨þÈí‹5D«Í÷‘(L˜žkVADõ½mÕTŸÃb|kÊ"¯=^sfÉ̇ ø.Íþ¦úzƒD?¼fd¥òCRØÇ”½²c+‡ò¼}ÌÉ?	Ž²69>jí™e›W"àùï
-.^7=º6Š2#0Ÿ“8uGzƒ)?&¯~Ó&Î^ma€ÐÎÝØ”ÉUk‚Ï]ûl ’4Já–‘—ªÖã¾ß‚•è‹ˆzN“Uæ§z¡Ø„ðcÃÀ4¼âeºsÂiŽ˜›ÈÈu"ÂXÐ MòÂàwB²Iê­Ã>¬qø´d†É¼•§Ç.m"£ûˆëDÊ!‘‰oRêS´½)™FÚêaÜ.¹½<ÙBý2ƶðÞ+ôBƒÐ­¡+-Õ›3ãò¡5ŠÚR" :zïEñ>©-Óæ°Îg‰lL8y$º›³Þ%µÙJÏX9?ænµ‡äFóà–®Œæ4GÕ'‡“ç@µ-–ýp5i~Ìoãø†Ž…·r–½Ý¢_«
-)׆þ®ì¸}Ÿð‘„¨ÍŽà”ÿâMµ3ëîDþþF·X#›Vx„¥Šš9—ÅÁ¨¢S@§¾Õ§+Öf.;™•óÛtÆçÕÍ&…¸eýÁˆQ³ý
Qi†•hOr{jY%ÙJw¯ÂT„—lFt{¸ö81÷(Â¥…ô¶äÃÊòûb2ÒJ8cá”ˈÒbÁÀm¼J&­Z‚A
-Õ!R3|´î|ܽ$uà×­GY‚œ	æ{Âx¡  ~.œú&[qæfôð†hZ³O D_‰Ã`z™7ÊMìòMA•WsÕ [ž„væsÅÜ!ƒØ^ZÉ»‘wïFÞVeGò‚\l¹ÑS\Ÿeæ"þÌDnÚ‘15Nôz{ƒ¸Yów0[°	ukz?¡Þì%¥
-Ü0†Ç/OLj[É|Z«×Ûž<Òí°4ûº·Dɇvk5A´oã	ÌtAÔ”	
-çHBžO+Ú‚ÄîóÎ"«g,Ç}õS?3Ù³”“´§+Ôö·V¥+ÂÜÖ/'Ên³÷^ö/€Õ…Óÿ곕µ°€ùÙ?"0ÁAÉÃ\(à-ŸÍ¹À/¾7mù±y}ýÔm“ýmùkìµ4#±$ß”
-¢0ÓžœÇ‹·z´RÒCfwMÎ-‡Ý
’օʹºwvE:…n6OAÆR	.
½Ã Kæÿ>©´‹™Ü¾hiÓn#Ç*ëÈÎ^ª‹{n„œƒ|Q‹évÝ	5¼ã›ènB	uv%ò9{d|ÞQP>CöŽŠß$qˆÒÊšÙ8”Ç­š¥«­u#Õ¸)«Û×¼¡ëSœiQ¡zJõÏA*tµÓ¦¤§	3;Ûtès-|b~0~B-Z)ñBšª©*·?ƒæ–+[L’0o!ìÆ»UÕ‹B"Œ¾ªÏ5jdÝi·©dVéc]Ð[æa÷Ú(i³ ¿=ב;†L íu߆+YÙÔ¯jÒðoAs-á÷!Þ;ýÈž8íöêš«Î~Ã0À„
-Œè†²}­°[^­ÄÊ"+4´Ÿê°»Ç[èë+SˆR·sQª‰’ŠYHX¿™ïC6ñé|W$­µÈ¹ê1±£×Kì¸ËG4ÄÓ:£å9d8—f‘%¬-Uo—@~<Í‚¿<ÀÂ/OY„рƈŸ²7	9ÿFL!Ë·$À#Í‘»%#“ÂÏ®À!¼d^ûÉßì#r8ç7Ôs¹ùáÃ@óî¤D((§vL¼ñgà³wKKf8Õ–u±M„ ,GìÀ±„#†áÎ7n$\*Âä2Þ
Ví/@3*Û¯¦"üÔHÏÄ»Tm’k7ìècƒÀ¶oÝ…æpxVåÓ{'ŸÀVÏQ@Lv¥ày«§ ç-{†Õ#c¾Ùy·Gö=…lL˜ÀL[×nЩ2oY4êðÌûÖË•÷>BX^M4UÓvŒ„l0gz
-ó½ýÙÍËF£jkN°3½WäfÜÁ)8+í':º/¨%²+žG%$Åw·í=¾tÀÜ~ÆéÁúäi*¨ÐuÙ>lû2{†X’GVM"¹ï§¿äØÞóŠ-I¦./q*#Ú-ÍÌûS­n®Þ~¿5f58O&Ó=ƒSµ@·ŒVÓÃܧçOPkÓÿhÙ)&ÒªîÏWfzv,Þ6ì,Ïp¸êÉã7­‡ixÔÆ­SÆ;Øc¹}¤ÛUŸV¼ðœxç.»wQ~ßÓJ3CÙNcYB»Ñƒ¤3Æ›õ?­ÔæuÅXŽÝʇÌ®þÈ}‹b×"¼ô)ÿÆ;Ñ€¤ˆÍ
-Ú‚+m.'ª®ãæáLVò ÊacL-À³…KË+@±ù~àI mªÎw3$‰/pKx÷ÛNìvþBͽ2ÛÏA‹É]`Kmâd¹êuW‡¶oŠ\ˆ©/QÙî„„!'Ìqzî¿æÞ`rŒjéÒÍd‹ß”¥
-¹•úÑÅ0vñ>R0Þ{W8ý34®H‘ó£îH±±­
-—0oj+tóH*ßj<šÊ¡ÁYzdÍ¿f1hJãg<+ïa??Â…VMQ·IŠ´Ö`ÁÖK)²jâ‚·8óK×…
-t‚i]ÕܹQ7•¬¶">ø'2cq’ÅuE}sÀ£e9L&„MrÐ`yOCÀ´ó'{›HPO˜ÒoÅø8ì»n·Šš¹Î1è˜(]zš¦ÊÜ÷ŒDÈQ–Í’>¸iŒYñvÃ×LT%ù+0&—¢1BµUkæÞê«–Ì«l
-¶Û2g§yö$®ö*Îæøe"'WèÖ£“C
N1.-ÖsÛòQí5rJ÷ÛYAQ&¢V1R7Œ¾'NI,Ÿ*˜å~Ƶ”›~÷Úrò9!ˆcV†aCPµO;;PÝÌå³(t>ƒ¯ì~0Óâ&ý¥tdW)T?&ÔzISÆ—µ Ñéô9óóŒl|—T¶·ô¤+NÓÄn“4üÑ«#éÜ‘ñÑÄüÁÉ֕aã_.›+A¯@™øêSÈ3•'üp‡IøÐÌySzùO‡´æìÍ®¼Ck;ë2O3Ô‰áy/sT²—»ŸŸhŸúĈäomg…Zˆ­‰fº9ðþÒnjĹ.&i&ß7AŸÀ’\aö(±V­J¸ãnÔœm>	ØŸ) þêy…ñålkMO¸éX8VEdàŸs][»NÆoñ3F_4å`}†v,ïˆnd ‚ì’تLÚB+;1‹h²QÀú·î´¢f)²kß8OÒ#õ:‰É°*NøG0Úðž{Ï·¸Gâ3]ÒB]ÝãŸeõÊUút–Zä¡ÛQ*He'3u}š&ºaVÙ0nÂ_å·	Ø5J泧Þ;R~&ôc5Æ¥:3…/ïì&Ó¢.AðáÁÎƸÃÄžR¿nÈ€¦ã~E2Kâèš”¾³klÌM"÷mkòù¶Bˆ)™öøï¿¿ÓIF{/õð·לuù[Š“‹ÜhV¥<õ!1QÏG)9ì(Å¥
ÒtM ËëqÌõþ¸]%tƒP]¦ûtàÆ&Ks:!lg‡€†)®7ì,èøÔ:Åaäæá·ãäQùÔò=•ÃýnÙ,×À­¼kZ^IºgàÁô.uQ³÷},Œz“¸»•dA@{â^@±ÝƒžÅ&ýþ°Æ¹rVL*ç‹jïRf§ž¦|ú¦ØhwFjPÜ{tnãðž¸Â1LM‰ðg6þ>¬€ä¨è!³ßO’N·3PsÞvz¤' W›Bb×÷d•ª;ì;Ъ"j7Ž”‹98ô©å,³ÑÕ4ÛÕ-뀌éÂçË+[ã®fΠ´=5"ëO_Z§ÝQýJå÷#	;~Æ×:¦ùOuP2Ãþû9¿™Úã†ß°q¸D’!ˆñÛü"Np G“óTI¹Düˆmuáê°q¤boówH/Xâ¼¹vbh™‚79}Øži•0!5mù'p¸ªŒÍ-ÖЗXéçQdrîá•fè÷ëåÞ1ŸdÅ˛Σã…ê(?ÞOCüUd;â±ñ.&-	ÆÍ á©UÃ&ÄlÈQ¶œFWüÊîG˜ç;!:XV†à
Ž«¦g.šÆÌ" ƒâÝ`”Âp¼](G¦•|ªf?„ËÄŒjݬ~h2w|¶A™¿îÇ숚ˆ‘u	#S0g0XÌŠo	æ<
~°fC1å¹TËI€I¯v8ì{0®BôÂPœŽì>@;QÐÃ'‡³
†êÉ2$¢b(ŸÜ~¦rŽ}žjÈê	6G\æ«ëVáÃðšOD©h#Œir~7úsaóÊÀ?Ô³©§²ÆÍ9Õܯ»
-%*RŠ
8$	²Bí¦®ä[D¥ªÝ«ÔGÆ;üÑh<®^‰¨´ÑE—@$|ûÈ89O\2¾ãw3ÆRæò…iŠR)ÇäN(˜$	âBd ±ÈÔ: ¤cCœšÒÅãE…É<¬)2@5ø.½’ë"¼ë'óMÂÛçœÌ„8
-БQöw>}N·>¢Z[@ßHÀ—ÞäN—÷“$wŽp»X0õ•Äƒ<±´Áí¼sÎ*`<Ñú¶øAF‹/©=J^®üݯ‰TÿýŠCX	k¯”¢vÈ´ªøƒßnÔ«Ó¨ÉŽ:ÁCò®E~$œ-b™¶ëþto©ýB5÷ªF¶¬ïϾ¦´]çnÿ¾ãçz£û-&úiý½®€Q“²sxGûÑû¦I`¾|R$I‘õ\‹àX.áçëÑMdù	ØGË7DÐÁ`lÈÒák‡)*¢mÁˆŠ‰£ä¾цëmhQ8ð™’¦;¦eP‰Ñ£EçòÎïZ¶úAI
-¦£Ò턳`à*ùê™>÷)›td¾ñlË•]“î×=í
-9l¿»YªjËŠÍa™°Tt÷W.™”Õ>/žú„	VݪdspÏ#¸îú§+^üƺ§h¥ÔS-b©\LÔåg›llª¦¢,#Un¥`ÙD2ïÑw^´îWƒ…jžÚòHƒ,ߣ4i´Ø$ƒšš4œ¤c„\œÐ9˜n³žK=F™•S'a&È6cS4	EV×#ž°Nšy’ QN¦]ˆ‚{4)gáŠÈZó±ñëÛ¢¸$¶§”tÖ©ç<
K·fÐ2o„mê„‘iª:Ï”)Ðö¬×ø,m/@=ÉFËi‚tÖ²$Q."]å+&•²jjÄD™Þ}Û­n38e(Ö²õ²·™s,ÒõáÙĽëÃîñ¦Öà#”
-,
kÉ÷´éhÏ·.rLgâ×hž„—pZ??ÎË;@·aQÞ¦fÍ‘Á£˜ÁüÒ,_g+õÇDê–[ÖË`lƒÿmjC“½
µ‰¹ñ•«ßyÁÙUe°M	©P21=ÑAC6R²ãxÖ¢Ó»ÌiI˜µnþ¡twÙW|$Ø©Ýv;Œ4âcƒäy.,üôFÖm@Ë1›ÚÜÒS½V%¥
òN)®#ò÷~H}ç†/œ¶CDÞË>K†·Õ04y\·ç¤Í¨ƒÎ¬VD©?qúÉ´K¿¸!˜Ù6t’m3ã˜B.
-ÂJY†Z†ûš|ý4-¼©‡ôÄÖ/äNø&vL‰¸y)û÷oæéÆ¡s¨Fâ²JJ–à!`²K-TîÍ$\\8fÇ®Ÿ™ºˆ¤]z‹9L9‘Ïÿö4ÆðÞ/Tþ&š¥ëÕŽÛîäHŒ7ýø1ô°’ë{ÇnŽrbÍ¤à„©7ëã!ÀÎ|#^ìñ›C§.Öçì1Ê"‰	>B÷‹=^Õäìb—bu/ÙÒXÄ‚™Oå§kY‚O)™:&Bç|i¿ôÚ¸rŽ:7q.8VJG±Ú–=
-¼œggÍMÛR9éà½Ù»T¿Ø6žft»@ã.‡±v¸g8ËÃ7ÖÇËñˆùƒs‡@JE¢ ÌL‡²¾ì§£é-ø?ÝÉ8݇uÊ I·ï*"3 Ò÷ËVA¬¢Õ-
¡Z"ÞÆmU{/)tŽÎ›ð?KŸä~_†ÜÙšÖ¶lâ’¡n˲aþq+—ôú¨¤ë1æo/+žQTËq&ÕHdn„Ô¾u
˜Ñ­-ëMåÇ‘sÿÉÅ™[tœ¼¨øµŸÀÄíÞ®ßPx|òúËüá‘æ/¨-epsƒÛ;ʽQÊeŽÍYszgÏLf²Ê%—â
-‡3¾•þ4¡´°Ç4s©Ó(œ#qp6ßïȈLÞè¹xÌ9ÿ*Ͻ-+\NÆ"ìÊלý4±ëè“B»5ýû/VQO‰Aüp
ÈÄ@ˆtö·­ã*EÕV0µ¬7Vn¸¨bÍ[u?¹CöuJ4,Òk|_Ë­|Ïë2•`k”äÅhÅEdÔ<üÉgÁÛ{Ôrä5ø‹›o{Ÿ¬cy¯£ÓJ¥Ò/âðÉÞ28Ê8®9!úzÕP“¤¨x÷6`1©ÖÝ`¯îOzó€Xú8jvƒXq¢™°£»kÌí²¶¡‰2D¾ß•‰”uaôBAwõúà‰¿
-€ÞŸ|æ`xFÎärãiwÍBÄt·Ñ9”kE‡-ñL¡•´]^`ƒ|ðv?B@ÕÚ,eç¼oì.9‚¿‡ú‚8ÛƒïûÝ
-2h°Ø‹­ˆÓçBJ6
	rD÷ öy@hÓ©A˜orÉbo»­]hdçb;é^ûxw^c»{$¯öw÷ª(:©]Bæ?0B¨Zt=qsŽ»_ý¾$UÎö×ÐíT!
vMIöM»ªéKk¦øy"Óî“hŸQ¨¿tHg½Å#v³Ë¢¹(^Ë×"F¸CáßÚï~µÍO[ŸåÇ•ÖZ²Æ~!íg‚dö¯hÙ¿¿«ðÉ×_j¼ºÞÑñ¯EAåƒß€MŽ›_ô?¸M¼½Ñ¹t~ŒÜ+ìSVáu¤T…r©¡l®¥Uƒ0P;Þ‡™OØ~uLáÑwöÞ5gL›É+Êj/1ˆwv_›Æª¥µ[þ±žœh…{eóåa"ë‡u™rÔc§®–㶭=üdxí†ã%û¡AUì÷È+×¼Ô4ÞΔEÞ°•ÏØ„ç“ø¡´ûèâPz?¢†Ú mê"ìvbîdU‘Ö¾”ñzñj3¹¢¸j&ÁÄ~¶§‹»‘LͱZ
-É5w½‚'☺²¡tg‚ÉGѺÐäQ`Æ9vÉlpúÿÖ§ÿ¢^ʆÁ.¸7%Ò` ã±¬Fœ}a<õŽÞµªž2Ȇ´h¶”RÒ`k‰ÉÓUúÞê¤/˜÷¢ú¹«É«¿ð\”)$q‘1)Ûÿ~3w¿,ᶉ:—ŠùÒ¬®ÊÊ€W6	Ù ƒé‡~ÕiЩ`’××»žÉv ˜rGK/ÊBˆTJRÌZ[¡}ÙAöˆóÛ¡Ýå熫"ø`™Þ[þö‘±U1²ѵÀÈyþ¸ëhBØ…ÏÃÌQ)¼é‰e‹@Ÿª"´±³ÿ2ŸJÙÒe5>	9UV„jTÔ׳4ašG}„Ç᧜5ÅHgQz>ÜØÕ"oÍ£i:,®Zƒ…[ªŸo[¿¢!cÝÛ)èu3oÁÜKÄÏ6W
Þ¯"Ó 
”ÚðUAtE©

¿#Ibz£±'»PæÜä
-	!˜s¥8cs;ªÄj­ÌÜfºô#·Ãÿg:‘s2$Œ©ˆ×6'?^1„4=Wk¯^éßÈsê&Ù¸e;ìðìÐégªA¬½Ù¢vXþ]ïz¿Y¬ÍrôÞ=
-Þ?”XÉÙTVà†Q¢›‚3=A(ÊŒ®?Ît??xnkà1›Ô›ÔÚäŸA`ã×0滬²tôŠ¡Œ»*!ÂFë¾ÈÕÁ(»L lô-eFf×Å
-§,Éù¾Nª„8’sŽ±©U WSi—³¶,keõ%ï"‚×cQ:Á`c„†3p›	Ò£ïטvv„_Y†)„A(@n`'7)$P²tJíòkÓp?
¨OÝï°¸>ózäö	o"DXÓº3Êlª‘ûÁ†êÙKß±6ÎÀš9ŒÌ9‘寧«Ÿ#Áâw©üljœ]rlXÀfñêjéÙÖ	ˆ¹œqwLLCÖŽ¯ËAŒÍƒ•è­0|¦·Ý¢fZ/Ç
-qH	{ÃŽÆ¡I<Ü“QvÏÍ‚TD†¶ßûu|s˜ÙöoÜœ¼ •ÁáÊË—1™­.·óüe|î÷œzzEݳÝ
U1d•1°Æ½™Ä<‚Ǩ‹Ç/œapbÑþ?íÌ÷?à3ÎÙdds_ël_ûÎÞ;33gwÈæì’³ÇÙ„ì2Î(ópvÄÙ+
-eËè2R¼ÄûÛûyŸ?à	·Cžtж‰ä€¢rªØt°W¨ÂÃ^Ã>\\hŠþ…¸­£éÝÓùÞ©e‚&
-ŒÙí?ÄSËÜ·7¦Mwv½	r#aCp	ÑÁ¤»Ê«Z²â™×?åYó›j‚foM¤Ž¾ïhWò÷%Ñq.4ƒ5ÍÞóŒ®:žªFï€uI|Òxóstóår}¤‘(º…íOëËD›ïö0C³Xò™Ï­mtý#¿#/OÙÉU5ƒ|¦ðžË%åOŸ8+‡!ðÕÈïÆÄ»Þpi¯ÏÊ*ÓK(’èÛ¾½ÙR„n9 ½i3Í“~i/]L‰ÙA•+®ƒ¬-ãÐúˆ¿”X£Ôëë"M3µ°hónf;ñˆYþÒ$qW½ÒG_¹jcR2š×»‹7¨Š}r¼áègJ?%Lë9bBú<–ŽÌ&f·´È’Mµ½>ºç|lÙQs-
-Ï7û1'»öoσAü¬¸²a«Í¡K-é¢äþ{." xÊDïùÐæI~˹G=Ö±?‚§>Èyüñ°“NÐ%îIß×µ¿è4É^)Oïä¥ç¾®ÁÉ’F°³¥1ŽžzÓ€SÚóJîi¸g_
~`ñ›1E!ûŽ±Ö]Óhcotí¿AàçUpö„ß*&"-š{~gò&ú{
…rO]ÉOœ…È”[‰„î£-•;J×VAЊü$JJX&Ê×"é 5
-¼ØñÆV¼_±  ’™c€AÆ
-€~g´¦™L#ZeöܬðrFVU
-¨ì¿öžÓpÇ£†äH¶Õ2Señϵt(å¶õOÖt†Ò[	\„¢73}ñƒça-ø{û9…Ô8‚Ãõa8K<ªä-™£UÍZˆjzìɲ¦Omuã–‹
-|BÖÝB|kæZÄ@ºÛt7B5úÿü¥/Òµ׃1šòò‚Æû±®¸—ÜQZÖ¿S^©Àþz?§â7*¬UÌ‘Ž´Á9a¸|ø2DyúQZg‰?D[á4m|‚B–*õ¹÷kîìDRºÚ0„¾ýç–É­wó~ýØÒPÇü>?
-»ë~÷aœ¿nïOÝp}ê#Æ)f’’¦„?BË`„ú~R(hà'Ùç¾óì
ØÉ»žOÛšù.»ûe<™“1êÌÇÒïÒÂfÔÕóÏ“¤òÞ!°(íTLÈÃÖ¥råúDÌ|–ÐÅ8Gä|}¥|è+ÏTPDpƒˆíJN5ª,»sa}èàÝ!/ÿhEî:±‰–ÂÖuL¥èmzÍŒÈ%áØß+pJ^‚…®Ù†V§óÕ7ƒ°	3¡‘
áâ9zU¯Ì…‰ò;é–Ÿ·(Nâ°­|&=×ÝÉEr4GîÇ4ê˽/Vñùén:,'劘ʕc(x^µ@$ÛL‰†¸æVìP¤ýÄJÍÏD{¤>pV$QJ¬©ô=˜Ð9Úp€Õâ«ùD¤å0ù_‡b>éRêVtÃÖ ÄMd~„Ýl{‚òsÉÞ!5õµPÓÎ!ÓêÕ±·ÍˆoÅï$ø4÷µ£e!Ó†R©û,ÞΦbŽ†lŠ\›»ÆÈì\Ùú$Rk=›‹Tö°
-Úð­,6äX€qÐ-}nJ®k^¨£ô@l€¼ÜI>Œ˜×TqÅOшتxín°úâ…õµ4JÌäÅVkw¨Š‘þI’€¥¤\°^0Vò˘íep«%"h*
êmQôB±Ýë“ÙÏXšEÿ¶Éµú0üöA•ÚªÏPbÑËöê6EL7‹:Æ6ÒpÑÁå»ý%Tñ4w bBY6Kn8¢slG›‡œ	.ôˆdŸ*‹îí¡ï8‚ìu)+¸"xJmKMÛ /û’oË3ÌkŒÐ‘ÜãƒÛ’ÍËïÌk‡;/°¿‚ë’àU¿n¦NÔí]…6sÍ£¹ÛÉi<9s„pÓ4ìЛ•E÷³¡{¨Î¸›Ñ(@£ìª–8¥C©·g{foU>Ñ™vù¨µ«IÈÜÞPœU›K)ʶZQýmk ·çƒe~cs3˨Œ°2è£ßÕ ¾ÄùNs´Añ,ù¡H¾…¼ÀÅt••å;:
-œ•F“þ/Eň¢M—íîÒX
=r‡K—+hö¦­y¢–éx>39+¥¸®¯k"½…Çl÷ÀJí„MÚÜ8ÁYËÜ&F¶”´Ñnýó'¶±_t¯…´²ÅÕÛ¥ ¼”žŸö8Gojü=ã6ÀçÞ}IP†C?äy¹l÷×MÜ8ºSJ§Y´%$<-ãw¼S9ðJU&tŽÞ[™#ÅÀ½5‘µc§O&QNðoMÂM/	…Ìþæ2¼`ÕE”n¼]QàѨPØÅA9TM;x¸á•3O‰­X»ãÞä»ÎúF_s„"oêoì9‘ö-Z%×/ÌÓÀ¨LÒ¬ŽÇçDrU‡¿¶Ï­š6ÞxÓÂï¯Å÷†½®w~¿Î~ÁX0nïýe´Ý&¤„’Wm»Š)Ôšë2ÒÄ`ÇŸ­B¢ž}dMÞ xì)㟂ñU‘dIÂçÍÊ>`O‹5ö7ÕKõ 5ñŽ£ÓÔ‹Á}äIZ-™óDZ´[ŠkA,è3úI—ãq­«E2·:±AÚJÇ‚p9lrEèp¢V —2JÙçï£)m×·ÇѾ&\!H !Wuy§|õ
¸ýkI±3ÓËôìünŠÐŠµ¼J§UÇ‘º;Ë÷Û\»#QÆ>‰E¼ßå
îÜôÕ7;w“«)½VM.òHfÜ7$fÒzVÒþ
®:ëÍ©Û"Ä%yF#u»¶b1:î£Î¦Ð¦ºwI§âtß±.bïö:Áô|š·!/ä‘×…lEŒ];\PâéƒÀJ-†ùfï\gX?ÚÝbÊâ¼q#°È™JZcvr›”)\MUŠÿ½žØ«R#óÞ*{OÙ¥òó£SØÊ3«uS¥Ò+¦Ë?:ô$±ó4£º‹Õ±™o	°Î³d
q‰ÿ|¡âWV¬I¾ßxo¦Ì=ˆ4Šž%,²——Tí–]x-«GU}¡:¼@šëäãÕô´:+VfÀiIÆx†‡Ë2Ë–„\ü_¢øð?¸ùº»Áý\}(þ1‹ß
-endstream
+ŠšRòJ	y5€Ðè`hPtþien57Ú8©&¶«F¶6Ææÿ´æHÿKÈ`p´™ÿMºíþqÑì€Ö掎¿æŽSC§¿3p²˜ÛY9ÿCà¯ÝÄö_„ìlÿFXÿõýS´utr4r0·sü­ª(*þožNf†NÿÔv4ÿëØšü4¶5rþ§¥ùþÂüõ:šÛ8œ€nNÿÔú	›;ÚYºÿ­ýÌÎÁü_4œÍmLÿ‹-Àhjè`lttüóûŸéüWŸ€ÿ­{C;;+÷eÛþ+êq0wrZ™ÐÃ11ÿ­iäô·¶©¹
Ã?‹"ecb`bü·ÝØÙîú\€ÿå?;Cõ—„¡±­•;ÀhÇ oëô·$€òÿNeúÿ>‘ÿ$þoø¿EÞÿâþ§FÿÛ%þÿ{ŸÿZÜÙÊJÞÐúïüûü}al²€Þ+C‡ÿW¸¡µ¹•ûÿ!á?5€ÿ&ùÿ#ådøwB6¦a¤gü·ÑÜQÜÜ
h¬hîdd01´ú;©ÙÕlŒVæ6À¿Šþk˜:&FÆÿð©š™YÚü3z¶»€6ÆÿIþ¯Hÿ¢Î §"¡!¯DóŸoê¿¢ÿjï¤ên÷—ØÿhEÎÖøþÁ¶uxÒý½tÌ,ö¿9™˜¼ÿÕþÃô_g9C's7€öß–™þÕøÿøý×I÷?`ÄlŒlÿÙ'Cã¿ëõ¿ÿ¸œþªú¯ÿ·áÿyþ×¢n@#¸Õ߶Fö¥©F{1­(zR€—ùøÞ$T}¨›ä4z%ˆégQžW‹²ÛZìŒê»“JÊzÅïPߧ;X`®ž¨üH\
+üÐIí|ŒRëc1:QA¾Õžž‘'?=RŽõÜ@öíãÑäÄÂ’ñ¸@ ’GúÙçà	h©Ux†SA¥7!àÝ´_}jt{êå‘‘â’FX˾*šæ¯Ù´Ë¾'A¦·ð&Ê9H¶îWþÀ¼žŸŽäJœæšËýZw&sÄâmŸ
+쿵$
œÉ„®'~»¦ìw󬵮¦~íCÊ]™Qê,©wmÚ'c¤	w®Diµs$óÐY–1¾—f‡ÙÄ&>.jüäë賬9“5ÎÕu¨ÍÄV¤?m=Á8ib/4l¼˜’lºÖ’Ÿ$):Srïð¹ŒtéÇ#/sƒydŠü¡
_•vÏÐX¢ÖÙ"» ú”4Ú]Ô†Üf†·”-FêÕˆFG‚„ùs!kt>
+j8+¼="HOló‰à|V”LôIŽÅ_y·1A‘T5dSoEy%|Dm3N†Á‡P¥{ú¼ÞÆÙˆ
+šÔ0ã#¢DËFwˆ(¤ ÙÓ§~¾f%ž©Y·˜"<Ø™Él¶‹Ç¹ÿúä2Ý©²HˆîKöÿ¢Õê’2|Cu˜Äï4‡ÙbIYY`AýÝ«!ðc*	w¡)óÊ~#†!åÌDŠ¹p¼šÖ™(bðÆ%łߪÇ4òsœ.劎^Ëú0ª†'>
+dÇ$[ß4˜h3iï*#§†]Y·6_¡$l¥—\5Š´
+ÖƒGÒgÏt7êz \ÄØSÂèÑÝá	Kz¬Å~»šF£¦s>y{­)ÕCóaÑýû²Ú7×	Ý#ÓF¾o¯Q2v3äòÔן¼xÒ¾#x9s¬(ÃÇÊÒ÷öUX7Žqb‘ŠŒHö;QºÙö³ˆÊëí:²5p,sÍŠ˜VÚÜýXQý3j.jWô…¼¬[Ç2#oîä2’«²6¢£yé0O ÙÓËø8³)Kz¡l„ïzä^骟|‚gOH)àY	îó¸¢e¾,Ùê›Ì,ðŒ‚þ²Êsźy&Ê⥄ñϤì*“@bKiyäúk@WÁ»¾/ÿë÷îÆ5
Ï##êáù@¹‡ŽRƒ;ÇË6ÈV|¶å9{<)¼ç	QU+ó؉¬@"9ãå·¾9Ì-–†Æ¬»î³ØŽÈ³¼…„e†tY.ž±áWËÔÀ;žš¹„PfÙWÐBNûŠX÷a|nÓd5ÕR©¡Ûo÷¿]fǧ_$¿å0[^ž‚IpƒVzrEÄsÜó^Á¤ÑÏJó„½Ë®Ïô—qŠž€3«Çþt¿ipôøɼïÆ/ÑøµÑ7d™§©M’°{<1†/ß{€"Ãg'”Dnnë«J0VkÜ„},j6ä²6”ª’nå'Ž`gâ[ö
+õ	Ò””d³3þˆA*ú<ì;»ãçëȈÏÞr‘U¦Ξƒ	¸R64yEIÝ#ب[@“4ÂS»Ð¯«±÷è(pÖg/ä/ÄX»ÐÖ@­Å»b¾äcŠÅIî n¿¿„îçç3Ã"çU=^ó»\XºwV¯”¡ûB:Ï‘
+[—ÒØ$ ´zEø}:µ`s(éHô‚Å+X—³÷¶*5Â^ÁmøÆÊ$¶ïÉéGH
+>êò:Û†ç-àñwN‰
+3“7º]Ç }"}xt¿-i7Ÿè¹½‚•
+üƉ¾ÏÑüІž@S&_#‰= ]Œ% ešPŠ†¼RŽ”oQÈJt{¸œñàº0ê8&ò½A"zXXª‰„^i$º@õÁh0škm}…“u­@îK/²OÊ\®zOóu#«"ùÈR.¯AÇ„ŠòÙôÐJ©4I°muþ`*?섨0­V2×~„/ŽZ.&òÂ×Ñ_ݼÇa)¼<¯l ‹¤ab˜wK¿ð[p…*¿–ªì˜F°_z¡>ôÿ-p¾þmQÌHtðFЇt½®
·Ð[Cr:Îæ'w|…ôSoñ;ÕdȇkM*a1eˆƒS¢ß%!¹J-¢¤tXäÖ’´–šBÎuÞ/
+p‡÷/ó¢nD(0ÂDã ,q®R5Î@¨)µŠ
ö|÷ò¤ºÛ\{=÷5¯ãƒ8zBuyÚ£e4O랊u¼z.©2Êqi¼ûTœ°,³Õ¸¼[¡~o$n{Ìq³¦×·1åŠ|…²Ï!§-4`f‘ך¹ïPÛ¹Ui«í!3ÏpN"LnR‰ôAQ“!ÄùðíSÆŽËî1ÕÔ9PƒoHT7-÷dâz7/ÉÐ÷3¯vU~2‰áW3Ýk"XŸ&¾L;Ï´Ö¾s°˜9¿O'`u?‹¶Ôi„ØCBs®Q‘ô±…ñ"¯Ïæ˜L#ÈÝœÿìUüÒ¹ùeŸáS©Ù_§Ó¢ªîÑ
_e(ò~
¾áÚÈÙ¼ßÕt2ƒÄI]Õ×Éuûͺ›WV>{€º^7¬K·ƒ9@3¤uÜq¿¯ØŒM(ÕAfW$ùÑ>Ž¢róÕõ'Üt*®IkÒæ·&„óÎãÔ£yù„2¦§äº VБÇ/êÀp4¹‡èT›ïwnÚuŠêæÔgW«È$&¥é®&tÏ„ZgqÙÇCȇŒ† ßðéårüc­ŽMÔEÇ×çÔkâÓåLÁG1‹^­?z&É ¢2™"«….^R,• ÀÜ ndAU]l$þôº<¤qJá9	[Rèç+œ„$E˜b…†F΂dù#ÕÒéËYûV·"r†Š}cà’³$#QZ0	ãû‡H„f¡ª÷›v«±*øöç9ꞧÇ)$¥!€4%J)Æ«B¡(kèè^«£ Œ¢K"ôŒÖIQ§.¾É°UDBó€â¼HÛHzõV¢’éç5柑&xã>fé.j/O§Î5$8žÔÎÅòíÊ°¿_ëqv–'´#zÑÚfs
+[Õ%:P+t¦*5Gil@ÐvmY‘ ‚œÁ‰~¦S JÖjn5£ë—ðys¬Ø0ÒÉð¹¼tOC»¯‰æ÷­™ÄiÐDX¯ÐåpÖïÆÎl¶TS†ffe2·©iB>²ˆÜKmV3	·ï¬I‰Àq>ü€~y
±z‘ô&VQ|!æ쨯tàZ…)"¡	?ëzÁ4%vïù2<€ºµ—ÊŠ¶ÍìA6hä挑ÿ>„ŒÔxZÜ5&R'!Ö§•gÜ…«¢ú½s’+ÔCÐ[ØÄx›)½ºo
+Ù¿®;ªôŠD™r]9@èšÌˆ“ÖS|æ[Û,
('|f¤~}Ã!Ónëw¦©®n”Š\8ÖgK½Uz:'=*"Ô›%FWHO´­Ú³ÒèÒõÖDÐ_|ÌÎ\ê\Û
+qá‚ú a¾ýGŸºî“•e
+™âîÑ~)Ü“U‚™$¹ß“ñA=‡C“ü‘:³œW•Pv Æû§hbÖ¼ð»AàlmoÎUÁùË7…¹í\~3È
+ÂÏå±äÑs‰TNŸ	+Ã<ˆ•9O¶¥fÈËDˆF§‹ÑÉöY廙l›¸·°6¿33ïáð\1ôb°	a÷	Á{ó|³m«é*Ê›}½"é?Yš,µÔ¹‹e§úPh‹ŽŸXEô¸º\©çÜ[ëgøV3C^à ±çSø¥$š ƒÛáÃ:“É»®’´ð¾ˆïÅ^ƒÑÁ´‹¶ù´ë¬†)à!jáìKøGR~ŽCkCœùŒBΔí!$ÐdÕˆV`¨­\ ©n¿»Gó§æHðnêÚïvœ&ëÌŠ":—íÞÕ^"Æ;bÊz³N¾0UÅÕ–ûÖ1ÃÁ,Ծ㢫|7ßoV};º:Mý³éØc£ôÂà¤=™MhüCÔgaì‘7¨²Âˆ±b®5_¡·¸/ÂH:L«
>r>Õ²"™y£6o„Aù±RQ ¼“_;N\¾L©µá%7¸àÀ‘¾g$µc [ž Ü80›=~Øü.¥T¿†ñ¥™^šW`/ž$8¢%S>ô”æý XÞ$'ñ.ά¡¥„2Éÿoƒã;At«!Äò‚´žÖ&\Åžã™dn£˜kjÓ¥³< -YRç˜oiæUìÚÆ‘ÌY	Kî%?ê5TXrz¶ë[È/¨£=gU0‰Ü„€UShW´1ûºzcw™>ÔXê1§†S\»²3Š‘ÎBaʉ@,ŒëÂ?/ßu3u¤ð;…®MXÛ;Í0¾z“ƒE9–T¨ÕÖ[x,ÐÏsô1Æ÷Ìó–Q£×©VNcÌ…ËrÖs,¨ ³“eeµ‚l€N0j—;î~÷–ê2›ZoºäÆ
JR¸¬Ý.nìÿ¦ÏR(šF½qqIéì{7¸–lƒ%Jåíi6.’±ñNJ„µ­~d¢Jă÷^Oß«ÑÉs!¨kgw%¼¤ó_†©ëÂ
+??zÜ…¤Ÿ'PìE¶e6¹-Vƒú£ò>áÂPe†–½Í•Gèf5©{AuÔ¦JÑø^V¡ÌP
+:Ù‰4GÌCe*Z­:?ß"íÖŠS$`ë¾*~=QîFf†£¾d5 ?Užaú9v¢÷"“T!KÈ
õð;[ùÛCµÛ²Ñä$|É•ÿ#]±·,ÄgåÂc>t-ƒôÏ/c!Ö’&,î—AØ$l‹ˆ4`¿Ì™é„G‘9h{±IK­àôáî·3ÂF£Ýйô±Peûw
+
8ø=ÇC¦ñÙ"ê®ÒL¨ì:0%»¸vÕ´HƒŒ?˜ø¾âù¢õ3™VF_?Òí)Û÷³qoTŒ²>ô£‚ùvî[±~á+Ó
ñ¢øøhÂ…ª>çV©Ã{‰iÜÁɾ,ÓPhF°1J4‘÷Ò.’×l"üˆæ
¿D9TäÝ!°hjky~ÒHTòövd@X|A¼—Õò/²áxxûfÙ	z¸|ÁV§Om×¾SD*gi[‹4i	p¯—ðƒ½ÐØv	)ilPcΙŒ€~9¤Í^-P>½•Sø¢ªÖ_Ñ:v}¼ú‰ø9#}hçp‘à;‡¾¢~¶&í@»Âªž$ûòYéØsE6ýPÈ¿Dpñˆò϶J
úy·#“Ø'PG‡ãŒY9ÇçzÖïIE ç©_¿+Pììk.Âî+çpnT+±µÇ1*#Xd4-.¹.f(܌̠n{Sš©|ãPtw90¿Ì§­ã=tÜr•xÿ’Yñ©Õa…@.i¾™?#E¬4*872lºGÝ›ü”òóÕƒ¹óšAúa§¢+lµh›¹cÿ[ÅU‚·_Q'ï–íMÇ7&U6æØ‹{tÍ3_ŸÔ_óerˆ$q¿E½â>$zr,¾.ÄBËëDÒ‰ú@û‡ÍDü”Ä­wPL+w1xàKDTjã_žKU÷‡Š¿÷ðN€úè±=©C;]‹‰ØÑ\z©r¸úÕ~ÈK*¼Æf:²}䥳ý]°¤Bu›B<+2¦ø¥Ø×Iÿ§½²¿S©ôûü¨·zM­<ƒïˆn1•ùu›Ó÷^Vú#:.æ?¿yÙž®ïµá§ðƒ£|`q^Iš©åâ:kÓãZFMd§Í‡ˆ¨><…÷Å4I)'16TØ͆Nß°`‹ð`	[€r	óz‡ÅÜl8±§’¹Ll[@Æh_ëí; Hk¢ÉjLÁf'‘Ö%З&så@µTýb[Ojöß	0®šm-Z‡µ<"ÂVç­wSp#H¸Í°ÿ,3L\g*±Ý¾–Ýçpg¡’^uІªH%a€ÃuQlàÎZK‡B£vHÕqe·lAW`¬úÑ–îxüFÁŽ¸“Õ7º¼ÎIhB($y{³ÓËòMSô~¥ã# Z|Ѻ6Æ×c>ÁB’Y”ï‚*¤ÓµEkèið„ûܲ²ê6ë#¥ÊxNÛµqqŠ®k%:ЂÃÏý0{Â4Û¤8¿ŸJØTá‡ð~UâjçµDg,Vå|ÌÙ)îmÛÁÎn$;ùâßÎWûË)6{ô2÷Å1§ßÿ2_Q.4ÓZxWG)ûqŠ·óGŠõ{RÜh¯ºÎW¦ãrzÞõÈÐKËDä]Üw¹Qöº¯G…\å#n—ë{aæÆŸð»Â¯U"¨k;`aEw}øŽ¦¢´Äætf	µŒu	&ßéæsÜk¶Qk¥pxNšnL’v’Ô(|)²FðcˆÇY£0c…‚Ø0cX{Ò}hƒ¸eÐúƒKŸ:†ohÁhdYÔ}îw¼Vj¾]½¹cû¦wní†PžQY@V)[7ôU5:Ò³ûÑ
7k"%W¥v3<ú[j¬ån–E¿kƒœm»ŠìŸ×—´[™Ý%I¤@DZrbÑll¯azQ?ÍüŽÂævFúµg. P³e†¼x€ÉôHý‚€#j(hôÄEÕÑ7z,œB-»§óÎ…5E«›}~i›“;e€b9i«À9úHðêùÚ§7~ Êã>OöᙯµÒ+7¿Ë„8Xu@HáÐG§6¤'Q{—ªß/R2§o´D^ÒEœ (¸ü,¯TcÏ©ÆìȽã‚Z]iÚXçKâ Ó«¦ŒÜ„Y¼ý}ÉkwïPï	<{.ÏÓ™O .õÔ‚Äñ|Ÿoh£‹êÙÕ†4ü&Æ
ÊÌŸ¢RÚ±¡™Hõš‰wó½é2)B­…‹·†ª"Ú7cHЭŽ8º̧\tøºlg%Ijð«]R˼a\nÝ8†÷¿ú³à!V#RÎ96áw¥1K©DŠŒ?VäÃÍBD\w.UȇH·:Êæ·7Ä­‰ö‘gBrny)A½Á4k1H´?ëÉà$œNŲ!ÉZS†^0yVÖldlƒËä~~;Þ¿g;¡Ð\ÚaæôK¾L‚ùõÛÛ“½O’l»,©	¿™[§
+¢ðBîBZYø ¡QÚ÷¥Ä:_}ÒbeÚ*r³9ò”¯Ô¿åÏ{ݘéËáªÝ]1÷WšeÂ…5âo#”‰Nb… ¨ô>¶ïÓAÎì·¼žíÉzàá]M¸Q»„)ˆ'°&má"²‡8øg+Gž‹-¯ðJÁÙ¶(!‚d%šò÷F¨é’‹Íü0ÓK^žŒð§.Úf9Õºi"‚Bœ‘תÂh‚0æ£Þ·/Dž¿V™¹6j©Û̇‡o—
+_0ß9ø™Ü®Á³@3&i¯)BBD‚Òr8ª¯sÿ’¶þø¶6ù5EåÇÁ‡›3§ŸÒûišI©R«‹ª]S¯Ðeÿzý!KþãÑÑÛ7çÙ96@:áO´ˆE(Q`¡W¡ÐêgÉCIචœ7·@ªÁ×N~ðOÎÏL ÔšîÑ„6t>æ€ñtFt&QòŒõk©ú¡Ì:	ZBw˜0.•Ö 
+X˜DöBà矉uƒRá±êëŒãù³"‹‡»½øS,VëUgÈÓÑ×Hë‡
Ö•Ø®ôh3ßõ½@gYa°«¯ÃK}\)ÚÖ„èoô}7dÔ{Â+ä’רþ‘ǟúiæpC8[bk%u‘I0: ]¯úíŽI*]¬NꌕԲî<'âÌ€Dq¥1öYßþù4ˆù;4Ù´Ô˜¥^ðžöE›:ãZ”¢‡ÖãßhSÁÒ"”‘æeGq	¿¸ú‚Ò®ˆ÷ñ"‰v=}ç¾ÌÅ%ű;>RÕw´ºÊuú)DãPèñåVÂ-{
i¢87£rC~zIu(a=/åÓ`éÇ
+`JVæ€ÝM?Ë-*\šFì\q¬w÷4³Ç"Ây'LÜi
æI²úвTxÝCxEåÇ7#Í=䬯šÐ]ÏÂ)9™šj^wpŸiuØ•°I/9c½šÙ;ˆ†YÂV%íÇ’:ðgEFÙÒ·O(–qS”•=ŽM.A¥ó¾5Æ·ôŸ·¸PF×/ *ÝXåï·Dê,oö°`ÐO„&ÄÓú1¢ç)ã”au§4‚x­¦"ô£šVKnþ?af¿½ðÒâº-©Þ(äM×4jý€‘âª[ Âx06Ä–3±ÊbV®gG¬$¨ˆX”£þÙ]0ML]B@! !k“ö'9iH„%7ØdÇýý³ê«VÂiH€ð‹Lêõº«§ÜTÉMÓ´1=1TäöÅ¢ÕæûH&LÏ5« "ŒúÞ¶jªÏa1¾5e‘ׯŠ9³dfƒC|—fS}½Á¢^3²Ry€!©ìcÊ^Ù±•CyÞ>æäŸGY›µöLˆ²Í+ðüw…¯‰‡›]E™†ÏIœº#½Á”“W¿ig/€¶0@hçnlÊäª5Áç®ýF6PI¥pKˆÈKUëqßoÁÎJôƒED=§É*óS½PlBø±a`
+^ñ2Ý9á4GÌMdHä:a,h&y	að;!Ù$õÖaÖ8|Z2ÃdÞ‹J‰Óc—…6‘Ñ}Äu"åÈÄ7)õ)ÚÞ”L#mõ0n—Ü^žÇl¡~c[øïz¡AèÖЕ–êÍ™qùÐEm)PF½÷¢xŠÔ–ŒisØ€ç³D6
&œ<ÝÍYï’Úl¥ç¬œs·ÚCò£ypKWFsš£jƒ“ÃÉs ÈÚË~
+¸š4?æ·q|CÇÂ[9ËÞnÑŽ¯U…”kCWvܾOøHBÔfGpÊñ¦Ú™uw"£Û¬‘M+<ÂREÍœËâ`Ôщ) SßêÓk3—ÌŒÊy‰m:ãs‚êf“BܲþàĨÙþ†¨4ÃJ´§¹=µ¬l%Ž»Wa*ÂÎK6#º=\{œ˜{áÒBz[òaey}1i%œ1ˆpÊeDNi±`à6^¥
+“V-Á …ê©>Zw>î^’:ðëÖ£,AÎó=a¼PP?N}“­8s3zxC4-áÙ'Ð@¢¯Äa0½ÌåŠ&vù& Ê«¹jÐ-OB;ó¹bîAl/­äÝÈ»÷
#o«²#yÁ?.¶Üè©®Ï²
+sf"7íȘ'z½½Aܬù;˜-Ø„º5½ŸPoö’RnÃã—§cÄ­d>­Õ‚ëmOévXš}Ý…["äC»Îµš Ú·ñfº ?jÊ…Šs$!ϧmAb÷yg‘Õ3–ã¾ú©Ÿ™ì‰YÊIÚÓjû[«Òaîë—e·Ù{/ûÀjÂé‰õÙÊZXÀüì˜à äa.ð–Ïæ\àß›¶üؼ¾~
ê¶Éþ¶ü5öZ	š‘X’oJQ˜iOÎãÅ[=Z)é!³»&ç–ÃîIëBå\Ý;»"B7›§ c)Œ—†Þa%ó‡ŸTÚÅLn_´´i·‘c•udg/U†Å=7
+BÎA>ȨÅt»î„ÞñMt7¡Š:»ùœ=2>ï((Ÿ!{GÅo’8DiåGÍlœ
ÊãVÍÒUŒÖº‘jÜ”Õíë
+ÞÐõ)δ¨ŠP=¥ŠúçÇ ºÚiÓNRŠÓ€„™m:ô¹¾@1??¡–­”x!MÕT•ÛŸAsË•-&I˜·ö@ãݪƒêE!F_Õç5²î´ÛT²«ô±.è-ó°{m”´YÐßžëÈC&ÐöºoÕ¬ìêW5iø·Š ¹Ž–ðûï~dÏFœöN{uÍUg¿a`BFtCÙ¾VØ-¯Vâe*ï@ì	@uòQµ
ä8L°4§2Ir©¶Ð“†¤o§¿Ù	§¥ëÁIÆtPÕ'ÆiÎâsëŽÉÇTЃF`Þ™0Úu­5hJ»½
Ù‡,KíÜкÔP¡f|éO7§Hf|dÑr^kç
Žß¼¥'@>¢íð@‘…„—Ä”ÄÄJÄÞ¿Ý>3„Œµ¬èZˆ›Ù¡R^XÚ9ÈÍjÕy0”Nš¯s„gA‚îWˆ™[Uú	£™2õÞzבl‡KØ6`ñ
+î†Å×°æËùß'™+¹O?àªH‡q@…ÑQœÙ–l.vk	-3Ô+¸GçQ@CX<¢â*î>Ö‰?7ëÝSY±ƒ°±÷a~ü¨=j ºíd„¾‚þÔ‘"Ød±ÊUU;•ÞÆrÝJéŒ$AøZ©uëÎñ³‰W´Bšgûû±wæp'Øbû5莵Ë#—½ë
¿É¥M!¹q¼V@«ßÂ=¼8жœÃñ!r1†À`^6]ÈÊü«o†c\'7 V;:šb˜€™Sì
+…eȤ½øÛ ]Ûq};—¼¿ý%W[J¨÷¡¼–Þè	aÁþ[Ò-@^ŸFðGH¿	ìÏÈÜ°<·eÕ@wô¨‰Îy«(‘«xd;{”«‰U¸otÁªDÕL
+˜ªˆÍ|Îóp—aÜ^§9Lî÷‹¥¨`=1OþLˆq‡p–*ÃsqÇwŸÚOuØÝã-ôõ•)D©Û¹(ÕDIÅ,$¬ßÌ÷!›xŠt¾+’V‚Zä\õ‰ØÑk‡¥	vÜå#
âiÑò2œK³ÈÖ–ª·K ?žfÁ_ž`á—À§,‡h@cÄÏÙ›‰„œ#¦å[àŒ‘æÈÝŒ‘IágWà^2/Œýäoö9œóê¹ÜüŒða yƒ?wR"”S;¦ÇG^ˆø3ðÙ»¥%3œj˺Ø&B–#vàXÂÃÇpçŽ7†.arï«ö •íWÓ~
j¤gb‹]ª6ɵvô±A`	Û·ŽîB	s8<«ò齓O`«ç( &»Rð¼ÕSÐó–=Ãê‘1ßì¼Û#ûžB6&L`¦­k7èT™7„,uxæ}ëåÊ{!,¯&šª‚i»FB6˜3=…ÎÀùÞþì…æe£Qµ5'ØŒ™Þ+ò@3îàœ•öÝÔÙÏ£’â»Ûö_:`n?ãô`}ò4	T躉l¶}™=aC,I‚#«&‘Ü÷Ó_rlïyÅ–$S—‡—8•í–æ
æý©ŠV7Wo¿ßγœ'“éžÁ©Z [ÆN«éaîÓó'¨5ˆé´ìiU÷ç+3=;–ov
–ç8\	õäñ›V†Ã4¼@jãÖ)ãì±Ü>ÒíªO+^xN¼s—]Ž»(¿ïi¥™¡ì
§±,¡ÝèAÒãÍúŸŽVjóºb,ÇnåCæWä¾E	±k‘
+^ú”ãh@RÄfíÁ•6—U
+×qóp&+yPå°1¦àÙÂ¥å Xˆ|¿ð$6Uç»’ÄŽ¸%¼ûm'v»!†æ^™íç Åä.°¥6q2Œ\õº«CÛ7E.ÄÔ—¨lwBÂæ8=÷_so09Fµtéf²ÅoÊRaáÜJýèb;†xŸ)ｫGœþW¤ÈùQw¤ØØV„K˜7µºy$•o5MåÐà,=²æ_³4¥ñ3ž•÷°Ÿ
+áB«¦¨Û$EZk°`ë¥Y
5qÁ[œù¥ëÂF…:ÁƒN„´®jîܨ€›JV[‘
+ü™±8Ébº¢¾9àѲœ&Â&9h°¼§!`Z„ù“½M$¨'Ìé·Ç	ˆ‰b|ö]·[EÍ\çtHL”.=MSeî{F"ä(ËfIÜ
+ˆ4ƬÆx»ák&ªˆü•“KѡڪƎ5soõUKæU6Û‹m™³Ó<{WûFgsü2‘“+tëÑɇ¡ˆ§Ç—–Fë¹mù¨ö9¥ûŒí¬ (	Q«¿˜?©Fߧ$‹OÌr?ãZJŠM¿{m9ùœÄ1+É°‡!¨Ú‚§¨næòY:ŸAÈ‹Wv¿˜iq“~ˆRŠ:²«ªj½¤©Gc„ËZÐètúœùyF6¾K*Û[HzÒ§ib·I	þhŠÕ‘¿tîÈøhbþàáDëÊ0Žñ/—Í• W L|õ)ä™Ê~¸Ã$|hæ¼)½ü'CZHsöfW^È¡µ
„u™§™êÄð‰¼—9*ÙËŒÝÏO´OýbDòÎ7Ž¶³B	­DÖD3]‰xécFb\“4“ï› O`É@®0{”X«V%Üq7j·6Ç„ŒìÏõ¼Âør¶µ¦§@Üt,«"2ðÏǹ.Š­Ý§ã7‹ø£¯šr°>C;–wD72ÐAvIlU&m¡•˜E4Ù(`ý[wZQ3‡Ùµoœ'é†zDŒdØ'ü#mø
Ͻç[Ü#ñ™‰.i¡®îñϲzåª}:K-òÐm(¤²“™º>ÍÝ0«l7á¯r†Ûì%óÙSï)?ú±ãR™Â—wv“iQ— øð`gcÜabO©_7d@Óq¿"	™%qtÍGJ߃Ù56榑û¶5ù|[!Ä”L{ü÷ß_é$£½—zø[HŠëNκü-ÅÉEn4«Ržú˜‹¨ç£”v”bRŒiº&åõ8æzÜ®ºˆA¨.Ó}:pc“%„9¶³C@Ã×vt|jâ0òFóðÛqò¨|jùŠƒÊá~·l–‡kàVÞ5-¯$Ý3ð`z—º¨Ùû…>F½IÜÝJ² ? =q/ ØîAÏb“~Xc„\9+&•óEµ‡w)³SOS>}Sl´;#5(î=:·qøO\ᦦDø3ÖF@rTôÙoÈ'É@'áÛ¨9o;=Ò«M!±ë{2‡JÕöhU5ŒGÊÇÅúÔr–Ùèjšíê–uÀ@Ætáóå•­qW3gPÚž‘õ§/-‰Óî¨~%ŒŽòû‘„¿Fãk	Óü§:(™aÿýœßL
+íqÃoØ8\"ÉÄø‰m~'8
£Éùª¤\"~Ķº…puX‚8R±·ù;¤‡,qÞ\;1´L	AÈ›œ>lϴʘƒš¶ü¸\UÆækèK¬ôó(29÷ðJ3ôûõrï˜O²âåMçÑñBu”蓼!þ*²‰ñØx“–ãfðÔƒªáFb6ä([N£+þe÷#Ìó,+CðÇUÓ3Mcf‘ÐAñn0Ja¸Þ.H”#ÓJ>U³ÂåbFµîV?4™;>
+Û Ì_÷cvDMÄȺ„‘)˜3,fÅ·„@sž?X³¡˜ò\ªå$@Š$ÈW;ö=W!za(NGv È(èᇓÃY†CõdQ1”On?S9Ç>Oµ
+dõ›#.
+óÕu«ðaxÍ'¢T´Æ49¿}
+„¹ƒ°yeàêÙÔSYãæœjî×]…)Å’ÀY¡vSWòÀ­¢ÒGÕîUê£	ãþh4×
¯DTÚè¢Ë ¾ŠŒ}dœœ'.ßñ»c)sùÂ4E©”€cr'L’q!2XdêFÒ±!NMi€âñ¢ÂdÖ |H—^ÉuÞõ“ù¦?aÈísNfBèÈ(û;Ÿ>§[Q-„- ï$àKor§ËûI’;G¸],˜úJâAžXÚ€àvÞ9g•0žh}[ü £Å‹—T€%/WHþî×Dªÿ~Å!¬„ŒµWJQ;dZUüÁˆo	7êU
‰iT†dGà!y×"?αLÛuº·Ô~¡šŒ{U#[Ö÷g_SÚ®s·ßñs=„Ñý}Ž´þ^W@ƒ¨IÙ9¼£ýè@‡}Ó$0_>)’¤Èz®Ep,—ðóõ覲üˆì£å"è`06déðµÃ•GѶ`DÅÄÑrß‹èGÃõ¶F´(øLIÓÓ2¨ÄhŒÑ¢syçw-[ý $SŠQévÂÙG0p•|õL	ŸûŒM:2ßx¶åÊ®I÷ëžvH…¶ß]„,U5‰eÅæ°LX*º{Œ+—LÊjŸO}«nU²9¸ç\wýÓ/~cÝS4ƒRꩱT.&êò³Í66USQ–‘*·R°l"È÷è;/Z÷«ÁB5OmùǤA–
+ÈïQš4Zl’€AÍMNÒ1B.NèL·YÏ¥£ÌÊ©“0d›±)š„¢«ëOØF'Í<I('Ó.DÁ=Œ”³‡pEd­ùØøõmQÜÛÓJ:ëÔs††¥[H3h™7Â6uaÂÈ4UgÊh
{V†k|–¶ žd£å4A:kY’(‰®rŒ“JY55b¢Lï¾íV·œ2kÙzÙÛÌ9éúŒðlâÞõa÷xSkðJ–†µä{Út´çŽ[9¦3ñÇk4OÂK8­Ÿçå Û°¨oS3æÈàQÌà~i–¯³•úc"uË-ëe0¶Áÿ6µ¡ÉÞ†ÚÄÜøÊUƒÆï¼à쌪2ئ„T(™˜ž‚è ¡)ÙqìÔn»Fñ±Aò¼Œ
+~z#ë6 å˜Mmné©^«ŠÒŽ†y§×ù{?¤¾ó
ÃN[„!H-Èâ–‘Ôyúê³Ból«nsªYòU4Mö¤
©0lÕÜ´~µÇê½æ`¾ü™ñd™ÿÍ%ºŒ(„ïñÃpY0çh^zÑl™dɄ˱½ú¸çðG0Q'[9R3…m4cA¸Ôá÷¹öîY+x‡}Ê)¹ÕV¹„çþìm‚›sÞi
+chô„,	3 ‹
ï‘“#•ÃùG	ÖÑŠ9$5à »l|ëQλM}ž¥’>‚ÈÔ!¦}™n¿°B=…_½' qŠ=ò¼²D½JQ:|4ù	"V&71¢‡»Ê´XGŽÌ˜Û6¸XÉLjðD^«Pìˆ,0ª°>«ÇŒzK„Uê• Á;ð#
zJí™ÛGÃLtåk
­' , 2ýòô™ÏªÍÑk|Õ[~>'}A–ž­h¦M$™O¤{É™™aý|Fo¾á¦›\basmç­‚‹ÝjM߃½€—RÚ·Ž¤`W 5YC¶]Þœ}ËA…	IñFÝi„—¤>4Å1 <ÏÜïQ»ÔäJ!¼@ïµ/g”ÆL…˦Xx2¹Z‰—L¤xó¨jZ‹¿•…<	ËÍ(癵uèKvÝ%'
¹ä†¡&$XôÕÝevþŒÂ…--kZ"»À¤Kõ.C!5—ÔÖ²
NɆ	ÅŸ;DrR,çÖ‚ŒQŸ¥Hâ-A(wYœÐ%
+ ±(ø'E5 Í0Á{'­WÈÐÐlûù
4·Oÿæþk¨ÕÏÙ€œ“æ¬)Tlý¼SM¢ÌºtÙö:ʇOI[|¹,™á
+¸}³i¼<nU·ƒÊ'D†7Òz;%s}S°l<•’y°46Ê–TZ¹eÛ]DÕ\Y¹ñ}˜en|(xèn)<¸ËŒ¢G/Çê‚«þf$'„ƒ":èuë	ìðx/’<€Â?‰CòSÁ064qcZŒz¸ÙÝü\! ;‰^¼·'PZÖ‰EvdŒ¢bòjGYþ=Ñh/«¹È´®ŸË	$8éÈ'kê¼²à
+%gsðùB§*÷Ä•TÝþô¶VÔ½~Þgÿ°s-Ãê¾ù¤‡I3ôÀâʨbŠÅ4ZŨǾdzçÏ—à	Áç‰÷ø׳ŠX]"ïe‰¥?ÂÛjš…<®ÛsÒfÔAgV+¢ÔŸ8ýdÚ¥_ÜÌl:ɶ™q
+L!
…a¥,C-CŒ}M¾~šÞƒÔCzâë—ò'|;¦DÜ‹	Ž‹¼”ýû·NsŠŠô
c‹Ð9T#qY%%ËGð	0Ù¥*÷f’®
+.³ã׋ÏLH]DÒ.½Å¦œÈçûNcxï*ÿÍRŒõjHGmwr$Æ›~üzXÉõ½c7G9±fRpÂÔ›õñ`ç¾/ŽFöøÍ¡Sësöe‘Ä¡ûůjrv±K±‚º‹—li¬@bÁ̧òÓµ¬FÁ§”L¡s¾´_úm\9G›8+¥£XmK‰^γ³æ&„m©œtðÞì]ª_l„Š@O3º] q—ÃX;Ü3œåá›
+kƒãåxÄüÁ‡¹C ¥"QPf¦CY_vŠÓÑô|‚ŸŽîdœîÃ:
eФÛw‘éûe« VÑê–†P-o‰ã¶*‚½—€:GçMøŸ¥ÀOr¿/CîlMk[6qÉŠP·eÙ0ÿ¸•Ëzý?TRÈõó·—Ï(ªå8“j$27BjߺÌèÖ–õ¦òãȹÿäâÌ-:N
^TüÚO`bŒvï	×o(<>yýeþðHó‚Tƒƒ2¸¹ÁíåÞ(å2Çæ¬9½³g¦F³Ùå’Ë?q…ÃNßJšPZØcš¹ÔiΑ88›ï…wäD&oô\<朕çÞ‡.'cve‰kÎþšØuôI¡]Èš‡þý+‡¨§Ä ~¸db D:{‹ÛÖq	•¢j+˜ZÖ+·?ÜT±æ­ºŸÀÜÀ!
+û:%é5¾¯åV¾çu™J°5Jòb´â"2jþä³àí=j¹òüÅÍ·½OÖ±¼×Ñi¥Réqødoeל}½j(áIaRFT¼‡{°˜Të‰n°‹W÷'½y@,}H5»A¬8ÑLØÑ]ƒ5ævYÛÐD"ßïŽÊDʺ°z¡Ž »z}ð…ˆÇÄ_@ïO>s0<#gr¹ñ´»f!bºÛèÊ5ƒ¢Ã–x¦ÐJÚ./°A>x»! jm–²sÞ7vÁßC}AœíÁ÷}Žn4XìÅVÄés¡%›†¹¢{Pû< ´éÔ Ì7¹d±·ÝÖ.´?²s1‹t¯}¼;¯±Ý½’×Gû»{UÔ.!ó!T-ºž¸9Çݯ~_’*gûkèŽvª»¦$û¦ÝU‰ô¥5Sü¼‘i÷I´Ï(Ô_:$³^‹â»Ù…eÑ\¯eÈk#Ü¡ðï…Šíw¿ÆÚæ'È­ÏòãJk-Yc¿ö3A2ûW´ìßßUøäë/5^]ïèø×¢ òÁoÀ&ÇÀÍ/úŸNÜ&ÞÞè\:?Fîö…)«pÈ:RªB¹TŠP¶×ÒªA
+¨ïÃÌ'l¿:¦ðè;{3¦Íäeµ—Ä;»¯McÕÒÚ-ÿXON´Â½²ùr0‘õC€ƒºÆ…L9ꉱSWËñÛÖþN2¼‹ÆvÃñ’ýÐ È*ö{ä•k^‡jogÊ"oØÊglÂóIüPÚ}tq(½Ÿ
+QCm6õv;1w²ª‡Hk_Êx½xµ™\Q\5“`b?ÛÓE„ÝH¦æX­Ž…äš»^ÁqL]ÙPºÀ³A‚ä£h]hò(0ã»d68ýÀëÓQ/eÃ`Ü›i0ÐñXV£ξ0žzGïZUOdCZ4[J)é?°µDäé*}ïuÒÌ{QýÜÕ‚äÕ_x®
+Ê’¸È˜”m€¿™»_–pÛD‹KÅ|iVWeeÀÀ«‰
„lÐÁôÿê4èT0Éëë]Ïd‹;PL¹£¥e!D*%)f­­Ð¾ì {ÄùíÐîòsÃÕ|0ŠLï-ûÈØÀªY‚èZ`ä<Üu´N!ìÆÂçaæ¨ÞôIJE OÕFÚØÙ‚™O¥ì鲟‹„œ*+aB5*êëˆYš0MŽŒ£>ÂãðSΚb¤³(=nìj‘·æÑ4W­ÁÂ-ÕÏ·­_ѱîíô‡Çº™·`î%âg›«ïW‘iІJmøª º¢Ô††ß‘$1½ÑØ“](snr…„L¹Rœ±¹UbµVfn3]ú‘ÛÀáˆÿ3È9ÆTÄk›“¯Bšž«µW¯ôoäˆ9u“lܲ‡vxvèô3Õ ÖÞlQ;,
ÿ®w½ß,Öf9z	ïï‹?ŽJ¬äl*+pË(ÑMÁ™ž eF×gº‡@‰<·5ð˜MêÍ	jmòÏ °ñksŒ]VY:zÅPÆ]•a£¿u_d„‰ê`”]&6ú‚–2#³ëb…S–ä|_'UBÉ9ÇØÔ*+‹©´ËY[–µ²zŽ’w
+Áë±(`°1BøÍéÑ÷kL»;B„/ˆ,à G70“›(Y:¥ö
+ùµi¸ŸÔ§îwX\Ÿy=rû„7"¬ˆiÝe6ÕÈý`Cõì¥oØ?g`ÍF朌‹ÀH‹†ò×ÓÕÏ‘`ñ»
‚ƒT~65Î.96,`³xõµôlë	Ä\θ;&¦!kÇ×å ÆæÁJôV>ÓÛnQ3­‹c…8¤„½aGãÐ$îÉ(»çf†A*"CÛï}„:¾¹Ìl{‹7nN^ÐÊ`„påƒå˘ÌV—Ûyþ2>÷{Ή	=½"ž;ôl`¦GS=)ÅhhR:êbÞ°ã}µ;íYÏHey~aN'¡¦o¦NQ»ð%`\ô?G°2™9×Á>ìSŠ¬7…¾»Ù6ò_qÛ§ÍȒΊŽ¤¦vغä.Ù#*Íõ¹²G-–à°Ã~3º½øÕNôdàÐH¬|ò€Ò>I6]ñs˜öüåÛ{ñ7cÌ	a8d?‡ÉNV¦æWíûê^ÙŸ\W’é†;ˆwÒ`–v0zA…füA©‰õ§$=›Ò¥˜ÖÒGVöašMŒs*(±Ó8üì¹äô¶^d•àŒ1÷·»s®ÛCºDdq
+I¢BŸîÙ¿¿²ÊXãÞLbÁcÔÅã‡Î0¸±hÿŸvæû
+‡ðgl2²¹¯u¶¯}gï™™³;dsvÉÙãlBvg”y8;âì…²et)Þ?âýíý¼Ïð„Û!O:hÛDr@Q9Ul:Ø«Táa¯a	..4EÿBÜÖÑôŽŒn†éü
+ïÔ2AÆìöâ©eîÛ›Ó¦;»ŠÞ¹‘°!¸„è`Ò]åU-YñÌëŸò¬ùM5ÁF³·&RGßw´+ùûè8šŒÁÈfïyFW
OU£wÀº$¾¿@i¼ù9ºùr¹>ÒHÝÂö§õÆe¢Íw{˜¡Ù
+,ùÌçÖ6ºþ‘ß‘—§ìä*ƒšA>SxÏå’ò§Oœ•Ãøjäwcâ]o¸‡´×ç?e•é%IômßÞl)·œ?Þ4‹™æI¿´—.¦Äì Ê×AÖŒqh}Ä_J¬Qêõu‘¦ZX´y7³xÄ,i’¸«^飯\µ1)Ík„ÝÅ	TÅ>¹Þðô3¥Ÿ¦õ1!}KGf³[ZdɦÚ^Ýs>¶ì¨¹…ç›ý˜“]û·çÁ ~V\Yƒ°ÕæÆÐ¥–tQrÿ=!ën¡¾5ó-b Ýmº¡ýŽþÒéÚŽëÁMyùAãýX	W	ÜKî(-ëß)¯Tà‰aß½ŸSñÖ*æHGÚàœ°\>|¢<ý(­³Ä¢­pš6>AÈ?!K•úÜû5wv")]mBßþsËäÖ»y¿ˆ~li¨c~Ÿ…Ýu¿û0Î_·÷§n¸>õã³@IIS¡å
0B}?)4ð“ìóßùöìä]ϧmÍ|—Ýý2žÌÉuf‹cHéwia3êêùçIRyïX”v*&äaëR¹r}"f>Kèbœ#òF¾¾R>ô•g*("¸AÄv%§U–ݹ°¾tðî—´"wXÈD	Kaë:¦Rô6½fFä’pìï8%/ÁB×lC«ÓùꉛAØ„‹ƒ™ÐȆpñ½ªWfÂDùtËÏÛƒ'qØV>“žÇëîä"9š#÷cõeŠÞ«øüt7–À“rELåÊ1<¯Z 
¡“gÌ^™7…fÖ¶†Î;xzÍ.—½°õ<µ@|˜¾÷º`ÜG¶ÁàÇ¡ÝQ‘ôÁö¥¿XmQ žh?ÝŠd„Zêà¸
w–_ã÷ëÛ“ÌWsƒÚHãØ´ðÕHPÎ#razoºÚ·¼§,ýÎ{=M¤LÅ;uD«&RVdz»Qò¿£Ài:ü:a‘Ѽr.<Ó!OÍÁãÏcL­ó*ó@ dbzâ2YÌóŒûäð<îº|¯t$âckÖvzÎÌfPW´ DSÄwÞqŸm¦DC\s+v¨Ò~b¥æg¢=R8+’(%ÖTúL茜m8ÀjñÕ|"Òr˜ü¯C1Ÿt)u+	ºakPâ&2?Ân6ˆ=Aù¹ä?úZ¨içiõêØÛfÄ·âw|šûÚѲiC©ÔŒ€}
+ogÓƒ1GC6E®Í]cdv®l}©µžÆÍE*û‚Xí
øVr,À8è–>7%×5/ÔQz 6@^î$Æ
+Ìkª¸â§hDlU¼v7X}ñÂúZ%fòb+†Î5ƒ;TÅHÿ$IÀÒR.X/+ùeÌö2¸Õ4•õ…6È(z¡ØîõÉìg,Í¢ÛäZ}~û JmÕg(±èe{u›"&Œ›Å?ci¸èàòÝþªxš»P1¡,›%7Ñ9¶£ÍCN„zD²O•EwŒöÐwAöº”\¼¥¶¥&†m—}É·åæ5FèHîñÁmÉæåwæµÃØ_ÁÆuIð*Š_7S§êö®B›¹æÑÜíä4žœ¹?B¸ivèÍÊ¢ûÙ‰Ð=ŠTgÜÍÎh QvUKœRŠ¡ÔÛ³=³·*ŸèÌ
»üÔÚÕ$dno(Î*ˆÍ¥e[­¨þ¶5ÐÛóÁ2¿±¹™eTFXôÑïŽj_â|§Ç9Ú ÆxŽüP$ßB^àâG:ƒÊÊòÎJ£Iÿ—¢baDѦËvwi¬†¹Ã¥Ë•4{ÓÖÓ/mJûW2S‡êrÚS–V¸&•ˆàúZ(^S'2×ä‹’L3:5¨V}JC9ÜÖË”2Jî(>9c·aïj<Ü(ÎQC…6Ç­ X)sSl„öϲژÑ߬n
+i¿5xÑ@>,Ïu> w?tiÓ¶0ûôIÏä#%(ù‰ö
+©«ˆ|LO†D¨Å÷¦gîÑå¼Þ8vÉC÷I~®O–ÙÍ>mŒáõÞ¢‰‘}‚
+^hâŒð·¹ œ£“hZ™Í/øÅ_à7œÀ+P¸¸&&êåî$+Nȶp®Ô
~I(–»c¹ÚŸYªÓÅg¶%ø¥p%ö>­’H¾iL¿\ÚõÐß(¦µâ_«8Cƒ—R{‹
+Žµrð¦ëØíû‹0Ê{‡˜ÊQê¸2‰«Zœa‰ƒ†*7Äc¹äJî„I›ÏüìÒ]©æÁ 1=Š¡å©òñS€MX¡¥GMøªéþP¢‹:*½ÙOT9†ÜD¨*ÀzÞÃ*Úž“¬ÿ°Ë_hg
+‚œ«ê9ŸjˆŠ"J7Þ®(ðhT(ìâ ª¦¼ÜðÊ™§Ä‹V¬áÝq
+oò]ç}£¯9B‘7õ·	öœH{È­’ëæi`T&éVÇãs"¹‡‡ªÃßÛçVMo¼iá÷׈â{C„^×;¿_g¿`,·÷þ2
Ún“
RÂɫǶ]ÅjÍuib°ƒãÏV!QÏÆ>²¦aO<ö”ñOÁxƒªH²$áófe°§Åû›ê¥úКxÇÑiêÅà>ò$­–Ìy"-Ú-ŵ ôý‰¤Ëq¸ŠÖˆÕ"™[Ø m¥cA¸¶¹"t8Q+PK¥ìó÷Ñ”¶ëÛãh_“	®$+ƒº‡¼S¾ÎúÜþµ$áØ™éezv~7EhÅZÞ‚¥ÓªãHÝåûm®Ý‘(ãŸÄ"Þïòwnúê›»ÉÕ”^«¦y$3î3i=+iÿWuÈæÔmâ’<£Ⱥ][±÷QgShSÝ»¤SñºïX±wû@`z>ÍÛòÈëB¶"Æ®.(ñôAàN¥Ã|³w®3¬ín1eqÞ¸XäL%­1;¹MÊ®¦*Åÿ^OìU©‘yo•½§ìRùùÑ©	lå™Õº©RéÓåú’ØyšQÝÅêØÌ·XçY2‹†¸Ä¾ŒPñ+«Ö$ßo¼7SæDEÏ–GÙËËGªvË.¼–Õ£ª¾PH^ ÍuòñjzZ+3àÆ´¤Nc<ÃÃe™åGKB.þ/Qü?øŸÜ|Ý]ƒà~.>ÿx¦ßendstream
 endobj
-863 0 obj <<
+868 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 33
 /LastChar 125
-/Widths 1940 0 R
-/BaseFont /HXBZDR+NimbusMonL-Regu
-/FontDescriptor 861 0 R
+/Widths 1952 0 R
+/BaseFont /MSGWNQ+NimbusMonL-Regu
+/FontDescriptor 866 0 R
 >> endobj
-861 0 obj <<
+866 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /HXBZDR+NimbusMonL-Regu
+/FontName /MSGWNQ+NimbusMonL-Regu
 /ItalicAngle 0
 /StemV 41
 /XHeight 426
 /FontBBox [-12 -237 650 811]
 /Flags 4
 /CharSet (/exclam/quotedbl/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/underscore/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 862 0 R
+/FontFile 867 0 R
 >> endobj
-1940 0 obj
+1952 0 obj
 [600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
 endobj
-746 0 obj <<
+750 0 obj <<
 /Length1 1630
 /Length2 15892
 /Length3 532
@@ -9256,7 +9307,7 @@ stream
 xÚ¬¹cx¥]³-Ûv¯ØfǶm¯$+6:ìض“Žm;éØè°culãëç}ÏÞû\ûœ_çÛ¿Ö=kTªY£æ¼îûZ”¤ÊjŒ"æ¦@I{WFV&^€†ª–²‰­­‰9ÈAžQÕÁÎð×̉@I)æ4q9Ø‹›¸yZ@s€8ÐÀÆ`ýúõ+%@ÌÁÑËdiå
  ùËAKOÏð_–\¦^ÿütYÚ¨þ>¸mí€ö®)þŸÕ€@€«`²Ä””ud¥4RŠ) =ÐÙÄ ìfj2ȃ̀ö.@Z€…ƒ3Àö߀™ƒ½9蟭¹0ýåq˜\f ¿a@O3 ã?Àèlrqùû¹,Mì]ÿöÀÕ²7³u3ÿ§€¿v‡äèìð×Ãî/ö—LÙÁÅÕÅÌäè
 ø›UY\òßuºZ™¸þ“Ûô8Xüõ4w0sûgKÿÂþÒüE]M@ö.W §ë?¹Ls‹£­‰×ßÜÉAÿ*ÃÍdoù_0œ–&Îæ¶@—¿4¹ÿéÎíð¿íÞÄÑÑÖë_ÑÿòúÏ@®.@[&V¶¿9Í\ÿæ¶Ù#0ÿ3*2öV–ÛÍÝÿs:ÿ«A4ÿÌíß"LÌìm½æ@fE׿)4ÿo*3ýωü? ñÿˆÀÿ#òþÿ÷¿kô¿âÿ¿çù¿SKºÙÚ*šØÿø; øç’±ÿ?¼Mì@¶^ÿ7ÿÿî©üw‘ÿWW“¿­±·ü+ãW&–¯ÿ@.’ O ¹2ÈÕÌ
-`abû·Wÿ²kØ›mAöÀ¿šþ«FV–ÿ†©[Ìlìÿi>ç¿! ½ù¯ÿ¯LÿªžYS[CSBþÿ¸WÕlÿΗ+÷¿#”ÿN‚«º—#ð¿Òi)8˜ÿçâ>QQO€7#+€‘‡ýïdc|å`÷ý¿äþë­L\Až=&Ö¿¤ÿü²ü“û?
ƒÿF#aoæ`þÏ쨹šØ›ÿ·ÿ4ü›¹9;ÿUù_7ÀßíÿÇú_ƒzÍV9˜ñ[§ge¸Öáæ
OŠë
ô±B‡8–6ªÔ8ôú§‡o­4~«
ajšæýh÷Z:q|ß—¥;íñ¥îM^ù’Óö¢ÿ¦êä¦?d6,EÎ8ÕŠö¾\”ß‚ÒåbÑ<Ø™TQ5,yƒ!žîdw†»|¤
 w/À¢xpDñ3KkˆÃîBkèûqrJ•tüø@=462ü³÷ºŸ>7ž’Ï
+`abû·Wÿ²kØ›mAöÀ¿šþ«FV–ÿ†©[Ìlìÿi>ç¿! ½ù¯ÿ¯LÿªžYLB[EU†þÿ¸WÕlÿΗ+÷¿#”ÿN‚«º—#ð¿Òi)8˜ÿçâ>QQO€7#+€‘‡ýïdc|å`÷ý¿äþë­L\Až=&Ö¿¤ÿü²ü“û?
ƒÿF#aoæ`þÏ쨹šØ›ÿ·ÿ4ü›¹9;ÿUù_7ÀßíÿÇú_ƒzÍV9˜ñ[§ge¸Öáæ
OŠë
ô±B‡8–6ªÔ8ôú§‡o­4~«
ajšæýh÷Z:q|ß—¥;íñ¥îM^ù’Óö¢ÿ¦êä¦?d6,EÎ8ÕŠö¾\”ß‚ÒåbÑ<Ø™TQ5,yƒ!žîdw†»|¤
 w/À¢xpDñ3KkˆÃîBkèûqrJ•tüø@=462ü³÷ºŸ>7ž’Ï
 ™**À)—PHW£B¢ªU³m·WÛÔOrí]VÉ• $«ùqyĤ"õÂzŒf<0ëûë£Îðf}/Ÿí¤>bêFè,VØUd‹ÕƒæÔJlNÍo’©+¬OXÏ1Ï-¼§c-NÂ1ipÝ›í\AÖµ?ªª…¹{G.ž'Þ½µ$5õü^oDÌÒ’j8Á¬R/ë‰yÝ࣑<Ì`½^
 úêì`uvdé,RHžê$žkK‚>&Y	¤ºÛ”OØ&â„o™kâÆœm§Ù WëÙÉ
 ¨œ/û«Ð[BÒó´`Ûtä¯äÍN¿GfáĈHªýmVéDÇÏ“Ÿ”Ä÷¦Y_kÉóÍ+èü1pÇÒ¨åÁ³ñÂjD•jÊ
@@ -9318,81 +9369,82 @@ MI
 ¿n$rÝ	XðD˜t
ÎõÓ…”2§—n„sÞmOÆ„ ˆ;²ÃßshuåU9ñÖ&;y-sõP~K*ªÅz4rnp´}ª÷œõ)RB—+«å—>¢cI£Ž¹w×	éhz€Ì\mm £MúHþ×<×|Ìï­&‰ Ÿw³s£Üë+\?VË´<=yò‹ØH»M'²ñÑ67Cøoí+A5x5½·x¯'_Ë
 c!vÜ~óÓ4¶bIpµP]ãH^ŒúÀnkLßYßÙ„æÀ,•‰)tCœrÀ‘Çi†Ï±m$hýÈn.ÿ¶»öO¿ªWÂ[–{OFChÓ'žWùÆ*6L‡1±’g^H]u Ââa3ð¸g@—TÕL_1@d7¾ùÁ“†µ‹Œ:…‘XF.ÿ§Òfb1\ÄñSÙ£Ö®TÁIS ÒŽã{9.´ v´ôPš_$ƒºÃ™.T€Áj”¤RÚ.zàÂiXÎ^;-”ûkwå0HMKyÃûSc-‘tkâôk'a.*bí	Û¶4ŠdÇ&ž*qÉŸX‡ÒÝÓä"c°4	*+9‚3£
 cáE¢Lg%ãŸïÁó§KíÚï©=ëg‡~Q)œu‘Še7@ô`­¥¡c˜„s2¬ìe/ï´Ã÷5ØI*·[ÔrHîD4;"«hntRÉ´c¬¥ŸýÝ„u å{ÿÁØ}hë …x;³°çlqf—š
“d79˜R€2õ¨)iµ†–Gö»€ê&‚—ÜÞ¨CšùŸeVò]ÏÓ~„ð¡T}îY¸dë`XÕìéÎ<òeJË»1ÒXê¤QáÀ#÷gX¹;«ÜÉà{}¤*½lÈ»€~.ž©kÜõVÅÇ®þÒ€§ú‘7ã$o—#€àkص<Éâ{
-¯41¶{ºQµÚâl·Pãg;‹($@QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW
ä­ë6Å͆ÇIjË‚¶{Al ¸¸
²œísè¹”Lª £ÈàýÞùqœöÇ=*Y€þKTØ&§Ð9æ2ös³Ìü±×îªÊ›õäõ§=ìÌÉIx=ãç7åv[¿Céhw›«Ó(îl*ø®Ÿq	‰Ëb“ÛfÜèYàûYÚÿßRŸåÆ	|)¶U-*ª[rᇻ……øw8me-PÍsóQîñúW™N‡vé¸î²”š{e³ã=öEëe>*­xQÿuò_­Rñ„çÒ˜
¢þ«Iïç?d¯Y¹Æa½/Kz†Âc™›gZ6qæåØöì—3 p0,HÎIM,*ÉÏM,Êæ&œfÁendstream
+¯41¶{ºQµÚâl·Pãg;‹($@QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW
ä­ë6Å͆ÇIjË‚¶{Al ¸¸
²œísè¹”Lª £ÈàýÞùqœöÇ=*Y€þKTØ&§Ð9æ2ös³Ìü±×îªÊ›õäõ§=ìÌÉIx=ãç7åv[¿Céhw›«Ó(îl*ø®Ÿq	‰Ëb“ÛfÜèYàûYÚÿßRŸåÆ	|)¶U-*ª[rᇻ……øw8me-PÍsóQîñúW™N‡vé¸î²”š{e³ã=öEëe>*­xQÿuò_­Rñ„çÒ˜
¢þ«Iïç?d¯Y¹Æa½/Kz†Âc™›gZ6qæåØöì—3 p0,HÎIM,*ÉÏM,Êæ¼[fœendstream
 endobj
-747 0 obj <<
+751 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 40
 /LastChar 90
-/Widths 1941 0 R
-/BaseFont /VXUVES+URWPalladioL-Roma-Slant_167
-/FontDescriptor 745 0 R
+/Widths 1953 0 R
+/BaseFont /CEXQRI+URWPalladioL-Roma-Slant_167
+/FontDescriptor 749 0 R
 >> endobj
-745 0 obj <<
+749 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /VXUVES+URWPalladioL-Roma-Slant_167
+/FontName /CEXQRI+URWPalladioL-Roma-Slant_167
 /ItalicAngle -9
 /StemV 84
 /XHeight 469
 /FontBBox [-166 -283 1021 943]
 /Flags 4
 /CharSet (/parenleft/parenright/hyphen/period/zero/one/two/three/four/five/six/seven/eight/nine/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/X/Y/Z)
-/FontFile 746 0 R
+/FontFile 750 0 R
 >> endobj
-1941 0 obj
+1953 0 obj
 [333 333 0 0 0 333 250 0 500 500 500 500 500 500 500 500 500 500 0 0 0 0 0 0 0 778 611 709 774 611 556 763 832 337 0 726 611 946 831 786 604 786 668 525 613 778 722 0 667 667 667 ]
 endobj
-684 0 obj <<
+688 0 obj <<
 /Length1 862
 /Length2 1251
 /Length3 532
-/Length 1861      
+/Length 1862      
 /Filter /FlateDecode
 >>
 stream
-xÚíUkTgnõJÀ+Å€€¸
-æ2@	Š&X4-."(R’		$˜$ \(PÁ Bå"Pi¥´^€ÊÅ`EÁS#BAn¬\uÝôØ¥?wíÙ™?ó>Ïó½ß3ÏûóY˜yúè$vEDHi€‹»Ï~€D2ÎÂÂ…!	í‚$0
A€.
@*@v QÈ4ªÎpA£P~OX¹|² rèBå³!àIx°ëÁ†€ÂæÃ’("@ï…bÀÃh$Ì!â@àðÙ á‹p¤GL–`Ž4ü-	£bÌ`…™üÀ,r‘ 
-àÀ\ÉÁö‚1'ÿ
SË›»JH¸Ð~1¥¿ð/ˆz£@„áR	ŒîFEË¥~ð’9w˜Ã—
-—³L	$à³é¢@;"Ù–ºDðÅ®|ÌñäKØ<€	Äð"‹8Ë­`ñ-!íbyøîñ±y3×EÒâ‹${£Âa€üN½Xƒïj,%”/ÈD2Ä„Øûö+pÙfŸ‰Ø‡/
-(T{BQ(
-‡ ¬¢1 Àq`Ë0Ç$¢‘`K,šX€‹ ¸…±‚¶‰ÍGÙ˜½05É»DPR0–9ü'ˆLÁ0bØûgØö
¼4ôw¸=†Cè;ËØab$æ-Â
ŽÁ@d1Š#@p´Ç~íjì¿	ÙR…E’ų‰Åÿ¶æò±‘Á°fãzº¶SrhnUJyÜgçnÿIçEk…¦G»É¿&.ωõ¡žõ2‘”Œ©®SàÔ†Ÿ³N꣗2<Ž~9U¬áJza™ÿñj#±Û•”._õÊÆr„©ˆØw*ÿk•1­}xæ›-[{¦¶Ä·êå¨Î5Ìté®·ö>am¾Ñ¡ç¼vÿûðQý;6OÔÄç^ßοuÏ鉻¦[*¹ÎºÁSÐÌ#\ 7R©´ñ¦7ßU«ræÖ²Ž6Èž˜¦™§Zº´‹%þ©Æ–QðÅzg»é|mzÙ™µj¦Én»Áð¿°·“W’Å‹žL;û›ù‹ø?&¾[_Jø1Æzp\¹¹'k:~ØÝèD)UëTUjjFìqsHîÄ9£òä6Õª'ø¶Aöܧ˜FÄ?1jæ©¥Ï*“_vÒMLjxn›(ó™]aãaÙÿ¬PN‰ZL¨{f€«z6oÛ5ñ¡î¥|ïá“Û~ÔP¬¥-ßVïåÝŸªòÝð:sß³v†aÎGaÿПñ×¼ŒÈ;4¤9¢fÉ{—pïç5Ⱦþñ·Á’‰ˆµyWo*®*ˆ®„–ñ–¾›…öTåáªk×G¥õ7œ,å$Õ-Šoâé㜀’\¿?hXQìËj«G•
ݵs©Aâùp讲òcÚÊ}ê:Vî4QQ@ûÔgϯñT	÷ýù/'I¯“ºžkÕ¶ÈLJý•©“SÅ:-¯7{od
Ègm¬”ªUÒ=M ÝqgŸñ¶]ÜÙó¿Ë›×Œù)“bõ¼C\pÖê=ùéNÓÎW¼¼§G´bRC…|Òš€{êjÍ)“pÚ=E`ù(±¶ ýü¯;
-T©)s‘›ò¯5”ïØ—Ëlòi~àpdÝLãË$+õ7™•žæ+M‹zç‹+Æ–¡"M~ÿ$ÉÖÒ~÷CÂ=þiab}{„gÿl§4»>'1ÛCq9šœù¸)òo±Ó+ÃuÇ\w­ƒ£MZ«ëoÿ=Íùpçšé;wá´ºù¨›zEŒv¯‘þ×Òý–ùÎÎæ[#Ρƒô«:Ò`A«öOóò á€_îQíi»uIˆYöÑÀ±®ü­†Æk²Lv“¸‚|xãþ1õÁÌf¯û±É,=¯ñ S¨|sÎ쇯£©‡VGŒüÜÛl¨®­=tª£3Å/ÎÍ|¶M–zZ5¹~{[áØŽ,Ö#æ‰ÞÏn§µúf:+“Ëâ8í¡uvhü~iwl–·Vœ—¿:¨'§œûžù?|pÿoð?Ñ»º!T‚!4÷/ƒ¿þfendstream
+xÚíUkTgnõJÀ+Å €¸
+æ2M°HZ TP¤2&“d ÉÀ$Ñ*°@Á¢* @¥•Òz-+Šž
+rÓ(š€`E.º‚îzìÚŸ»¿öìÌŸyŸçùÞï™çýÎùœy¡$–Ýû£2	$ƒLÀ/(t3H@2•àìì‡ÁAek!Ì@oo`)EH¨&ʤ3΀«Æ‘X¸ú}2%b,)Œ!|HA
+1,Å{ð!	ŠòX¡&,‰™Z!B`9Œí€d„¯¶Ã"DF L9âÈ„(À˜ÊØ7Ô“ã¦WÜä'nQ€Ê$j@	”`ßÆü7L½ÛÜ_)‘CÒ©öÓ)ý…‡¤ˆDýZJc•
+‚PŒÉÞ•†Á3æ‚`¢”¾Ërá³d"	@O2Õƒ>C rDxˆ‚/„DOã°Lð®<¾i#”€u,'Àýõ\§I„ÈÔ±0@}«ž®Á·5ž†¨€*™Jq!þ¾ùŠ|g³Ïd|T€ÈDî@©	ø	Â+:ˆL«X…;¦e¨_àÑì„(F˜+èPøÆ—Àü©©)¦Ø‚P¶ã™Ã‚¨4à >,…†=^Ã3C‹{á8„½ðp€#—@rñ4ü×àØlT•@¢y$o/üG@Ð`0è»þMÈWb,SLŸM<þ7µÁGÃ*˜OèhCù>iÑ5镉Ÿ»þý‹çÍU¦óÆ𳉅ˆ`W(ýÈzG‘¢¬¿ÔpfŸ–£·ýœïsÀ;½8+xï—#G­OœÉ,©ÏI¦7ÛC‰êÔLÍœ—î.ýmܦƒE_ì˜
ؽÃß,_Ñ1²<©ÙêˆÀÈÞr¬~¼§Ír¡[È~7§%ŒŽãæÝï/"ª»Þ\6|6©àÒ*þеÛQîŸé¢úZnÆî"…;ôz÷õXM·Œ†¶‚‰ùܽ
ªG»2œŸèB+T£™‰v	¿_‰5'ÞØ=U:úׂÐàÀ¾Ø}]›vÉ@ÉN^Wïhß|ÏCübI³{°æ#µÇcÖÉg·Dßßøs5˜ñÊh¾¤<ñYST›ï°öQ|ÜwçVo$fí"Qspóã²sZ˶s6 õê[~ÙÏ‹-‚¯šeÒ‚”gÆ4gÅû(ľAÏ«m×וÝK–¾gµøÛ¯ÖGÖ²¸ÿK³¬¦¾ž=ciNšV†½Ë—›^pfWÌ•u]$?z2y •Ùµ¬¾|³¼cÌÚš—ÈædÚä‹.¤Àj²wµ[ãBMM{ía¶ÓÊÁ¼Ëo£wÔT)¢á!˱ì½Y¼Èàõá_˜%mm,H‹äF>1™:ŸU>.G¯Xš2fJçìÓ=ïr*µdžl-Ï°sQÃ'ÏûzŽ™³*Ï7rôh^Ëevø‰
­ââô\qüÓÝG~szžÔóÇðwK¢I?&¸õ™¡WrG“-Þ_.~bàÖùÔ”;8’;¼iíÑ;¾˜&­Å0çñ²GÔÍ-whqI9ÛâyfÖÜ
+ÍiË”©I¸”6™Ý3“÷Ï*ýˆLgOÿ˜—ÎéX¶ríð‡–§ŠBXù£‰æ¦Ô}[»Aug¤fã¢WÙ›ž\eÛæóë±pÓ‹¸‚‰m}¦=F®¦S{Šð~a½ê{éë-Ž›_xáŠö‚–ìOÒ
麮”xÑõ;ï.V]Pž¿ì㢡®Ñ6¦ÊD”„øÁÄUóO]ïW7Ô·×MdDõÈ'c¡[úꙘð±ÿ`¥ÏpUYóÓЀ_“è
+á~Ö³_P^¥¶=3«Ó©ìËÃØÕOGŽZè^-ãå´ôr{l4ãînlZÍe@#	Èô^Óe·r­püøï*ï¦yƒaúÔo«Q½ÁíC«G?Ýh\óR\øxYB†¶¯„MLqÛ8Ëh:h˼­¬ ×gÿ5xu±!#}bÇÒÂÞ‹õ•«7pC›î2ö,kx‘êjü&»šç4Û¡´sòhÀ^ÞWj*êþ€¢XQÞgKêgò‡>-I95Ž×=ÞªÌ;ŸŸ’¬=OÍ~X†–†ë<­*ˆ¥í	§ämàxûæÚó‘×ÿ¾Ûwgë¼Ñ·àÝçŠ5ÆY	æ‹­oÜô/ï·ÖMž¬iºÖïÝ˺`¡Ü.i6ÿiR³¥!$m	+Øk>ê¹ uÌÛ9ØV´ÂÖn^®ý:ŠPAŒm˜ >¤ß[¶¾Çkði.“UØ°•#Õ?%süáëømÆsãúîl²5ÖÕm;x³5=,1Ði¼E•qÈðt᪖6Ò¾Õ¹ÜûœýŸ³™uk-f§U$
+®FŸóÄ’6+Ûw冘uhÄEs£:ò+…ïYQÿÇðÿÿ
ð«Â¨ÂbÿvþFendstream
 endobj
-685 0 obj <<
+689 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1942 0 R
+/Encoding 1954 0 R
 /FirstChar 13
 /LastChar 110
-/Widths 1943 0 R
-/BaseFont /DONUHS+CMSY10
-/FontDescriptor 683 0 R
+/Widths 1955 0 R
+/BaseFont /HGAPIH+CMSY10
+/FontDescriptor 687 0 R
 >> endobj
-683 0 obj <<
+687 0 obj <<
 /Ascent 750
 /CapHeight 683
 /Descent -194
-/FontName /DONUHS+CMSY10
+/FontName /HGAPIH+CMSY10
 /ItalicAngle -14.035
 /StemV 85
 /XHeight 431
 /FontBBox [-29 -960 1116 775]
 /Flags 4
 /CharSet (/circlecopyrt/bullet/braceleft/braceright/bar/backslash)
-/FontFile 684 0 R
+/FontFile 688 0 R
 >> endobj
-1943 0 obj
+1955 0 obj
 [1000 0 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 500 0 0 278 0 0 0 500 ]
 endobj
-1942 0 obj <<
+1954 0 obj <<
 /Type /Encoding
 /Differences [ 0 /.notdef 13/circlecopyrt 14/.notdef 15/bullet 16/.notdef 102/braceleft/braceright 104/.notdef 106/bar 107/.notdef 110/backslash 111/.notdef]
 >> endobj
-681 0 obj <<
+685 0 obj <<
 /Length1 1616
 /Length2 25291
 /Length3 532
@@ -9401,7 +9453,7 @@ endobj
 >>
 stream
 xÚ¬ºc”¤]°%\]èª.uÙȲmÛ¶]YV—mÛ¶mtÙ¶ºlÛÖ×ï{çÎug~Í7?r­çDÄÙ±#ö9±Ö“™$òJ4ƶ†@Q[GZzN€Š¢š¼••±¹­4¢­µ௙š„DÈhàhnk#làä¨Â@###€ƒƒš dkçfonjæ ÿ‹AAEEý_–B†nÿéù»ÓÁÜÔ@ú÷Áhekg
´qüñ½Q	8š&æV@€œ¼†„¬€\LV ´ÚXä­ÌÒæF@ ÀÄÖ`õ€‘­±ù?¥9ÐþÅpì€Fæ·]€vÿ¸¨v@{ks‡¿Ïs€©½ãß8ÚÌmŒ¬œŒÿ!ð×nbû/!;{Û¿Ö}ÁämŒìÍí³Ê‹þOG3Çr;˜ÿulMþFÛ9ýSÒ¿¾¿0½Žæ6G «ã?¹cs;+·¿¹ÿ‚ÙÙ›ÿKÃÉÁÜÆô¿Pì¦öÆV@‡¿0±ÿéÎÕ	ø_ª7°³³rûw·í¿Qÿ“ƒ¹£ÐÊ„šñoN#Ç¿¹MÍm éþ9*6&¶úÿ°;Ùý§ÏhÿoƒÈÿ93IÛÚX¹Œ&Ðt²¶ŽSÈÿïT¦ý'òÿ‰ÿŸüÿDÞÿâþwþ—Küÿ÷>ÿwhQ'++Ykà¿›ÿ9cÒ€†ŒÍÿm`mnåöŠÿï‘jÀÿ ù„‘p4øÛ
-Ó¿rÐÓÒÿ‡ÑÜAÔÜh,oîhd01°úÛ§í*6Æ@{+sà_=ÿm%€†žþ¿ù”ÍÌ,mþi<˸€6Æÿû_‰þeN'«"%$«Fõ¿ÏÔãäÿjï¨ìf÷—Úÿ(EÆÖø.þA´uxÐ0°²hÙ™þ^9F3“×ÿ!ã¿@ÿµ–1p´7whý-›žáßâÿÇç¿V:ÿ
FÄÆÈÖøŸÓ¢äh`cü÷€ýOÃ?n#'{û¿ºþ{çÿýŸë:è
+Ó¿rÐÓÒÿ‡ÑÜAÔÜh,oîhd01°úÛ§í*6Æ@{+sà_=ÿm%€†žþ¿ù”ÍÌ,mþi<˸€6Æÿû_‰þeN'/"ª¨,Bõ¿ÏÔãäÿjï¨ìf÷—Úÿ(EÆÖø.þA´uxÐ0°²hÙ™þ^9F3“×ÿ!ã¿@ÿµ–1p´7whý-›žáßâÿÇç¿V:ÿ
FÄÆÈÖøŸÓ¢äh`cü÷€ýOÃ?n#'{û¿ºþ{çÿýŸë:è
 4‚^ùckÄh‘š‘æX‹ž34!¬Õ×Ã6dWÒ \˜ï[mÛ퓺ÍQ¡ÿ^DÛ8ÅùÙê¶xj÷±/Iy0ÒƒfEÖ¼ÌÃñ"¢èÍGÜ mg£:ð§Ó-K;S‹ô¸ZÞ×d¥W=Ø™PPÔ-~ÿŽ;ÕÎduõDáKäœï‹Bühïm”RƒÚЂT[pzFšpüôH60:<4Ø}Ñ»M•óƒ„ËŽ4Â÷W66Ÿ¦J¹He‹êïÝn-6CoÑÕI9G¬ Œ¦§¥aŸáòäK‹Qîïcþ~Ÿ{4C›uÝ\VÚÜñÉëÁ3(!×áÍfª“ËѿѪ7ð^Å®Q¾4¢]G]·0žõÕX°G-Å¿iÞngó2ø*(žTñ³u_¾Œxô«‰ªjy¿Ý
 ¥$T³ØÄ^×âs:‰¿„³Ót»©È i+3«0€Ö~Z¦Ò‹Áº*ã¹®.òzbdÄhn“<£c¿§¯
 ë³ü>Ëä1os´˜™(ÏÂß_Ø⟣٦$z#zlúµ1R?m%„ƒWåc¹BI-8v‘øòKNxoŠá­†(׸œÒùÏ[4¹RÈFNH•ƒˆUIþj¢ïö…D«6Êh”oϯ[%Z0ïÆQ:Åç$؆­˜U‰ú!6Wã1YDæcô*þ`ß•ø¸qÅó¯Rrú†};V”¡ý!ÅYs>*²%èa¡ûG¶G\V­n63QËR]BlõõLƒšªNS±o³®Xãk”t¯Ž¿¥è%+Ú£|ŽÔuœÙ¨ýf4
l˜³®En>îg„	1æ„ÄNò]¨ß`Ф­×/i‰û5Òyµ˜7:ê	2M~¨‚´S&Ò>À{y$«É6W¼H?ŠÅÏÝÉÓ*S;£BÝŠÄIÕÓ¤¹ª|wf	ãÆ!â…@[|…9s³qÈŽ××—}>¹v¼¶±Ä¸©–ˆ2CÌQÕ™15Bj"«RŸóöÚ窙Ä;cF1rv/T…ÎeBPBœÐA/[ŒÒ'}¯ä •©Ú{rRŸñ[±p†âºÙ§9êppàÒ-ƒÅ”vÁ{:Æð"çd€BnRâtïn‹}¨Â‡‡5„P‡<ùáew”McÛb…
L™¯ÎýŽ’µú¹¬<,ÌÒ=¶I¥]¥¶‚•!ìk
ÎÔÄdùÝÊ:ó$q®éÞ®Šq¾ƒ¼Æ<ÃýÊ,svwA]¯cŽŸ™¾"{=Ÿ&ulc
^£çDÿ)a/{¦8N.§%	§q±ü5¥×KÇx20œqK;ÈjtTŽ¸y´&H*À͵§¶q¨p¥GsÓü G4%Dá—rnì$áD_f!º>Èø`k‹æógúCÞŽsNU¸ÁŸ2û¥çüUÔÎ7Ú-/3аÉt=ÂœZžZ÷öešElòÉåi³Ø!š±ýKŽœ—DíØûø½u×"ƒq”‚d¯²Ôšª 9僄U1ðêpbDþ±kWaGÚ”ªø5ÁÐç#Ç~ÞŸú§jÇÿ½B7$Åšš’”6ìG†g€y†µWÿÚ›¨¸ð‹Êö|Ÿ¹^qHcOG_ùÎ}ŒÝËîNÓPb¥j„úiQR}D™CTµ u(
Õ]ú·ð»è·¸{§¢e%‚ÓòåO™
Ú¡Þ=’Gf0ýa½<ŒjZ80P߬j…'¿Ú_/ü„ÑêaÍ·LšÖz‹€f1ÏÍRpÿß&áì88g=§u©Îc“ñÖ›í²!»GYº7ù:1’‚¾3¼rž.5»W¹"j> •Š2¦Õ?Ê{®!¹	ДÏ@ÏœüO©ªtºG©÷Ž’4Å%ü’Y×ÞöPðüid‘˃8LÖU/p„h[×ÿ1õ˜åô×îE¥JP(òCˆ¤‚§t¢8ꜧÝÎQ‹‚j%U×¼±†ÙŸJXµ¿LF-.=5†Oí~Ñ
 \jË9gWØÅ."FˆmßÝÔÇ‘ÓßAÌõ|ˆWj
p7MÐ"Kc20ȧåOh]9J°F®×Ò‡õíTNì)mC\Rà‰æ8èÄЗ|-	µÂ¸ÅæßËlÏB@\ë®4Ʋó˜•k™_̦CÍö˜T!Ô½\!ƒÂD×$×&miÀ槻ÁLÝ¢»?a|ÿ¤þë™ú*$÷¼66ÛëðÞºR¨p`N‹8¹Îs©2õóŸÉ×®aLç%¢)K–9CJN¼·ดÇÃ6ôqx~ë“;à@È÷<þ]ÍCļؽyùI©Ž6xóm·Lº¥—Óê©.Chøƒ‹ÿ<™a-^õÄÞU\u´úé,R8ô0V‰ƒÖ=iï$……ní±ª—Æ„®h„¸çM«KÈÅcóÇŒqØÌ8wƒZÃÊf;Íhi3‚{~„Ý($
 iÿót:ùÃûxxñÍš6ïÛ÷ÄKZ·ÏlŽ¸ŠŒbd|Oá±–kË¥þÎÏB™E‹¤»
-èlLäšOnRZ~‡î&I°=w¦}æ‰l§b””Î÷g ÅTÍ‘ûûÁ{Ë1LxméÌ­?b†‘Ü€±%Öé]¶çÛ'$5ˆç
}~Ü‹{Á47
ŒCS®¯çÏgá·!v(°Z^cß—"|ÏÉUÛëUÛ„³¾Éêºêo6–I‰®óì¢;ɬ	‹a6²ôÍEê—'ÅKÜv–Ý«kî]¥’*€Þÿ<þSÍ?´.õÞ>|»ùו{šV8IÉ€¸@²`!Cr}Ùu3MVÅògè¿<*4ËëαÁŸ%… Ò9zS7ú‘Ÿœ’âó:·©Ž6Z3_C¯h¬Q½ÉŒff]1.ärÔõ„ÀݺgŒ6 hnO+(HuXíY]dOUÝ&°†9&/×á!^cnȯ(«eHü€SdClvÌf‹•”ØME?ÛÔ³ÐZ›N˜´BfG1d>QÚj\¼È”Ï·îPΊŸ¿æà;j:Œáo2çI­`þ÷?Á…ÀÌÞÂÄÅÕÑÁÄÅîÿ™¹²endstream
+èlLäšOnRZ~‡î&I°=w¦}æ‰l§b””Î÷g ÅTÍ‘ûûÁ{Ë1LxméÌ­?b†‘Ü€±%Öé]¶çÛ'$5ˆç
}~Ü‹{Á47
ŒCS®¯çÏgá·!v(°Z^cß—"|ÏÉUÛëUÛ„³¾Éêºêo6–I‰®óì¢;ɬ	‹a6²ôÍEê—'ÅKÜv–Ý«kî]¥’*€Þÿ<þSÍ?´.õÞ>|»ùו{šV8IÉ€¸@²`!Cr}Ùu3MVÅògè¿<*4ËëαÁŸ%… Ò9zS7ú‘Ÿœ’âó:·©Ž6Z3_C¯h¬Q½ÉŒff]1.ärÔõ„ÀݺgŒ6 hnO+(HuXíY]dOUÝ&°†9&/×á!^cnȯ(«eHü€SdClvÌf‹•”ØME?ÛÔ³ÐZ›N˜´BfG1d>QÚj\¼È”Ï·îPΊŸ¿æà;j:Œáo2çI­`þ÷?Á…ÀÌÞÂÄÅÕÑÁÄÅîÿ¯¹¢endstream
 endobj
-682 0 obj <<
+686 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 1942 0 R
 /FirstChar 2
 /LastChar 216
-/Widths 1944 0 R
-/BaseFont /NUKCNW+URWPalladioL-Roma
-/FontDescriptor 680 0 R
+/Widths 1956 0 R
+/BaseFont /PEFRTE+URWPalladioL-Roma
+/FontDescriptor 684 0 R
 >> endobj
-680 0 obj <<
+684 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /NUKCNW+URWPalladioL-Roma
+/FontName /PEFRTE+URWPalladioL-Roma
 /ItalicAngle 0
 /StemV 84
 /XHeight 469
 /FontBBox [-166 -283 1021 943]
 /Flags 4
 /CharSet (/fi/fl/exclam/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/circumflex/quotedblright/emdash/Oslash)
-/FontFile 681 0 R
+/FontFile 685 0 R
 >> endobj
-1944 0 obj
+1956 0 obj
 [605 608 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 500 500 840 0 278 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 0 606 0 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 0 333 0 0 278 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 ]
 endobj
-657 0 obj <<
+661 0 obj <<
 /Length1 1614
 /Length2 24766
 /Length3 532
@@ -9526,7 +9578,7 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xÚ¬zSm]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%c;CQ;[gZzNE5ykkc;iA;kc‚3)©£‰³…­°³	'š‰1°‰##)½‡£…™¹3ùõYþ	!0ôøÏÏN'3[²ŸWk;{[çˆÿçJ&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,''{#‹Ÿm&îF&öÿ¸¨	ìMm,œœ~Þ	,œÌ
lzàlG`akdíbü»©Ý¿Ù;ÚýDØüø~Àä휜Œ-ì	~²Ê‹þOgsçr;Yü¸	ìL"íŒ\þ)é_¾˜¯³…­³‰»ó?¹MŒ-œì­
<~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrúùÁþ§;ÿU'ÁÿV½½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfaE÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþwþ·Cüÿ{žÿ;´¨‹µµ¬É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìGzZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk[“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:)EMYqªÿóFýWœüòÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`DlìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþõ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ]¯_zøG¥þGmmÓçW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛdlTÇtº¥°jÑ^7KÒ» š¬ôªÇûS
+xÚ¬zSm]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%c;CQ;[gZzNE5ykkc;iA;kc‚3)©£‰³…­°³	'š‰1°‰##)½‡£…™¹3ùõYþ	!0ôøÏÏN'3[²ŸWk;{[çˆÿçJ&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,''{#‹Ÿm&îF&öÿ¸¨	ìMm,œœ~Þ	,œÌ
lzàlG`akdíbü»©Ý¿Ù;ÚýDØüø~Àä휜Œ-ì	~²Ê‹þOgsçr;Yü¸	ìL"íŒ\þ)é_¾˜¯³…­³‰»ó?¹MŒ-œì­
<~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrúùÁþ§;ÿU'ÁÿV½½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfaE÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþwþ·Cüÿ{žÿ;´¨‹µµ¬É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìGzZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk[“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:I1Q%ªÿóFýWœüòÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`DlìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþõ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ]¯_zøG¥þGmmÓçW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛdlTÇtº¥°jÑ^7KÒ» š¬ôªÇûS
 Šº%`¸3LŽ7)ü‰]üQHžíá|ÒâP»šê
 ÿ\%ý}þ54>:2Ü{Ú„M•IÊå
 KåïƒÍ§©R!RÕDzÝžeÌ}øØ"œ³\ʤ!g?5íµ	Îk“T$f}QìŒ}}œ7Ãë–aI­zQ£Ø`{1®ËÊ›¡9sõ‰ór5úË<#¤=ø…ˆ´±36…è4Ó+òŽÇ¾a‘Ïp:‰é"“|:[5P6“Ó#\2®˜Æíß»OÍß
6.â'¢ÿp$iÊíù2ŸÒ;LÛ–Oòá ±Fóyº)‘ùµ©ãà~¥ŸC¡ë­„aø
ÅÑ«¨ÙûGæhg[&óâ<1—Xû²Âø{iª_“¸bf)¦Œ²§T˜
ÜÓ»GAe!ógF玦àUa!*ÚZ0Ÿðç/èa0¼€ž~£œ†äwÝo	âïfŸJ³xÛw®ÞaÇL¿õ0è^š`8¿Ú	Ù4Ùç÷Ï©4†V×"”]BÝ3pþà·½_) èIÞ\H$séåXŒ{Òb^Z,ÃÛ6ö©ÉÁ¬–R2µCÇŠ‰t(£ˆOܲÓ7‚9òó`e€²ä@y%0júAÈëRÿ˜à˜~xƒ4wÖ5çíÂàÖ±åmÝÓ×â}=Ð’tRX[>͔ҞÐRÔ "çH³l/é•_r> endobj
-656 0 obj <<
+660 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /KRZENH+URWPalladioL-Bold
+/FontName /UUJGFS+URWPalladioL-Bold
 /ItalicAngle 0
 /StemV 123
 /XHeight 471
 /FontBBox [-152 -301 1000 935]
 /Flags 4
 /CharSet (/fi/fl/exclam/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/question/at/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/emdash)
-/FontFile 657 0 R
+/FontFile 661 0 R
 >> endobj
-1945 0 obj
+1957 0 obj
 [611 611 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 0 500 889 0 278 333 333 444 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 0 0 0 444 747 778 667 722 833 611 556 833 833 389 0 778 611 1000 833 833 611 833 722 611 667 778 778 1000 667 667 667 333 0 333 0 0 0 500 611 444 611 500 389 556 611 333 333 611 333 889 611 556 611 611 389 444 333 611 556 833 500 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 ]
 endobj
-659 0 obj <<
+663 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [650 0 R 677 0 R 687 0 R 742 0 R 806 0 R 867 0 R]
+/Parent 1958 0 R
+/Kids [654 0 R 681 0 R 691 0 R 746 0 R 810 0 R 872 0 R]
 >> endobj
-886 0 obj <<
+891 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [871 0 R 888 0 R 902 0 R 913 0 R 920 0 R 932 0 R]
+/Parent 1958 0 R
+/Kids [876 0 R 893 0 R 907 0 R 918 0 R 925 0 R 937 0 R]
 >> endobj
-944 0 obj <<
+949 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [937 0 R 946 0 R 957 0 R 965 0 R 972 0 R 978 0 R]
+/Parent 1958 0 R
+/Kids [942 0 R 951 0 R 962 0 R 970 0 R 977 0 R 983 0 R]
 >> endobj
-1001 0 obj <<
+1006 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [986 0 R 1008 0 R 1018 0 R 1023 0 R 1027 0 R 1034 0 R]
+/Parent 1958 0 R
+/Kids [991 0 R 1013 0 R 1023 0 R 1028 0 R 1032 0 R 1039 0 R]
 >> endobj
-1050 0 obj <<
+1055 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [1043 0 R 1053 0 R 1060 0 R 1065 0 R 1074 0 R 1081 0 R]
+/Parent 1958 0 R
+/Kids [1048 0 R 1058 0 R 1065 0 R 1070 0 R 1079 0 R 1086 0 R]
 >> endobj
-1093 0 obj <<
+1098 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [1085 0 R 1096 0 R 1101 0 R 1110 0 R 1117 0 R 1126 0 R]
+/Parent 1958 0 R
+/Kids [1090 0 R 1101 0 R 1106 0 R 1115 0 R 1122 0 R 1131 0 R]
 >> endobj
-1145 0 obj <<
+1150 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1136 0 R 1147 0 R 1152 0 R 1158 0 R 1164 0 R 1172 0 R]
+/Parent 1959 0 R
+/Kids [1141 0 R 1152 0 R 1157 0 R 1163 0 R 1169 0 R 1174 0 R]
 >> endobj
-1182 0 obj <<
+1190 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1179 0 R 1184 0 R 1189 0 R 1195 0 R 1199 0 R 1205 0 R]
+/Parent 1959 0 R
+/Kids [1181 0 R 1192 0 R 1196 0 R 1200 0 R 1205 0 R 1211 0 R]
 >> endobj
-1219 0 obj <<
+1221 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1216 0 R 1221 0 R 1225 0 R 1235 0 R 1243 0 R 1248 0 R]
+/Parent 1959 0 R
+/Kids [1217 0 R 1223 0 R 1233 0 R 1237 0 R 1245 0 R 1254 0 R]
 >> endobj
-1255 0 obj <<
+1263 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1252 0 R 1257 0 R 1263 0 R 1271 0 R 1277 0 R 1284 0 R]
+/Parent 1959 0 R
+/Kids [1260 0 R 1265 0 R 1269 0 R 1273 0 R 1281 0 R 1288 0 R]
 >> endobj
-1296 0 obj <<
+1299 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1291 0 R 1298 0 R 1310 0 R 1315 0 R 1321 0 R 1326 0 R]
+/Parent 1959 0 R
+/Kids [1293 0 R 1301 0 R 1309 0 R 1316 0 R 1327 0 R 1331 0 R]
 >> endobj
-1339 0 obj <<
+1341 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1331 0 R 1341 0 R 1345 0 R 1349 0 R 1353 0 R 1361 0 R]
+/Parent 1959 0 R
+/Kids [1337 0 R 1343 0 R 1349 0 R 1357 0 R 1361 0 R 1365 0 R]
 >> endobj
-1382 0 obj <<
+1376 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1366 0 R 1384 0 R 1399 0 R 1414 0 R 1424 0 R 1430 0 R]
+/Parent 1960 0 R
+/Kids [1369 0 R 1378 0 R 1392 0 R 1404 0 R 1426 0 R 1434 0 R]
 >> endobj
-1445 0 obj <<
+1449 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1436 0 R 1447 0 R 1459 0 R 1468 0 R 1474 0 R 1478 0 R]
+/Parent 1960 0 R
+/Kids [1446 0 R 1451 0 R 1460 0 R 1472 0 R 1481 0 R 1490 0 R]
 >> endobj
-1487 0 obj <<
+1499 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1482 0 R 1489 0 R 1500 0 R 1504 0 R 1508 0 R 1519 0 R]
+/Parent 1960 0 R
+/Kids [1494 0 R 1501 0 R 1512 0 R 1516 0 R 1520 0 R 1531 0 R]
 >> endobj
-1529 0 obj <<
+1541 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1523 0 R 1531 0 R 1541 0 R 1600 0 R 1656 0 R 1710 0 R]
+/Parent 1960 0 R
+/Kids [1535 0 R 1543 0 R 1553 0 R 1612 0 R 1668 0 R 1722 0 R]
 >> endobj
-1752 0 obj <<
+1764 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1744 0 R 1754 0 R 1760 0 R 1765 0 R 1769 0 R 1774 0 R]
+/Parent 1960 0 R
+/Kids [1756 0 R 1766 0 R 1772 0 R 1777 0 R 1781 0 R 1786 0 R]
 >> endobj
-1789 0 obj <<
+1801 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1786 0 R 1791 0 R 1803 0 R 1808 0 R 1819 0 R 1824 0 R]
+/Parent 1960 0 R
+/Kids [1798 0 R 1803 0 R 1815 0 R 1820 0 R 1831 0 R 1836 0 R]
 >> endobj
-1839 0 obj <<
+1851 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1949 0 R
-/Kids [1829 0 R 1841 0 R 1853 0 R 1857 0 R 1868 0 R 1873 0 R]
+/Parent 1961 0 R
+/Kids [1841 0 R 1853 0 R 1865 0 R 1869 0 R 1880 0 R 1885 0 R]
 >> endobj
-1889 0 obj <<
+1901 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1949 0 R
-/Kids [1878 0 R 1891 0 R 1901 0 R 1908 0 R 1915 0 R 1924 0 R]
+/Parent 1961 0 R
+/Kids [1890 0 R 1903 0 R 1913 0 R 1920 0 R 1927 0 R 1936 0 R]
 >> endobj
-1946 0 obj <<
+1958 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 1950 0 R
-/Kids [659 0 R 886 0 R 944 0 R 1001 0 R 1050 0 R 1093 0 R]
+/Parent 1962 0 R
+/Kids [663 0 R 891 0 R 949 0 R 1006 0 R 1055 0 R 1098 0 R]
 >> endobj
-1947 0 obj <<
+1959 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 1950 0 R
-/Kids [1145 0 R 1182 0 R 1219 0 R 1255 0 R 1296 0 R 1339 0 R]
+/Parent 1962 0 R
+/Kids [1150 0 R 1190 0 R 1221 0 R 1263 0 R 1299 0 R 1341 0 R]
 >> endobj
-1948 0 obj <<
+1960 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 1950 0 R
-/Kids [1382 0 R 1445 0 R 1487 0 R 1529 0 R 1752 0 R 1789 0 R]
+/Parent 1962 0 R
+/Kids [1376 0 R 1449 0 R 1499 0 R 1541 0 R 1764 0 R 1801 0 R]
 >> endobj
-1949 0 obj <<
+1961 0 obj <<
 /Type /Pages
 /Count 12
-/Parent 1950 0 R
-/Kids [1839 0 R 1889 0 R]
+/Parent 1962 0 R
+/Kids [1851 0 R 1901 0 R]
 >> endobj
-1950 0 obj <<
+1962 0 obj <<
 /Type /Pages
 /Count 120
-/Kids [1946 0 R 1947 0 R 1948 0 R 1949 0 R]
+/Kids [1958 0 R 1959 0 R 1960 0 R 1961 0 R]
 >> endobj
-1951 0 obj <<
+1963 0 obj <<
 /Type /Outlines
 /First 7 0 R
-/Last 607 0 R
+/Last 611 0 R
 /Count 10
 >> endobj
+651 0 obj <<
+/Title 652 0 R
+/A 649 0 R
+/Parent 611 0 R
+/Prev 647 0 R
+>> endobj
 647 0 obj <<
 /Title 648 0 R
 /A 645 0 R
-/Parent 607 0 R
+/Parent 611 0 R
 /Prev 643 0 R
+/Next 651 0 R
 >> endobj
 643 0 obj <<
 /Title 644 0 R
 /A 641 0 R
-/Parent 607 0 R
+/Parent 611 0 R
 /Prev 639 0 R
 /Next 647 0 R
 >> endobj
 639 0 obj <<
 /Title 640 0 R
 /A 637 0 R
-/Parent 607 0 R
+/Parent 611 0 R
 /Prev 635 0 R
 /Next 643 0 R
 >> endobj
 635 0 obj <<
 /Title 636 0 R
 /A 633 0 R
-/Parent 607 0 R
+/Parent 611 0 R
 /Prev 631 0 R
 /Next 639 0 R
 >> endobj
 631 0 obj <<
 /Title 632 0 R
 /A 629 0 R
-/Parent 607 0 R
+/Parent 611 0 R
 /Prev 627 0 R
 /Next 635 0 R
 >> endobj
 627 0 obj <<
 /Title 628 0 R
 /A 625 0 R
-/Parent 607 0 R
+/Parent 611 0 R
 /Prev 623 0 R
 /Next 631 0 R
 >> endobj
 623 0 obj <<
 /Title 624 0 R
 /A 621 0 R
-/Parent 607 0 R
+/Parent 611 0 R
 /Prev 619 0 R
 /Next 627 0 R
 >> endobj
 619 0 obj <<
 /Title 620 0 R
 /A 617 0 R
-/Parent 607 0 R
+/Parent 611 0 R
 /Prev 615 0 R
 /Next 623 0 R
 >> endobj
 615 0 obj <<
 /Title 616 0 R
 /A 613 0 R
-/Parent 607 0 R
-/Prev 611 0 R
+/Parent 611 0 R
 /Next 619 0 R
 >> endobj
 611 0 obj <<
 /Title 612 0 R
 /A 609 0 R
-/Parent 607 0 R
-/Next 615 0 R
+/Parent 1963 0 R
+/Prev 575 0 R
+/First 615 0 R
+/Last 651 0 R
+/Count -10
 >> endobj
 607 0 obj <<
 /Title 608 0 R
 /A 605 0 R
-/Parent 1951 0 R
-/Prev 571 0 R
-/First 611 0 R
-/Last 647 0 R
-/Count -10
+/Parent 595 0 R
+/Prev 603 0 R
 >> endobj
 603 0 obj <<
 /Title 604 0 R
 /A 601 0 R
-/Parent 591 0 R
+/Parent 595 0 R
 /Prev 599 0 R
+/Next 607 0 R
 >> endobj
 599 0 obj <<
 /Title 600 0 R
 /A 597 0 R
-/Parent 591 0 R
-/Prev 595 0 R
+/Parent 595 0 R
 /Next 603 0 R
 >> endobj
 595 0 obj <<
 /Title 596 0 R
 /A 593 0 R
-/Parent 591 0 R
-/Next 599 0 R
+/Parent 575 0 R
+/Prev 587 0 R
+/First 599 0 R
+/Last 607 0 R
+/Count -3
 >> endobj
 591 0 obj <<
 /Title 592 0 R
 /A 589 0 R
-/Parent 571 0 R
-/Prev 583 0 R
-/First 595 0 R
-/Last 603 0 R
-/Count -3
+/Parent 587 0 R
 >> endobj
 587 0 obj <<
 /Title 588 0 R
 /A 585 0 R
-/Parent 583 0 R
+/Parent 575 0 R
+/Prev 579 0 R
+/Next 595 0 R
+/First 591 0 R
+/Last 591 0 R
+/Count -1
 >> endobj
 583 0 obj <<
 /Title 584 0 R
 /A 581 0 R
-/Parent 571 0 R
-/Prev 575 0 R
-/Next 591 0 R
-/First 587 0 R
-/Last 587 0 R
-/Count -1
+/Parent 579 0 R
 >> endobj
 579 0 obj <<
 /Title 580 0 R
 /A 577 0 R
 /Parent 575 0 R
+/Next 587 0 R
+/First 583 0 R
+/Last 583 0 R
+/Count -1
 >> endobj
 575 0 obj <<
 /Title 576 0 R
 /A 573 0 R
-/Parent 571 0 R
-/Next 583 0 R
+/Parent 1963 0 R
+/Prev 555 0 R
+/Next 611 0 R
 /First 579 0 R
-/Last 579 0 R
-/Count -1
+/Last 595 0 R
+/Count -3
 >> endobj
 571 0 obj <<
 /Title 572 0 R
 /A 569 0 R
-/Parent 1951 0 R
-/Prev 551 0 R
-/Next 607 0 R
-/First 575 0 R
-/Last 591 0 R
-/Count -3
+/Parent 555 0 R
+/Prev 567 0 R
 >> endobj
 567 0 obj <<
 /Title 568 0 R
 /A 565 0 R
-/Parent 551 0 R
-/Prev 563 0 R
+/Parent 555 0 R
+/Prev 559 0 R
+/Next 571 0 R
 >> endobj
 563 0 obj <<
 /Title 564 0 R
 /A 561 0 R
-/Parent 551 0 R
-/Prev 555 0 R
-/Next 567 0 R
+/Parent 559 0 R
 >> endobj
 559 0 obj <<
 /Title 560 0 R
 /A 557 0 R
 /Parent 555 0 R
+/Next 567 0 R
+/First 563 0 R
+/Last 563 0 R
+/Count -1
 >> endobj
 555 0 obj <<
 /Title 556 0 R
 /A 553 0 R
-/Parent 551 0 R
-/Next 563 0 R
+/Parent 1963 0 R
+/Prev 531 0 R
+/Next 575 0 R
 /First 559 0 R
-/Last 559 0 R
-/Count -1
+/Last 571 0 R
+/Count -3
 >> endobj
 551 0 obj <<
 /Title 552 0 R
 /A 549 0 R
-/Parent 1951 0 R
-/Prev 527 0 R
-/Next 571 0 R
-/First 555 0 R
-/Last 567 0 R
-/Count -3
+/Parent 531 0 R
+/Prev 539 0 R
 >> endobj
 547 0 obj <<
 /Title 548 0 R
 /A 545 0 R
-/Parent 527 0 R
-/Prev 535 0 R
+/Parent 539 0 R
+/Prev 543 0 R
 >> endobj
 543 0 obj <<
 /Title 544 0 R
 /A 541 0 R
-/Parent 535 0 R
-/Prev 539 0 R
+/Parent 539 0 R
+/Next 547 0 R
 >> endobj
 539 0 obj <<
 /Title 540 0 R
 /A 537 0 R
-/Parent 535 0 R
-/Next 543 0 R
+/Parent 531 0 R
+/Prev 535 0 R
+/Next 551 0 R
+/First 543 0 R
+/Last 547 0 R
+/Count -2
 >> endobj
 535 0 obj <<
 /Title 536 0 R
 /A 533 0 R
-/Parent 527 0 R
-/Prev 531 0 R
-/Next 547 0 R
-/First 539 0 R
-/Last 543 0 R
-/Count -2
+/Parent 531 0 R
+/Next 539 0 R
 >> endobj
 531 0 obj <<
 /Title 532 0 R
 /A 529 0 R
-/Parent 527 0 R
-/Next 535 0 R
+/Parent 1963 0 R
+/Prev 243 0 R
+/Next 555 0 R
+/First 535 0 R
+/Last 551 0 R
+/Count -3
 >> endobj
 527 0 obj <<
 /Title 528 0 R
 /A 525 0 R
-/Parent 1951 0 R
-/Prev 243 0 R
-/Next 551 0 R
-/First 531 0 R
-/Last 547 0 R
-/Count -3
+/Parent 479 0 R
+/Prev 523 0 R
 >> endobj
 523 0 obj <<
 /Title 524 0 R
 /A 521 0 R
-/Parent 475 0 R
-/Prev 519 0 R
+/Parent 479 0 R
+/Prev 507 0 R
+/Next 527 0 R
 >> endobj
 519 0 obj <<
 /Title 520 0 R
 /A 517 0 R
-/Parent 475 0 R
-/Prev 503 0 R
-/Next 523 0 R
+/Parent 507 0 R
+/Prev 515 0 R
 >> endobj
 515 0 obj <<
 /Title 516 0 R
 /A 513 0 R
-/Parent 503 0 R
+/Parent 507 0 R
 /Prev 511 0 R
+/Next 519 0 R
 >> endobj
 511 0 obj <<
 /Title 512 0 R
 /A 509 0 R
-/Parent 503 0 R
-/Prev 507 0 R
+/Parent 507 0 R
 /Next 515 0 R
 >> endobj
 507 0 obj <<
 /Title 508 0 R
 /A 505 0 R
-/Parent 503 0 R
-/Next 511 0 R
+/Parent 479 0 R
+/Prev 503 0 R
+/Next 523 0 R
+/First 511 0 R
+/Last 519 0 R
+/Count -3
 >> endobj
 503 0 obj <<
 /Title 504 0 R
 /A 501 0 R
-/Parent 475 0 R
+/Parent 479 0 R
 /Prev 499 0 R
-/Next 519 0 R
-/First 507 0 R
-/Last 515 0 R
-/Count -3
+/Next 507 0 R
 >> endobj
 499 0 obj <<
 /Title 500 0 R
 /A 497 0 R
-/Parent 475 0 R
+/Parent 479 0 R
 /Prev 495 0 R
 /Next 503 0 R
 >> endobj
 495 0 obj <<
 /Title 496 0 R
 /A 493 0 R
-/Parent 475 0 R
-/Prev 491 0 R
+/Parent 479 0 R
+/Prev 483 0 R
 /Next 499 0 R
 >> endobj
 491 0 obj <<
 /Title 492 0 R
 /A 489 0 R
-/Parent 475 0 R
-/Prev 479 0 R
-/Next 495 0 R
+/Parent 483 0 R
+/Prev 487 0 R
 >> endobj
 487 0 obj <<
 /Title 488 0 R
 /A 485 0 R
-/Parent 479 0 R
-/Prev 483 0 R
+/Parent 483 0 R
+/Next 491 0 R
 >> endobj
 483 0 obj <<
 /Title 484 0 R
 /A 481 0 R
 /Parent 479 0 R
-/Next 487 0 R
+/Next 495 0 R
+/First 487 0 R
+/Last 491 0 R
+/Count -2
 >> endobj
 479 0 obj <<
 /Title 480 0 R
 /A 477 0 R
-/Parent 475 0 R
-/Next 491 0 R
+/Parent 243 0 R
+/Prev 275 0 R
 /First 483 0 R
-/Last 487 0 R
-/Count -2
+/Last 527 0 R
+/Count -7
 >> endobj
 475 0 obj <<
 /Title 476 0 R
 /A 473 0 R
-/Parent 243 0 R
-/Prev 275 0 R
-/First 479 0 R
-/Last 523 0 R
-/Count -7
+/Parent 459 0 R
+/Prev 471 0 R
 >> endobj
 471 0 obj <<
 /Title 472 0 R
 /A 469 0 R
-/Parent 455 0 R
+/Parent 459 0 R
 /Prev 467 0 R
+/Next 475 0 R
 >> endobj
 467 0 obj <<
 /Title 468 0 R
 /A 465 0 R
-/Parent 455 0 R
+/Parent 459 0 R
 /Prev 463 0 R
 /Next 471 0 R
 >> endobj
 463 0 obj <<
 /Title 464 0 R
 /A 461 0 R
-/Parent 455 0 R
-/Prev 459 0 R
+/Parent 459 0 R
 /Next 467 0 R
 >> endobj
 459 0 obj <<
 /Title 460 0 R
 /A 457 0 R
-/Parent 455 0 R
-/Next 463 0 R
+/Parent 275 0 R
+/Prev 455 0 R
+/First 463 0 R
+/Last 475 0 R
+/Count -4
 >> endobj
 455 0 obj <<
 /Title 456 0 R
 /A 453 0 R
 /Parent 275 0 R
 /Prev 451 0 R
-/First 459 0 R
-/Last 471 0 R
-/Count -4
+/Next 459 0 R
 >> endobj
 451 0 obj <<
 /Title 452 0 R
@@ -10200,156 +10259,156 @@ endobj
 /Title 432 0 R
 /A 429 0 R
 /Parent 275 0 R
-/Prev 427 0 R
+/Prev 351 0 R
 /Next 435 0 R
 >> endobj
 427 0 obj <<
 /Title 428 0 R
 /A 425 0 R
-/Parent 275 0 R
-/Prev 347 0 R
-/Next 431 0 R
+/Parent 351 0 R
+/Prev 423 0 R
 >> endobj
 423 0 obj <<
 /Title 424 0 R
 /A 421 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 419 0 R
+/Next 427 0 R
 >> endobj
 419 0 obj <<
 /Title 420 0 R
 /A 417 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 415 0 R
 /Next 423 0 R
 >> endobj
 415 0 obj <<
 /Title 416 0 R
 /A 413 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 411 0 R
 /Next 419 0 R
 >> endobj
 411 0 obj <<
 /Title 412 0 R
 /A 409 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 407 0 R
 /Next 415 0 R
 >> endobj
 407 0 obj <<
 /Title 408 0 R
 /A 405 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 403 0 R
 /Next 411 0 R
 >> endobj
 403 0 obj <<
 /Title 404 0 R
 /A 401 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 399 0 R
 /Next 407 0 R
 >> endobj
 399 0 obj <<
 /Title 400 0 R
 /A 397 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 395 0 R
 /Next 403 0 R
 >> endobj
 395 0 obj <<
 /Title 396 0 R
 /A 393 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 391 0 R
 /Next 399 0 R
 >> endobj
 391 0 obj <<
 /Title 392 0 R
 /A 389 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 387 0 R
 /Next 395 0 R
 >> endobj
 387 0 obj <<
 /Title 388 0 R
 /A 385 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 383 0 R
 /Next 391 0 R
 >> endobj
 383 0 obj <<
 /Title 384 0 R
 /A 381 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 379 0 R
 /Next 387 0 R
 >> endobj
 379 0 obj <<
 /Title 380 0 R
 /A 377 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 375 0 R
 /Next 383 0 R
 >> endobj
 375 0 obj <<
 /Title 376 0 R
 /A 373 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 371 0 R
 /Next 379 0 R
 >> endobj
 371 0 obj <<
 /Title 372 0 R
 /A 369 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 367 0 R
 /Next 375 0 R
 >> endobj
 367 0 obj <<
 /Title 368 0 R
 /A 365 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 363 0 R
 /Next 371 0 R
 >> endobj
 363 0 obj <<
 /Title 364 0 R
 /A 361 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 359 0 R
 /Next 367 0 R
 >> endobj
 359 0 obj <<
 /Title 360 0 R
 /A 357 0 R
-/Parent 347 0 R
+/Parent 351 0 R
 /Prev 355 0 R
 /Next 363 0 R
 >> endobj
 355 0 obj <<
 /Title 356 0 R
 /A 353 0 R
-/Parent 347 0 R
-/Prev 351 0 R
+/Parent 351 0 R
 /Next 359 0 R
 >> endobj
 351 0 obj <<
 /Title 352 0 R
 /A 349 0 R
-/Parent 347 0 R
-/Next 355 0 R
+/Parent 275 0 R
+/Prev 347 0 R
+/Next 431 0 R
+/First 355 0 R
+/Last 427 0 R
+/Count -19
 >> endobj
 347 0 obj <<
 /Title 348 0 R
 /A 345 0 R
 /Parent 275 0 R
 /Prev 343 0 R
-/Next 427 0 R
-/First 351 0 R
-/Last 423 0 R
-/Count -19
+/Next 351 0 R
 >> endobj
 343 0 obj <<
 /Title 344 0 R
@@ -10376,21 +10435,21 @@ endobj
 /Title 332 0 R
 /A 329 0 R
 /Parent 275 0 R
-/Prev 327 0 R
+/Prev 315 0 R
 /Next 335 0 R
 >> endobj
 327 0 obj <<
 /Title 328 0 R
 /A 325 0 R
-/Parent 275 0 R
-/Prev 315 0 R
-/Next 331 0 R
+/Parent 315 0 R
+/Prev 323 0 R
 >> endobj
 323 0 obj <<
 /Title 324 0 R
 /A 321 0 R
 /Parent 315 0 R
 /Prev 319 0 R
+/Next 327 0 R
 >> endobj
 319 0 obj <<
 /Title 320 0 R
@@ -10403,10 +10462,10 @@ endobj
 /A 313 0 R
 /Parent 275 0 R
 /Prev 311 0 R
-/Next 327 0 R
+/Next 331 0 R
 /First 319 0 R
-/Last 323 0 R
-/Count -2
+/Last 327 0 R
+/Count -3
 >> endobj
 311 0 obj <<
 /Title 312 0 R
@@ -10475,9 +10534,9 @@ endobj
 /A 273 0 R
 /Parent 243 0 R
 /Prev 247 0 R
-/Next 475 0 R
+/Next 479 0 R
 /First 279 0 R
-/Last 455 0 R
+/Last 459 0 R
 /Count -24
 >> endobj
 271 0 obj <<
@@ -10534,11 +10593,11 @@ endobj
 243 0 obj <<
 /Title 244 0 R
 /A 241 0 R
-/Parent 1951 0 R
+/Parent 1963 0 R
 /Prev 231 0 R
-/Next 527 0 R
+/Next 531 0 R
 /First 247 0 R
-/Last 475 0 R
+/Last 479 0 R
 /Count -3
 >> endobj
 239 0 obj <<
@@ -10556,7 +10615,7 @@ endobj
 231 0 obj <<
 /Title 232 0 R
 /A 229 0 R
-/Parent 1951 0 R
+/Parent 1963 0 R
 /Prev 131 0 R
 /Next 243 0 R
 /First 235 0 R
@@ -10738,7 +10797,7 @@ endobj
 131 0 obj <<
 /Title 132 0 R
 /A 129 0 R
-/Parent 1951 0 R
+/Parent 1963 0 R
 /Prev 91 0 R
 /Next 231 0 R
 /First 135 0 R
@@ -10812,7 +10871,7 @@ endobj
 91 0 obj <<
 /Title 92 0 R
 /A 89 0 R
-/Parent 1951 0 R
+/Parent 1963 0 R
 /Prev 67 0 R
 /Next 131 0 R
 /First 95 0 R
@@ -10855,7 +10914,7 @@ endobj
 67 0 obj <<
 /Title 68 0 R
 /A 65 0 R
-/Parent 1951 0 R
+/Parent 1963 0 R
 /Prev 7 0 R
 /Next 91 0 R
 /First 71 0 R
@@ -10964,2001 +11023,2013 @@ endobj
 7 0 obj <<
 /Title 8 0 R
 /A 5 0 R
-/Parent 1951 0 R
+/Parent 1963 0 R
 /Next 67 0 R
 /First 11 0 R
 /Last 23 0 R
 /Count -4
 >> endobj
-1952 0 obj <<
-/Names [(Access_Control_Lists) 1486 0 R (Bv9ARM.ch01) 874 0 R (Bv9ARM.ch02) 923 0 R (Bv9ARM.ch03) 940 0 R (Bv9ARM.ch04) 989 0 R (Bv9ARM.ch05) 1077 0 R (Bv9ARM.ch06) 1088 0 R (Bv9ARM.ch07) 1485 0 R (Bv9ARM.ch08) 1511 0 R (Bv9ARM.ch09) 1526 0 R (Bv9ARM.ch10) 1747 0 R (Configuration_File_Grammar) 1113 0 R (DNSSEC) 1056 0 R (Doc-Start) 655 0 R (Setting_TTLs) 1452 0 R (acache) 930 0 R (access_control) 1231 0 R (acl) 1121 0 R (address_match_lists) 1094 0 R (admin_tools) 963 0 R (appendix.A) 570 0 R (appendix.B) 606 0 R (bibliography) 1535 0 R (boolean_options) 1005 0 R (builtin) 1305 0 R (chapter*.1) 690 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 526 0 R (chapter.8) 550 0 R (cite.RFC1033) 1662 0 R (cite.RFC1034) 1547 0 R (cite.RFC1035) 1549 0 R (cite.RFC1101) 1644 0 R (cite.RFC1123) 1646 0 R (cite.RFC1183) 1606 0 R (cite.RFC1464) 1684 0 R (cite.RFC1535) 1592 0 R (cite.RFC1536) 1594 0 R (cite.RFC1537) 1664 0 R (cite.RFC1591) 1648 0 R (cite.RFC1706) 1608 0 R (cite.RFC1712) 1704 0 R (cite.RFC1713) 1686 0 R (cite.RFC1794) 1688 0 R (cite.RFC1876) 1610 0 R (cite.RFC1912) 1666 0 R (cite.RFC1982) 1596 0 R (cite.RFC1995) 1554 0 R (cite.RFC1996) 1556 0 R (cite.RFC2010) 1668 0 R (cite.RFC2052) 1612 0 R (cite.RFC2065) 1716 0 R (cite.RFC2136) 1558 0 R (cite.RFC2137) 1718 0 R (cite.RFC2163) 1614 0 R (cite.RFC2168) 1616 0 R (cite.RFC2181) 1560 0 R (cite.RFC2219) 1670 0 R (cite.RFC2230) 1618 0 R (cite.RFC2240) 1690 0 R (cite.RFC2308) 1562 0 R (cite.RFC2317) 1650 0 R (cite.RFC2345) 1692 0 R (cite.RFC2352) 1694 0 R (cite.RFC2535) 1720 0 R (cite.RFC2536) 1620 0 R (cite.RFC2537) 1622 0 R (cite.RFC2538) 1624 0 R (cite.RFC2539) 1626 0 R (cite.RFC2540) 1628 0 R (cite.RFC2671) 1564 0 R (cite.RFC2672) 1566 0 R (cite.RFC2673) 1706 0 R (cite.RFC2782) 1630 0 R (cite.RFC2825) 1674 0 R (cite.RFC2826) 1652 0 R (cite.RFC2845) 1568 0 R (cite.RFC2874) 1708 0 R (cite.RFC2915) 1632 0 R (cite.RFC2929) 1654 0 R (cite.RFC2930) 1570 0 R (cite.RFC2931) 1572 0 R (cite.RFC3007) 1574 0 R (cite.RFC3008) 1722 0 R (cite.RFC3071) 1696 0 R (cite.RFC3090) 1724 0 R (cite.RFC3110) 1634 0 R (cite.RFC3123) 1636 0 R (cite.RFC3225) 1580 0 R (cite.RFC3258) 1698 0 R (cite.RFC3445) 1726 0 R (cite.RFC3490) 1676 0 R (cite.RFC3491) 1678 0 R (cite.RFC3492) 1680 0 R (cite.RFC3596) 1638 0 R (cite.RFC3597) 1640 0 R (cite.RFC3645) 1576 0 R (cite.RFC3655) 1728 0 R (cite.RFC3658) 1730 0 R (cite.RFC3755) 1732 0 R (cite.RFC3757) 1734 0 R (cite.RFC3833) 1582 0 R (cite.RFC3845) 1736 0 R (cite.RFC3901) 1700 0 R (cite.RFC4033) 1584 0 R (cite.RFC4035) 1586 0 R (cite.RFC4044) 1588 0 R (cite.RFC4074) 1598 0 R (cite.RFC974) 1551 0 R (cite.id2499963) 1741 0 R (configuration_file_elements) 1089 0 R (controls_statement_definition_and_usage) 976 0 R (diagnostic_tools) 911 0 R (dynamic_update) 999 0 R (dynamic_update_policies) 1051 0 R (dynamic_update_security) 1241 0 R (empty) 1313 0 R (historical_dns_information) 1528 0 R (id2464966) 875 0 R (id2466572) 876 0 R (id2467531) 880 0 R (id2467541) 881 0 R (id2467713) 893 0 R (id2467734) 894 0 R (id2467768) 895 0 R (id2467852) 898 0 R (id2467945) 891 0 R (id2470250) 905 0 R (id2470274) 908 0 R (id2470372) 909 0 R (id2470393) 910 0 R (id2470423) 916 0 R (id2470526) 917 0 R (id2470553) 918 0 R (id2470587) 924 0 R (id2470614) 925 0 R (id2470627) 926 0 R (id2470721) 929 0 R (id2470731) 935 0 R (id2470763) 942 0 R (id2470779) 943 0 R (id2470802) 949 0 R (id2470819) 950 0 R (id2471156) 953 0 R (id2471161) 954 0 R (id2473080) 981 0 R (id2473092) 982 0 R (id2473469) 1014 0 R (id2473488) 1015 0 R (id2473923) 1031 0 R (id2473940) 1032 0 R (id2473978) 1037 0 R (id2473996) 1038 0 R (id2474007) 1039 0 R (id2474046) 1040 0 R (id2474172) 1041 0 R (id2474285) 1047 0 R (id2474299) 1048 0 R (id2474417) 1049 0 R (id2474621) 1057 0 R (id2474691) 1058 0 R (id2474770) 1063 0 R (id2474844) 1068 0 R (id2474974) 1070 0 R (id2474996) 1071 0 R (id2475165) 1078 0 R (id2475313) 1090 0 R (id2476171) 1099 0 R (id2476199) 1104 0 R (id2476374) 1105 0 R (id2476389) 1106 0 R (id2476419) 1107 0 R (id2476502) 1114 0 R (id2476918) 1120 0 R (id2476961) 1122 0 R (id2477176) 1124 0 R (id2477605) 1131 0 R (id2477622) 1132 0 R (id2477645) 1133 0 R (id2477669) 1139 0 R (id2477760) 1143 0 R (id2477885) 1144 0 R (id2477938) 1150 0 R (id2478768) 1161 0 R (id2479441) 1167 0 R (id2479514) 1168 0 R (id2479578) 1175 0 R (id2479622) 1176 0 R (id2479637) 1177 0 R (id2481622) 1202 0 R (id2483531) 1228 0 R (id2483590) 1230 0 R (id2484011) 1240 0 R (id2485010) 1260 0 R (id2485069) 1266 0 R (id2485253) 1268 0 R (id2485483) 1274 0 R (id2486119) 1288 0 R (id2487441) 1318 0 R (id2488552) 1335 0 R (id2488603) 1336 0 R (id2488685) 1338 0 R (id2490133) 1356 0 R (id2490140) 1357 0 R (id2490146) 1358 0 R (id2490560) 1364 0 R (id2490593) 1369 0 R (id2492021) 1411 0 R (id2492346) 1417 0 R (id2492364) 1418 0 R (id2492385) 1421 0 R (id2492621) 1427 0 R (id2493653) 1433 0 R (id2493781) 1439 0 R (id2493802) 1440 0 R (id2494233) 1442 0 R (id2494370) 1444 0 R (id2494392) 1450 0 R (id2494865) 1453 0 R (id2494989) 1455 0 R (id2495004) 1456 0 R (id2495253) 1462 0 R (id2495275) 1463 0 R (id2495336) 1464 0 R (id2495405) 1465 0 R (id2495442) 1466 0 R (id2495504) 1471 0 R (id2496119) 1496 0 R (id2496196) 1497 0 R (id2496256) 1498 0 R (id2496336) 1512 0 R (id2496341) 1513 0 R (id2496353) 1514 0 R (id2496370) 1515 0 R (id2496432) 1527 0 R (id2496672) 1534 0 R (id2496928) 1539 0 R (id2496930) 1545 0 R (id2496938) 1550 0 R (id2496962) 1546 0 R (id2496985) 1548 0 R (id2497021) 1559 0 R (id2497048) 1561 0 R (id2497074) 1553 0 R (id2497098) 1555 0 R (id2497122) 1557 0 R (id2497177) 1563 0 R (id2497204) 1565 0 R (id2497230) 1567 0 R (id2497361) 1569 0 R (id2497390) 1571 0 R (id2497420) 1573 0 R (id2497447) 1575 0 R (id2497522) 1578 0 R (id2497529) 1579 0 R (id2497556) 1581 0 R (id2497592) 1583 0 R (id2497657) 1587 0 R (id2497722) 1585 0 R (id2497787) 1590 0 R (id2497796) 1591 0 R (id2497821) 1593 0 R (id2497890) 1595 0 R (id2497925) 1597 0 R (id2497965) 1604 0 R (id2497971) 1605 0 R (id2498028) 1607 0 R (id2498066) 1615 0 R (id2498101) 1609 0 R (id2498155) 1611 0 R (id2498194) 1613 0 R (id2498219) 1617 0 R (id2498245) 1619 0 R (id2498272) 1621 0 R (id2498298) 1623 0 R (id2498338) 1625 0 R (id2498368) 1627 0 R (id2498397) 1629 0 R (id2498440) 1631 0 R (id2498473) 1633 0 R (id2498500) 1635 0 R (id2498523) 1637 0 R (id2498581) 1639 0 R (id2498605) 1642 0 R (id2498613) 1643 0 R (id2498638) 1645 0 R (id2498661) 1647 0 R (id2498684) 1649 0 R (id2498730) 1651 0 R (id2498754) 1653 0 R (id2498804) 1660 0 R (id2498811) 1661 0 R (id2498835) 1663 0 R (id2498861) 1665 0 R (id2498888) 1667 0 R (id2498924) 1669 0 R (id2498965) 1672 0 R (id2498970) 1673 0 R (id2499002) 1675 0 R (id2499048) 1677 0 R (id2499083) 1679 0 R (id2499110) 1682 0 R (id2499128) 1683 0 R (id2499150) 1685 0 R (id2499176) 1687 0 R (id2499202) 1689 0 R (id2499225) 1691 0 R (id2499271) 1693 0 R (id2499294) 1695 0 R (id2499321) 1697 0 R (id2499347) 1699 0 R (id2499384) 1702 0 R (id2499390) 1703 0 R (id2499448) 1705 0 R (id2499475) 1707 0 R (id2499511) 1714 0 R (id2499523) 1715 0 R (id2499562) 1717 0 R (id2499657) 1719 0 R (id2499687) 1721 0 R (id2499713) 1723 0 R (id2499739) 1725 0 R (id2499776) 1727 0 R (id2499812) 1729 0 R (id2499838) 1731 0 R (id2499865) 1733 0 R (id2499910) 1735 0 R (id2499952) 1738 0 R (id2499961) 1740 0 R (id2499963) 1742 0 R (incremental_zone_transfers) 1011 0 R (internet_drafts) 1737 0 R (ipv6addresses) 1072 0 R (journal) 1000 0 R (lwresd) 1079 0 R (man.dig) 1748 0 R (man.dnssec-keygen) 1797 0 R (man.dnssec-signzone) 1814 0 R (man.host) 1781 0 R (man.named) 1863 0 R (man.named-checkconf) 1834 0 R (man.named-checkzone) 1847 0 R (man.rndc) 1885 0 R (man.rndc-confgen) 1918 0 R (man.rndc.conf) 1898 0 R (notify) 990 0 R (options) 1187 0 R (page.1) 654 0 R (page.10) 915 0 R (page.100) 1767 0 R (page.101) 1771 0 R (page.102) 1776 0 R (page.103) 1788 0 R (page.104) 1793 0 R (page.105) 1805 0 R (page.106) 1810 0 R (page.107) 1821 0 R (page.108) 1826 0 R (page.109) 1831 0 R (page.11) 922 0 R (page.110) 1843 0 R (page.111) 1855 0 R (page.112) 1859 0 R (page.113) 1870 0 R (page.114) 1875 0 R (page.115) 1880 0 R (page.116) 1893 0 R (page.117) 1903 0 R (page.118) 1910 0 R (page.119) 1917 0 R (page.12) 934 0 R (page.120) 1926 0 R (page.13) 939 0 R (page.14) 948 0 R (page.15) 959 0 R (page.16) 967 0 R (page.17) 974 0 R (page.18) 980 0 R (page.19) 988 0 R (page.2) 679 0 R (page.20) 1010 0 R (page.21) 1020 0 R (page.22) 1025 0 R (page.23) 1029 0 R (page.24) 1036 0 R (page.25) 1045 0 R (page.26) 1055 0 R (page.27) 1062 0 R (page.28) 1067 0 R (page.29) 1076 0 R (page.3) 689 0 R (page.30) 1083 0 R (page.31) 1087 0 R (page.32) 1098 0 R (page.33) 1103 0 R (page.34) 1112 0 R (page.35) 1119 0 R (page.36) 1128 0 R (page.37) 1138 0 R (page.38) 1149 0 R (page.39) 1154 0 R (page.4) 744 0 R (page.40) 1160 0 R (page.41) 1166 0 R (page.42) 1174 0 R (page.43) 1181 0 R (page.44) 1186 0 R (page.45) 1191 0 R (page.46) 1197 0 R (page.47) 1201 0 R (page.48) 1207 0 R (page.49) 1218 0 R (page.5) 808 0 R (page.50) 1223 0 R (page.51) 1227 0 R (page.52) 1237 0 R (page.53) 1245 0 R (page.54) 1250 0 R (page.55) 1254 0 R (page.56) 1259 0 R (page.57) 1265 0 R (page.58) 1273 0 R (page.59) 1279 0 R (page.6) 869 0 R (page.60) 1286 0 R (page.61) 1293 0 R (page.62) 1300 0 R (page.63) 1312 0 R (page.64) 1317 0 R (page.65) 1323 0 R (page.66) 1328 0 R (page.67) 1333 0 R (page.68) 1343 0 R (page.69) 1347 0 R (page.7) 873 0 R (page.70) 1351 0 R (page.71) 1355 0 R (page.72) 1363 0 R (page.73) 1368 0 R (page.74) 1386 0 R (page.75) 1401 0 R (page.76) 1416 0 R (page.77) 1426 0 R (page.78) 1432 0 R (page.79) 1438 0 R (page.8) 890 0 R (page.80) 1449 0 R (page.81) 1461 0 R (page.82) 1470 0 R (page.83) 1476 0 R (page.84) 1480 0 R (page.85) 1484 0 R (page.86) 1491 0 R (page.87) 1502 0 R (page.88) 1506 0 R (page.89) 1510 0 R (page.9) 904 0 R (page.90) 1521 0 R (page.91) 1525 0 R (page.92) 1533 0 R (page.93) 1543 0 R (page.94) 1602 0 R (page.95) 1658 0 R (page.96) 1712 0 R (page.97) 1746 0 R (page.98) 1756 0 R (page.99) 1762 0 R (proposed_standards) 1016 0 R (query_address) 1246 0 R (rfcs) 900 0 R (rndc) 1134 0 R (rrset_ordering) 955 0 R (sample_configuration) 941 0 R (section*.10) 1671 0 R (section*.11) 1681 0 R (section*.12) 1701 0 R (section*.13) 1713 0 R (section*.14) 1739 0 R (section*.15) 1749 0 R (section*.16) 1750 0 R (section*.17) 1751 0 R (section*.18) 1757 0 R (section*.19) 1758 0 R (section*.2) 1538 0 R (section*.20) 1763 0 R (section*.21) 1772 0 R (section*.22) 1777 0 R (section*.23) 1778 0 R (section*.24) 1779 0 R (section*.25) 1780 0 R (section*.26) 1782 0 R (section*.27) 1783 0 R (section*.28) 1784 0 R (section*.29) 1794 0 R (section*.3) 1544 0 R (section*.30) 1795 0 R (section*.31) 1796 0 R (section*.32) 1798 0 R (section*.33) 1799 0 R (section*.34) 1800 0 R (section*.35) 1801 0 R (section*.36) 1806 0 R (section*.37) 1811 0 R (section*.38) 1812 0 R (section*.39) 1813 0 R (section*.4) 1552 0 R (section*.40) 1815 0 R (section*.41) 1816 0 R (section*.42) 1817 0 R (section*.43) 1822 0 R (section*.44) 1827 0 R (section*.45) 1832 0 R (section*.46) 1833 0 R (section*.47) 1835 0 R (section*.48) 1836 0 R (section*.49) 1837 0 R (section*.5) 1577 0 R (section*.50) 1838 0 R (section*.51) 1844 0 R (section*.52) 1845 0 R (section*.53) 1846 0 R (section*.54) 1848 0 R (section*.55) 1849 0 R (section*.56) 1850 0 R (section*.57) 1851 0 R (section*.58) 1860 0 R (section*.59) 1861 0 R (section*.6) 1589 0 R (section*.60) 1862 0 R (section*.61) 1864 0 R (section*.62) 1865 0 R (section*.63) 1866 0 R (section*.64) 1871 0 R (section*.65) 1876 0 R (section*.66) 1881 0 R (section*.67) 1882 0 R (section*.68) 1883 0 R (section*.69) 1884 0 R (section*.7) 1603 0 R (section*.70) 1886 0 R (section*.71) 1887 0 R (section*.72) 1888 0 R (section*.73) 1894 0 R (section*.74) 1895 0 R (section*.75) 1896 0 R (section*.76) 1897 0 R (section*.77) 1899 0 R (section*.78) 1904 0 R (section*.79) 1905 0 R (section*.8) 1641 0 R (section*.80) 1906 0 R (section*.81) 1911 0 R (section*.82) 1912 0 R (section*.83) 1913 0 R (section*.84) 1919 0 R (section*.85) 1920 0 R (section*.86) 1921 0 R (section*.87) 1922 0 R (section*.88) 1927 0 R (section*.89) 1928 0 R (section*.9) 1659 0 R (section*.90) 1929 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 474 0 R (section.7.1) 530 0 R (section.7.2) 534 0 R (section.7.3) 546 0 R (section.8.1) 554 0 R (section.8.2) 562 0 R (section.8.3) 566 0 R (section.A.1) 574 0 R (section.A.2) 582 0 R (section.A.3) 590 0 R (section.B.1) 610 0 R (section.B.10) 646 0 R (section.B.2) 614 0 R (section.B.3) 618 0 R (section.B.4) 622 0 R (section.B.5) 626 0 R (section.B.6) 630 0 R (section.B.7) 634 0 R (section.B.8) 638 0 R (section.B.9) 642 0 R (server_statement_definition_and_usage) 1214 0 R (server_statement_grammar) 1324 0 R (statsfile) 1193 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 326 0 R (subsection.6.2.12) 330 0 R (subsection.6.2.13) 334 0 R (subsection.6.2.14) 338 0 R (subsection.6.2.15) 342 0 R (subsection.6.2.16) 346 0 R (subsection.6.2.17) 426 0 R (subsection.6.2.18) 430 0 R (subsection.6.2.19) 434 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 438 0 R (subsection.6.2.21) 442 0 R (subsection.6.2.22) 446 0 R (subsection.6.2.23) 450 0 R (subsection.6.2.24) 454 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 478 0 R (subsection.6.3.2) 490 0 R (subsection.6.3.3) 494 0 R (subsection.6.3.4) 498 0 R (subsection.6.3.5) 502 0 R (subsection.6.3.6) 518 0 R (subsection.6.3.7) 522 0 R (subsection.7.2.1) 538 0 R (subsection.7.2.2) 542 0 R (subsection.8.1.1) 558 0 R (subsection.A.1.1) 578 0 R (subsection.A.2.1) 586 0 R (subsection.A.3.1) 594 0 R (subsection.A.3.2) 598 0 R (subsection.A.3.3) 602 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.16.1) 350 0 R (subsubsection.6.2.16.10) 386 0 R (subsubsection.6.2.16.11) 390 0 R (subsubsection.6.2.16.12) 394 0 R (subsubsection.6.2.16.13) 398 0 R (subsubsection.6.2.16.14) 402 0 R (subsubsection.6.2.16.15) 406 0 R (subsubsection.6.2.16.16) 410 0 R (subsubsection.6.2.16.17) 414 0 R (subsubsection.6.2.16.18) 418 0 R (subsubsection.6.2.16.19) 422 0 R (subsubsection.6.2.16.2) 354 0 R (subsubsection.6.2.16.3) 358 0 R (subsubsection.6.2.16.4) 362 0 R (subsubsection.6.2.16.5) 366 0 R (subsubsection.6.2.16.6) 370 0 R (subsubsection.6.2.16.7) 374 0 R (subsubsection.6.2.16.8) 378 0 R (subsubsection.6.2.16.9) 382 0 R (subsubsection.6.2.24.1) 458 0 R (subsubsection.6.2.24.2) 462 0 R (subsubsection.6.2.24.3) 466 0 R (subsubsection.6.2.24.4) 470 0 R (subsubsection.6.3.1.1) 482 0 R (subsubsection.6.3.1.2) 486 0 R (subsubsection.6.3.5.1) 506 0 R (subsubsection.6.3.5.2) 510 0 R (subsubsection.6.3.5.3) 514 0 R (table.1.1) 882 0 R (table.1.2) 892 0 R (table.3.1) 951 0 R (table.3.2) 983 0 R (table.6.1) 1091 0 R (table.6.10) 1422 0 R (table.6.11) 1428 0 R (table.6.12) 1434 0 R (table.6.13) 1441 0 R (table.6.14) 1443 0 R (table.6.15) 1451 0 R (table.6.16) 1454 0 R (table.6.17) 1457 0 R (table.6.18) 1472 0 R (table.6.2) 1115 0 R (table.6.3) 1123 0 R (table.6.4) 1162 0 R (table.6.5) 1203 0 R (table.6.6) 1289 0 R (table.6.7) 1319 0 R (table.6.8) 1359 0 R (table.6.9) 1412 0 R (the_category_phrase) 1156 0 R (the_sortlist_statement) 1280 0 R (topology) 1275 0 R (tsig) 1030 0 R (tuning) 1294 0 R (types_of_resource_records_and_when_to_use_them) 899 0 R (view_statement_grammar) 1308 0 R (zone_statement_grammar) 1233 0 R (zone_transfers) 1006 0 R (zonefile_format) 1307 0 R]
+1964 0 obj <<
+/Names [(Access_Control_Lists) 1498 0 R (Bv9ARM.ch01) 879 0 R (Bv9ARM.ch02) 928 0 R (Bv9ARM.ch03) 945 0 R (Bv9ARM.ch04) 994 0 R (Bv9ARM.ch05) 1082 0 R (Bv9ARM.ch06) 1093 0 R (Bv9ARM.ch07) 1497 0 R (Bv9ARM.ch08) 1523 0 R (Bv9ARM.ch09) 1538 0 R (Bv9ARM.ch10) 1759 0 R (Configuration_File_Grammar) 1118 0 R (DNSSEC) 1061 0 R (Doc-Start) 659 0 R (Setting_TTLs) 1468 0 R (acache) 935 0 R (access_control) 1248 0 R (acl) 1126 0 R (address_match_lists) 1099 0 R (admin_tools) 968 0 R (appendix.A) 574 0 R (appendix.B) 610 0 R (bibliography) 1547 0 R (boolean_options) 1010 0 R (builtin) 1322 0 R (chapter*.1) 694 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) 530 0 R (chapter.8) 554 0 R (cite.RFC1033) 1674 0 R (cite.RFC1034) 1559 0 R (cite.RFC1035) 1561 0 R (cite.RFC1101) 1656 0 R (cite.RFC1123) 1658 0 R (cite.RFC1183) 1618 0 R (cite.RFC1464) 1696 0 R (cite.RFC1535) 1604 0 R (cite.RFC1536) 1606 0 R (cite.RFC1537) 1676 0 R (cite.RFC1591) 1660 0 R (cite.RFC1706) 1620 0 R (cite.RFC1712) 1716 0 R (cite.RFC1713) 1698 0 R (cite.RFC1794) 1700 0 R (cite.RFC1876) 1622 0 R (cite.RFC1912) 1678 0 R (cite.RFC1982) 1608 0 R (cite.RFC1995) 1566 0 R (cite.RFC1996) 1568 0 R (cite.RFC2010) 1680 0 R (cite.RFC2052) 1624 0 R (cite.RFC2065) 1728 0 R (cite.RFC2136) 1570 0 R (cite.RFC2137) 1730 0 R (cite.RFC2163) 1626 0 R (cite.RFC2168) 1628 0 R (cite.RFC2181) 1572 0 R (cite.RFC2219) 1682 0 R (cite.RFC2230) 1630 0 R (cite.RFC2240) 1702 0 R (cite.RFC2308) 1574 0 R (cite.RFC2317) 1662 0 R (cite.RFC2345) 1704 0 R (cite.RFC2352) 1706 0 R (cite.RFC2535) 1732 0 R (cite.RFC2536) 1632 0 R (cite.RFC2537) 1634 0 R (cite.RFC2538) 1636 0 R (cite.RFC2539) 1638 0 R (cite.RFC2540) 1640 0 R (cite.RFC2671) 1576 0 R (cite.RFC2672) 1578 0 R (cite.RFC2673) 1718 0 R (cite.RFC2782) 1642 0 R (cite.RFC2825) 1686 0 R (cite.RFC2826) 1664 0 R (cite.RFC2845) 1580 0 R (cite.RFC2874) 1720 0 R (cite.RFC2915) 1644 0 R (cite.RFC2929) 1666 0 R (cite.RFC2930) 1582 0 R (cite.RFC2931) 1584 0 R (cite.RFC3007) 1586 0 R (cite.RFC3008) 1734 0 R (cite.RFC3071) 1708 0 R (cite.RFC3090) 1736 0 R (cite.RFC3110) 1646 0 R (cite.RFC3123) 1648 0 R (cite.RFC3225) 1592 0 R (cite.RFC3258) 1710 0 R (cite.RFC3445) 1738 0 R (cite.RFC3490) 1688 0 R (cite.RFC3491) 1690 0 R (cite.RFC3492) 1692 0 R (cite.RFC3596) 1650 0 R (cite.RFC3597) 1652 0 R (cite.RFC3645) 1588 0 R (cite.RFC3655) 1740 0 R (cite.RFC3658) 1742 0 R (cite.RFC3755) 1744 0 R (cite.RFC3757) 1746 0 R (cite.RFC3833) 1594 0 R (cite.RFC3845) 1748 0 R (cite.RFC3901) 1712 0 R (cite.RFC4033) 1596 0 R (cite.RFC4034) 1598 0 R (cite.RFC4035) 1600 0 R (cite.RFC4074) 1610 0 R (cite.RFC974) 1563 0 R (cite.id2500874) 1753 0 R (configuration_file_elements) 1094 0 R (controls_statement_definition_and_usage) 981 0 R (diagnostic_tools) 916 0 R (dynamic_update) 1004 0 R (dynamic_update_policies) 1056 0 R (dynamic_update_security) 1252 0 R (empty) 1324 0 R (historical_dns_information) 1540 0 R (id2466552) 880 0 R (id2466576) 881 0 R (id2467377) 1095 0 R (id2467534) 885 0 R (id2467544) 886 0 R (id2467716) 898 0 R (id2467737) 899 0 R (id2467771) 900 0 R (id2467856) 903 0 R (id2467948) 896 0 R (id2470253) 910 0 R (id2470277) 913 0 R (id2470375) 914 0 R (id2470396) 915 0 R (id2470426) 921 0 R (id2470530) 922 0 R (id2470556) 923 0 R (id2470590) 929 0 R (id2470617) 930 0 R (id2470630) 931 0 R (id2470724) 934 0 R (id2470734) 940 0 R (id2470766) 947 0 R (id2470782) 948 0 R (id2470805) 954 0 R (id2470822) 955 0 R (id2471159) 958 0 R (id2471164) 959 0 R (id2472979) 986 0 R (id2472990) 987 0 R (id2473374) 1019 0 R (id2473393) 1020 0 R (id2473828) 1036 0 R (id2473845) 1037 0 R (id2473883) 1042 0 R (id2473901) 1043 0 R (id2473912) 1044 0 R (id2474023) 1045 0 R (id2474149) 1046 0 R (id2474265) 1052 0 R (id2474279) 1053 0 R (id2474328) 1054 0 R (id2474465) 1062 0 R (id2474534) 1063 0 R (id2474613) 1068 0 R (id2474759) 1073 0 R (id2474889) 1075 0 R (id2474910) 1076 0 R (id2475012) 1083 0 R (id2476222) 1104 0 R (id2476250) 1109 0 R (id2476361) 1110 0 R (id2476444) 1111 0 R (id2476474) 1112 0 R (id2476549) 1119 0 R (id2476965) 1125 0 R (id2477076) 1127 0 R (id2477291) 1129 0 R (id2477652) 1136 0 R (id2477669) 1137 0 R (id2477692) 1138 0 R (id2477716) 1144 0 R (id2477943) 1148 0 R (id2478069) 1149 0 R (id2478121) 1155 0 R (id2478746) 1166 0 R (id2479514) 1172 0 R (id2479576) 1177 0 R (id2479965) 1179 0 R (id2480039) 1184 0 R (id2480103) 1187 0 R (id2480215) 1188 0 R (id2480230) 1189 0 R (id2482243) 1214 0 R (id2484179) 1240 0 R (id2484237) 1242 0 R (id2484737) 1257 0 R (id2485670) 1276 0 R (id2485798) 1278 0 R (id2486357) 1286 0 R (id2486856) 1305 0 R (id2488061) 1334 0 R (id2489252) 1352 0 R (id2489303) 1353 0 R (id2489453) 1355 0 R (id2490790) 1372 0 R (id2490797) 1373 0 R (id2490803) 1374 0 R (id2491293) 1382 0 R (id2491395) 1383 0 R (id2492864) 1431 0 R (id2493121) 1437 0 R (id2493139) 1438 0 R (id2493159) 1441 0 R (id2493396) 1443 0 R (id2494496) 1454 0 R (id2494624) 1456 0 R (id2494645) 1457 0 R (id2495076) 1463 0 R (id2495212) 1465 0 R (id2495230) 1466 0 R (id2495703) 1469 0 R (id2495828) 1475 0 R (id2495843) 1476 0 R (id2495955) 1478 0 R (id2495977) 1479 0 R (id2496038) 1484 0 R (id2496107) 1485 0 R (id2496144) 1486 0 R (id2496205) 1487 0 R (id2496821) 1508 0 R (id2496902) 1509 0 R (id2497030) 1510 0 R (id2497110) 1524 0 R (id2497115) 1525 0 R (id2497264) 1526 0 R (id2497281) 1527 0 R (id2497411) 1539 0 R (id2497582) 1546 0 R (id2497770) 1551 0 R (id2497772) 1557 0 R (id2497781) 1562 0 R (id2497804) 1558 0 R (id2497828) 1560 0 R (id2497864) 1571 0 R (id2497891) 1573 0 R (id2497916) 1565 0 R (id2497941) 1567 0 R (id2497964) 1569 0 R (id2498020) 1575 0 R (id2498046) 1577 0 R (id2498073) 1579 0 R (id2498135) 1581 0 R (id2498165) 1583 0 R (id2498195) 1585 0 R (id2498221) 1587 0 R (id2498296) 1590 0 R (id2498304) 1591 0 R (id2498330) 1593 0 R (id2498366) 1595 0 R (id2498432) 1597 0 R (id2498497) 1599 0 R (id2498562) 1602 0 R (id2498570) 1603 0 R (id2498596) 1605 0 R (id2498664) 1607 0 R (id2498699) 1609 0 R (id2498740) 1616 0 R (id2498745) 1617 0 R (id2498803) 1619 0 R (id2498840) 1627 0 R (id2498875) 1621 0 R (id2498930) 1623 0 R (id2498968) 1625 0 R (id2498994) 1629 0 R (id2499019) 1631 0 R (id2499046) 1633 0 R (id2499073) 1635 0 R (id2499112) 1637 0 R (id2499142) 1639 0 R (id2499172) 1641 0 R (id2499214) 1643 0 R (id2499248) 1645 0 R (id2499274) 1647 0 R (id2499298) 1649 0 R (id2499355) 1651 0 R (id2499380) 1654 0 R (id2499387) 1655 0 R (id2499413) 1657 0 R (id2499435) 1659 0 R (id2499459) 1661 0 R (id2499505) 1663 0 R (id2499528) 1665 0 R (id2499578) 1672 0 R (id2499654) 1673 0 R (id2499677) 1675 0 R (id2499704) 1677 0 R (id2499731) 1679 0 R (id2499767) 1681 0 R (id2499808) 1684 0 R (id2499813) 1685 0 R (id2499845) 1687 0 R (id2499891) 1689 0 R (id2499926) 1691 0 R (id2499953) 1694 0 R (id2499971) 1695 0 R (id2500061) 1697 0 R (id2500087) 1699 0 R (id2500113) 1701 0 R (id2500136) 1703 0 R (id2500182) 1705 0 R (id2500205) 1707 0 R (id2500232) 1709 0 R (id2500258) 1711 0 R (id2500295) 1714 0 R (id2500301) 1715 0 R (id2500359) 1717 0 R (id2500386) 1719 0 R (id2500422) 1726 0 R (id2500434) 1727 0 R (id2500473) 1729 0 R (id2500500) 1731 0 R (id2500530) 1733 0 R (id2500555) 1735 0 R (id2500582) 1737 0 R (id2500686) 1739 0 R (id2500723) 1741 0 R (id2500749) 1743 0 R (id2500776) 1745 0 R (id2500821) 1747 0 R (id2500862) 1750 0 R (id2500872) 1752 0 R (id2500874) 1754 0 R (incremental_zone_transfers) 1016 0 R (internet_drafts) 1749 0 R (ipv6addresses) 1077 0 R (journal) 1005 0 R (lwresd) 1084 0 R (man.dig) 1760 0 R (man.dnssec-keygen) 1809 0 R (man.dnssec-signzone) 1826 0 R (man.host) 1793 0 R (man.named) 1875 0 R (man.named-checkconf) 1846 0 R (man.named-checkzone) 1859 0 R (man.rndc) 1897 0 R (man.rndc-confgen) 1930 0 R (man.rndc.conf) 1910 0 R (notify) 995 0 R (options) 1203 0 R (page.1) 658 0 R (page.10) 920 0 R (page.100) 1779 0 R (page.101) 1783 0 R (page.102) 1788 0 R (page.103) 1800 0 R (page.104) 1805 0 R (page.105) 1817 0 R (page.106) 1822 0 R (page.107) 1833 0 R (page.108) 1838 0 R (page.109) 1843 0 R (page.11) 927 0 R (page.110) 1855 0 R (page.111) 1867 0 R (page.112) 1871 0 R (page.113) 1882 0 R (page.114) 1887 0 R (page.115) 1892 0 R (page.116) 1905 0 R (page.117) 1915 0 R (page.118) 1922 0 R (page.119) 1929 0 R (page.12) 939 0 R (page.120) 1938 0 R (page.13) 944 0 R (page.14) 953 0 R (page.15) 964 0 R (page.16) 972 0 R (page.17) 979 0 R (page.18) 985 0 R (page.19) 993 0 R (page.2) 683 0 R (page.20) 1015 0 R (page.21) 1025 0 R (page.22) 1030 0 R (page.23) 1034 0 R (page.24) 1041 0 R (page.25) 1050 0 R (page.26) 1060 0 R (page.27) 1067 0 R (page.28) 1072 0 R (page.29) 1081 0 R (page.3) 693 0 R (page.30) 1088 0 R (page.31) 1092 0 R (page.32) 1103 0 R (page.33) 1108 0 R (page.34) 1117 0 R (page.35) 1124 0 R (page.36) 1133 0 R (page.37) 1143 0 R (page.38) 1154 0 R (page.39) 1159 0 R (page.4) 748 0 R (page.40) 1165 0 R (page.41) 1171 0 R (page.42) 1176 0 R (page.43) 1183 0 R (page.44) 1194 0 R (page.45) 1198 0 R (page.46) 1202 0 R (page.47) 1207 0 R (page.48) 1213 0 R (page.49) 1219 0 R (page.5) 812 0 R (page.50) 1225 0 R (page.51) 1235 0 R (page.52) 1239 0 R (page.53) 1247 0 R (page.54) 1256 0 R (page.55) 1262 0 R (page.56) 1267 0 R (page.57) 1271 0 R (page.58) 1275 0 R (page.59) 1283 0 R (page.6) 874 0 R (page.60) 1290 0 R (page.61) 1295 0 R (page.62) 1303 0 R (page.63) 1311 0 R (page.64) 1318 0 R (page.65) 1329 0 R (page.66) 1333 0 R (page.67) 1339 0 R (page.68) 1345 0 R (page.69) 1351 0 R (page.7) 878 0 R (page.70) 1359 0 R (page.71) 1363 0 R (page.72) 1367 0 R (page.73) 1371 0 R (page.74) 1380 0 R (page.75) 1394 0 R (page.76) 1406 0 R (page.77) 1428 0 R (page.78) 1436 0 R (page.79) 1448 0 R (page.8) 895 0 R (page.80) 1453 0 R (page.81) 1462 0 R (page.82) 1474 0 R (page.83) 1483 0 R (page.84) 1492 0 R (page.85) 1496 0 R (page.86) 1503 0 R (page.87) 1514 0 R (page.88) 1518 0 R (page.89) 1522 0 R (page.9) 909 0 R (page.90) 1533 0 R (page.91) 1537 0 R (page.92) 1545 0 R (page.93) 1555 0 R (page.94) 1614 0 R (page.95) 1670 0 R (page.96) 1724 0 R (page.97) 1758 0 R (page.98) 1768 0 R (page.99) 1774 0 R (proposed_standards) 1021 0 R (query_address) 1258 0 R (rfcs) 905 0 R (rndc) 1139 0 R (root_delegation_only) 1390 0 R (rrset_ordering) 960 0 R (sample_configuration) 946 0 R (section*.10) 1683 0 R (section*.11) 1693 0 R (section*.12) 1713 0 R (section*.13) 1725 0 R (section*.14) 1751 0 R (section*.15) 1761 0 R (section*.16) 1762 0 R (section*.17) 1763 0 R (section*.18) 1769 0 R (section*.19) 1770 0 R (section*.2) 1550 0 R (section*.20) 1775 0 R (section*.21) 1784 0 R (section*.22) 1789 0 R (section*.23) 1790 0 R (section*.24) 1791 0 R (section*.25) 1792 0 R (section*.26) 1794 0 R (section*.27) 1795 0 R (section*.28) 1796 0 R (section*.29) 1806 0 R (section*.3) 1556 0 R (section*.30) 1807 0 R (section*.31) 1808 0 R (section*.32) 1810 0 R (section*.33) 1811 0 R (section*.34) 1812 0 R (section*.35) 1813 0 R (section*.36) 1818 0 R (section*.37) 1823 0 R (section*.38) 1824 0 R (section*.39) 1825 0 R (section*.4) 1564 0 R (section*.40) 1827 0 R (section*.41) 1828 0 R (section*.42) 1829 0 R (section*.43) 1834 0 R (section*.44) 1839 0 R (section*.45) 1844 0 R (section*.46) 1845 0 R (section*.47) 1847 0 R (section*.48) 1848 0 R (section*.49) 1849 0 R (section*.5) 1589 0 R (section*.50) 1850 0 R (section*.51) 1856 0 R (section*.52) 1857 0 R (section*.53) 1858 0 R (section*.54) 1860 0 R (section*.55) 1861 0 R (section*.56) 1862 0 R (section*.57) 1863 0 R (section*.58) 1872 0 R (section*.59) 1873 0 R (section*.6) 1601 0 R (section*.60) 1874 0 R (section*.61) 1876 0 R (section*.62) 1877 0 R (section*.63) 1878 0 R (section*.64) 1883 0 R (section*.65) 1888 0 R (section*.66) 1893 0 R (section*.67) 1894 0 R (section*.68) 1895 0 R (section*.69) 1896 0 R (section*.7) 1615 0 R (section*.70) 1898 0 R (section*.71) 1899 0 R (section*.72) 1900 0 R (section*.73) 1906 0 R (section*.74) 1907 0 R (section*.75) 1908 0 R (section*.76) 1909 0 R (section*.77) 1911 0 R (section*.78) 1916 0 R (section*.79) 1917 0 R (section*.8) 1653 0 R (section*.80) 1918 0 R (section*.81) 1923 0 R (section*.82) 1924 0 R (section*.83) 1925 0 R (section*.84) 1931 0 R (section*.85) 1932 0 R (section*.86) 1933 0 R (section*.87) 1934 0 R (section*.88) 1939 0 R (section*.89) 1940 0 R (section*.9) 1671 0 R (section*.90) 1941 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) 478 0 R (section.7.1) 534 0 R (section.7.2) 538 0 R (section.7.3) 550 0 R (section.8.1) 558 0 R (section.8.2) 566 0 R (section.8.3) 570 0 R (section.A.1) 578 0 R (section.A.2) 586 0 R (section.A.3) 594 0 R (section.B.1) 614 0 R (section.B.10) 650 0 R (section.B.2) 618 0 R (section.B.3) 622 0 R (section.B.4) 626 0 R (section.B.5) 630 0 R (section.B.6) 634 0 R (section.B.7) 638 0 R (section.B.8) 642 0 R (section.B.9) 646 0 R (server_resource_limits) 1284 0 R (server_statement_definition_and_usage) 1231 0 R (server_statement_grammar) 1340 0 R (statsfile) 1209 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) 330 0 R (subsection.6.2.12) 334 0 R (subsection.6.2.13) 338 0 R (subsection.6.2.14) 342 0 R (subsection.6.2.15) 346 0 R (subsection.6.2.16) 350 0 R (subsection.6.2.17) 430 0 R (subsection.6.2.18) 434 0 R (subsection.6.2.19) 438 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 442 0 R (subsection.6.2.21) 446 0 R (subsection.6.2.22) 450 0 R (subsection.6.2.23) 454 0 R (subsection.6.2.24) 458 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) 482 0 R (subsection.6.3.2) 494 0 R (subsection.6.3.3) 498 0 R (subsection.6.3.4) 502 0 R (subsection.6.3.5) 506 0 R (subsection.6.3.6) 522 0 R (subsection.6.3.7) 526 0 R (subsection.7.2.1) 542 0 R (subsection.7.2.2) 546 0 R (subsection.8.1.1) 562 0 R (subsection.A.1.1) 582 0 R (subsection.A.2.1) 590 0 R (subsection.A.3.1) 598 0 R (subsection.A.3.2) 602 0 R (subsection.A.3.3) 606 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.10.3) 326 0 R (subsubsection.6.2.16.1) 354 0 R (subsubsection.6.2.16.10) 390 0 R (subsubsection.6.2.16.11) 394 0 R (subsubsection.6.2.16.12) 398 0 R (subsubsection.6.2.16.13) 402 0 R (subsubsection.6.2.16.14) 406 0 R (subsubsection.6.2.16.15) 410 0 R (subsubsection.6.2.16.16) 414 0 R (subsubsection.6.2.16.17) 418 0 R (subsubsection.6.2.16.18) 422 0 R (subsubsection.6.2.16.19) 426 0 R (subsubsection.6.2.16.2) 358 0 R (subsubsection.6.2.16.3) 362 0 R (subsubsection.6.2.16.4) 366 0 R (subsubsection.6.2.16.5) 370 0 R (subsubsection.6.2.16.6) 374 0 R (subsubsection.6.2.16.7) 378 0 R (subsubsection.6.2.16.8) 382 0 R (subsubsection.6.2.16.9) 386 0 R (subsubsection.6.2.24.1) 462 0 R (subsubsection.6.2.24.2) 466 0 R (subsubsection.6.2.24.3) 470 0 R (subsubsection.6.2.24.4) 474 0 R (subsubsection.6.3.1.1) 486 0 R (subsubsection.6.3.1.2) 490 0 R (subsubsection.6.3.5.1) 510 0 R (subsubsection.6.3.5.2) 514 0 R (subsubsection.6.3.5.3) 518 0 R (table.1.1) 887 0 R (table.1.2) 897 0 R (table.3.1) 956 0 R (table.3.2) 988 0 R (table.6.1) 1096 0 R (table.6.10) 1432 0 R (table.6.11) 1442 0 R (table.6.12) 1444 0 R (table.6.13) 1455 0 R (table.6.14) 1458 0 R (table.6.15) 1464 0 R (table.6.16) 1467 0 R (table.6.17) 1470 0 R (table.6.18) 1477 0 R (table.6.19) 1488 0 R (table.6.2) 1120 0 R (table.6.3) 1128 0 R (table.6.4) 1167 0 R (table.6.5) 1178 0 R (table.6.6) 1215 0 R (table.6.7) 1306 0 R (table.6.8) 1335 0 R (table.6.9) 1375 0 R (the_category_phrase) 1161 0 R (the_sortlist_statement) 1296 0 R (topology) 1291 0 R (tsig) 1035 0 R (tuning) 1307 0 R (types_of_resource_records_and_when_to_use_them) 904 0 R (view_statement_grammar) 1325 0 R (zone_statement_grammar) 1243 0 R (zone_transfers) 1011 0 R (zonefile_format) 1314 0 R]
 /Limits [(Access_Control_Lists) (zonefile_format)]
 >> endobj
-1953 0 obj <<
-/Kids [1952 0 R]
+1965 0 obj <<
+/Kids [1964 0 R]
 >> endobj
-1954 0 obj <<
-/Dests 1953 0 R
+1966 0 obj <<
+/Dests 1965 0 R
 >> endobj
-1955 0 obj <<
+1967 0 obj <<
 /Type /Catalog
-/Pages 1950 0 R
-/Outlines 1951 0 R
-/Names 1954 0 R
+/Pages 1962 0 R
+/Outlines 1963 0 R
+/Names 1966 0 R
 /PageMode /UseOutlines 
-/OpenAction 649 0 R
+/OpenAction 653 0 R
 >> endobj
-1956 0 obj <<
+1968 0 obj <<
 /Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords()
-/CreationDate (D:20081024041421Z)
+/CreationDate (D:20100121064739Z)
 /PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)
 >> endobj
 xref
-0 1957
+0 1969
 0000000001 65535 f 
 0000000002 00000 f 
 0000000003 00000 f 
 0000000004 00000 f 
 0000000000 00000 f 
 0000000009 00000 n 
-0000066894 00000 n 
-0000671475 00000 n 
+0000067235 00000 n 
+0000679170 00000 n 
 0000000054 00000 n 
 0000000086 00000 n 
-0000067018 00000 n 
-0000671403 00000 n 
+0000067359 00000 n 
+0000679098 00000 n 
 0000000133 00000 n 
 0000000173 00000 n 
-0000067143 00000 n 
-0000671317 00000 n 
+0000067484 00000 n 
+0000679012 00000 n 
 0000000221 00000 n 
 0000000273 00000 n 
-0000067268 00000 n 
-0000671231 00000 n 
+0000067609 00000 n 
+0000678926 00000 n 
 0000000321 00000 n 
 0000000377 00000 n 
-0000071531 00000 n 
-0000671121 00000 n 
+0000071872 00000 n 
+0000678816 00000 n 
 0000000425 00000 n 
 0000000478 00000 n 
-0000071656 00000 n 
-0000671047 00000 n 
+0000071997 00000 n 
+0000678742 00000 n 
 0000000531 00000 n 
 0000000572 00000 n 
-0000071781 00000 n 
-0000670960 00000 n 
+0000072122 00000 n 
+0000678655 00000 n 
 0000000625 00000 n 
 0000000674 00000 n 
-0000071906 00000 n 
-0000670873 00000 n 
+0000072247 00000 n 
+0000678568 00000 n 
 0000000727 00000 n 
 0000000757 00000 n 
-0000076184 00000 n 
-0000670749 00000 n 
+0000076525 00000 n 
+0000678444 00000 n 
 0000000810 00000 n 
 0000000861 00000 n 
-0000076309 00000 n 
-0000670675 00000 n 
+0000076650 00000 n 
+0000678370 00000 n 
 0000000919 00000 n 
 0000000964 00000 n 
-0000076434 00000 n 
-0000670588 00000 n 
+0000076775 00000 n 
+0000678283 00000 n 
 0000001022 00000 n 
 0000001062 00000 n 
-0000076559 00000 n 
-0000670514 00000 n 
+0000076900 00000 n 
+0000678209 00000 n 
 0000001120 00000 n 
 0000001162 00000 n 
-0000079531 00000 n 
-0000670390 00000 n 
+0000079872 00000 n 
+0000678085 00000 n 
 0000001215 00000 n 
 0000001260 00000 n 
-0000079656 00000 n 
-0000670329 00000 n 
+0000079997 00000 n 
+0000678024 00000 n 
 0000001318 00000 n 
 0000001355 00000 n 
-0000079781 00000 n 
-0000670255 00000 n 
+0000080122 00000 n 
+0000677950 00000 n 
 0000001408 00000 n 
 0000001463 00000 n 
-0000082709 00000 n 
-0000670130 00000 n 
+0000083050 00000 n 
+0000677825 00000 n 
 0000001509 00000 n 
 0000001556 00000 n 
-0000082834 00000 n 
-0000670056 00000 n 
+0000083175 00000 n 
+0000677751 00000 n 
 0000001604 00000 n 
 0000001648 00000 n 
-0000082959 00000 n 
-0000669969 00000 n 
+0000083300 00000 n 
+0000677664 00000 n 
 0000001696 00000 n 
 0000001735 00000 n 
-0000083084 00000 n 
-0000669882 00000 n 
+0000083425 00000 n 
+0000677577 00000 n 
 0000001783 00000 n 
 0000001825 00000 n 
-0000083208 00000 n 
-0000669795 00000 n 
+0000083549 00000 n 
+0000677490 00000 n 
 0000001873 00000 n 
 0000001936 00000 n 
-0000084291 00000 n 
-0000669721 00000 n 
+0000084632 00000 n 
+0000677416 00000 n 
 0000001984 00000 n 
 0000002034 00000 n 
-0000086001 00000 n 
-0000669593 00000 n 
+0000086335 00000 n 
+0000677288 00000 n 
 0000002080 00000 n 
 0000002126 00000 n 
-0000086125 00000 n 
-0000669480 00000 n 
+0000086459 00000 n 
+0000677175 00000 n 
 0000002174 00000 n 
 0000002218 00000 n 
-0000086250 00000 n 
-0000669404 00000 n 
+0000086584 00000 n 
+0000677099 00000 n 
 0000002271 00000 n 
 0000002323 00000 n 
-0000086375 00000 n 
-0000669327 00000 n 
+0000086709 00000 n 
+0000677022 00000 n 
 0000002377 00000 n 
 0000002436 00000 n 
-0000088903 00000 n 
-0000669236 00000 n 
+0000089237 00000 n 
+0000676931 00000 n 
 0000002485 00000 n 
 0000002523 00000 n 
-0000089155 00000 n 
-0000669119 00000 n 
+0000089489 00000 n 
+0000676814 00000 n 
 0000002572 00000 n 
 0000002618 00000 n 
-0000089281 00000 n 
-0000669001 00000 n 
+0000089615 00000 n 
+0000676696 00000 n 
 0000002672 00000 n 
 0000002739 00000 n 
-0000092488 00000 n 
-0000668922 00000 n 
+0000092837 00000 n 
+0000676617 00000 n 
 0000002798 00000 n 
 0000002842 00000 n 
-0000092614 00000 n 
-0000668843 00000 n 
+0000092963 00000 n 
+0000676538 00000 n 
 0000002901 00000 n 
 0000002949 00000 n 
-0000102943 00000 n 
-0000668764 00000 n 
+0000103401 00000 n 
+0000676459 00000 n 
 0000003003 00000 n 
 0000003036 00000 n 
-0000107874 00000 n 
-0000668632 00000 n 
+0000108371 00000 n 
+0000676327 00000 n 
 0000003083 00000 n 
 0000003126 00000 n 
-0000108000 00000 n 
-0000668553 00000 n 
+0000108497 00000 n 
+0000676248 00000 n 
 0000003175 00000 n 
 0000003205 00000 n 
-0000108126 00000 n 
-0000668421 00000 n 
+0000108623 00000 n 
+0000676116 00000 n 
 0000003254 00000 n 
 0000003292 00000 n 
-0000108252 00000 n 
-0000668356 00000 n 
+0000108750 00000 n 
+0000676051 00000 n 
 0000003346 00000 n 
 0000003388 00000 n 
-0000112543 00000 n 
-0000668263 00000 n 
+0000113043 00000 n 
+0000675958 00000 n 
 0000003437 00000 n 
 0000003496 00000 n 
-0000112670 00000 n 
-0000668131 00000 n 
+0000113170 00000 n 
+0000675826 00000 n 
 0000003545 00000 n 
 0000003578 00000 n 
-0000112799 00000 n 
-0000668066 00000 n 
+0000113299 00000 n 
+0000675761 00000 n 
 0000003632 00000 n 
 0000003681 00000 n 
-0000120171 00000 n 
-0000667934 00000 n 
+0000120671 00000 n 
+0000675629 00000 n 
 0000003730 00000 n 
 0000003758 00000 n 
-0000120298 00000 n 
-0000667816 00000 n 
+0000120798 00000 n 
+0000675511 00000 n 
 0000003812 00000 n 
 0000003881 00000 n 
-0000120427 00000 n 
-0000667737 00000 n 
+0000120927 00000 n 
+0000675432 00000 n 
 0000003940 00000 n 
 0000003988 00000 n 
-0000123302 00000 n 
-0000667658 00000 n 
+0000123823 00000 n 
+0000675353 00000 n 
 0000004047 00000 n 
 0000004092 00000 n 
-0000123431 00000 n 
-0000667565 00000 n 
+0000123952 00000 n 
+0000675260 00000 n 
 0000004146 00000 n 
 0000004214 00000 n 
-0000123560 00000 n 
-0000667472 00000 n 
+0000124081 00000 n 
+0000675167 00000 n 
 0000004268 00000 n 
 0000004338 00000 n 
-0000123689 00000 n 
-0000667379 00000 n 
+0000124210 00000 n 
+0000675074 00000 n 
 0000004392 00000 n 
 0000004455 00000 n 
-0000123817 00000 n 
-0000667286 00000 n 
+0000124338 00000 n 
+0000674981 00000 n 
 0000004509 00000 n 
 0000004564 00000 n 
-0000127463 00000 n 
-0000667207 00000 n 
+0000128005 00000 n 
+0000674902 00000 n 
 0000004618 00000 n 
 0000004650 00000 n 
-0000127592 00000 n 
-0000667114 00000 n 
+0000128134 00000 n 
+0000674809 00000 n 
 0000004699 00000 n 
 0000004727 00000 n 
-0000127721 00000 n 
-0000667021 00000 n 
+0000128263 00000 n 
+0000674716 00000 n 
 0000004776 00000 n 
 0000004808 00000 n 
-0000131327 00000 n 
-0000666889 00000 n 
+0000131869 00000 n 
+0000674584 00000 n 
 0000004857 00000 n 
 0000004887 00000 n 
-0000131456 00000 n 
-0000666810 00000 n 
+0000131998 00000 n 
+0000674505 00000 n 
 0000004941 00000 n 
 0000004982 00000 n 
-0000131584 00000 n 
-0000666717 00000 n 
+0000132126 00000 n 
+0000674412 00000 n 
 0000005036 00000 n 
 0000005078 00000 n 
-0000135026 00000 n 
-0000666638 00000 n 
+0000135588 00000 n 
+0000674333 00000 n 
 0000005132 00000 n 
 0000005177 00000 n 
-0000138100 00000 n 
-0000666520 00000 n 
+0000138662 00000 n 
+0000674215 00000 n 
 0000005226 00000 n 
 0000005272 00000 n 
-0000138229 00000 n 
-0000666441 00000 n 
+0000138791 00000 n 
+0000674136 00000 n 
 0000005326 00000 n 
 0000005386 00000 n 
-0000138357 00000 n 
-0000666362 00000 n 
+0000138919 00000 n 
+0000674057 00000 n 
 0000005440 00000 n 
 0000005509 00000 n 
-0000140837 00000 n 
-0000666229 00000 n 
+0000141400 00000 n 
+0000673924 00000 n 
 0000005556 00000 n 
 0000005609 00000 n 
-0000140966 00000 n 
-0000666150 00000 n 
+0000141529 00000 n 
+0000673845 00000 n 
 0000005658 00000 n 
 0000005714 00000 n 
-0000141095 00000 n 
-0000666071 00000 n 
+0000141658 00000 n 
+0000673766 00000 n 
 0000005763 00000 n 
 0000005812 00000 n 
-0000145279 00000 n 
-0000665938 00000 n 
+0000145842 00000 n 
+0000673633 00000 n 
 0000005859 00000 n 
 0000005911 00000 n 
-0000145408 00000 n 
-0000665820 00000 n 
+0000145971 00000 n 
+0000673515 00000 n 
 0000005960 00000 n 
 0000006011 00000 n 
-0000150015 00000 n 
-0000665702 00000 n 
+0000150578 00000 n 
+0000673397 00000 n 
 0000006065 00000 n 
 0000006110 00000 n 
-0000150142 00000 n 
-0000665623 00000 n 
+0000150705 00000 n 
+0000673318 00000 n 
 0000006169 00000 n 
 0000006203 00000 n 
-0000153580 00000 n 
-0000665544 00000 n 
+0000154163 00000 n 
+0000673239 00000 n 
 0000006262 00000 n 
 0000006310 00000 n 
-0000153709 00000 n 
-0000665426 00000 n 
+0000154292 00000 n 
+0000673121 00000 n 
 0000006364 00000 n 
 0000006404 00000 n 
-0000153838 00000 n 
-0000665347 00000 n 
+0000154421 00000 n 
+0000673042 00000 n 
 0000006463 00000 n 
 0000006497 00000 n 
-0000153967 00000 n 
-0000665268 00000 n 
+0000154550 00000 n 
+0000672963 00000 n 
 0000006556 00000 n 
 0000006604 00000 n 
-0000157817 00000 n 
-0000665135 00000 n 
+0000158541 00000 n 
+0000672830 00000 n 
 0000006653 00000 n 
 0000006703 00000 n 
-0000160916 00000 n 
-0000665056 00000 n 
+0000161811 00000 n 
+0000672751 00000 n 
 0000006757 00000 n 
 0000006804 00000 n 
-0000161044 00000 n 
-0000664963 00000 n 
+0000161940 00000 n 
+0000672658 00000 n 
 0000006858 00000 n 
 0000006918 00000 n 
-0000161303 00000 n 
-0000664870 00000 n 
+0000162198 00000 n 
+0000672565 00000 n 
 0000006972 00000 n 
 0000007024 00000 n 
-0000161432 00000 n 
-0000664777 00000 n 
+0000162327 00000 n 
+0000672472 00000 n 
 0000007078 00000 n 
 0000007143 00000 n 
-0000166331 00000 n 
-0000664684 00000 n 
+0000166928 00000 n 
+0000672379 00000 n 
 0000007197 00000 n 
 0000007248 00000 n 
-0000166460 00000 n 
-0000664591 00000 n 
+0000167054 00000 n 
+0000672286 00000 n 
 0000007302 00000 n 
 0000007366 00000 n 
-0000166589 00000 n 
-0000664498 00000 n 
+0000167183 00000 n 
+0000672193 00000 n 
 0000007420 00000 n 
 0000007467 00000 n 
-0000170354 00000 n 
-0000664405 00000 n 
+0000170945 00000 n 
+0000672100 00000 n 
 0000007521 00000 n 
 0000007581 00000 n 
-0000170483 00000 n 
-0000664312 00000 n 
+0000171074 00000 n 
+0000672007 00000 n 
 0000007635 00000 n 
 0000007686 00000 n 
-0000170612 00000 n 
-0000664180 00000 n 
+0000171203 00000 n 
+0000671875 00000 n 
 0000007741 00000 n 
 0000007806 00000 n 
-0000175144 00000 n 
-0000664101 00000 n 
+0000175735 00000 n 
+0000671796 00000 n 
 0000007866 00000 n 
 0000007913 00000 n 
-0000181571 00000 n 
-0000664022 00000 n 
+0000182174 00000 n 
+0000671703 00000 n 
 0000007973 00000 n 
 0000008021 00000 n 
-0000185205 00000 n 
-0000663929 00000 n 
-0000008076 00000 n 
-0000008126 00000 n 
-0000185334 00000 n 
-0000663836 00000 n 
-0000008181 00000 n 
-0000008244 00000 n 
-0000187219 00000 n 
-0000663743 00000 n 
-0000008299 00000 n 
-0000008351 00000 n 
-0000187348 00000 n 
-0000663650 00000 n 
-0000008406 00000 n 
-0000008471 00000 n 
-0000187477 00000 n 
-0000663557 00000 n 
-0000008526 00000 n 
-0000008578 00000 n 
-0000190809 00000 n 
-0000663424 00000 n 
-0000008633 00000 n 
-0000008698 00000 n 
-0000198905 00000 n 
-0000663345 00000 n 
-0000008758 00000 n 
-0000008802 00000 n 
-0000220055 00000 n 
-0000663252 00000 n 
-0000008862 00000 n 
-0000008901 00000 n 
-0000220184 00000 n 
-0000663159 00000 n 
-0000008961 00000 n 
-0000009008 00000 n 
-0000220313 00000 n 
-0000663066 00000 n 
-0000009068 00000 n 
-0000009111 00000 n 
-0000224587 00000 n 
-0000662973 00000 n 
-0000009171 00000 n 
-0000009210 00000 n 
-0000228114 00000 n 
-0000662880 00000 n 
-0000009270 00000 n 
-0000009312 00000 n 
-0000231064 00000 n 
-0000662787 00000 n 
-0000009372 00000 n 
-0000009415 00000 n 
-0000238656 00000 n 
-0000662694 00000 n 
-0000009475 00000 n 
-0000009518 00000 n 
-0000242961 00000 n 
-0000662601 00000 n 
-0000009578 00000 n 
-0000009639 00000 n 
-0000243090 00000 n 
-0000662508 00000 n 
-0000009700 00000 n 
-0000009752 00000 n 
-0000246876 00000 n 
-0000662415 00000 n 
-0000009813 00000 n 
+0000185653 00000 n 
+0000671624 00000 n 
+0000008081 00000 n 
+0000008135 00000 n 
+0000189114 00000 n 
+0000671531 00000 n 
+0000008190 00000 n 
+0000008240 00000 n 
+0000191939 00000 n 
+0000671438 00000 n 
+0000008295 00000 n 
+0000008358 00000 n 
+0000192068 00000 n 
+0000671345 00000 n 
+0000008413 00000 n 
+0000008465 00000 n 
+0000192197 00000 n 
+0000671252 00000 n 
+0000008520 00000 n 
+0000008585 00000 n 
+0000192326 00000 n 
+0000671159 00000 n 
+0000008640 00000 n 
+0000008692 00000 n 
+0000198793 00000 n 
+0000671026 00000 n 
+0000008747 00000 n 
+0000008812 00000 n 
+0000206888 00000 n 
+0000670947 00000 n 
+0000008872 00000 n 
+0000008916 00000 n 
+0000224498 00000 n 
+0000670854 00000 n 
+0000008976 00000 n 
+0000009015 00000 n 
+0000224627 00000 n 
+0000670761 00000 n 
+0000009075 00000 n 
+0000009122 00000 n 
+0000229140 00000 n 
+0000670668 00000 n 
+0000009182 00000 n 
+0000009225 00000 n 
+0000232242 00000 n 
+0000670575 00000 n 
+0000009285 00000 n 
+0000009324 00000 n 
+0000232371 00000 n 
+0000670482 00000 n 
+0000009384 00000 n 
+0000009426 00000 n 
+0000239620 00000 n 
+0000670389 00000 n 
+0000009486 00000 n 
+0000009529 00000 n 
+0000247388 00000 n 
+0000670296 00000 n 
+0000009589 00000 n 
+0000009632 00000 n 
+0000247517 00000 n 
+0000670203 00000 n 
+0000009692 00000 n 
+0000009753 00000 n 
+0000251446 00000 n 
+0000670110 00000 n 
+0000009814 00000 n 
 0000009866 00000 n 
-0000247005 00000 n 
-0000662322 00000 n 
+0000251575 00000 n 
+0000670017 00000 n 
 0000009927 00000 n 
-0000009965 00000 n 
-0000251036 00000 n 
-0000662229 00000 n 
-0000010026 00000 n 
-0000010078 00000 n 
-0000254054 00000 n 
-0000662136 00000 n 
-0000010139 00000 n 
-0000010183 00000 n 
-0000258009 00000 n 
-0000662043 00000 n 
-0000010244 00000 n 
-0000010280 00000 n 
-0000262835 00000 n 
-0000661950 00000 n 
-0000010341 00000 n 
-0000010404 00000 n 
-0000266161 00000 n 
-0000661857 00000 n 
-0000010465 00000 n 
-0000010515 00000 n 
-0000269322 00000 n 
-0000661764 00000 n 
-0000010576 00000 n 
-0000010625 00000 n 
-0000273049 00000 n 
-0000661685 00000 n 
-0000010686 00000 n 
-0000010742 00000 n 
-0000273177 00000 n 
-0000661592 00000 n 
-0000010797 00000 n 
-0000010848 00000 n 
-0000277701 00000 n 
-0000661499 00000 n 
-0000010903 00000 n 
-0000010967 00000 n 
-0000281213 00000 n 
-0000661406 00000 n 
-0000011022 00000 n 
-0000011079 00000 n 
-0000281342 00000 n 
-0000661313 00000 n 
-0000011134 00000 n 
-0000011204 00000 n 
-0000281471 00000 n 
-0000661220 00000 n 
-0000011259 00000 n 
-0000011308 00000 n 
-0000281600 00000 n 
-0000661127 00000 n 
-0000011363 00000 n 
-0000011425 00000 n 
-0000286259 00000 n 
-0000661034 00000 n 
-0000011480 00000 n 
-0000011529 00000 n 
-0000290062 00000 n 
-0000660916 00000 n 
-0000011584 00000 n 
-0000011646 00000 n 
-0000290191 00000 n 
-0000660837 00000 n 
-0000011706 00000 n 
-0000011745 00000 n 
-0000294250 00000 n 
-0000660744 00000 n 
-0000011805 00000 n 
-0000011839 00000 n 
-0000299864 00000 n 
-0000660651 00000 n 
-0000011899 00000 n 
-0000011940 00000 n 
-0000310269 00000 n 
-0000660572 00000 n 
-0000012000 00000 n 
-0000012052 00000 n 
-0000314360 00000 n 
-0000660454 00000 n 
-0000012101 00000 n 
-0000012134 00000 n 
-0000314488 00000 n 
-0000660336 00000 n 
-0000012188 00000 n 
-0000012260 00000 n 
-0000314616 00000 n 
-0000660257 00000 n 
-0000012319 00000 n 
-0000012363 00000 n 
-0000325410 00000 n 
-0000660178 00000 n 
-0000012422 00000 n 
-0000012475 00000 n 
-0000325798 00000 n 
-0000660085 00000 n 
-0000012529 00000 n 
-0000012579 00000 n 
-0000329220 00000 n 
-0000659992 00000 n 
-0000012633 00000 n 
-0000012671 00000 n 
-0000329479 00000 n 
-0000659899 00000 n 
-0000012725 00000 n 
-0000012774 00000 n 
-0000332384 00000 n 
-0000659767 00000 n 
-0000012828 00000 n 
-0000012880 00000 n 
-0000332512 00000 n 
-0000659688 00000 n 
-0000012939 00000 n 
-0000012991 00000 n 
-0000332641 00000 n 
-0000659595 00000 n 
-0000013050 00000 n 
-0000013103 00000 n 
-0000332769 00000 n 
-0000659516 00000 n 
-0000013162 00000 n 
-0000013211 00000 n 
-0000332898 00000 n 
-0000659423 00000 n 
-0000013265 00000 n 
-0000013345 00000 n 
-0000336811 00000 n 
-0000659344 00000 n 
-0000013399 00000 n 
-0000013448 00000 n 
-0000340557 00000 n 
-0000659211 00000 n 
-0000013495 00000 n 
-0000013547 00000 n 
-0000340686 00000 n 
-0000659132 00000 n 
-0000013596 00000 n 
-0000013640 00000 n 
-0000344779 00000 n 
-0000659000 00000 n 
-0000013689 00000 n 
-0000013730 00000 n 
-0000344908 00000 n 
-0000658921 00000 n 
-0000013784 00000 n 
-0000013832 00000 n 
-0000345037 00000 n 
-0000658842 00000 n 
-0000013886 00000 n 
-0000013937 00000 n 
-0000345166 00000 n 
-0000658763 00000 n 
-0000013986 00000 n 
-0000014033 00000 n 
-0000349429 00000 n 
-0000658630 00000 n 
-0000014080 00000 n 
-0000014117 00000 n 
-0000349558 00000 n 
-0000658512 00000 n 
-0000014166 00000 n 
-0000014205 00000 n 
-0000349687 00000 n 
-0000658447 00000 n 
-0000014259 00000 n 
-0000014337 00000 n 
-0000349816 00000 n 
-0000658354 00000 n 
-0000014386 00000 n 
-0000014453 00000 n 
-0000349945 00000 n 
-0000658275 00000 n 
-0000014502 00000 n 
-0000014547 00000 n 
-0000353384 00000 n 
-0000658142 00000 n 
-0000014595 00000 n 
-0000014627 00000 n 
-0000353513 00000 n 
-0000658024 00000 n 
-0000014676 00000 n 
-0000014715 00000 n 
-0000353642 00000 n 
-0000657959 00000 n 
-0000014769 00000 n 
-0000014830 00000 n 
-0000357407 00000 n 
-0000657827 00000 n 
-0000014879 00000 n 
-0000014936 00000 n 
-0000357536 00000 n 
-0000657762 00000 n 
-0000014990 00000 n 
-0000015039 00000 n 
-0000357665 00000 n 
-0000657644 00000 n 
-0000015088 00000 n 
-0000015150 00000 n 
-0000357794 00000 n 
-0000657565 00000 n 
-0000015204 00000 n 
-0000015259 00000 n 
-0000381817 00000 n 
-0000657472 00000 n 
-0000015313 00000 n 
-0000015354 00000 n 
-0000381946 00000 n 
-0000657393 00000 n 
-0000015408 00000 n 
-0000015460 00000 n 
-0000384676 00000 n 
-0000657273 00000 n 
-0000015508 00000 n 
-0000015542 00000 n 
-0000384805 00000 n 
-0000657194 00000 n 
-0000015591 00000 n 
-0000015618 00000 n 
-0000402812 00000 n 
-0000657101 00000 n 
-0000015667 00000 n 
-0000015695 00000 n 
-0000410349 00000 n 
-0000657008 00000 n 
-0000015744 00000 n 
+0000009980 00000 n 
+0000254642 00000 n 
+0000669924 00000 n 
+0000010041 00000 n 
+0000010079 00000 n 
+0000258713 00000 n 
+0000669831 00000 n 
+0000010140 00000 n 
+0000010192 00000 n 
+0000261945 00000 n 
+0000669738 00000 n 
+0000010253 00000 n 
+0000010297 00000 n 
+0000262202 00000 n 
+0000669645 00000 n 
+0000010358 00000 n 
+0000010394 00000 n 
+0000271167 00000 n 
+0000669552 00000 n 
+0000010455 00000 n 
+0000010518 00000 n 
+0000271296 00000 n 
+0000669459 00000 n 
+0000010579 00000 n 
+0000010629 00000 n 
+0000277445 00000 n 
+0000669366 00000 n 
+0000010690 00000 n 
+0000010739 00000 n 
+0000277703 00000 n 
+0000669287 00000 n 
+0000010800 00000 n 
+0000010856 00000 n 
+0000281169 00000 n 
+0000669194 00000 n 
+0000010911 00000 n 
+0000010962 00000 n 
+0000281298 00000 n 
+0000669101 00000 n 
+0000011017 00000 n 
+0000011081 00000 n 
+0000289908 00000 n 
+0000669008 00000 n 
+0000011136 00000 n 
+0000011193 00000 n 
+0000290037 00000 n 
+0000668915 00000 n 
+0000011248 00000 n 
+0000011318 00000 n 
+0000290165 00000 n 
+0000668822 00000 n 
+0000011373 00000 n 
+0000011422 00000 n 
+0000290294 00000 n 
+0000668729 00000 n 
+0000011477 00000 n 
+0000011539 00000 n 
+0000292540 00000 n 
+0000668636 00000 n 
+0000011594 00000 n 
+0000011643 00000 n 
+0000298725 00000 n 
+0000668518 00000 n 
+0000011698 00000 n 
+0000011760 00000 n 
+0000298853 00000 n 
+0000668439 00000 n 
+0000011820 00000 n 
+0000011859 00000 n 
+0000303880 00000 n 
+0000668346 00000 n 
+0000011919 00000 n 
+0000011953 00000 n 
+0000304009 00000 n 
+0000668253 00000 n 
+0000012013 00000 n 
+0000012054 00000 n 
+0000319667 00000 n 
+0000668174 00000 n 
+0000012114 00000 n 
+0000012166 00000 n 
+0000323570 00000 n 
+0000668056 00000 n 
+0000012215 00000 n 
+0000012248 00000 n 
+0000323699 00000 n 
+0000667938 00000 n 
+0000012302 00000 n 
+0000012374 00000 n 
+0000323826 00000 n 
+0000667859 00000 n 
+0000012433 00000 n 
+0000012477 00000 n 
+0000331369 00000 n 
+0000667780 00000 n 
+0000012536 00000 n 
+0000012589 00000 n 
+0000335141 00000 n 
+0000667687 00000 n 
+0000012643 00000 n 
+0000012693 00000 n 
+0000335399 00000 n 
+0000667594 00000 n 
+0000012747 00000 n 
+0000012785 00000 n 
+0000338645 00000 n 
+0000667501 00000 n 
+0000012839 00000 n 
+0000012888 00000 n 
+0000338903 00000 n 
+0000667369 00000 n 
+0000012942 00000 n 
+0000012994 00000 n 
+0000339032 00000 n 
+0000667290 00000 n 
+0000013053 00000 n 
+0000013105 00000 n 
+0000341860 00000 n 
+0000667197 00000 n 
+0000013164 00000 n 
+0000013217 00000 n 
+0000341989 00000 n 
+0000667118 00000 n 
+0000013276 00000 n 
+0000013325 00000 n 
+0000342118 00000 n 
+0000667025 00000 n 
+0000013379 00000 n 
+0000013459 00000 n 
+0000346156 00000 n 
+0000666946 00000 n 
+0000013513 00000 n 
+0000013562 00000 n 
+0000348053 00000 n 
+0000666813 00000 n 
+0000013609 00000 n 
+0000013661 00000 n 
+0000348182 00000 n 
+0000666734 00000 n 
+0000013710 00000 n 
+0000013754 00000 n 
+0000352288 00000 n 
+0000666602 00000 n 
+0000013803 00000 n 
+0000013844 00000 n 
+0000352417 00000 n 
+0000666523 00000 n 
+0000013898 00000 n 
+0000013946 00000 n 
+0000352546 00000 n 
+0000666444 00000 n 
+0000014000 00000 n 
+0000014051 00000 n 
+0000352675 00000 n 
+0000666365 00000 n 
+0000014100 00000 n 
+0000014147 00000 n 
+0000356940 00000 n 
+0000666232 00000 n 
+0000014194 00000 n 
+0000014231 00000 n 
+0000357069 00000 n 
+0000666114 00000 n 
+0000014280 00000 n 
+0000014319 00000 n 
+0000357198 00000 n 
+0000666049 00000 n 
+0000014373 00000 n 
+0000014451 00000 n 
+0000357327 00000 n 
+0000665956 00000 n 
+0000014500 00000 n 
+0000014567 00000 n 
+0000357456 00000 n 
+0000665877 00000 n 
+0000014616 00000 n 
+0000014661 00000 n 
+0000360895 00000 n 
+0000665744 00000 n 
+0000014709 00000 n 
+0000014741 00000 n 
+0000361024 00000 n 
+0000665626 00000 n 
+0000014790 00000 n 
+0000014829 00000 n 
+0000361153 00000 n 
+0000665561 00000 n 
+0000014883 00000 n 
+0000014944 00000 n 
+0000364834 00000 n 
+0000665429 00000 n 
+0000014993 00000 n 
+0000015050 00000 n 
+0000364963 00000 n 
+0000665364 00000 n 
+0000015104 00000 n 
+0000015153 00000 n 
+0000365092 00000 n 
+0000665246 00000 n 
+0000015202 00000 n 
+0000015264 00000 n 
+0000365221 00000 n 
+0000665167 00000 n 
+0000015318 00000 n 
+0000015373 00000 n 
+0000389244 00000 n 
+0000665074 00000 n 
+0000015427 00000 n 
+0000015468 00000 n 
+0000389373 00000 n 
+0000664995 00000 n 
+0000015522 00000 n 
+0000015574 00000 n 
+0000392103 00000 n 
+0000664875 00000 n 
+0000015622 00000 n 
+0000015656 00000 n 
+0000392232 00000 n 
+0000664796 00000 n 
+0000015705 00000 n 
+0000015732 00000 n 
+0000410371 00000 n 
+0000664703 00000 n 
 0000015781 00000 n 
-0000416667 00000 n 
-0000656915 00000 n 
-0000015830 00000 n 
-0000015869 00000 n 
-0000426187 00000 n 
-0000656822 00000 n 
-0000015918 00000 n 
-0000015957 00000 n 
-0000429074 00000 n 
-0000656729 00000 n 
-0000016006 00000 n 
-0000016045 00000 n 
-0000435466 00000 n 
-0000656636 00000 n 
-0000016094 00000 n 
-0000016123 00000 n 
-0000444851 00000 n 
-0000656543 00000 n 
-0000016172 00000 n 
-0000016200 00000 n 
-0000448491 00000 n 
-0000656450 00000 n 
-0000016249 00000 n 
-0000016282 00000 n 
-0000457889 00000 n 
-0000656371 00000 n 
-0000016332 00000 n 
-0000016369 00000 n 
-0000016738 00000 n 
-0000016860 00000 n 
-0000024689 00000 n 
-0000016422 00000 n 
-0000024563 00000 n 
-0000024626 00000 n 
-0000652234 00000 n 
-0000626291 00000 n 
-0000652060 00000 n 
-0000653259 00000 n 
-0000019723 00000 n 
-0000019940 00000 n 
-0000020009 00000 n 
-0000020078 00000 n 
-0000020146 00000 n 
-0000020214 00000 n 
-0000020263 00000 n 
-0000020310 00000 n 
-0000020643 00000 n 
-0000020665 00000 n 
-0000020833 00000 n 
-0000020998 00000 n 
-0000021167 00000 n 
-0000021346 00000 n 
-0000021655 00000 n 
-0000021815 00000 n 
-0000026053 00000 n 
-0000025868 00000 n 
-0000024789 00000 n 
-0000025990 00000 n 
-0000625079 00000 n 
-0000598600 00000 n 
-0000624905 00000 n 
-0000597915 00000 n 
-0000595770 00000 n 
-0000597751 00000 n 
-0000037759 00000 n 
-0000029109 00000 n 
-0000026138 00000 n 
-0000037633 00000 n 
-0000037696 00000 n 
-0000029643 00000 n 
-0000029797 00000 n 
-0000029954 00000 n 
-0000030111 00000 n 
-0000030267 00000 n 
-0000030424 00000 n 
-0000030586 00000 n 
-0000030747 00000 n 
-0000030908 00000 n 
-0000031070 00000 n 
-0000031237 00000 n 
-0000031404 00000 n 
-0000031569 00000 n 
-0000031731 00000 n 
-0000031897 00000 n 
-0000032058 00000 n 
-0000032213 00000 n 
-0000032370 00000 n 
-0000032526 00000 n 
-0000032683 00000 n 
-0000032840 00000 n 
-0000032997 00000 n 
-0000033151 00000 n 
-0000033307 00000 n 
-0000033469 00000 n 
-0000033631 00000 n 
-0000033787 00000 n 
-0000033944 00000 n 
-0000034106 00000 n 
-0000034273 00000 n 
-0000034439 00000 n 
-0000034600 00000 n 
-0000034755 00000 n 
-0000034912 00000 n 
-0000035069 00000 n 
-0000035231 00000 n 
-0000035388 00000 n 
-0000035545 00000 n 
-0000035707 00000 n 
-0000035864 00000 n 
-0000036026 00000 n 
-0000036193 00000 n 
-0000036359 00000 n 
-0000036521 00000 n 
-0000036683 00000 n 
-0000036845 00000 n 
-0000037006 00000 n 
-0000037168 00000 n 
-0000037323 00000 n 
-0000037478 00000 n 
-0000051124 00000 n 
-0000041076 00000 n 
-0000037844 00000 n 
-0000051061 00000 n 
-0000595219 00000 n 
-0000578138 00000 n 
-0000595035 00000 n 
-0000041666 00000 n 
-0000041829 00000 n 
-0000041991 00000 n 
-0000042154 00000 n 
-0000042312 00000 n 
-0000042475 00000 n 
-0000042638 00000 n 
-0000042793 00000 n 
-0000042951 00000 n 
-0000043109 00000 n 
-0000043265 00000 n 
-0000043423 00000 n 
-0000043586 00000 n 
-0000043754 00000 n 
-0000043922 00000 n 
-0000044085 00000 n 
-0000044253 00000 n 
-0000044421 00000 n 
-0000044579 00000 n 
-0000044742 00000 n 
-0000044905 00000 n 
-0000045067 00000 n 
-0000045229 00000 n 
-0000045392 00000 n 
-0000045554 00000 n 
-0000045716 00000 n 
-0000045879 00000 n 
-0000046042 00000 n 
-0000046205 00000 n 
-0000046374 00000 n 
-0000046543 00000 n 
-0000046707 00000 n 
-0000046870 00000 n 
-0000047034 00000 n 
-0000047198 00000 n 
-0000047361 00000 n 
-0000047525 00000 n 
-0000047694 00000 n 
-0000047862 00000 n 
-0000048031 00000 n 
-0000048200 00000 n 
-0000048369 00000 n 
-0000048538 00000 n 
-0000048707 00000 n 
-0000048876 00000 n 
-0000049045 00000 n 
-0000049215 00000 n 
-0000049385 00000 n 
-0000049555 00000 n 
-0000049724 00000 n 
-0000049894 00000 n 
-0000050064 00000 n 
-0000050232 00000 n 
-0000050401 00000 n 
-0000050571 00000 n 
-0000050738 00000 n 
-0000050899 00000 n 
-0000063946 00000 n 
-0000054652 00000 n 
-0000051222 00000 n 
-0000063883 00000 n 
-0000055218 00000 n 
-0000055381 00000 n 
-0000055544 00000 n 
-0000055707 00000 n 
-0000055870 00000 n 
-0000056032 00000 n 
-0000056195 00000 n 
-0000056363 00000 n 
-0000056531 00000 n 
-0000056699 00000 n 
-0000056867 00000 n 
-0000057023 00000 n 
-0000057185 00000 n 
-0000057352 00000 n 
-0000057519 00000 n 
-0000057681 00000 n 
-0000057843 00000 n 
-0000058005 00000 n 
-0000058167 00000 n 
-0000058334 00000 n 
-0000058501 00000 n 
-0000058667 00000 n 
-0000058829 00000 n 
-0000058991 00000 n 
-0000059146 00000 n 
-0000059301 00000 n 
-0000059458 00000 n 
-0000059620 00000 n 
-0000059782 00000 n 
-0000059939 00000 n 
-0000060094 00000 n 
-0000060251 00000 n 
-0000060413 00000 n 
-0000060569 00000 n 
-0000060726 00000 n 
-0000060882 00000 n 
-0000061039 00000 n 
-0000061201 00000 n 
-0000061358 00000 n 
-0000061520 00000 n 
-0000061677 00000 n 
-0000061838 00000 n 
-0000062000 00000 n 
-0000062162 00000 n 
-0000062317 00000 n 
-0000062473 00000 n 
-0000062630 00000 n 
-0000062787 00000 n 
-0000062944 00000 n 
-0000063100 00000 n 
-0000063257 00000 n 
-0000063414 00000 n 
-0000577172 00000 n 
-0000557205 00000 n 
-0000576999 00000 n 
-0000063571 00000 n 
-0000063727 00000 n 
-0000064391 00000 n 
-0000064206 00000 n 
-0000064057 00000 n 
-0000064328 00000 n 
-0000067519 00000 n 
-0000066709 00000 n 
-0000064432 00000 n 
-0000066831 00000 n 
-0000066955 00000 n 
-0000067080 00000 n 
-0000067205 00000 n 
-0000556316 00000 n 
-0000534984 00000 n 
-0000556142 00000 n 
-0000067330 00000 n 
-0000067393 00000 n 
-0000067456 00000 n 
-0000534210 00000 n 
-0000516663 00000 n 
-0000534037 00000 n 
-0000653377 00000 n 
-0000072030 00000 n 
-0000070848 00000 n 
-0000067643 00000 n 
-0000071342 00000 n 
-0000071405 00000 n 
-0000071468 00000 n 
-0000071593 00000 n 
-0000071718 00000 n 
-0000071843 00000 n 
-0000070998 00000 n 
-0000071191 00000 n 
-0000071968 00000 n 
-0000314552 00000 n 
-0000357858 00000 n 
-0000076684 00000 n 
-0000075648 00000 n 
-0000072154 00000 n 
-0000076121 00000 n 
-0000076246 00000 n 
-0000075798 00000 n 
-0000075960 00000 n 
-0000076371 00000 n 
-0000076496 00000 n 
-0000076621 00000 n 
-0000092551 00000 n 
-0000079906 00000 n 
-0000079346 00000 n 
-0000076808 00000 n 
-0000079468 00000 n 
-0000079593 00000 n 
-0000079718 00000 n 
-0000079843 00000 n 
-0000083333 00000 n 
-0000082192 00000 n 
-0000080017 00000 n 
-0000082646 00000 n 
-0000082771 00000 n 
-0000082896 00000 n 
-0000083021 00000 n 
-0000083146 00000 n 
-0000082342 00000 n 
-0000082494 00000 n 
-0000083270 00000 n 
-0000273113 00000 n 
-0000084416 00000 n 
-0000084106 00000 n 
-0000083418 00000 n 
-0000084228 00000 n 
-0000084353 00000 n 
-0000086501 00000 n 
-0000085816 00000 n 
-0000084514 00000 n 
-0000085938 00000 n 
-0000086063 00000 n 
-0000086187 00000 n 
-0000086312 00000 n 
-0000086438 00000 n 
-0000653495 00000 n 
-0000089406 00000 n 
-0000088538 00000 n 
-0000086599 00000 n 
-0000088840 00000 n 
-0000088966 00000 n 
-0000089029 00000 n 
-0000089092 00000 n 
-0000088680 00000 n 
-0000089218 00000 n 
-0000089344 00000 n 
-0000254118 00000 n 
-0000092740 00000 n 
-0000092303 00000 n 
-0000089517 00000 n 
-0000092425 00000 n 
-0000516007 00000 n 
-0000504421 00000 n 
-0000515830 00000 n 
-0000092677 00000 n 
-0000096525 00000 n 
-0000096340 00000 n 
-0000092864 00000 n 
-0000096462 00000 n 
-0000503882 00000 n 
-0000494141 00000 n 
-0000503705 00000 n 
-0000100909 00000 n 
-0000100518 00000 n 
-0000096688 00000 n 
-0000100846 00000 n 
-0000100660 00000 n 
-0000161496 00000 n 
-0000103195 00000 n 
-0000102758 00000 n 
-0000101046 00000 n 
-0000102880 00000 n 
-0000103006 00000 n 
-0000103069 00000 n 
-0000103132 00000 n 
-0000105847 00000 n 
-0000108379 00000 n 
-0000105696 00000 n 
-0000103319 00000 n 
-0000107811 00000 n 
-0000107937 00000 n 
-0000108063 00000 n 
-0000107489 00000 n 
-0000107650 00000 n 
-0000493282 00000 n 
-0000483910 00000 n 
-0000493110 00000 n 
-0000483348 00000 n 
-0000474265 00000 n 
-0000483175 00000 n 
-0000108189 00000 n 
-0000108315 00000 n 
-0000653613 00000 n 
-0000107318 00000 n 
-0000107376 00000 n 
-0000107466 00000 n 
-0000198969 00000 n 
-0000231128 00000 n 
-0000112928 00000 n 
-0000111994 00000 n 
-0000108531 00000 n 
-0000112478 00000 n 
-0000112606 00000 n 
-0000112150 00000 n 
-0000112316 00000 n 
-0000112734 00000 n 
-0000112863 00000 n 
-0000361883 00000 n 
-0000116420 00000 n 
-0000116040 00000 n 
-0000113079 00000 n 
-0000116355 00000 n 
-0000116187 00000 n 
-0000117654 00000 n 
-0000117463 00000 n 
-0000116545 00000 n 
-0000117589 00000 n 
-0000120556 00000 n 
-0000119980 00000 n 
-0000117753 00000 n 
-0000120106 00000 n 
-0000120233 00000 n 
-0000120362 00000 n 
-0000120491 00000 n 
-0000123946 00000 n 
-0000123111 00000 n 
-0000120694 00000 n 
-0000123237 00000 n 
-0000123366 00000 n 
-0000123495 00000 n 
-0000123624 00000 n 
-0000123752 00000 n 
-0000123881 00000 n 
-0000127849 00000 n 
-0000127081 00000 n 
-0000124084 00000 n 
-0000127398 00000 n 
-0000127228 00000 n 
-0000127527 00000 n 
-0000127656 00000 n 
-0000127785 00000 n 
-0000653737 00000 n 
-0000310333 00000 n 
-0000131713 00000 n 
-0000131136 00000 n 
-0000127961 00000 n 
-0000131262 00000 n 
-0000131391 00000 n 
-0000131519 00000 n 
-0000131648 00000 n 
-0000135155 00000 n 
-0000134835 00000 n 
-0000131851 00000 n 
-0000134961 00000 n 
-0000135090 00000 n 
-0000138486 00000 n 
-0000137727 00000 n 
-0000135267 00000 n 
-0000138035 00000 n 
-0000138164 00000 n 
-0000137874 00000 n 
-0000138293 00000 n 
-0000138421 00000 n 
-0000357600 00000 n 
-0000141224 00000 n 
-0000140646 00000 n 
-0000138652 00000 n 
-0000140772 00000 n 
-0000140901 00000 n 
-0000141030 00000 n 
-0000141159 00000 n 
-0000141664 00000 n 
-0000141473 00000 n 
-0000141323 00000 n 
-0000141599 00000 n 
-0000145666 00000 n 
-0000144900 00000 n 
-0000141706 00000 n 
-0000145214 00000 n 
-0000145343 00000 n 
-0000145471 00000 n 
-0000145536 00000 n 
-0000145601 00000 n 
-0000145047 00000 n 
-0000653862 00000 n 
-0000150078 00000 n 
-0000150270 00000 n 
-0000149824 00000 n 
-0000145765 00000 n 
-0000149950 00000 n 
-0000150205 00000 n 
-0000154096 00000 n 
-0000153389 00000 n 
-0000150395 00000 n 
-0000153515 00000 n 
-0000153644 00000 n 
-0000153773 00000 n 
-0000153902 00000 n 
-0000154031 00000 n 
-0000156826 00000 n 
-0000158075 00000 n 
-0000156700 00000 n 
-0000154221 00000 n 
-0000157752 00000 n 
-0000157881 00000 n 
-0000157946 00000 n 
-0000158010 00000 n 
-0000161559 00000 n 
-0000160725 00000 n 
-0000158229 00000 n 
-0000160851 00000 n 
-0000160980 00000 n 
-0000161108 00000 n 
-0000161173 00000 n 
-0000161238 00000 n 
-0000161367 00000 n 
-0000166717 00000 n 
-0000165800 00000 n 
-0000161671 00000 n 
-0000166266 00000 n 
-0000165956 00000 n 
-0000166107 00000 n 
-0000166395 00000 n 
-0000166524 00000 n 
-0000166652 00000 n 
-0000460456 00000 n 
-0000170741 00000 n 
-0000169599 00000 n 
-0000166855 00000 n 
-0000170289 00000 n 
-0000170418 00000 n 
-0000169764 00000 n 
-0000169916 00000 n 
-0000170103 00000 n 
-0000170547 00000 n 
-0000170676 00000 n 
-0000653987 00000 n 
-0000175273 00000 n 
-0000174953 00000 n 
-0000170866 00000 n 
-0000175079 00000 n 
-0000175208 00000 n 
-0000178462 00000 n 
-0000178083 00000 n 
-0000175398 00000 n 
-0000178397 00000 n 
-0000178230 00000 n 
-0000181635 00000 n 
-0000181830 00000 n 
-0000181380 00000 n 
-0000178574 00000 n 
-0000181506 00000 n 
-0000181700 00000 n 
-0000181765 00000 n 
-0000185463 00000 n 
-0000184678 00000 n 
-0000181942 00000 n 
-0000185140 00000 n 
-0000185269 00000 n 
-0000185398 00000 n 
-0000184834 00000 n 
-0000184987 00000 n 
-0000187606 00000 n 
-0000187028 00000 n 
-0000185575 00000 n 
-0000187154 00000 n 
-0000187283 00000 n 
-0000187412 00000 n 
-0000187541 00000 n 
-0000189177 00000 n 
-0000188986 00000 n 
-0000187718 00000 n 
-0000189112 00000 n 
-0000654112 00000 n 
-0000190937 00000 n 
-0000190618 00000 n 
-0000189276 00000 n 
-0000190744 00000 n 
-0000190873 00000 n 
-0000195079 00000 n 
-0000194711 00000 n 
-0000191049 00000 n 
-0000195014 00000 n 
-0000194858 00000 n 
-0000269386 00000 n 
-0000199034 00000 n 
-0000198714 00000 n 
-0000195204 00000 n 
-0000198840 00000 n 
-0000202871 00000 n 
-0000202551 00000 n 
-0000199159 00000 n 
-0000202677 00000 n 
-0000202742 00000 n 
-0000202806 00000 n 
-0000208134 00000 n 
-0000206840 00000 n 
-0000202996 00000 n 
-0000208069 00000 n 
-0000207032 00000 n 
-0000207186 00000 n 
-0000207342 00000 n 
-0000207527 00000 n 
-0000207701 00000 n 
-0000207885 00000 n 
-0000277765 00000 n 
-0000212392 00000 n 
-0000212201 00000 n 
-0000208313 00000 n 
-0000212327 00000 n 
-0000654237 00000 n 
-0000216088 00000 n 
-0000215897 00000 n 
-0000212517 00000 n 
-0000216023 00000 n 
-0000220442 00000 n 
-0000219499 00000 n 
-0000216200 00000 n 
-0000219990 00000 n 
-0000220119 00000 n 
-0000219655 00000 n 
-0000220248 00000 n 
-0000220377 00000 n 
-0000219824 00000 n 
-0000286323 00000 n 
-0000224715 00000 n 
-0000224024 00000 n 
-0000220608 00000 n 
-0000224522 00000 n 
-0000224180 00000 n 
-0000224351 00000 n 
-0000224651 00000 n 
-0000345230 00000 n 
-0000228243 00000 n 
-0000227923 00000 n 
-0000224840 00000 n 
-0000228049 00000 n 
-0000228178 00000 n 
-0000231193 00000 n 
-0000230873 00000 n 
-0000228355 00000 n 
-0000230999 00000 n 
-0000235248 00000 n 
-0000235057 00000 n 
-0000231346 00000 n 
-0000235183 00000 n 
-0000654362 00000 n 
-0000238785 00000 n 
-0000238284 00000 n 
-0000235401 00000 n 
-0000238591 00000 n 
-0000238720 00000 n 
-0000238431 00000 n 
-0000243217 00000 n 
-0000242410 00000 n 
-0000238951 00000 n 
-0000242896 00000 n 
-0000243025 00000 n 
-0000242566 00000 n 
-0000243153 00000 n 
-0000242741 00000 n 
-0000247134 00000 n 
-0000246685 00000 n 
-0000243329 00000 n 
-0000246811 00000 n 
-0000246940 00000 n 
-0000247069 00000 n 
-0000251164 00000 n 
-0000250497 00000 n 
-0000247287 00000 n 
-0000250971 00000 n 
-0000251100 00000 n 
-0000250653 00000 n 
-0000250815 00000 n 
-0000254312 00000 n 
-0000253673 00000 n 
-0000251330 00000 n 
-0000253989 00000 n 
-0000253820 00000 n 
-0000254182 00000 n 
-0000254247 00000 n 
-0000258137 00000 n 
-0000257637 00000 n 
-0000254437 00000 n 
-0000257944 00000 n 
-0000258073 00000 n 
-0000257784 00000 n 
-0000654487 00000 n 
-0000262963 00000 n 
-0000262285 00000 n 
-0000258316 00000 n 
-0000262770 00000 n 
-0000262441 00000 n 
-0000473910 00000 n 
-0000471912 00000 n 
-0000473745 00000 n 
-0000262898 00000 n 
-0000262603 00000 n 
-0000336875 00000 n 
-0000281535 00000 n 
-0000266290 00000 n 
-0000265970 00000 n 
-0000263089 00000 n 
-0000266096 00000 n 
-0000266225 00000 n 
-0000269580 00000 n 
-0000269131 00000 n 
-0000266456 00000 n 
-0000269257 00000 n 
-0000269451 00000 n 
-0000269515 00000 n 
-0000273306 00000 n 
-0000272858 00000 n 
-0000269679 00000 n 
-0000272984 00000 n 
-0000273241 00000 n 
-0000277829 00000 n 
-0000277340 00000 n 
-0000273418 00000 n 
-0000277636 00000 n 
-0000277487 00000 n 
-0000281728 00000 n 
-0000280676 00000 n 
-0000277941 00000 n 
-0000281148 00000 n 
-0000280832 00000 n 
-0000281277 00000 n 
-0000281406 00000 n 
-0000280994 00000 n 
-0000281664 00000 n 
-0000654612 00000 n 
-0000284830 00000 n 
-0000284639 00000 n 
-0000281840 00000 n 
-0000284765 00000 n 
-0000286388 00000 n 
-0000286068 00000 n 
-0000284942 00000 n 
-0000286194 00000 n 
-0000287824 00000 n 
-0000287633 00000 n 
-0000286500 00000 n 
-0000287759 00000 n 
-0000290450 00000 n 
-0000289871 00000 n 
-0000287923 00000 n 
-0000289997 00000 n 
-0000290126 00000 n 
-0000290255 00000 n 
-0000290320 00000 n 
-0000290385 00000 n 
-0000294379 00000 n 
-0000294059 00000 n 
-0000290562 00000 n 
-0000294185 00000 n 
-0000294314 00000 n 
-0000299993 00000 n 
-0000297603 00000 n 
-0000294491 00000 n 
-0000299799 00000 n 
-0000299928 00000 n 
-0000297849 00000 n 
-0000298011 00000 n 
-0000298173 00000 n 
-0000298334 00000 n 
-0000298494 00000 n 
-0000298665 00000 n 
-0000298827 00000 n 
-0000298989 00000 n 
-0000299149 00000 n 
-0000299310 00000 n 
-0000299473 00000 n 
-0000299636 00000 n 
-0000654737 00000 n 
-0000305217 00000 n 
-0000303157 00000 n 
-0000300118 00000 n 
-0000305152 00000 n 
-0000303394 00000 n 
-0000303554 00000 n 
-0000303716 00000 n 
-0000303877 00000 n 
-0000304038 00000 n 
-0000304200 00000 n 
-0000304363 00000 n 
-0000304517 00000 n 
-0000304670 00000 n 
-0000304832 00000 n 
-0000304992 00000 n 
-0000310526 00000 n 
-0000308563 00000 n 
-0000305342 00000 n 
-0000310204 00000 n 
-0000308782 00000 n 
-0000308942 00000 n 
-0000309104 00000 n 
-0000309263 00000 n 
-0000309422 00000 n 
-0000309575 00000 n 
-0000309738 00000 n 
-0000309888 00000 n 
-0000310050 00000 n 
-0000310398 00000 n 
-0000310462 00000 n 
-0000314874 00000 n 
-0000313808 00000 n 
-0000310651 00000 n 
-0000314295 00000 n 
-0000314423 00000 n 
-0000314680 00000 n 
-0000313964 00000 n 
-0000314134 00000 n 
-0000314745 00000 n 
-0000314810 00000 n 
-0000318327 00000 n 
-0000318006 00000 n 
-0000314999 00000 n 
-0000318132 00000 n 
-0000318197 00000 n 
-0000318262 00000 n 
-0000321897 00000 n 
-0000321576 00000 n 
-0000318426 00000 n 
-0000321702 00000 n 
-0000321767 00000 n 
-0000321832 00000 n 
-0000325927 00000 n 
-0000325219 00000 n 
-0000322009 00000 n 
-0000325345 00000 n 
-0000325474 00000 n 
-0000325539 00000 n 
-0000325604 00000 n 
-0000325668 00000 n 
-0000325733 00000 n 
-0000325862 00000 n 
-0000654862 00000 n 
-0000329738 00000 n 
-0000328899 00000 n 
-0000326052 00000 n 
-0000329025 00000 n 
-0000329090 00000 n 
-0000329155 00000 n 
-0000329284 00000 n 
-0000329349 00000 n 
-0000329414 00000 n 
-0000329543 00000 n 
-0000329608 00000 n 
-0000329673 00000 n 
-0000333026 00000 n 
-0000332193 00000 n 
-0000329917 00000 n 
-0000332319 00000 n 
-0000332448 00000 n 
-0000332576 00000 n 
-0000332704 00000 n 
-0000332833 00000 n 
-0000332962 00000 n 
-0000336940 00000 n 
-0000336490 00000 n 
-0000333219 00000 n 
-0000336616 00000 n 
-0000336681 00000 n 
-0000336746 00000 n 
-0000338422 00000 n 
-0000338231 00000 n 
-0000337065 00000 n 
-0000338357 00000 n 
-0000338875 00000 n 
-0000338684 00000 n 
-0000338534 00000 n 
-0000338810 00000 n 
-0000340815 00000 n 
-0000340366 00000 n 
-0000338917 00000 n 
-0000340492 00000 n 
-0000340621 00000 n 
-0000340750 00000 n 
-0000654987 00000 n 
-0000345295 00000 n 
-0000344351 00000 n 
-0000340927 00000 n 
-0000344714 00000 n 
-0000471591 00000 n 
-0000462378 00000 n 
-0000471405 00000 n 
-0000344498 00000 n 
-0000344843 00000 n 
-0000344972 00000 n 
-0000345101 00000 n 
-0000346333 00000 n 
-0000346142 00000 n 
-0000345528 00000 n 
-0000346268 00000 n 
-0000346760 00000 n 
-0000346569 00000 n 
-0000346419 00000 n 
-0000346695 00000 n 
-0000350073 00000 n 
-0000348847 00000 n 
-0000346802 00000 n 
-0000349364 00000 n 
-0000349493 00000 n 
-0000349622 00000 n 
-0000349751 00000 n 
-0000349880 00000 n 
-0000350009 00000 n 
-0000349003 00000 n 
-0000349175 00000 n 
-0000350527 00000 n 
-0000350336 00000 n 
-0000350186 00000 n 
-0000350462 00000 n 
-0000353771 00000 n 
-0000353193 00000 n 
-0000350569 00000 n 
-0000353319 00000 n 
-0000353448 00000 n 
-0000353577 00000 n 
-0000353706 00000 n 
-0000655112 00000 n 
-0000358050 00000 n 
-0000356831 00000 n 
-0000353857 00000 n 
-0000357342 00000 n 
-0000357471 00000 n 
-0000357729 00000 n 
-0000356987 00000 n 
-0000357166 00000 n 
-0000357922 00000 n 
-0000357986 00000 n 
-0000364935 00000 n 
-0000361107 00000 n 
-0000358202 00000 n 
-0000361233 00000 n 
-0000361298 00000 n 
-0000361363 00000 n 
-0000361428 00000 n 
-0000361493 00000 n 
-0000361558 00000 n 
-0000361623 00000 n 
-0000361688 00000 n 
-0000361753 00000 n 
-0000361818 00000 n 
-0000361948 00000 n 
-0000362013 00000 n 
-0000362078 00000 n 
-0000362143 00000 n 
-0000362208 00000 n 
-0000362273 00000 n 
-0000362338 00000 n 
-0000362403 00000 n 
-0000362468 00000 n 
-0000362533 00000 n 
-0000362598 00000 n 
-0000362663 00000 n 
-0000362728 00000 n 
-0000362793 00000 n 
-0000362858 00000 n 
-0000362923 00000 n 
-0000362988 00000 n 
-0000363053 00000 n 
-0000363118 00000 n 
-0000363183 00000 n 
-0000363248 00000 n 
-0000363313 00000 n 
-0000363378 00000 n 
-0000363443 00000 n 
-0000363507 00000 n 
-0000363572 00000 n 
-0000363637 00000 n 
-0000363702 00000 n 
-0000363767 00000 n 
-0000363832 00000 n 
-0000363897 00000 n 
-0000363962 00000 n 
-0000364027 00000 n 
-0000364092 00000 n 
-0000364157 00000 n 
-0000364222 00000 n 
-0000364287 00000 n 
-0000364352 00000 n 
-0000364417 00000 n 
-0000364482 00000 n 
-0000364547 00000 n 
-0000364612 00000 n 
-0000364677 00000 n 
-0000364742 00000 n 
-0000364807 00000 n 
-0000364871 00000 n 
-0000371581 00000 n 
-0000368017 00000 n 
-0000365047 00000 n 
-0000368143 00000 n 
-0000368208 00000 n 
-0000368273 00000 n 
-0000368338 00000 n 
-0000368403 00000 n 
-0000368468 00000 n 
-0000368533 00000 n 
-0000368598 00000 n 
-0000368663 00000 n 
-0000368728 00000 n 
-0000368793 00000 n 
-0000368858 00000 n 
-0000368922 00000 n 
-0000368987 00000 n 
-0000369052 00000 n 
-0000369117 00000 n 
-0000369182 00000 n 
-0000369247 00000 n 
-0000369312 00000 n 
-0000369377 00000 n 
-0000369442 00000 n 
-0000369507 00000 n 
-0000369572 00000 n 
-0000369637 00000 n 
-0000369701 00000 n 
-0000369766 00000 n 
-0000369831 00000 n 
-0000369896 00000 n 
-0000369961 00000 n 
-0000370026 00000 n 
-0000370091 00000 n 
-0000370156 00000 n 
-0000370221 00000 n 
-0000370286 00000 n 
-0000370351 00000 n 
-0000370416 00000 n 
-0000370481 00000 n 
-0000370546 00000 n 
-0000370611 00000 n 
-0000370676 00000 n 
+0000015809 00000 n 
+0000417904 00000 n 
+0000664610 00000 n 
+0000015858 00000 n 
+0000015895 00000 n 
+0000424222 00000 n 
+0000664517 00000 n 
+0000015944 00000 n 
+0000015983 00000 n 
+0000433742 00000 n 
+0000664424 00000 n 
+0000016032 00000 n 
+0000016071 00000 n 
+0000436629 00000 n 
+0000664331 00000 n 
+0000016120 00000 n 
+0000016159 00000 n 
+0000443022 00000 n 
+0000664238 00000 n 
+0000016208 00000 n 
+0000016237 00000 n 
+0000452411 00000 n 
+0000664145 00000 n 
+0000016286 00000 n 
+0000016314 00000 n 
+0000456051 00000 n 
+0000664052 00000 n 
+0000016363 00000 n 
+0000016396 00000 n 
+0000465449 00000 n 
+0000663973 00000 n 
+0000016446 00000 n 
+0000016483 00000 n 
+0000016852 00000 n 
+0000016974 00000 n 
+0000024803 00000 n 
+0000016536 00000 n 
+0000024677 00000 n 
+0000024740 00000 n 
+0000659836 00000 n 
+0000633893 00000 n 
+0000659662 00000 n 
+0000660861 00000 n 
+0000019837 00000 n 
+0000020054 00000 n 
+0000020123 00000 n 
+0000020192 00000 n 
+0000020260 00000 n 
+0000020328 00000 n 
+0000020377 00000 n 
+0000020424 00000 n 
+0000020757 00000 n 
+0000020779 00000 n 
+0000020947 00000 n 
+0000021112 00000 n 
+0000021281 00000 n 
+0000021460 00000 n 
+0000021769 00000 n 
+0000021929 00000 n 
+0000026167 00000 n 
+0000025982 00000 n 
+0000024903 00000 n 
+0000026104 00000 n 
+0000632681 00000 n 
+0000606202 00000 n 
+0000632507 00000 n 
+0000605517 00000 n 
+0000603371 00000 n 
+0000605353 00000 n 
+0000037873 00000 n 
+0000029223 00000 n 
+0000026252 00000 n 
+0000037747 00000 n 
+0000037810 00000 n 
+0000029757 00000 n 
+0000029911 00000 n 
+0000030068 00000 n 
+0000030225 00000 n 
+0000030381 00000 n 
+0000030538 00000 n 
+0000030700 00000 n 
+0000030861 00000 n 
+0000031022 00000 n 
+0000031184 00000 n 
+0000031351 00000 n 
+0000031518 00000 n 
+0000031683 00000 n 
+0000031845 00000 n 
+0000032011 00000 n 
+0000032172 00000 n 
+0000032327 00000 n 
+0000032484 00000 n 
+0000032640 00000 n 
+0000032797 00000 n 
+0000032954 00000 n 
+0000033111 00000 n 
+0000033265 00000 n 
+0000033421 00000 n 
+0000033583 00000 n 
+0000033745 00000 n 
+0000033901 00000 n 
+0000034058 00000 n 
+0000034220 00000 n 
+0000034387 00000 n 
+0000034553 00000 n 
+0000034714 00000 n 
+0000034869 00000 n 
+0000035026 00000 n 
+0000035183 00000 n 
+0000035345 00000 n 
+0000035502 00000 n 
+0000035659 00000 n 
+0000035821 00000 n 
+0000035978 00000 n 
+0000036140 00000 n 
+0000036307 00000 n 
+0000036473 00000 n 
+0000036635 00000 n 
+0000036797 00000 n 
+0000036959 00000 n 
+0000037120 00000 n 
+0000037282 00000 n 
+0000037437 00000 n 
+0000037592 00000 n 
+0000051262 00000 n 
+0000041209 00000 n 
+0000037958 00000 n 
+0000051199 00000 n 
+0000602820 00000 n 
+0000585739 00000 n 
+0000602636 00000 n 
+0000041799 00000 n 
+0000041962 00000 n 
+0000042124 00000 n 
+0000042287 00000 n 
+0000042445 00000 n 
+0000042608 00000 n 
+0000042771 00000 n 
+0000042926 00000 n 
+0000043084 00000 n 
+0000043242 00000 n 
+0000043398 00000 n 
+0000043556 00000 n 
+0000043719 00000 n 
+0000043887 00000 n 
+0000044055 00000 n 
+0000044218 00000 n 
+0000044386 00000 n 
+0000044554 00000 n 
+0000044712 00000 n 
+0000044875 00000 n 
+0000045038 00000 n 
+0000045200 00000 n 
+0000045362 00000 n 
+0000045525 00000 n 
+0000045687 00000 n 
+0000045849 00000 n 
+0000046012 00000 n 
+0000046175 00000 n 
+0000046338 00000 n 
+0000046507 00000 n 
+0000046676 00000 n 
+0000046845 00000 n 
+0000047008 00000 n 
+0000047172 00000 n 
+0000047336 00000 n 
+0000047499 00000 n 
+0000047663 00000 n 
+0000047827 00000 n 
+0000047995 00000 n 
+0000048164 00000 n 
+0000048333 00000 n 
+0000048502 00000 n 
+0000048671 00000 n 
+0000048840 00000 n 
+0000049009 00000 n 
+0000049178 00000 n 
+0000049347 00000 n 
+0000049517 00000 n 
+0000049687 00000 n 
+0000049856 00000 n 
+0000050026 00000 n 
+0000050196 00000 n 
+0000050364 00000 n 
+0000050533 00000 n 
+0000050703 00000 n 
+0000050870 00000 n 
+0000051037 00000 n 
+0000064310 00000 n 
+0000054845 00000 n 
+0000051360 00000 n 
+0000064247 00000 n 
+0000055419 00000 n 
+0000055582 00000 n 
+0000055745 00000 n 
+0000055908 00000 n 
+0000056071 00000 n 
+0000056233 00000 n 
+0000056396 00000 n 
+0000056559 00000 n 
+0000056727 00000 n 
+0000056893 00000 n 
+0000057061 00000 n 
+0000057229 00000 n 
+0000057386 00000 n 
+0000057548 00000 n 
+0000057715 00000 n 
+0000057882 00000 n 
+0000058044 00000 n 
+0000058206 00000 n 
+0000058368 00000 n 
+0000058530 00000 n 
+0000058697 00000 n 
+0000058864 00000 n 
+0000059031 00000 n 
+0000059193 00000 n 
+0000059355 00000 n 
+0000059510 00000 n 
+0000059667 00000 n 
+0000059824 00000 n 
+0000059986 00000 n 
+0000060148 00000 n 
+0000060305 00000 n 
+0000060460 00000 n 
+0000060617 00000 n 
+0000060778 00000 n 
+0000060935 00000 n 
+0000061092 00000 n 
+0000061247 00000 n 
+0000061404 00000 n 
+0000061566 00000 n 
+0000061723 00000 n 
+0000061885 00000 n 
+0000062041 00000 n 
+0000062203 00000 n 
+0000062365 00000 n 
+0000062527 00000 n 
+0000062683 00000 n 
+0000062840 00000 n 
+0000062997 00000 n 
+0000063154 00000 n 
+0000063310 00000 n 
+0000063467 00000 n 
+0000063624 00000 n 
+0000063781 00000 n 
+0000584773 00000 n 
+0000564806 00000 n 
+0000584600 00000 n 
+0000063937 00000 n 
+0000064092 00000 n 
+0000064755 00000 n 
+0000064570 00000 n 
+0000064421 00000 n 
+0000064692 00000 n 
+0000067860 00000 n 
+0000067050 00000 n 
+0000064796 00000 n 
+0000067172 00000 n 
+0000067296 00000 n 
+0000067421 00000 n 
+0000067546 00000 n 
+0000563917 00000 n 
+0000542586 00000 n 
+0000563743 00000 n 
+0000067671 00000 n 
+0000067734 00000 n 
+0000067797 00000 n 
+0000541812 00000 n 
+0000524265 00000 n 
+0000541639 00000 n 
+0000660979 00000 n 
+0000072371 00000 n 
+0000071189 00000 n 
+0000067984 00000 n 
+0000071683 00000 n 
+0000071746 00000 n 
+0000071809 00000 n 
+0000071934 00000 n 
+0000072059 00000 n 
+0000072184 00000 n 
+0000071339 00000 n 
+0000071532 00000 n 
+0000072309 00000 n 
+0000323763 00000 n 
+0000365285 00000 n 
+0000077025 00000 n 
+0000075989 00000 n 
+0000072495 00000 n 
+0000076462 00000 n 
+0000076587 00000 n 
+0000076139 00000 n 
+0000076301 00000 n 
+0000076712 00000 n 
+0000076837 00000 n 
+0000076962 00000 n 
+0000092900 00000 n 
+0000080247 00000 n 
+0000079687 00000 n 
+0000077149 00000 n 
+0000079809 00000 n 
+0000079934 00000 n 
+0000080059 00000 n 
+0000080184 00000 n 
+0000083674 00000 n 
+0000082533 00000 n 
+0000080358 00000 n 
+0000082987 00000 n 
+0000083112 00000 n 
+0000083237 00000 n 
+0000083362 00000 n 
+0000083487 00000 n 
+0000082683 00000 n 
+0000082835 00000 n 
+0000083611 00000 n 
+0000277767 00000 n 
+0000084757 00000 n 
+0000084447 00000 n 
+0000083759 00000 n 
+0000084569 00000 n 
+0000084694 00000 n 
+0000086835 00000 n 
+0000086150 00000 n 
+0000084855 00000 n 
+0000086272 00000 n 
+0000086397 00000 n 
+0000086521 00000 n 
+0000086646 00000 n 
+0000086772 00000 n 
+0000661097 00000 n 
+0000089740 00000 n 
+0000088872 00000 n 
+0000086933 00000 n 
+0000089174 00000 n 
+0000089300 00000 n 
+0000089363 00000 n 
+0000089426 00000 n 
+0000089014 00000 n 
+0000089552 00000 n 
+0000089678 00000 n 
+0000262009 00000 n 
+0000093089 00000 n 
+0000092652 00000 n 
+0000089851 00000 n 
+0000092774 00000 n 
+0000523609 00000 n 
+0000512024 00000 n 
+0000523432 00000 n 
+0000093026 00000 n 
+0000096906 00000 n 
+0000096721 00000 n 
+0000093213 00000 n 
+0000096843 00000 n 
+0000511485 00000 n 
+0000501742 00000 n 
+0000511308 00000 n 
+0000101367 00000 n 
+0000100976 00000 n 
+0000097069 00000 n 
+0000101304 00000 n 
+0000101118 00000 n 
+0000162391 00000 n 
+0000103653 00000 n 
+0000103216 00000 n 
+0000101504 00000 n 
+0000103338 00000 n 
+0000103464 00000 n 
+0000103527 00000 n 
+0000103590 00000 n 
+0000106344 00000 n 
+0000108877 00000 n 
+0000106193 00000 n 
+0000103777 00000 n 
+0000108308 00000 n 
+0000108434 00000 n 
+0000108560 00000 n 
+0000107986 00000 n 
+0000108147 00000 n 
+0000500883 00000 n 
+0000491510 00000 n 
+0000500710 00000 n 
+0000490946 00000 n 
+0000481859 00000 n 
+0000490771 00000 n 
+0000108686 00000 n 
+0000108813 00000 n 
+0000661215 00000 n 
+0000107815 00000 n 
+0000107873 00000 n 
+0000107963 00000 n 
+0000206952 00000 n 
+0000239684 00000 n 
+0000113428 00000 n 
+0000112494 00000 n 
+0000109031 00000 n 
+0000112978 00000 n 
+0000113106 00000 n 
+0000112650 00000 n 
+0000112816 00000 n 
+0000113234 00000 n 
+0000113363 00000 n 
+0000369310 00000 n 
+0000116920 00000 n 
+0000116540 00000 n 
+0000113579 00000 n 
+0000116855 00000 n 
+0000116687 00000 n 
+0000118154 00000 n 
+0000117963 00000 n 
+0000117045 00000 n 
+0000118089 00000 n 
+0000121056 00000 n 
+0000120480 00000 n 
+0000118253 00000 n 
+0000120606 00000 n 
+0000120733 00000 n 
+0000120862 00000 n 
+0000120991 00000 n 
+0000124467 00000 n 
+0000123632 00000 n 
+0000121194 00000 n 
+0000123758 00000 n 
+0000123887 00000 n 
+0000124016 00000 n 
+0000124145 00000 n 
+0000124273 00000 n 
+0000124402 00000 n 
+0000128391 00000 n 
+0000127623 00000 n 
+0000124605 00000 n 
+0000127940 00000 n 
+0000127770 00000 n 
+0000128069 00000 n 
+0000128198 00000 n 
+0000128327 00000 n 
+0000661339 00000 n 
+0000319731 00000 n 
+0000132255 00000 n 
+0000131678 00000 n 
+0000128503 00000 n 
+0000131804 00000 n 
+0000131933 00000 n 
+0000132061 00000 n 
+0000132190 00000 n 
+0000135717 00000 n 
+0000135397 00000 n 
+0000132393 00000 n 
+0000135523 00000 n 
+0000135652 00000 n 
+0000139048 00000 n 
+0000138289 00000 n 
+0000135829 00000 n 
+0000138597 00000 n 
+0000138726 00000 n 
+0000138436 00000 n 
+0000138855 00000 n 
+0000138983 00000 n 
+0000365027 00000 n 
+0000141787 00000 n 
+0000141209 00000 n 
+0000139215 00000 n 
+0000141335 00000 n 
+0000141464 00000 n 
+0000141593 00000 n 
+0000141722 00000 n 
+0000142227 00000 n 
+0000142036 00000 n 
+0000141886 00000 n 
+0000142162 00000 n 
+0000146229 00000 n 
+0000145463 00000 n 
+0000142269 00000 n 
+0000145777 00000 n 
+0000145906 00000 n 
+0000146034 00000 n 
+0000146099 00000 n 
+0000146164 00000 n 
+0000145610 00000 n 
+0000661464 00000 n 
+0000150641 00000 n 
+0000150833 00000 n 
+0000150387 00000 n 
+0000146328 00000 n 
+0000150513 00000 n 
+0000150768 00000 n 
+0000154679 00000 n 
+0000153972 00000 n 
+0000150958 00000 n 
+0000154098 00000 n 
+0000154227 00000 n 
+0000154356 00000 n 
+0000154485 00000 n 
+0000154614 00000 n 
+0000157550 00000 n 
+0000158800 00000 n 
+0000157424 00000 n 
+0000154804 00000 n 
+0000158476 00000 n 
+0000158605 00000 n 
+0000158670 00000 n 
+0000158735 00000 n 
+0000162455 00000 n 
+0000161620 00000 n 
+0000158955 00000 n 
+0000161746 00000 n 
+0000161875 00000 n 
+0000162003 00000 n 
+0000162068 00000 n 
+0000162133 00000 n 
+0000162262 00000 n 
+0000167312 00000 n 
+0000166397 00000 n 
+0000162567 00000 n 
+0000166863 00000 n 
+0000166553 00000 n 
+0000166704 00000 n 
+0000166991 00000 n 
+0000167118 00000 n 
+0000167247 00000 n 
+0000468049 00000 n 
+0000171332 00000 n 
+0000170190 00000 n 
+0000167450 00000 n 
+0000170880 00000 n 
+0000171009 00000 n 
+0000170355 00000 n 
+0000170507 00000 n 
+0000170694 00000 n 
+0000171138 00000 n 
+0000171267 00000 n 
+0000661589 00000 n 
+0000175864 00000 n 
+0000175544 00000 n 
+0000171457 00000 n 
+0000175670 00000 n 
+0000175799 00000 n 
+0000179053 00000 n 
+0000178674 00000 n 
+0000175989 00000 n 
+0000178988 00000 n 
+0000178821 00000 n 
+0000182238 00000 n 
+0000182433 00000 n 
+0000181983 00000 n 
+0000179165 00000 n 
+0000182109 00000 n 
+0000182303 00000 n 
+0000182368 00000 n 
+0000185782 00000 n 
+0000185462 00000 n 
+0000182545 00000 n 
+0000185588 00000 n 
+0000185717 00000 n 
+0000189243 00000 n 
+0000188793 00000 n 
+0000185894 00000 n 
+0000188919 00000 n 
+0000188984 00000 n 
+0000189049 00000 n 
+0000189178 00000 n 
+0000192455 00000 n 
+0000191412 00000 n 
+0000189355 00000 n 
+0000191874 00000 n 
+0000192003 00000 n 
+0000191568 00000 n 
+0000191721 00000 n 
+0000192132 00000 n 
+0000192261 00000 n 
+0000192390 00000 n 
+0000661714 00000 n 
+0000194043 00000 n 
+0000193852 00000 n 
+0000192567 00000 n 
+0000193978 00000 n 
+0000195559 00000 n 
+0000195368 00000 n 
+0000194142 00000 n 
+0000195494 00000 n 
+0000198922 00000 n 
+0000198602 00000 n 
+0000195658 00000 n 
+0000198728 00000 n 
+0000198857 00000 n 
+0000203016 00000 n 
+0000202648 00000 n 
+0000199047 00000 n 
+0000202951 00000 n 
+0000202795 00000 n 
+0000277509 00000 n 
+0000207147 00000 n 
+0000206697 00000 n 
+0000203128 00000 n 
+0000206823 00000 n 
+0000207017 00000 n 
+0000207082 00000 n 
+0000211325 00000 n 
+0000210959 00000 n 
+0000207259 00000 n 
+0000211260 00000 n 
+0000211106 00000 n 
+0000661839 00000 n 
+0000216411 00000 n 
+0000215278 00000 n 
+0000211450 00000 n 
+0000216346 00000 n 
+0000215461 00000 n 
+0000215617 00000 n 
+0000215802 00000 n 
+0000215976 00000 n 
+0000216161 00000 n 
+0000281362 00000 n 
+0000220635 00000 n 
+0000220444 00000 n 
+0000216604 00000 n 
+0000220570 00000 n 
+0000224755 00000 n 
+0000224116 00000 n 
+0000220747 00000 n 
+0000224433 00000 n 
+0000224562 00000 n 
+0000224263 00000 n 
+0000224691 00000 n 
+0000292604 00000 n 
+0000229269 00000 n 
+0000228403 00000 n 
+0000224867 00000 n 
+0000229075 00000 n 
+0000229204 00000 n 
+0000228568 00000 n 
+0000228734 00000 n 
+0000228904 00000 n 
+0000352739 00000 n 
+0000232499 00000 n 
+0000232051 00000 n 
+0000229437 00000 n 
+0000232177 00000 n 
+0000232306 00000 n 
+0000232435 00000 n 
+0000235872 00000 n 
+0000235681 00000 n 
+0000232624 00000 n 
+0000235807 00000 n 
+0000661964 00000 n 
+0000239749 00000 n 
+0000239429 00000 n 
+0000236040 00000 n 
+0000239555 00000 n 
+0000243306 00000 n 
+0000243115 00000 n 
+0000239904 00000 n 
+0000243241 00000 n 
+0000247646 00000 n 
+0000246832 00000 n 
+0000243474 00000 n 
+0000247323 00000 n 
+0000247452 00000 n 
+0000246988 00000 n 
+0000247581 00000 n 
+0000247149 00000 n 
+0000251703 00000 n 
+0000251079 00000 n 
+0000247800 00000 n 
+0000251381 00000 n 
+0000251510 00000 n 
+0000251226 00000 n 
+0000251639 00000 n 
+0000254771 00000 n 
+0000254451 00000 n 
+0000251828 00000 n 
+0000254577 00000 n 
+0000254706 00000 n 
+0000258842 00000 n 
+0000258175 00000 n 
+0000254925 00000 n 
+0000258648 00000 n 
+0000258777 00000 n 
+0000258331 00000 n 
+0000258493 00000 n 
+0000662089 00000 n 
+0000262331 00000 n 
+0000261563 00000 n 
+0000259010 00000 n 
+0000261880 00000 n 
+0000261710 00000 n 
+0000262072 00000 n 
+0000262137 00000 n 
+0000262266 00000 n 
+0000267036 00000 n 
+0000266492 00000 n 
+0000262512 00000 n 
+0000266971 00000 n 
+0000266648 00000 n 
+0000266809 00000 n 
+0000346220 00000 n 
+0000271424 00000 n 
+0000270788 00000 n 
+0000267203 00000 n 
+0000271102 00000 n 
+0000481504 00000 n 
+0000479505 00000 n 
+0000481339 00000 n 
+0000271231 00000 n 
+0000270935 00000 n 
+0000271359 00000 n 
+0000290229 00000 n 
+0000274182 00000 n 
+0000273991 00000 n 
+0000271550 00000 n 
+0000274117 00000 n 
+0000277831 00000 n 
+0000277254 00000 n 
+0000274349 00000 n 
+0000277380 00000 n 
+0000277574 00000 n 
+0000277639 00000 n 
+0000281427 00000 n 
+0000280978 00000 n 
+0000277930 00000 n 
+0000281104 00000 n 
+0000281233 00000 n 
+0000662214 00000 n 
+0000286436 00000 n 
+0000285904 00000 n 
+0000281539 00000 n 
+0000286371 00000 n 
+0000286060 00000 n 
+0000286211 00000 n 
+0000290423 00000 n 
+0000289542 00000 n 
+0000286535 00000 n 
+0000289843 00000 n 
+0000289972 00000 n 
+0000290100 00000 n 
+0000289689 00000 n 
+0000290358 00000 n 
+0000292669 00000 n 
+0000292349 00000 n 
+0000290535 00000 n 
+0000292475 00000 n 
+0000294153 00000 n 
+0000293962 00000 n 
+0000292781 00000 n 
+0000294088 00000 n 
+0000295518 00000 n 
+0000295327 00000 n 
+0000294252 00000 n 
+0000295453 00000 n 
+0000299111 00000 n 
+0000298534 00000 n 
+0000295617 00000 n 
+0000298660 00000 n 
+0000298789 00000 n 
+0000298916 00000 n 
+0000298981 00000 n 
+0000299046 00000 n 
+0000662339 00000 n 
+0000304138 00000 n 
+0000302469 00000 n 
+0000299223 00000 n 
+0000303815 00000 n 
+0000302670 00000 n 
+0000303944 00000 n 
+0000304073 00000 n 
+0000302837 00000 n 
+0000302999 00000 n 
+0000303161 00000 n 
+0000303323 00000 n 
+0000303485 00000 n 
+0000303655 00000 n 
+0000468016 00000 n 
+0000309282 00000 n 
+0000307704 00000 n 
+0000304250 00000 n 
+0000309217 00000 n 
+0000307914 00000 n 
+0000308077 00000 n 
+0000308238 00000 n 
+0000308399 00000 n 
+0000308561 00000 n 
+0000308724 00000 n 
+0000308887 00000 n 
+0000309050 00000 n 
+0000315518 00000 n 
+0000312264 00000 n 
+0000309407 00000 n 
+0000315453 00000 n 
+0000312564 00000 n 
+0000312734 00000 n 
+0000312896 00000 n 
+0000313058 00000 n 
+0000313220 00000 n 
+0000313381 00000 n 
+0000313544 00000 n 
+0000313698 00000 n 
+0000313851 00000 n 
+0000314013 00000 n 
+0000314175 00000 n 
+0000314336 00000 n 
+0000314498 00000 n 
+0000314660 00000 n 
+0000314822 00000 n 
+0000314984 00000 n 
+0000315137 00000 n 
+0000315300 00000 n 
+0000319925 00000 n 
+0000319129 00000 n 
+0000315643 00000 n 
+0000319602 00000 n 
+0000319285 00000 n 
+0000319448 00000 n 
+0000319796 00000 n 
+0000319860 00000 n 
+0000324215 00000 n 
+0000323018 00000 n 
+0000320050 00000 n 
+0000323505 00000 n 
+0000323634 00000 n 
+0000323890 00000 n 
+0000323174 00000 n 
+0000323344 00000 n 
+0000323955 00000 n 
+0000324020 00000 n 
+0000324085 00000 n 
+0000324150 00000 n 
+0000327541 00000 n 
+0000327350 00000 n 
+0000324340 00000 n 
+0000327476 00000 n 
+0000662464 00000 n 
+0000331627 00000 n 
+0000331048 00000 n 
+0000327627 00000 n 
+0000331174 00000 n 
+0000331239 00000 n 
+0000331304 00000 n 
+0000331433 00000 n 
+0000331497 00000 n 
+0000331562 00000 n 
+0000335658 00000 n 
+0000334820 00000 n 
+0000331752 00000 n 
+0000334946 00000 n 
+0000335011 00000 n 
+0000335076 00000 n 
+0000335205 00000 n 
+0000335270 00000 n 
+0000335335 00000 n 
+0000335463 00000 n 
+0000335528 00000 n 
+0000335593 00000 n 
+0000339159 00000 n 
+0000338454 00000 n 
+0000335783 00000 n 
+0000338580 00000 n 
+0000338709 00000 n 
+0000338773 00000 n 
+0000338838 00000 n 
+0000338967 00000 n 
+0000339094 00000 n 
+0000342376 00000 n 
+0000341669 00000 n 
+0000339367 00000 n 
+0000341795 00000 n 
+0000341924 00000 n 
+0000342053 00000 n 
+0000342182 00000 n 
+0000342247 00000 n 
+0000342312 00000 n 
+0000346285 00000 n 
+0000345965 00000 n 
+0000342557 00000 n 
+0000346091 00000 n 
+0000348311 00000 n 
+0000347862 00000 n 
+0000346410 00000 n 
+0000347988 00000 n 
+0000348117 00000 n 
+0000348246 00000 n 
+0000662589 00000 n 
+0000352804 00000 n 
+0000351860 00000 n 
+0000348423 00000 n 
+0000352223 00000 n 
+0000479184 00000 n 
+0000469971 00000 n 
+0000478998 00000 n 
+0000352007 00000 n 
+0000352352 00000 n 
+0000352481 00000 n 
+0000352610 00000 n 
+0000353844 00000 n 
+0000353653 00000 n 
+0000353039 00000 n 
+0000353779 00000 n 
+0000354271 00000 n 
+0000354080 00000 n 
+0000353930 00000 n 
+0000354206 00000 n 
+0000357584 00000 n 
+0000356358 00000 n 
+0000354313 00000 n 
+0000356875 00000 n 
+0000357004 00000 n 
+0000357133 00000 n 
+0000357262 00000 n 
+0000357391 00000 n 
+0000357520 00000 n 
+0000356514 00000 n 
+0000356686 00000 n 
+0000358038 00000 n 
+0000357847 00000 n 
+0000357697 00000 n 
+0000357973 00000 n 
+0000361282 00000 n 
+0000360704 00000 n 
+0000358080 00000 n 
+0000360830 00000 n 
+0000360959 00000 n 
+0000361088 00000 n 
+0000361217 00000 n 
+0000662714 00000 n 
+0000365477 00000 n 
+0000364259 00000 n 
+0000361368 00000 n 
+0000364769 00000 n 
+0000364898 00000 n 
+0000365156 00000 n 
+0000364415 00000 n 
+0000364594 00000 n 
+0000365349 00000 n 
+0000365413 00000 n 
+0000372362 00000 n 
+0000368534 00000 n 
+0000365629 00000 n 
+0000368660 00000 n 
+0000368725 00000 n 
+0000368790 00000 n 
+0000368855 00000 n 
+0000368920 00000 n 
+0000368985 00000 n 
+0000369050 00000 n 
+0000369115 00000 n 
+0000369180 00000 n 
+0000369245 00000 n 
+0000369375 00000 n 
+0000369440 00000 n 
+0000369505 00000 n 
+0000369570 00000 n 
+0000369635 00000 n 
+0000369700 00000 n 
+0000369765 00000 n 
+0000369830 00000 n 
+0000369895 00000 n 
+0000369960 00000 n 
+0000370025 00000 n 
+0000370090 00000 n 
+0000370155 00000 n 
+0000370220 00000 n 
+0000370285 00000 n 
+0000370350 00000 n 
+0000370415 00000 n 
+0000370480 00000 n 
+0000370545 00000 n 
+0000370610 00000 n 
+0000370675 00000 n 
 0000370740 00000 n 
-0000370804 00000 n 
-0000370868 00000 n 
-0000370933 00000 n 
-0000370998 00000 n 
-0000371063 00000 n 
-0000371128 00000 n 
-0000371193 00000 n 
-0000371258 00000 n 
-0000371323 00000 n 
-0000371388 00000 n 
-0000371453 00000 n 
-0000371517 00000 n 
-0000377756 00000 n 
-0000374318 00000 n 
-0000371693 00000 n 
-0000374444 00000 n 
-0000374509 00000 n 
-0000374574 00000 n 
-0000374639 00000 n 
-0000374704 00000 n 
-0000374769 00000 n 
-0000374834 00000 n 
-0000374899 00000 n 
-0000374964 00000 n 
-0000375029 00000 n 
-0000375094 00000 n 
-0000375159 00000 n 
-0000375224 00000 n 
-0000375289 00000 n 
-0000375354 00000 n 
-0000375419 00000 n 
-0000375484 00000 n 
-0000375549 00000 n 
-0000375614 00000 n 
-0000375679 00000 n 
-0000375744 00000 n 
-0000375809 00000 n 
-0000375874 00000 n 
-0000375939 00000 n 
-0000376004 00000 n 
-0000376069 00000 n 
-0000376134 00000 n 
-0000376199 00000 n 
-0000376264 00000 n 
-0000376329 00000 n 
-0000376394 00000 n 
-0000376459 00000 n 
-0000376524 00000 n 
-0000376589 00000 n 
-0000376653 00000 n 
-0000376718 00000 n 
-0000376783 00000 n 
-0000376848 00000 n 
-0000376913 00000 n 
-0000376978 00000 n 
-0000377043 00000 n 
-0000377108 00000 n 
-0000377173 00000 n 
-0000377238 00000 n 
-0000377303 00000 n 
-0000377368 00000 n 
-0000377433 00000 n 
-0000377498 00000 n 
-0000377563 00000 n 
-0000377628 00000 n 
-0000377692 00000 n 
-0000382335 00000 n 
-0000380071 00000 n 
-0000377868 00000 n 
-0000380197 00000 n 
-0000380262 00000 n 
-0000380327 00000 n 
-0000380392 00000 n 
-0000380457 00000 n 
-0000380522 00000 n 
-0000380587 00000 n 
-0000380652 00000 n 
-0000380717 00000 n 
-0000380782 00000 n 
-0000380847 00000 n 
-0000380912 00000 n 
-0000380977 00000 n 
-0000381042 00000 n 
-0000381104 00000 n 
-0000381168 00000 n 
-0000381233 00000 n 
-0000381297 00000 n 
-0000381362 00000 n 
-0000381427 00000 n 
-0000381492 00000 n 
-0000381557 00000 n 
-0000381622 00000 n 
-0000381687 00000 n 
-0000381752 00000 n 
-0000381881 00000 n 
-0000382010 00000 n 
-0000382075 00000 n 
-0000382140 00000 n 
-0000382205 00000 n 
-0000382270 00000 n 
-0000385129 00000 n 
-0000384485 00000 n 
-0000382460 00000 n 
-0000384611 00000 n 
-0000384740 00000 n 
-0000384869 00000 n 
-0000384934 00000 n 
-0000384999 00000 n 
-0000385064 00000 n 
-0000655237 00000 n 
-0000389467 00000 n 
-0000389147 00000 n 
-0000385241 00000 n 
-0000389273 00000 n 
-0000389338 00000 n 
-0000389403 00000 n 
-0000392936 00000 n 
-0000392680 00000 n 
-0000389619 00000 n 
-0000392806 00000 n 
-0000392871 00000 n 
-0000396183 00000 n 
-0000395992 00000 n 
-0000393074 00000 n 
-0000396118 00000 n 
-0000399962 00000 n 
-0000399706 00000 n 
-0000396308 00000 n 
-0000399832 00000 n 
-0000399897 00000 n 
-0000403136 00000 n 
-0000402361 00000 n 
-0000400100 00000 n 
-0000402487 00000 n 
-0000402552 00000 n 
-0000402617 00000 n 
-0000402682 00000 n 
-0000402747 00000 n 
-0000402876 00000 n 
-0000402941 00000 n 
-0000403006 00000 n 
-0000403071 00000 n 
-0000407608 00000 n 
-0000407417 00000 n 
-0000403274 00000 n 
-0000407543 00000 n 
-0000655362 00000 n 
-0000410737 00000 n 
-0000409964 00000 n 
-0000407746 00000 n 
-0000410090 00000 n 
-0000410155 00000 n 
-0000410220 00000 n 
-0000410284 00000 n 
-0000410413 00000 n 
-0000410478 00000 n 
-0000410542 00000 n 
-0000410607 00000 n 
-0000410672 00000 n 
-0000414128 00000 n 
-0000413872 00000 n 
-0000410875 00000 n 
-0000413998 00000 n 
-0000414063 00000 n 
-0000416991 00000 n 
-0000416281 00000 n 
-0000414266 00000 n 
-0000416407 00000 n 
-0000416472 00000 n 
-0000416537 00000 n 
-0000416602 00000 n 
-0000416731 00000 n 
-0000416796 00000 n 
-0000416861 00000 n 
-0000416926 00000 n 
-0000420670 00000 n 
-0000420414 00000 n 
-0000417142 00000 n 
-0000420540 00000 n 
-0000420605 00000 n 
-0000424107 00000 n 
-0000423851 00000 n 
-0000420795 00000 n 
-0000423977 00000 n 
-0000424042 00000 n 
-0000426576 00000 n 
-0000425868 00000 n 
-0000424245 00000 n 
-0000425994 00000 n 
-0000426059 00000 n 
-0000426124 00000 n 
-0000426251 00000 n 
-0000426316 00000 n 
-0000426381 00000 n 
-0000426446 00000 n 
-0000426511 00000 n 
-0000655487 00000 n 
-0000429462 00000 n 
-0000428688 00000 n 
-0000426727 00000 n 
-0000428814 00000 n 
-0000428879 00000 n 
-0000428944 00000 n 
-0000429009 00000 n 
-0000429137 00000 n 
-0000429202 00000 n 
-0000429267 00000 n 
-0000429332 00000 n 
-0000429397 00000 n 
-0000432818 00000 n 
-0000432627 00000 n 
-0000429600 00000 n 
-0000432753 00000 n 
-0000435789 00000 n 
-0000435080 00000 n 
-0000432943 00000 n 
-0000435206 00000 n 
-0000435271 00000 n 
-0000435336 00000 n 
-0000435401 00000 n 
-0000435529 00000 n 
-0000435594 00000 n 
-0000435659 00000 n 
-0000435724 00000 n 
-0000439301 00000 n 
-0000439045 00000 n 
-0000435940 00000 n 
-0000439171 00000 n 
-0000439236 00000 n 
-0000442176 00000 n 
-0000441920 00000 n 
-0000439507 00000 n 
-0000442046 00000 n 
-0000442111 00000 n 
-0000445175 00000 n 
-0000444400 00000 n 
-0000442382 00000 n 
-0000444526 00000 n 
-0000444591 00000 n 
-0000444656 00000 n 
-0000444721 00000 n 
-0000444786 00000 n 
-0000444915 00000 n 
-0000444980 00000 n 
-0000445045 00000 n 
-0000445110 00000 n 
-0000655612 00000 n 
-0000448684 00000 n 
-0000448041 00000 n 
-0000445326 00000 n 
-0000448167 00000 n 
-0000448232 00000 n 
-0000448297 00000 n 
-0000448362 00000 n 
-0000448427 00000 n 
-0000448555 00000 n 
-0000448620 00000 n 
-0000452245 00000 n 
-0000451859 00000 n 
-0000448848 00000 n 
-0000451985 00000 n 
-0000452050 00000 n 
-0000452115 00000 n 
-0000452180 00000 n 
-0000454598 00000 n 
-0000454213 00000 n 
-0000452370 00000 n 
-0000454339 00000 n 
-0000454404 00000 n 
-0000454469 00000 n 
-0000454534 00000 n 
-0000458278 00000 n 
-0000457698 00000 n 
-0000454749 00000 n 
-0000457824 00000 n 
-0000457953 00000 n 
-0000458018 00000 n 
-0000458083 00000 n 
-0000458148 00000 n 
-0000458213 00000 n 
-0000460305 00000 n 
-0000459919 00000 n 
-0000458416 00000 n 
-0000460045 00000 n 
-0000460110 00000 n 
-0000460175 00000 n 
-0000460240 00000 n 
-0000460489 00000 n 
-0000471833 00000 n 
-0000474157 00000 n 
-0000474126 00000 n 
-0000483645 00000 n 
-0000493701 00000 n 
-0000504168 00000 n 
-0000516376 00000 n 
-0000534653 00000 n 
-0000556743 00000 n 
-0000577753 00000 n 
-0000595571 00000 n 
-0000598402 00000 n 
-0000598172 00000 n 
-0000625660 00000 n 
-0000652769 00000 n 
-0000655737 00000 n 
-0000655860 00000 n 
-0000655986 00000 n 
-0000656112 00000 n 
-0000656202 00000 n 
-0000656294 00000 n 
-0000671585 00000 n 
-0000688895 00000 n 
-0000688936 00000 n 
-0000688976 00000 n 
-0000689110 00000 n 
+0000370805 00000 n 
+0000370870 00000 n 
+0000370934 00000 n 
+0000370999 00000 n 
+0000371064 00000 n 
+0000371129 00000 n 
+0000371194 00000 n 
+0000371259 00000 n 
+0000371324 00000 n 
+0000371389 00000 n 
+0000371454 00000 n 
+0000371519 00000 n 
+0000371584 00000 n 
+0000371649 00000 n 
+0000371714 00000 n 
+0000371779 00000 n 
+0000371844 00000 n 
+0000371909 00000 n 
+0000371974 00000 n 
+0000372039 00000 n 
+0000372104 00000 n 
+0000372169 00000 n 
+0000372234 00000 n 
+0000372298 00000 n 
+0000379008 00000 n 
+0000375444 00000 n 
+0000372474 00000 n 
+0000375570 00000 n 
+0000375635 00000 n 
+0000375700 00000 n 
+0000375765 00000 n 
+0000375830 00000 n 
+0000375895 00000 n 
+0000375960 00000 n 
+0000376025 00000 n 
+0000376090 00000 n 
+0000376155 00000 n 
+0000376220 00000 n 
+0000376285 00000 n 
+0000376349 00000 n 
+0000376414 00000 n 
+0000376479 00000 n 
+0000376544 00000 n 
+0000376609 00000 n 
+0000376674 00000 n 
+0000376739 00000 n 
+0000376804 00000 n 
+0000376869 00000 n 
+0000376934 00000 n 
+0000376999 00000 n 
+0000377064 00000 n 
+0000377128 00000 n 
+0000377193 00000 n 
+0000377258 00000 n 
+0000377323 00000 n 
+0000377388 00000 n 
+0000377453 00000 n 
+0000377518 00000 n 
+0000377583 00000 n 
+0000377648 00000 n 
+0000377713 00000 n 
+0000377778 00000 n 
+0000377843 00000 n 
+0000377908 00000 n 
+0000377973 00000 n 
+0000378038 00000 n 
+0000378103 00000 n 
+0000378167 00000 n 
+0000378231 00000 n 
+0000378295 00000 n 
+0000378360 00000 n 
+0000378425 00000 n 
+0000378490 00000 n 
+0000378555 00000 n 
+0000378620 00000 n 
+0000378685 00000 n 
+0000378750 00000 n 
+0000378815 00000 n 
+0000378880 00000 n 
+0000378944 00000 n 
+0000385183 00000 n 
+0000381745 00000 n 
+0000379120 00000 n 
+0000381871 00000 n 
+0000381936 00000 n 
+0000382001 00000 n 
+0000382066 00000 n 
+0000382131 00000 n 
+0000382196 00000 n 
+0000382261 00000 n 
+0000382326 00000 n 
+0000382391 00000 n 
+0000382456 00000 n 
+0000382521 00000 n 
+0000382586 00000 n 
+0000382651 00000 n 
+0000382716 00000 n 
+0000382781 00000 n 
+0000382846 00000 n 
+0000382911 00000 n 
+0000382976 00000 n 
+0000383041 00000 n 
+0000383106 00000 n 
+0000383171 00000 n 
+0000383236 00000 n 
+0000383301 00000 n 
+0000383366 00000 n 
+0000383431 00000 n 
+0000383496 00000 n 
+0000383561 00000 n 
+0000383626 00000 n 
+0000383691 00000 n 
+0000383756 00000 n 
+0000383821 00000 n 
+0000383886 00000 n 
+0000383951 00000 n 
+0000384016 00000 n 
+0000384080 00000 n 
+0000384145 00000 n 
+0000384210 00000 n 
+0000384275 00000 n 
+0000384340 00000 n 
+0000384405 00000 n 
+0000384470 00000 n 
+0000384535 00000 n 
+0000384600 00000 n 
+0000384665 00000 n 
+0000384730 00000 n 
+0000384795 00000 n 
+0000384860 00000 n 
+0000384925 00000 n 
+0000384990 00000 n 
+0000385055 00000 n 
+0000385119 00000 n 
+0000389762 00000 n 
+0000387498 00000 n 
+0000385295 00000 n 
+0000387624 00000 n 
+0000387689 00000 n 
+0000387754 00000 n 
+0000387819 00000 n 
+0000387884 00000 n 
+0000387949 00000 n 
+0000388014 00000 n 
+0000388079 00000 n 
+0000388144 00000 n 
+0000388209 00000 n 
+0000388274 00000 n 
+0000388339 00000 n 
+0000388404 00000 n 
+0000388469 00000 n 
+0000388531 00000 n 
+0000388595 00000 n 
+0000388660 00000 n 
+0000388724 00000 n 
+0000388789 00000 n 
+0000388854 00000 n 
+0000388919 00000 n 
+0000388984 00000 n 
+0000389049 00000 n 
+0000389114 00000 n 
+0000389179 00000 n 
+0000389308 00000 n 
+0000389437 00000 n 
+0000389502 00000 n 
+0000389567 00000 n 
+0000389632 00000 n 
+0000389697 00000 n 
+0000392556 00000 n 
+0000391912 00000 n 
+0000389887 00000 n 
+0000392038 00000 n 
+0000392167 00000 n 
+0000392296 00000 n 
+0000392361 00000 n 
+0000392426 00000 n 
+0000392491 00000 n 
+0000662839 00000 n 
+0000396894 00000 n 
+0000396574 00000 n 
+0000392668 00000 n 
+0000396700 00000 n 
+0000396765 00000 n 
+0000396830 00000 n 
+0000400491 00000 n 
+0000400236 00000 n 
+0000397046 00000 n 
+0000400362 00000 n 
+0000400427 00000 n 
+0000403738 00000 n 
+0000403547 00000 n 
+0000400629 00000 n 
+0000403673 00000 n 
+0000407521 00000 n 
+0000407265 00000 n 
+0000403863 00000 n 
+0000407391 00000 n 
+0000407456 00000 n 
+0000410695 00000 n 
+0000409920 00000 n 
+0000407659 00000 n 
+0000410046 00000 n 
+0000410111 00000 n 
+0000410176 00000 n 
+0000410241 00000 n 
+0000410306 00000 n 
+0000410435 00000 n 
+0000410500 00000 n 
+0000410565 00000 n 
+0000410630 00000 n 
+0000415163 00000 n 
+0000414972 00000 n 
+0000410833 00000 n 
+0000415098 00000 n 
+0000662964 00000 n 
+0000418292 00000 n 
+0000417519 00000 n 
+0000415301 00000 n 
+0000417645 00000 n 
+0000417710 00000 n 
+0000417775 00000 n 
+0000417839 00000 n 
+0000417968 00000 n 
+0000418033 00000 n 
+0000418097 00000 n 
+0000418162 00000 n 
+0000418227 00000 n 
+0000421683 00000 n 
+0000421427 00000 n 
+0000418430 00000 n 
+0000421553 00000 n 
+0000421618 00000 n 
+0000424546 00000 n 
+0000423836 00000 n 
+0000421821 00000 n 
+0000423962 00000 n 
+0000424027 00000 n 
+0000424092 00000 n 
+0000424157 00000 n 
+0000424286 00000 n 
+0000424351 00000 n 
+0000424416 00000 n 
+0000424481 00000 n 
+0000428225 00000 n 
+0000427969 00000 n 
+0000424697 00000 n 
+0000428095 00000 n 
+0000428160 00000 n 
+0000431662 00000 n 
+0000431406 00000 n 
+0000428350 00000 n 
+0000431532 00000 n 
+0000431597 00000 n 
+0000434131 00000 n 
+0000433423 00000 n 
+0000431800 00000 n 
+0000433549 00000 n 
+0000433614 00000 n 
+0000433679 00000 n 
+0000433806 00000 n 
+0000433871 00000 n 
+0000433936 00000 n 
+0000434001 00000 n 
+0000434066 00000 n 
+0000663089 00000 n 
+0000437017 00000 n 
+0000436243 00000 n 
+0000434282 00000 n 
+0000436369 00000 n 
+0000436434 00000 n 
+0000436499 00000 n 
+0000436564 00000 n 
+0000436692 00000 n 
+0000436757 00000 n 
+0000436822 00000 n 
+0000436887 00000 n 
+0000436952 00000 n 
+0000440374 00000 n 
+0000440183 00000 n 
+0000437155 00000 n 
+0000440309 00000 n 
+0000443345 00000 n 
+0000442636 00000 n 
+0000440499 00000 n 
+0000442762 00000 n 
+0000442827 00000 n 
+0000442892 00000 n 
+0000442957 00000 n 
+0000443085 00000 n 
+0000443150 00000 n 
+0000443215 00000 n 
+0000443280 00000 n 
+0000446857 00000 n 
+0000446601 00000 n 
+0000443496 00000 n 
+0000446727 00000 n 
+0000446792 00000 n 
+0000449734 00000 n 
+0000449478 00000 n 
+0000447065 00000 n 
+0000449604 00000 n 
+0000449669 00000 n 
+0000452735 00000 n 
+0000451960 00000 n 
+0000449942 00000 n 
+0000452086 00000 n 
+0000452151 00000 n 
+0000452216 00000 n 
+0000452281 00000 n 
+0000452346 00000 n 
+0000452475 00000 n 
+0000452540 00000 n 
+0000452605 00000 n 
+0000452670 00000 n 
+0000663214 00000 n 
+0000456244 00000 n 
+0000455601 00000 n 
+0000452886 00000 n 
+0000455727 00000 n 
+0000455792 00000 n 
+0000455857 00000 n 
+0000455922 00000 n 
+0000455987 00000 n 
+0000456115 00000 n 
+0000456180 00000 n 
+0000459805 00000 n 
+0000459419 00000 n 
+0000456408 00000 n 
+0000459545 00000 n 
+0000459610 00000 n 
+0000459675 00000 n 
+0000459740 00000 n 
+0000462158 00000 n 
+0000461773 00000 n 
+0000459930 00000 n 
+0000461899 00000 n 
+0000461964 00000 n 
+0000462029 00000 n 
+0000462094 00000 n 
+0000465838 00000 n 
+0000465258 00000 n 
+0000462309 00000 n 
+0000465384 00000 n 
+0000465513 00000 n 
+0000465578 00000 n 
+0000465643 00000 n 
+0000465708 00000 n 
+0000465773 00000 n 
+0000467865 00000 n 
+0000467479 00000 n 
+0000465976 00000 n 
+0000467605 00000 n 
+0000467670 00000 n 
+0000467735 00000 n 
+0000467800 00000 n 
+0000468082 00000 n 
+0000479426 00000 n 
+0000481751 00000 n 
+0000481720 00000 n 
+0000491245 00000 n 
+0000501302 00000 n 
+0000511771 00000 n 
+0000523978 00000 n 
+0000542255 00000 n 
+0000564344 00000 n 
+0000585354 00000 n 
+0000603172 00000 n 
+0000606004 00000 n 
+0000605774 00000 n 
+0000633262 00000 n 
+0000660371 00000 n 
+0000663339 00000 n 
+0000663462 00000 n 
+0000663588 00000 n 
+0000663714 00000 n 
+0000663804 00000 n 
+0000663896 00000 n 
+0000679280 00000 n 
+0000696733 00000 n 
+0000696774 00000 n 
+0000696814 00000 n 
+0000696948 00000 n 
 trailer
 <<
-/Size 1957
-/Root 1955 0 R
-/Info 1956 0 R
-/ID [ ]
+/Size 1969
+/Root 1967 0 R
+/Info 1968 0 R
+/ID [ ]
 >>
 startxref
-689368
+697206
 %%EOF
diff --git a/doc/arm/Makefile.in b/doc/arm/Makefile.in
index 85f318d61acf..b98171228fe2 100644
--- a/doc/arm/Makefile.in
+++ b/doc/arm/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001, 2002  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.12.18.8 2007/08/28 07:20:03 tbox Exp $
+# $Id: Makefile.in,v 1.12.18.10 2009/02/12 23:46:03 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -44,6 +44,10 @@ Bv9ARM.html: Bv9ARM-book.xml releaseinfo.xml
 	${XSLTPROC} --stringparam root.filename Bv9ARM \
 		${top_srcdir}/doc/xsl/isc-docbook-chunk.xsl -
 
+Bv9ARM-all.html: Bv9ARM-book.xml releaseinfo.xml
+	expand Bv9ARM-book.xml | \
+	${XSLTPROC} -o Bv9ARM-all.html ../xsl/isc-docbook-html.xsl -
+
 Bv9ARM.tex: Bv9ARM-book.xml releaseinfo.xml
 	expand Bv9ARM-book.xml | \
 	${XSLTPROC} ${top_srcdir}/doc/xsl/pre-latex.xsl - | \
diff --git a/doc/arm/man.dig.html b/doc/arm/man.dig.html
index e6aa96d26227..fed552ef07b8 100644
--- a/doc/arm/man.dig.html
+++ b/doc/arm/man.dig.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -52,7 +52,7 @@
 
dig  [global-queryopt...] [query...]

 
 

-
DESCRIPTION

+
DESCRIPTION

 
dig
       (domain information groper) is a flexible tool
       for interrogating DNS name servers.  It performs DNS lookups and
@@ -98,7 +98,7 @@
     

 

 

-
SIMPLE USAGE

+
SIMPLE USAGE

 

       A typical invocation of dig looks like:
       

@@ -144,7 +144,7 @@
     

 

 

-
OPTIONS

+
OPTIONS

 

       The -b option sets the source IP address of the query
       to address.  This must be a valid
@@ -248,7 +248,7 @@
     

 

 

-
QUERY OPTIONS

+
QUERY OPTIONS

 
dig
       provides a number of query options which affect
       the way in which lookups are made and the results displayed.  Some of
@@ -326,13 +326,15 @@
             

 
+[no]adflag

 

-              Set [do not set] the AD (authentic data) bit in the query.  The
-              AD bit
-              currently has a standard meaning only in responses, not in
-              queries,
-              but the ability to set the bit in the query is provided for
-              completeness.
-            

+	      Set [do not set] the AD (authentic data) bit in the
+	      query.  This requests the server to return whether
+	      all of the answer and authority sections have all
+	      been validated as secure according to the security
+	      policy of the server.  AD=1 indicates that all records
+	      have been validated as secure and the answer is not
+	      from a OPT-OUT range.  AD=0 indicate that some part
+	      of the answer was insecure or not validated.
+	    

 
+[no]cdflag

 

               Set [do not set] the CD (checking disabled) bit in the query.
@@ -547,7 +549,7 @@
 	      on its own line.
             

 

-	      If not specified dig will look for
+	      If not specified, dig will look for
 	      /etc/trusted-key.key then
 	      trusted-key.key in the current directory.
 	    

@@ -567,7 +569,7 @@
     

 

 

-
MULTIPLE QUERIES

+
MULTIPLE QUERIES

 

       The BIND 9 implementation of dig 
       supports
@@ -613,7 +615,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     

 

 

-
IDN SUPPORT

+
IDN SUPPORT

 

       If dig has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names.
@@ -627,14 +629,14 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     

 

 

-
FILES

+
FILES

 
/etc/resolv.conf
     

 
${HOME}/.digrc
     

 

 

-
SEE ALSO

+
SEE ALSO

 
host(1),
       named(8),
       dnssec-keygen(8),
@@ -642,7 +644,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     

 

 

-
BUGS

+
BUGS

 

       There are probably too many query options.
     

diff --git a/doc/arm/man.dnssec-keygen.html b/doc/arm/man.dnssec-keygen.html
index ac3fbe8be9ec..67fb5a6af50f 100644
--- a/doc/arm/man.dnssec-keygen.html
+++ b/doc/arm/man.dnssec-keygen.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -50,7 +50,7 @@
 
dnssec-keygen  {-a algorithm} {-b keysize} {-n nametype} [-c class] [-e] [-f flag] [-g generator] [-h] [-k] [-p protocol] [-r randomdev] [-s strength] [-t type] [-v level] {name}

 

 

-
DESCRIPTION

+
DESCRIPTION

 
dnssec-keygen
       generates keys for DNSSEC (Secure DNS), as defined in RFC 2535
       and RFC 4034.  It can also generate keys for use with
@@ -58,7 +58,7 @@
     

 

 

-
OPTIONS

+
OPTIONS

 

 
-a algorithm

 

@@ -166,7 +166,7 @@
 

 

 

-
GENERATED KEYS

+
GENERATED KEYS

 

       When dnssec-keygen completes
       successfully,
@@ -212,7 +212,7 @@
     

 

 

-
EXAMPLE

+
EXAMPLE

 

       To generate a 768-bit DSA key for the domain
       example.com, the following command would be
@@ -233,7 +233,7 @@
     

 

 

-
SEE ALSO

+
SEE ALSO

 
dnssec-signzone(8),
       BIND 9 Administrator Reference Manual,
       RFC 2539,
@@ -242,7 +242,7 @@
     

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

diff --git a/doc/arm/man.dnssec-signzone.html b/doc/arm/man.dnssec-signzone.html
index a12d3551e3f4..a48072d31690 100644
--- a/doc/arm/man.dnssec-signzone.html
+++ b/doc/arm/man.dnssec-signzone.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -50,7 +50,7 @@
 
dnssec-signzone  [-a] [-c class] [-d directory] [-e end-time] [-f output-file] [-g] [-h] [-k key] [-l domain] [-i interval] [-I input-format] [-j jitter] [-N soa-serial-format] [-o origin] [-O output-format] [-p] [-r randomdev] [-s start-time] [-t] [-v level] [-z] {zonefile} [key...]

 
 

-
DESCRIPTION

+
DESCRIPTION

 
dnssec-signzone
       signs a zone.  It generates
       NSEC and RRSIG records and produces a signed version of the
@@ -61,7 +61,7 @@
     

 

 

-
OPTIONS

+
OPTIONS

 

 
-a

 

@@ -259,7 +259,7 @@
 

 

 

-
EXAMPLE

+
EXAMPLE

 

       The following command signs the example.com
       zone with the DSA key generated by dnssec-keygen
@@ -288,14 +288,14 @@ db.example.com.signed
 %
 

 

-
SEE ALSO

+
SEE ALSO

 
dnssec-keygen(8),
       BIND 9 Administrator Reference Manual,
       RFC 4033.
     

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

diff --git a/doc/arm/man.host.html b/doc/arm/man.host.html
index f180544a3f0a..cf281efa2c71 100644
--- a/doc/arm/man.host.html
+++ b/doc/arm/man.host.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -50,7 +50,7 @@
 
host  [-aCdlnrsTwv] [-c class] [-N ndots] [-R number] [-t type] [-W wait] [-m flag] [-4] [-6] {name} [server]

 
 

-
DESCRIPTION

+
DESCRIPTION

 
host
       is a simple utility for performing DNS lookups.
       It is normally used to convert names to IP addresses and vice versa.
@@ -148,7 +148,7 @@
       referrals to other name servers.
     

 

-      By default host uses UDP when making
+      By default, host uses UDP when making
       queries.  The
       -T option makes it use a TCP connection when querying
       the name server.  TCP will be automatically selected for queries that
@@ -166,7 +166,7 @@
       NS, SOA, SIG, KEY, AXFR, etc.  When no query type is specified,
       host automatically selects an appropriate
       query
-      type.  By default it looks for A, AAAA, and MX records, but if the
+      type.  By default, it looks for A, AAAA, and MX records, but if the
       -C option was given, queries will be made for SOA
       records, and if name is a
       dotted-decimal IPv4
@@ -202,7 +202,7 @@
     

 

 

-
IDN SUPPORT

+
IDN SUPPORT

 

       If host has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names. 
@@ -216,12 +216,12 @@
     

 

 

-
FILES

+
FILES

 
/etc/resolv.conf
     

 

 

-
SEE ALSO

+
SEE ALSO

 
dig(1),
       named(8).
     

diff --git a/doc/arm/man.named-checkconf.html b/doc/arm/man.named-checkconf.html
index 3d5cdd233c66..d3e8893d7e0c 100644
--- a/doc/arm/man.named-checkconf.html
+++ b/doc/arm/man.named-checkconf.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -50,14 +50,14 @@
 
named-checkconf  [-v] [-j] [-t directory] {filename} [-z]

 

 

-
DESCRIPTION

+
DESCRIPTION

 
named-checkconf
       checks the syntax, but not the semantics, of a named
       configuration file.
     

 

 

-
OPTIONS

+
OPTIONS

 

 
-t directory

 

@@ -88,21 +88,21 @@
 

 

 

-
RETURN VALUES

+
RETURN VALUES

 
named-checkconf
       returns an exit status of 1 if
       errors were detected and 0 otherwise.
     

 

 

-
SEE ALSO

+
SEE ALSO

 
named(8),
       named-checkzone(8),
       BIND 9 Administrator Reference Manual.
     

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

diff --git a/doc/arm/man.named-checkzone.html b/doc/arm/man.named-checkzone.html
index 264e960696d6..1c8748157e75 100644
--- a/doc/arm/man.named-checkzone.html
+++ b/doc/arm/man.named-checkzone.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -51,7 +51,7 @@
 
named-compilezone  [-d] [-j] [-q] [-v] [-c class] [-C mode] [-f format] [-F format] [-i mode] [-k mode] [-m mode] [-n mode] [-o filename] [-s style] [-t directory] [-w directory] [-D] [-W mode] {zonename} {filename}

 
 

-
DESCRIPTION

+
DESCRIPTION

 
named-checkzone
       checks the syntax and integrity of a zone file.  It performs the
       same checks as named does when loading a
@@ -71,7 +71,7 @@
      

 

 

-
OPTIONS

+
OPTIONS

 

 
-d

 

@@ -92,7 +92,7 @@
           

 
-c class

 

-            Specify the class of the zone.  If not specified "IN" is assumed.
+            Specify the class of the zone.  If not specified, "IN" is assumed.
           

 
-i mode

 

@@ -251,14 +251,14 @@
 

 

 

-
RETURN VALUES

+
RETURN VALUES

 
named-checkzone
       returns an exit status of 1 if
       errors were detected and 0 otherwise.
     

 

 

-
SEE ALSO

+
SEE ALSO

 
named(8),
       named-checkconf(8),
       RFC 1035,
@@ -266,7 +266,7 @@
     

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

diff --git a/doc/arm/man.named.html b/doc/arm/man.named.html
index b08e7383820b..8f7c217bf2c0 100644
--- a/doc/arm/man.named.html
+++ b/doc/arm/man.named.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -50,7 +50,7 @@
 
named  [-4] [-6] [-c config-file] [-d debug-level] [-f] [-g] [-m flag] [-n #cpus] [-p port] [-s] [-S #max-socks] [-t directory] [-u user] [-v] [-x cache-file]

 
 

-
DESCRIPTION

+
DESCRIPTION

 
named
       is a Domain Name System (DNS) server,
       part of the BIND 9 distribution from ISC.  For more
@@ -65,7 +65,7 @@
     

 

 

-
OPTIONS

+
OPTIONS

 

 
-4

 

@@ -234,7 +234,7 @@
 

 

 

-
SIGNALS

+
SIGNALS

 

       In routine operation, signals should not be used to control
       the nameserver; rndc should be used
@@ -255,7 +255,7 @@
     

 

 

-
CONFIGURATION

+
CONFIGURATION

 

       The named configuration file is too complex
       to describe in detail here.  A complete description is provided
@@ -264,7 +264,7 @@
     

 

 

-
FILES

+
FILES

 

 
/etc/named.conf

 

@@ -277,7 +277,7 @@
 

 

 

-
SEE ALSO

+
SEE ALSO

 
RFC 1033,
       RFC 1034,
       RFC 1035,
@@ -290,7 +290,7 @@
     

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

diff --git a/doc/arm/man.rndc-confgen.html b/doc/arm/man.rndc-confgen.html
index fa5924db3e86..ef2ef7953570 100644
--- a/doc/arm/man.rndc-confgen.html
+++ b/doc/arm/man.rndc-confgen.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -48,7 +48,7 @@
 
rndc-confgen  [-a] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-r randomfile] [-s address] [-t chrootdir] [-u user]

 
 

-
DESCRIPTION

+
DESCRIPTION

 
rndc-confgen
       generates configuration files
       for rndc.  It can be used as a
@@ -64,7 +64,7 @@
     

 

 

-
OPTIONS

+
OPTIONS

 

 
-a

 

@@ -171,7 +171,7 @@
 

 

 

-
EXAMPLES

+
EXAMPLES

 

       To allow rndc to be used with
       no manual configuration, run
@@ -188,7 +188,7 @@
     

 

 

-
SEE ALSO

+
SEE ALSO

 
rndc(8),
       rndc.conf(5),
       named(8),
@@ -196,7 +196,7 @@
     

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

diff --git a/doc/arm/man.rndc.conf.html b/doc/arm/man.rndc.conf.html
index 47a5d9d83c26..a43638ad03f8 100644
--- a/doc/arm/man.rndc.conf.html
+++ b/doc/arm/man.rndc.conf.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -50,7 +50,7 @@
 
rndc.conf 

 
 

-
DESCRIPTION

+
DESCRIPTION

 
rndc.conf is the configuration file
       for rndc, the BIND 9 name server control
       utility.  This file has a similar structure and syntax to
@@ -135,7 +135,7 @@
     

 

 

-
EXAMPLE

+
EXAMPLE

 
       options {
         default-server  localhost;
@@ -209,7 +209,7 @@
     

 

 

-
NAME SERVER CONFIGURATION

+
NAME SERVER CONFIGURATION

 

       The name server must be configured to accept rndc connections and
       to recognize the key specified in the rndc.conf
@@ -219,7 +219,7 @@
     

 

 

-
SEE ALSO

+
SEE ALSO

 
rndc(8),
       rndc-confgen(8),
       mmencode(1),
@@ -227,7 +227,7 @@
     

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

diff --git a/doc/arm/man.rndc.html b/doc/arm/man.rndc.html
index 351267be0825..ea9afacd40b5 100644
--- a/doc/arm/man.rndc.html
+++ b/doc/arm/man.rndc.html
@@ -1,8 +1,8 @@
 
-
+
 
 
 
@@ -50,7 +50,7 @@
 
rndc  [-b source-address] [-c config-file] [-k key-file] [-s server] [-p port] [-V] [-y key_id] {command}

 
 

-
DESCRIPTION

+
DESCRIPTION

 
rndc
       controls the operation of a name
       server.  It supersedes the ndc utility
@@ -79,7 +79,7 @@
     

 

 

-
OPTIONS

+
OPTIONS

 

 
-b source-address

 

@@ -151,7 +151,7 @@
     

 

 

-
LIMITATIONS

+
LIMITATIONS

 
rndc
       does not yet support all the commands of
       the BIND 8 ndc utility.
@@ -165,7 +165,7 @@
     

 

 

-
SEE ALSO

+
SEE ALSO

 
rndc.conf(5),
       rndc-confgen(8),
       named(8),
@@ -175,7 +175,7 @@
     

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
deleted file mode 100644
index 1030e5782ef9..000000000000
--- a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-
-Internet-Draft                                                   T. Baba
-Expires: March 11, 2004                                         NTT Data
-                                                      September 11, 2003
-
-
-         Requirements for Access Control in Domain Name Systems
-                   draft-baba-dnsext-acl-reqts-01.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   Distribution of this memo is unlimited.
-
-   This Internet-Draft will expire on March 11, 2004.
-
-Abstract
-
-   This document describes the requirements for access control
-   mechanisms in the Domain Name System (DNS), which authenticate
-   clients and then allow or deny access to resource records in the
-   zone according to the access control list (ACL).
-
-1. Introduction
-
-   The Domain Name System (DNS) is a hierarchical, distributed, highly
-   available database used for bi-directional mapping between domain
-   names and IP addresses, for email routing, and for other information
-   [RFC1034, 1035].  DNS security extensions (DNSSEC) have been defined
-   to authenticate the data in DNS and provide key distribution services
-   using SIG, KEY, and NXT resource records (RRs) [RFC2535].
-
-
-
-Baba                     Expires March 11, 2004                 [Page 1]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-   At the 28th IETF Meeting in Houston in 1993, DNS security design team
-   started a discussion about DNSSEC and agreed to accept the assumption
-   that "DNS data is public".  Accordingly, confidentiality for queries
-   or responses is not provided by DNSSEC, nor are any sort of access
-   control lists or other means to differentiate inquirers.  However,
-   about ten years has passed, access control in DNS has been more
-   important than before.  Currently, new RRs are proposed to add new
-   functionality to DNS such as ENUM [RFC2916].  Such new RRs may
-   contain private information.  Thus, DNS access control will be
-   needed.
-
-   Furthermore, with DNS access control mechanism, access from
-   unauthorized clients can be blocked when they perform DNS name
-   resolution.  Thus, for example, Denial of Service (DoS) attacks
-   against a server used by a closed user group can be prevented using
-   this mechanism if IP address of the server is not revealed by other
-   sources.
-
-   This document describes the requirements for access control
-   mechanisms in DNS.
-
-2. Terminology
-
-   AC-aware client
-      This is the client that understands the DNS access control
-      extensions. This client may be an end host which has a stub
-      resolver, or a cashing/recursive name server which has a
-      full-service resolver.
-
-   AC-aware server
-      This is the authoritative name server that understands the DNS
-      access control extensions.
-
-   ACE
-      An Access Control Entry.  This is the smallest unit of access
-      control policy.  It grants or denies a given set of access
-      rights to a set of principals.  An ACE is a component of an ACL,
-      which is associated with a resource.
-
-   ACL
-      An Access Control List.  This contains all of the access control
-      policies which are directly associated with a particular
-      resource.  These policies are expressed as ACEs.
-
-   Client
-      A program or host which issues DNS requests and accepts its
-      responses. A client may be an end host or a cashing/recursive name
-      server.
-
-
-
-Baba                     Expires March 11, 2004                 [Page 2]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-   RRset
-      All resource records (RRs) having the same NAME, CLASS and TYPE
-      are called a Resource Record Set (RRset).
-
-3. Requirements
-
-   This section describes the requirements for access control in DNS.
-
-3.1 Authentication
-
-3.1.1 Client Authentication Mechanism
-
-   The AC-aware server must identify AC-aware clients based on IP
-   address and/or domain name (user ID or host name), and must
-   authenticate them using strong authentication mechanism such as
-   digital signature or message authentication code (MAC).
-
-   SIG(0) RR [RFC2931] contains a domain name associated with sender's
-   public key in its signer's name field, and TSIG RR [RFC2845] also
-   contains a domain name associated with shared secret key in its key
-   name field.  Each of these domain names can be a host name or a user
-   name, and can be used as a sender's identifier for access control.
-   Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
-   message authentication.  These mechanisms can be used to authenticate
-   AC-aware clients.
-
-   Server authentication may be also provided.
-
-3.1.2 End-to-End Authentication
-
-   In current DNS model, caching/recursive name servers are deployed
-   between end hosts and authoritative name servers.  Although
-   authoritative servers can authenticate caching/recursive name servers
-   using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
-   For end-to-end authentication, the mechanism for an end host to
-   discover the target authoritative name server and directly access to
-   it bypassing caching/recursive name servers is needed.  For example,
-   an end host can get the IP addresses of the authoritative name
-   servers by retrieving NS RRs for the zone via local caching/recursive
-   name server.
-
-   In many enterprise networks, however, there are firewalls that block
-   all DNS packets other than those going to/from the particular
-   caching/recursive servers.  To deal with this problem, one can
-   implement packet forwarding function on the caching/recursive servers
-   and enable end-to-end authentication via the caching/recursive
-   servers.
-
-
-
-
-Baba                     Expires March 11, 2004                 [Page 3]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-3.1.3 Authentication Key Retrieval
-
-   Keys which are used to authenticate clients should be able to be
-   automatically retrieved.  The KEY RR is used to store a public key
-   for a zone or a host that is associated with a domain name.  SIG(0)
-   RR uses a public key in KEY RR for verifying the signature.  If
-   DNSSEC is available, the KEY RR would be protected by the SIG RR.
-   KEY RR or newly defined RR can be used to automatic key retrieval.
-
-3.2 Confidentiality
-
-3.2.1 Data Encryption
-
-   To avoid disclosure to eavesdroppers, the response containing the
-   RRsets which are restricted to access from particular users should be
-   encrypted.  Currently, no encryption mechanism is specified in DNS.
-   Therefore, new RRs should be defined for DNS message encryption.
-   Instead, IPsec [RFC2401] can be used to provide confidentiality if
-   name server and resolver can set up security associations dynamically
-   using IPsec API [IPSECAPI] when encryption is required.
-
-   In case encryption is applied, entire DNS message including DNS
-   header should be encrypted to hide information including error code.
-
-   Query encryption may be also provided for hiding query information.
-
-3.2.2 Key Exchange
-
-   If DNS message encryption is provided, automatic key exchange
-   mechanism should be also provided.  [RFC2930] specifies a TKEY RR
-   that can be used to establish and delete shared secret keys used by
-   TSIG between a client and a server.  With minor extensions, TKEY can
-   be used to establish shared secret keys used for message encryption.
-
-3.2.3 Caching
-
-   The RRset that is restricted to access from particular users must not
-   be cached.  To avoid caching, the TTL of the RR that is restricted to
-   access should be set to zero during transit.
-
-3.3 Access Control
-
-3.3.1 Granularity of Access Control
-
-   Control of access on a per-user/per-host granularity must be
-   supported.  Control of access to individual RRset (not just the
-   entire zone) must be also supported.  However, SOA, NS, SIG, NXT,
-   KEY, and DS RRs must be publicly accessible to avoid unexpected
-   results.
-   
-
-Baba                     Expires March 11, 2004                 [Page 4]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-3.3.2 ACL Representation
-
-   Access Control List (ACL) format must be standardized so that both
-   the primary and secondary AC-aware servers can recognize the same
-   ACL.  Although ACL may appear in or out of zone data, it must be
-   transferred to the secondary AC-aware server with associated zone
-   data.  It is a good idea to contain ACL in zone data, because ACL can
-   be transferred with zone data using existing zone transfer mechanisms
-   automatically.  However, ACL must not be published except for
-   authorized secondary master servers.
-   
-   In zone data master files, ACL should be specified using TXT RRs or
-   newly defined RRs.  In each access control entry (ACE), authorized
-   entities (host or user) must be described using domain name (host
-   name, user name, or IP address in in-addr.arpa/ip6.arpa format).
-   There may be other access control attributes such as access time.
-
-   It must be possible to create publicly readable entries, which may be
-   read even by unauthenticated clients.
-
-3.3.3 Zone/ACL Transfer
-
-   As mentioned above, ACL should be transferred from a primary AC-aware
-   server to a secondary AC-aware server with associated zone data.
-   When an AC-aware server receives a zone/ACL transfer request, the
-   server must authenticate the client, and should encrypt the zone
-   data and associated ACL during transfer.
-
-3.4 Backward/co-existence Compatibility
-
-   Any new protocols to be defined for access control in DNS must be
-   backward compatible with existing DNS protocol.  AC-aware servers
-   must be able to process normal DNS query without authentication, and
-   must respond if retrieving RRset is publicly accessible.
-   
-   Modifications to root/gTLD/ccTLD name servers are not allowed.
-
-4. Security Considerations
-
-   This document discusses the requirements for access control
-   mechanisms in DNS.
-
-5. Acknowledgements
-
-   This work is funded by the Telecommunications Advancement
-   Organization of Japan (TAO).
-
-   The author would like to thank the members of the NTT DATA network
-   security team for their important contribution to this work.
-
-
-Baba                     Expires March 11, 2004                 [Page 5]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-6. References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
-              Internet Protocol", RFC 2401, November 1998.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-              "Secret Key Transaction Authentication for DNS (TSIG)", 
-              RFC 2845, May 2000.
-
-   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
-              September 2000.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
-              RFC 2930, September 2000.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s)", RFC 2931, September 2000.
-
-   [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
-              draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
-              Progress.
-
-
-Author's Address
-
-   Tatsuya Baba
-   NTT Data Corporation
-   Research and Development Headquarters
-   Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
-   Tokyo 104-0033, Japan
-   
-   Tel: +81 3 3523 8081
-   Fax: +81 3 3523 8090
-   Email: babatt@nttdata.co.jp
-
-
-
-
-
-
-
-
-Baba                     Expires March 11, 2004                 [Page 6]
diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt
deleted file mode 100644
index fffa8a5f20b3..000000000000
--- a/doc/draft/draft-daigle-napstr-04.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-Network Working Group                                          L. Daigle
-Internet-Draft                                                 A. Newton
-Expires: August 15, 2004                                  VeriSign, Inc.
-                                                       February 15, 2004
-
-
-    Domain-based Application Service Location Using SRV RRs and the
-              Dynamic Delegation Discovery Service (DDDS)
-                       draft-daigle-napstr-04.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 15, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This memo defines a generalized mechanism for application service
-   naming that allows service location without relying on rigid domain
-   naming conventions (so-called name hacks).  The proposal defines a
-   Dynamic Delegation Discovery System (DDDS) Application to map domain
-   name, application service name, and application protocol to target
-   server and port, dynamically.
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 1]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.    Straightforward-NAPTR (S-NAPTR) Specification  . . . . . . .  4
-   2.1   Key Terms  . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.2   S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . .  5
-   2.2.1 Ordering and Preference  . . . . . . . . . . . . . . . . . .  5
-   2.2.2 Matching and non-Matching NAPTR Records  . . . . . . . . . .  5
-   2.2.3 Terminal and Non-Terminal NAPTR Records  . . . . . . . . . .  5
-   2.2.4 S-NAPTR and Successive Resolution  . . . . . . . . . . . . .  6
-   2.2.5 Clients Supporting Multiple Protocols  . . . . . . . . . . .  6
-   3.    Guidelines . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   3.1   Guidelines for Application Protocol Developers . . . . . . .  7
-   3.1.1 Registration of application service and protocol tags  . . .  7
-   3.1.2 Definition of conditions for retry/failure . . . . . . . . .  8
-   3.1.3 Server identification and handshake  . . . . . . . . . . . .  8
-   3.2   Guidelines for Domain Administrators . . . . . . . . . . . .  8
-   3.3   Guidelines for Client Software Writers . . . . . . . . . . .  9
-   4.    Illustrations  . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.1   Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.2   Service Discovery within a Domain  . . . . . . . . . . . . . 10
-   4.3   Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
-   4.4   Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
-   4.5   Sets of NAPTR RRs  . . . . . . . . . . . . . . . . . . . . . 12
-   4.6   Sample sequence diagram  . . . . . . . . . . . . . . . . . . 12
-   5.    Motivation and Discussion  . . . . . . . . . . . . . . . . . 14
-   5.1   So, why not just SRV records?  . . . . . . . . . . . . . . . 15
-   5.2   So, why not just NAPTR records?  . . . . . . . . . . . . . . 15
-   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
-   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
-   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
-         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
-         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
-   A.    Application Service Location Application of DDDS . . . . . . 18
-   A.1   Application Unique String  . . . . . . . . . . . . . . . . . 18
-   A.2   First Well Known Rule  . . . . . . . . . . . . . . . . . . . 18
-   A.3   Expected Output  . . . . . . . . . . . . . . . . . . . . . . 18
-   A.4   Flags  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
-   A.5   Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
-   A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
-   A.5.2 Application Protocols  . . . . . . . . . . . . . . . . . . . 20
-   A.6   Valid Rules  . . . . . . . . . . . . . . . . . . . . . . . . 20
-   A.7   Valid Databases  . . . . . . . . . . . . . . . . . . . . . . 20
-   B.    Pseudo pseudocode for S-NAPTR  . . . . . . . . . . . . . . . 20
-   B.1   Finding the first (best) target  . . . . . . . . . . . . . . 20
-   B.2   Finding subsequent targets . . . . . . . . . . . . . . . . . 21
-         Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 2]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-1. Introduction
-
-   This memo defines a generalized mechanism for application service
-   naming that allows service location without relying on rigid domain
-   naming conventions (so-called name hacks).  The proposal defines a
-   Dynamic Delegation Discovery System (DDDS -- see [6]) Application to
-   map domain name, application service name, and application protocol
-   to target server and port, dynamically.
-
-   As discussed in Section 5, existing approaches to using DNS records
-   to dynamically determining the current host for a given application
-   service are limited in terms of the use cases supported.  To address
-   some of the limitations, this document defines a DDDS Application to
-   map service+protocol+domain to specific server addresses using both
-   NAPTR [7] and SRV ([5]) DNS resource records.  This can be viewed as
-   a more general version of the use of SRV and/or a very restricted
-   application of the use of NAPTR resource records.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC2119 ([2]).
-
-2. Straightforward-NAPTR (S-NAPTR) Specification
-
-   The precise details of the specification of this DDDS application are
-   given in Appendix A.  This section defines the usage of the DDDS
-   application.
-
-2.1 Key Terms
-
-   An "application service" is a generic term for some type of
-   application, indpendent of the protocol that may be used to offer it.
-   Each application service will be associated with an IANA-registered
-   tag.  For example, instant messaging is a type of application
-   service, which can be implemented by many different application-layer
-   protocols, and the tag "IM" (used as an illustration here) could be
-   registered for it.
-
-   An "application protocol" is used to implement the application
-   service.  These are also associated with IANA-registered tags.  In
-   the case where multiple transports are available for the application,
-   separate tags should be defined for each transport.
-
-   The intention is that the combination of application service and
-   protocol tags should be specific enough that finding a known pair
-   (e.g., "IM:ProtC") is sufficient for a client to identify a server
-   with which it can communicate.
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 3]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   Some protocols support multiple application services.  For example,
-   LDAP is an application protocol, and can be found supporting various
-   services (e.g., "whitepages", "directory enabled networking", etc).
-
-2.2 S-NAPTR DDDS Application Usage
-
-   As outlined in Appendix A, NAPTR records are used to store
-   application service+protocol information for a given domain.
-   Following the DDDS standard, these records are looked up,  and the
-   rewrite rules (contained in the NAPTR records) are used to determine
-   the successive DNS lookups, until a desirable target is found.
-
-   For the rest of this section, refer to the set of NAPTR resource
-   records for example.com shown in the figure below.
-
-   example.com.
-   ;;       order pref flags service     regexp replacement
-   IN NAPTR 100   10   ""    "WP:whois++" ""    bunyip.example.
-   IN NAPTR 100   20   "s"   "WP:ldap"    ""    _ldap._tcp.myldap.example.com.
-   IN NAPTR 200   10   ""    "IM:protA"   ""    someisp.example.
-   IN NAPTR 200   30   "a"   "IM:protB"   ""    myprotB.example.com.
-
-
-2.2.1 Ordering and Preference
-
-   A client retrieves all of the NAPTR records associated with the
-   target domain name (example.com, above).  These are to be sorted in
-   terms of increasing ORDER, and increasing PREF within each ORDER.
-
-2.2.2 Matching and non-Matching NAPTR Records
-
-   Starting with the first sorted NAPTR record, the client examines the
-   SERVICE field to find a match.  In the case of the S-NAPTR DDDS
-   application, that means a SERVICE field that includes the tags for
-   the desired application service and a supported application protocol.
-
-   If more than one NAPTR record matches, they are processed in
-   increasing sort order.
-
-2.2.3 Terminal and Non-Terminal NAPTR Records
-
-   A NAPTR record with an empty FLAG field is "non-terminal".  That is,
-   more NAPTR RR lookups are to be performed.  Thus, to process a NAPTR
-   record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
-   used as the target of the next DNS lookup -- for NAPTR RRs.
-
-   In S-NAPTR, the only terminal flags are "S" and "A".  These are
-   called "terminal" NAPTR lookups because they denote the end of the
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 4]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   DDDS/NAPTR processing rules.  In the case of an "S" flag, the
-   REPLACEMENT field is used as the target of a DNS query for SRV RRs,
-   and normal SRV processing is applied.  In the case of an "A" flag, an
-   address record is sought for the REPLACEMENT field target (and the
-   default protocol port is assumed).
-
-2.2.4 S-NAPTR and Successive Resolution
-
-   As shown in the example NAPTR RR set above, it is possible to have
-   multiple possible targets for a single application service+protocol
-   pair.  These are to be pursued in order until a server is
-   successfully contacted or all possible matching NAPTR records have
-   been successively pursued to terminal lookups and servers contacted.
-   That is, a client must backtrack and attempt other resolution paths
-   in the case of failure.
-
-   "Failure" is declared, and backtracking must be used when
-
-   o  the designated remote server (host and port) fail to provide
-      appropriate security credentials for the *originating* domain
-
-   o  connection to the designated remote server otherwise fails -- the
-      specifics terms of which are defined when an application protocol
-      is registered
-
-   o  the S-NAPTR-designated DNS lookup fails to yield expected results
-      -- e.g., no A RR for an "A" target, no SRV record for an "S"
-      target, or no NAPTR record with appropriate application service
-      and protocol for a NAPTR lookup.  Except in the case of the very
-      first NAPTR lookup, this last is a configuration error:  the fact
-      that example.com has a NAPTR record pointing to "bunyip.example"
-      for the "WP:Whois++" service and protocol means the administrator
-      of example.com believes that service exists.  If bunyip.example
-      has no "WP:Whois++" NAPTR record, the application client MUST
-      backtrack and try the next available "WP:Whois++" option from
-      example.com.  As there is none, the whole resolution fails.
-
-   An application client first queries for the NAPTR RRs for the domain
-   of a named application service.  The application client MUST select
-   one protocol to choose The PREF field of the NAPTR RRs may be used by
-   the domain administrator to The first DNS query is for the NAPTR RRs
-   in the original target domain (example.com, above).
-
-2.2.5 Clients Supporting Multiple Protocols
-
-   In the case of an application client that supports more than one
-   protocol for a given application service, it MUST pursue S-NAPTR
-   resolution completely for one protocol before trying another.j It MAY
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 5]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   choose which protocol to try first based on its own preference, or
-   from the PREF ranking in the first set of NAPTR records (i.e., those
-   for the target named domain).    However, the chosen protocol MUST be
-   listed in that first NAPTR RR set.
-
-   That is, what the client MUST NOT do is start looking for one
-   protocol, observe that a successive NAPTR RR set supports another of
-   its preferred protocols, and continue the S-NAPTR resolution based on
-   that protocol.  For example, even if someisp.example offers the "IM"
-   service with protocol "ProtB", there is no reason to believe it does
-   so on behalf of example.com (since there is no such pointer in
-   example.com's NAPTR RR set).
-
-3. Guidelines
-
-3.1 Guidelines for Application Protocol Developers
-
-   The purpose of S-NAPTR is to provide application standards developers
-   with a more powerful framework (than SRV RRs alone) for naming
-   service targets, without requiring each application protocol (or
-   service) standard to define a separate DDDS application.
-
-   Note that this approach is intended specifically for use when it
-   makes sense to associate services with particular domain names (e.g.,
-   e-mail addresses, SIP addresses, etc).  A non-goal is having all
-   manner of label mapped into domain names in order to use this.
-
-   Specifically not addressed in this document is how to select the
-   domain for which the service+protocol is being sought.  It is up to
-   other conventions to define how that might be used (e.g., instant
-   messaging standards can define what domain to use from IM URIs, how
-   to step down from foobar.example.com to example.com, and so on, if
-   that is applicable).
-
-   Although this document proposes a DDDS application that does not use
-   all the features of NAPTR resource records, it does not mean to imply
-   that DNS resolvers should fail to implement all aspects of the NAPTR
-   RR standard.  A DDDS application is a client use convention.
-
-   The rest of this section outlines the specific elements that protocol
-   developers must determine and document in order to make use of S-
-   NAPTR.
-
-3.1.1 Registration of application service and protocol tags
-
-   Application protocol developers that wish to make use of S-NAPTR must
-   make provision to register any relevant application service and
-   application protocol tags, as described in Section 6.
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 6]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-3.1.2 Definition of conditions for retry/failure
-
-   One other important aspect that must be defined is the expected
-   behaviour for interacting with the servers that are reached via S-
-   NAPTR.  Specifically,  under what circumstances should the client
-   retry a target that was found via S-NAPTR?  What should it consider a
-   failure that causes it to return to the S-NAPTR process to determine
-   the next serviceable target (a less preferred target)?
-
-   For example, if the client gets a "connection refused" from a server,
-   should it retry for some (protocol-dependent) period of time?  Or,
-   should it try the next-preferred target in the S-NAPTR chain of
-   resolution?  Should it only try the next-preferred target if it
-   receives a protocol-specific permanent error message?
-
-   The most important thing is to select one expected behaviour and
-   document it as part of the use of S-NAPTR.
-
-   As noted earlier, failure to provide appropriate credentials to
-   identify the server as being authoritative for the original taret
-   domain is always considered a failure condition.
-
-3.1.3 Server identification and handshake
-
-   As noted in Section 7, use of the DNS for server location increases
-   the importance of using protocol-specific handshakes to determine and
-   confirm the identity of the server that is eventually reached.
-
-   Therefore, application protocol developers using S-NAPTR should
-   identify the mechanics of the expected identification handshake when
-   the client connects to a server found through S-NAPTR.
-
-3.2 Guidelines for Domain Administrators
-
-   Although S-NAPTR aims to provide a "straightforward" application of
-   DDDS and use of NAPTR records, it is still possible to create very
-   complex chains and dependencies with the NAPTR and SRV records.
-
-   Therefore, domain administrators are called upon to use S-NAPTR with
-   as much restraint as possible, while still achieving their service
-   design goals.
-
-   The complete set of NAPTR, SRV and A RRs that are "reachable" through
-   the S-NAPTR process for a particular application service can be
-   thought of as a "tree".  Each NAPTR RR retrieved points to more NAPTR
-   or SRV records; each SRV record points to several A record lookups.
-   Even though a particular client can "prune" the tree to use only
-   those records referring to application protocols supported by the
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 7]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   client, the tree could be quite deep, and retracing the tree to retry
-   other targets can become expensive if the tree has many branches.
-
-   Therefore,
-
-   o  Fewer branches is better:  for both NAPTR and SRV records, provide
-      different targets with varying preferences where appropriate
-      (e.g., to provide backup services, etc), but don't look for
-      reasons to provide more.
-
-   o  Shallower is better:  avoid using NAPTR records to "rename"
-      services within a zone.  Use NAPTR records to identify services
-      hosted elsewhere (i.e., where you cannot reasonably provide the
-      SRV records in your own zone).
-
-
-3.3 Guidelines for Client Software Writers
-
-   To properly understand DDDS/NAPTR, an implementor must read [6].
-   However, the most important aspect to keep in mind is that, if one
-   target fails to work for the application, it is expected that the
-   application will continue through the S-NAPTR tree to try the (less
-   preferred) alternatives.
-
-4. Illustrations
-
-4.1 Use Cases
-
-   The basic intended use cases for which S-NAPTR has been developed
-   are:
-
-   o  Service discovery within a domain.  For example, this can be used
-      to find the "authoritative" server for some type of service within
-      a domain (see the specific example in Section 4.2).
-
-   o  Multiple protocols.  This is increasingly common as new
-      application services are defined.  This includes the case of
-      instant messaging (a service) which can be offered with multiple
-      protocols (see Section 4.3).
-
-   o  Remote hosting.  Each of the above use cases applies within the
-      administration of a single domain.  However, one domain operator
-      may elect to engage another organization to provide an application
-      service.  See Section 4.4 for an example that cannot be served by
-      SRV records alone.
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 8]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-4.2 Service Discovery within a Domain
-
-   There are occasions when it is useful to be able to determine the
-   "authoritative" server for a given application service within a
-   domain.  This is "discovery", because there is no a priori knowledge
-   as to whether or where the service is offered; it is therefore
-   important to determine the location and characteristics of the
-   offered service.
-
-   For example, there is growing discussion of having a generic
-   mechanism for locating the keys or certificates associated with
-   particular application (servers) operated in (or for) a particular
-   domain.  Here's a hypothetical case for storing application key or
-   certificate data for a given domain.  The premise is that some
-   credentials registry (CredReg) service has been defined to be a leaf
-   node service holding the keys/certs for the servers operated by (or
-   for) the domain.  Furthermore, it is assumed that more than one
-   protocol is available to provide the service for a particular domain.
-   This DDDS-based approach is used to find the CredReg server that
-   holds the information.
-
-   Thus, the set of NAPTR records for thinkingcat.example might look
-   like this:
-
-   thinkingcat.example.
-   ;;       order pref flags service                 regexp  replacement
-   IN NAPTR 100   10   ""    "CREDREG:ldap:iris-beep" ""     theserver.thinkingcat.example.
-
-   Note that another domain, offering the same application service,
-   might offer it using a different set of application protocols:
-
-   anotherdomain.example.
-   ;;       order pref flags service                    regexp replacement
-   IN NAPTR 100   10   ""    "CREDREG:iris-lw:iris-beep" ""    foo.anotherdomain.example.
-
-
-4.3 Multiple Protocols
-
-   As it stands, there are several different protocols proposed for
-   offering "instant message" services.  Assuming that "IM" was
-   registered as an application service, this DDDS application could be
-   used to determine the available services for delivering to a target.
-
-   Two particular features of instant messaging should be noted:
-
-   1.  gatewaying is expected to bridge communications across protocols
-
-   2.  instant messaging servers are likely to be operated out of a
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 9]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-       different domain than the instant messaging address, and servers
-       of different protocols may be offered by independent
-       organizations
-
-   For example, "thinkingcat.example" may support its own servers for
-   the "ProtA" instant messaging protocol, but rely on outsourcing from
-   "example.com" for "ProtC" and "ProtB" servers.
-
-   Using this DDDS-based approach, thinkingcat.example can indicate a
-   preference ranking for the different types of servers for the instant
-   messaging service, and yet the out-sourcer can independently rank the
-   preference and ordering of servers.  This independence is not
-   achievable through the use of SRV records alone.
-
-   Thus, to find the IM services for thinkingcat.example, the NAPTR
-   records for thinkingcat.example are retrieved:
-
-   thinkingcat.example.
-   ;;	order pref flags service   regexp replacement
-   IN NAPTR 100  10   "s"   "IM:ProtA" ""    _ProtA._tcp.thinkingcat.example.
-   IN NAPTR 100  20   "s"   "IM:ProtB" ""    _ProtB._tcp.example.com.
-   IN NAPTR 100  30   "s"   "IM:ProtC" ""    _ProtC._tcp.example.com.
-
-   and then the administrators at example.com can manage the preference
-   rankings of the servers they use to support the ProtB service:
-
-   _ProtB._tcp.example.com.
-    ;;    Pref Weight Port  Target
-   IN SRV 10    0     10001 bigiron.example.com
-   IN SRV 20    0     10001 backup.im.example.com
-   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
-
-
-4.4 Remote Hosting
-
-   In the Instant Message hosting example in Section 4.3, the service
-   owner (thinkingcat.example) had to host pointers to the hosting
-   service's SRV records in the thinkingcat.example domain.
-
-   A better way to approach this is to have one NAPTR RR in the
-   thinkingcat.example domain pointing to all the hosted services, and
-   the hosting domain has NAPTR records for each service to map them to
-   whatever local hosts it chooses (and may change from time to time).
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 10]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   thinkingcat.example.
-   ;;      order pref flags service         regexp replacement
-   IN NAPTR 100  10   "s"   "IM:ProtA"       ""    _ProtA._tcp.thinkingcat.example.
-   IN NAPTR 100  20   ""    "IM:ProtB:ProtC" ""    thinkingcat.example.com.
-
-
-   and then the administrators at example.com can break out the
-   individual application protocols and manage the preference rankings
-   of the servers they use to support the ProtB service (as before):
-
-   thinkingcat.example.com.
-   ;;      order pref flags service   regexp  replacement
-   IN NAPTR 100  10   "s"   "IM:ProtC" ""     _ProtC._tcp.example.com.
-   IN NAPTR 100  20   "s"   "IM:ProtB" ""     _ProtB._tcp.example.com.
-
-
-
-   _ProtC._tcp.example.com.
-    ;;    Pref Weight Port  Target
-   IN SRV 10    0     10001 bigiron.example.com
-   IN SRV 20    0     10001 backup.im.example.com
-   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
-
-
-4.5 Sets of NAPTR RRs
-
-   Note that the above sections assumed that there was one service
-   available (via S-NAPTR) per domain.  Often, that will not be the
-   case.  Assuming thinkingcat.example had the CredReg service set up as
-   described in Section 4.2 and the instant messaging service set up as
-   described in Section 4.4, then a client querying for the NAPTR RR set
-   from thinkingcat.com would get the following answer:
-
-   thinkingcat.example.
-   ;;       order pref flags service          regexp  replacement
-   IN NAPTR 100   10   "s"   "IM:ProtA"        ""     _ProtA._tcp.thinkingcat.example.
-   IN NAPTR 100   20   ""    "IM:ProtB:ProtC:" ""     thinkingcat.example.com.
-   IN NAPTR 200   10   ""    "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.
-
-   Sorting them by increasing "ORDER", the client would look through the
-   SERVICE strings to determine if there was a NAPTR RR that matched the
-   application service it was looking for, with an application protocol
-   it could use.  The first (lowest PREF) record that so matched is the
-   one the client would use to continue.
-
-4.6 Sample sequence diagram
-
-   Consider the example in Section 4.3.  Visually, the sequence of steps
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 11]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   required for the client to reach the final server for a "ProtB"
-   service for IM for the thinkingcat.example domain is as follows:
-
-
-   Client   NS for                NS for
-            thinkingcat.example   example.com    backup.im.example.com
-                |                     |                  |
-     1 -------->|                     |                  |
-     2 <--------|                     |                  |
-     3 ------------------------------>|                  |
-     4 <------------------------------|                  |
-     5 ------------------------------>|                  |
-     6 <------------------------------|                  |
-     7 ------------------------------>|                  |
-     8 <------------------------------|                  |
-     9 ------------------------------------------------->|
-    10 <-------------------------------------------------|
-    11 ------------------------------------------------->|
-    12 <-------------------------------------------------|
-   (...)
-
-
-
-   1.  the name server (NS) for thinkingcat.example is reached with a
-        request for all NAPTR records
-
-   2.  the server responds with the NAPTR records shown in Section 4.3.
-
-   3.  the second NAPTR record matches the desired criteria; that has an
-        "s" flag and a replacement fields of "_ProtB._tcp.example.com".
-        So, the client looks up SRV records for that target, ultimately
-        making the request of the NS for example.com.
-
-   4.  the response includes the SRV records listed in Section 4.3.
-
-   5.  the client attempts to reach the server with the lowest PREF in
-        the SRV list -- looking up the A record for the SRV record's
-        target (bigiron.example.com).
-
-   6.  the example.com NS responds with an error message -- no such
-        machine!
-
-   7.  the client attempts to reach the second server in the SRV list,
-        and looks up the A record for backup.im.example.com
-
-   8.  the client gets the A record with the IP address for
-        backup.im.example.com from example.com's NS.
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 12]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   9.  the client connects to that IP address, on port 10001 (from the
-        SRV record), using ProtB over tcp.
-
-   10.  the server responds with an "OK" message.
-
-   11.  the client uses ProtB to challenge that this server has
-        credentials to operate the service for the original domain
-        (thinkingcat.example)
-
-   12.  the server responds, and the rest is IM.
-
-
-5. Motivation and Discussion
-
-   Increasingly, application protocol standards are using domain names
-   to identify server targets, and stipulating that clients should look
-   up SRV resource records to determine the host and port providing the
-   server.  This enables a distinction between naming an application
-   service target and actually hosting the server.  It also increases
-   flexibility in hosting the target service:
-
-   o  the server may be operated by a completely different organization
-      without having to list the details of that organization's DNS
-      setup (SRVs)
-
-   o  multiple instances can be set up (e.g., for load balancing or
-      secondaries)
-
-   o  it can be moved from time to time without disrupting clients'
-      access, etc.
-
-   This is quite useful, but Section 5.1 outlines some of the
-   limitations inherent in the approach.
-
-   That is, while SRV records can be used to map from a specific service
-   name and protocol for a specific domain to a specific server, SRV
-   records are limited to one layer of indirection, and are focused on
-   server administration rather than on application naming.  And, while
-   the DDDS specification and use of NAPTR allows multiple levels of
-   redirection before locating the target server machine with an SRV
-   record, this proposal requires only a subset of NAPTR strictly bound
-   to domain names, without making use of the REGEXP field of NAPTR.
-   These restrictions make the client's resolution process much more
-   predictable and efficient than with some potential uses of NAPTR
-   records.  This is dubbed "S-NAPTR" -- a "S"traightforward use of
-   NAPTR records.
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 13]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-5.1 So, why not just SRV records?
-
-   An expected question at this point is: this is so similar in
-   structure to SRV records, why are we doing this with DDDS/NAPTR?
-
-   Limitations of SRV include:
-
-   o  SRV provides a single layer of indirection -- the outcome of an
-      SRV lookup is a new domain name for which the A RR is to be found.
-
-   o  the purpose of SRV is focused on individual server administration,
-      not application naming: as stated in [5] "The SRV RR allows
-      administrators to use several servers for a single domain, to move
-      services from host to host with little fuss, and to designate some
-      hosts as primary servers for a service and others as backups."
-
-   o  target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
-      "tcp") in a given domain.  The definition of these terms implies
-      specific things (e.g., that protocol should be one of UDP or TCP)
-      without being precise.  Restriction to UDP and TCP is insufficient
-      for the uses described here.
-
-   The basic answer is that SRV records provide mappings from protocol
-   names to host and port.  The use cases described herein require an
-   additional layer -- from some service label to servers that may in
-   fact be hosted within different administrative domains.  We could
-   tweak SRV to say that the next lookup could be something other than
-   an address record, but that is more complex than is necessary for
-   most applications of SRV.
-
-5.2 So, why not just NAPTR records?
-
-   That's a trick question.  NAPTR records cannot appear in the wild --
-   see [6].  They must be part of a DDDS application.
-
-   The purpose here is to define a single, common mechanism (the DDDS
-   application) to use NAPTR when all that is desired is simple DNS-
-   based location of services.  This should be easy for applications to
-   use -- some simple IANA registrations and it's done.
-
-   Also, NAPTR has very powerful tools for expressing "rewrite" rules.
-   That power (==complexity) makes some protocol designers and service
-   administrators nervous.  The concern is that it can translate into
-   unintelligible, noodle-like rule sets that are difficult to test and
-   administer.
-
-   This proposed DDDS application specifically uses a subset of NAPTR's
-   abilities.  Only "replacement" expressions are allowed, not "regular
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 14]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   expressions".
-
-6. IANA Considerations
-
-   This document calls for 2 IANA registries:  one for application
-   service tags, and one for application protocol tags.
-
-   Application service and protocol tags should be defined in an RFC
-   (unless the "x-" experimental form is used, in which case they are
-   unregistered).  There are no restrictions placed on the tags other
-   than that they must conform with the syntax defined below (Appendix
-   A.5).  The IANA registries should list the tags and the RFC that
-   defines their use.
-
-7. Security Considerations
-
-   The security of this approach to application service location is only
-   as good as the security of the DNS servers along the way.  If any of
-   them is compromised, bogus NAPTR and SRV records could be inserted to
-   redirect clients to unintended destinations.  This problem is hardly
-   unique to S-NAPTR (or NAPTR in general).
-
-   To protect against DNS-vectored attacks, applications should define
-   some form of end-to-end authentication to ensure that the correct
-   destination has been reached.  Many application protocols such as
-   HTTPS, BEEP, IMAP, etc...  define the necessary handshake mechansims
-   to accomplish this task.
-
-   The basic mechanism works in the following way:
-
-   1.  During some portion of the protocol handshake, the client sends
-       to the server the original name of the desired destination (i.e.
-       no transformations that may have resulted from NAPTR
-       replacements, SRV targets, or CNAME changes).  In certain cases
-       where the application protocol does not have such a feature but
-       TLS may be used, it is possible to use the "server_name" TLS
-       extension.
-
-   2.  The server sends back to the client a credential with the
-       appropriate name.  For X.509 certificates, the name would either
-       be in the subjectDN or subjectAltName fields.  For Kerberos, the
-       name would be a service principle name.
-
-   3.  Using the matching semantics defined by the application protocol,
-       the client compares the name in the credential with the name sent
-       to the server.
-
-   4.  If the names match, there is reasonable assurance that the
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 15]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-       correct end point has been reached.
-
-   It is important to note that this document does not define either the
-   handshake mechanism, the specific credenential naming fields, nor the
-   name matching semantics.  Definitions of S-NAPTR for particular
-   application protocols MUST define these.
-
-8. Acknowledgements
-
-   Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
-   discussion and input that has (hopefully!) provoked clarifying
-   revisions of this document.
-
-References
-
-   [1]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
-        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-        Specifications: ABNF", RFC 2234, November 1997.
-
-   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [5]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-        specifying the location of services (DNS SRV)", RFC 2782,
-        February 2000.
-
-   [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-        One: The Comprehensive DDDS", RFC 3401, October 2002.
-
-   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-        Three: The Domain Name System (DNS) Database", RFC 3403, October
-        2002.
-
-   [8]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-        Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
-        2002.
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 16]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-Authors' Addresses
-
-   Leslie Daigle
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
-
-
-   Andrew Newton
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   EMail: anewton@verisignlabs.com
-
-Appendix A. Application Service Location Application of DDDS
-
-   This section defines the DDDS application, as described in [6].
-
-A.1 Application Unique String
-
-   The Application Unique String is domain label for which an
-   authoritative server for a particular service is sought.
-
-A.2 First Well Known Rule
-
-   The "First Well Known Rule" is identity -- that is, the output of the
-   rule is the Application Unique String, the domain label for which the
-   authoritative server for a particular service is sought.
-
-A.3 Expected Output
-
-   The expected output of this Application is the information necessary
-   to connect to authoritative server(s) (host, port, protocol) for an
-   application service within a given a given domain.
-
-A.4 Flags
-
-   This DDDS Application uses only 2 of the Flags defined for the
-   URI/URN Resolution Application ([8]): "S" and "A".  No other Flags
-   are valid.
-
-   Both are for terminal lookups.  This means that the Rule is the last
-   one and that the flag determines what the next stage should be.  The
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 17]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   "S" flag means that the output of this Rule is a domain label for
-   which one or more SRV [5] records exist.  "A" means that the output
-   of the Rule is a domain name and should be used to lookup address
-   records for that domain.
-
-   Consistent with the DDDS algorithm, if the Flag string is empty the
-   next lookup is for another NAPTR record (for the replacement target).
-
-A.5 Service Parameters
-
-   Service Parameters for this Application take the form of a string of
-   characters that follow this ABNF ([3]):
-
-      service-parms = [ [app-service] *(":" app-protocol)]
-      app-service   = experimental-service  / iana-registered-service
-      app-protocol  = experimental-protocol / iana-registered-protocol
-      experimental-service      = "x-" 1*30ALPHANUMSYM
-      experimental-protocol     = "x-" 1*30ALPHANUMSYM
-      iana-registered-service   = ALPHA *31ALPHANUMSYM
-      iana-registered-protocol  = ALPHA *31ALPHANUM
-      ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
-      DIGIT         =  %x30-39 ; 0-9
-      SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
-      ALPHANUMSYM   =  ALPHA / DIGIT / SYM
-      ; The app-service and app-protocol tags are limited to 32
-      ; characters and must start with an alphabetic character.
-      ; The service-parms are considered case-insensitive.
-
-   Thus, the Service Parameters may consist of an empty string, just an
-   app-service, or an app-service with one or more app-protocol
-   specifications separated by the ":" symbol.
-
-   Note that this is similar to, but not the same as the syntax used in
-   the URI DDDS application ([8]).  The DDDS DNS database requires each
-   DDDS application to define the syntax of allowable service strings.
-   The syntax here is expanded to allow the characters that are valid in
-   any URI scheme name (see [1]).  Since "+" (the separator used in the
-   RFC3404 service parameter string) is an allowed character for URI
-   scheme names, ":" is chosen as the separator here.
-
-A.5.1 Application Services
-
-   The "app-service" must be a registered service [this will be an IANA
-   registry; this is not the IANA port registry, because we want to
-   define services for which there is no single protocol, and we don't
-   want to use up port space for nothing].
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 18]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-A.5.2 Application Protocols
-
-   The protocol identifiers that are valid for the "app-protocol"
-   production are any standard, registered protocols [IANA registry
-   again -- is this the list of well known/registered ports?].
-
-A.6 Valid Rules
-
-   Only substitution Rules are permitted for this application.  That is,
-   no regular expressions are allowed.
-
-A.7 Valid Databases
-
-   At present only one DDDS Database is specified for this Application.
-   [7] specifies a DDDS Database that uses the NAPTR DNS resource record
-   to contain the rewrite rules.  The Keys for this database are encoded
-   as domain-names.
-
-   The First Well Known Rule produces a domain name, and this is the Key
-   that is used for the first lookup -- the NAPTR records for that
-   domain are requested.
-
-   DNS servers MAY interpret Flag values and use that information to
-   include appropriate NAPTR, SRV or A records in the Additional
-   Information portion of the DNS packet.  Clients are encouraged to
-   check for additional information but are not required to do so.  See
-   the Additional Information Processing section of [7] for more
-   information on NAPTR records and the Additional Information section
-   of a DNS response packet.
-
-Appendix B. Pseudo pseudocode for S-NAPTR
-
-B.1 Finding the first (best) target
-
-   Assuming the client supports 1 protocol for a particular application
-   service, the following pseudocode outlines the expected process to
-   find the first (best) target for the client, using S-NAPTR.
-
-
-    target = [initial domain]
-    naptr-done = false
-
-    while (not naptr-done)
-     {
-      NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
-      [sort NAPTR-RRset by ORDER, and PREF within each ORDER]
-      rr-done = false
-      cur-rr = [first NAPTR RR]
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 19]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-      while (not rr-done)
-         if ([SERVICE field of cur-rr contains desired application
-              service and application protocol])
-            rr-done = true
-            target= [REPLACEMENT target of NAPTR RR]
-         else
-            cur-rr = [next rr in list]
-
-         if (not empty [FLAG in cur-rr])
-            naptr-done = true
-     }
-
-    port = -1
-
-    if ([FLAG in cur-rr is "S"])
-     {
-      SRV-RRset = [DNSlookup of SRV RRs for target]
-      [sort SRV-RRset based on PREF]
-      target = [target of first RR of SRV-RRset]
-      port = [port in first RR of SRV-RRset]
-     }
-
-    ; now, whether it was an "S" or an "A" in the NAPTR, we
-    ; have the target for an A record lookup
-
-    host = [DNSlookup of target]
-
-    return (host, port)
-
-
-
-B.2 Finding subsequent targets
-
-   The pseudocode in Appendix B is crafted to find the first, most
-   preferred, host-port pair for a particular application service an
-   protocol.  If, for any reason, that host-port pair did not work
-   (connection refused, application-level error), the client is expected
-   to try the next host-port in the S-NAPTR tree.
-
-   The pseudocode above does not permit retries -- once complete, it
-   sheds all context of where in the S-NAPTR tree it finished.
-   Therefore, client software writers could
-
-   o  entwine the application-specific protocol with the DNS lookup and
-      RRset processing described in the pseudocode and continue the S-
-      NAPTR processing if the application code fails to connect to a
-      located host-port pair;
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 20]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   o  use callbacks for the S-NAPTR processing;
-
-   o  use an S-NAPTR resolution routine that finds *all* valid servers
-      for the required application service and protocol from the
-      originating domain, and provides them in sorted order for the
-      application to try in order.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 21]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 22]
-
diff --git a/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/doc/draft/draft-danisch-dns-rr-smtp-03.txt
deleted file mode 100644
index 4a01d91b9a8b..000000000000
--- a/doc/draft/draft-danisch-dns-rr-smtp-03.txt
+++ /dev/null
@@ -1,1960 +0,0 @@
-
-
-
-INTERNET-DRAFT                                           Hadmut Danisch
-Category: Experimental                                         Oct 2003
-Expires: Apr 1, 2004
-
- The RMX DNS RR and method for lightweight SMTP sender authorization
-                   draft-danisch-dns-rr-smtp-03.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other
-   documents at any time.  It is inappropriate to use Internet-Drafts
-   as reference material or to cite them other than as "work in
-   progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Abstract
-
-   This memo introduces a new authorization scheme for SMTP e-mail
-   transport. It is designed to be a simple and robust protection
-   against e-mail fraud, spam and worms. It is based solely on
-   organisational security mechanisms and does not require but still
-   allow use of cryptography. This memo also focuses on security and
-   privacy problems and requirements in context of spam defense. In
-   contrast to prior versions of the draft a new RR type is not
-   required anymore.
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch                Experimental                      [Page 1]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-                           Table of Contents
-
-
-1.  General Issues . . . . . . . . . . . . . . . . . . . . . . . . .   4
-2.  Problem and threat description . . . . . . . . . . . . . . . . .   4
-    2.1.  Mail sender forgery  . . . . . . . . . . . . . . . . . . .   4
-          2.1.1  Definition of sender forgery  . . . . . . . . . . .   4
-          2.1.2  Spam  . . . . . . . . . . . . . . . . . . . . . . .   5
-          2.1.3  E-Mail Worms  . . . . . . . . . . . . . . . . . . .   5
-          2.1.4  E-Mail spoofing and fraud . . . . . . . . . . . . .   5
-    2.2.  Indirect damage caused by forgery  . . . . . . . . . . . .   6
-    2.3.  Technical problem analysis . . . . . . . . . . . . . . . .   6
-    2.4.  Shortcomings of cryptographical approaches . . . . . . . .   7
-3.  A DNS based sender address verification  . . . . . . . . . . . .   7
-    3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .   7
-    3.2.  Envelope vs. header sender address . . . . . . . . . . . .   9
-    3.3.  Domain part vs. full sender address  . . . . . . . . . . .   9
-4.  Mapping of E-Mail addresses to DNS names . . . . . . . . . . . .  10
-    4.1.  Domain part only . . . . . . . . . . . . . . . . . . . . .  10
-    4.2.  Full address . . . . . . . . . . . . . . . . . . . . . . .  11
-    4.3.  Empty address  . . . . . . . . . . . . . . . . . . . . . .  11
-5.  Mandatory entry types and their syntax . . . . . . . . . . . . .  11
-    5.1.  Overall structure  . . . . . . . . . . . . . . . . . . . .  11
-    5.2.  Unused . . . . . . . . . . . . . . . . . . . . . . . . . .  12
-    5.3.  IPv4 and IPv6 address ranges . . . . . . . . . . . . . . .  12
-    5.4.  DNS Hostname . . . . . . . . . . . . . . . . . . . . . . .  13
-          5.4.1  Road warriors and DynDNS entries  . . . . . . . . .  13
-    5.5.  APL Reference  . . . . . . . . . . . . . . . . . . . . . .  14
-    5.6.  Domain Member  . . . . . . . . . . . . . . . . . . . . . .  14
-    5.7.  Full Address Query . . . . . . . . . . . . . . . . . . . .  15
-    5.8.  DNS mapped authorization . . . . . . . . . . . . . . . . .  15
-    5.9.  RMX reference  . . . . . . . . . . . . . . . . . . . . . .  16
-6.  Optional and experimental entry types  . . . . . . . . . . . . .  16
-    6.1.  TLS fingerprint  . . . . . . . . . . . . . . . . . . . . .  16
-    6.2.  TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . .  16
-    6.3.  PGP or S/MIME signature  . . . . . . . . . . . . . . . . .  16
-    6.4.  Transparent Challenge/Response . . . . . . . . . . . . . .  17
-    6.5.  SASL Challenge/Response  . . . . . . . . . . . . . . . . .  17
-7.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
-    7.1.  Alternative encoding as TXT records  . . . . . . . . . . .  17
-    7.2.  RMX Records  . . . . . . . . . . . . . . . . . . . . . . .  17
-          7.2.1  Overall structure . . . . . . . . . . . . . . . . .  18
-          7.2.2  Record encoding . . . . . . . . . . . . . . . . . .  18
-          7.2.3  Encoding of IPv4 and IPv6 address ranges  . . . . .  18
-          7.2.4  Encoding of DNS . . . . . . . . . . . . . . . . . .  18
-          7.2.5  Encoding of unused and full query . . . . . . . . .  19
-          7.2.6  Additional Records  . . . . . . . . . . . . . . . .  19
-8.  Message Headers  . . . . . . . . . . . . . . . . . . . . . . . .  19
-
-
-
-Hadmut Danisch                Experimental                      [Page 2]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-9.  SMTP error messages  . . . . . . . . . . . . . . . . . . . . . .  20
-10.  Message relaying and forwarding . . . . . . . . . . . . . . . .  20
-    10.1.  Problem description . . . . . . . . . . . . . . . . . . .  20
-    10.2.  Trusted relaying/forwarding . . . . . . . . . . . . . . .  21
-    10.3.  Untrusted relaying/forwarding . . . . . . . . . . . . . .  21
-11.  Security Considerations . . . . . . . . . . . . . . . . . . . .  22
-    11.1.  Draft specific considerations . . . . . . . . . . . . . .  22
-          11.1.1  Authentication strength  . . . . . . . . . . . . .  22
-          11.1.2  Where Authentication and Authorization end . . . .  22
-          11.1.3  Vulnerability of DNS . . . . . . . . . . . . . . .  23
-          11.1.4  Sneaking RMX attack?   . . . . . . . . . . . . . .  25
-          11.1.5  Open SMTP relays . . . . . . . . . . . . . . . . .  25
-          11.1.6  Unforged Spam  . . . . . . . . . . . . . . . . . .  25
-          11.1.7  Reliability of Whois Entries . . . . . . . . . . .  26
-          11.1.8  Hazards for Freedom of Speech  . . . . . . . . . .  26
-    11.2.  General Considerations about spam defense . . . . . . . .  27
-          11.2.1  Action vs. reaction  . . . . . . . . . . . . . . .  27
-          11.2.2  Content based Denial of Service attacks  . . . . .  27
-12.  Privacy Considerations  . . . . . . . . . . . . . . . . . . . .  28
-    12.1.  Draft specific considerations . . . . . . . . . . . . . .  28
-          12.1.1  No content leaking . . . . . . . . . . . . . . . .  28
-          12.1.2  Message reception and sender domain  . . . . . . .  28
-          12.1.3  Network structure  . . . . . . . . . . . . . . . .  29
-          12.1.4  Owner information distribution . . . . . . . . . .  29
-    12.2.  General Considerations about spam defense . . . . . . . .  29
-          12.2.1  Content leaking of content filters . . . . . . . .  29
-          12.2.2  Black- and Whitelists  . . . . . . . . . . . . . .  30
-13.  Deployment Considerations . . . . . . . . . . . . . . . . . . .  30
-    13.1.  Compatibility . . . . . . . . . . . . . . . . . . . . . .  30
-          13.1.1  Compatibility with old mail receivers  . . . . . .  30
-          13.1.2  Compatibility with old mail senders  . . . . . . .  30
-          13.1.3  Compatibility with old DNS clients . . . . . . . .  30
-          13.1.4  Compatibility with old DNS servers . . . . . . . .  30
-    13.2.  Enforcement policy  . . . . . . . . . . . . . . . . . . .  31
-14.  General considerations about fighting spam  . . . . . . . . . .  31
-    14.1.  The economical problem  . . . . . . . . . . . . . . . . .  31
-    14.2.  The POP problem . . . . . . . . . . . . . . . . . . . . .  32
-    14.3.  The network structure problem . . . . . . . . . . . . . .  33
-    14.4.  The mentality problem . . . . . . . . . . . . . . . . . .  33
-    14.5.  The identity problem  . . . . . . . . . . . . . . . . . .  33
-    14.6.  The multi-legislation problem . . . . . . . . . . . . . .  34
-Implementation and further Information . . . . . . . . . . . . . . .  34
-References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  34
-Draft History  . . . . . . . . . . . . . . . . . . . . . . . . . . .  35
-Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .  35
-
-
-
-
-
-
-Hadmut Danisch                Experimental                      [Page 3]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-1.  General Issues
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
-   this document are to be interpreted as described in RFC 2119 [1].
-
-2.  Problem and threat description
-
-2.1.  Mail sender forgery
-
-   The amount of e-mails with forged sender addresses has dramatically
-   increased. As a consequence, damages and annoyances caused by such
-   e-mails increased as well. In the majority of examined e-mails the
-   domain name of the envelope sender address was forged, and the e-
-   mail was sent from an IP address which does not belong to a network
-   used by the actual owner of the domain.
-
-2.1.1.  Definition of sender forgery
-
-   As discussions, comments to prior versions of this draft, and
-   different approaches to stop forgery showed, different perceptions
-   of "mail forgery" exist. For example, there are mechanisms to
-   verify e-mail addresses for mailing lists, web servers, or to stop
-   spam, which do send a message with a random number to the given
-   address and expect the user to send a reply. Here, someone is
-   considered to be allowed to use a particular e-mail address, if and
-   only if he is able to receive informations sent to this address,
-   and is able to reply to such a message. While this definition
-   appears to be quite plausible and natural, it can't be used for a
-   simple technical solution. Sending back a challenge and expecting a
-   reply is simply too much overhead and time delay, and not every
-   authorized sender is able or willing to reply (e.g. because he went
-   offline or is not a human).
-
-   Within the scope of this memo, sender forgery means that the
-   initiator of an e-mail transfer (which is the original sender in
-   contrast to relays) uses a sender address which he was not
-   authorized to use. Being authorized to use an address means that
-   the owner (administrator) of the internet domain has given
-   permission, i.e. agrees with the use of the address by that
-   particular sender. This memo will cover both the permission of the
-   full e-mail address and the domain part only for simplicity.
-
-   Within context of Internet and SMTP, the sender address usually
-   occurs twice, once as the envelope sender address in SMTP, and once
-   as the address given in the RFC822 mail header. While the following
-   considerations apply to both addresses in principle, it is
-   important to stress that both addresses have distinct semantics and
-
-
-
-Hadmut Danisch                Experimental                      [Page 4]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   are not neccessarily the same. The envelope address identifies the
-   initiator of the transport, while the header identifies the author
-   of the message content. Since this memo deals with the message
-   transport only and completely ignores the message content, the
-   method should naturally be applied to the envelope sender address.
-
-2.1.2.  Spam
-
-   A common and well known problem is the dramatic increase of
-   unsolicited e-mail, commonly called "spam". Again, the majority of
-   examined e-mails had forged sender addresses.  The abused domains
-   were mainly those of common webmailers as hotmail or yahoo, or
-   well-known companies.
-
-   Unfortunately, there is no accurate definition of spam availabe
-   yet, and neither are the concise technical criterions to filter or
-   block spam with technical mechanisms. There are efforts to design
-   content based filters, but these filters are expensive in
-   calculation time (and sometimes money), and they do not reliably
-   provide predictable results. Usually they give false positives
-   and/or require user interaction. Content filters in general suffer
-   from a design problem described later in this memo.  Therefore,
-   this proposal does not use the content based approach to block
-   spam.
-
-   As analysis of spam messages showed, most of spam messages were
-   sent with forged envelope sender addresses. This has mainly three
-   reasons.  The first reason is, that spam senders usually do not
-   want to be contacted by e-mail. The second reason is, that they do
-   not want to be blacklisted easily. The third reason is, that spam
-   is or is going to be unlawful in many countries, and the sender
-   does not want to reveal his identity. Therefore, spam is considered
-   to be a special case of sender forgery.
-
-2.1.3.  E-Mail Worms
-
-   Another example of sender forgery is the reproduction of e-mail
-   worms. Most worms do choose random sender addresses, e.g.  using
-   the addresses found in mailboxes on the infected system. In most
-   cases analyzed by the author, the e-mails sent by the reproduction
-   process can also be categorized as forged, since the infected
-   system would under normal circumstances not be authorized to send
-   e-mails with such e-mail addresses. So forgery does not require a
-   malicious human to be directly involved. This memo covers any kind
-   of e-mail sender address forgery, included those generated by
-   malicious software.
-
-2.1.4.  E-Mail spoofing and fraud
-
-
-
-Hadmut Danisch                Experimental                      [Page 5]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   Forging e-mail sender addresses for fraud or other kinds of
-   deception ("human engineering") has also dramatically increased.
-   There are many known cases where single or mass e-mails were sent
-   with wrong sender addresses, pretending to come from service
-   provider, software manufacturers etc., and asking the receiver to
-   install any software or patches, or to reply with any confidential
-   information. The Internet is becoming more and more a scene of
-   crime, and so are it's services, including e-mail. It is obvious
-   that crime based on e-mail is eased by the fact that SMTP allows
-   arbitrary sender address spoofing.
-
-2.2.  Indirect damage caused by forgery
-
-   As observed by the author, mass mails and worms with forged sender
-   addresses can cause a severe damage for the real owner of the
-   abused sender addresses. If a sender A is sending an e-mail to the
-   receiver B, pretending to be C by using a sender address of C's
-   domain, then C has currently no chance to prevent this, since C's
-   machines and software are not involved in any way in the delivery
-   process between A and B.  B will nevertheless send any error
-   messages (virus/spam alert, "no such user", etc.) to C, erroneously
-   assuming that the message was sent by C. The author found several
-   cases where this flood of error messages caused a severe denial of
-   service or a dramatic increase of costs, e.g. when C was
-   downloading the e-mail through expensive or low bandwidth
-   connections (e.g. modem or mobile phones), or where disk space was
-   limited. The author examined mass mailings, where several tens or
-   hundreds of thousands of messages were sent to several addresses
-   around the world, where these messages caused only annoyance. But
-   since several thousands of these addresses were invalid or didn't
-   accept the message, the owner of the DNS domain which was abused by
-   the spammer to forge sender addresses was flooded for several
-   months with thousands of error messages, jamming the e-mail system
-   and causing severe costs and damages.
-
-   As a consequence, when A sends a message to B, pretending to be C,
-   there must be any mechanism to allow C to inform B about the fact,
-   that A is not authorized to use C as a sender address. This is what
-   this memo is about.
-
-2.3.  Technical problem analysis
-
-   Why does e-mail forgery actually exist? Because of the lack of the
-   Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
-   authentication, authorisation, or verification. This protocol was
-   designed at a time where security was not an issue. Efforts have
-   been made to block forged e-mails by requiring the sender address
-   domain part to be resolvable.  This method provides protection from
-
-
-
-Hadmut Danisch                Experimental                      [Page 6]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   e-mails with non-existing sender domains, and indeed, for some time
-   it blocked most spam e-mails. However, since attackers and spam
-   senders began to abuse existing domain names, this method was
-   rendered ineffective.
-
-2.4.  Shortcomings of cryptographical approaches
-
-   At a first glance, the problem of sender address forgery might
-   appear to be solvable with cryptographic methods such as challenge
-   response authentications or digital signatures. A deeper analysis
-   shows that only a small, closed user group could be covered with
-   cryptographical methods. Any method used to stop spam forgery must
-   be suitable to detect forgery not only for a small number of
-   particular addresses, but for all addresses on the world. An
-   attacker does not need to know the secrets belonging to a
-   particular address. It is sufficient to be able to forge any
-   address and thus to know any secret key. Since there are several
-   hundreds of millions of users, there will always be a large amount
-   of compromised keys, thus spoiling any common cryptographic method.
-   Furthermore, cryptography has proven to be far too complicated and
-   error prone to be commonly administered and reliably implemented.
-   Many e-mail and DNS administrators do not have the knowledge
-   required to deal with cryptographic mechanisms. Many legislations
-   do not allow the general deployment of cryptography and a directory
-   service with public keys. For these reasons, cryptography is
-   applicable only to a small and closed group of users, but not to
-   all participants of the e-mail service.
-
-3.  A DNS based sender address verification
-
-3.1.  Overview
-
-   To gain improvement in e-mail authenticity while keeping as much
-   SMTP compatibility as possible, a method is suggested which doesn't
-   change SMTP at all.
-
-   The idea is to store informations about how to verify who is
-   authorized to transmit e-mails through SMTP with a particular
-   sender address (either full address or - for simplicity - only the
-   domain part of the address) in a directory service, which is
-   currently the DNS. To be precise, the verification consists of two
-   steps, the classical pair of authentication and authorization:
-
-   The first step is the authentication. While several methods are
-   possible to perform authentication (see below), the most important
-   and robust method is the verification of the sender's IP address.
-   This is done implicitely by TCP/IP and the TCP sequence number. The
-   authenticated identity is the IP address. It has to be stressed
-
-
-
-Hadmut Danisch                Experimental                      [Page 7]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   that this TCP/IP "authentication" is a weak authentication and
-   vulnerable to several attacks. It is nevertheless sufficient for
-   this purpose, especially for blocking spam. It doesn't take any
-   implementation and it doesn't cost: It is already there, it is a
-   functionality of TCP/IP. An incoming SMTP connection based on
-   TCP/IP already carries the sender's IP address without any
-   modification of SMTP. See below (section Entry types) for more
-   details about authentication methods.
-
-   The second step is the authorization. It is based on the identity
-   given by the previous authentication step, e.g. the IP address of
-   the originator of the incoming SMTP connection,  and on the
-   envelope sender address. The mechanism proposed in this memo
-   answers the question "Is that particular sender (IP address,...)
-   allowed to send with that sender address" by querying and
-   processing informations stored in a directory service, which is
-   DNS.
-
-   When the sender has issued the "MAIL FROM:" SMTP command, the
-   receiving mail transfer agent (MTA) can - and modern MTAs do -
-   perform some authorization checks, e.g. run a local rule database
-   or check whether the sender domain is resolvable.
-
-   The suggested method is to let the DNS server for the sender domain
-   provide informations about who - this means for example which IP
-   address - is authorized to use an address or a domain as a part of
-   it.  After receiving the "MAIL FROM:" SMTP command, the receiving
-   MTA can verify, whether e. g. the IP address of the sending MTA is
-   authorized to send mails with this domain name. Therefore, a list
-   of entries with authorized IP addresses or other informations is
-   provided by the authoritative DNS server of that domain. The entry
-   types are described in the subsequent chapters. Some of these
-   methods are
-
-     - An IPv4 or IPv6 network address and mask
-     - A fully qualified domain name referring to an A record
-     - A fully qualified domain name referring to an APL record
-
-   RMX records of these types would look like this:
-
-      somedomain.de.      IN RMX ipv4:10.0.0.0/8
-      rmxtest.de.         IN RMX host:relay.provider.com
-      danisch.de.         IN RMX apl:relays.rackland.de
-      relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
-
-   where the machine with the example address 213.133.101.23 and the
-   machines in the example subnet 1.2.3.0/24 are the only machines
-   allowed to send e-mails with an envelope sender address of domain
-
-
-
-Hadmut Danisch                Experimental                      [Page 8]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   danisch.de. Since the APL records do not necessarily belong to the
-   same domain or zone table as the RMX records, this easily allows to
-   refer to APL records defined by someone else, e.g. the internet
-   access or server hosting provider, thus reducing administrative
-   overhead to a minimum. In the example given above, the domain
-   danisch.de and several other domains are hosted by the service
-   provider Rackland. So if the relay structure of Rackland is
-   modified, only the zone of rackland.de needs to be modified. The
-   domain owners don't need to care about such details.
-
-3.2.  Envelope vs. header sender address
-
-   Questions were raised why the proposed mechanism is based on the
-   envelope sender address, and not on the sender address given in the
-   message header. Technically, both can be used. Actually, it makes
-   sense to use the envelope address.
-
-   In common, the header sender address identifies the author of the
-   content, while the envelope sender tells who caused the
-   transmission.  The approach proposed in this memo is transmission
-   based, not content based. We can not authorize the author of a
-   message if we don't have contact with him, if the message does not
-   already contain a signature. In contrast, the sending MTA is linked
-   to an IP address which can be used for authentication. This
-   mechanism might not be very strong, but it is available and
-   sufficient to solve today's e-mail security problems.
-
-   Some people argued that it is the header address and not the sender
-   address, which is displayed in common mail readers (MUAs), and
-   where the receiver believes the mail comes from. That's true, but
-   it doesn't help. There are many cases where the header sender
-   differs from the envelope sender for good reasons (see below in the
-   consequences chapter for the discussion about relaying).  Relaying,
-   mailing lists etc. require to replace the sender address used for
-   RMX. If this were the header address, the message header would have
-   to be modified. This is undesirable.
-
-3.3.  Domain part vs. full sender address
-
-   Former versions of this draft were limited to the domain part of
-   the sender address. The first reason is that it is common and MX-
-   like, to lookup only the domain part of an e-mail address in DNS.
-   The second reason is, that it was left to the private business of
-   the domain administration to handle details of user verification.
-   The idea was that the domain administration takes care to verify
-   the left part of an e-mail address with an arbitrary method of
-   their individual taste. RMX was originally designed to ignore the
-   left part of the address and to expect the domain administration to
-
-
-
-Hadmut Danisch                Experimental                      [Page 9]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   take over responsibility for enforcing their policy. If, e.g., a
-   spam message arrived and passed the RMX mechanism, it is known to
-   be authorized by the domain administration and they can be blamed,
-   no matter what is on the left side of the sender address - it's
-   their private problem what happens on the left side of the @. By
-   far the most of the comments to prior versions of this draft agreed
-   with that. A few comments asked for a finer granularity.
-
-   And indeed, there is no technical reason against a finer
-   granularity.  All it takes is a mapping from a given envelope
-   sender address to a DNS name, and the RMX lookup for that
-   particular e-mail address could be done instead of a lookup for the
-   domain part only.  However, to my knowledge, most domain
-   administrators would not like to provide an RMX entry for every
-   single e-mail address. In many cases, this would also overload DNS
-   servers.
-
-   It is to be discussed how to cover both views. One method could be
-   to query the full address, and if no RMX records were found to
-   query the domain part only. A different approach would be to query
-   the domain part only, and if it's RMX record contain a special
-   entry, then a new query for the full address is triggered. A third
-   way would be to always query the full address and to leave the
-   problem to the wildcard mechanism of DNS. This still has to be
-   discussed and will be described in future versions of this draft.
-
-
-
-
-
-
-
-
-
-
-
-4.  Mapping of E-Mail addresses to DNS names
-
-   To perform the RMX query, a mapping is needed from E-Mail addresses
-   to DNS fully qualified domain names.
-
-   This chapter is under development and just a first approach.
-
-4.1.  Domain part only
-
-   Mapping of the domain part is trivial, since the domain part of an
-   e-mail address itself is a valid DNS name and does not need
-   translation. It might be nevertheless desirable to distinguish the
-
-
-
-Hadmut Danisch                Experimental                     [Page 10]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   RMX entries from other entries, depending of the encoding of the
-   records. If the RMX entries are encoded in TXT record types, they
-   might collide with other uses of TXT records.  It might be
-   necessary to prepend the domain part with a special prefix, e.g.
-   _rmx. So the e-mail address some.user@example.com could be mapped
-   to example.com or _rmx.example.com.
-
-4.2.  Full address
-
-   Mapping a full address is slightly more difficult. The @ sign must
-   be unambiguously translated, and therefore can not be simply
-   translated into a dot. The e-mail addresses some.user@example.com
-   and some@user.example.com must have different mappings. Therefore,
-   the @ sign could be translated into _rmx, implicitely assuming that
-   this is not an allowed domain name component of normal domain
-   names. Then the rightmost _rmx in the mapped DNS name always
-   corresponds to the @ sign. some.user@example.com would e translated
-   into some.user._rmx.example.com and can be covered by a wildcard
-   entry like *._rmx.example.com.
-
-   Character encoding and character sets are still to be discussed.
-
-4.3.  Empty address
-
-   Unfortunately, SMTP allows empty envelope sender addresses to be
-   used for error messages. Empty sender addresses can therefore not
-   be prohibited. As observed, a significant amount of spam was sent
-   with such an empty sender address. To solve this problem, the host
-   name given in the HELO or EHLO command is taken to lookup the RMX
-   records instead. This makes sense, since such messages were
-   generated by the machine, not a human.
-
-
-
-
-5.  Mandatory entry types and their syntax
-
-   The entry types described in this section MUST be supported by any
-   implementation of this draft.
-
-5.1.  Overall structure
-
-   Similar to APL, an RMX record is just a concatenation of zero or
-   more RMX entries. The entries within one record form an ordered
-   rule base as commonly usual in packet filtes and firewall rulesets,
-   i. e. they are processed one ofter another until the first entry
-   matches. This entry determines the result of the query. Once a
-   matching entry is found, the RMX processing is finished.
-
-
-
-Hadmut Danisch                Experimental                     [Page 11]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   For any domain name there should not exist more than a single RMX
-   record. Due to the structure of DNS, it is nevertheless possible to
-   have more than a single RMX record. Multiple RMX records are
-   treated as a single record consisting of the concatenation of all
-   records. While the entries in a record are ordered, the records are
-   not ordered and may be processed in arbitrary order. If the order
-   of the entries matters, it is the zone maintainer's responsibility
-   to keep those entries in a single record. For example, there are
-   negative entries, which exclude IP addresses from authorization.
-   It is important that these entries are processed before positive
-   entries giving permission to a wider address range. Since order is
-   guaranteed only within a record, corresponding negative and
-   positive entries must be put in the same record.
-
-   An RMX record may consist of one or more entries, where the entries
-   are separated by whitespace. An entry must not contain white space.
-   Each entry consists of an optional exclamation sign, a tag, a
-   colon, and the entry data:
-
-      [!] TAG : ENTRY-SPECIFIC-DATA
-
-   If the entry starts with an exclamation sign, the entry is negated.
-   See the entry type description below for details.
-
-   The TAG is the mnemonic type identifier or the decimal number of
-   the entry. The TAG is case-insensitive. It is immediately followed
-   by a colon.
-
-   The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
-   entry type. See description below.
-
-   Example:
-
-      danisch.de.  IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
-   ipv4:1.2.3.0/24
-
-5.2.  Unused
-
-   This is a primitive entry which just says that this sender address
-   will never be used as a sender address under any circumstances.
-   Example:
-
-   testdomain.danisch.de    IN RMX unused:
-
-5.3.  IPv4 and IPv6 address ranges
-
-   These entry types contain a bit sequence representing a CIDR
-   address part. If that bit sequence matches the given IP address,
-
-
-
-Hadmut Danisch                Experimental                     [Page 12]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   authorization is granted or denied, depending on the negation flag.
-
-   The entry is prepended with the tag "IPv4" or "IPv6". The colon is
-   followed with an IPv4 or IPv6 address in standard notation,
-   optionally followed by a slash and a mask length. If the negation
-   flag is set, then the given address range is excluded.  Examples:
-
-   danisch.de   IN RMX ipv4:213.133.101.23 ipv6:fe00::0
-                IN RMX ipv4:10.0.0.0/8     ipv6:fec0::0/16
-                IN RMX !ipv4:1.2.3.4
-
-   (Please note that it does not make much sense to use
-   RFC1918-Addresses in RMX records, this is just to give a syntax
-   example.)
-
-
-5.4.  DNS Hostname
-
-   This entry type simply contains a regular DNS name, which is to be
-   resolved as a host name (fetch the A record or IPv6 equivalent). If
-   the given IP address matches the result, authorization is granted
-   or denied, depending on the negation flag.  It is still to be
-   defined how to treat unresolvable entries.
-
-   The entry is prepended with the tag "host", followed by a colon and
-   the hostname. Examples:
-
-   danisch.de  IN RMX host:relay.provider.de
-               IN RMX !host:badmachine.domain.de apl:relays.domain.de
-
-5.4.1.  Road warriors and DynDNS entries
-
-   Several people argued against RMX that it would break their
-   existing installation which delivers e-mail from dynamically
-   assigned IP addresses, because their IP providers didn't assign a
-   static address, or because they are a road warrior, plugging their
-   notebook in any hotel room on the world.
-
-   RMX provides a simple solution. If such a machine has a dynamically
-   updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
-   the hostname type pointing to this dynamic DNS entry.
-
-   The cleaner solution would be to deliver mail the same way as it is
-   received: If downloaded by POP from a central relay with a static
-   address, where the MX points to, then it would be a good idea to
-   deliver e-mail the same way in reverse direction. Unfortunately,
-   plain POP does not support uploading yet.
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 13]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-5.5.  APL Reference
-
-   This entry type simply contains a regular DNS name, which is to be
-   resolved as an APL record index  (fetch the APL record).  If the
-   given IP address positively  matches the APL, authorization is
-   granted. Details of the semantic (espially when the negation bit is
-   set) are still to be defined.  It is still to be defined how to
-   treat unresolvable entries.
-
-   The entry is prepended with the tag "host", followed by a colon and
-   the hostname. Example:
-
-   danisch.de     IN RMX apl:relays.rackland.de
-
-5.6.  Domain Member
-
-   In many cases it is desirable to cover all hosts of a given domain
-   with an RMX record without the need to duplicate the list of these
-   hosts. This entry type does it (thanks to Eric A. Hall for pointing
-   out this entry type).  It contains a regular DNS name.
-
-   If this entry type is given, a reverse DNS query for the IP address
-   of the sending MTA is performed to find its official fully
-   qualified domain name. To prevent spoofing, this domain name is
-   accepted only if a subsequent address query to the given domain
-   name points to exactly the IP address of the sending MTA (the usual
-   procedure to verify PTR records).
-
-   The entry matches if the fully qualified domain name of the sending
-   MTA ends in the given domain. The negation flag works as usual.
-
-   The tag for this entry type is "domain". After the colon the domain
-   name is given, but might be empty, thus pointing to itself.
-   Example:
-
-      somedomain.org  IN RMX domain:somedomain.org domain:provider.com
-
-   would authorize all machines which's hostname can be verified
-   through an PTR and A query, and which ends in "somedomain.org" or
-   "provider.com".
-
-   With such an entry, large companies with different networks can
-   easily be covered with just a single and simple RMX entry.
-   Obviously, it requires proper PTR records.
-
-   As a special shortcut, the DNS name may be empty. In this case the
-   domain name of the zone itself is taken. Thus, with a very simple
-   entry of the type
-
-
-
-Hadmut Danisch                Experimental                     [Page 14]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-     somecompany.com  IN RMX domain:
-
-   a company could authorize all machines which's IP addresses map to
-   DNS names end in somecompany.com, which applies in the majority of
-   companies.
-
-
-
-
-5.7.  Full Address Query
-
-   As described above, RMX records will in most cases apply to the
-   domain part of the sender address. In special cases it might be
-   desirable to query the RMX record for a particular address.  An RMX
-   entry of the Full Address Query type may occur in a domain RMX
-   record only. It signals that the RMX record for the full address is
-   to be fetched and processed.
-
-   This entry type does not take arguments. The negation flag is not
-   supported. The tag is "full".
-
-   If such a full address query is to be performed, the mail address
-   must be mapped to a valid and non-ambiguos DNS name. This mapping
-   is still to be defined. It is not sufficient to simply replace the
-   @ with a dot, because of case sensitivity, character sets, etc. The
-   e-mail addresses
-
-      john.doe@example.org
-      John.Doe@example.org
-      john@doe.example.org
-
-   must all be mapped to different DNS entries. This entry type might
-   vanish in future versions of the draft, depending on the discussion
-   about whether to query the domain name part only or the full
-   address.
-
-5.8.  DNS mapped authorization
-
-   As I learned from comments to prior versions of the draft and from
-   alternative proposals, many users wish to have a DNS mapped
-   authorization table, i. e. the client queries a DNS entry of the
-   form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
-   Since people wish to have this, RMX will now include such a mapping
-   entry. The entry has a parameter giving the DNS domain name where
-   to look at. If the parameter is empty, then the same domain is
-   taken as for the RMX lookup.
-
-   As this is currently under construction and discussion in an IETF
-
-
-
-Hadmut Danisch                Experimental                     [Page 15]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   group, details will be published in future versions of this draft.
-
-5.9.  RMX reference
-
-   This entry type has no parameters. It means that all those machines
-   are authorized, which are pointed to by an MX record.
-
-6.  Optional and experimental entry types
-
-   The following subsections roughly describe further entry types
-   which might not be supported by all implementations and might not
-   be allowed in all legislations. These methods might vanish in
-   future versions of the draft and are just considerations about what
-   to include in RMX and what to not include. The main purpose of this
-   section is to start discussion about such entry types.
-
-   The disadvantage of the following methods is that they violate the
-   basic idea of RMX, i. e. to be simple, robust, easy to implement
-   and easy to administer. I personally do not believe that it is a
-   good idea or even feasible to implement cryptography for a world
-   wide e-mail transfer network. Keep in mind that cryptographic keys
-   can be copied.  If only <0.1% of cryptographic keys were revealed,
-   this completely compromises and spoils RMX. Cryptography is simply
-   the wrong tool for the problem RMX is intended to solve. I
-   nevertheless like to discuss these methods.
-
-6.1.  TLS fingerprint
-
-   The sender is considered to be authorized if the message was
-   transmitted through SMTP and TLS, and the sender used a certificate
-   matching the fingerprint given in the RMX record.
-
-6.2.  TLS and LDAP
-
-   This means that the receiver should perform an LDAP query for the
-   sender address (through the LDAP SRV record or given in the RMX
-   record), fetch the X.509 certificate for the sender. The sender is
-   considered to be authorized when the message was transmitted
-   through SMTP and TLS using this certificate.
-
-6.3.  PGP or S/MIME signature
-
-   It would be possible to accept a message only if it was signed with
-   PGP or S/MIME with a key which's fingerprint is given in the RMX
-   record or to be fetched from LDAP or any PGP database.  This is
-   just for discussion, since it violates the idea of RMX to focus on
-   the transport, not on the content. It would also allow replay
-   attacks and not cover the envelope sender address or message
-
-
-
-Hadmut Danisch                Experimental                     [Page 16]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   header.
-
-6.4.  Transparent Challenge/Response
-
-   It would also be possible to implement a challenge-response
-   mechanism without modifying the syntax of SMTP. For example, the
-   receiving MTA could issue a challenge with it's very first greeting
-   message, the sending MTA could hide the response in the HELO
-   parameter and when the receiving MTA later learns the sender
-   envelope address, it could verify the response based on
-   informations in the RMX record.
-
-6.5.  SASL Challenge/Response
-
-   Modern SMTP implementations already include a SASL mechanisms,
-   which easily allows to plugin new authentication mechanisms. While
-   common SASL mechanisms require to use a previously shared password,
-   a new mechanism could perform a challenge response authentication
-   as a SASL method.
-
-
-
-
-
-
-7.  Encoding
-
-7.1.  Alternative encoding as TXT records
-
-   The main objection against the prior versions of this draft was
-   that it requires a new RR entry type and upgrading all DNS servers.
-
-   Therefore and alternative encoding is proposed. Instead of using a
-   new RR type, the TXT record type is used to contain the RMX record.
-   The records would simply look as described in the entry type
-   chapters above, e.g.
-
-      _rmx.danisch.de.   IN TXT "apl:relays.rackland.de"
-
-   To allow smooth introduction of RMX without the need to immediately
-   upgrade all DNS servers, all clients (which have to be newly
-   installed anyway) MUST support both the TXT and the RMX records. A
-   client has to perform an ANY or a TXT and a RMX query. Servers/zone
-   tables may currently use TXT entries but SHOULD use RMX entries in
-   future.
-
-7.2.  RMX Records
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 17]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-7.2.1.  Overall structure
-
-   Each entry starts with an octet containting the entry type and the
-   negation flag:
-
-      +---+---+---+---+---+---+---+---+------
-      | N |    Entry Type Code        | Parameters...
-      +---+---+---+---+---+---+---+---+------
-
-      N           If this bit (MSB) is set, an IP address
-                  matching this entry is not authorized,
-                  but explicitely rejected. See entry
-                  type descriptions for details.
-
-      Entry Type  A 7bit number simply determining the entry
-                  type.
-
-
-   Currently, entries do not have an explicit length field, the entry
-   length is determined implicitely by the entry type. Applications
-   are required to abort if an unknown entry type is found, instead of
-   skipping unknown entries.
-
-7.2.2.  Record encoding
-
-   A RMX record is simply a concatenation of RMX entries.
-
-7.2.3.  Encoding of IPv4 and IPv6 address ranges
-
-   After the entry type tag as described above, one octet follows
-   giving the length L of the bit sequence. Then a sequence of exactly
-   as many octets follows as needed to carry L bits of information (=
-   trunc((L+7)/8) ).
-
-      +---+---+---+---+---+---+---+---+
-      | N | Entry Type Code  (1 or 2) |
-      +---+---+---+---+---+---+---+---+
-      |         Length Field L        |
-      +---+---+---+---+---+---+---+---+
-      |           Bit Field           |
-      /        ((L+7)/8) Octets       /
-      +---+---+---+---+---+---+---+---+
-
-
-7.2.4.  Encoding of DNS
-
-   After the entry type tag immediately follows a DNS encoded and
-   compressed [3] domain name.
-
-
-
-Hadmut Danisch                Experimental                     [Page 18]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-      +---+---+---+---+---+---+---+---+
-      | N |  Entry Type Code  (3..5)  |
-      +---+---+---+---+---+---+---+---+
-      |         Length Field L        |
-      +---+---+---+---+---+---+---+---+
-      |  Encoded DNS                  |
-      /  Name as described in RFC1035 /
-      +---+---+---+---+---+---+---+---+
-
-   In contrast to earlier versions of this draft, the DNS name cannot
-   be compressed, since this would cause decompression errors when a
-   DNS server is part of the query chain which does not know this
-   particular RR type.
-
-7.2.5.  Encoding of unused and full query
-
-   These entries do not contain parameters and does not allow the
-   negation flag.  So the encoding is quite simple:
-
-      +---+---+---+---+---+---+---+---+
-      | 0 |  Entry Type Code  (6 or 7)|
-      +---+---+---+---+---+---+---+---+
-
-
-
-7.2.6.  Additional Records
-
-   In order to avoid the need of a second query to resolve the given
-   host name, a DNS server should enclose the A record for that domain
-   name in the additional section of the additional section of the DNS
-   reply, if the server happens to be authoritative.
-
-   In order to avoid the need of a second query to resolve the given
-   host name, a DNS server should enclose the APL record for that
-   domain name in the additional section of the additional section of
-   the DNS reply, if the server happens to be authoritative.
-
-
-
-8.  Message Headers
-
-   An RMX query must be followed by any kind of action depending on
-   the RMX result. One action might be to reject the message.  Another
-   action might be to add a header line to the message body, thus
-   allowing MUAs and delivery programs to filter or sort messages.
-
-   In future, the RMX result might be melted into the Received: header
-   line.
-
-
-
-Hadmut Danisch                Experimental                     [Page 19]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   The details of such entries are to be discussed. As a proposal the
-   following form is suggested:
-
-     X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
-
-   where
-
-   RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
-   "TempFail", "BadData", "Trusted".
-
-   ADDRESS is the IP address of the sending machine
-
-   HOST is the name of the machine performing the RMX query.
-
-   DATE is the date of the query.
-
-   MECHANISM is the RMX method used to authorize the sender.
-
-
-
-9.  SMTP error messages
-
-   If a message is rejected because of RMX records, an error message
-   should be issued which explains the details.  It is to be discussed
-   whether new SMTP error codes are to be defined.
-
-
-10.  Message relaying and forwarding
-
-10.1.  Problem description
-
-   Message forwarding and relaying means that an MTA which received an
-   e-mail by SMTP does not deliver it locally, but resends the message
-   - usually unchanged except for an additional Received header line
-   and maybe the recipient's address rewritten - to the next SMTP MTA.
-   Message forwarding is an essential functionality of e-mail
-   transport services, for example:
-
-     - Message transport from outer MX relay to the intranet
-     - Message forwarding and Cc-ing by .forward or .procmail-alike
-       mechanisms
-     - Mailing list processing
-     - Message reception by mail relays with low MX priority,
-       usually provided by third parties as a stand-by service
-       in case of relay failure or maintenance
-     - "Forwarding" and "Bouncing" as a MUA functionality
-
-   In all these cases a message is sent by SMTP from a host which is
-
-
-
-Hadmut Danisch                Experimental                     [Page 20]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   not covered by the original sender domain's RMX records.  While the
-   RMX records would forbid accepting this message, it still must be
-   accepted. The following subsections explain how to cope with
-   relaying.
-
-10.2.  Trusted relaying/forwarding
-
-   In some cases the receiving MTA trusts the sending MTA to not fake
-   messages and to already have checked the RMX records at message
-   reception. As a typical example, a company might have an outer mail
-   relay which receives messages from the Internet and checks the RMX
-   records. This relay then forwards the messages to the different
-   department's mail servers. It does not make sense for these
-   department mail servers to check the RMX record, since the RMX
-   records have already been checked and - since the message was
-   relayed by the outer relay - always would deny the message. In this
-   case there is a trust relationship between the department relays
-   and the outer relay.  So RMX checking is turned off for trusted
-   relays. In this example, the department relays would not check
-   messages from the outer relay (but for intranet security, they
-   could still check RMX records of the other departments sub-domains
-   to avoid internal forgery between departments).
-
-   Another common example are the low-priority MX relays, which
-   receive and cache e-mails when the high-priority relays are down.
-   In this case, the high-priority relay would trust the low-priority
-   relay to have verified the sender authorization and would not
-   perform another RMX verification (which would obviously fail).
-
-   When a relay forwards a message to a trusting machine, the envelope
-   sender address should remain unchanged.
-
-10.3.  Untrusted relaying/forwarding
-
-   If the receiving MTA does not trust the forwarding MTA, then there
-   is no chance to leave the sender envelope address unchanged. At a
-   first glance this might appear impracticable, but this is
-   absolutely necessary. If an untrusted MTA could claim to have
-   forwarded a message from a foreign sender address, it could have
-   forged the message as well. Spammers and forgers would just have to
-   act as such a relay.
-
-   Therefore, it is required that, when performing untrusted
-   forwarding, the envelope sender address has to be replaced by the
-   sender address of someone responsible for the relaying mechanism,
-   e.g. the owner of the mailing list or the mail address of the user
-   who's .forward caused the transmission. It is important to stress
-   that untrusted relaying/forwarding means taking over responsibility
-
-
-
-Hadmut Danisch                Experimental                     [Page 21]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   for the message.  It is the idea of RMX records to tie
-   responsibility to message transmission. Untrusted relaying without
-   replacing the sender address would mean to transmit without taking
-   responsibility.
-
-   The disadvantage is that the original sender address is lost.
-   Therefore, whenever a sender address replacement happens, the
-   Received-Line must contain the old address. Many of today's MTAs
-   already insert the envelope recipient address, but not the sender
-   address into the Received header line. It seems reasonable to
-   require every Received line to include both the sender and
-   recipient address of the incoming SMTP connection.
-
-
-11.  Security Considerations
-
-11.1.  Draft specific considerations
-
-11.1.1.  Authentication strength
-
-   It is important to stress, that the suggested method does not
-   provide high level security and does not completely prevent forged
-   e-mails or spam under any circumstances. It is a robust, but not
-   highly reliable and completely secure security mechanism. Keep in
-   mind that it is based on DNS, and DNS is not secure today.
-   Authorization is based on the IP address. The very same machine
-   with the very same IP address could be authorized to send e-mail
-   with a given sender address and sending spam at the same time.
-   Maybe because several users are logged in. Or because several
-   customers use the same relay of the same ISP, where one customer
-   could use the sender address of a different customer. It is up to
-   the ISP to prevent this or not. Machines can still be hijacked.
-   Spammers are also domain owners. They can simply use their own
-   domain and authorize themselves. You will always find people on the
-   world who do not care about security and open their relays and RMX
-   records for others to abuse them.  RMX is to be considered as a
-   very cheap and simple light weight mechanism, which can
-   nevertheless provide a significant improvement in mail security
-   against a certain class of attacks, until a successor of SMTP has
-   been defined and commonly accepted.
-
-11.1.2.  Where Authentication and Authorization end
-
-   Previous versions of RMX records did not cover the local part of
-   the e-mail address, i.e. what's on the left side of the @ sign.
-   This is still to be discussed. Authentication and authorization are
-   limited to the sending MTA's IP address. The authentication is
-   limited to the TCP functionality, which is sufficient for light
-
-
-
-Hadmut Danisch                Experimental                     [Page 22]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   weight authentication. The RMX records authorize the IP address of
-   the sending host only, not the particular sender of the message. So
-   if a machine is authorized to use sender addresses of more than a
-   single domain, the authentication scheme does not prevent that any
-   user on this machine can send with any of these domains. RMX is not
-   a substitute for the host security of the involved machines.
-
-   The proposed authentication scheme can be seen as a "half way
-   authentication": It does not track back an e-mail to the effective
-   sender. It tracks only half of the way, i. e. it tracks back to the
-   domain and it's DNS administrators who authorized that particular
-   sender IP address to use it for sending e-mail. How the party
-   responsible for that domain performs user authentication, whom it
-   grants access to, how it helds people responsible for abuse, is
-   completely left as the private business of those who are in charge
-   of that domain. So this draft does not interfere with the domain's
-   individual security policy or any legislation about such policies.
-   On the other hand, the proposed authentication scheme does not give
-   any statement about the nature and quality of the domain's security
-   policy. This is an essential feature of the proposal: E-mail
-   authentication must be deployed world wide, otherwise it won't do
-   the job. Any security scheme interfering with the local
-   legislations or the domain's security policy will not be accepted
-   and can't effectively deployed. Therefore, the security policy must
-   remain the domain's private business, no matter how lousy the
-   policy might be.
-
-   In order to achieve this and to make use of the only existing world
-   wide Internet directory scheme (DNS), the approach of this proposal
-   is to just ignore the local part of the sender address (i.e. what's
-   left of the @ part) and limit view to the domain part. After all,
-   that's what we do anyway when delivering to a given address with
-   SMTP.
-
-11.1.3.  Vulnerability of DNS
-
-   DNS is an essential part of the proposed authentication scheme,
-   since it requires any directory service, and DNS is currently the
-   only one available. Unfortunately, DNS is vulnerable and can be
-   spoofed and poisoned. This flaw is commonly known and weakens many
-   network services, but for reasons beyond that draft DNS has not
-   been significantly improved yet. After the first version of this
-   draft, I received several comments who asked me not to use DNS
-   because of its lack of security. I took this into consideration,
-   but came to the conclusion that this is unfeasible: Any
-   authentication scheme linked to some kind of symbolic identity (in
-   this case the domain name) needs some kind of infrastructure and
-   trusted assignment. There are basically two ways to do it: Do it
-
-
-
-Hadmut Danisch                Experimental                     [Page 23]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   yourself and trust nobody else, or let someone else do it. There
-   are methods to do it the former way, e.g. to give someone some kind
-   of authentication information after a first successful e-mail
-   exchange, e.g. some kind of cookie or special e-mail address. This
-   is certainly interesting and powerful, but it does not solve the
-   problem on a world wide scale and is far to complicated and error
-   prone for the average user, i. e. 99% of the users.
-
-   The latter method to let someone else do the symbolic name
-   assignment and create the authentication framework is well known.
-   It context of public key cryptography, this is called a Public Key
-   Infrastructure (PKI). On of the best known facts about PKIs is
-   that, until now, we don't have any covering a significant part of
-   the Internet. And we won't have any in near future. The complexity
-   is far too high, it is too expensive, and it involves cooperation
-   of every single user, which is simply unrealistic and extremely
-   error prone. So what do we have we can use? All we have is the DNS
-   and the Whois database. And we have countries who don't allow
-   cryptography. So the proposal was designed to use DNS without
-   cryptography. It does not avoid DNS because of its vulnerability,
-   it asks for a better DNS, but accepts the DNS as it is for the
-   moment. Currently there are two main threats caused by the DNS
-   weakness:
-
-      - A spammer/forger could spoof DNS in order to gain false
-        authorization to send fake e-mails.
-
-      - An attacker could spoof DNS in order to block delivery from
-        authorized machines, i. e. perform a Denial of Service attack.
-
-   The first one is rather unrealistic, because it would require an
-   average spammer to poison a significant part of the DNS servers of
-   its victims. A spammer sending messages to one million receipients
-   would need to poison at least 1-10% which is 10,000 to 100,000
-   receipient's DNS servers. This should be unfeasible in most cases.
-
-   In contrast, the second threat is a severe one. If an attacker
-   wanted to block messages from one company to another, he just needs
-   to poison the recipients DNS server with a wrong RMX record in
-   order to make the recipient's SMTP machine reject all messages. And
-   this is feasible since the attacker needs to poison only a single
-   DNS server. But does this make SMTP more vulnerable? No. Because
-   the attacker can already do even more without RMX. By poisoning the
-   sender's DNS server with wrong MX records, the attacker can also
-   block message delivery or even redirect the messages to the
-   attacker's machine, thus preventing any delivery error messages and
-   furthermore getting access to the messages.
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 24]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   As a consequence, e-mail delivery by SMTP requires a better DNS
-   anyway. The requirements are not significantly expanded by RMX.
-
-11.1.4.  Sneaking RMX attack?
-
-   While writing a test implementation, a certain kind of attack came
-   into my mind. I'm still not sure, whether this attack is possible
-   on any DNS server, but I believe it should be mentioned:
-
-   Imagine an unauthorized sender is sending a forged mail (e.g.
-   spam).  At connection time, before querying the RMX record, the
-   receiving MTA usually performs a PTR query for the IP address of
-   the sending MTA. If the sender has control over the authoritative
-   name server for that particular IP address, the sender could give a
-   normal PTR answer, but could append a wrong RMX, APL, or A record
-   in the additional section of the query. A subsequent RMX query
-   could receive wrong DNS data if the DNS server used by the
-   receiving MTA accepted those forged records.
-
-11.1.5.  Open SMTP relays
-
-   Open SMTP relays (i.e. machines who accept any e-mail message from
-   anyone and deliver to the world) abused by spammers are a one of
-   the main problems of spam defense and sender backtracking. In most
-   cases this problem just vanishes because foreign open relay
-   machines will not be covered by the RMX records of the forged
-   sender address. But there are two special cases:
-
-   If the spammer knows about a domain which authorizes this
-   particular machine, that domain can be used for forgery. But in
-   this case, the IP address of the relay machine and the RMX records
-   of the domain track back to the persons responsible. Both can be
-   demanded to fix the relay or remove the RMX record for this
-   machine. An open relay is a security flaw like leaving the machine
-   open for everybody to login and send random mails from inside. Once
-   the administrative persons refuse to solve the problem, they can be
-   identified as spammers and held responsible.
-
-   The second special case is when a domain authorizes all IP
-   addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
-   this case, open relays don't make things worse. It's up to the
-   recipient's MTA to reject mails from domains with loose security
-   policies.
-
-11.1.6.  Unforged Spam
-
-   This proposal does not prevent spam (which is, by the way, not yet
-   exactly defined), it prevents forgery. Since spam is against law
-
-
-
-Hadmut Danisch                Experimental                     [Page 25]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   and violates the recipients rights, spam depends on untracability
-   of the sender. In practice the sender forges the sender address
-   (other cases see below). This proposal is designed to detect such
-   forgeries.
-
-   However, the RMX approach is rendered ineffective, if the sender
-   doesn't forge. If the sender uses just a normal address of it's own
-   domain, this is just a plain, normal e-mail, which needs to be let
-   through. Since it is up to the human's taste whether this is spam
-   or not, there's no technical way to reliably identify this as spam.
-   But since the sender domain is known, this domain can be
-   blacklisted or legal steps can be gone into.
-
-11.1.7.  Reliability of Whois Entries
-
-   Once the RMX infrastructure gets deployed, what's the security
-   gain?  It allows to determine the domain which's DNS zone
-   authorized the sending machine. What's that good for? There are
-   some immediate uses of the domain name, e.g. in black- and
-   whitelisting. But in most cases this is just the starting point of
-   further investigations, either performed automatically before
-   message acceptance, or manually after spam has been received and
-   complainted about.
-
-   The next step after determining the domain is determining the
-   people responsible for this domain. This can sometimes be achieved
-   by querying the Whois databases. Unfortunately, many whois entries
-   are useless because they are incomplete, wrong, obsolete, or in
-   uncommon languages. Furthermore, there are several formats of
-   address informations which make it difficult to automatically
-   extract the address. Sometimes the whois entry identifies the
-   provider and not the owner of the domain. Whois servers are not
-   built for high availability and sometimes unreachable.
-
-   Therefore, a mandatory standard is required about the contents and
-   the format of whois entries, and the availability of the servers.
-   After receiving the MAIL FROM SMTP command with the sender envelope
-   address, the receiving MTA could check the RMX record and Whois
-   entry. If it doesn't point to a real human, the message could be
-   rejected and an error message like "Ask your provider to fix your
-   Whois entry" could be issued. Obviously, domain providers must be
-   held responsible for wrong entries. It might still be acceptable to
-   allow anonymous domains, i. e. domains which don't point to a
-   responsible human. But it is the receivers choice to accept e-mails
-   from such domains or not.
-
-11.1.8.  Hazards for Freedom of Speech
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 26]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   Currently, some governments try to enforce limitations of internet
-   traffic in order to cut unwanted content providers from the
-   network. Some of these governments try to hide a whole country
-   behind firewalls, others try to force Internet providers to poison
-   DNS servers with wrong A records for web servers, e.g. one county
-   administration in Germany tries to do so. If message reception
-   depends on DNS entries, the same governments will try to block not
-   only HTTP, but SMTP also.
-
-   However, since most MTAs already reject messages from unresolvable
-   domain names this is not a new threat.
-
-11.2.  General Considerations about spam defense
-
-   After discussing security requirements of the proposal, now the
-   security advantages of the RMX approach over content based filters
-   will be explained. Basically, there are three kinds of content
-   filters:
-
-      - Those who upload the message or some digest to an external
-        third party and ask "Is this spam"?
-
-      - Those who download a set of patterns and rules from a third
-        party and apply this set to incoming messages in order to
-        determine whether it is spam.
-
-      - Those who are independent and don't contact any third party,
-        but try to learn themselves what is spam and what isn't.
-
-
-   The message filters provided by some e-mail service providers are
-   usually not a kind of their own, but a combination of the first two
-   kinds.
-
-11.2.1.  Action vs. reaction
-
-   Content filters suffer from a fundamental design problem: They are
-   late. They need to see some content of the same kind before in
-   order to learn and to block further distribution.
-
-   This works for viruses and worms, which redistribute. This doesn't
-   work for spam, since spam is usually not redistributed after the
-   first delivery. When the filters have learned or downloaded new
-   pattern sets, it's too late.
-
-   This proposal does not have this problem.
-
-11.2.2.  Content based Denial of Service attacks
-
-
-
-Hadmut Danisch                Experimental                     [Page 27]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   All three kinds of content filters, but especially the second and
-   the third kind are vulnerable to content based Denial of Service
-   attacks.
-
-   If some kind of third party (e.g. non-democratic government,
-   intellectual property warriors, religious groups, military, secret
-   services, patriots, public relation agents, etc.) wants certain
-   contents not to be distributed, they could either poison the
-   pattern/rule databases or feed wrong sets to particular receivers.
-
-   Such pattern/rule sets are the perfect tool for censoring e-mail
-   traffic and denial of service attacks by governments and other
-   parties, and a similar threat are virus filters. E. g. the content
-   industry could demand to teach all virus and spam filters to delete
-   all e-mails containing the URL of an MP3 web server outside the
-   legislations. Software manufacturers could try to block all e-mails
-   containing software license keys, thus trying to make unallowed
-   distribution more difficult. Governments could try to block
-   distribution of unwanted informations.
-
-   This proposal does not have this problem.
-
-
-12.  Privacy Considerations
-
-   (It was proposed on the 56th IETF meeting to have a privacy section
-   in drafts and RFCs.)
-
-12.1.  Draft specific considerations
-
-12.1.1.  No content leaking
-
-   Since the RMX approach doesn't touch the contents of a message in
-   any way, there is obviously no way of leaking out any information
-   about the content of the message. RMX is based solely on the
-   envelope recipient address. However, methods to fix problems not
-   covered by RMX might allow content leaking, e.g. if the acceptance
-   of a message with an empty sender address requires the reference to
-   the message id of an e-mail recently sent, this allows an attacker
-   to verify whether a certain message was delivered from there.
-
-12.1.2.  Message reception and sender domain
-
-   Message delivery triggers RMX and APL requests by the recipient.
-   Thus, the admin of the DNS server or an eavesdropper could learn
-   that the given machine has just received a message with a sender
-   from this address, even if the SMTP traffic itself had been
-   encrypted.
-
-
-
-Hadmut Danisch                Experimental                     [Page 28]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   However, most of today's MTAs do query the MX and A records of the
-   domain after the MAIL FROM command, so this is not a real new
-   threat.
-
-12.1.3.  Network structure
-
-   Since RMX and its associated APL records provide a complete list of
-   all IP addresses of hosts authorized to send messages from this
-   address, they do reveal informations about the network structure
-   and maybe the lifestyle of the domain owner, since a growing number
-   of domains are owned by single persons or families. E.g. the RMX
-   records could reveal where someone has his job or spends his time
-   at weekends.
-
-   If such informations are to be kept secret, it is the user's job to
-   not sent e-mails from there and to relay them from non-compromising
-   IP addresses.
-
-12.1.4.  Owner information distribution
-
-   As described above, RMX depends partly on the reliability of the
-   whois database entries. It does not make anonymous domains
-   impossible, but it requires to keep the database entries "true", i.
-   e. if a whois entry does not contain informations about the
-   responsible person, this must be unambigously labeled as anonymous.
-   It must not contain fake names and addresses to pretend a non-
-   existing person. However, since most Internet users on the world
-   feel extremely annoyed by spam, they will urge their MTA admin to
-   reject messages from anonymous domains. The domain owner will have
-   the choice to either remain anonymous but be not able to send e-
-   mail to everyone in the world, or to be able but to reveal his
-   identity to everyone on the world.
-
-   It would be possible to provide whois-like services only to
-   recipients of recent messages, but this would make things too
-   complicated to be commonly adopted.
-
-12.2.  General Considerations about spam defense
-
-12.2.1.  Content leaking of content filters
-
-   As described above in the Security chapter, there are spam filters
-   which inherently allow leakage of the message body. Those filters
-   upload either the message body, or in most cases just some kind of
-   checksum to a third party, which replies whether this is to be seen
-   as spam or not. The idea is to keep a databases of all digests of
-   all messages.  If a message is sent more often than some threshold,
-   it is to be considered as a mass mail and therefore tagged as spam.
-
-
-
-Hadmut Danisch                Experimental                     [Page 29]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   While the digest itself does not reveal the content of the message,
-   it perfectly reveals where a particular message has been delivered
-   to. If a government finds just a single unwanted message, if a
-   software manufacturer finds a single message with a stolen product
-   license key, if someone finds a message with unpatriotic content,
-   it takes just a single database lookup to get a list of all people
-   who received this particular message. Content filters with digest
-   upload are the perfect "Big Brother".
-
-12.2.2.  Black- and Whitelists
-
-   Some proposals against spam are based on a central database of
-   white- or blacklisted IP addresses, Sender names, Message IDs or
-   whatever. Again, there is a central database which learns who has
-   received which e-mail or from which sender with every query. This
-   allows tracking relations between persons, which is also a breach
-   of privacy.
-
-
-
-13.  Deployment Considerations
-
-13.1.  Compatibility
-
-13.1.1.  Compatibility with old mail receivers
-
-   Since the suggested extension doesn't change the SMTP protocol at
-   all, it is fully compatible with old mail receivers. They simply
-   don't ask for the RMX records and don't perform the check.
-
-13.1.2.  Compatibility with old mail senders
-
-   Since the SMTP protocol is unchanged and the SMTP sender is not
-   involved in the check, the method is fully compatible with old mail
-   senders.
-
-13.1.3.  Compatibility with old DNS clients
-
-   Since the RMX is a new RR, the existing DNS protocol and zone
-   informations remain completely untouched.
-
-   If RMX is provided as a TXT record instead, it must be ensured that
-   no other software is misinterpreting this entry.
-
-13.1.4.  Compatibility with old DNS servers
-
-   Full compatibility: If the server does not support RMX records, RMX
-   in TXT records can be used.
-
-
-
-Hadmut Danisch                Experimental                     [Page 30]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-13.2.  Enforcement policy
-
-   Obviously, for reasons of backward compatibility and smooth
-   introduction of this scheme, RMX records can't be required
-   immediately. Domains without RMX records must temporarily be
-   treated the same way as they are treated right now, i.e. e-mail
-   must be accepted from anywhere. But once the scheme becomes
-   sufficiently widespread, mail relays can start to refuse e-mails
-   with sender addresses from domains without RMX records, thus
-   forcing the owner of the domain to include a statement of
-   authorization into the domain's zone table.  Domain owners will
-   still be free to have an RMX record with a network and mask
-   0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
-   On the other hand, mail receivers will be free to refuse mails from
-   domains without RMX records or RMX records which are too loose.
-   Advanced MTAs might have a configuration option to set the maximum
-   number of IP addresses authorized to use a domain. E-mails from a
-   domain, which's RMX records exceed this limit, would be rejected.
-   For example, a relay could reject e-mails from domains which
-   authorize more than 8 IP addresses. That allows to accept e-mails
-   only from domains with a reasonable security policy.
-
-
-
-14.  General considerations about fighting spam
-
-   Is there a concise technical solution against spam? Yes.
-
-   Will it be deployed? Certainly not.
-
-   Why not? Because of the strong non-technical interests of several
-   parties against a solution to the problem, as described below.
-   Since these are non-technical reasons, they might be beyond the
-   scope of such a draft. But since they are the main problems that
-   prevent fighting spam, it is unavoidable to address them. This
-   chapter exists temporarily only and should support the discussion
-   of solutions. It is not supposed to be included in a later RFC.
-
-14.1.  The economical problem
-
-   As has been recently illustrated in the initial session of the
-   IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
-   sending spam is a business with significant revenues.
-
-   But a much bigger business is selling Anti-Spam software. This is a
-   billion dollar market, and it is rapidly growing. Any simple and
-   effective solution against spam would defeat revenues and drive
-   several companies into bankrupt, would make consultants jobless.
-
-
-
-Hadmut Danisch                Experimental                     [Page 31]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   Therefore, spam is essential for the Anti-Spam business. If there
-   is no spam, then no Anti-Spam software can be sold, similar to the
-   Anti-Virus business. There are extremely strong efforts to keep
-   this market growing. Viruses, Worms, and now spam are just perfect
-   to keep this market alive: It is not sufficient to just buy a
-   software. Databases need to be updated continuously, thus making
-   the cash flow continuously. Have a single, simple, and permanent
-   solution to the problem and - boom - this billion dollar market is
-   dead.
-
-   That's one of the reasons why people are expected to live with
-   spam. They have to live with it to make them buy Anti-Spam
-   software.  Content filters are perfect products to keep this market
-   alive.
-
-14.2.  The POP problem
-
-   Another problem is the history of mail delivery. Once upon a time,
-   there used to be very few SMTP relays which handled the e-mail
-   traffic of all the world, and everybody was happy with that. Then
-   odd things like Personal Computers, which are sometimes switched
-   off, portable computers, dynamicly assigned IP addresses, IP access
-   from hotel rooms, etc. was invented, and people became unhappy,
-   because SMTP does not support delivery to such machines. To make
-   them happy again, the Post Office Protocol[4] was invented, which
-   turned the last part of message delivery from SMTP's push style
-   into a pull style, thus making virtually every computer on the
-   world with any random IP address a potential receiver of mails for
-   random domains. Unfortunately, only receiving e-mail was covered,
-   but sending e-mail was left to SMTP.
-
-   The result is that today we have only very few SMTP relays pointed
-   to by MX records, but an extreme number of hosts sending e-mail
-   with SMTP from any IP address with sender addresses from any
-   domain. Mail delivery has become very asymmetric. Insecurity,
-   especially forgeability, has become an essential part of mail
-   transport.
-
-   That problem could easily be fixed: Use protocols which allow
-   uploading of messages to be delivered. If a host doesn't receive
-   messages by SMTP, it shouldn't deliver by SMTP.  Mail delivery
-   should go the same way back that incoming mail went in.  This is
-   not a limitation to those people on the road who plug their
-   portable computer in any hotel room's phone plug and use any
-   provider. If there is a POP server granting download access from
-   anywhere, then the same server should be ready to accept uploading
-   of outgoing messages.
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 32]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   But as I saw from the comments on the first version of this draft,
-   people religiously insist on sending e-mail with their domain from
-   any computer with any IP address in the world, e.g. when visiting a
-   friend using her computer. It appears to be impossible to convince
-   people that stopping mail forgery requires every one of them to
-   give up forging.
-
-14.3.  The network structure problem
-
-   A subsequent problem is that many organisations failed to implement
-   a proper mail delivery structure and heavily based their network on
-   this asymmetry. I received harsh comments from Universities who
-   were unable to give their network a good structure. While they do
-   have a central mail relay for incoming mail to the universities
-   domain, they developed a structure where every member of the
-   University randomly sends e-mails with that University's domain as
-   a sender address from home or everywhere in the world with any
-   dynamically assigned IP address from any provider. So this domain
-   is to be used from every possible IP address on earth, and they are
-   unable to operate any authentication scheme. Furthermore, they were
-   unable to understand that such a policy heavily supports spam and
-   that they have to expect that people don't accept such e-mails
-   anymore once they become blacklisted.
-
-   As long as organisations insist on having such policies, spammers
-   will have a perfect playground.
-
-14.4.  The mentality problem
-
-   Another problem is the mentality of many internet users of certain
-   countries. I received harsh comments from people who strongly
-   insisted on the freedom to send any e-mail with any sender address
-   from anywhere, and who heavily refused any kind of authentication
-   step or any limitation, because they claimed that this would
-   infringe their constitutional "Freedom of speech". They are
-   undeviatingly convinced that "Freedom of speech" guarantees their
-   right to talk to everybody with any sender address, and that is has
-   to be kept the recipient's own problem to sort out what he doesn't
-   want to read - on the recipient's expense.
-
-   It requires a clear statement that the constitutional "Freedom of
-   Speech" does not cover molesting people with unsolicited e-mail
-   with forged sender address.
-
-14.5.  The identity problem
-
-   How does one fight against mail forgery? With authentication.  What
-   is authentication? In simple words: Making sure that the sender's
-
-
-
-Hadmut Danisch                Experimental                     [Page 33]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   real identity meets the recipients idea of who is the sender, based
-   on the sender address which came with the message.
-
-   What is identity? It is the main problem. Several countries have
-   different ideas of "identity", which turn out to be somehow
-   incompatible. In some countries people have identity cards and
-   never change their name and birthday. Identities are created by
-   human birth, not by identity changes. Other countries do not have
-   such a tight idea about identity. People's temporary identity is
-   based on nothing more than a driving license and a social security
-   number.  With this background, it is virtually impossible to create
-   a trustworthy PKI covering all Internet users. I learned that it is
-   extremely difficult to convince some people to give up random e-
-   mail sending.
-
-14.6.  The multi-legislation problem
-
-   Many proposals about fighting spam are feasible under certain
-   legislations only, and are inacceptable under some of the
-   legislations. But a world wide applicable method is required.
-   That's why the approach to ask everone on the world to sign
-   messages with cryptographic keys is not feasible.
-
-
-Implementation and further Information
-
-   Further informations and a test implementation are available at
-
-      http://www.danisch.de/work/security/antispam.html
-      http://www.danisch.de/software/rmx/
-
-
-   Additional informations and a technology overview are also
-   available at
-
-      http://www.mikerubel.org/computers/rmx_records/
-
-
-References
-
-
-
-1.   S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
-     els," RFC 2119 (March 1997).
-
-2.   J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
-
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 34]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-3.   P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
-     RFC 1035 (November 1987).
-
-4.   J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
-     (May 1996).
-
-
-Draft History
-
-   00  Dec 2002
-   01  Apr 2003
-   02  Jun 2003
-   03  Oct 2003
-
-Author's Address
-
-   Hadmut Danisch
-
-   Tennesseeallee 58
-   76149 Karlsruhe
-   Germany
-
-   Phone:  ++49-721-843004 or ++49-351-4850477
-   E-Mail: rfc@danisch.de
-
-Comments
-
-   Please send comments to rfc@danisch.de.
-
-Expiry
-
-   This drafts expires on Apr 1, 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 35]
-
diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt
deleted file mode 100644
index 7b5e8cc4455b..000000000000
--- a/doc/draft/draft-dnsext-opcode-discover-02.txt
+++ /dev/null
@@ -1,241 +0,0 @@
-
-IETF DNSEXT WG                                             Bill Manning
-draft-dnsext-opcode-discover-02.txt                              ep.net
-                                                             Paul Vixie
-                                                                    ISC
-                                                            13 Oct 2003
-
-
-                         The DISCOVER opcode
-
-This document is an Internet-Draft and is subject to all provisions of
-Section 10 of RFC2026.
-
-Comments may be submitted to the group mailing list at "mdns@zocalo.net"
-or the authors.
-
-Distribution of this memo is unlimited.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months and
-may be updated, replaced, or obsoleted by other documents at any time.  It
-is inappropriate to use Internet-Drafts as reference material or to cite
-them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119
-
-0. Abstract:
-
-   The QUERY opcode in the DNS is designed for unicast. With the
-   development of multicast capabilities in the DNS, it is desireable
-   to have a more robust opcode for server interactions since a single
-   request may generate replies from multiple responders. So DISCOVER
-   is defined to deal with replies from multiple responders.
-
-   As such, this document extends the core DNS specifications to allow
-   clients to have a method for coping with replies from multiple
-   responders. Use of this new opcode may facilitate DNS operations in
-   modern networking topologies. A prototype of the DISCOVER opcode
-   was developed during the TBDS project (1999-2000), funded under DARPA
-   grant F30602-99-1-0523.
-
-1. Introduction:
-
-   This document describes an experimental extension to the DNS to receive
-   multiple responses which is the likely result when using DNS that has
-   enabled multicast queries.  This approach was developed as part of the
-   TBDS research project, funded under DARPA grant F30602-99-1-0523.  The
-   full processing rules used by TBDS are documented here for possible
-   incorporation in a future revision of the DNS specification."
-
-2. Method:
-
-        DISCOVER works like QUERY except:
-
-        1. it can be sent to a broadcast or multicast destination. QUERY
-           isn't defined for non-unicast, and arguably shouldn't be.
-
-        2. the Question section, if present, has 
-           tuples. TBDS tried to augment this structure as follows:
-           . While this worked for our purposes in
-           TBDS, it is cleaner to place the SRV question in a separate pass.
-
-        3. if QDCOUNT equals 0 then only servers willing to do recursion should
-           answer. Other servers must silently discard the DISCOVER request.
-
-        4. if QDCOUNT is not equal to 0 then only servers who are authoritative
-           for the zones named by some QNAME should answer.
-
-        5. responses may echo the request's Question section or leave it blank,
-           just like QUERY.
-
-        6. responses have standard Answer, Authority, and Additional sections.
-           e.g. the response is the same as that to a QUERY. It is desireable
-           that zero content answers not be sent to avoid badly formed or
-           unfulfilled requests. Responses should be sent to the unicast
-           address of the requester and the source address should reflect
-           the unicast address of the responder.
-
-   Example usage for gethostby{name,addr}-style requestors:
-
-        Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
-        ip6.arpa domain.
-
-        DISCOVER whether anyone in-scope is authoritative for this zone.
-
-                If so, query these authoritative servers for local
-                in-addr/ip6 names.
-
-        If not, DISCOVER whether there are recursive servers available.
-
-                If so, query these recursive servers for local
-                in-addr/ip6 names.
-
-        So, a node will issue a multicast request with the DISCOVER opcode at
-        some particular multicast scope.  Then determine, from the replies,
-        whether there are any DNS servers which are authoritative (or support
-        recursion) for the zone. Replies to DISCOVER requests MUST set the
-        Recursion Available (RA) flag in the DNS message header.
-
-        It is important to recognize that a requester must be prepared to
-        receive multiple replies from multiple responders. We expect that
-        there will be a single response per responder.
-
-        Once one learns a host's FQDN by the above means, repeat the process
-        for discovering the closest enclosing authoritative server of such
-        local name.
-
-        Cache all NS and A data learned in this process, respecting TTL's.
-
-   TBDS usage for SRV requestors:
-
-        Do the gethostbyaddr() and gethostbyname() on one's own link-local
-        address, using the above process.
-
-        Assume that the closest enclosing zone for which an authority server
-        answers an in-scope DISCOVER packet is "this host's parent domain".
-
-        Compute the SRV name as _service._transport.*.parentdomain.
-
-        This is a change to the definition as defined in RFC 1034.
-        A wildcard label ("*") in the QNAME used in a DNS message with
-        opcode DISCOVER SHOULD be evaluated with special rules.  The
-        wildcard matches any label for which the DNS server data is
-        authoritative.  For example 'x.*.example.com.' would match
-        'x.y.example.com.' and 'x.yy.example.com.' provided that the
-        server was authoritative for 'example.com.'  In this particular
-        case, we suggest the follwing considerations be made:
-
-   getservbyname() can be satisfied by issuing a request with
-   this computed SRV name.  This structure can be
-   populated by values returned from a request as follows:
-
-        s_name    The name of the service, "_service" without the
-                  preceding underscore.
-        s_aliases The names returned in the SRV RRs in replies
-                  to the query.
-        s_port    The port number in the SRV RRs replies to the
-                  query.  If these port numbers disagree - one
-                  of the port numbers is chosen, and only those
-                  names which correspond are returned.
-        s_proto   The transport protocol from named by the
-                  "_transport" label, without the preceding
-                  underscore.
-
-        Send SRV query for this name to discovered local authoritative servers.
-
-     Usage for disconnected networks with no authoritative servers:
-
-        Hosts should run a "stub server" which acts as though its FQDN is a
-        zone name.  Computed SOA gives the host's FQDN as MNAME, "." as the
-        ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
-        and the other timers.  Compute NS as the host's FQDN.  Compute the
-        glue as the host's link-local address. Or Hosts may run a
-        "DNS stub server" which acts as though its FQDN is a zone name.  The
-        rules governing the behavior of this stub server are given elsewhere
-        [1] [2].
-
-        Such stub servers should answer DISCOVER packets for its zone, and
-        will be found by the iterative "discover closest enclosing authority
-        server" by DISCOVER clients, either in the gethostbyname() or SRV
-        cases described above.  Note that stub servers only answer with
-        zone names which exactly match QNAME's, not with zone names which
-        are owned by QNAME's.
-
-   The main deviation from the DNS[3][4] model is that a host (like, say, a
-   printer offering LPD services) has a DNS server which answers authoritatively
-   for something which hasn't been delegated to it.  However, the only way that
-   such DNS servers can be discovered is with a new opcode, DISCOVER, which
-   is explicitly defined to discover undelegated zones for tightly scoped
-   purposes.  Therefore this isn't officially a violation of DNS's coherency
-   principles. In some cases a responder to DISCOVER may not be traditional
-   DNS software, it could be special purpose software.
-
-3. IANA Considerations
-
-        As a new opcode, the IANA will need to assign a numeric value
-        for the memnonic. The last OPCODE assigned was "5", for UPDATE.
-        Test implementations have used OPCODE "6".
-
-4. Security Considerations
-
-        No new security considerations are known to be introduced with any new
-        opcode, however using multicast for service discovery has the potential
-        for denial of service, primarly from flooding attacks. It may also be
-        possible to enable deliberate misconfiguration of clients simply by
-        running a malicious DNS resolver that claims to be authoritative for
-        things that it is not. One possible way to mitigate this effect is by
-        use of credentials, such as CERT resource records within an RR set.
-        The TBDS project took this approach.
-
-5. Attribution:
-
-        This material was generated in discussions on the mdns mailing list
-hosted by Zocalo in March 2000. Updated by discussion in September/October
-2003.  David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
-Erik Guttman, Bill Manning and Paul Vixie were active contributors.
-
-6. Author's Address
-
-   Bill Manning
-   PO 12317
-   Marina del Rey, CA. 90295
-   +1.310.322.8102
-   bmanning@karoshi.com
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-   +1 650 779 7001
-   
-
-7. References
-
-Informational References:
-
-[1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
-        draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
-
-[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
-        draft-manning-dnsext-mdns-00.txt,  August 2000.  Expired.
-
-Normative References:
-[3]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
-        RFC 1034, November 1987.
-[4]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
-        RFC 1035, November 1987
-
-        ----------------------------EOL-----------------------
-
diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt
deleted file mode 100644
index 224e7ad1697e..000000000000
--- a/doc/draft/draft-durand-dnsop-dynreverse-00.txt
+++ /dev/null
@@ -1,240 +0,0 @@
-Internet Engineering Task Force                             Alain Durand
-INTERNET-DRAFT                                          SUN Microsystems
-Feb 21, 2003
-Expires Aug 2, 2003
-
-
-
-                Dynamic reverse DNS for IPv6
-              
-
-
-
-Status of this memo
-
-
-   This memo provides information to the Internet community.  It does
-   not specify an Internet standard of any kind.  This memo is in full
-   conformance with all provisions of Section 10 of RFC2026 [RFC2026].
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-
-Abstract
-
-   This document describes a method to dynamically generate PTR records
-   and corresponding A or AAAA records when the reverse path DNS tree is
-   not populated.
-
-   A special domain dynrev.arpa. is reserved for that purpose.
-
-
-1. Introduction
-
-   In IPv4, the reverse path tree of the DNS under in-addr.arpa.
-   although not perfectly maintained, is still mostly usable and its
-   existence is important for a number of applications that relies on
-   its existence and decent status.  Some applications performs some
-   (very) weak security checks based on it. Mail relays relies on it for
-   some anti-spams checks an some FTP server will not let you in unless
-   your IP address resolve properly with a PTR record.
-
-   IPv6 addresses being much longer (and cumbersome) than IPv4
-   addresses, it is to fear that the reverse path tree under ip6.arpa.
-   would not be as well maintained.  Also, tools like 6to4, Isatap and
-   others have made creative use of the 128 bits of an IPv6 address to
-   automatically embed an IPv4 address to enable seamless connection to
-   the IPv6 Internet. However, no provision has been made to make sure
-   the reverse path tree gets automatically updated as well for those
-   new IPv6 addresses.  One step furter, RFC3041 describes a mechanism
-   to basically use random bits in the bottom part of an IPv6 address to
-   preserver anonymity. If those addresses are to resolve in the reverse
-   path tree, it obviously has to be with anonymous data as well.
-   Another point to note is that home customer ISPs in IPv4 have a
-   current practice to pre-populate the reverse path tree with names
-   automatically derived from the IP addresses. This practice is no
-   longer possible in IPv6, where IP address allocation is not dense as
-   it is the case in IPv4. The mere size of typical customer allocation
-   (2^48 according to the recommendation of RFC3177) makes it
-   impossible.
-
-   Applications that check the existence of PTR records usually follow
-   this by checking if the name pointed by the PTR resolve in a A (or
-   AAAA for IPv6) that match the original IP address. Thus the forward
-   path tree must also include the corresponding data.
-
-   One simple approach of this problem is to simply declare the usage of
-   the reverse path DNS as described above obsolete.  The author believe
-   this is too strong an approach for now.
-
-   Similarly, a completely different approach would be to deprecate the
-   usage of DNS for the reverse tree altogether and replace it by
-   something inspired from ICMP name-info messages. The author believes
-   that this approached is an important departure from the current
-   practise and thus not very realistic.  Also, there are some concerns
-   about the the security implications of this method as any node could
-   easily impersonate any name. This approach would fundamentally change
-   the underlying assumption of "I trust what has been put in the DNS by
-   the local administrators" to "I trust what has been configured on
-   each machine I query directly".
-
-
-
-2. Dynamic record generation
-
-   If static pre-population of the tree is not possible anymore and data
-   still need to be returned to applications using getnameinfo(), the
-   alternative is dynamic record generation.  This can be done is two
-   places: in the DNS servers responsible for the allocated space (/64
-   or /48) in the ip6.arpa. domain.  or in the DNS resolvers (either the
-   sub resolver library or the recursive DNS server).
-
-   2.1. On the resolver side.
-
-   The resolver, either in the recursive DNS server or in the stub
-   library could theoretically generate this data.
-
-   In case DNSsec is in place, the recursive DNS server would have to
-   pretend these records are authentic.
-
-   If the synthesis is done in the stub-resolver library, no record
-   needs to be actually generated, only the right information needs to
-   be passed to getnameinfo() and getaddrinfo().  If the synthesis is
-   done in the recursive DNS server, no modification is required to
-   existing stub resolvers.
-
-
-2.2. On the server side.
-
-   PTR records could be generated automatically by the server
-   responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
-   prefixes or basically anything in between) when static data is not
-   available.
-
-   There could be impact on DNSsec as the zone or some parts of the zone
-   may need to be resigned each time a DNS query is made for an
-   unpopulated address. This can be seen as a DOS attack on a DNSsec
-   zone, so server side synthesis is not recommended if DNSsec is
-   deployed.
-
-
-
-3. Synthesis
-
-   The algorithm is simple: Do the normal queries. If the query returns
-   No such domain, replace this answer by the synthetized one if
-   possible.
-
-3.1. PTR synthesis
-
-   The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
-   where [X] is any valid DNS name.
-
-   The fact that the synthetized PTR points to the dynrev.arpa. domain
-   is an indication to the applications that this record has been
-   dynamically generated.
-
-
-3.2. A synthesis
-
-   If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
-   record for the string [X].dynrev.arpa. which value is d.c.b.a. with
-   a,b,c & d being integer [0..255]
-
-
-3.3. AAAA synthesis
-
-   If [X] is in the form
-   a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
-   addr.arpa, one can synthetized a AAAA record for the string
-   [X].dynrev.arpa. which value is
-   FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
-   a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
-
-
-3.4. Server side synthesis
-
-   If synthesis is done on the server side, PTR could be set not to use
-   the dynrev.arpa domain but the local domain name instead.  It culd be
-   for instance dynrev.mydomain.com.
-
-   Note also that server side synthesis is not incompatible with
-   resolver side synthesis.
-
-
-
-4. IANA considerations
-
-   The dynrev.arpa. domain is reserved for the purpose of this document.
-
-
-
-5. Security considerations
-
-   Section 2. discusses the the interactions with DNSsec.
-
-
-
-6. Authors addresses
-
-   Alain Durand
-   SUN Microsystems, Inc
-   17, Network Circle
-   UMPK17-202
-   Menlo Park, CA 94025
-   USA
-   Mail: Alain.Durand@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt
new file mode 100644
index 000000000000..f15b069b5ba7
--- /dev/null
+++ b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt
@@ -0,0 +1,785 @@
+
+
+
+IPv6 Maintenance Working Group                               S. Kawamura
+Internet-Draft                                         NEC BIGLOBE, Ltd.
+Intended status: Informational                              M. Kawashima
+Expires: April 21, 2010                         NEC AccessTechnica, Ltd.
+                                                        October 18, 2009
+
+
+         A Recommendation for IPv6 Address Text Representation
+              draft-ietf-6man-text-addr-representation-01
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 April 21, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   As IPv6 network grows, there will be more engineers and also non-
+   engineers who will have the need to use an IPv6 address in text.
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                 [Page 1]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+   While the IPv6 address architecture RFC 4291 section 2.2 depicts a
+   flexible model for text representation of an IPv6 address, this
+   flexibility has been causing problems for operators, system
+   engineers, and users.  This document will describe the problems that
+   a flexible text representation has been causing.  This document also
+   recommends a canonical representation format that best avoids
+   confusion.  It is expected that the canonical format is followed by
+   humans and systems when representing IPv6 addresses as text, but all
+   implementations must accept and be able to handle any legitimate
+   RFC4291 format.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
+   2.  Text Representation Flexibility of RFC4291 . . . . . . . . . .  4
+     2.1.  Leading Zeros in a 16 Bit Field  . . . . . . . . . . . . .  4
+     2.2.  Zero Compression . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Uppercase or Lowercase . . . . . . . . . . . . . . . . . .  5
+   3.  Problems Encountered with the Flexible Model . . . . . . . . .  6
+     3.1.  Searching  . . . . . . . . . . . . . . . . . . . . . . . .  6
+       3.1.1.  General Summary  . . . . . . . . . . . . . . . . . . .  6
+       3.1.2.  Searching Spreadsheets and Text Files  . . . . . . . .  6
+       3.1.3.  Searching with Whois . . . . . . . . . . . . . . . . .  6
+       3.1.4.  Searching for an Address in a Network Diagram  . . . .  7
+     3.2.  Parsing and Modifying  . . . . . . . . . . . . . . . . . .  7
+       3.2.1.  General Summary  . . . . . . . . . . . . . . . . . . .  7
+       3.2.2.  Logging  . . . . . . . . . . . . . . . . . . . . . . .  7
+       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  8
+       3.2.4.  Auditing: Case 2 . . . . . . . . . . . . . . . . . . .  8
+       3.2.5.  Verification . . . . . . . . . . . . . . . . . . . . .  8
+       3.2.6.  Unexpected Modifying . . . . . . . . . . . . . . . . .  8
+     3.3.  Operating  . . . . . . . . . . . . . . . . . . . . . . . .  8
+       3.3.1.  General Summary  . . . . . . . . . . . . . . . . . . .  8
+       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  9
+       3.3.3.  Abuse  . . . . . . . . . . . . . . . . . . . . . . . .  9
+     3.4.  Other Minor Problems . . . . . . . . . . . . . . . . . . .  9
+       3.4.1.  Changing Platforms . . . . . . . . . . . . . . . . . .  9
+       3.4.2.  Preference in Documentation  . . . . . . . . . . . . .  9
+       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . . 10
+   4.  A Recommendation for IPv6 Text Representation  . . . . . . . . 10
+     4.1.  Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
+     4.2.  "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
+       4.2.1.  Shorten As Much As Possible  . . . . . . . . . . . . . 10
+       4.2.2.  Handling One 16 Bit 0 Field  . . . . . . . . . . . . . 10
+       4.2.3.  Choice in Placement of "::"  . . . . . . . . . . . . . 10
+     4.3.  Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                 [Page 2]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+   5.  Text Representation of Special Addresses . . . . . . . . . . . 11
+   6.  Notes on Combining IPv6 Addresses with Port Numbers  . . . . . 11
+   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  For Developers  . . . . . . . . . . . . . . . . . . . 13
+   Appendix B.  Prefix Issues . . . . . . . . . . . . . . . . . . . . 13
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                 [Page 3]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+1.  Introduction
+
+   A single IPv6 address can be text represented in many ways.  Examples
+   are shown below.
+
+      2001:db8:0:0:1:0:0:1
+
+      2001:0db8:0:0:1:0:0:1
+
+      2001:db8::1:0:0:1
+
+      2001:db8::0:1:0:0:1
+
+      2001:0db8::1:0:0:1
+
+      2001:db8:0:0:1::1
+
+      2001:db8:0000:0:1::1
+
+      2001:DB8:0:0:1::1
+
+   All the above point to the same IPv6 address.  This flexibility has
+   caused many problems for operators, systems engineers, and customers.
+   The problems will be noted in Section 3.  Also, a canonical
+   representation format to avoid problems will be introduced in
+   Section 4.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+2.  Text Representation Flexibility of RFC4291
+
+   Examples of flexibility in Section 2.2 of [RFC4291] are described
+   below.
+
+2.1.  Leading Zeros in a 16 Bit Field
+
+      'It is not necessary to write the leading zeros in an individual
+      field.'
+
+   In other words, it is also not necessary to omit leading zeros.  This
+   means that, it is possible to select from such as the following
+   example.  The final 16 bit field is different, but all these
+   addresses mean the same.
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                 [Page 4]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
+
+2.2.  Zero Compression
+
+      'A special syntax is available to compress the zeros.  The use of
+      "::" indicates one or more groups of 16 bits of zeros.'
+
+   It is possible to select whether or not to omit just one 16 bits of
+   zeros.
+
+      2001:db8:aaaa:bbbb:cccc:dddd::1
+
+      2001:db8:aaaa:bbbb:cccc:dddd:0:1
+
+   In case where there are more than one zero fields, there is a choice
+   of how many fields can be shortened.  Examples follow.
+
+      2001:db8:0:0:0::1
+
+      2001:db8:0:0::1
+
+      2001:db8:0::1
+
+      2001:db8::1
+
+   In addition, [RFC4291] in section 2.2 notes,
+
+      'The "::" can only appear once in an address.'
+
+   This gives a choice on where, in a single address to compress the
+   zero.  Examples are shown below.
+
+      2001:db8::aaaa:0:0:1
+
+      2001:db8:0:0:aaaa::1
+
+2.3.  Uppercase or Lowercase
+
+   [RFC4291] does not mention about preference of uppercase or
+   lowercase.  Various flavors are shown below.
+
+
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                 [Page 5]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
+
+
+3.  Problems Encountered with the Flexible Model
+
+3.1.  Searching
+
+3.1.1.  General Summary
+
+   A search of an IPv6 address if conducted through a UNIX system is
+   usually case sensitive and extended options to allow for regular
+   expression use will come in handy.  However, there are many
+   applications in the Internet today that do not provide this
+   capability.  When searching for an IPv6 address in such systems, the
+   system engineer will have to try each and every possibility to search
+   for an address.  This has critical impacts especially when trying to
+   deploy IPv6 over an enterprise network.
+
+3.1.2.  Searching Spreadsheets and Text Files
+
+   Spreadsheet applications and text editors on GUI systems, rarely have
+   the ability to search for a text using regular expression.  Moreover,
+   there are many non-engineers (who are not aware of case sensitivity
+   and regular expression use) that use these application to manage IP
+   addresses.  This has worked quite well with IPv4 since text
+   representation in IPv4 has very little flexibility.  There is no
+   incentive to encourage these non-engineers to change their tool or
+   learn regular expression when they decide to go dual-stack.  If the
+   entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
+   conducted as 2001:db8:0:0:1::1, this will show a result of no match.
+   One example where this will cause problem is, when the search is
+   being conducted to assign a new address from a pool, and a check was
+   being done to see if it was not in use.  This may cause problems to
+   the end-hosts or end-users.  This type of address management is very
+   often seen in enterprise networks and also in ISPs.
+
+3.1.3.  Searching with Whois
+
+   The "whois" utility is used by a wide range of people today.  When a
+   record is set to a database, one will likely check the output to see
+   if the entry is correct.  If an entity was recorded as 2001:db8::/48,
+   but the whois output showed 2001:0db8:0000::/48, most non-engineers
+   would think that their input was wrong, and will likely retry several
+   times or make a frustrated call to the database hostmaster.  If there
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                 [Page 6]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+   was a need to register the same address on different systems, and
+   each system showed a different text representation, this would
+   confuse people even more.  Although this document focuses on
+   addresses rather than prefixes, this is worth mentioning since
+   problems encountered are mostly equal.
+
+3.1.4.  Searching for an Address in a Network Diagram
+
+   Network diagrams and blue-prints contain IP addresses as allocated to
+   system devices.  In times of trouble shooting, there may be a need to
+   search through a diagram to find the point of failure (for example,
+   if a traceroute stopped at 2001:db8::1, one would search the diagram
+   for that address).  This is a technique quite often in use in
+   enterprise networks and managed services.  Again, the different
+   flavors of text representation will result in a time-consuming
+   search, leading to longer MTTR in times of trouble.
+
+3.2.  Parsing and Modifying
+
+3.2.1.  General Summary
+
+   With all the possible text representation ways, each application must
+   include a module, object, link, etc. to a function that will parse
+   IPv6 addresses in a manner that no matter how it is represented, they
+   will mean the same address.  This is not too much a problem if the
+   output is to be just 'read' or 'managed' by a network engineer.
+   However, many system engineers who integrate complex computer systems
+   to corporate customers will have difficulties finding that their
+   favorite tool will not have this function, or will encounter
+   difficulties such as having to rewrite their macro's or scripts for
+   their customers.  It must be noted that each additional line of a
+   program will result in increased development fees that will be
+   charged to the customers.
+
+3.2.2.  Logging
+
+   If an application were to output a log summary that represented the
+   address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
+   the output would be highly unreadable compared to the IPv4 output.
+   The address would have to be parsed and reformed to make it useful
+   for human reading.  This will result in additional code on the
+   applications which will result in extra fees charged to the
+   customers.  Sometimes, logging for critical systems is done by
+   mirroring the same traffic to two different systems.  Care must be
+   taken that no matter what the log output is, the logs should be
+   parsed so they will mean the same.
+
+
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                 [Page 7]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+3.2.3.  Auditing: Case 1
+
+   When a router or any other network appliance machine configuration is
+   audited, there are many methods to compare the configuration
+   information of a node.  Sometimes, auditing will be done by just
+   comparing the changes made each day.  In this case, if configuration
+   was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
+   0000:0000:0000:0001 just because the new engineer on the block felt
+   it was better, a simple diff will tell you that a different address
+   was configured.  If this was done on a wide scale network, people
+   will be focusing on 'why the extra zeros were put in' instead of
+   doing any real auditing.  Lots of tools are just plain 'diff's that
+   do not take into account address representation rules.
+
+3.2.4.  Auditing: Case 2
+
+   Node configurations will be matched against an information system
+   that manages IP addresses.  If output notation is different, there
+   will need to be a script that is implemented to cover for this.  An
+   SNMP GET of an interface address and text representation in a humanly
+   written text file is highly unlikely to match on first try.
+
+3.2.5.  Verification
+
+   Some protocols require certain data fields to be verified.  One
+   example of this is X.509 certificates.  If an IPv6 address was
+   embedded in one of the fields in a certificate, and the verification
+   was done by just a simple textual comparison, the certificate may be
+   maistakenly shown as being invalid due to a difference in text
+   representation methods.
+
+3.2.6.  Unexpected Modifying
+
+   Sometimes, a system will take an address and modify it as a
+   convenience.  For example, a system may take an input of
+   2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some
+   RIR databases).  If the zeros were input for a reason, the outcome
+   may be somewhat unexpected.
+
+3.3.  Operating
+
+3.3.1.  General Summary
+
+   When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
+   0:0:1, the system may take the address and show the configuration
+   result as 2001:DB8::1:0:0:1.  A distinguished engineer will know that
+   the right address is set, but an operator, or a customer that is
+   communicating with the operator to solve a problem, is usually not as
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                 [Page 8]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+   distinguished as we would like.  Again, the extra load in checking
+   that the IP address is the same as was intended, will result in fees
+   that will be charged to the customers.
+
+3.3.2.  Customer Calls
+
+   When a customer calls to inquire about a suspected outage, IPv6
+   address representation should be handled with care.  Not all
+   customers are engineers nor have the same skill in IPv6 technology.
+   The NOC will have to take extra steps to humanly parse the address to
+   avoid having to explain to the customers that 2001:db8:0:1::1 is the
+   same as 2001:db8::1:0:0:0:1.  This is one thing that will never
+   happen in IPv4 because IPv4 address cannot be abbreviated.
+
+3.3.3.  Abuse
+
+   Network abuse is reported along with the abusing IP address.  This
+   'reporting' could take any shape or form of the flexible model.  A
+   team that handles network abuse must be able to tell the difference
+   between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
+   placement of the "::" will result in a critical situation.  A system
+   that handles these incidents should be able to handle any type of
+   input and parse it in a correct manner.  Also, incidents are reported
+   over the phone.  It is unnecessary to report if the letter is an
+   uppercase or lowercase.  However, when a letter is spelled uppercase,
+   people tend to clarify that it is uppercase, which is unnecessary
+   information.
+
+3.4.  Other Minor Problems
+
+3.4.1.  Changing Platforms
+
+   When an engineer decides to change the platform of a running service,
+   the same code may not work as expected due to the difference in IPv6
+   address text representation.  Usually, a change in a platform (e.g.
+   Unix to Windows, Cisco to Juniper) will result in a major change of
+   code, but flexibility in address representation will increase the
+   work load which will again, result in fees that will be charged to
+   the customers, and also longer down time of systems.
+
+3.4.2.  Preference in Documentation
+
+   A document that is edited by more than one author, may become harder
+   to read.
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                 [Page 9]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+3.4.3.  Legibility
+
+   Capital case D and 0 can be quite often misread.  Capital B and 8 can
+   also be misread.
+
+
+4.  A Recommendation for IPv6 Text Representation
+
+   A recommendation for a canonical text representation format of IPv6
+   addresses is presented in this section.  The recommendation in this
+   document is one that, complies fully with [RFC4291], is implemented
+   by various operating systems, and is human friendly.  The
+   recommendation in this document SHOULD be followed by humans and
+   systems when generating an address to represent as text, but all
+   implementations MUST accept any legitimate [RFC4291] format.
+
+4.1.  Handling Leading Zeros in a 16 Bit Field
+
+   Leading zeros should be chopped for human legibility and easier
+   searching.  Also, a single 16 bit 0000 field should be represented as
+   just 0.  Place holder zeros are often cause of misreading.
+
+4.2.  "::" Usage
+
+4.2.1.  Shorten As Much As Possible
+
+   The use of "::" should be used to its maximum capability (i.e. 2001:
+   db8::0:1 is not considered as clean representation).
+
+4.2.2.  Handling One 16 Bit 0 Field
+
+   "::" should not be used to shorten just one 16 bit 0 field for it
+   would tend to mislead that there are more than one 16 bit field that
+   is shortened.
+
+4.2.3.  Choice in Placement of "::"
+
+   When there is an alternative choice in the placement of a "::", the
+   longest run of consecutive 16 bit 0 fields should be shortened (i.e.
+   latter is shortened in 2001:0:0:1:0:0:0:1).  When the length of the
+   consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1),
+   the former is shortened.  This is consistent with many current
+   implementations.  One idea to avoid any confusion, is for the
+   operator to not use 16 bit field 0 in the first 64 bits.  By nature
+   IPv6 addresses are usually assigned or allocated to end-users as
+   longer than 32 bits (typically 48 bits or longer).
+
+
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                [Page 10]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+4.3.  Lower Case
+
+   Recent implementations tend to represent IPv6 address as lower case.
+   It is better to use lower case to avoid problems such as described in
+   section 3.3.3 and 3.4.3.
+
+
+5.  Text Representation of Special Addresses
+
+   Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
+   IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in
+   the low-order 32 bits of the address.  These addresses have special
+   representation that may mix hexadecimal and decimal notations.  In
+   cases where there is a choice of whether to express the address as
+   fully hexadecimal or hexadecimal and decimal mixed, and if the
+   address type can be distinguished as having IPv4 addresses embedded
+   in the lower 32 bits solely from the 128bits of the address field
+   itself, mixed notation is the better choice.  However, there may be
+   situations where hexadecimal representation is chosen to meet certain
+   needs.  Addressing those needs is out of the scope of this document.
+   The text representation method noted in Section 4 should be applied
+   for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of
+   0:0:0:0:0:ffff:192.0.2.1).
+
+
+6.  Notes on Combining IPv6 Addresses with Port Numbers
+
+   When IPv6 addresses and port numbers are represented in text combined
+   together, there seems to be many different ways to do so.  Examples
+   are shown below.
+
+   o  [2001:db8::1]:80
+
+   o  2001:db8::1:80
+
+   o  2001:db8::1.80
+
+   o  2001:db8::1 port 80
+
+   o  2001:db8::1p80
+
+   o  2001:db8::1#80
+
+   The situation is not much different in IPv4, but the most ambiguous
+   case with IPv6 is the second bullet.  This is due to the "::"usage in
+   IPv6 addresses.  This style is not recommended for its ambiguity.
+   The [] style as expressed in [RFC3986] is recommended.  Other styles
+   are acceptable when cross-platform portability does not become an
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                [Page 11]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+   issue.
+
+
+7.  Conclusion
+
+   The recommended format of text representing an IPv6 address is
+   summarized as follows.
+
+      (1) omit leading zeros in a 16 bit field
+
+      (2) when using "::", shorten consecutive zero fields to their
+      maximum extent (leave no zero fields behind).
+
+      (3) "::" used where shortens address the most
+
+      (4) "::" used in the former part in case of a tie breaker
+
+      (5) do not shorten one 16 bit 0 field, but always shorten when
+      there are two or more consecutive 16 bit 0 fields
+
+      (6) use lower case
+
+   Hints for developers are written in the Appendix section.
+
+
+8.  Security Considerations
+
+   None.
+
+
+9.  IANA Considerations
+
+   None.
+
+
+10.  Acknowledgements
+
+   The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
+   Toshimitsu Matsuura for their generous and helpful comments in kick
+   starting this document.  We also would like to thank Brian Carpenter,
+   Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
+   Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
+   Vatiainen for their input.  Also a very special thanks to Ron Bonica,
+   Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt
+   Lindqvist for their support in bringing this document to the light of
+   IETF working groups.
+
+
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                [Page 12]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+11.2.  Informative References
+
+   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+              (SIIT)", RFC 2765, February 2000.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
+   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+              Castro, "Application Aspects of IPv6 Transition",
+              RFC 4038, March 2005.
+
+   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
+              March 2008.
+
+
+Appendix A.  For Developers
+
+   We recommend that developers use display routines that conform to
+   these rules.  For example, the usage of getnameinfo() with flags
+   argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
+   except for the special addresses notes in Section 5.  The function
+   inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
+   be called directly.  See [RFC4038] for details.
+
+
+Appendix B.  Prefix Issues
+
+   Problems with prefixes are just the same as problems encountered with
+   addresses.  Text representation method of IPv6 prefixes should be no
+   different from that of IPv6 addresses.
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                [Page 13]
+
+Internet-Draft          IPv6 Text Representation            October 2009
+
+
+Authors' Addresses
+
+   Seiichi Kawamura
+   NEC BIGLOBE, Ltd.
+   14-22, Shibaura 4-chome
+   Minatoku, Tokyo  108-8558
+   JAPAN
+
+   Phone: +81 3 3798 6085
+   Email: kawamucho@mesh.ad.jp
+
+
+   Masanobu Kawashima
+   NEC AccessTechnica, Ltd.
+   800, Shimomata
+   Kakegawa-shi, Shizuoka  436-8501
+   JAPAN
+
+   Phone: +81 537 23 9655
+   Email: kawashimam@necat.nec.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires April 21, 2010                [Page 14]
+
+
diff --git a/doc/draft/draft-ietf-behave-dns64-01.txt b/doc/draft/draft-ietf-behave-dns64-01.txt
new file mode 100644
index 000000000000..25a6dd4d0726
--- /dev/null
+++ b/doc/draft/draft-ietf-behave-dns64-01.txt
@@ -0,0 +1,1624 @@
+
+
+
+BEHAVE WG                                                     M. Bagnulo
+Internet-Draft                                                      UC3M
+Intended status: Standards Track                             A. Sullivan
+Expires: April 22, 2010                                         Shinkuro
+                                                             P. Matthews
+                                                          Alcatel-Lucent
+                                                          I. van Beijnum
+                                                          IMDEA Networks
+                                                        October 19, 2009
+
+
+DNS64: DNS extensions for Network Address Translation from IPv6 Clients
+                            to IPv4 Servers
+                       draft-ietf-behave-dns64-01
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 April 22, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                 [Page 1]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+Abstract
+
+   DNS64 is a mechanism for synthesizing AAAA records from A records.
+   DNS64 is used with an IPv6/IPv4 translator to enable client-server
+   communication between an IPv6-only client and an IPv4-only server,
+   without requiring any changes to either the IPv6 or the IPv4 node,
+   for the class of applications that work through NATs.  This document
+   specifies DNS64, and provides suggestions on how it should be
+   deployed in conjunction with IPv6/IPv4 translators.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Background to DNS64 - DNSSEC interaction . . . . . . . . . . .  6
+   4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   5.  DNS64 Normative Specification  . . . . . . . . . . . . . . . .  9
+     5.1.  Resolving AAAA queries and the answer section  . . . . . .  9
+       5.1.1.  The answer when there is AAAA data available . . . . .  9
+       5.1.2.  The answer when there is an error  . . . . . . . . . .  9
+       5.1.3.  Data for the answer when performing synthesis  . . . .  9
+       5.1.4.  Performing the synthesis . . . . . . . . . . . . . . . 10
+       5.1.5.  Querying in parallel . . . . . . . . . . . . . . . . . 11
+     5.2.  Generation of the IPv6 representations of IPv4
+           addresses  . . . . . . . . . . . . . . . . . . . . . . . . 11
+     5.3.  Handling other RRs . . . . . . . . . . . . . . . . . . . . 12
+       5.3.1.  PTR queries  . . . . . . . . . . . . . . . . . . . . . 12
+       5.3.2.  Handling the additional section  . . . . . . . . . . . 13
+       5.3.3.  Other records  . . . . . . . . . . . . . . . . . . . . 13
+     5.4.  Assembling a synthesized response to a AAAA query  . . . . 14
+     5.5.  DNSSEC processing: DNS64 in recursive server mode  . . . . 14
+     5.6.  DNS64 and multihoming  . . . . . . . . . . . . . . . . . . 15
+   6.  Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16
+     6.1.  DNS resolvers and DNS64  . . . . . . . . . . . . . . . . . 16
+     6.2.  DNSSEC validators and DNS64  . . . . . . . . . . . . . . . 16
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
+   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
+   Appendix A.  Deployment scenarios and examples . . . . . . . . . . 20
+     A.1.  Embed and Zero-Pad algorithm description . . . . . . . . . 21
+     A.2.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in
+           DNS server mode  . . . . . . . . . . . . . . . . . . . . . 22
+     A.3.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in
+           stub-resolver mode . . . . . . . . . . . . . . . . . . . . 23
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                 [Page 2]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+     A.4.  IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
+           server mode  . . . . . . . . . . . . . . . . . . . . . . . 25
+   Appendix B.  Motivations and Implications of synthesizing AAAA
+                RR when real AAAA RR exists . . . . . . . . . . . . . 27
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                 [Page 3]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+1.  Introduction
+
+   This document specifies DNS64, a mechanism that is part of the
+   toolbox for IPv6-IPv4 transition and co-existence.  DNS64, used
+   together with an IPv6/IPv4 translator such as NAT64
+   [I-D.bagnulo-behave-nat64], allows an IPv6-only client to initiate
+   communications by name to an IPv4-only server.
+
+   DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
+   from A RRs.  A synthetic AAAA RR created by the DNS64 from an
+   original A RR contains the same FQDN of the original A RR but it
+   contains an IPv6 address instead of an IPv4 address.  The IPv6
+   address is an IPv6 representation of the IPv4 address contained in
+   the original A RR.  The IPv6 representation of the IPv4 address is
+   algorithmically generated from the IPv4 address returned in the A RR
+   and a set of parameters configured in the DNS64 (typically, an IPv6
+   prefix used by IPv6 representations of IPv4 addresses and optionally
+   other parameters).
+
+   Together with a IPv6/IPv4 translator, these two mechanisms allow an
+   IPv6-only client to initiate communications to an IPv4-only server
+   using the FQDN of the server.
+
+   These mechanisms are expected to play a critical role in the IPv4-
+   IPv6 transition and co-existence.  Due to IPv4 address depletion, it
+   is likely that in the future, many IPv6-only clients will want to
+   connect to IPv4-only servers.  In the typical case, the approach only
+   requires the deployment of IPv6/IPv4 translators that connect an
+   IPv6-only network to an IPv4-only network, along with the deployment
+   of one or more DNS64-enabled name servers.  However, some advanced
+   features require performing the DNS64 function directly by the end-
+   hosts themselves.
+
+
+2.  Overview
+
+   This section provides a non-normative introduction to the DNS64
+   mechanism.
+
+   We assume that we have an IPv6/IPv4 translator box connecting an IPv4
+   network and an IPv6 network.  The IPv6/IPv4 translator device
+   provides translation services between the two networks enabling
+   communication between IPv4-only hosts and IPv6-only hosts.  (NOTE: By
+   IPv6-only hosts we mean hosts running IPv6-only applications, hosts
+   that can only use IPv6, as well as the cases where only IPv6
+   connectivity is available to the client.  By IPv4-only servers we
+   mean servers running IPv4-only applications, servers that can only
+   use IPv4, as well as the cases where only IPv4 connectivity is
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                 [Page 4]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   available to the server).  The IPv6/IPv4 translator used in
+   conjunction with DNS64 must allow communications initiated from the
+   IPv6-only host to the IPv4-only host.
+
+   To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
+   learn the address of the responder, DNS64 is used to synthesize a
+   AAAA record from an A record containing a real IPv4 address of the
+   responder, whenever the DNS64 service cannot retrieve a AAAA record
+   for the requested host name.  The DNS64 device appears as a regular
+   recursive resolver for the IPv6 initiator.  The DNS64 box receives an
+   AAAA DNS query generated by the IPv6 initiator.  It first attempts a
+   recursive resolution for the requested AAAA records.  If there is no
+   AAAA record available for the target node (which is the normal case
+   when the target node is an IPv4-only node), DNS64 performs a query
+   for A records.  If any A records are discovered, DNS64 creates a
+   synthetic AAAA RR from the information retrieved in each A RR.
+
+   The FQDN of a synthetic AAAA RR is the same as that of the original A
+   RR, but an IPv6 representation of the IPv4 address contained in the
+   original A RR is included in the AAAA RR.  The IPv6 representation of
+   the IPv4 address is algorithmically generated from the IPv4 address
+   and additional parameters configured in the DNS64.  Among those
+   parameters configured in the DNS64, there is at least one IPv6
+   prefix, called Pref64::/n.  The IPv6 address representing IPv4
+   addresses included in the AAAA RR synthesized by the DNS64 function
+   contain Pref64::/n and they also embed the original IPv4 address.
+
+   The same algorithm and the same Pref64::/n prefix or prefixes must be
+   configured both in the DNS64 device and the IPv6/IPv4 translator, so
+   that both can algorithmically generate the same IPv6 representation
+   for a given IPv4 address.  In addition, it is required that IPv6
+   packets addressed to an IPv6 destination that contains the Pref64::/n
+   be delivered to the IPv6/IPv4 translator, so they can be translated
+   into IPv4 packets.
+
+   Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is
+   passed back to the IPv6 initiator, which will initiate an IPv6
+   communication with the IPv6 address associated with the IPv4
+   receiver.  The packet will be routed to the IPv6/IPv4 translator
+   which will forward it to the IPv4 network .
+
+   In general, the only shared state between the DNS64 and the IPv6/IPv4
+   translator is the Pref64::/n and an optional set of static
+   parameters.  The Pref64::/n and the set of static parameters must be
+   configured to be the same on both; there is no communication between
+   the DNS64 device and IPv6/IPv4 translator functions.  The mechanism
+   to be used for configuring the parameters of the DNS64 is beyond the
+   scope of this memo.
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                 [Page 5]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   The DNS64 function can be performed in two places.
+
+      One option is to locate the DNS64 function in recursive name
+      servers serving end hosts.  In this case, when an IPv6-only host
+      queries the name server for AAAA RRs for an IPv4-only host, the
+      name server can perform the synthesis of AAAA RRs and pass them
+      back to the IPv6 only initiator.  The main advantage of this mode
+      is that current IPv6 nodes can use this mechanism without
+      requiring any modification.  This mode is called "DNS64 in DNS
+      server mode".
+
+      The other option is to place the DNS64 function in the end hosts
+      themselves, coupled to the local stub resolver.  In this case, the
+      stub resolver will try to obtain (real) AAAA RRs and in case they
+      are not available, the DNS64 function will synthesize AAAA RRs for
+      internal usage.  This mode is compatible with some advanced
+      functions like DNSSEC validation in the end host.  The main
+      drawback of this mode is its deployability, since it requires
+      changes in the end hosts.  This mode is called "DNS64 in stub-
+      resolver mode"".
+
+
+3.  Background to DNS64 - DNSSEC interaction
+
+   DNSSEC presents a special challenge for DNS64, because DNSSEC is
+   designed to detect changes to DNS answers, and DNS64 may alter
+   answers coming from an authoritative server.
+
+   A recursive resolver can be security-aware or security-oblivious.
+   Moreover, a security-aware recursive name server can be validating or
+   non-validating, according to operator policy.  In the cases below,
+   the recursive server is also performing DNS64, and has a local policy
+   to validate.  We call this general case vDNS64, but in all the cases
+   below the DNS64 functionality should be assumed needed.
+
+   DNSSEC includes some signaling bits that offer some indicators of
+   what the query originator understands.
+
+   If a query arrives at a vDNS64 device with the DO bit set, the query
+   originator is signaling that it understands DNSSEC.  The DO bit does
+   not indicate that the query originator will validate the response.
+   It only means that the query originator can understand responses
+   containing DNSSEC data.  Conversely, if the DO bit is clear, that is
+   evidence that the querying agent is not aware of DNSSEC.
+
+   If a query arrives at a vDNS64 device with the CD bit set, it is an
+   indication that the querying agent wants all the validation data so
+   it can do checking itself.  By local policy, vDNS64 could still
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                 [Page 6]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   validate, but it must return all data to the querying agent anyway.
+
+   Here are the possible cases:
+
+   1.  A security-oblivious DNS64 node receives a query with the DO bit
+       clear.  In this case, DNSSEC is not a concern, because the
+       querying agent does not understand DNSSEC responses.
+
+   2.  A security-oblivious DNS64 node receives a query with the DO bit
+       set, and the CD bit clear.  This is just like the case of a non-
+       DNS64 case: the server doesn't support it, so the querying agent
+       is out of luck.
+
+   3.  A security-aware and non-validating DNS64 node receives a query
+       with the DO bit set and the CD bit clear.  Such a resolver is not
+       validating responses, likely due to local policy (see [RFC4035],
+       section 4.2).  For that reason, this case amounts to the same as
+       the previous case, and no validation happens.
+
+   4.  A security-aware and non-validating DNS64 node receives a query
+       with the DO bit set and the CD bit set.  In this case, the
+       resolver is supposed to pass on all the data it gets to the query
+       initiator (see section 3.2.2 of [RFC4035]).  This case will be
+       problematic with DNS64.  If the DNS64 server modifies the record,
+       the client will get the data back and try to validate it, and the
+       data will be invalid as far as the client is concerned.
+
+   5.  A security-aware and validating DNS64 node receives a query with
+       the DO bit clear and CD clear.  In this case, the resolver
+       validates the data.  If it fails, it returns RCODE 2 (SERVFAIL);
+       otherwise, it returns the answer.  This is the ideal case for
+       vDNS64.  The resolver validates the data, and then synthesizes
+       the new record and passes that to the client.  The client, which
+       is presumably not validating (else it would have set DO and CD),
+       cannot tell that DNS64 is involved.
+
+   6.  A security-aware and validating DNS64 node receives a query with
+       the DO bit set and CD clear.  In principle, this ought to work
+       like the previous case, except that the resolver should also set
+       the AD bit on the response.
+
+   7.  A security-aware and validating DNS64 node receives a query with
+       the DO bit set and CD set.  This is effectively the same as the
+       case where a security-aware and non-validating recursive resolver
+       receives a similar query, and the same thing will happen: the
+       downstream validator will mark the data as invalid if DNS64 has
+       performed synthesis.
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                 [Page 7]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+4.  Terminology
+
+   This section provides definitions for the special terms used in the
+   document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   Authoritative server:  A DNS server that can answer authoritatively a
+      given DNS question.
+
+   DNS64:  A logical function that synthesizes DNS resource records (e.g
+      AAAA records containing IPv6 addresses) from DNS resource records
+      actually contained in the global DNS (e.g.  A records containing
+      IPv4 addresses).
+
+   DNS64 recursor:  A recursive resolver that provides the DNS64
+      functionality as part of its operation.
+
+   Recursive resolver:  A DNS server that accepts requests from one
+      resolver, and asks another resolver for the answer on behalf of
+      the first resolver.  In the context of this document, "the
+      recursive resolver" means a recursive resolver immediately next in
+      the DNS resolution chain from an end point.  The end point usually
+      has only a stub resolver available.[[anchor5: I can't actually
+      remember why we needed the sentences following "In the context of
+      this document. . ."  Unless someone has a reason, I'll take it
+      out. --ajs@shinkuro.com]]
+
+   Synthetic RR:  A DNS resource record (RR) that is not contained in
+      any zone data file, but has been synthesized from other RRs.  An
+      example is a synthetic AAAA record created from an A record.
+
+   Stub resolver:  A resolver with minimum functionality, typically for
+      use in end points that depend on a recursive resolver.  Most end
+      points on the Internet as of this writing use stub
+      resolvers.[[anchor6: Do we need this in the document?  I don't
+      think so. 1034 defines this term. --ajs@shinkuro.com]]
+
+   IPv6/IPv4 translator:  A device that translates IPv6 packets to IPv4
+      packets and vice-versa.  It is only required that the
+      communication initiated from the IPv6 side be supported.
+
+   For a detailed understanding of this document, the reader should also
+   be familiar with DNS terminology from [RFC1034],[RFC1035] and current
+   NAT terminology from [RFC4787].  Some parts of this document assume
+   familiarity with the terminology of the DNS security extensions
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                 [Page 8]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   outlined in [RFC4035].
+
+
+5.  DNS64 Normative Specification
+
+   A DNS64 is a logical function that synthesizes AAAA records from A
+   records.  The DNS64 function may be implemented in a stub resolver,
+   in a recursive resolver, or in an authoritative name server.
+
+   The implementation SHOULD support mapping of IPv4 address ranges to
+   separate IPv6 prefixes for AAAA record synthesis.  This allows
+   handling of special use IPv4 addresses [I-D.iana-rfc3330bis].
+   Multicast address handling is further specified in
+   [I-D.venaas-behave-mcast46].
+
+5.1.  Resolving AAAA queries and the answer section
+
+   When the DNS64 receives a query for RRs of type AAAA and class IN, it
+   first attempts to retrieve non-synthetic RRs of this type and class,
+   either by performing a query or, in the case of an authoritative
+   server, by examining its own results.
+
+5.1.1.  The answer when there is AAAA data available
+
+   If the query results in one or more AAAA records in the answer
+   section, the result is returned to the requesting client as per
+   normal DNS semantics (except in the case where the AAAA falls in the
+   ::ffff/96 network; see below for treatment of that network).  In this
+   case, DNS64 SHOULD NOT include synthetic AAAA RRs in the response
+   (see Appendix B for an analysis of the motivations for and the
+   implications of not complying with this recommendation).  By default
+   DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
+   exist.
+
+5.1.2.  The answer when there is an error
+
+   If the query results in a response with an error code other than 0,
+   the result is handled according to normal DNS operation -- that is,
+   either the resolver tries again using a different server from the
+   authoritative NS RRSet, or it returns the error to the client.  This
+   stage is still prior to any synthesis having happened, so a response
+   to be returned to the client does not need any special assembly than
+   would usually happen in DNS operation.
+
+5.1.3.  Data for the answer when performing synthesis
+
+   If the query results in no error but an empty answer section in the
+   response, the DNS64 resolver attempts to retrieve A records for the
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                 [Page 9]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   name in question.  If this new A RR query results in an empty answer
+   or in an error, then the empty result or error is used as the basis
+   for the answer returned to the querying client.  (Transient errors
+   may result in retrying the query, depening on the operation of the
+   resolver; this is just as in Section 5.1.2.)  If instead the query
+   results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on
+   the A RRs according to the procedure outlined in Section 5.1.4.  The
+   DNS64 resolver then returns the synthesized AAAA records in the
+   answer section to the client, removing the A records that form the
+   basis of the synthesis.
+
+   As an exception to the general rule about always returning the AAAA
+   records if they are returned in the answer, AAAA records with
+   addresses in the ::ffff/96 network are treated just like the case
+   where there is neither an error nor an empty answer section.  This is
+   because a real IPv6-only node will not be any more able to reach the
+   addresses in ::ffff/96 than it is able to reach an IPv4 address
+   without assistance.  An implementation MAY use the address in
+   ::ffff/96 as the basis of synthesis without querying for an A record,
+   by using the last 32 bits of the address provided in the AAAA record.
+   [[anchor10: I changed this to say "neither. . .nor" because the
+   previous version suggested that it would return the error-or-empty-
+   answer to the querying client, and that can't be right.  Correct?
+   --ajs@shinkuro.com]]
+
+5.1.4.  Performing the synthesis
+
+   A synthetic AAAA record is created from an A record as follows:
+
+   o  The NAME field is set to the NAME field from the A record
+
+   o  The TYPE field is set to 28 (AAAA)
+
+   o  The CLASS field is set to 1 (IN)
+
+   o  The TTL field is set to the minimum of the TTL of the original A
+      RR and the SOA RR for the queried domain.  (Note that in order to
+      obtain the TTL of the SOA RR the DNS64 does not need to perform a
+      new query, but it can remember the TTL from the SOA RR in the
+      negative response to the AAAA query).
+
+   o  The RDLENGTH field is set to 16
+
+   o  The RDATA field is set to the IPv6 representation of the IPv4
+      address from the RDATA field of the A record.  The DNS64 SHOULD
+      check each A RR against IPv4 address ranges and select the
+      corresponding IPv6 prefix to use in synthesizing the AAAA RR.  See
+      Section 5.2 for discussion of the algorithms to be used in
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 10]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+      effecting the transformation.
+
+5.1.5.  Querying in parallel
+
+   DNS64 MAY perform the query for the AAAA RR and for the A RR in
+   parallel, in order to minimize the delay.  However, this would result
+   in performing unnecessary A RR queries in the case no AAAA RR
+   synthesis is required.  A possible trade-off would be to perform them
+   sequentially but with a very short interval between them, so if we
+   obtain a fast reply, we avoid doing the additional query.  (Note that
+   this discussion is relevant only if the DNS64 function needs to
+   perform external queries to fetch the RR.  If the needed RR
+   information is available locally, as in the case of an authoritative
+   server, the issue is no longer relevant.)
+
+5.2.  Generation of the IPv6 representations of IPv4 addresses
+
+   DNS64 supports multiple algorithms for the generation of the IPv6
+   representation of an IPv4 address.  The constraints imposed on the
+   generation algorithms are the following:
+
+      The same algorithm to create an IPv6 address from an IPv4 address
+      MUST be used by both the DNS64 to create the IPv6 address to be
+      returned in the synthetic AAAA RR from the IPv4 address contained
+      in original A RR, and by the IPv6/IPv4 translator to create the
+      IPv6 address to be included in the destination address field of
+      the outgoing IPv6 packets from the IPv4 address included in the
+      destination address field of the incoming IPv4 packet.
+
+      The algorithm MUST be reversible, i.e. it MUST be possible to
+      extract the original IPv4 address from the IPv6 representation.
+
+      The input for the algorithm MUST be limited to the IPv4 address,
+      the IPv6 prefix (denoted Pref64::/n) used in the IPv6
+      representations and optionally a set of stable parameters that are
+      configured in the DNS64 (such as fixed string to be used as a
+      suffix).
+
+         If we note n the length of the prefix Pref64::/n, then n MUST
+         the less or equal than 96.  If a Pref64::/n is configured
+         through any means in the DNS64 (such as manually configured, or
+         other automatic mean not specified in this document), the
+         default algorithm MUST use this prefix.  If no prefix is
+         available, the algorithm MUST use the Well-Known prefix TBD1
+         defined in [I-D.thaler-behave-translator-addressing]
+
+      [[anchor12: Note in document: TBD1 in the passage above is to be
+      substituted by whatever prefix is assigned by IANA to be the well-
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 11]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+      known prefix.]]
+
+   DNS64 MUST support the following algorithms for generating IPv6
+   representations of IPv4 addresses defined in
+   [I-D.thaler-behave-translator-addressing]:
+
+      Zero-Pad And Embed, defined in section 3.2.3 of
+      [I-D.thaler-behave-translator-addressing]
+
+      Compensation-Pad And Embed, defined in section of 3.2.4 of
+      [I-D.thaler-behave-translator-addressing]
+
+      Embed And Zero-Pad, defined in section of 3.2.5 of
+      [I-D.thaler-behave-translator-addressing]
+
+      Preconfigured Mapping Table, defined in section of 3.2.6 of
+      [I-D.thaler-behave-translator-addressing]
+
+   The default algorithm used by DNS64 must be Embed and Zero-Pad.
+   While the normative description of the algorithms is provided in
+   [I-D.thaler-behave-translator-addressing], an sample description of
+   the algorithm and its application to different scenarios is provided
+   in Appendix A for illustration purposes.
+
+5.3.  Handling other RRs
+
+5.3.1.  PTR queries
+
+   If a DNS64 nameserver receives a PTR query for a record in the
+   IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME,
+   reverse the address portion of the QNAME according to the encoding
+   scheme outlined in section 2.5 of [RFC3596] , and examine the
+   resulting address to see whether its prefix matches the locally-
+   configured Pref64::/n.  There are two alternatives for a DNS64
+   nameserver to respond to such PTR queries.  A DNS64 node MUST provide
+   one of these, and SHOULD NOT provide both at the same time unless
+   different IP6.ARPA zones require answers of different sorts.
+
+   The first option is for the DNS64 nameserver to respond
+   authoritatively for its prefixes.  If the address prefix matches any
+   Pref64::/n used in the site, either a LIR prefix or a well-known
+   prefix used for NAT64 as defined in
+   [I-D.thaler-behave-translator-addressing], then the DNS64 server MAY
+   answer the query using locally-appropriate RDATA.  The DNS64 server
+   MAY use the same RDATA for all answers.  Note that the requirement is
+   to match any Pref64::/n used at the site, and not merely the locally-
+   configured Pref64::/n.  This is because end clients could ask for a
+   PTR record matching an address received through a different (site-
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 12]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   provided) DNS64, and if this strategy is in effect, those queries
+   should never be sent to the global DNS.  The advantage of this
+   strategy is that it makes plain to the querying client that the
+   prefix is one operated by the DNS64 site, and that the answers the
+   client is getting are generated by the DNS64.  The disadvantage is
+   that any useful reverse-tree information that might be in the global
+   DNS is unavailable to the clients querying the DNS64.
+
+   The second option is for the DNS64 nameserver to synthesize a CNAME
+   mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA
+   name.  The rest of the response would be the normal DNS processing.
+   The CNAME can be signed on the fly if need be.  The advantage of this
+   approach is that any useful information in the reverse tree is
+   available to the querying client.  The disadvantage is that it adds
+   additional load to the DNS64 (because CNAMEs have to be synthesized
+   for each PTR query that matches the Pref64::/n), and that it may
+   require signing on the fly. [[anchor15: what are we supposed to do
+   here when the in-addr.arpa zone is unmaintained, as it may be.  If
+   there is no data at the target name, then we'll get a CNAME with a
+   map to an empty namespace, I think?  Isn't that bad?
+   --ajs@shinkuro.com]]
+
+   If the address prefix does not match any of the Pref64::/n, then the
+   DNS64 server MUST process the query as though it were any other query
+   -- i.e. a recursive nameserver MUST attempt to resolve the query as
+   though it were any other (non-A/AAAA) query, and an authoritative
+   server MUST respond authoritatively or with a referral, as
+   appropriate.
+
+5.3.2.  Handling the additional section
+
+   DNS64 synthesis MUST NOT be performed on any records in the
+   additional section of synthesized answers.  The DNS64 MUST pass the
+   additional section unchanged.
+
+   [[anchor16: We had some discussion, as an alternative to the above,
+   of allowing the DNS64 to truncate the additional section completely,
+   on the grounds that the additional section could break mixed-mode
+   iterative/forwarding resolvers that happen to end up behind DNS64.
+   Nobody else seemed to like that plan, so I haven't included it.
+   --ajs@shinkuro.com]]
+
+5.3.3.  Other records
+
+   If the DNS64 is in recursive resolver mode, then it SHOULD also serve
+   the zones specified in [I-D.ietf-dnsop-default-local-zones], rather
+   than forwarding those queries elsewhere to be handled.
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 13]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   All other RRs MUST be returned unchanged.
+
+5.4.  Assembling a synthesized response to a AAAA query
+
+   The DNS64 uses different pieces of data to build the response
+   returned to the querying client.
+
+   The query that is used as the basis for synthesis results either in
+   an error, an answer that can be used as a basis for synthesis, or an
+   empty (authoritative) answer.  If there is an empty answer, then the
+   DNS64 responds to the original querying client with the answer the
+   DNS64 received to the original AAAA query.  Otherwise, the response
+   is assembled as follows.
+
+   The header fields are set according to the usual rules for recursive
+   or authoritative servers, depending on the role that the DNS64 is
+   serving.  The question section is copied from the original AAAA
+   query.  The answer section is populated according to the rules in
+   Section 5.1.4.  The authority section is copied from the response to
+   the A query that the DNS64 performed.  The additional section is
+   populated according to the rules in Section 5.3.2.
+
+   [[anchor18: The cross-reference to how to do the additional section
+   can be removed, and replaced by "copied from the response to the A
+   query that the DNS64 performed" if we don't want to allow the DNS64
+   to truncate the additional section.  See the note above.  If I hear
+   no more feedback on this topic, then I'll make this change in the
+   next version. --ajs@shinkuro.com]]
+
+5.5.  DNSSEC processing: DNS64 in recursive server mode
+
+   We consider the case where the recursive server that is performing
+   DNS64 also has a local policy to validate the answers according to
+   the procedures outlined in [RFC4035] Section 5.  We call this general
+   case vDNS64.
+
+   The vDNS64 uses the presence of the DO and CD bits to make some
+   decisions about what the query originator needs, and can react
+   accordingly:
+
+   1.  If CD is not set and DO is not set, vDNS64 SHOULD perform
+       validation and do synthesis as needed.
+
+   2.  If CD is not set and DO is set, then vDNS64 SHOULD perform
+       validation.  Whenever vDNS64 performs validation, it MUST
+       validate the negative answer for AAAA queries before proceeding
+       to query for A records for the same name, in order to be sure
+       that there is not a legitimate AAAA record on the Internet.
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 14]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+       Failing to observe this step would allow an attacker to use DNS64
+       as a mechanism to circumvent DNSSEC.  If the negative response
+       validates, and the response to the A query validates, then the
+       vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
+       answer to the client.  This is acceptable, because [RFC4035],
+       section 3.2.3 says that the AD bit is set by the name server side
+       of a security-aware recursive name server if and only if it
+       considers all the RRSets in the Answer and Authority sections to
+       be authentic.  In this case, the name server has reason to
+       believe the RRSets are all authentic, so it SHOULD set the AD
+       bit.  If the data does not validate, the vDNS64 MUST respond with
+       RCODE=2 (server failure).
+       A security-aware end point might take the presence of the AD bit
+       as an indication that the data is valid, and may pass the DNS
+       (and DNSSEC) data to an application.  If the application attempts
+       to validate the synthesized data, of course, the validation will
+       fail.  One could argue therefore that this approach is not
+       desirable.  But security aware stub resolvers MUST NOT place any
+       reliance on data received from resolvers and validated on their
+       behalf without certain criteria established by [RFC4035], section
+       4.9.3.  An application that wants to perform validation on its
+       own should use the CD bit.
+
+   3.  If the CD bit is set and DO is set, then vDNS64 MAY perform
+       validation, but MUST NOT perform synthesis.  It MUST hand the
+       data back to the query initiator, just like a regular recursive
+       resolver, and depend on the client to do the validation and the
+       synthesis itself.
+       The disadvantage to this approach is that an end point that is
+       translation-oblivious but security-aware and validating will not
+       be able to use the DNS64 functionality.  In this case, the end
+       point will not have the desired benefit of NAT64.  In effect,
+       this strategy means that any end point that wishes to do
+       validation in a NAT64 context must be upgraded to be translation-
+       aware as well.
+
+5.6.  DNS64 and multihoming
+
+   Synthetic AAAA records may be constructed on the basis of the network
+   context in which they were constructed.  Therefore, a synthetic AAAA
+   received from one interface MUST NOT be used to resolve hosts via
+   another network interface. [[anchor21: This seems to be the result of
+   the discussion on-list starting with message id 18034D4D7FE9AE48BF19A
+   B1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com, but it's pretty
+   strange when stated baldly.  In particular, how is the multi-homed
+   host supposed to know that a given AAAA is synthetic?
+   --ajs@shinkuro.com]]
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 15]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+6.  Deployment notes
+
+   While DNS64 is intended to be part of a strategy for aiding IPv6
+   deployment in an internetworking environment with some IPv4-only and
+   IPv6-only networks, it is important to realise that it is
+   incompatible with some things that may be deployed in an IPv4-only or
+   dual-stack context.
+
+6.1.  DNS resolvers and DNS64
+
+   Full-service resolvers that are unaware of the DNS64 function can be
+   (mis)configured to act as mixed-mode iterative and forwarding
+   resolvers.  In a native-IPv4 context, this sort of configuration may
+   appear to work.  It is impossible to make it work properly without it
+   being aware of the DNS64 function, because it will likely at some
+   point obtain IPv4-only glue records and attempt to use them for
+   resolution.  The result that is returned will contain only A records,
+   and without the ability to perform the DNS64 function the resolver
+   will simply be unable to answer the necessary AAAA queries.
+
+6.2.  DNSSEC validators and DNS64
+
+   Existing DNSSEC validators (i.e. that are unaware of DNS64) will
+   reject all the data that comes from the DNS64 as having been tampered
+   with.  If it is necessary to have validation behind the DNS64, then
+   the validator must know how to perform the DNS64 function itself.
+   Alternatively, the validating host may establish a trusted connection
+   with the DNS64, and allow the DNS64 to do all validation on its
+   behalf.
+
+
+7.  Security Considerations
+
+   See the discussion on the usage of DNSSEC and DNS64 described in the
+   document.
+
+
+8.  Contributors
+
+      Dave Thaler
+
+      Microsoft
+
+      dthaler@windows.microsoft.com
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 16]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+9.  Acknowledgements
+
+   This draft contains the result of discussions involving many people,
+   including the participants of the IETF BEHAVE Working Group.  The
+   following IETF participants made specific contributions to parts of
+   the text, and their help is gratefully acknowledged: Mark Andrews,
+   Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet,
+   Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed
+   Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs
+   Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki
+   Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund,
+   Florian Weimer, Dan Wing, Xu Xiaohu.
+
+   Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
+   Trilogy, a research project supported by the European Commission
+   under its Seventh Framework Program.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
+              RFC 2672, August 1999.
+
+   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+              (SIIT)", RFC 2765, February 2000.
+
+   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
+              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+              RFC 4787, January 2007.
+
+   [I-D.ietf-behave-tcp]
+              Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
+              Srisuresh, "NAT Behavioral Requirements for TCP",
+              draft-ietf-behave-tcp-08 (work in progress),
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 17]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+              September 2008.
+
+   [I-D.ietf-behave-nat-icmp]
+              Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
+              Behavioral Requirements for ICMP protocol",
+              draft-ietf-behave-nat-icmp-12 (work in progress),
+              January 2009.
+
+   [I-D.thaler-behave-translator-addressing]
+              Thaler, D., "IPv6 Addressing of IPv6/IPv4 Translators",
+              draft-thaler-behave-translator-addressing-00 (work in
+              progress), July 2009.
+
+10.2.  Informative References
+
+   [I-D.bagnulo-behave-nat64]
+              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
+              Address and Protocol Translation from IPv6 Clients to IPv4
+              Servers", draft-bagnulo-behave-nat64-03 (work in
+              progress), March 2009.
+
+   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
+              Translation - Protocol Translation (NAT-PT)", RFC 2766,
+              February 2000.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC1858]  Ziemba, G., Reed, D., and P. Traina, "Security
+              Considerations for IP Fragment Filtering", RFC 1858,
+              October 1995.
+
+   [RFC3128]  Miller, I., "Protection Against a Variant of the Tiny
+              Fragment Attack (RFC 1858)", RFC 3128, June 2001.
+
+   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
+              Address Translator (Traditional NAT)", RFC 3022,
+              January 2001.
+
+   [RFC3484]  Draves, R., "Default Address Selection for Internet
+              Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IP Version 6", RFC 3596,
+              October 2003.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 18]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+              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.
+
+   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
+              Address Translator - Protocol Translator (NAT-PT) to
+              Historic Status", RFC 4966, July 2007.
+
+   [I-D.iana-rfc3330bis]
+              Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+              draft-iana-rfc3330bis-06 (work in progress),
+              February 2009.
+
+   [I-D.ietf-mmusic-ice]
+              Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address  Translator (NAT)
+              Traversal for Offer/Answer Protocols",
+              draft-ietf-mmusic-ice-19 (work in progress), October 2007.
+
+   [I-D.ietf-6man-addr-select-sol]
+              Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
+              "Solution approaches for address-selection problems",
+              draft-ietf-6man-addr-select-sol-01 (work in progress),
+              June 2008.
+
+   [RFC3498]  Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of
+              Managed Objects for Synchronous Optical Network (SONET)
+              Linear Automatic Protection Switching (APS)
+              Architectures", RFC 3498, March 2003.
+
+   [I-D.wing-behave-learn-prefix]
+              Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix
+              of an IPv6/IPv4 Translator",
+              draft-wing-behave-learn-prefix-02 (work in progress),
+              May 2009.
+
+   [I-D.miyata-behave-prefix64]
+              Miyata, H. and M. Bagnulo, "PREFIX64 Comparison",
+              draft-miyata-behave-prefix64-02 (work in progress),
+              March 2009.
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 19]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   [I-D.venaas-behave-mcast46]
+              Venaas, S., "An IPv4 - IPv6 multicast translator",
+              draft-venaas-behave-mcast46-00 (work in progress),
+              December 2008.
+
+   [I-D.ietf-dnsop-default-local-zones]
+              Andrews, M., "Locally-served DNS Zones",
+              draft-ietf-dnsop-default-local-zones-08 (work in
+              progress), February 2009.
+
+
+Appendix A.  Deployment scenarios and examples
+
+   In this section, we first provide a description of the default
+   address transformation algorithm and then we walk through some sample
+   scenarios that are expected to be common deployment cases.  It should
+   be noted that is provided for illustrative purposes and this section
+   is not normative.  The normative definition of DNS64 is provided in
+   Section 5 and the normative definition of the address transformation
+   algorithm is provided in [I-D.thaler-behave-translator-addressing].
+
+   There are two main different setups where DNS64 is expected to be
+   used (other setups are possible as well, but these two are the main
+   ones identified at the time of this writing).
+
+      One possible setup that is expected to be common is the case of an
+      end site or an ISP that is providing IPv6-only connectivity or
+      connectivity to IPv6-only hosts that wants to allow the
+      communication from these IPv6-only connected hosts to the IPv4
+      Internet.  This case is called An-IPv6-network-to-IPv4-Internet.
+      In this case, the IPv6/IPv4 Translator is used to connect the end
+      site or the ISP to the IPv4 Internet and the DNS64 function is
+      provided by the end site or the ISP.
+
+      The other possible setup that is expected is an IPv4 site that
+      wants that its IPv4 servers to be reachable from the IPv6
+      Internet.  This case is called IPv6-Internet-to-an-IPv4-network.
+      It should be noted that the IPv4 addresses used in the IPv4 site
+      can be either public or private.  In this case, the IPv6/IPv4
+      Translator is used to connect the IPv4 end site to the IPv6
+      Internet and the DNS64 function is provided by the end site
+      itself.
+
+   In this section we illustrate how the DNS64 behaves in the different
+   scenarios that are expected to be common.  We consider then 3
+   possible scenarios, namely:
+
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 20]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   1.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
+       mode
+
+   2.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
+       resolver mode
+
+   3.  IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
+       mode
+
+   The notation used is the following: upper case letters are IPv4
+   addresses; upper case letters with a prime(') are IPv6 addresses;
+   lower case letters are ports; prefixes are indicated by "P::X", which
+   is an IPv6 address built from an IPv4 address X by adding the prefix
+   P, mappings are indicated as "(X,x) <--> (Y',y)".
+
+A.1.   Embed and Zero-Pad algorithm description
+
+   In this section we describe the default algorithm for the generation
+   of IPv6 address from IPv4 address to be implemented in the DNS64.
+
+   The only parameter required by the default algorithm is an IPv6
+   prefix.  This prefix is used to map IPv4 addresses into IPv6
+   addresses, and is denoted Pref64.  If we note n the length of the
+   prefix Pref64, then n must the less or equal than 96.  If an Pref64
+   is configured through any means in the DNS64 (such as manually
+   configured, or other automatic mean not specified in this document),
+   the default algorithm must use this prefix.  If no prefix is
+   available the algorithm must use the Well-Know prefix (include here
+   the prefix to be assigned by IANA) defined in
+   [I-D.thaler-behave-translator-addressing]
+
+   The input for the algorithm are:
+
+      The IPv4 address: X
+
+      The IPv6 prefix: Pref64::/n
+
+   The IPv6 address is generated by concatenating the prefix Pref64::/n,
+   the IPv4 address X and optionally (in case n is strictly smaller than
+   96) an all-zero suffix.  So, the resulting IPv6 address would be
+   Pref64:X::
+
+   Reverse algorithm
+
+   We next describe the reverse algorithm of the algorithm described in
+   the previous section.  This algorithm allows to generate and IPv4
+   address from an IPv6 address.  This reverse algorithm is NOT
+   implemented by the DNS64 but it is implemented in the IPv6/IPv4
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 21]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   translator that is serving the same domain the DNS64.
+
+   The only parameter required by the default algorithm is an IPv6
+   prefix.  This prefix is the one originally used to map IPv4 addresses
+   into IPv6 addresses, and is denoted Pref64.
+
+   The input for the algorithm are:
+
+      The IPv6 address: X'
+
+      The IPv6 prefix: Pref64::/n
+
+   First, the algorithm checks that the fist n bits of the IPv6 address
+   X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n =
+   X'/n.
+
+      If this is not the case, the algorithm ends and no IPv4 address is
+      generated.
+
+      If the verification is successful, then the bits between the n+1
+      and the n+32 of the IPv6 address X' are extracted to form the IPv4
+      address.
+
+A.2.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
+      mode
+
+   In this example, we consider an IPv6 node located in an IPv6-only
+   site that initiates a communication to an IPv4 node located in the
+   IPv4 Internet.
+
+   The scenario for this case is depicted in the following figure:
+
+
+      +---------------------------------------+         +-----------+
+      |IPv6 site       +-------------+        |IP Addr: |           |
+      |  +----+        | Name server |   +-------+ T    |   IPv4    |
+      |  | H1 |        | with DNS64  |   |64Trans|------| Internet  |
+      |  +----+        +-------------+   +-------+      +-----------+
+      |    |IP addr: Y'     |              |  |            |IP addr: X
+      |    ---------------------------------  |          +----+
+      +---------------------------------------+          | H2 |
+                                                         +----+
+
+   The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
+   IPv4 node H2 with IPv4 address X.
+
+   A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
+   Internet.  This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 22]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   an IPv4 address T assigned to its IPv4 interface.
+
+   The other element involved is the local name server.  The name server
+   is a dual-stack node, so that H1 can contact it via IPv6, while it
+   can contact IPv4-only name servers via IPv4.
+
+   The local name server needs to know the prefix assigned to the local
+   IPv6/IPv4 Translator (Pref64::/n).  For the purpose of this example,
+   we assume it learns this through manual configuration.
+
+   For this example, assume the typical DNS situation where IPv6 hosts
+   have only stub resolvers, and always query a name server that
+   performs recursive lookups (henceforth called "the recursive
+   nameserver").
+
+   The steps by which H1 establishes communication with H2 are:
+
+   1.  H1 does a DNS lookup for FQDN(H2).  H1 does this by sending a DNS
+       query for an AAAA record for H2 to the recursive name server.
+       The recursive name server implements DNS64 functionality.
+
+   2.  The recursive name server resolves the query, and discovers that
+       there are no AAAA records for H2.
+
+   3.  The recursive name server queries for an A record for H2 and gets
+       back an A record containing the IPv4 address X. The name server
+       then synthesizes an AAAA record.  The IPv6 address in the AAAA
+       record contains the prefix assigned to the IPv6/IPv4 Translator
+       in the upper n bits then the IPv4 address X and then an all-zero
+       padding i.e. the resulting IPv6 address is Pref64:X::
+
+   4.  H1 receives the synthetic AAAA record and sends a packet towards
+       H2.  The packet is sent from a source transport address of (Y',y)
+       to a destination transport address of (Pref64:X::,x), where y and
+       x are ports chosen by H2.
+
+   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
+       Translator and the subsequent communication flows by means of the
+       IPv6/IPv4 Translator mechanisms.
+
+A.3.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver
+      mode
+
+   The scenario for this case is depicted in the following figure:
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 23]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+      +---------------------------------------+         +-----------+
+      |IPv6 site             +-------+        |IP addr: |           |
+      |  +---------------+   | Name  |   +-------+  T   |   IPv4    |
+      |  | H1 with DNS64 |   | Server|   |64Trans|------| Internet  |
+      |  +---------------+   +-------+   +-------+      +-----------+
+      |        |IP addr: Y'      |         |  |            |IP addr: X
+      |    ---------------------------------  |          +----+
+      +---------------------------------------+          | H2 |
+                                                         +----+
+
+   The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
+   IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64
+   function.
+
+   A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
+   Internet.  This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
+   and an IPv4 address T assigned to its IPv4 interface.
+
+   H1 needs to know the prefix assigned to the local IPv6/IPv4
+   Translator (Pref64::/n).  For the purpose of this example, we assume
+   it learns this through manual configuration.
+
+   Also shown is a name server.  For the purpose of this example, we
+   assume that the name server is a dual-stack node, so that H1 can
+   contact it via IPv6, while it can contact IPv4-only name servers via
+   IPv4.
+
+   For this example, assume the typical situation where IPv6 hosts have
+   only stub resolvers and always query a name server that provides
+   recursive lookups (henceforth called "the recursive name server").
+   The recursive name server does not perform the DNS64 function.
+
+   The steps by which H1 establishes communication with H2 are:
+
+   1.  H1 does a DNS lookup for FQDN(H2).  H1 does this by sending a DNS
+       query for a AAAA record for H2 to the recursive name server.
+
+   2.  The recursive DNS server resolves the query, and returns the
+       answer to H1.  Because there are no AAAA records in the global
+       DNS for H2, the answer is empty.
+
+   3.  The stub resolver at H1 then queries for an A record for H2 and
+       gets back an A record containing the IPv4 address X. The DNS64
+       function within H1 then synthesizes a AAAA record.  The IPv6
+       address in the AAAA record contains the prefix assigned to the
+       IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X
+       and then an all-zero padding i.e. the resulting IPv6 address is
+       Pref64:X::.
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 24]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   4.  H1 sends a packet towards H2.  The packet is sent from a source
+       transport address of (Y',y) to a destination transport address of
+       (Pref64:X::,x), where y and x are ports chosen by H2.
+
+   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
+       Translator and the subsequent communication flows using the IPv6/
+       IPv4 Translator mechanisms.
+
+A.4.  IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode
+
+   In this example, we consider an IPv6 node located in the IPv6
+   Internet site that initiates a communication to a IPv4 node located
+   in the IPv4 site.
+
+   This scenario can be addressed without using any form of DNS64
+   function.  This is so because it is possible to assign a fixed IPv6
+   address to each of the IPv4 servers.  Such an IPv6 address would be
+   constructed as the Pref64::/n concatenated with the IPv4 address of
+   the IPv4 server and an all-zero padding.  Note that the IPv4 address
+   can be a public or a private address; the latter does not present any
+   additional difficulty, since the LIR prefix must be used a Pref64 (in
+   this scenario the usage of the WK prefix is not supported).  Once
+   these IPv6 addresses have been assigned to represent the IPv4 servers
+   in the IPv6 Internet, real AAAA RRs containing these addresses can be
+   published in the DNS under the site's domain.  This is the
+   recommended approach to handle this scenario, because it does not
+   involve synthesizing AAAA records at the time of query.  Such a
+   configuration is easier to troubleshoot in the event of problems,
+   because it always provides the same answer to every query.
+
+   However, there are some more dynamic scenarios, where synthesizing
+   AAAA RRs in this setup may be needed.  In particular, when DNS Update
+   [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
+   servers, there are two options: One option is to modify the server
+   that receives the dynamic DNS updates.  That would normally be the
+   authoritative server for the zone.  So the authoritative zone would
+   have normal AAAA RRs that are synthesized as dynamic updates occur.
+   The other option is modify the authoritative server to generate
+   synthetic AAAA records for a zone, possibly based on additional
+   constraints, upon the receipt of a DNS query for the AAAA RR.  The
+   first option -- in which the AAAA is synthesized when the DNS update
+   message is received, and the data published in the relevant zone --
+   is recommended over the second option (i.e. the synthesis upon
+   receipt of the AAAA DNS query).  This is because it is usually easier
+   to solve problems of misconfiguration and so on when the DNS
+   responses are not being generated dynamically.  For completeness, the
+   DNS64 behavior that we describe in this section covers the case of
+   synthesizing the AAAA RR when the DNS query arrives.  Nevertheless,
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 25]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   such a configuration is NOT RECOMMENDED.  Troubleshooting
+   configurations that change the data depending on the query they
+   receive is notoriously hard, and the IPv4/IPv6 translation scenario
+   is complicated enough without adding additional opportunities for
+   possible malfunction.
+
+   The scenario for this case is depicted in the following figure:
+
+
+     +-----------+          +----------------------------------------+
+     |           |          |   IPv4 site            +-------------+ |
+     |   IPv6    |      +-------+      +----+        | Name server | |
+     | Internet  |------|64Trans|      | H2 |        | with DNS64  | |
+     +-----------+      +-------+      +----+        +-------------+ |
+       |IP addr: Y'         |  |         |IP addr: X     |           |
+     +----+                 | -----------------------------------    |
+     | H1 |                 +----------------------------------------+
+     +----+
+
+   The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
+   IPv4 node H2 with IPv4 address X.
+
+   A IPv6/IPv4 Translator connects the IPv4 network to the IPv6
+   Internet.  This IPv6/IPv4 Translator has a prefix (called
+   Pref64::/n).
+
+   Also shown is the authoritative name server for the local domain with
+   DNS64 functionality.  For the purpose of this example, we assume that
+   the name server is a dual-stack node, so that H1 or a recursive
+   resolver acting on the request of H1 can contact it via IPv6, while
+   it can be contacted by IPv4-only nodes to receive dynamic DNS updates
+   via IPv4.
+
+   The local name server needs to know the prefix assigned to the local
+   IPv6/IPv4 Translator (Pref64::/n).  For the purpose of this example,
+   we assume it learns this through manual configuration.
+
+   The steps by which H1 establishes communication with H2 are:
+
+   1.  H1 does a DNS lookup for FQDN(H2).  H1 does this by sending a DNS
+       query for an AAAA record for H2.  The query is eventually
+       forwarded to the server in the IPv4 site.
+
+   2.  The local DNS server resolves the query (locally), and discovers
+       that there are no AAAA records for H2.
+
+   3.  The name server verifies that FQDN(H2) and its A RR are among
+       those that the local policy defines as allowed to generate a AAAA
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 26]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+       RR from.  If that is the case, the name server synthesizes an
+       AAAA record from the A RR and the relevant Pref64::/n.  The IPv6
+       address in the AAAA record contains the prefix assigned to the
+       IPv6/IPv4 Translator in the first n bits and the IPv4 address X
+       and then an all-zero padding.
+
+   4.  H1 receives the synthetic AAAA record and sends a packet towards
+       H2.  The packet is sent from a source transport address of (Y',y)
+       to a destination transport address of (Pref64:X::,x), where y and
+       x are ports chosen by H2.
+
+   5.  The packet is routed through the IPv6 Internet to the IPv6
+       interface of the IPv6/IPv4 Translator and the communication flows
+       using the IPv6/IPv4 Translator mechanisms.
+
+
+Appendix B.  Motivations and Implications of synthesizing AAAA RR when
+             real AAAA RR exists
+
+   The motivation for synthesizing AAAA RR when a real AAAA RR exists is
+   to support the following scenario:
+
+      An IPv4-only server application (e.g. web server software) is
+      running on a dual-stack host.  There may also be dual-stack server
+      applications also running on the same host.  That host has fully
+      routable IPv4 and IPv6 addresses and hence the authoritative DNS
+      server has an A and a AAAA record as a result.
+
+      An IPv6-only client (regardless of whether the client application
+      is IPv6-only, the client stack is IPv6-only, or it only has an
+      IPv6 address) wants to access the above server.
+
+      The client issues a DNS query to a DNS64 recursor.
+
+   If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
+   then the communication will fail.  Even though there's a real AAAA,
+   the only way for communication to succeed is with the translated
+   address.  So, in order to support this scenario, the administrator of
+   a DNS64 service may want to enable the synthesis of AAAA RR even when
+   real AAAA RR exist.
+
+   The implication of including synthetic AAAA RR when real AAAA RR
+   exist is that translated connectivity may be preferred over native
+   connectivity in some cases where the DNS64 is operated in DNS server
+   mode.
+
+   RFC3484 [RFC3484] rules use longest prefix match to select which is
+   the preferred destination address to use.  So, if the DNS64 recursor
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 27]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+   returns both the synthetic AAAA RR and the real AAAA RR, then if the
+   DNS64 is operated by the same domain as the initiating host, and a
+   global unicast prefix (called the LIR prefix as defined in
+   [I-D.thaler-behave-translator-addressing]) is used, then the
+   synthetic AAAA RR is likely to be preferred.
+
+   This means that without further configuration:
+
+      In the case of An IPv6 network to the IPv4 internet, the host will
+      prefer translated connectivity if LIR prefix is used.  If the
+      Well-Known (WK) prefix defined in
+      [I-D.thaler-behave-translator-addressing] is used, it will
+      probably prefer native connectivity.
+
+      In the case of the IPv6 Internet to an IPv4 network, it is
+      possible to bias the selection towards the real AAAA RR if the
+      DNS64 recursor returns the real AAAA first in the DNS reply, when
+      the LIR prefix is used (the WK prefix usage is not recommended in
+      this case)
+
+      In the case of the IPv6 to IPv4 in the same network, for local
+      destinations (i.e., target hosts inside the local site), it is
+      likely that the LIR prefix and the destination prefix are the
+      same, so we can use the order of RR in the DNS reply to bias the
+      selection through native connectivity.  If a WK prefix is used,
+      the longest prefix match rule will select native connectivity.
+
+   So this option introduces problems in the following cases:
+
+      An IPv6 network to the IPv4 internet with the LIR prefix
+
+      IPv6 to IPv4 in the same network when reaching external
+      destinations and the LIR prefix is used.
+
+   In any case, the problem can be solved by properly configuring the
+   RFC3484 [RFC3484] policy table, but this requires effort on the part
+   of the site operator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 28]
+
+Internet-Draft                    DNS64                     October 2009
+
+
+Authors' Addresses
+
+   Marcelo Bagnulo
+   UC3M
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   Spain
+
+   Phone: +34-91-6249500
+   Fax:
+   Email: marcelo@it.uc3m.es
+   URI:   http://www.it.uc3m.es/marcelo
+
+
+   Andrew Sullivan
+   Shinkuro
+   4922 Fairmont Avenue, Suite 250
+   Bethesda, MD  20814
+   USA
+
+   Phone: +1 301 961 3131
+   Email: ajs@shinkuro.com
+
+
+   Philip Matthews
+   Unaffiliated
+   600 March Road
+   Ottawa, Ontario
+   Canada
+
+   Phone: +1 613-592-4343 x224
+   Fax:
+   Email: philip_matthews@magma.ca
+   URI:
+
+
+   Iljitsch van Beijnum
+   IMDEA Networks
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   Spain
+
+   Phone: +34-91-6246245
+   Email: iljitsch@muada.com
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires April 22, 2010                [Page 29]
+
diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt
deleted file mode 100644
index fa41e7635e2f..000000000000
--- a/doc/draft/draft-ietf-dnsext-2929bis-01.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-Obsoletes RFC 2929, Updates RFC 1183               Motorola Laboratories
-Expires: February 2006                                       August 2005
-
-
-
-              Domain Name System (DNS) IANA Considerations
-              ------ ---- ------ ----- ---- --------------
-                   
-
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this draft is unlimited.  It is intended to become
-   the new BCP 42 obsoleting RFC 2929.  Comments should be sent to the
-   DNS Working Group mailing list .
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
-   Internet Assigned Number Authority (IANA) parameter assignment
-   considerations are given for the allocation of Domain Name System
-   (DNS) classes, RR types, operation codes, error codes, RR header
-   bits, and AFSDB subtypes.
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. DNS Query/Response Headers..............................3
-      2.1 One Spare Bit?.........................................4
-      2.2 Opcode Assignment......................................4
-      2.3 RCODE Assignment.......................................5
-      3. DNS Resource Records....................................6
-      3.1 RR TYPE IANA Considerations............................7
-      3.1.1 DNS TYPE Allocation Policy...........................8
-      3.1.2 Special Note on the OPT RR...........................9
-      3.1.3 The AFSDB RR Subtype Field...........................9
-      3.2 RR CLASS IANA Considerations...........................9
-      3.3 RR NAME Considerations................................11
-      4. Security Considerations................................11
-
-      Appendix: Changes from RFC 2929...........................12
-
-      Copyright and Disclaimer..................................13
-      Normative References......................................13
-      Informative References....................................14
-
-      Authors Addresses.........................................16
-      Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-1. Introduction
-
-   The Domain Name System (DNS) provides replicated distributed secure
-   hierarchical databases which hierarchically store "resource records"
-   (RRs) under domain names.  DNS data is structured into CLASSes and
-   zones which can be independently maintained.  See [RFC 1034, 1035,
-   2136, 2181, 4033] familiarity with which is assumed.
-
-   This document provides, either directly or by reference, general IANA
-   parameter assignment considerations applying across DNS query and
-   response headers and all RRs.  There may be additional IANA
-   considerations that apply to only a particular RR type or
-   query/response opcode.  See the specific RFC defining that RR type or
-   query/response opcode for such considerations if they have been
-   defined, except for AFSDB RR considerations [RFC 1183] which are
-   included herein. This RFC obsoletes [RFC 2929].
-
-   IANA currently maintains a web page of DNS parameters.  See
-   .
-
-   "IETF Standards Action", "IETF Consensus", "Specification Required",
-   and "Private Use" are as defined in [RFC 2434].
-
-
-
-2. DNS Query/Response Headers
-
-   The header for DNS queries and responses contains field/bits in the
-   following diagram taken from [RFC 2136, 2929]:
-
-                                              1  1  1  1  1  1
-                0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                      ID                       |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                QDCOUNT/ZOCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                ANCOUNT/PRCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                NSCOUNT/UPCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                    ARCOUNT                    |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The ID field identifies the query and is echoed in the response so
-   they can be matched.
-
-   The QR bit indicates whether the header is for a query or a response.
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
-   only in queries or only in responses, depending on the bit.  However,
-   many DNS implementations copy the query header as the initial value
-   of the response header without clearing bits.  Thus any attempt to
-   use a "query" bit with a different meaning in a response or to define
-   a query meaning for a "response" bit is dangerous given existing
-   implementation.  Such meanings may only be assigned by an IETF
-   Standards Action.
-
-   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
-   authority count (NSCOUNT), and additional information count (ARCOUNT)
-   express the number of records in each section for all opcodes except
-   Update.  These fields have the same structure and data type for
-   Update but are instead the counts for the zone (ZOCOUNT),
-   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
-   (ARCOUNT) sections.
-
-
-
-2.1 One Spare Bit?
-
-   There have been ancient DNS implementations for which the Z bit being
-   on in a query meant that only a response from the primary server for
-   a zone is acceptable.  It is believed that current DNS
-   implementations ignore this bit.
-
-   Assigning a meaning to the Z bit requires an IETF Standards Action.
-
-
-
-2.2 Opcode Assignment
-
-   Currently DNS OpCodes are assigned as follows:
-
-          OpCode Name                      Reference
-
-           0     Query                     [RFC 1035]
-           1     IQuery  (Inverse Query, Obsolete) [RFC 3425]
-           2     Status                    [RFC 1035]
-           3     available for assignment
-           4     Notify                    [RFC 1996]
-           5     Update                    [RFC 2136]
-          6-15   available for assignment
-
-   New OpCode assignments require an IETF Standards Action as modified
-   by [RFC 4020].
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-2.3 RCODE Assignment
-
-   It would appear from the DNS header above that only four bits of
-   RCODE, or response/error code are available.  However, RCODEs can
-   appear not only at the top level of a DNS response but also inside
-   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
-   The OPT RR provides an eight bit extension resulting in a 12 bit
-   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
-
-   Error codes appearing in the DNS header and in these three RR types
-   all refer to the same error code space with the single exception of
-   error code 16 which has a different meaning in the OPT RR from its
-   meaning in other contexts.  See table below.
-
-        RCODE   Name    Description                        Reference
-        Decimal
-          Hexadecimal
-         0    NoError   No Error                           [RFC 1035]
-         1    FormErr   Format Error                       [RFC 1035]
-         2    ServFail  Server Failure                     [RFC 1035]
-         3    NXDomain  Non-Existent Domain                [RFC 1035]
-         4    NotImp    Not Implemented                    [RFC 1035]
-         5    Refused   Query Refused                      [RFC 1035]
-         6    YXDomain  Name Exists when it should not     [RFC 2136]
-         7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
-         8    NXRRSet   RR Set that should exist does not  [RFC 2136]
-         9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
-        10    NotZone   Name not contained in zone         [RFC 2136]
-        11 - 15         Available for assignment
-        16    BADVERS   Bad OPT Version                    [RFC 2671]
-        16    BADSIG    TSIG Signature Failure             [RFC 2845]
-        17    BADKEY    Key not recognized                 [RFC 2845]
-        18    BADTIME   Signature out of time window       [RFC 2845]
-        19    BADMODE   Bad TKEY Mode                      [RPC 2930]
-        20    BADNAME   Duplicate key name                 [RPF 2930]
-        21    BADALG    Algorithm not supported            [RPF 2930]
-
-        22 - 3,840
-          0x0016 - 0x0F00   Available for assignment
-
-        3,841 - 4,095
-          0x0F01 - 0x0FFF   Private Use
-
-        4,096 - 65,534
-          0x1000 - 0xFFFE   Available for assignment
-
-        65,535
-          0xFFFF            Reserved, can only be allocated by an IETF
-                            Standards Action.
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   Since it is important that RCODEs be understood for interoperability,
-   assignment of new RCODE listed above as "available for assignment"
-   requires an IETF Consensus.
-
-
-
-3. DNS Resource Records
-
-   All RRs have the same top level format shown in the figure below
-   taken from [RFC 1035]:
-
-                                       1  1  1  1  1  1
-         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                                               |
-       /                                               /
-       /                      NAME                     /
-       |                                               |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                      TYPE                     |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                     CLASS                     |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                      TTL                      |
-       |                                               |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                   RDLENGTH                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-       /                     RDATA                     /
-       /                                               /
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   NAME is an owner name, i.e., the name of the node to which this
-   resource record pertains.  NAMEs are specific to a CLASS as described
-   in section 3.2.  NAMEs consist of an ordered sequence of one or more
-   labels each of which has a label type [RFC 1035, 2671].
-
-   TYPE is a two octet unsigned integer containing one of the RR TYPE
-   codes.  See section 3.1.
-
-   CLASS is a two octet unsigned integer containing one of the RR CLASS
-   codes.  See section 3.2.
-
-   TTL is a four octet (32 bit) bit unsigned integer that specifies the
-   number of seconds that the resource record may be cached before the
-   source of the information should again be consulted.  Zero is
-   interpreted to mean that the RR can only be used for the transaction
-   in progress.
-
-   RDLENGTH is an unsigned 16 bit integer that specifies the length in
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   octets of the RDATA field.
-
-   RDATA is a variable length string of octets that constitutes the
-   resource. The format of this information varies according to the TYPE
-   and in some cases the CLASS of the resource record.
-
-
-
-3.1 RR TYPE IANA Considerations
-
-   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
-   and MetaTYPEs.
-
-   Data TYPEs are the primary means of storing data.  QTYPES can only be
-   used in queries.  Meta-TYPEs designate transient data associated with
-   an particular DNS message and in some cases can also be used in
-   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
-   the block from 100 through 103 while Q and Meta Types have been
-   assigned from 255 downwards except for the OPT Meta-RR which is
-   assigned TYPE 41.  There have been DNS implementations which made
-   caching decisions based on the top bit of the bottom byte of the RR
-   TYPE.
-
-   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
-   [RFC 2845], and TKEY [RFC 2930].
-
-   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
-   AXFR, and IXFR.
-
-   Considerations for the allocation of new RR TYPEs are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
-          2535] and in other circumstances and must never be allocated
-          for ordinary use.
-
-     1 - 127
-   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
-          TYPEs by the DNS TYPE Allocation Policy as specified in
-          section 3.1.1.
-
-     128 - 255
-   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
-          Meta TYPEs by the DNS TYPE Allocation Policy as specified in
-          section 3.1.1.
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-     256 - 32,767
-   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
-          TYPE Allocation Policy as specified in section 3.1.1.
-
-     32,768 - 65,279
-   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
-     65,280 - 65534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65,535
-   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-
-3.1.1 DNS TYPE Allocation Policy
-
-   Parameter values specified above as assigned based on DNS TYPE
-   Allocation Policy. That is, Expert Review with the additional
-   requirement that the review be based on a complete template as
-   specified below which has been posted for three weeks to the
-   namedroppers@ops.ietf.org mailing list.
-
-   Partial or draft templates may be posted with the intend of
-   soliciting feedback.
-
-
-                 DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
-
-        Date:
-
-        Name and email of originator:
-
-        Pointer to internet-draft or other document giving a detailed
-        description of the protocol use of the new RR Type:
-
-        What need is the new RR TYPE intended to fix?
-
-        What existing RR TYPE(s) come closest to filling that need and why are
-        they unsatisfactory?
-
-        Does the proposed RR TYPR require special handling within the DNS
-        different from an Unknown RR TYPE?
-
-        Comments:
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-3.1.2 Special Note on the OPT RR
-
-   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
-   primary purpose is to extend the effective field size of various DNS
-   fields including RCODE, label type, OpCode, flag bits, and RDATA
-   size.  In particular, for resolvers and servers that recognize it, it
-   extends the RCODE field from 4 to 12 bits.
-
-
-
-3.1.3 The AFSDB RR Subtype Field
-
-   The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
-   RDATA field structure as the MX RR but the 16 bit unsigned integer
-   field at the beginning of the RDATA is interpreted as a subtype as
-   follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 -  Allocation requires IETF Standards Action.
-
-     1
-   0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
-
-     2
-   0x0002 - DCE/NCA root cell directory node [RFC 1183].
-
-     3 - 65,279
-   0x0003 - 0xFEFF - Allocation by IETF Consensus.
-
-     65,280 - 65,534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65,535
-   0xFFFF - Reserved, allocation requires IETF Standards Action.
-
-
-
-3.2 RR CLASS IANA Considerations
-
-   DNS CLASSes have been little used but constitute another dimension of
-   the DNS distributed database.  In particular, there is no necessary
-   relationship between the name space or root servers for one CLASS and
-   those for another CLASS.  The same name can have completely different
-   meanings in different CLASSes; however, the label types are the same
-   and the null label is usable only as root in every CLASS.  However,
-   as global networking and DNS have evolved, the IN, or Internet, CLASS
-   has dominated DNS use.
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   There are two subcategories of DNS CLASSes: normal data containing
-   classes and QCLASSes that are only meaningful in queries or updates.
-
-   The current CLASS assignments and considerations for future
-   assignments are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - Reserved, assignment requires an IETF Standards Action.
-
-     1
-   0x0001 - Internet (IN).
-
-     2
-   0x0002 - Available for assignment by IETF Consensus as a data CLASS.
-
-     3
-   0x0003 - Chaos (CH) [Moon 1981].
-
-     4
-   0x0004 - Hesiod (HS) [Dyer 1987].
-
-     5 - 127
-   0x0005 - 0x007F - available for assignment by IETF Consensus for data
-          CLASSes only.
-
-     128 - 253
-   0x0080 - 0x00FD - available for assignment by IETF Consensus for
-          QCLASSes only.
-
-     254
-   0x00FE - QCLASS None [RFC 2136].
-
-     255
-   0x00FF - QCLASS Any [RFC 1035].
-
-     256 - 32,767
-   0x0100 - 0x7FFF - Assigned by IETF Consensus.
-
-     32,768 - 65,279
-   0x8000 - 0xFEFF - Assigned based on Specification Required as defined
-          in [RFC 2434].
-
-     65,280 - 65,534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65,535
-   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-D. Eastlake 3rd                                                [Page 10]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-3.3 RR NAME Considerations
-
-   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
-   NAME is "ROOT" which is the zero length label.  By definition, the
-   null or ROOT label can not be used for any other NAME purpose.
-
-   At the present time, there are two categories of label types, data
-   labels and compression labels.  Compression labels are pointers to
-   data labels elsewhere within an RR or DNS message and are intended to
-   shorten the wire encoding of NAMEs.  The two existing data label
-   types are sometimes referred to as Text and Binary.  Text labels can,
-   in fact, include any octet value including zero value octets but most
-   current uses involve only [US-ASCII].  For retrieval, Text labels are
-   defined to treat ASCII upper and lower case letter codes as matching
-   [insensitive].  Binary labels are bit sequences [RFC 2673]. The
-   Binary label type is Experimental [RFC 3363].
-
-   IANA considerations for label types are given in [RFC 2671].
-
-   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
-   1981] CLASSes are essentially for local use.  The IN or Internet
-   CLASS is thus the only DNS CLASS in global use on the Internet at
-   this time.
-
-   A somewhat out-of-date description of name allocation in the IN Class
-   is given in [RFC 1591].  Some information on reserved top level
-   domain names is in BCP 32 [RFC 2606].
-
-
-
-4. Security Considerations
-
-   This document addresses IANA considerations in the allocation of
-   general DNS parameters, not security.  See [RFC 4033, 4034, 4035] for
-   secure DNS considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 11]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Appendix: Changes from RFC 2929
-
-   RFC Editor: This Appendix should be deleted for publication.
-
-   Changes from RFC 2929 to this draft:
-
-   1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
-   Allocation Policy" and add the specification of that policy. Change
-   some remaining "IETF Standards Action" allocation requirements to say
-   "as modified by [RFC 4020]".
-
-   2. Updated various RFC references.
-
-   3. Mentioned that the Binary label type is now Experimental and
-   IQuery is Obsolete.
-
-   4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
-   IETF Standards Action required.
-
-   5. Add an IANA allocation policy for the AFSDB RR Subtype field.
-
-   6. Addition of reference to case insensitive draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 12]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2005).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except
-   as set forth therein, the authors retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Normative References
-
-   [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
-   Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
-   Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
-   Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
-
-   [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
-   Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
-   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-   April 1997.
-
-   [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
-   Specification", RFC 2181, July 1997.
-
-   [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
-   IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
-   2671, August 1999.
-
-   [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
-   RFC 2673, August 1999.
-
-   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
-   RFC 2845, May 2000.
-
-
-D. Eastlake 3rd                                                [Page 13]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
-   RR)", September 2000.
-
-   [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
-   Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
-   the Domain Name System (DNS)", RFC 3363, August 2002.
-
-   [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
-   2002.
-
-   [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
-   Standards Track Code Points", BCP 100, RFC 4020, February 2005.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-   [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
-   X3.4, American National Standards Institute: New York, 1968.
-
-
-
-Informative References
-
-   [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
-   Technical Plan - Name Service, April 1987,
-
-   [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
-   Institute of Technology Artificial Intelligence Laboratory, June
-   1981.
-
-   [RFC 1591] - Postel, J., "Domain Name System Structure and
-   Delegation", RFC 1591, March 1994.
-
-   [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
-   "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
-   September 2000.
-
-   [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
-   Names", RFC 2606, June 1999.
-
-   [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
-
-
-D. Eastlake 3rd                                                [Page 14]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
-   work in progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 15]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Authors Addresses
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554 (w)
-   email:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires February 2006.
-
-   Its file name is draft-ietf-dnsext-2929bis-01.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 16]
-
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
deleted file mode 100644
index f0ce70ab1c99..000000000000
--- a/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-
-INTERNET-DRAFT                                      Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-05.txt                     Nominum Inc.
-                                                         November 2002
-
-
-               DNS Zone Transfer Protocol Clarifications
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   In the Domain Name System, zone data is replicated among
-   authoritative DNS servers by means of the "zone transfer" protocol,
-   also known as the "AXFR" protocol.  This memo clarifies, updates, and
-   adds missing detail to the original AXFR protocol specification in
-   RFC1034.
-
-1. Introduction
-
-   The original definition of the DNS zone transfer protocol consists of
-   a single paragraph in [RFC1034] section 4.3.5 and some additional
-   notes in [RFC1035] section 6.3.  It is not sufficiently detailed to
-   serve as the sole basis for constructing interoperable
-   implementations.  This document is an attempt to provide a more
-   complete definition of the protocol.  Where the text in RFC1034
-   conflicts with existing practice, the existing practice has been
-   codified in the interest of interoperability.
-
-
-
-
-Expires May 2003                                                [Page 1]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-2. The zone transfer request
-
-   To initiate a zone transfer, the slave server sends a zone transfer
-   request to the master server over a reliable transport such as TCP.
-   The form of this request is specified in sufficient detail in RFC1034
-   and needs no further clarification.
-
-   Implementers are advised that one server implementation in widespread
-   use sends AXFR requests where the TCP message envelope size exceeds
-   the DNS request message size by two octets.
-
-3. The zone transfer response
-
-   If the master server is unable or unwilling to provide a zone
-   transfer, it MUST respond with a single DNS message containing an
-   appropriate RCODE other than NOERROR.  If the master is not
-   authoritative for the requested zone, the RCODE SHOULD be 9
-   (NOTAUTH).
-
-   Slave servers should note that some master server implementations
-   will simply close the connection when denying the slave access to the
-   zone.  Therefore, slaves MAY interpret an immediate graceful close of
-   the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
-   If a zone transfer can be provided, the master server sends one or
-   more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
-   The zone data in a zone transfer response is a sequence of answer
-   RRs.  These RRs are transmitted in the answer section(s) of one or
-   more DNS response messages.
-
-   The AXFR protocol definition in RFC1034 does not make a clear
-   distinction between response messages and answer RRs.  Historically,
-   DNS servers always transmitted a single answer RR per message.  This
-   encoding is wasteful due to the overhead of repeatedly sending DNS
-   message headers and the loss of domain name compression
-   opportunities.  To improve efficiency, some newer servers support a
-   mode where multiple RRs are transmitted in a single DNS response
-   message.
-
-   A master MAY transmit multiple answer RRs per response message up to
-   the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires May 2003                                                [Page 2]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   DNS message size.  In the case of a small zone, this can cause the
-   entire transfer to be transmitted in a single response message.
-
-   Slaves MUST accept messages containing any number of answer RRs.  For
-   compatibility with old slaves, masters that support sending multiple
-   answers per message SHOULD be configurable to revert to the
-   historical mode of one answer per message, and the configuration
-   SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
-   RFC1034 does not specify the contents of the DNS message header of
-   the zone transfer response messages.  The header of each message MUST
-   be as follows:
-
-       ID      Copy from request
-       QR      1
-       OPCODE  QUERY
-       AA      1, but MAY be 0 when RCODE is not NOERROR
-       TC      0
-       RD      Copy from request, or 0
-       RA      Set according to availability of recursion, or 0
-       Z       0
-       AD      0
-       CD      0
-       RCODE   NOERROR on success, error code otherwise
-
-   The slave MUST check the RCODE in each message and abort the transfer
-   if it is not NOERROR.  It SHOULD check the ID of the first message
-   received and abort the transfer if it does not match the ID of the
-   request.  The ID SHOULD be ignored in subsequent messages, and fields
-   other than RCODE and ID SHOULD be ignored in all messages, to ensure
-   interoperability with certain older implementations which transmit
-   incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
-   Zone transfer responses are not subject to any kind of additional
-   section processing or automatic inclusion of SIG records.  SIG RRs in
-   the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
-   RFC1034 does not specify whether zone transfer response messages have
-   a question section or not.  The initial message of a zone transfer
-   response SHOULD have a question section identical to that in the
-   request.  Subsequent messages SHOULD NOT have a question section,
-   though the final message MAY.  The receiving slave server MUST accept
-
-
-
-Expires May 2003                                                [Page 3]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   any combination of messages with and without a question section.
-
-3.5. The authority section
-
-   The master server MUST transmit messages with an empty authority
-   section.  Slaves MUST ignore any authority section contents they may
-   receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
-   The additional section MAY contain additional RRs such as transaction
-   signatures.  The slave MUST ignore any unexpected RRs in the
-   additional section.  It MUST NOT treat additional section RRs as zone
-   data.
-
-4. Zone data
-
-   The purpose of the zone transfer mechanism is to exactly replicate at
-   each slave the set of RRs associated with a particular zone at its
-   primary master.  An RR is associated with a zone by being loaded from
-   the master file of that zone at the primary master server, or by some
-   other, equivalent method for configuring zone data.
-
-   This replication shall be complete and unaltered, regardless of how
-   many and which intermediate masters/slaves are involved, and
-   regardless of what other zones those intermediate masters/slaves do
-   or do not serve, and regardless of what data may be cached in
-   resolvers associated with the intermediate masters/slaves.
-
-   Therefore, in a zone transfer the master MUST send exactly those
-   records that are associated with the zone, whether or not their owner
-   names would be considered to be "in" the zone for purposes of
-   resolution, and whether or not they would be eligible for use as glue
-   in responses.  The transfer MUST NOT include any RRs that are not
-   associated with the zone, such as RRs associated with zones other
-   than the one being transferred or present in the cache of the local
-   resolver, even if their owner names are in the zone being transferred
-   or are pointed to by NS records in the zone being transferred.
-
-   The slave MUST associate the RRs received in a zone transfer with the
-   specific zone being transferred, and maintain that association for
-   purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
-   RFC1034 states that "The first and last messages must contain the
-   data for the top authoritative node of the zone".  This is not
-   consistent with existing practice.  All known master implementations
-
-
-
-Expires May 2003                                                [Page 4]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   send, and slave implementations expect to receive, the zone's SOA RR
-   as the first and last record of the transfer.
-
-   Therefore, the quoted sentence is hereby superseded by the sentence
-   "The first and last RR transmitted must be the SOA record of the
-   zone".
-
-   The initial and final SOA record MUST be identical, with the possible
-   exception of case and compression.  In particular, they MUST have the
-   same serial number.  The slave MUST consider the transfer to be
-   complete when, and only when, it has received the message containing
-   the second SOA record.
-
-   The transmission order of all other RRs in the zone is undefined.
-   Each of them SHOULD be transmitted only once, and slaves MUST ignore
-   any duplicate RRs received.
-
-6. Security Considerations
-
-   The zone transfer protocol as defined in [RFC1034] and clarified by
-   this memo does not have any built-in mechanisms for the slave to
-   securely verify the identity of the master server and the integrity
-   of the transferred zone data.  The use of a cryptographic mechanism
-   for ensuring authenticity and integrity, such as TSIG [RFC2845],
-   IPSEC, or TLS, is RECOMMENDED.
-
-   The zone transfer protocol allows read-only public access to the
-   complete zone data.  Since data in the DNS is public by definition,
-   this is generally acceptable.  Sites that wish to avoid disclosing
-   their full zone data MAY restrict zone transfer access to authorized
-   slaves.
-
-   These clarifications are not believed to themselves introduce any new
-   security problems, nor to solve any existing ones.
-
-Acknowledgements
-
-   Many people have contributed input and commentary to earlier versions
-   of this document, including but not limited to Bob Halley, Dan
-   Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
-   Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
-   Trenholme, and Brian Wellington.
-
-References
-
-   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
-   November 1987.
-
-
-
-
-Expires May 2003                                                [Page 5]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   [RFC1035] - Domain Names - Implementation and Specifications, P.
-   Mockapetris, November 1987.
-
-   [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
-   S. Bradner, BCP 14, March 1997.
-
-   [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG).  P.
-   Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
-   Andreas Gustafsson
-   Nominum Inc.
-   2385 Bay Rd
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6004
-
-   Email: gson@nominum.com
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000 - 2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published and
-   distributed, in whole or in part, without restriction of any kind,
-   provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-
-
-
-Expires May 2003                                                [Page 6]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2003                                                [Page 7]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt
new file mode 100644
index 000000000000..b0a269b1113d
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt
@@ -0,0 +1,1579 @@
+
+
+
+
+
+DNS Extensions Working Group                                Edward Lewis
+Internet-Draft                                             NeuStar, Inc.
+Updates: 1034, 1035 (if approved)                              A. Hoenes
+Intended status: Standards Track                                  TR-Sys
+Expires: June  6, 2010                                 December  6, 2009
+
+
+                    DNS Zone Transfer Protocol (AXFR)
+                    draft-ietf-dnsext-axfr-clarify-12
+
+Abstract
+
+   The Domain Name System standard mechanisms for maintaining coherent
+   servers for a zone consist of three elements.  One mechanism is the
+   Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
+   The definition of AXFR has proven insufficient in detail, thereby
+   forcing implementations intended to be compliant to make assumptions,
+   impeding interoperability.  Yet today we have a satisfactory set of
+   implementations that do interoperate.  This document is a new
+   definition of AXFR -- new in the sense that is it recording an
+   accurate definition of an interoperable AXFR mechanism.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79. This document may contain material
+   from IETF Documents or IETF Contributions published or made publicly
+   available before November 10, 2008.  The person(s) controlling the
+   copyright in some of this material may not have granted the IETF
+   Trust the right to allow modifications of such material outside the
+   IETF Standards Process.  Without obtaining an adequate license from
+   the person(s) controlling the copyright in such materials, this
+   document may not be modified outside the IETF Standards Process, and
+   derivative works of it may not be created outside the IETF Standards
+   Process, except to format it for publication as an RFC or to
+   translate it into languages other than English.
+
+   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
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                 [Page 1]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   This Internet-Draft will expire on June 6, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                 [Page 2]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
+   1.1.  Definition of Terms  . . . . . . . . . . . . . . . . . . .  4
+   1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   1.3.  Context  . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   1.4.  Coverage and Relationship to Original AXFR Specification .  5
+   2.  AXFR Messages  . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.1.  AXFR query . . . . . . . . . . . . . . . . . . . . . . . .  8
+   2.1.1.  Header Values  . . . . . . . . . . . . . . . . . . . . .  9
+   2.1.2.  Question Section . . . . . . . . . . . . . . . . . . . . 10
+   2.1.3.  Answer Section . . . . . . . . . . . . . . . . . . . . . 10
+   2.1.4.  Authority Section  . . . . . . . . . . . . . . . . . . . 10
+   2.1.5.  Additional Section . . . . . . . . . . . . . . . . . . . 10
+   2.2.  AXFR Response  . . . . . . . . . . . . . . . . . . . . . . 11
+   2.2.1.  "0 Message" Response . . . . . . . . . . . . . . . . . . 11
+   2.2.2.  Header Values  . . . . . . . . . . . . . . . . . . . . . 12
+   2.2.3.  Question Section . . . . . . . . . . . . . . . . . . . . 14
+   2.2.4.  Answer Section . . . . . . . . . . . . . . . . . . . . . 14
+   2.2.5.  Authority Section  . . . . . . . . . . . . . . . . . . . 14
+   2.2.6.  Additional Section . . . . . . . . . . . . . . . . . . . 14
+   2.3.  TCP Connection Aborts  . . . . . . . . . . . . . . . . . . 14
+   3.  Zone Contents  . . . . . . . . . . . . . . . . . . . . . . . 15
+   3.1.  Records to Include . . . . . . . . . . . . . . . . . . . . 15
+   3.2.  Delegation Records . . . . . . . . . . . . . . . . . . . . 16
+   3.3.  Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18
+   3.4.  Name Compression . . . . . . . . . . . . . . . . . . . . . 18
+   3.5.  Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19
+   4.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . 19
+   4.1.  TCP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   4.1.1.  AXFR client TCP  . . . . . . . . . . . . . . . . . . . . 20
+   4.1.2.  AXFR server TCP  . . . . . . . . . . . . . . . . . . . . 21
+   4.2.  UDP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+   5.  Authorization  . . . . . . . . . . . . . . . . . . . . . . . 22
+   6.  Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23
+   7.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . 24
+   7.1.  Server . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+   7.2.  Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . 25
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 25
+   10.  Internationalization Considerations . . . . . . . . . . . . 25
+   11.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
+   12.  References  . . . . . . . . . . . . . . . . . . . . . . . . 25
+   12.1.  Normative References  . . . . . . . . . . . . . . . . . . 26
+   12.2.  Informative References  . . . . . . . . . . . . . . . . . 27
+   13.  Editor's Address  . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                 [Page 3]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+1.  Introduction
+
+   The Domain Name System standard facilities for maintaining coherent
+   servers for a zone consist of three elements.  Authoritative Transfer
+   (AXFR) is defined in "Domain Names - Concepts and Facilities"
+   [RFC1034] (referred to in this document as RFC 1034) and "Domain
+   Names - Implementation and Specification" [RFC1035] (henceforth
+   RFC 1035).  Incremental Zone Transfer (IXFR) is defined in
+   "Incremental Zone Transfer in DNS" [RFC1995].  A mechanism for prompt
+   notification of zone changes (NOTIFY) is defined in "A Mechanism for
+   Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996].  The
+   goal of these mechanisms is to enable a set of DNS name servers to
+   remain coherently authoritative for a given zone.
+
+   This document re-specifies the AXFR mechanism as it is deployed in
+   the Internet at large, hopefully with the precision expected from
+   modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
+
+1.1.  Definition of Terms
+
+   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 "Key words for use in
+   RFCs to Indicate Requirement Levels" [BCP14].
+
+   Use of "newer"/"new" and "older"/"old" DNS refers to implementations
+   written after and prior to the publication of this document.
+
+   "General purpose DNS implementation" refers to DNS software developed
+   for wide-spread use.  This includes resolvers and servers freely
+   accessible as libraries and standalone processes.  This also includes
+   proprietary implementations used only in support of DNS service
+   offerings.
+
+   "Turnkey DNS implementation" refers to custom made, single use
+   implementations of DNS.  Such implementations consist of software
+   that employs the DNS protocol message format yet does not conform to
+   the entire range of DNS functionality.
+
+   The terms "AXFR session", "AXFR server" and "AXFR client" will be
+   introduced in the first paragraph of Section 2, after some more
+   context has been established.
+
+1.2.  Scope
+
+   In general terms, authoritative name servers for a given zone can use
+   various means to achieve coherency of the zone contents they serve.
+   For example, there are DNS implementations that assemble answers from
+   data stored in relational databases (as opposed to master files),
+
+
+Lewis & Hoenes             Expires June 6, 2010                 [Page 4]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   relying on the database's non-DNS means to synchronize the database
+   instances.  Some of these non-DNS solutions interoperate in some
+   fashion.  However, AXFR, IXFR, and NOTIFY are the only protocol-
+   defined in-band mechanisms to provide coherence of a set of name
+   servers, and they are the only mechanisms specified by the IETF.
+
+   This document does not cover incoherent DNS situations.  There are
+   applications of the DNS in which servers for a zone are designed to
+   be incoherent.  For these configurations, a coherency mechanism as
+   described here would be unsuitable.
+
+   A DNS implementation is not required to support AXFR, IXFR, and
+   NOTIFY, but it should have some means for maintaining name server
+   coherency.  A general purpose DNS implementation will likely support
+   AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
+   implementations may exist without AXFR.
+
+1.3.  Context
+
+   Besides describing the mechanisms themselves, there is the context in
+   which they operate to consider.  In the initial specifications of
+   AXFR (and IXFR and NOTIFY), little consideration was given to
+   security and privacy issues.  Since the original definition of AXFR,
+   new opinions have appeared on the access to an entire zone's
+   contents.  In this document, the basic mechanisms will be discussed
+   separately from the permission to use these mechanisms.
+
+1.4.  Coverage and Relationship to Original AXFR Specification
+
+   This document concentrates on just the definition of AXFR.  Any
+   effort to update the specification of the IXFR or NOTIFY mechanisms
+   is left to different documents.
+
+   The original "specification" of the AXFR sub-protocol is scattered
+   through RFC 1034 and RFC 1035.  Section 2.2 of RFC 1035 (on page 5)
+   depicts the scenario for which AXFR has been designed.  Section 4.3.5
+   of RFC 1034 describes the zone synchronization strategies in general
+   and rules for the invocation of a full zone transfer via AXFR; the
+   fifth paragraph of that section contains a very short sketch of the
+   AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
+   flaw in that specification.  Section 3.2.3 of RFC 1035 has assigned
+   the code point for the AXFR QTYPE (see Section 2.1.2 below for more
+   details).  Section 4.2 of RFC 1035 discusses the transport layer use
+   of DNS and shortly explains why UDP transport is deemed inappropriate
+   for AXFR; the last paragraph of Section 4.2.2 gives details for the
+   TCP connection management with AXFR.  Finally, the second paragraph
+   of Section 6.3 in RFC 1035 mandates server behavior when zone data
+   changes occur during an ongoing zone transfer using AXFR.
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                 [Page 5]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   This document will update the specification of AXFR.  To this end, it
+   fully specifies the record formats and processing rules for AXFR,
+   largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it
+   details the transport considerations for AXFR, thus amending Section
+   4.2.2 of RFC 1035.  Furthermore, it discusses backward compatibility
+   issues and provides policy/management considerations as well as
+   specific Security Considerations for AXFR.  The goal of this document
+   is to define AXFR as it exists, or is supposed to exist, currently.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                 [Page 6]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+2.  AXFR Messages
+
+   An AXFR session consists of an AXFR query message and the sequence of
+   AXFR response messages returned for it.  In this document, the AXFR
+   client is the sender of the AXFR query and the AXFR server is the
+   responder.  (Use of terms such as master, slave, primary, secondary
+   are not important to defining AXFR.)  The use of the word "session"
+   without qualification refers to an AXFR session.
+
+   An important aspect to keep in mind is that the definition of AXFR is
+   restricted to TCP [RFC0793].  The design of the AXFR process has
+   certain inherent features that are not easily ported to UDP
+   [RFC0768].
+
+   The basic format of an AXFR message is the DNS message as defined in
+   Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
+   following documents.
+
+   o  The 'Basic' DNS specification:
+
+   -  "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)"
+       [RFC1996]
+   -  "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
+   -  "Clarifications to the DNS Specification" [RFC2181]
+   -  "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
+   -  "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
+   -  "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
+   -  "Obsoleting IQUERY" [RFC3425]
+   -  "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
+   -  "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
+   -  "Domain Name System (DNS) IANA Considerations" [RFC5395]
+
+   o  Further additions related to the DNS Security Extensions (DNSSEC),
+      defined in these base documents:
+
+   -  "DNS Security Introduction and Requirements" [RFC4033]
+   -  "Resource Records for the DNS Security Extensions" [RFC4034]
+   -  "Protocol Modifications for the DNS Security Extensions" [RFC4035]
+   -  "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509]
+   -  "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]
+   -  "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
+       Records for DNSSEC" [RFC5702]
+   -  "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
+
+   These documents contain information about the syntax and semantics of
+   DNS messages.  They ought not interfere with AXFR but are also
+   helpful in understanding what will be carried via AXFR.
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                 [Page 7]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   For convenience, the synopsis of the DNS message header from
+   [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
+   reproduced here informally:
+
+                 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                      ID                       |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |QR|   OpCode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                QDCOUNT/ZOCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                ANCOUNT/PRCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                NSCOUNT/UPCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                    ARCOUNT                    |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   This document makes use of the field names as they appear in this
+   diagram.  The names of sections in the body of DNS messages are
+   capitalized in this document for clarity, e.g., "Additional section".
+
+   The DNS message size limit from [RFC1035] for DNS over UDP (and its
+   extension via the EDNS0 mechanism specified in [RFC2671]) is not
+   relevant for AXFR, as explained in Section 4.  The upper limit on the
+   permissible size of a DNS message over TCP is only restricted by the
+   TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
+   two-octet message length field, understood to be unsigned, and thus
+   causing a limit of 65535 octets.  This limit is not changed by EDNS0.
+
+   Note that the TC (truncation) bit is never set by an AXFR server nor
+   considered/read by an AXFR client.
+
+2.1.  AXFR query
+
+   An AXFR query is sent by a client whenever there is a reason to ask.
+   This might be because of scheduled or triggered zone maintenance
+   activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
+   respectively) or as a result of a command line request, say for
+   debugging.
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                 [Page 8]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+2.1.1.  Header Values
+
+   These are the DNS message header values for an AXFR query.
+
+      ID          Selected by client; see Note a)
+
+      QR          MUST be 0 (Query)
+
+      OPCODE      MUST be 0 (Standard Query)
+
+      Flags:
+         AA       'n/a' -- see Note b)
+         TC       'n/a' -- see Note b)
+         RD       'n/a' -- see Note b)
+         RA       'n/a' -- see Note b)
+         Z        'mbz' -- see Note c)
+         AD       'n/a' -- see Note b)
+         CD       'n/a' -- see Note b)
+
+      RCODE       MUST be 0 (No error)
+
+      QDCOUNT     Number of entries in Question section;   MUST be 1
+
+      ANCOUNT     Number of entries in Answer section;     MUST be 0
+
+      NSCOUNT     Number of entries in Authority section;  MUST be 0
+
+      ARCOUNT     Number of entries in Additional section -- see Note d)
+
+   Notes:
+
+   a) Set to any value that the client is not already using with the
+      same server.  There is no specific means for selecting the value
+      in this field.  (Recall that AXFR is done only via TCP connections
+      -- see Section 4 "Transport".)
+
+      A server MUST reply using messages that use the same message ID to
+      allow a client to have multiple queries outstanding concurrently
+      over the same TCP connection -- see Note a) in Section 2.2.2 for
+      more details.
+
+   b) 'n/a' -- The value in this field has no meaning in the context of
+      AXFR query messages.  For the client, it is RECOMMENDED that the
+      value be zero.  The server MUST ignore this value.
+
+   c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
+      it.
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                 [Page 9]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   d) The client MUST set this field to the number of resource records
+      appearing in the Additional section.  See Section 2.1.5
+      "Additional Section" for details.
+
+      The value MAY be 0, 1 or 2.  If it is 2, the Additional section
+      MUST contain both an EDNS0 [RFC2671] OPT resource record and a
+      record carrying transaction integrity and authentication data,
+      currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931].  If the
+      value is 1, then the Additional section MUST contain either only
+      an EDNS0 OPT resource record or a record carrying transaction
+      integrity and authentication data.  If the value is 0, the
+      Additional section MUST be empty.
+
+2.1.2.  Question Section
+
+   The Query section of the AXFR query MUST conform to Section 4.1.2 of
+   RFC 1035, and contain a single resource record with the following
+   values:
+
+      QNAME       the name of the zone requested
+
+      QTYPE       AXFR (= 252), the pseudo-RR type for zone transfer
+                  [DNSVALS]
+
+      QCLASS      the class of the zone requested [DNSVALS]
+
+2.1.3.  Answer Section
+
+   The Answer section MUST be empty.
+
+2.1.4.  Authority Section
+
+   The Authority section MUST be empty.
+
+2.1.5.  Additional Section
+
+   The client MAY include an EDNS0 OPT [RFC2671] resource record.  If
+   the server does not support EDNS0, the client MUST send this section
+   without an EDNS0 OPT resource record if there is a retry.  However,
+   the protocol does not define an explicit indication that the server
+   does not support EDNS0; that needs to be inferred by the client.
+   Often, the server will return a FormErr(1) which might be related to
+   the OPT resource record.
+
+   The client MAY include a transaction integrity and authentication
+   resource record, currently a choice of TSIG [RFC2845] or SIG(0)
+   [RFC2931].  If the server has indicated that it does not recognize
+   the resource record, and that the error is indeed caused by the
+   resource record, the client probably should not try again.  Removing
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 10]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   the security data in the face of an obstacle ought to only be done
+   with full awareness of the implication of doing so.
+
+   In general, if an AXFR client is aware that an AXFR server does not
+   support a particular mechanism, the client SHOULD NOT attempt to
+   engage the server using the mechanism (or at all).  A client could
+   become aware of a server's abilities via a configuration setting or
+   via some other (as yet) undefined means.
+
+   The range of permissible resource records that MAY appear in the
+   Additional section might change over time.  If either a change to an
+   existing resource record (like the OPT RR for EDNS0) is made or a new
+   Additional section record is created, the new definitions ought to
+   include a discussion on the impact upon AXFR.  Future resource
+   records residing in the Additional section might have an effect that
+   is orthogonal to AXFR, so can ride through the session as opaque
+   data.  In this case, a "wise" implementation ought to be able to pass
+   these records through without disruption.
+
+2.2.  AXFR Response
+
+   The AXFR response will consist of 0 or more messages.  A "0 message"
+   response is covered in Section 2.2.1.
+
+   An AXFR response that is transferring the zone's contents will
+   consist of a series (which could be a series of length 1) of DNS
+   messages.  In such a series, the first message MUST begin with the
+   SOA resource record of the zone, the last message MUST conclude with
+   the same SOA resource record.  Intermediate messages MUST NOT contain
+   the SOA resource record.  The AXFR server MUST copy the Question
+   section from the corresponding AXFR query message in to the first
+   response message's Question section.  Subsequent messages MAY do the
+   same or contain an empty Question section.
+
+   An AXFR response indicates an error via a single DNS message with the
+   return code set to the appropriate value for the condition
+   encountered, sent once the error condition is detected.  Such a
+   message terminates the AXFR session; it MUST copy the Query Section
+   from the AXFR query into its Query Section, but the inclusion of the
+   terminating SOA resource record is not necessary.
+
+   An AXFR server may send a number of AXFR response messages free of an
+   error condition before it sends the message indicating an error.
+
+2.2.1.  "0 Message" Response
+
+   A legitimate "0 message" response, i.e., the client sees no response
+   whatsoever, is very exceptional and controversial.  Unquestionably it
+   is unhealthy for there to be 0 responses in a protocol that is
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 11]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   designed around a query - response paradigm over an unreliable
+   transport.  The lack of a response could be a sign of underlying
+   network problems and cause the protocol state machine to react
+   accordingly.  However, AXFR uses TCP and not UDP, eliminating
+   undetectable network errors.
+
+   A "0 message response" is reserved for situations in which the server
+   has a reason to suspect that the query is sent for the purpose of
+   abuse.  Due to the use of this being so controversial, a "0 message
+   response" is not being defined as a legitimate part of the protocol
+   but the use of it is being acknowledged as a warning to AXFR client
+   implementations.  Any earnest query has the expectation of some
+   response but nevertheless may not get one.
+
+2.2.2.  Header Values
+
+   These are the DNS message header values for AXFR responses.
+
+      ID          MUST be copied from request -- see Note a)
+
+      QR          MUST be 1 (Response)
+
+      OPCODE      MUST be 0 (Standard Query)
+
+      Flags:
+         AA       normally 1 -- see Note b)
+         TC       MUST be 0 (Not truncated)
+         RD       RECOMMENDED: copy request's value, MAY be set to 0
+         RA       SHOULD be 0 -- see Note c)
+         Z        'mbz' -- see Note d)
+         AD       covered by DNSSEC rules -- see Note e)
+         CD       covered by DNSSEC rules -- see Note e)
+
+      RCODE       See Note f)
+
+      QDCOUNT     MUST be 1 in the first message;
+                  MUST be 0 or 1 in all following messages;
+                  MUST be 1 if RCODE indicates an error
+
+      ANCOUNT     See Note g)
+
+      NSCOUNT     MUST be 0
+
+      ARCOUNT     See Note h)
+
+
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 12]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   Notes:
+
+   a) Because some old implementations behave differently than is now
+      desired, the requirement on this field is stated in detail.  New
+      DNS servers MUST set this field to the value of the AXFR query ID
+      in each AXFR response message for the session.  AXFR clients MUST
+      be able to manage sessions resulting from the issuance of multiple
+      outstanding queries, whether AXFR queries or other DNS queries.
+      A client SHOULD discard responses that do not correspond (via the
+      message ID) to any outstanding queries.
+
+      Unless the client is sure that the server will consistently set
+      the ID field to the query's ID, the client is NOT RECOMMENDED to
+      issue any other queries until the end of the zone transfer.
+      A client MAY become aware of a server's abilities via a
+      configuration setting.
+
+   b) If the RCODE is 0 (no error), then the AA bit MUST be 1.
+      For any other value of RCODE, the AA bit MUST be set according to
+      the rules for that error code.  If in doubt, it is RECOMMENDED
+      that it be set to 1.  It is RECOMMENDED that the value be ignored
+      by the AXFR client.
+
+   c) It is RECOMMENDED that the server set the value to 0, the client
+      MUST ignore this value.
+
+      The server MAY set this value according to the local policy
+      regarding recursive service, but doing so might confuse the
+      interpretation of the response as AXFR can not be retrieved
+      recursively.  A client MAY note the server's policy regarding
+      recursive service from this value, but SHOULD NOT conclude that
+      the AXFR response was obtained recursively even if the RD bit was
+      1 in the query.
+
+   d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
+      it.
+
+   e) If the implementation supports the DNS Security Extensions (DNSSEC
+      -- see Section 2), then this value MUST be set according to the
+      rules in RFC 4035, Section 3.1.6, "The AD and CD Bits in an
+      Authoritative Response".  If the implementation does not support
+      the DNS Security Extensions, then this value MUST be set to 0 and
+      MUST be ignored upon receipt.
+
+   f) In the absence of an error, the server MUST set the value of this
+      field to NoError(0).  If a server is not authoritative for the
+      queried zone, the server SHOULD set the value to NotAuth(9).
+      (Reminder, consult the appropriate IANA registry [DNSVALS].)  If a
+      client receives any other value in response, it MUST act according
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 13]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+      to the error.  For example, a malformed AXFR query or the presence
+      of an EDNS0 OPT resource record sent to an old server will garner
+      a FormErr(1) value.  This value is not set as part of the AXFR-
+      specific response processing.  The same is true for other values
+      indicating an error.
+
+   g) The count of answer records MUST equal the number of resource
+      records in the AXFR Answer Section.  When a server is aware that a
+      client will only accept one resource record per response message,
+      then the value MUST be 1.  A server MAY be made aware of a
+      client's limitations via configuration data.
+
+   h) The client MUST set this field to the number of resource records
+      appearing in the Additional section.  The considerations of Note
+      d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional
+      Section" below for more details.
+
+2.2.3.  Question Section
+
+   In the first response message, this section MUST be copied from the
+   query.  In subsequent messages, this section MAY be copied from the
+   query or it MAY be empty.  However, in an error response message (see
+   Section 2.2), this section MUST be copied as well.  The content of
+   this section MAY be used to determine the context of the message,
+   that is, the name of the zone being transferred.
+
+2.2.4.  Answer Section
+
+   MUST be populated with the zone contents.  See Section 3 below on
+   encoding zone contents.
+
+2.2.5.  Authority Section
+
+   The Authority section MUST be empty.
+
+2.2.6.  Additional Section
+
+   The contents of this section MUST follow the guidelines for EDNS0 and
+   TSIG, SIG(0), or whatever other future record is possible here.  The
+   contents of Section 2.1.5 apply analogously as well.
+
+2.3.  TCP Connection Aborts
+
+   If an AXFR client sends a query on a TCP connection and the
+   connection is closed at any point, the AXFR client MUST consider the
+   AXFR session terminated.  The message ID MAY be used again on a new
+   connection, even if the question and AXFR server are the same.
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 14]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   Facing a dropped connection, a client SHOULD try to make some
+   determination whether the connection closure was the result of
+   network activity or a decision by the AXFR server.  This
+   determination is not an exact science.  It is up to the AXFR client
+   implementor to react, but the reaction SHOULD NOT be an endless cycle
+   of retries nor an increasing (in frequency) retry rate.
+
+   An AXFR server implementor SHOULD take into consideration the dilemma
+   described above when a connection is closed with an outstanding query
+   in the pipeline.  For this reason, a server ought to reserve this
+   course of action for situations in which it believes beyond a doubt
+   that the AXFR client is attempting abusive behavior.
+
+
+3.  Zone Contents
+
+   The objective of the AXFR session is to request and transfer the
+   contents of a zone.  The objective is to permit the AXFR client to
+   reconstruct the zone as it exists at the server for the given zone
+   serial number.  Over time the definition of a zone has evolved from
+   denoting a static set of records to also cover a dynamically updated
+   set of records, and then a potentially continually regenerated set of
+   records (e.g., RRs synthesized "on the fly" from rule sets or
+   database lookup results in other forms than RR format) as well.
+
+3.1.  Records to Include
+
+   In the Answer section of AXFR response messages the resource records
+   within a zone for the given serial number MUST appear.  The
+   definition of what belongs in a zone is described in RFC 1034,
+   Section 4.2, "How the database is divided into zones" (in particular
+   Section 4.2.1, "Technical considerations"), and it has been clarified
+   in Section 6 of RFC 2181.
+
+   Unless the AXFR server knows that the AXFR client is old and expects
+   just one resource record per AXFR response message, an AXFR server
+   SHOULD populate an AXFR response message with as many complete
+   resource record sets as will fit within a DNS message.
+
+   Zones for which it is impractical to list the entire zone for a
+   serial number are not suitable for AXFR retrieval.  A typical (but
+   not limiting) description of such a zone is a zone consisting of
+   responses generated via other database lookups and/or computed based
+   upon ever changing data.
+
+
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 15]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+3.2.  Delegation Records
+
+   In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
+   the "should" in the quotation predates [BCP14], cf. Section 1.1):
+
+      "The RRs that describe cuts ... should be exactly the same as the
+       corresponding RRs in the top node of the subzone."
+
+   There has been some controversy over this statement and the impact on
+   which NS resource records are included in a zone transfer.
+
+   The phrase "that describe cuts" is a reference to the NS set and
+   applicable glue records.  It does not mean that the cut point and
+   apex resource records are identical.  For example, the SOA resource
+   record is only found at the apex.  The discussion here is restricted
+   to just the NS resource record set and glue as these "describe cuts".
+
+   DNSSEC resource records have special specifications regarding their
+   occurrence at a zone cut and the apex of a zone.  This was first
+   described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
+   specification of DNSSEC), which parts of RFC 2181 now in fact are
+   historical.  The current DNSSEC core document set (see Note e) in
+   Section 2.2.2 above) gives the full details for DNSSEC(bis) resource
+   record placement, and Section 3.1.5 of RFC 4035 normatively specifies
+   their treatment during AXFR; the alternate NSEC3 resource record
+   defined later in RFC 5155 behaves identically as the NSEC RR, for the
+   purpose of AXFR.
+
+   Informally:
+
+   o  The DS RRSet only occurs at the parental side of a zone cut and is
+      authoritative data in the parent zone, not the secure child zone.
+
+   o  The DNSKEY RRSet only occurs at the APEX of a signed zone and is
+      part of the authoritative data of the zone it serves.
+
+   o  Independent RRSIG RRSets occur at the signed parent side of a zone
+      cut and at the apex of a signed zone; they are authoritative data
+      in the respective zone; simple queries for RRSIG resource records
+      may return both RRSets at once if the same server is authoritative
+      for the parent zone and the child zone (Section 3.1.5 of RFC 4035
+      describes how to distinguish these RRs); this seeming ambiguity
+      does not occur for AXFR, since each such RRSIG RRset belongs to a
+      single zone.
+
+   o  Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
+      equally may occur at the parental side of a zone cut and at the
+      apex of a zone; each such resource record belongs to exactly one
+      of these zones and is to be included in the AXFR of that zone.
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 16]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   One issue is that in operations there are times when the NS resource
+   records for a zone might be different at a cut point in the parent
+   and at the apex of a zone.  Sometimes this is the result of an error
+   and sometimes it is part of an ongoing change in name servers.  The
+   DNS protocol is robust enough to overcome inconsistencies up to (but
+   not including) there being no parent indicated NS resource record
+   referencing a server that is able to serve the child zone.  This
+   robustness is one quality that has fueled the success of the DNS.
+   Still, the inconsistency is an error state and steps need to be taken
+   to make it apparent (if it is unplanned) and to make it clear once
+   the inconsistency has been removed.
+
+   Another issue is that the AXFR server could be authoritative for a
+   different set of zones than the AXFR client.  It is possible that the
+   AXFR server be authoritative for both halves of an inconsistent cut
+   point and that the AXFR client is authoritative for just the parent
+   side of the cut point.
+
+   When facing a situation in which a cut point's NS resource records do
+   not match the authoritative set, the question arises whether an AXFR
+   server responds with the NS resource record set that is in the zone
+   being transferred or the one that is at the authoritative location.
+
+   The AXFR response MUST contain the cut point NS resource record set
+   registered with the zone whether it agrees with the authoritative set
+   or not.  "Registered with" can be widely interpreted to include data
+   residing in the zone file of the zone for the particular serial
+   number (in zone file environments) or as any data configured to be in
+   the zone (database), statically or dynamically.
+
+   The reasons for this requirement are:
+
+   1) The AXFR server might not be able to determine that there is an
+   inconsistency given local data, hence requiring consistency would
+   mean a lot more needed work and even network retrieval of data.  An
+   authoritative server ought not be required to perform any queries.
+
+   2) By transferring the inconsistent NS resource records from a server
+   that is authoritative for both the cut point and the apex to a client
+   that is not authoritative for both, the error is exposed.  For
+   example, an authorized administrator can manually request the AXFR
+   and inspect the results to see the inconsistent records.  (A server
+   authoritative for both halves would otherwise always answer from the
+   more authoritative set, concealing the error.)
+
+   3) The inconsistent NS resource record set might indicate a problem
+   in a registration database.
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 17]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   4) This requirement is necessary to ensure that retrieving a given
+   (zone,serial) pair by AXFR yields the exact same set of resource
+   records no matter which of the zone's authoritative servers is chosen
+   as the source of the transfer.
+
+   If an AXFR server were allowed to respond with the authoritative NS
+   RRset of a child zone instead of a glue NS RRset in the zone being
+   transferred, the set of records returned could vary depending on
+   whether or not the server happens to be authoritative for the child
+   zone as well.
+
+   The property that a given (zone,serial) pair corresponds to a single,
+   well-defined set of records is necessary for the correct operation of
+   incremental transfer protocols such as IXFR [RFC1995].  For example,
+   a client may retrieve a zone by AXFR from one server, and then apply
+   an incremental change obtained by IXFR from a different server.  If
+   the two servers have different ideas of the zone contents, the client
+   can end up attempting to incrementally add records that already exist
+   or to delete records that do not exist.
+
+3.3.  Glue Records
+
+   As quoted in the previous section, Section 4.2.1 of RFC 1034 provides
+   guidance and rationale for the inclusion of glue records as part of
+   an AXFR transfer.  And, as also argued in the previous section of
+   this document, even when there is an inconsistency between the
+   address in a glue record and the authoritative copy of the name
+   server's address, the glue resource record that is registered as part
+   of the zone for that serial number is to be included.
+
+   This applies to glue records for any address family [IANA-AF].
+
+   The AXFR response MUST contain the appropriate glue records as
+   registered with the zone.  The interpretation of "registered with" in
+   the previous section applies here.  Inconsistent glue records are an
+   operational matter.
+
+3.4.  Name Compression
+
+   Compression of names in DNS messages is described in RFC 1035,
+   Section 4.1.4, "Message compression".  The issue highlighted here
+   relates to a comment made in RFC 1034, Section 3.1, "Name space
+   specifications and terminology" which says "When you receive a domain
+   name or label, you should preserve its case."  ("Should" in the quote
+   predates [BCP14].)
+
+   Name compression in an AXFR message MUST preserve the case of the
+   original domain name.  That is, although when comparing a domain
+   name, "a" equals "A", when comparing for the purposes of message
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 18]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   compression, "a" is not equal to "A".  Note that this is not the
+   usual definition of name comparison in the DNS protocol and
+   represents a new requirement on AXFR servers.
+
+   Rules governing name compression of RDATA in an AXFR message MUST
+   abide by the specification in "Handling of Unknown DNS Resource
+   Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
+   Compression".
+
+3.5.  Occluded Names
+
+   Dynamic Update [RFC2136] operations, and in particular its
+   interaction with DNAME [RFC2672], can have a side effect of occluding
+   names in a zone.  The addition of a delegation point via dynamic
+   update will render all subordinate domain names to be in a limbo,
+   still part of the zone but not available to the lookup process.  The
+   addition of a DNAME resource record has the same impact.  The
+   subordinate names are said to be "occluded".
+
+   Occluded names MUST be included in AXFR responses.  An AXFR client
+   MUST be able to identify and handle occluded names.  The rationale
+   for this action is based on a speedy recovery if the dynamic update
+   operation was in error and is to be undone.
+
+
+4.  Transport
+
+   AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
+   1034 that states:  "Because accuracy is essential, TCP or some other
+   reliable protocol must be used for AXFR requests."  The restriction
+   to TCP is also mentioned in Section 6.1.3.2. of "Requirements for
+   Internet Hosts - Application and Support" [RFC1123].
+
+   The most common scenario is for an AXFR client to open a TCP
+   connection to the AXFR server, send an AXFR query, receive the AXFR
+   response, and then close the connection.  But variations of that
+   most simple scenario are legitimate and likely, in particular sending
+   a query for the zone's SOA resource record first over the same TCP
+   connection, and reusing an existing TCP connection for other queries.
+
+   Therefore, the assumption that a TCP connection is dedicated to a
+   single AXFR session is incorrect.  This wrong assumption has led to
+   implementation choices that prevent either multiple concurrent zone
+   transfers or the use of an open connection for other queries.
+
+   Since the early days of the DNS, operators who have sets of name
+   servers that are authoritative for a common set of zones found it
+   desirable to be able to have multiple concurrent zone transfers in
+   progress; this way a name server does not have to wait for one zone
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 19]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   transfer to complete before the next could begin.  RFC 1035 did not
+   exclude this possibility, but legacy implementations missed to
+   support this functionality.  The remaining presence of such legacy
+   implementations makes it necessary that new general purpose server
+   implementation still provide options for gracefull fallback to the
+   old behavior in their support of concurrent DNS transactions and AXFR
+   sessions on a single TCP connection.
+
+4.1.  TCP
+
+   In the original definition there arguably is an implicit assumption
+   (probably unintentional) that a TCP connection is used for one and
+   only one AXFR session.  This is evidenced in the lack of an explicit
+   requirement to copy the Query section and/or the message ID into
+   responses, no explicit ordering information within the AXFR response
+   messages, and the lack of an explicit notice indicating that a zone
+   transfer continues in the next message.
+
+   The guidance given below is intended to enable better performance of
+   the AXFR exchange as well as provide guidelines on interactions with
+   older software.  Better performance includes being able to multiplex
+   DNS message exchanges including zone transfer sessions.  Guidelines
+   for interacting with older software are generally applicable to new
+   AXFR clients.  In the reverse situation, older AXFR client and newer
+   AXFR server, the server ought to operate within the specification for
+   an older server.
+
+4.1.1.  AXFR client TCP
+
+   An AXFR client MAY request a connection to an AXFR server for any
+   reason.  An AXFR client SHOULD close the connection when there is no
+   apparent need to use the connection for some time period.  The AXFR
+   server ought not have to maintain idle connections, the burden of
+   connection closure ought to be on the client.  "Apparent need" for
+   the connection is a judgment for the AXFR client and the DNS client.
+   If the connection is used for multiple sessions, or if it is known
+   sessions will be coming, or if there is other query/response traffic
+   anticipated or currently on the open connection, then there is
+   "apparent need".
+
+   An AXFR client can cancel the delivery of a zone only by closing the
+   connection.  However, this action will also cancel all other
+   outstanding activity using the connection.  There is no other
+   mechanism by which an AXFR response can be cancelled.
+
+   When a TCP connection is closed remotely (relative to the client),
+   whether by the AXFR server or due to a network event, the AXFR client
+   MUST cancel all outstanding sessions and non-AXFR transactions.
+   Recovery from this situation is not straightforward.  If the
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 20]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   disruption was a spurious event, attempting to restart the connection
+   would be proper.  If the disruption was caused by a failure that
+   proved to be persistent, the AXFR client would be wise to not spend
+   too many resources trying to rebuild the connection.  Finally, if the
+   connection was dropped because of a policy at the AXFR server (as can
+   be the case with older AXFR servers), the AXFR client would be wise
+   to not retry the connection.  Unfortunately, knowing which of the
+   three cases above (momentary disruption, failure, policy) applies is
+   not possible with certainty, and can only be assessed by heuristics.
+
+   An AXFR client MAY use an already opened TCP connection to start an
+   AXFR session.  Using an existing open connection is RECOMMENDED over
+   opening a new connection.  (Non-AXFR session traffic can also use an
+   open connection.)  If in doing so the AXFR client realizes that the
+   responses cannot be properly differentiated (lack of matching query
+   IDs for example) or the connection is terminated for a remote reason,
+   then the AXFR client SHOULD NOT attempt to reuse an open connection
+   with the specific AXFR server until the AXFR server is updated (which
+   is, of course, not an event captured in the DNS protocol).
+
+4.1.2.  AXFR server TCP
+
+   An AXFR server MUST be able to handle multiple AXFR sessions on a
+   single TCP connection, as well as handle other query/response
+   transactions over it.
+
+   If a TCP connection is closed remotely, the AXFR server MUST cancel
+   all AXFR sessions in place.  No retry activity is necessary; that is
+   initiated by the AXFR client.
+
+   Local policy MAY dictate that a TCP connection is to be closed.  Such
+   an action SHOULD be in reaction to limits such as those placed on the
+   number of outstanding open connections.  Closing a connection in
+   response to a suspected security event SHOULD be done only in extreme
+   cases, when the server is certain the action is warranted.  An
+   isolated request for a zone not on the AXFR server SHOULD receive a
+   response with the appropriate return code and not see the connection
+   broken.
+
+4.2.  UDP
+
+   With the addition of EDNS0 and applications which require many small
+   zones such as in web hosting and some ENUM scenarios, AXFR sessions
+   on UDP would now seem desirable.  However, there are still some
+   aspects of AXFR sessions that are not easily translated to UDP.
+
+   Therefore, this document does not update RFC 1035 in this respect:
+   AXFR sessions over UDP transport are not defined.
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 21]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+5.  Authorization
+
+   A zone administrator has the option to restrict AXFR access to a
+   zone.  This was not envisioned in the original design of the DNS but
+   has emerged as a requirement as the DNS has evolved.  Restrictions on
+   AXFR could be for various reasons including a desire (or in some
+   instances, having a legal requirement) to keep the bulk version of
+   the zone concealed or to prevent the servers from handling the load
+   incurred in serving AXFR.  It has been argued that these reasons are
+   questionable, but this document, driven by the desire to leverage the
+   interoperable practice that has evolved since RFC 1035, acknowledges
+   the factual requirement to provide mechanisms to restrict AXFR.
+
+   A DNS implementation SHOULD provide means to restrict AXFR sessions
+   to specific clients.
+
+   An implementation SHOULD allow access to be granted to Internet
+   Protocol addresses and ranges, regardless of whether a source address
+   could be spoofed.  Combining this with techniques such as Virtual
+   Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be
+   effective.
+
+   A general purpose implementation is RECOMMENDED to implement access
+   controls based upon "Secret Key Transaction Authentication for DNS"
+   [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
+   [RFC2931].
+
+   A general purpose implementation SHOULD allow access to be open to
+   all AXFR requests.  I.e., an operator ought to be able to allow any
+   AXFR query to be granted.
+
+   A general purpose implementation SHOULD NOT have a default policy for
+   AXFR requests to be "open to all".  For example, a default could be
+   to restrict transfers to addresses selected by the DNS
+   administrator(s) for zones on the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 22]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+6.  Zone Integrity
+
+   An AXFR client MUST ensure that only a successfully transferred copy
+   of the zone data can be used to serve this zone.  Previous
+   description and implementation practice have introduced a two-stage
+   model of the whole zone synchronization procedure:  Upon a trigger
+   event (e.g., polling of a SOA resource record detects change in the
+   SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is
+   initiated, whereby the zone data are saved in a zone file or data
+   base (this latter step is necessary anyway to ensure proper restart
+   of the server); upon successful completion of the AXFR operation and
+   some sanity checks, this data set is 'loaded' and made available for
+   serving the zone in an atomic operation, and flagged 'valid' for use
+   during the next restart of the DNS server; if any error is detected,
+   this data set MUST be deleted, and the AXFR client MUST continue to
+   serve the previous version of the zone, if it did before.  The
+   externally visible behavior of an AXFR client implementation MUST be
+   equivalent to that of this two-stage model.
+
+   If an AXFR client rejects data contained in an AXFR session, it
+   SHOULD remember the serial number and MAY attempt to retrieve the
+   same zone version again.  The reason the same retrieval could make
+   sense is that the reason for the rejection could be rooted in an
+   implementation detail of one AXFR server used for the zone and not
+   present in another AXFR server used for the zone.
+
+   Ensuring that an AXFR client does not accept a forged copy of a zone
+   is important to the security of a zone.  If a zone operator has the
+   opportunity, protection can be afforded via dedicated links, physical
+   or virtual via a VPN among the authoritative servers.  But there are
+   instances in which zone operators have no choice but to run AXFR
+   sessions over the global public Internet.
+
+   Besides best attempts at securing TCP connections, DNS
+   implementations SHOULD provide means to make use of "Secret Key
+   Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and
+   Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients
+   to verify the contents.  These techniques MAY also be used for
+   authorization.
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 23]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+7.  Backwards Compatibility
+
+   Describing backwards compatibility is difficult because of the lack
+   of specifics in the original definition.  In this section some hints
+   at building in backwards compatibility are given, mostly repeated
+   from the relevant earlier sections.
+
+   Backwards compatibility is not necessary, but the greater the extent
+   of an implementation's compatibility the greater its
+   interoperability.  For turnkey implementations this is not usually a
+   concern.  For general purpose implementations this takes on varying
+   levels of importance depending on the implementer's desire to
+   maintain interoperability.
+
+   It is unfortunate that a need to fall back to older behavior cannot
+   be discovered, hence needs to be noted in a configuration file.  An
+   implementation SHOULD, in its documentation, encourage operators to
+   periodically review AXFR clients and servers it has made notes about
+   repeatedly, as old software gets updated from time to time.
+
+7.1.  Server
+
+   An AXFR server has the luxury of being able to react to an AXFR
+   client's abilities with the exception of knowing whether the client
+   can accept multiple resource records per AXFR response message.  The
+   knowledge that a client is so restricted cannot be discovered, hence
+   it has to be set by configuration.
+
+   An implementation of an AXFR server MAY permit configuring, on a per
+   AXFR client basis, the necessity to revert to single resource record
+   per message; in that case, the default SHOULD be to use multiple
+   records per message.
+
+7.2.  Client
+
+   An AXFR client has the opportunity to try other features (i.e., those
+   not defined by this document) when querying an AXFR server.
+
+   Attempting to issue multiple DNS queries over a TCP transport for an
+   AXFR session SHOULD be aborted if it interrupts the original request,
+   and SHOULD take into consideration whether the AXFR server intends to
+   close the connection immediately upon completion of the original
+   (connection-causing) zone transfer.
+
+
+
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 24]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+8.  Security Considerations
+
+   Concerns regarding authorization, traffic flooding, and message
+   integrity are mentioned in "Authorization" (Section 5), "TCP"
+   (Section 4.2) and "Zone Integrity" (Section 6).
+
+
+9.  IANA Considerations
+
+   [[ Note to RFC-Ed: this section may be deleted before publication. ]]
+
+   No new registries or new registrations are included in this document.
+
+
+10.  Internationalization Considerations
+
+   The AXFR protocol is transparent to the parts of DNS zone content
+   that can possibly be subject to Internationalization considerations.
+   It is assumed that for DNS labels and domain names, the issue has
+   been solved via "Internationalizing Domain Names in Applications
+   (IDNA)" [RFC3490] or its successor(s).
+
+
+11.  Acknowledgments
+
+   Earlier editions of this document have been edited by Andreas
+   Gustafsson.  In his latest version, this acknowledgment appeared:
+
+    "Many people have contributed input and commentary to earlier
+     versions of this document, including but not limited to Bob Halley,
+     Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert
+     Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
+     Trenholme, and Brian Wellington."
+
+   Comments since the -05 version have come from these individuals:
+   Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
+   Ian Jackson, Andreas Gustafsson, Brian Wellington, and other
+   participants of the DNSEXT working group.
+
+   Edward Lewis served as a patiently listening sole document editor for
+   two years.
+
+12.  References
+
+   All "RFC" references by can be obtained from the RFC Editor web site
+   at the URLs:       http://rfc-editor.org/rfc.html
+   or                 http://rfc-editor.org/rfcsearch.html ;
+   information regarding this organization can be found at the following
+   URL:               http://rfc-editor.org/
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 25]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+12.1.  Normative References
+
+   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              August 1980.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              August 1996.
+
+   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
+              Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
+              RFC 2672, August 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s )", RFC 2931, September 2000.
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 26]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   [RFC3425]  Lawrence, D., "Obsoleting IQUERY", RFC 3425,
+              November 2002.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [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.
+
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006
+
+   [RFC4635]  Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
+              Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
+              RFC 4635, August 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008
+
+   [RFC5395]  Eastlake 3rd, "Domain Name System (DNS) IANA
+              Considerations", BCP 42, RFC 5395, November 2008.
+
+   [RFC5702]  Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
+              and RRSIG Resource Records for DNSSEC", RFC 5702,
+              October 2009.
+
+12.2.  Informative References
+
+   [DNSVALS]  IANA Registry "Domain Name System (DNS) Parameters",
+              http://www.iana.org/assignments/dns-parameters
+
+   [IANA-AF]  IANA Registry "Address Family Numbers",
+              http://www.iana.org/assignments/Address-family-numbers/ .
+
+   [RFC2764]  Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
+              Malis, "A Framework for IP Based Virtual Private
+              Networks", RFC 2764, February 2000.
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 27]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
+
+
+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
+              "Internationalizing Domain Names in Applications (IDNA)",
+              RFC 3490, March 2003.
+
+   [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
+              Implementation Notes for DNSSECbis",
+              draft-ietf-dnsext-dnssec-bis-updates-09 (work in
+              progress), September 2009.
+
+
+13.  Editors' Addresses
+
+   Edward Lewis
+   46000 Center Oak Plaza
+   Sterling, VA, 22033, US
+
+   Email: ed.lewis@neustar.biz
+
+
+   Alfred Hoenes
+   TR-Sys
+   Gerlinger Str. 12
+   Ditzingen  D-71254
+   Germany
+
+   Email: ah@TR-Sys.de
+
+
+Editorial Note: Discussion  [[ to be removed by RFC-Editor ]]
+
+   Comments on this draft ought to be addressed to the editors and/or to
+   namedroppers@ops.ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes             Expires June 6, 2010                [Page 28]
+
diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
deleted file mode 100644
index 07749d954947..000000000000
--- a/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
+++ /dev/null
@@ -1,674 +0,0 @@
-
-
-
-
-DNSEXT                                                          M. Stapp
-Internet-Draft                                       Cisco Systems, Inc.
-Expires: September 1, 2006                                      T. Lemon
-                                                           Nominum, Inc.
-                                                           A. Gustafsson
-                                          Araneus Information Systems Oy
-                                                       February 28, 2006
-
-
-           A DNS RR for Encoding DHCP Information (DHCID RR)
-                  
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 1, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   It is possible for DHCP clients to attempt to update the same DNS
-   FQDN or attempt to update a DNS FQDN that has been added to the DNS
-   for another purpose as they obtain DHCP leases.  Whether the DHCP
-   server or the clients themselves perform the DNS updates, conflicts
-   can arise.  To resolve such conflicts, "Resolution of DNS Name
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 1]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   Conflicts" [1] proposes storing client identifiers in the DNS to
-   unambiguously associate domain names with the DHCP clients to which
-   they refer.  This memo defines a distinct RR type for this purpose
-   for use by DHCP clients and servers, the "DHCID" RR.
-
-
-Table of Contents
-
-   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1.  DHCID RDATA format . . . . . . . . . . . . . . . . . . . .  3
-     3.2.  DHCID Presentation Format  . . . . . . . . . . . . . . . .  4
-     3.3.  The DHCID RR Identifier Type Codes . . . . . . . . . . . .  4
-     3.4.  The DHCID RR Digest Type Code  . . . . . . . . . . . . . .  4
-     3.5.  Computation of the RDATA . . . . . . . . . . . . . . . . .  5
-       3.5.1.  Using the Client's DUID  . . . . . . . . . . . . . . .  5
-       3.5.2.  Using the Client Identifier Option . . . . . . . . . .  5
-       3.5.3.  Using the Client's htype and chaddr  . . . . . . . . .  6
-     3.6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       3.6.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . .  6
-       3.6.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . .  6
-       3.6.3.  Example 3  . . . . . . . . . . . . . . . . . . . . . .  7
-   4.  Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . . .  7
-   5.  Updater Behavior . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 2]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-1.  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [2].
-
-
-2.  Introduction
-
-   A set of procedures to allow DHCP [6] [10] clients and servers to
-   automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
-   in "Resolution of DNS Name Conflicts" [1].
-
-   Conflicts can arise if multiple DHCP clients wish to use the same DNS
-   name or a DHCP client attempts to use a name added for another
-   purpose.  To resolve such conflicts, "Resolution of DNS Name
-   Conflicts" [1] proposes storing client identifiers in the DNS to
-   unambiguously associate domain names with the DHCP clients using
-   them.  In the interest of clarity, it is preferable for this DHCP
-   information to use a distinct RR type.  This memo defines a distinct
-   RR for this purpose for use by DHCP clients or servers, the "DHCID"
-   RR.
-
-   In order to obscure potentially sensitive client identifying
-   information, the data stored is the result of a one-way SHA-256 hash
-   computation.  The hash includes information from the DHCP client's
-   message as well as the domain name itself, so that the data stored in
-   the DHCID RR will be dependent on both the client identification used
-   in the DHCP protocol interaction and the domain name.  This means
-   that the DHCID RDATA will vary if a single client is associated over
-   time with more than one name.  This makes it difficult to 'track' a
-   client as it is associated with various domain names.
-
-
-3.  The DHCID RR
-
-   The DHCID RR is defined with mnemonic DHCID and type code [TBD].  The
-   DHCID RR is only defined in the IN class.  DHCID RRs cause no
-   additional section processing.  The DHCID RR is not a singleton type.
-
-3.1.  DHCID RDATA format
-
-   The RDATA section of a DHCID RR in transmission contains RDLENGTH
-   octets of binary data.  The format of this data and its
-   interpretation by DHCP servers and clients are described below.
-
-   DNS software should consider the RDATA section to be opaque.  DHCP
-   clients or servers use the DHCID RR to associate a DHCP client's
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 3]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   identity with a DNS name, so that multiple DHCP clients and servers
-   may deterministically perform dynamic DNS updates to the same zone.
-   From the updater's perspective, the DHCID resource record RDATA
-   consists of a 2-octet identifier type, in network byte order,
-   followed by a 1-octet digest type, followed by one or more octets
-   representing the actual identifier:
-
-           < 2 octets >    Identifier type code
-           < 1 octet >     Digest type code
-           < n octets >    Digest (length depends on digest type)
-
-3.2.  DHCID Presentation Format
-
-   In DNS master files, the RDATA is represented as a single block in
-   base 64 encoding identical to that used for representing binary data
-   in RFC 3548 [7].  The data may be divided up into any number of white
-   space separated substrings, down to single base 64 digits, which are
-   concatenated to form the complete RDATA.  These substrings can span
-   lines using the standard parentheses.
-
-3.3.  The DHCID RR Identifier Type Codes
-
-   The DHCID RR Identifier Type Code specifies what data from the DHCP
-   client's request was used as input into the hash function.  The
-   identifier type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the identifier type code is:
-
-   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
-   0x0001 = The data octets (i.e., the Type and Client-Identifier
-      fields) from a DHCPv4 client's Client Identifier option [9].
-   0x0002 = The client's DUID (i.e., the data octets of a DHCPv6
-      client's Client Identifier option [10] or the DUID field from a
-      DHCPv4 client's Client Identifier option [12]).
-
-   0x0003 - 0xfffe = Available to be assigned by IANA.
-
-   0xffff = RESERVED
-
-3.4.  The DHCID RR Digest Type Code
-
-   The DHCID RR Digest Type Code is an identifier for the digest
-   algorithm used.  The digest is calculated over an identifier and the
-   canonical FQDN as described in the next section.
-
-   The digest type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the digest type codes is: value 0 is reserved and value 1 is SHA-256.
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 4]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   Reserving other types requires IETF standards action.  Defining new
-   values will also require IETF standards action to document how DNS
-   updaters are to deal with multiple digest types.
-
-3.5.  Computation of the RDATA
-
-   The DHCID RDATA is formed by concatenating the 2-octet identifier
-   type code with variable-length data.
-
-   The RDATA for all type codes other than 0xffff, which is reserved for
-   future expansion, is formed by concatenating the 2-octet identifier
-   type code, the 1-octet digest type code, and the digest value (32
-   octets for SHA-256).
-
-       < identifier-type > < digest-type > < digest >
-
-   The input to the digest hash function is defined to be:
-
-       digest = SHA-256(< identifier > < FQDN >)
-
-   The FQDN is represented in the buffer in unambiguous canonical form
-   as described in RFC 4034 [8], section 6.1.  The identifier type code
-   and the identifier are related as specified in Section 3.3: the
-   identifier type code describes the source of the identifier.
-
-   A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
-   option is present in the DHCPv4 messages and it is encoded as
-   specified in [12].  Otherwise, the updater uses 0x0001 if a Client
-   Identifier option is present and 0x0000 if not.
-
-   A DHCPv6 updater always uses the 0x0002 type code.
-
-3.5.1.  Using the Client's DUID
-
-   When the updater is using the Client's DUID (either from a DHCPv6
-   Client Identifier option or from a portion of the DHCPv4 Client
-   Identifier option encoded as specified in [12]), the first two octets
-   of the DHCID RR MUST be 0x0002, in network byte order.  The third
-   octet is the digest type code (1 for SHA-256).  The rest of the DHCID
-   RR MUST contain the results of computing the SHA-256 hash across the
-   octets of the DUID followed by the FQDN.
-
-3.5.2.  Using the Client Identifier Option
-
-   When the updater is using the DHCPv4 Client Identifier option sent by
-   the client in its DHCPREQUEST message, the first two octets of the
-   DHCID RR MUST be 0x0001, in network byte order.  The third octet is
-   the digest type code (1 for SHA-256).  The rest of the DHCID RR MUST
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 5]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   contain the results of computing the SHA-256 hash across the data
-   octets (i.e., the Type and Client-Identifier fields) of the option,
-   followed by the FQDN.
-
-3.5.3.  Using the Client's htype and chaddr
-
-   When the updater is using the client's link-layer address as the
-   identifier, the first two octets of the DHCID RDATA MUST be zero.
-   The third octet is the digest type code (1 for SHA-256).  To generate
-   the rest of the resource record, the updater computes a one-way hash
-   using the SHA-256 algorithm across a buffer containing the client's
-   network hardware type, link-layer address, and the FQDN data.
-   Specifically, the first octet of the buffer contains the network
-   hardware type as it appeared in the DHCP 'htype' field of the
-   client's DHCPREQUEST message.  All of the significant octets of the
-   'chaddr' field in the client's DHCPREQUEST message follow, in the
-   same order in which the octets appear in the DHCPREQUEST message.
-   The number of significant octets in the 'chaddr' field is specified
-   in the 'hlen' field of the DHCPREQUEST message.  The FQDN data, as
-   specified above, follows.
-
-3.6.  Examples
-
-3.6.1.  Example 1
-
-   A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
-   Ethernet MAC address 01:02:03:04:05:06 using domain name
-   "client.example.com" uses the client's link-layer address to identify
-   the client.  The DHCID RDATA is composed by setting the two type
-   octets to zero, the 1-octet digest type to 1 for SHA-256, and
-   performing an SHA-256 hash computation across a buffer containing the
-   Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
-   domain name (represented as specified in Section 3.5).
-
-     client.example.com.   A       10.0.0.1
-     client.example.com.   DHCID   ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
-                                     ytcKD//7es/deY= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
-             fffedeb3f75e6 )
-
-3.6.2.  Example 2
-
-   A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
-   included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 6]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   in its DHCP request.  The server updates the name "chi.example.com"
-   on the client's behalf, and uses the DHCP client identifier option
-   data as input in forming a DHCID RR.  The DHCID RDATA is formed by
-   setting the two type octets to the value 0x0001, the 1-octet digest
-   type to 1 for SHA-256, and performing a SHA-256 hash computation
-   across a buffer containing the seven octets from the client-id option
-   and the FQDN (represented as specified in Section 3.5).
-
-     chi.example.com.      A       10.0.12.99
-     chi.example.com.      DHCID   ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
-                                     L3b/NaiUDlW2No= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
-             6a2503956d8da )
-
-3.6.3.  Example 3
-
-   A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
-   which included the DHCPv6 client-identifier option data 00:01:00:06:
-   41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request.  The server
-   updates the name "chi6.example.com" on the client's behalf, and uses
-   the DHCP client identifier option data as input in forming a DHCID
-   RR.  The DHCID RDATA is formed by setting the two type octets to the
-   value 0x0002, the 1-octet digest type to 1 for SHA-256, and
-   performing a SHA-256 hash computation across a buffer containing the
-   14 octets from the client-id option and the FQDN (represented as
-   specified in Section 3.5).
-
-     chi6.example.com.     AAAA    2000::1234:5678
-     chi6.example.com.     DHCID   ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
-                                     OjxfNuVAA2kjEA= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
-             b95000da48c40 )
-
-
-4.  Use of the DHCID RR
-
-   This RR MUST NOT be used for any purpose other than that detailed in
-   "Resolution of DNS Name Conflicts" [1].  Although this RR contains
-   data that is opaque to DNS servers, the data must be consistent
-   across all entities that update and interpret this record.
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 7]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   Therefore, new data formats may only be defined through actions of
-   the DHC Working Group, as a result of revising [1].
-
-
-5.  Updater Behavior
-
-   The data in the DHCID RR allows updaters to determine whether more
-   than one DHCP client desires to use a particular FQDN.  This allows
-   site administrators to establish policy about DNS updates.  The DHCID
-   RR does not establish any policy itself.
-
-   Updaters use data from a DHCP client's request and the domain name
-   that the client desires to use to compute a client identity hash, and
-   then compare that hash to the data in any DHCID RRs on the name that
-   they wish to associate with the client's IP address.  If an updater
-   discovers DHCID RRs whose RDATA does not match the client identity
-   that they have computed, the updater SHOULD conclude that a different
-   client is currently associated with the name in question.  The
-   updater SHOULD then proceed according to the site's administrative
-   policy.  That policy might dictate that a different name be selected,
-   or it might permit the updater to continue.
-
-
-6.  Security Considerations
-
-   The DHCID record as such does not introduce any new security problems
-   into the DNS.  In order to obscure the client's identity information,
-   a one-way hash is used.  And, in order to make it difficult to
-   'track' a client by examining the names associated with a particular
-   hash value, the FQDN is included in the hash computation.  Thus, the
-   RDATA is dependent on both the DHCP client identification data and on
-   each FQDN associated with the client.
-
-   However, it should be noted that an attacker that has some knowledge,
-   such as of MAC addresses commonly used in DHCP client identification
-   data, may be able to discover the client's DHCP identify by using a
-   brute-force attack.  Even without any additional knowledge, the
-   number of unknown bits used in computing the hash is typically only
-   48 to 80.
-
-   Administrators should be wary of permitting unsecured DNS updates to
-   zones, whether or not they are exposed to the global Internet.  Both
-   DHCP clients and servers SHOULD use some form of update
-   authentication (e.g., TSIG [11]) when performing DNS updates.
-
-
-7.  IANA Considerations
-
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 8]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   IANA is requested to allocate a DNS RR type number for the DHCID
-   record type.
-
-   This specification defines a new number-space for the 2-octet
-   identifier type codes associated with the DHCID RR.  IANA is
-   requested to establish a registry of the values for this number-
-   space.  Three initial values are assigned in Section 3.3, and the
-   value 0xFFFF is reserved for future use.  New DHCID RR identifier
-   type codes are assigned through Standards Action, as defined in RFC
-   2434 [5].
-
-   This specification defines a new number-space for the 1-octet digest
-   type codes associated with the DHCID RR.  IANA is requested to
-   establish a registry of the values for this number-space.  Two
-   initial values are assigned in Section 3.4.  New DHCID RR digest type
-   codes are assigned through Standards Action, as defined in RFC 2434
-   [5].
-
-
-8.  Acknowledgements
-
-   Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
-   Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
-   Volz for their review and suggestions.
-
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
-        DHCP Clients (draft-ietf-dhc-dns-resolution-*)", February 2006.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [3]  Mockapetris, P., "Domain names - concepts and facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [4]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 9]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-9.2.  Informative References
-
-   [6]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-         March 1997.
-
-   [7]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [8]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [9]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
-         Extensions", RFC 2132, March 1997.
-
-   [10]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
-         Carney, "Dynamic Host Configuration Protocol for IPv6
-         (DHCPv6)", RFC 3315, July 2003.
-
-   [11]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)",
-         RFC 2845, May 2000.
-
-   [12]  Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
-         for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
-         RFC 4361, February 2006.
-
-   [13]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006              [Page 10]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-Authors' Addresses
-
-   Mark Stapp
-   Cisco Systems, Inc.
-   1414 Massachusetts Ave.
-   Boxborough, MA  01719
-   USA
-
-   Phone: 978.936.1535
-   Email: mjs@cisco.com
-
-
-   Ted Lemon
-   Nominum, Inc.
-   950 Charter St.
-   Redwood City, CA  94063
-   USA
-
-   Email: mellon@nominum.com
-
-
-   Andreas Gustafsson
-   Araneus Information Systems Oy
-   Ulappakatu 1
-   02320 Espoo
-   Finland
-
-   Email: gson@araneus.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006              [Page 11]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Stapp, et al.           Expires September 1, 2006              [Page 12]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
deleted file mode 100644
index 438e8008a4c7..000000000000
--- a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
+++ /dev/null
@@ -1,1397 +0,0 @@
-DNS Extensions Working Group                                   G. Sisson
-Internet-Draft                                                 B. Laurie
-Expires: January 11, 2006                                        Nominet
-                                                           July 10, 2005
-
-
-            Derivation of DNS Name Predecessor and Successor
-                   draft-ietf-dnsext-dns-name-p-s-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 11, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes two methods for deriving the canonically-
-   ordered predecessor and successor of a DNS name.  These methods may
-   be used for dynamic NSEC resource record synthesis, enabling
-   security-aware name servers to provide authenticated denial of
-   existence without disclosing other owner names in a DNSSEC-secured
-   zone.
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 1]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
-   3.  Absolute Method  . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  4
-     3.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  4
-   4.  Modified Method  . . . . . . . . . . . . . . . . . . . . . . .  5
-     4.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  6
-     4.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  6
-   5.  Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     5.1.  Case Considerations  . . . . . . . . . . . . . . . . . . .  7
-     5.2.  Choice of Range  . . . . . . . . . . . . . . . . . . . . .  7
-     5.3.  Wild Card Considerations . . . . . . . . . . . . . . . . .  8
-     5.4.  Possible Modifications . . . . . . . . . . . . . . . . . .  8
-       5.4.1.  Restriction of Effective Maximum DNS Name Length . . .  8
-       5.4.2.  Use of Modified Method With Zones Containing
-               SRV RRs  . . . . . . . . . . . . . . . . . . . . . . .  9
-   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     6.1.  Examples of Immediate Predecessors Using Absolute
-           Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     6.2.  Examples of Immediate Successors Using Absolute Method . . 13
-     6.3.  Examples of Predecessors Using Modified Method . . . . . . 19
-     6.4.  Examples of Successors Using Modified Method . . . . . . . 20
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
-   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 22
-     A.1.  Changes from sisson-02 to ietf-00  . . . . . . . . . . . . 22
-     A.2.  Changes from sisson-01 to sisson-02  . . . . . . . . . . . 23
-     A.3.  Changes from sisson-00 to sisson-01  . . . . . . . . . . . 23
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
-   Intellectual Property and Copyright Statements . . . . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 2]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-1.  Introduction
-
-   One of the proposals for avoiding the exposure of zone information
-   during the deployment DNSSEC is dynamic NSEC resource record (RR)
-   synthesis.  This technique is described in [I-D.ietf-dnsext-dnssec-
-   trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the
-   generation of NSEC RRs that just span the query name for non-existent
-   owner names.  In order to do this, the DNS names which would occur
-   just prior to and just following a given query name must be
-   calculated in real time, as maintaining a list of all possible owner
-   names that might occur in a zone would be impracticable.
-
-   Section 6.1 of [RFC4034] defines canonical DNS name order.  This
-   document does not amend or modify this definition.  However, the
-   derivation of immediate predecessor and successor, while trivial, is
-   non-obvious.  Accordingly, several methods are described here as an
-   aid to implementors and a reference to other interested parties.
-
-   This document describes two methods:
-
-   1.  An ``absolute method'', which returns the immediate predecessor
-       or successor of a domain name such that no valid DNS name could
-       exist between that DNS name and the predecessor or successor.
-
-   2.  A ``modified method'', which returns a predecessor and successor
-       which are more economical in size and computation.  This method
-       is restricted to use with zones consisting only of single-label
-       owner names where a maximum-length owner name would not result in
-       a DNS name exceeding the maximum DNS name length.  This is,
-       however, the type of zone for which the technique of online-
-       signing is most likely to be used.
-
-
-2.  Notational Conventions
-
-   The following notational conventions are used in this document for
-   economy of expression:
-
-   N: An unspecified DNS name.
-
-   P(N): Immediate predecessor to N (absolute method).
-
-   S(N): Immediate successor to N (absolute method).
-
-   P'(N): Predecessor to N (modified method).
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 3]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   S'(N): Successor to N (modified method).
-
-
-3.  Absolute Method
-
-   These derivations assume that all uppercase US-ASCII letters in N
-   have already been replaced by their corresponding lowercase
-   equivalents.  Unless otherwise specified, processing stops after the
-   first step in which a condition is met.
-
-3.1.  Derivation of DNS Name Predecessor
-
-   To derive P(N):
-
-   1.  If N is the same as the owner name of the zone apex, prepend N
-       repeatedly with labels of the maximum length possible consisting
-       of octets of the maximum sort value (e.g. 0xff) until N is the
-       maximum length possible; otherwise continue to the next step.
-
-   2.  If the least significant (left-most) label of N consists of a
-       single octet of the minimum sort value (e.g. 0x00), remove that
-       label; otherwise continue to the next step.
-
-   3.  If the least significant (right-most) octet in the least
-       significant (left-most) label of N is the minimum sort value,
-       remove the least significant octet and continue with step 5.
-
-   4.  Decrement the value of the least significant (right-most) octet,
-       skipping any values that correspond to uppercase US-ASCII
-       letters, and then append the label with as many octets as
-       possible of the maximum sort value.  Continue to the next step.
-
-   5.  Prepend N repeatedly with labels of as long a length as possible
-       consisting of octets of the maximum sort value until N is the
-       maximum length possible.
-
-3.2.  Derivation of DNS Name Successor
-
-   To derive S(N):
-
-   1.  If N is two or more octets shorter than the maximum DNS name
-       length, prepend N with a label containing a single octet of the
-       minimum sort value (e.g. 0x00); otherwise continue to the next
-       step.
-
-   2.  If N is one or more octets shorter than the maximum DNS name
-       length and the least significant (left-most) label is one or more
-       octets shorter than the maximum label length, append an octet of
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 4]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-       the minimum sort value to the least significant label; otherwise
-       continue to the next step.
-
-   3.  Increment the value of the least significant (right-most) octet
-       in the least significant (left-most) label that is less than the
-       maximum sort value (e.g. 0xff), skipping any values that
-       correspond to uppercase US-ASCII letters, and then remove any
-       octets to the right of that one.  If all octets in the label are
-       the maximum sort value, then continue to the next step.
-
-   4.  Remove the least significant (left-most) label.  If N is now the
-       same as the owner name of the zone apex, do nothing.  (This will
-       occur only if N is the maximum possible name in canonical DNS
-       name order, and thus has wrapped to the owner name of zone apex.)
-       Otherwise repeat starting at step 2.
-
-
-4.  Modified Method
-
-   This method is for use with zones consisting only of single-label
-   owner names where an owner name consisting of label of maximum length
-   would not result in a DNS name which exceeded the maximum DNS name
-   length.  This method is computationally simpler and returns values
-   which are more economical in size than the absolute method.  It
-   differs from the absolute method detailed above in the following
-   ways:
-
-   1.  Step 1 of the derivation P(N) has been omitted as the existence
-       of the owner name of the zone apex never requires denial.
-
-   2.  A new step 1 has been introduced which removes unnecessary
-       labels.
-
-   3.  Step 4 of the derivation P(N) has been omitted as it is only
-       necessary for zones containing owner names consisting of more
-       than one label.  This omission generally results in a significant
-       reduction of the length of derived predecessors.
-
-   4.  Step 1 of the derivation S(N) had been omitted as it is only
-       necessary for zones containing owner names consisting of more
-       than one label.  This omission results in a tiny reduction of the
-       length of derived successors, and maintains consistency with the
-       modification of step 4 of the derivation P(N) described above.
-
-   5.  Steps 2 and 4 of the derivation S(N) have been modified to
-       eliminate checks for maximum DNS name length, as it is an
-       assumption of this method that no DNS name in the zone can exceed
-       the maximum DNS name length.
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 5]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   These derivations assume that all uppercase US-ASCII letters in N
-   have already been replaced by their corresponding lowercase
-   equivalents.  Unless otherwise specified, processing stops after the
-   first step in which a condition is met.
-
-4.1.  Derivation of DNS Name Predecessor
-
-   To derive P'(N):
-
-   1.  If N has more labels than the number of labels in the owner name
-       of the apex + 1, repeatedly remove the least significant (left-
-       most) label until N has no more labels than the number of labels
-       in the owner name of the apex + 1; otherwise continue to next
-       step.
-
-   2.  If the least significant (left-most) label of N consists of a
-       single octet of the minimum sort value (e.g. 0x00), remove that
-       label; otherwise continue to the next step.
-
-   3.  If the least significant (right-most) octet in the least
-       significant (left-most) label of N is the minimum sort value,
-       remove the least significant octet.
-
-   4.  Decrement the value of the least significant (right-most) octet,
-       skipping any values which correspond to uppercase US-ASCII
-       letters, and then append the label with as many octets as
-       possible of the maximum sort value.
-
-4.2.  Derivation of DNS Name Successor
-
-   To derive S'(N):
-
-   1.  If N has more labels than the number of labels in the owner name
-       of the apex + 1, repeatedly remove the least significant (left-
-       most) label until N has no more labels than the number of labels
-       in the owner name of the apex + 1.  Continue to next step.
-
-   2.  If the least significant (left-most) label of N is one or more
-       octets shorter than the maximum label length, append an octet of
-       the minimum sort value to the least significant label; otherwise
-       continue to the next step.
-
-   3.  Increment the value of the least significant (right-most) octet
-       in the least significant (left-most) label that is less than the
-       maximum sort value (e.g. 0xff), skipping any values which
-       correspond to uppercase US-ASCII letters, and then remove any
-       octets to the right of that one.  If all octets in the label are
-       the maximum sort value, then continue to the next step.
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 6]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   4.  Remove the least significant (left-most) label.  (This will occur
-       only if the least significant label is the maximum label length
-       and consists entirely of octets of the maximum sort value, and
-       thus has wrapped to the owner name of the zone apex.)
-
-
-5.  Notes
-
-5.1.  Case Considerations
-
-   Section 3.5 of [RFC1034] specifies that "while upper and lower case
-   letters are allowed in [DNS] names, no significance is attached to
-   the case".  Additionally, Section 6.1 of [RFC4034] states that when
-   determining canonical DNS name order, "uppercase US-ASCII letters are
-   treated as if they were lowercase US-ASCII letters".  Consequently,
-   values corresponding to US-ASCII uppercase letters must be skipped
-   when decrementing and incrementing octets in the derivations
-   described in Section 3.1 and Section 3.2.
-
-   The following pseudo-code is illustrative:
-
-   Decrement the value of an octet:
-
-      if (octet == '[')       // '[' is just after uppercase 'Z'
-              octet = '@';    // '@' is just prior to uppercase 'A'
-      else
-              octet--;
-
-   Increment the value of an octet:
-
-      if (octet == '@')       // '@' is just prior to uppercase 'A'
-              octet = '[';    // '[' is just after uppercase 'Z'
-      else
-              octet++;
-
-5.2.  Choice of Range
-
-   [RFC2181] makes the clarification that "any binary string whatever
-   can be used as the label of any resource record".  Consequently the
-   minimum sort value may be set as 0x00 and the maximum sort value as
-   0xff, and the range of possible values will be any DNS name which
-   contains octets of any value other than those corresponding to
-   uppercase US-ASCII letters.
-
-   However, if all owner names in a zone are in the letter-digit-hyphen,
-   or LDH, format specified in [RFC1034], it may be desirable to
-   restrict the range of possible values to DNS names containing only
-   LDH values.  This has the effect of:
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 7]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   1.  making the output of tools such as `dig' and `nslookup' less
-       subject to confusion;
-
-   2.  minimising the impact that NSEC RRs containing DNS names with
-       non-LDH values (or non-printable values) might have on faulty DNS
-       resolver implementations; and
-
-   3.  preventing the possibility of results which are wildcard DNS
-       names (see Section 5.3).
-
-   This may be accomplished by using a minimum sort value of 0x1f (US-
-   ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
-   character lowercase `z'), and then skipping non-LDH, non-lowercase
-   values when incrementing or decrementing octets.
-
-5.3.  Wild Card Considerations
-
-   Neither derivation avoids the possibility that the result may be a
-   DNS name containing a wildcard label, i.e. a label containing a
-   single octet with the value 0x2a (US-ASCII character `*').  With
-   additional tests, wildcard DNS names may be explicitly avoided;
-   alternatively, if the range of octet values can be restricted to
-   those corresponding to letter-digit-hyphen, or LDH, characters (see
-   Section 5.2), such DNS names will not occur.
-
-   Note that it is improbable that a result which is a wildcard DNS name
-   will occur unintentionally; even if one does occur either as the
-   owner name of, or in the RDATA of an NSEC RR, it is treated as a
-   literal DNS name with no special meaning.
-
-5.4.  Possible Modifications
-
-5.4.1.  Restriction of Effective Maximum DNS Name Length
-
-   [RFC1034] specifies that "the total number of octets that represent a
-   [DNS] name (i.e., the sum of all label octets and label lengths) is
-   limited to 255", including the null (zero-length) label which
-   represents the root.  For the purpose of deriving predecessors and
-   successors during NSEC RR synthesis, the maximum DNS name length may
-   be effectively restricted to the length of the longest DNS name in
-   the zone.  This will minimise the size of responses containing
-   synthesised NSEC RRs but, especially in the case of the modified
-   method, may result in some additional computational complexity.
-
-   Note that this modification will have the effect of revealing
-   information about the longest name in the zone.  Moreover, when the
-   contents of the zone changes, e.g. during dynamic updates and zone
-   transfers, care must be taken to ensure that the effective maximum
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 8]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   DNS name length agrees with the new contents.
-
-5.4.2.  Use of Modified Method With Zones Containing SRV RRs
-
-   Normally the modified method cannot be used in zones that contain
-   SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple
-   labels.  However the use of SRV RRs can be accommodated by various
-   techniques.  There are at least four possible ways to do this:
-
-   1.  Use conventional NSEC RRs for the region of the zone that
-       contains first-level labels beginning with the underscore (`_')
-       character.  For the purposes of generating these NSEC RRs, the
-       existence of (possibly fictional) ownernames `9{63}' and `a'
-       could be assumed, providing a lower and upper bound for this
-       region.  Then all queries where the QNAME doesn't exist but
-       contains a first-level label beginning with an underscore could
-       be handled using the normal DNSSEC protocol.
-
-       This approach would make it possible to enumerate all DNS names
-       in the zone containing a first-level label beginning with
-       underscore, including all SRV RRs, but this may be of less a
-       concern to the zone administrator than incurring the overhead of
-       the absolute method or of the following variants of the modified
-       method.
-
-   2.  The absolute method could be used for synthesising NSEC RRs for
-       all queries where the QNAME contains a leading underscore.
-       However this re-introduces the susceptibility of the absolute
-       method to denial of service activity, as an attacker could send
-       queries for an effectively inexhaustible supply of domain names
-       beginning with a leading underscore.
-
-   3.  A variant of the modified method could be used for synthesising
-       NSEC RRs for all queries where the QNAME contains a leading
-       underscore.  This variant would assume that all predecessors and
-       successors to queries where the QNAME contains a leading
-       underscore may consist of two lablels rather than only one.  This
-       introduces a little additional complexity without incurring the
-       full increase in response size and computational complexity as
-       the absolute method.
-
-   4.  Finally, a variant the modified method which assumes that all
-       owner names in the zone consist of one or two labels could be
-       used.  However this negates much of the reduction in response
-       size of the modified method and may be nearly as computationally
-       complex as the absolute method.
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 9]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-6.  Examples
-
-   In the following examples:
-
-      the owner name of the zone apex is "example.com.";
-
-      the range of octet values is 0x00 - 0xff excluding values
-      corresponding to uppercase US-ASCII letters; and
-
-      non-printable octet values are expressed as three-digit decimal
-      numbers preceded by a backslash (as specified in Section 5.1 of
-      [RFC1035]).
-
-6.1.  Examples of Immediate Predecessors Using Absolute Method
-
-   Example of typical case:
-
-      P(foo.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.fon\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
-
-      where {n} represents the number of repetitions of an octet.
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 10]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where least significant (left-most) label of DNS name
-   consists of a single octet of the minimum sort value:
-
-      P(\000.foo.example.com.) = foo.example.com.
-
-   Example where least significant (right-most) octet of least
-   significant (left-most) label has the minimum sort value:
-
-      P(foo\000.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.foo.example.com.
-
-      or, in alternate notation:
-
-           \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 11]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name contains an octet which must be decremented by
-   skipping values corresponding to US-ASCII uppercase letters:
-
-      P(fo\[.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.fo\@\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
-
-      where {n} represents the number of repetitions of an octet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 12]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the owner name of the zone apex, and
-   consequently wraps to the DNS name with the maximum possible sort
-   order in the zone:
-
-      P(example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
-6.2.  Examples of Immediate Successors Using Absolute Method
-
-   Example of typical case:
-
-      S(foo.example.com.) = \000.foo.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 13]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is one octet short of the maximum DNS name
-   length:
-
-      N =  fooooooooooooooooooooooooooooooooooooooooooooooo
-           .ooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooo.ooooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooo.ooooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           \000.ooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooo.ooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooo.ooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\000.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 14]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length:
-
-      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
-           o.oooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooo.oooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooo.oooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           o.example.com.
-
-      or, in alternate notation:
-
-           fo{48}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           p.oooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooo.oooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooo.oooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           o.example.com.
-
-      or, in alternate notation:
-
-           fo{47}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 15]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length and the least
-   significant (left-most) label has the maximum sort value:
-
-      N =  \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.ooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooo.ooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooo.ooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooo.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooop.oooooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooo.oooooooooooooooo
-           ooooooooooooooooooooooooooooooooooooooooooooooo.
-           example.com.
-
-      or, in alternate notation:
-
-           o{62}p.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 16]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length and the eight
-   least significant (right-most) octets of the least significant (left-
-   most) label have the maximum sort value:
-
-      N  = foooooooooooooooooooooooooooooooooooooooo\255
-           \255\255\255\255\255\255\255.ooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooo.ooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooo.ooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooop.oooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooo.oooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooo.oooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{39}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 17]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length and contains an
-   octet which must be incremented by skipping values corresponding to
-   US-ASCII uppercase letters:
-
-      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
-           \@.ooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooo.ooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooo.ooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\@.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           \[.ooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooo.ooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooo.ooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\[.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 18]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name has the maximum possible sort order in the
-   zone, and consequently wraps to the owner name of the zone apex:
-
-      N  = \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
-      S(N) = example.com.
-
-6.3.  Examples of Predecessors Using Modified Method
-
-   Example of typical case:
-
-      P'(foo.example.com.) =
-
-           fon\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           fon\255{60}.example.com.
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 19]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name contains more labels than DNS names in the
-   zone:
-
-      P'(bar.foo.example.com.) = foo.example.com.
-
-   Example where least significant (right-most) octet of least
-   significant (left-most) label has the minimum sort value:
-
-      P'(foo\000.example.com.) = foo.example.com.
-
-   Example where least significant (left-most) label has the minimum
-   sort value:
-
-      P'(\000.example.com.) = example.com.
-
-   Example where DNS name is the owner name of the zone apex, and
-   consequently wraps to the DNS name with the maximum possible sort
-   order in the zone:
-
-      P'(example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{63}.example.com.
-
-6.4.  Examples of Successors Using Modified Method
-
-   Example of typical case:
-
-      S'(foo.example.com.) = foo\000.example.com.
-
-   Example where DNS name contains more labels than DNS names in the
-   zone:
-
-      S'(bar.foo.example.com.) = foo\000.example.com.
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 20]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where least significant (left-most) label has the maximum
-   sort value, and consequently wraps to the owner name of the zone
-   apex:
-
-      N  = \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{63}.example.com.
-
-      S'(N) = example.com.
-
-
-7.  Security Considerations
-
-   The derivation of some predecessors/successors requires the testing
-   of more conditions than others.  Consequently the effectiveness of a
-   denial-of-service attack may be enhanced by sending queries that
-   require more conditions to be tested.  The modified method involves
-   the testing of fewer conditions than the absolute method and
-   consequently is somewhat less susceptible to this exposure.
-
-
-8.  IANA Considerations
-
-   This document has no IANA actions.
-
-   Note to RFC Editor: This section is included to make it clear during
-   pre-publication review that this document has no IANA actions.  It
-   may therefore be removed should it be published as an RFC.
-
-
-9.  Acknowledgments
-
-   The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and
-   Niall O'Reilly for their review and input.
-
-
-10.  References
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 21]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-10.1  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-              specifying the location of services (DNS SRV)", RFC 2782,
-              February 2000.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-10.2  Informative References
-
-   [I-D.ietf-dnsext-dnssec-online-signing]
-              Ihren, J. and S. Weiler, "Minimally Covering NSEC Records
-              and DNSSEC On-line Signing",
-              draft-ietf-dnsext-dnssec-online-signing-00 (work in
-              progress), May 2005.
-
-   [I-D.ietf-dnsext-dnssec-trans]
-              Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC
-              Transition Mechanisms",
-              draft-ietf-dnsext-dnssec-trans-02 (work in progress),
-              February 2005.
-
-
-Appendix A.  Change History
-
-A.1.  Changes from sisson-02 to ietf-00
-
-   o  Added notes on use of SRV RRs with modified method.
-
-   o  Changed reference from weiler-dnssec-online-signing to ietf-
-      dnsext-dnssec-online-signing.
-
-   o  Changed reference from ietf-dnsext-dnssec-records to RFC 4034.
-
-   o  Miscellaneous minor changes to text.
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 22]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-A.2.  Changes from sisson-01 to sisson-02
-
-   o  Added modified version of derivation (with supporting examples).
-
-   o  Introduced notational conventions N, P(N), S(N), P'(N) and S'(N).
-
-   o  Added clarification to derivations about when processing stops.
-
-   o  Miscellaneous minor changes to text.
-
-A.3.  Changes from sisson-00 to sisson-01
-
-   o  Split step 3 of derivation of DNS name predecessor into two
-      distinct steps for clarity.
-
-   o  Added clarifying text and examples related to the requirement to
-      avoid uppercase characters when decrementing or incrementing
-      octets.
-
-   o  Added optimisation using restriction of effective maximum DNS name
-      length.
-
-   o  Changed examples to use decimal rather than octal notation as per
-      [RFC1035].
-
-   o  Corrected DNS name length of some examples.
-
-   o  Added reference to weiler-dnssec-online-signing.
-
-   o  Miscellaneous minor changes to text.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 23]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-Authors' Addresses
-
-   Geoffrey Sisson
-   Nominet
-   Sandford Gate
-   Sandy Lane West
-   Oxford
-   OX4 6LB
-   GB
-
-   Phone: +44 1865 332339
-   Email: geoff@nominet.org.uk
-
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London
-   W3 7LR
-   GB
-
-   Phone: +44 20 8735 0686
-   Email: ben@algroup.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 24]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 25]
-
diff --git a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-02.txt b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-02.txt
new file mode 100644
index 000000000000..757e82a88c46
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-02.txt
@@ -0,0 +1,448 @@
+
+
+
+DNSEXT                                                         R. Bellis
+Internet-Draft                                                Nominet UK
+Updates: 1035, 1123                                      January 6, 2010
+(if approved)
+Intended status: Standards Track
+Expires: July 10, 2010
+
+
+          DNS Transport over TCP - Implementation Requirements
+               draft-ietf-dnsext-dns-tcp-requirements-02
+
+Abstract
+
+   This document updates the requirements for the support of TCP as a
+   transport protocol for DNS implementations.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 10, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+
+
+
+Bellis                    Expires July 10, 2010                 [Page 1]
+
+Internet-Draft                DNS over TCP                  January 2010
+
+
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+   2.  Terminology used in this document . . . . . . . . . . . . . . . 3
+
+   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+   4.  Transport Protocol Selection  . . . . . . . . . . . . . . . . . 4
+
+   5.  Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
+
+   6.  Response re-ordering  . . . . . . . . . . . . . . . . . . . . . 6
+
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
+     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+
+   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 8
+
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                    Expires July 10, 2010                 [Page 2]
+
+Internet-Draft                DNS over TCP                  January 2010
+
+
+1.  Introduction
+
+   Most DNS [RFC1035] transactions take place over UDP [RFC0792].  The
+   TCP [RFC0793] is used for zone transfers and for the transfer of
+   other packets which exceed the protocol's original 512 byte packet-
+   size limit.
+
+   Section 6.1.3.2 of [RFC1123] states:
+
+      DNS resolvers and recursive servers MUST support UDP, and SHOULD
+      support TCP, for sending (non-zone-transfer) queries.
+
+   However, some implementors have taken the text quoted above to mean
+   that TCP support is an optional feature of the DNS protocol.
+
+   The majority of DNS server operators already support TCP and the
+   default configuration for most software implementations is to support
+   TCP.  The primary audience for this document is those implementors
+   whose failure to support TCP restricts interoperability and limits
+   deployment of new DNS features.
+
+   This document therefore updates the core DNS protocol specifications
+   such that support for TCP is henceforth a REQUIRED part of a full DNS
+   protocol implementation.
+
+   Whilst this document makes no specific recommendations to operators
+   of DNS servers, it should be noted that failure to support TCP (or
+   blocking of DNS over TCP at the network layer) may result in
+   resolution failure and application-level timeouts.
+
+
+2.  Terminology used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+3.  Discussion
+
+   In the absence of EDNS0 (see below) the normal behaviour of any DNS
+   server needing to send a UDP response that exceeds that 512 byte
+   limit is for the server to truncate the response so that it fits
+   within the 512 byte limit and set the TC flag in the response header.
+   When the client receives such a response it takes the TC flag as an
+   indication that it should retry over TCP instead.
+
+   RFC 1123 also says:
+
+
+
+Bellis                    Expires July 10, 2010                 [Page 3]
+
+Internet-Draft                DNS over TCP                  January 2010
+
+
+
+      ... it is also clear that some new DNS record types defined in the
+      future will contain information exceeding the 512 byte limit that
+      applies to UDP, and hence will require TCP.  Thus, resolvers and
+      name servers should implement TCP services as a backup to UDP
+      today, with the knowledge that they will require the TCP service
+      in the future.
+
+   Existing deployments of DNSSEC [RFC4033] have shown that truncation
+   at the 512 byte boundary is now commonplace.  For example an NXDOMAIN
+   (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
+   is almost invariably longer than 512 bytes.
+
+   Since the original core specifications for DNS were written, the
+   Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
+   These extensions can be used to indicate that the client is prepared
+   to receive UDP responses longer than 512 bytes.  An EDNS0 compatible
+   server receiving a request from an EDNS0 compatible client may send
+   UDP packets up to that client's announced buffer size without
+   truncation.
+
+   However, transport of UDP packets that exceed the size of the path
+   MTU causes IP packet fragmentation, which has been found to be
+   unreliable in some circumstances.  Many firewalls routinely block
+   fragmented IP packets, and some implementations lack the software
+   logic necessary to reassemble a fragmented datagram.  Worse still,
+   some devices deliberately refuse to handle DNS packets containing
+   EDNS0 options.  Other issues relating to UDP transport and packet
+   size are discussed in [RFC5625].
+
+   The MTU most commonly found in the core of the Internet is around
+   1500 bytes, and even that limit is routinely exceeded by DNSSEC
+   signed responses.
+
+   The future that was anticipated in RFC 1123 has arrived, and the only
+   standardised UDP-based mechanism which may have resolved the packet
+   size issue has been found inadequate.
+
+
+4.  Transport Protocol Selection
+
+   All DNS implementations MUST support both UDP and TCP transport.
+
+   o  Authoritative resolver implementations MUST support TCP so that
+      they may serve any long responses that they are configured to
+      serve.
+
+
+
+
+
+Bellis                    Expires July 10, 2010                 [Page 4]
+
+Internet-Draft                DNS over TCP                  January 2010
+
+
+   o  A recursive resolver or forwarder MUST support TCP so that it does
+      not prevent long responses from a TCP-capable server from reaching
+      its TCP-capable clients.
+   o  A general purpose stub resolver implementation (e.g. an operating
+      system's DNS resolution library) MUST support TCP since to do
+      otherwise would limit its interoperability with its own clients
+      and with upstream servers.
+
+   An exception may be made for proprietary stub resolver
+   implementations.  These MAY omit support for TCP if operating in an
+   environment where truncation can never occur, or where DNS lookup
+   failure is acceptable should truncation occur.
+
+   Regarding the choice of when to use UDP or TCP, RFC 1123 says:
+
+      ... a DNS resolver or server that is sending a non-zone-transfer
+      query MUST send a UDP query first.
+
+   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
+   query first, but MAY elect to send a TCP query instead if it has good
+   reason to expect the response would be truncated if it were sent over
+   UDP (with or without EDNS0) or for other operational reasons, in
+   particular if it already has an open TCP connection to the server.
+
+
+5.  Connection Handling
+
+   Section 4.2.2 of [RFC1035] says:
+
+      If the server needs to close a dormant connection to reclaim
+      resources, it should wait until the connection has been idle for a
+      period on the order of two minutes.
+
+   Other more modern protocols (e.g.  HTTP [RFC2616]) have support for
+   persistent TCP connections and operational experience has shown that
+   long timeouts can easily cause resource exhaustion and poor response
+   under heavy load.  Intentionally opening many connections and leaving
+   them dormant can trivially create a "denial of service" attack.
+
+   This document therefore RECOMMENDS that the application-level idle
+   period should be of the order of TBD seconds.
+
+   Servers MAY allow dormant connections to remain open for longer
+   periods, but for the avoidance of doubt persistent DNS connections
+   should generally be considered to be as much for the server's benefit
+   as for the client's.  Therefore if the server needs to unilaterally
+   close a dormant TCP connection it MUST be free to do so whenever
+   required.
+
+
+
+Bellis                    Expires July 10, 2010                 [Page 5]
+
+Internet-Draft                DNS over TCP                  January 2010
+
+
+   To mitigate the risk of unintentional server overload DNS clients
+   MUST take care to minimize the number of concurrent TCP connections
+   made to any individual server.
+
+   Further recommendations for the tuning of TCP parameters to allow
+   higher throughput or improved resiliency against denial of service
+   attacks are outside the scope of this document.
+
+
+6.  Response re-ordering
+
+   RFC 1035 is ambiguous on the question of whether TCP queries may be
+   re-ordered - the only relevant text is in Section 4.2.1 which relates
+   to UDP:
+
+      Queries or their responses may be reordered by the network, or by
+      processing in name servers, so resolvers should not depend on them
+      being returned in order.
+
+   For the avoidance of future doubt, this requirement is clarified.
+   Client resolvers MUST be able to process responses which arrive in a
+   different order to that in which the requests were sent, regardless
+   of the transport protocol in use.
+
+
+7.  Security Considerations
+
+   Some DNS server operators have expressed concern that wider use of
+   DNS over TCP will expose them to a higher risk of "denial of service"
+   (DoS) attacks.
+
+   Whilst there is a theoretically higher risk of such attacks against
+   TCP-enabled servers, techniques for the mitigation of DoS attacks at
+   the network level have improved substantially since DNS was first
+   designed.
+
+   The vast majority of TLD authority servers and all but one of the
+   root name servers already support TCP and the author knows of no
+   evidence to suggest that TCP-based DoS attacks against existing DNS
+   infrastructure are commonplace.
+
+   Operators of recursive servers should ensure that they only accept
+   connections from expected clients, and do not accept them from
+   unknown sources.  In the case of UDP traffic this will protect
+   against reflector attacks [RFC5358] and in the case of TCP traffic it
+   will prevent an unknown client from exhausting the server's limits on
+   the number of concurrent connections.
+
+
+
+
+Bellis                    Expires July 10, 2010                 [Page 6]
+
+Internet-Draft                DNS over TCP                  January 2010
+
+
+8.  IANA Considerations
+
+   This document requests no IANA actions.
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
+              RFC 792, September 1981.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+9.2.  Informative References
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
+              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+              October 2008.
+
+   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
+              BCP 152, RFC 5625, August 2009.
+
+
+
+
+Bellis                    Expires July 10, 2010                 [Page 7]
+
+Internet-Draft                DNS over TCP                  January 2010
+
+
+Appendix A.  Change Log
+
+   NB: to be removed by the RFC Editor before publication.
+
+   draft-ietf-dnsext-dns-tcp-requirements-02
+      Change of title - more focus on implementation and not operation
+      Re-write of some of the security section
+      Added recommendation for minimal concurrent connections
+      Minor editorial nits from Alfred Hoenes
+
+   draft-ietf-dnsext-dns-tcp-requirements-01
+      Addition of response ordering section
+      Various minor editorial changes from WG reviewers
+
+   draft-ietf-dnsext-dns-tcp-requirements-00
+      Initial draft
+
+
+Author's Address
+
+   Ray Bellis
+   Nominet UK
+   Edmund Halley Road
+   Oxford  OX4 4DQ
+   United Kingdom
+
+   Phone: +44 1865 332211
+   Email: ray.bellis@nominet.org.uk
+   URI:   http://www.nominet.org.uk/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                    Expires July 10, 2010                 [Page 8]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
deleted file mode 100644
index bcc2b4ec516e..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+++ /dev/null
@@ -1,442 +0,0 @@
-
-
-INTERNET-DRAFT                                             Samuel Weiler
-Expires: June 2004                                     December 15, 2003
-Updates: RFC 2535, [DS]
-
-	 Legacy Resolver Compatibility for Delegation Signer
-	 draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other
-   documents at any time.  It is inappropriate to use Internet-Drafts
-   as reference material or to cite them other than as "work in
-   progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   Comments should be sent to the author or to the DNSEXT WG mailing
-   list: namedroppers@ops.ietf.org
-
-Abstract
-
-   As the DNS Security (DNSSEC) specifications have evolved, the
-   syntax and semantics of the DNSSEC resource records (RRs) have
-   changed.  Many deployed nameservers understand variants of these
-   semantics.  Dangerous interactions can occur when a resolver that
-   understands an earlier version of these semantics queries an
-   authoritative server that understands the new delegation signer
-   semantics, including at least one failure scenario that will cause
-   an unsecured zone to be unresolvable.  This document changes the
-   type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
-   avoid those interactions.
-
-Changes between 05 and 06:
-
-   Signifigantly reworked the IANA section -- went back to one
-   algorithm registry.
-
-   Removed Diffie-Hellman from the list of zone-signing algorithms
-   (leaving only DSA, RSA/SHA-1, and private algorithms).
-
-   Added a DNSKEY flags field registry.
-
-Changes between 04 and 05:
-
-   IESG approved publication.
-
-   Cleaned up an internal reference in the acknowledgements section.
-
-   Retained KEY and SIG for TKEY, too.  Added TKEY (2930) reference.
-
-   Changed the names of both new registries.  Added algorithm
-   mnemonics to the new zone signing algorithm registry.  Minor
-   rewording in the IANA section for clarity.
-
-   Cleaned up formatting of references.  Replaced unknown-rr draft
-   references with RFC3597.  Bumped DS version number.
-
-Changes between 03 and 04:
-
-   Clarified that RRSIG(0) may be defined by standards action.
-
-   Created a new algorithm registry and renamed the old algorithm
-   registry for SIG(0) only.  Added references to the appropriate
-   crypto algorithm and format specifications.
-
-   Several minor rephrasings.
-
-Changes between 02 and 03:
-
-   KEY (as well as SIG) retained for SIG(0) use only.
-
-Changes between 01 and 02:
-
-   SIG(0) still uses SIG, not RRSIG.  Added 2931 reference.
-
-   Domain names embedded in NSECs and RRSIGs are not compressible and
-   are not downcased.  Added unknown-rrs reference (as informative).
-
-   Simplified the last paragraph of section 3 (NSEC doesn't always
-   signal a negative answer).
-
-   Changed the suggested type code assignments.
-
-   Added 2119 reference.
-
-   Added definitions of "unsecure delegation" and "unsecure referral",
-   since they're not clearly defined elsewhere.
-
-   Moved 2065 to informative references, not normative.
-
-1. Introduction
-
-   The DNSSEC protocol has been through many iterations whose syntax
-   and semantics are not completely compatible.  This has occurred as
-   part of the ordinary process of proposing a protocol, implementing
-   it, testing it in the increasingly complex and diverse environment
-   of the Internet, and refining the definitions of the initial
-   Proposed Standard.  In the case of DNSSEC, the process has been
-   complicated by DNS's criticality and wide deployment and the need
-   to add security while minimizing daily operational complexity.
-
-   A weak area for previous DNS specifications has been lack of detail
-   in specifying resolver behavior, leaving implementors largely on
-   their own to determine many details of resolver function.  This,
-   combined with the number of iterations the DNSSEC spec has been
-   through, has resulted in fielded code with a wide variety of
-   behaviors.  This variety makes it difficult to predict how a
-   protocol change will be handled by all deployed resolvers.  The
-   risk that a change will cause unacceptable or even catastrophic
-   failures makes it difficult to design and deploy a protocol change.
-   One strategy for managing that risk is to structure protocol
-   changes so that existing resolvers can completely ignore input that
-   might confuse them or trigger undesirable failure modes.
-
-   This document addresses a specific problem caused by Delegation
-   Signer's [DS] introduction of new semantics for the NXT RR that are
-   incompatible with the semantics in RFC 2535 [RFC2535].  Answers
-   provided by DS-aware servers can trigger an unacceptable failure
-   mode in some resolvers that implement RFC 2535, which provides a
-   great disincentive to sign zones with DS.  The changes defined in
-   this document allow for the incremental deployment of DS.
-
-1.1 Terminology
-
-   In this document, the term "unsecure delegation" means any
-   delegation for which no DS record appears at the parent.  An
-   "unsecure referral" is an answer from the parent containing an NS
-   RRset and a proof that no DS record exists for that name.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-1.2 The Problem
-
-   Delegation Signer introduces new semantics for the NXT RR that are
-   incompatible with the semantics in RFC 2535.  In RFC 2535, NXT
-   records were only required to be returned as part of a
-   non-existence proof.  With DS, an unsecure referral returns, in
-   addition to the NS, a proof of non-existence of a DS RR in the form
-   of an NXT and SIG(NXT).  RFC 2535 didn't specify how a resolver was
-   to interpret a response with both an NS and an NXT in the authority
-   section, RCODE=0, and AA=0.  Some widely deployed 2535-aware
-   resolvers interpret any answer with an NXT as a proof of
-   non-existence of the requested record.  This results in unsecure
-   delegations being invisible to 2535-aware resolvers and violates
-   the basic architectural principle that DNSSEC must do no harm --
-   the signing of zones must not prevent the resolution of unsecured
-   delegations.
-
-2. Possible Solutions
-
-   This section presents several solutions that were considered.
-   Section 3 describes the one selected.
-
-2.1. Change SIG, KEY, and NXT type codes
-
-   To avoid the problem described above, legacy (RFC2535-aware)
-   resolvers need to be kept from seeing unsecure referrals that
-   include NXT records in the authority section.  The simplest way to
-   do that is to change the type codes for SIG, KEY, and NXT.
-
-   The obvious drawback to this is that new resolvers will not be able
-   to validate zones signed with the old RRs.  This problem already
-   exists, however, because of the changes made by DS, and resolvers
-   that understand the old RRs (and have compatibility issues with DS)
-   are far more prevalent than 2535-signed zones.
-
-2.2. Change a subset of type codes
-
-   The observed problem with unsecure referrals could be addressed by
-   changing only the NXT type code or another subset of the type codes
-   that includes NXT.  This has the virtue of apparent simplicity, but
-   it risks introducing new problems or not going far enough.  It's
-   quite possible that more incompatibilities exist between DS and
-   earlier semantics.  Legacy resolvers may also be confused by seeing
-   records they recognize (SIG and KEY) while being unable to find
-   NXTs.  Although it may seem unnecessary to fix that which is not
-   obviously broken, it's far cleaner to change all of the type codes
-   at once.  This will leave legacy resolvers and tools completely
-   blinded to DNSSEC -- they will see only unknown RRs.
-
-2.3. Replace the DO bit
-
-   Another way to keep legacy resolvers from ever seeing DNSSEC
-   records with DS semantics is to have authoritative servers only
-   send that data to DS-aware resolvers.  It's been proposed that
-   assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
-   called "DA"), and having authoritative servers send DNSSEC data
-   only in response to queries with the DA bit set, would accomplish
-   this.  This bit would presumably supplant the DO bit described in
-   RFC 3225.
-
-   This solution is sufficient only if all 2535-aware resolvers zero
-   out EDNS0 flags that they don't understand.  If one passed through
-   the DA bit unchanged, it would still see the new semantics, and it
-   would probably fail to see unsecure delegations.  Since it's
-   impractical to know how every DNS implementation handles unknown
-   EDNS0 flags, this is not a universal solution.  It could, though,
-   be considered in addition to changing the RR type codes.
-
-2.4. Increment the EDNS version
-
-   Another possible solution is to increment the EDNS version number
-   as defined in RFC 2671 [RFC2671], on the assumption that all
-   existing implementations will reject higher versions than they
-   support, and retain the DO bit as the signal for DNSSEC awareness.
-   This approach has not been tested.
-
-2.5. Do nothing
-
-   There is a large deployed base of DNS resolvers that understand
-   DNSSEC as defined by the standards track RFC 2535 and RFC 2065
-   and, due to under specification in those documents, interpret any
-   answer with an NXT as a non-existence proof.  So long as that is
-   the case, zone owners will have a strong incentive to not sign any
-   zones that contain unsecure delegations, lest those delegations be
-   invisible to such a large installed base.  This will dramatically
-   slow DNSSEC adoption.
-
-   Unfortunately, without signed zones there's no clear incentive for
-   operators of resolvers to upgrade their software to support the new
-   version of DNSSEC, as defined in [DS].  Historical data suggests
-   that resolvers are rarely upgraded, and that old nameserver code
-   never dies.
-
-   Rather than wait years for resolvers to be upgraded through natural
-   processes before signing zones with unsecure delegations,
-   addressing this problem with a protocol change will immediately
-   remove the disincentive for signing zones and allow widespread
-   deployment of DNSSEC.
-
-3. Protocol changes
-
-   This document changes the type codes of SIG, KEY, and NXT.  This
-   approach is the cleanest and safest of those discussed above,
-   largely because the behavior of resolvers that receive unknown type
-   codes is well understood.  This approach has also received the most
-   testing.
-
-   To avoid operational confusion, it's also necessary to change the
-   mnemonics for these RRs.  DNSKEY will be the replacement for KEY,
-   with the mnemonic indicating that these keys are not for
-   application use, per [RFC3445].  RRSIG (Resource Record SIGnature)
-   will replace SIG, and NSEC (Next SECure) will replace NXT.  These
-   new types completely replace the old types, except that SIG(0)
-   [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
-
-   The new types will have exactly the same syntax and semantics as
-   specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
-   the following:
-
-      1) Consistent with [RFC3597], domain names embedded in
-      RRSIG and NSEC RRs MUST NOT be compressed,
-
-      2) Embedded domain names in RRSIG and NSEC RRs are not downcased
-      for purposes of DNSSEC canonical form and ordering nor for
-      equality comparison, and
-
-      3) An RRSIG with a type-covered field of zero has undefined
-      semantics.  The meaning of such a resource record may only be
-      defined by IETF Standards Action.
-
-   If a resolver receives the old types, it SHOULD treat them as
-   unknown RRs and SHOULD NOT assign any special meaning to them or
-   give them any special treatment.  It MUST NOT use them for DNSSEC
-   validations or other DNS operational decision making.  For example,
-   a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
-   validate RRSIGs.  If SIG, KEY, or NXT RRs are included in a zone,
-   they MUST NOT receive special treatment.  As an example, if a SIG
-   is included in a signed zone, there MUST be an RRSIG for it.
-   Authoritative servers may wish to give error messages when loading
-   zones containing SIG or NXT records (KEY records may be included
-   for SIG(0) or TKEY).
-
-   As a clarification to previous documents, some positive responses,
-   particularly wildcard proofs and unsecure referrals, will contain
-   NSEC RRs.  Resolvers MUST NOT treat answers with NSEC RRs as
-   negative answers merely because they contain an NSEC.
-
-4. IANA Considerations
-
-4.1 DNS Resource Record Types
-
-   This document updates the IANA registry for DNS Resource Record
-   Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
-   DNSKEY RRs, respectively.
-
-   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
-   TKEY [RFC2930] use only.
-
-   Type 30 (NXT) should be marked as Obsolete.
-
-4.2 DNS Security Algorithm Numbers
-
-   To allow zone signing (DNSSEC) and transaction security mechanisms
-   (SIG(0) and TKEY) to use different sets of algorithms, the existing
-   "DNS Security Algorithm Numbers" registry is modified to include
-   the applicability of each algorithm.  Specifically, two new columns
-   are added to the registry, showing whether each algorithm may be
-   used for zone signing, transaction security mechanisms, or both.
-   Only algorithms usable for zone signing may be used in DNSKEY,
-   RRSIG, and DS RRs.  Only algorithms usable for SIG(0) and/or TSIG
-   may be used in SIG and KEY RRs.
-
-   All currently defined algorithms remain usable for transaction
-   security mechanisms.  Only RSA/SHA-1, DSA/SHA-1, and private
-   algorithms (types 253 and 254) may be used for zone signing.  Note
-   that the registry does not contain the requirement level of each
-   algorithm, only whether or not an algorithm may be used for the
-   given purposes.  For example, RSA/MD5, while allowed for
-   transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
-
-   Additionally, the presentation format algorithm mnemonics from
-   RFC2535 Section 7 are added to the registry.  This document assigns
-   RSA/SHA-1 the mnemonic RSASHA1.
-
-   As before, assignment of new algorithms in this registry requires
-   IETF Standards Action.  Additionally, modification of algorithm
-   mnemonics or applicability requires IETF Standards Action.
-   Documents defining a new algorithm must address the applicability
-   of the algorithm and should assign a presentation mnemonic to the
-   algorithm.
-
-4.3 DNSKEY Flags
-
-   Like the KEY resource record, DNSKEY contains a 16-bit flags field.
-   This document creates a new registry for the DNSKEY flags field.
-
-   Initially, this registry only contains an assignment for bit 7 (the
-   ZONE bit).  Bits 0-6 and 8-15 are available for assignment by IETF
-   Standards Action.
-
-4.4 DNSKEY Protocol Octet
-
-   Like the KEY resource record, DNSKEY contains an eight bit protocol
-   field.  The only defined value for this field is 3 (DNSSEC).  No
-   other values are allowed, hence no IANA registry is needed for this
-   field.
-
-5. Security Considerations
-
-   The changes introduced here do not materially affect security.
-   The implications of trying to use both new and legacy types
-   together are not well understood, and attempts to do so would
-   probably lead to unintended and dangerous results.
-
-   Changing type codes will leave code paths in legacy resolvers that
-   are never exercised.  Unexercised code paths are a frequent source
-   of security holes, largely because those code paths do not get
-   frequent scrutiny.
-
-   Doing nothing, as described in section 2.5, will slow DNSSEC
-   deployment.  While this does not decrease security, it also fails
-   to increase it.
-
-6. Normative references
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
-             RFC 2535, March 1999.
-
-   [DS]      Gudmundsson, O., "Delegation Signer Resource Record",
-             draft-ietf-dnsext-delegation-signer-15.txt, work in
-             progress, June 2003.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
-             (SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
-             RR)", RFC 2930, September 2000.
-
-   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
-             System (DNS)", RFC 2436, March 1999.
-
-   [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
-             Domain Name System (DNS)", RFC 2539, March 1999.
-
-   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
-             Domain Name System (DNS)", RFC 3110, May 2001.
-
-7. Informative References
-
-   [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
-             Extensions", RFC 2065, January 1997.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-	     2671, August 1999.
-
-   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-             3225, December 2001.
-
-   [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
-	     "Domain Name System (DNS) IANA Considerations", BCP 42,
-	     RFC 2929, September 2000.
-
-   [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
-	     Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
-             Record (RR) Types", RFC 3597, September 2003.
-
-8. Acknowledgments
-
-   The changes introduced here and the analysis of alternatives had
-   many contributors.  With apologies to anyone overlooked, those
-   include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
-   Lewis, Bill Manning, and Suzanne Woolf.
-
-   Thanks to Jakob Schlyter and Mark Andrews for identifying the
-   incompatibility described in section 1.2.
-
-   In addition to the above, the author would like to thank Scott
-   Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
-   comments.
-
-9. Author's Address
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, MD 21046
-   USA
-   weiler@tislabs.com
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
deleted file mode 100644
index 3a800f98880d..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-Network Working Group                                          S. Weiler
-Internet-Draft                                               SPARTA, Inc
-Updates: 4034, 4035 (if approved)                           May 23, 2005
-Expires: November 24, 2005
-
-
-         Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 24, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document is a collection of minor technical clarifications to
-   the DNSSECbis document set.  It is meant to serve as a resource to
-   implementors as well as an interim repository of possible DNSSECbis
-   errata.
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 1]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-Proposed additions in future versions
-
-   An index sorted by the section of DNSSECbis being clarified.
-
-   A list of proposed protocol changes being made in other documents,
-   such as NSEC3 and Epsilon.  This document would not make those
-   changes, merely provide an index into the documents that are making
-   changes.
-
-Changes between -00 and -01
-
-   Document significantly restructured.
-
-   Added section on QTYPE=ANY.
-
-Changes between personal submission and first WG draft
-
-   Added Section 2.1 based on namedroppers discussions from March 9-10,
-   2005.
-
-   Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
-
-   Added the DNSSECbis RFC numbers.
-
-   Figured out the confusion in Section 4.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 2]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-Table of Contents
-
-   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
-     1.1   Structure of this Document . . . . . . . . . . . . . . . .  4
-     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Significant Concerns . . . . . . . . . . . . . . . . . . . . .  4
-     2.1   Clarifications on Non-Existence Proofs . . . . . . . . . .  4
-     2.2   Empty Non-Terminal Proofs  . . . . . . . . . . . . . . . .  5
-     2.3   Validating Responses to an ANY Query . . . . . . . . . . .  5
-   3.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
-     3.1   Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
-     3.2   Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
-     3.3   Caution About Local Policy and Multiple RRSIGs . . . . . .  6
-     3.4   Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
-   4.  Minor Corrections and Clarifications . . . . . . . . . . . . .  7
-     4.1   Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  7
-     4.2   Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  7
-     4.3   Errors in Examples . . . . . . . . . . . . . . . . . . . .  8
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     7.1   Normative References . . . . . . . . . . . . . . . . . . .  8
-     7.2   Informative References . . . . . . . . . . . . . . . . . .  9
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
-   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
-       Intellectual Property and Copyright Statements . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 3]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-1.  Introduction and Terminology
-
-   This document lists some minor clarifications and corrections to
-   DNSSECbis, as described in [1], [2], and [3].
-
-   It is intended to serve as a resource for implementors and as a
-   repository of items that need to be addressed when advancing the
-   DNSSECbis documents from Proposed Standard to Draft Standard.
-
-   In this version (-01 of the WG document), feedback is particularly
-   solicited on the structure of the document and whether the text in
-   the recently added sections is correct and sufficient.
-
-   Proposed substantive additions to this document should be sent to the
-   namedroppers mailing list as well as to the editor of this document.
-   The editor would greatly prefer text suitable for direct inclusion in
-   this document.
-
-1.1  Structure of this Document
-
-   The clarifications to DNSSECbis are sorted according to the editor's
-   impression of their importance, starting with ones which could, if
-   ignored, lead to security and stability problems and progressing down
-   to clarifications that are likely to have little operational impact.
-   Mere typos and awkward phrasings are not addressed unless they could
-   lead to misinterpretation of the DNSSECbis documents.
-
-1.2  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [4].
-
-2.  Significant Concerns
-
-   This section provides clarifications that, if overlooked, could lead
-   to security issues or major interoperability problems.
-
-2.1  Clarifications on Non-Existence Proofs
-
-   RFC4035 Section 5.4 slightly underspecifies the algorithm for
-   checking non-existence proofs.  In particular, the algorithm there
-   might incorrectly allow the NSEC from the parent side of a zone cut
-   to prove the non-existence of either other RRs at that name in the
-   child zone or other names in the child zone.  It might also allow a
-   NSEC at the same name as a DNAME to prove the non-existence of names
-   beneath that DNAME.
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 4]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   A parent-side delegation NSEC (one with the NS bit set, but no SOA
-   bit set, and with a singer field that's shorter than the owner name)
-   must not be used to assume non-existence of any RRs below that zone
-   cut (both RRs at that ownername and at ownernames with more leading
-   labels, no matter their content).  Similarly, an NSEC with the DNAME
-   bit set must not be used to assume the non-existence of any
-   descendant of that NSEC's owner name.
-
-2.2  Empty Non-Terminal Proofs
-
-   To be written, based on Roy Arends' May 11th message to namedroppers.
-
-2.3  Validating Responses to an ANY Query
-
-   RFC4035 does not address now to validate responses when QTYPE=*.  As
-   described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
-   may include a subset of the RRsets at a given name -- it is not
-   necessary to include all RRsets at the QNAME in the response.
-
-   When validating a response to QTYPE=*, validate all received RRsets
-   that match QNAME and QCLASS.  If any of those RRsets fail validation,
-   treat the answer as Bogus.  If there are no RRsets matching QNAME and
-   QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
-   clarified in this document).  To be clear, a validator must not
-   insist on receiving all records at the QNAME in response to QTYPE=*.
-
-3.  Interoperability Concerns
-
-3.1  Unknown DS Message Digest Algorithms
-
-   Section 5.2 of RFC4035 includes rules for how to handle delegations
-   to zones that are signed with entirely unsupported algorithms, as
-   indicated by the algorithms shown in those zone's DS RRsets.  It does
-   not explicitly address how to handle DS records that use unsupported
-   message digest algorithms.  In brief, DS records using unknown or
-   unsupported message digest algorithms MUST be treated the same way as
-   DS records referring to DNSKEY RRs of unknown or unsupported
-   algorithms.
-
-   The existing text says:
-
-      If the validator does not support any of the algorithms listed
-      in an authenticated DS RRset, then the resolver has no supported
-      authentication path leading from the parent to the child.  The
-      resolver should treat this case as it would the case of an
-      authenticated NSEC RRset proving that no DS RRset exists, as
-      described above.
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 5]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   To paraphrase the above, when determining the security status of a
-   zone, a validator discards (for this purpose only) any DS records
-   listing unknown or unsupported algorithms.  If none are left, the
-   zone is treated as if it were unsigned.
-
-   Modified to consider DS message digest algorithms, a validator also
-   discards any DS records using unknown or unsupported message digest
-   algorithms.
-
-3.2  Private Algorithms
-
-   As discussed above, section 5.2 of RFC4035 requires that validators
-   make decisions about the security status of zones based on the public
-   key algorithms shown in the DS records for those zones.  In the case
-   of private algorithms, as described in RFC4034 Appendix A.1.1, the
-   eight-bit algorithm field in the DS RR is not conclusive about what
-   algorithm(s) is actually in use.
-
-   If no private algorithms appear in the DS set or if any supported
-   algorithm appears in the DS set, no special processing will be
-   needed.  In the remaining cases, the security status of the zone
-   depends on whether or not the resolver supports any of the private
-   algorithms in use (provided that these DS records use supported hash
-   functions, as discussed in Section 3.1).  In these cases, the
-   resolver MUST retrieve the corresponding DNSKEY for each private
-   algorithm DS record and examine the public key field to determine the
-   algorithm in use.  The security-aware resolver MUST ensure that the
-   hash of the DNSKEY RR's owner name and RDATA matches the digest in
-   the DS RR.  If they do not match, and no other DS establishes that
-   the zone is secure, the referral should be considered BAD data, as
-   discussed in RFC4035.
-
-   This clarification facilitates the broader use of private algorithms,
-   as suggested by [5].
-
-3.3  Caution About Local Policy and Multiple RRSIGs
-
-   When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
-   suggests that "the local resolver security policy determines whether
-   the resolver also has to test these RRSIG RRs and how to resolve
-   conflicts if these RRSIG RRs lead to differing results."  In most
-   cases, a resolver would be well advised to accept any valid RRSIG as
-   sufficient.  If the first RRSIG tested fails validation, a resolver
-   would be well advised to try others, giving a successful validation
-   result if any can be validated and giving a failure only if all
-   RRSIGs fail validation.
-
-   If a resolver adopts a more restrictive policy, there's a danger that
-
-
-
-Weiler                  Expires November 24, 2005               [Page 6]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   properly-signed data might unnecessarily fail validation, perhaps
-   because of cache timing issues.  Furthermore, certain zone management
-   techniques, like the Double Signature Zone-signing Key Rollover
-   method described in section 4.2.1.2 of [6] might not work reliably.
-
-3.4  Key Tag Calculation
-
-   RFC4034 Appendix B.1 incorrectly defines the Key Tag field
-   calculation for algorithm 1.  It correctly says that the Key Tag is
-   the most significant 16 of the least significant 24 bits of the
-   public key modulus.  However, RFC4034 then goes on to incorrectly say
-   that this is 4th to last and 3rd to last octets of the public key
-   modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
-
-4.  Minor Corrections and Clarifications
-
-4.1  Finding Zone Cuts
-
-   Appendix C.8 of RFC4035 discusses sending DS queries to the servers
-   for a parent zone.  To do that, a resolver may first need to apply
-   special rules to discover what those servers are.
-
-   As explained in Section 3.1.4.1 of RFC4035, security-aware name
-   servers need to apply special processing rules to handle the DS RR,
-   and in some situations the resolver may also need to apply special
-   rules to locate the name servers for the parent zone if the resolver
-   does not already have the parent's NS RRset.  Section 4.2 of RFC4035
-   specifies a mechanism for doing that.
-
-4.2  Clarifications on DNSKEY Usage
-
-   Questions of the form "can I use a different DNSKEY for signing the
-   X" have occasionally arisen.
-
-   The short answer is "yes, absolutely".  You can even use a different
-   DNSKEY for each RRset in a zone, subject only to practical limits on
-   the size of the DNSKEY RRset.  However, be aware that there is no way
-   to tell resolvers what a particularly DNSKEY is supposed to be used
-   for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
-   authenticate any RRset in the zone.  For example, if a weaker or less
-   trusted DNSKEY is being used to authenticate NSEC RRsets or all
-   dynamically updated records, that same DNSKEY can also be used to
-   sign any other RRsets from the zone.
-
-   Furthermore, note that the SEP bit setting has no effect on how a
-   DNSKEY may be used -- the validation process is specifically
-   prohibited from using that bit by RFC4034 section 2.1.2.  It possible
-   to use a DNSKEY without the SEP bit set as the sole secure entry
-
-
-
-Weiler                  Expires November 24, 2005               [Page 7]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   point to the zone, yet use a DNSKEY with the SEP bit set to sign all
-   RRsets in the zone (other than the DNSKEY RRset).  It's also possible
-   to use a single DNSKEY, with or without the SEP bit set, to sign the
-   entire zone, including the DNSKEY RRset itself.
-
-4.3  Errors in Examples
-
-   The text in RFC4035 Section C.1 refers to the examples in B.1 as
-   "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
-   obvious in the second paragraph where it states that the RRSIG labels
-   field value of 3 indicates that the answer was not the result of
-   wildcard expansion.  This is true for "x.w.example" but not for
-   "x.w.example.com", which of course has a label count of 4
-   (antithetically, a label count of 3 would imply the answer was the
-   result of a wildcard expansion).
-
-   The first paragraph of RFC4035 Section C.6 also has a minor error:
-   the reference to "a.z.w.w.example" should instead be "a.z.w.example",
-   as in the previous line.
-
-5.  IANA Considerations
-
-   This document specifies no IANA Actions.
-
-6.  Security Considerations
-
-   This document does not make fundamental changes to the DNSSEC
-   protocol, as it was generally understood when DNSSECbis was
-   published.  It does, however, address some ambiguities and omissions
-   in those documents that, if not recognized and addressed in
-   implementations, could lead to security failures.  In particular, the
-   validation algorithm clarifications in Section 2 are critical for
-   preserving the security properties DNSSEC offers.  Furthermore,
-   failure to address some of the interoperability concerns in Section 3
-   could limit the ability to later change or expand DNSSEC, including
-   by adding new algorithms.
-
-7.  References
-
-7.1  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-
-
-Weiler                  Expires November 24, 2005               [Page 8]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-7.2  Informative References
-
-   [5]  Blacka, D., "DNSSEC Experiments",
-        draft-blacka-dnssec-experiments-00 (work in progress),
-        December 2004.
-
-   [6]  Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
-        draft-ietf-dnsop-dnssec-operational-practices-04 (work in
-        progress), May 2005.
-
-
-Author's Address
-
-   Samuel Weiler
-   SPARTA, Inc
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   Email: weiler@tislabs.com
-
-Appendix A.  Acknowledgments
-
-   The editor is extremely grateful to those who, in addition to finding
-   errors and omissions in the DNSSECbis document set, have provided
-   text suitable for inclusion in this document.
-
-   The lack of specificity about handling private algorithms, as
-   described in Section 3.2, and the lack of specificity in handling ANY
-   queries, as described in Section 2.3, were discovered by David
-   Blacka.
-
-   The error in algorithm 1 key tag calculation, as described in
-   Section 3.4, was found by Abhijit Hayatnagarkar.  Donald Eastlake
-   contributed text for Section 3.4.
-
-   The bug relating to delegation NSEC RR's in Section 2.1 was found by
-   Roy Badami.  Roy Arends found the related problem with DNAME.
-
-   The errors in the RFC4035 examples were found by Roy Arends, who also
-   contributed text for Section 4.3 of this document.
-
-
-
-Weiler                  Expires November 24, 2005               [Page 9]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   The editor would like to thank Olafur Gudmundsson and Scott Rose for
-   their substantive comments on the text of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005              [Page 10]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Weiler                  Expires November 24, 2005              [Page 11]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt
new file mode 100644
index 000000000000..0953e28b471f
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt
@@ -0,0 +1,672 @@
+
+
+
+Network Working Group                                          S. Weiler
+Internet-Draft                                              SPARTA, Inc.
+Updates: 4033, 4034, 4035, 5155                                D. Blacka
+(if approved)                                             VeriSign, Inc.
+Intended status: Standards Track                       September 5, 2009
+Expires: March 9, 2010
+
+
+         Clarifications and Implementation Notes for DNSSECbis
+                draft-ietf-dnsext-dnssec-bis-updates-09
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on March 9, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   This document is a collection of technical clarifications to the
+
+
+
+Weiler & Blacka           Expires March 9, 2010                 [Page 1]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+   DNSSECbis document set.  It is meant to serve as a resource to
+   implementors as well as a repository of DNSSECbis errata.
+
+
+Table of Contents
+
+   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  3
+     1.1.  Structure of this Document . . . . . . . . . . . . . . . .  3
+     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Important Additions to DNSSSECbis  . . . . . . . . . . . . . .  3
+     2.1.  NSEC3 Support  . . . . . . . . . . . . . . . . . . . . . .  3
+     2.2.  SHA-256 Support  . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Security Concerns  . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Clarifications on Non-Existence Proofs . . . . . . . . . .  4
+     3.2.  Validating Responses to an ANY Query . . . . . . . . . . .  4
+     3.3.  Check for CNAME  . . . . . . . . . . . . . . . . . . . . .  5
+     3.4.  Insecure Delegation Proofs . . . . . . . . . . . . . . . .  5
+   4.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
+     4.1.  Errors in Canonical Form Type Code List  . . . . . . . . .  5
+     4.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
+     4.3.  Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
+     4.4.  Caution About Local Policy and Multiple RRSIGs . . . . . .  7
+     4.5.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
+     4.6.  Setting the DO Bit on Replies  . . . . . . . . . . . . . .  7
+     4.7.  Setting the AD bit on Replies  . . . . . . . . . . . . . .  7
+     4.8.  Setting the CD bit on Requests . . . . . . . . . . . . . .  8
+     4.9.  Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  8
+   5.  Minor Corrections and Clarifications . . . . . . . . . . . . .  8
+     5.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  8
+     5.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  9
+     5.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . .  9
+     5.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . .  9
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
+   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 11
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka           Expires March 9, 2010                 [Page 2]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+1.  Introduction and Terminology
+
+   This document lists some additions, clarifications and corrections to
+   the core DNSSECbis specification, as originally described in
+   [RFC4033], [RFC4034], and [RFC4035].
+
+   It is intended to serve as a resource for implementors and as a
+   repository of items that need to be addressed when advancing the
+   DNSSECbis documents from Proposed Standard to Draft Standard.
+
+1.1.  Structure of this Document
+
+   The clarifications to DNSSECbis are sorted according to their
+   importance, starting with ones which could, if ignored, lead to
+   security problems and progressing down to clarifications that are
+   expected to have little operational impact.
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+2.  Important Additions to DNSSSECbis
+
+   This section updates the set of core DNSSEC protocol documents
+   originally specified in Section 10 of [RFC4033].
+
+2.1.  NSEC3 Support
+
+   [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
+   records for hashed denial of existence.  Validator implementations
+   are strongly encouraged to include support for NSEC3 because a number
+   of highly visible zones are expected to use it.  Validators that do
+   not support validation of responses using NSEC3 will likely be
+   hampered in validating large portions of the DNS space.
+
+   [RFC5155] should be considered part of the DNS Security Document
+   Family as described by [RFC4033], Section 10.
+
+2.2.  SHA-256 Support
+
+   [RFC4509] describes the use of SHA-256 as a digest algorithm for use
+   with Delegation Signer (DS) RRs.  [I-D.ietf-dnsext-dnssec-rsasha256]
+   describes the use of the RSASHA256 algorithm for use in DNSKEY and
+   RRSIG RRs.  Validator implementations are strongly encouraged to
+   include support for this algorithm for DS, DNSKEY, and RRSIG records.
+
+
+
+Weiler & Blacka           Expires March 9, 2010                 [Page 3]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+   Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be
+   considered part of the DNS Security Document Family as described by
+   [RFC4033], Section 10.
+
+
+3.  Security Concerns
+
+   This section provides clarifications that, if overlooked, could lead
+   to security issues.
+
+3.1.  Clarifications on Non-Existence Proofs
+
+   [RFC4035] Section 5.4 under-specifies the algorithm for checking non-
+   existence proofs.  In particular, the algorithm as presented would
+   incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove
+   the non-existence of RRs in the child zone.
+
+   An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
+
+   o  the NS bit set,
+   o  the SOA bit clear, and
+   o  a signer field that is shorter than the owner name of the NSEC RR,
+      or the original owner name for the NSEC3 RR.
+
+   Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non-
+   existence of any RRs below that zone cut, which include all RRs at
+   that (original) owner name other than DS RRs, and all RRs below that
+   owner name regardless of type.
+
+   Similarly, the algorithm would also allow an NSEC RR at the same
+   owner name as a DNAME RR, or an NSEC3 RR at the same original owner
+   name as a DNAME, to prove the non-existence of names beneath that
+   DNAME.  An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
+   to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
+   (original) owner name.
+
+3.2.  Validating Responses to an ANY Query
+
+   [RFC4035] does not address how to validate responses when QTYPE=*.
+   As described in Section 6.2.2 of [RFC1034], a proper response to
+   QTYPE=* may include a subset of the RRsets at a given name.  That is,
+   it is not necessary to include all RRsets at the QNAME in the
+   response.
+
+   When validating a response to QTYPE=*, all received RRsets that match
+   QNAME and QCLASS MUST be validated.  If any of those RRsets fail
+   validation, the answer is considered Bogus.  If there are no RRsets
+   matching QNAME and QCLASS, that fact MUST be validated according to
+
+
+
+Weiler & Blacka           Expires March 9, 2010                 [Page 4]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+   the rules in [RFC4035] Section 5.4 (as clarified in this document).
+   To be clear, a validator must not expect to receive all records at
+   the QNAME in response to QTYPE=*.
+
+3.3.  Check for CNAME
+
+   Section 5 of [RFC4035] says little about validating responses based
+   on (or that should be based on) CNAMEs.  When validating a NOERROR/
+   NODATA response, validators MUST check the CNAME bit in the matching
+   NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
+   type.  Without this check, an attacker could successfully transform a
+   positive CNAME response into a NOERROR/NODATA response.
+
+3.4.  Insecure Delegation Proofs
+
+   [RFC4035] Section 5.2 specifies that a validator, when proving a
+   delegation is not secure, needs to check for the absence of the DS
+   and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
+   needs to check for the presence of the NS bit in the matching NSEC
+   (or NSEC3) RR (proving that there is, indeed, a delegation), or
+   alternately make sure that the delegation is covered by an NSEC3 RR
+   with the Opt-Out flag set.  If this is not checked, spoofed unsigned
+   delegations might be used to claim that an existing signed record is
+   not signed.
+
+
+4.  Interoperability Concerns
+
+4.1.  Errors in Canonical Form Type Code List
+
+   When canonicalizing DNS names, DNS names in the RDATA section of NSEC
+   and RRSIG resource records are not downcased.
+
+   [RFC4034] Section 6.2 item 3 has a list of resource record types for
+   which DNS names in the RDATA are downcased for purposes of DNSSEC
+   canonical form (for both ordering and signing).  That list
+   erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS
+   names in the RDATA of NSEC and RRSIG should not be downcased.
+
+   The same section also erroneously lists HINFO, and twice at that.
+   Since HINFO records contain no domain names, they are not subject to
+   downcasing.
+
+4.2.  Unknown DS Message Digest Algorithms
+
+   Section 5.2 of [RFC4035] includes rules for how to handle delegations
+   to zones that are signed with entirely unsupported public key
+   algorithms, as indicated by the key algorithms shown in those zone's
+
+
+
+Weiler & Blacka           Expires March 9, 2010                 [Page 5]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+   DS RRsets.  It does not explicitly address how to handle DS records
+   that use unsupported message digest algorithms.  In brief, DS records
+   using unknown or unsupported message digest algorithms MUST be
+   treated the same way as DS records referring to DNSKEY RRs of unknown
+   or unsupported public key algorithms.
+
+   The existing text says:
+
+      If the validator does not support any of the algorithms listed in
+      an authenticated DS RRset, then the resolver has no supported
+      authentication path leading from the parent to the child.  The
+      resolver should treat this case as it would the case of an
+      authenticated NSEC RRset proving that no DS RRset exists, as
+      described above.
+
+   To paraphrase the above, when determining the security status of a
+   zone, a validator disregards any DS records listing unknown or
+   unsupported algorithms.  If none are left, the zone is treated as if
+   it were unsigned.
+
+   Modified to consider DS message digest algorithms, a validator also
+   disregards any DS records using unknown or unsupported message digest
+   algorithms.
+
+4.3.  Private Algorithms
+
+   As discussed above, section 5.2 of [RFC4035] requires that validators
+   make decisions about the security status of zones based on the public
+   key algorithms shown in the DS records for those zones.  In the case
+   of private algorithms, as described in [RFC4034] Appendix A.1.1, the
+   eight-bit algorithm field in the DS RR is not conclusive about what
+   algorithm(s) is actually in use.
+
+   If no private algorithms appear in the DS set or if any supported
+   algorithm appears in the DS set, no special processing will be
+   needed.  In the remaining cases, the security status of the zone
+   depends on whether or not the resolver supports any of the private
+   algorithms in use (provided that these DS records use supported hash
+   functions, as discussed in Section 4.2).  In these cases, the
+   resolver MUST retrieve the corresponding DNSKEY for each private
+   algorithm DS record and examine the public key field to determine the
+   algorithm in use.  The security-aware resolver MUST ensure that the
+   hash of the DNSKEY RR's owner name and RDATA matches the digest in
+   the DS RR.  If they do not match, and no other DS establishes that
+   the zone is secure, the referral should be considered Bogus data, as
+   discussed in [RFC4035].
+
+   This clarification facilitates the broader use of private algorithms,
+
+
+
+Weiler & Blacka           Expires March 9, 2010                 [Page 6]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+   as suggested by [RFC4955].
+
+4.4.  Caution About Local Policy and Multiple RRSIGs
+
+   When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
+   suggests that "the local resolver security policy determines whether
+   the resolver also has to test these RRSIG RRs and how to resolve
+   conflicts if these RRSIG RRs lead to differing results."  In most
+   cases, a resolver would be well advised to accept any valid RRSIG as
+   sufficient.  If the first RRSIG tested fails validation, a resolver
+   would be well advised to try others, giving a successful validation
+   result if any can be validated and giving a failure only if all
+   RRSIGs fail validation.
+
+   If a resolver adopts a more restrictive policy, there's a danger that
+   properly-signed data might unnecessarily fail validation, perhaps
+   because of cache timing issues.  Furthermore, certain zone management
+   techniques, like the Double Signature Zone-signing Key Rollover
+   method described in section 4.2.1.2 of [RFC4641] might not work
+   reliably.
+
+4.5.  Key Tag Calculation
+
+   [RFC4034] Appendix B.1 incorrectly defines the Key Tag field
+   calculation for algorithm 1.  It correctly says that the Key Tag is
+   the most significant 16 of the least significant 24 bits of the
+   public key modulus.  However, [RFC4034] then goes on to incorrectly
+   say that this is 4th to last and 3rd to last octets of the public key
+   modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
+
+4.6.  Setting the DO Bit on Replies
+
+   [RFC4035] does not provide any instructions to servers as to how to
+   set the DO bit.  Some authoritative server implementations have
+   chosen to copy the DO bit settings from the incoming query to the
+   outgoing response.  Others have chosen to never set the DO bit in
+   responses.  Either behavior is permitted.  To be clear, in replies to
+   queries with the DO-bit set servers may or may not set the DO bit.
+
+4.7.  Setting the AD bit on Replies
+
+   Section 3.2.3 of [RFC4035] describes under which conditions a
+   validating resolver should set or clear the AD bit in a response.  In
+   order to protect legacy stub resolvers and middleboxes, validating
+   resolvers SHOULD only set the AD bit when a response both meets the
+   conditions listed in RFC 4035, section 3.2.3, and the request
+   contained either a set DO bit or a set AD bit.
+
+
+
+
+Weiler & Blacka           Expires March 9, 2010                 [Page 7]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+   Note that the use of the AD bit in the query was previously
+   undefined.  This document defines it as a signal indicating that the
+   requester understands and is interested in the value of the AD bit in
+   the response.  This allows a requestor to indicate that it
+   understands the AD bit without also requesting DNSSEC data via the DO
+   bit.
+
+4.8.  Setting the CD bit on Requests
+
+   When processing a request with the CD bit set, the resolver MUST set
+   the CD bit on its upstream queries.
+
+4.9.  Nested Trust Anchors
+
+   A DNSSEC validator may be configured such that, for a given response,
+   more than one trust anchor could be used to validate the chain of
+   trust to the response zone.  For example, imagine a validator
+   configured with trust anchors for "example." and "zone.example."
+   When the validator is asked to validate a response to
+   "www.sub.zone.example.", either trust anchor could apply.
+
+   When presented with this situation, DNSSEC validators SHOULD try all
+   applicable trust anchors until one succeeds.
+
+   There are some scenarios where different behaviors, such as choosing
+   the trust anchor closest to the QNAME of the response, may be
+   desired.  A DNSSEC validator MAY enable such behaviors as
+   configurable overrides.
+
+
+5.  Minor Corrections and Clarifications
+
+5.1.  Finding Zone Cuts
+
+   Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
+   for a parent zone.  To do that, a resolver may first need to apply
+   special rules to discover what those servers are.
+
+   As explained in Section 3.1.4.1 of [RFC4035], security-aware name
+   servers need to apply special processing rules to handle the DS RR,
+   and in some situations the resolver may also need to apply special
+   rules to locate the name servers for the parent zone if the resolver
+   does not already have the parent's NS RRset.  Section 4.2 of
+   [RFC4035] specifies a mechanism for doing that.
+
+
+
+
+
+
+
+Weiler & Blacka           Expires March 9, 2010                 [Page 8]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+5.2.  Clarifications on DNSKEY Usage
+
+   Questions of the form "can I use a different DNSKEY for signing this
+   RRset" have occasionally arisen.
+
+   The short answer is "yes, absolutely".  You can even use a different
+   DNSKEY for each RRset in a zone, subject only to practical limits on
+   the size of the DNSKEY RRset.  However, be aware that there is no way
+   to tell resolvers what a particularly DNSKEY is supposed to be used
+   for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
+   authenticate any RRset in the zone.  For example, if a weaker or less
+   trusted DNSKEY is being used to authenticate NSEC RRsets or all
+   dynamically updated records, that same DNSKEY can also be used to
+   sign any other RRsets from the zone.
+
+   Furthermore, note that the SEP bit setting has no effect on how a
+   DNSKEY may be used -- the validation process is specifically
+   prohibited from using that bit by [RFC4034] section 2.1.2.  It is
+   possible to use a DNSKEY without the SEP bit set as the sole secure
+   entry point to the zone, yet use a DNSKEY with the SEP bit set to
+   sign all RRsets in the zone (other than the DNSKEY RRset).  It's also
+   possible to use a single DNSKEY, with or without the SEP bit set, to
+   sign the entire zone, including the DNSKEY RRset itself.
+
+5.3.  Errors in Examples
+
+   The text in [RFC4035] Section C.1 refers to the examples in B.1 as
+   "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
+   obvious in the second paragraph where it states that the RRSIG labels
+   field value of 3 indicates that the answer was not the result of
+   wildcard expansion.  This is true for "x.w.example" but not for
+   "x.w.example.com", which of course has a label count of 4
+   (antithetically, a label count of 3 would imply the answer was the
+   result of a wildcard expansion).
+
+   The first paragraph of [RFC4035] Section C.6 also has a minor error:
+   the reference to "a.z.w.w.example" should instead be "a.z.w.example",
+   as in the previous line.
+
+5.4.  Errors in RFC 5155
+
+   A NSEC3 record that matches an Empty Non-Terminal effectively has no
+   type associated with it.  This NSEC3 record has an empty type bit
+   map.  Section 3.2.1 of [RFC5155] contains the statement:
+
+      Blocks with no types present MUST NOT be included.
+
+   However, the same section contains a regular expression:
+
+
+
+Weiler & Blacka           Expires March 9, 2010                 [Page 9]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+   The plus sign in the regular expression indicates that there is one
+   or more of the preceding element.  This means that there must be at
+   least one window block.  If this window block has no types, it
+   contradicts with the first statement.  Therefore, the correct text in
+   RFC 5155 3.2.1 should be:
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
+
+
+6.  IANA Considerations
+
+   This document specifies no IANA Actions.
+
+
+7.  Security Considerations
+
+   This document adds two cryptographic features to the core DNSSEC
+   protocol.  Additionally, it addresses some ambiguities and omissions
+   in the core DNSSEC documents that, if not recognized and addressed in
+   implementations, could lead to security failures.  In particular, the
+   validation algorithm clarifications in Section 3 are critical for
+   preserving the security properties DNSSEC offers.  Furthermore,
+   failure to address some of the interoperability concerns in Section 4
+   could limit the ability to later change or expand DNSSEC, including
+   adding new algorithms.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [I-D.ietf-dnsext-dnssec-rsasha256]
+              Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
+              and RRSIG Resource Records for DNSSEC",
+              draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress),
+              June 2009.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              RFC 1034, STD 13, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+
+
+Weiler & Blacka           Expires March 9, 2010                [Page 10]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+   [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.
+
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+8.2.  Informative References
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+              RFC 4641, September 2006.
+
+   [RFC4955]  Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
+              July 2007.
+
+
+Appendix A.  Acknowledgments
+
+   The editors would like the thank Rob Austein for his previous work as
+   an editor of this document.
+
+   The editors are extremely grateful to those who, in addition to
+   finding errors and omissions in the DNSSECbis document set, have
+   provided text suitable for inclusion in this document.
+
+   The lack of specificity about handling private algorithms, as
+   described in Section 4.3, and the lack of specificity in handling ANY
+   queries, as described in Section 3.2, were discovered by David
+   Blacka.
+
+   The error in algorithm 1 key tag calculation, as described in
+   Section 4.5, was found by Abhijit Hayatnagarkar.  Donald Eastlake
+   contributed text for Section 4.5.
+
+   The bug relating to delegation NSEC RR's in Section 3.1 was found by
+   Roy Badami.  Roy Arends found the related problem with DNAME.
+
+
+
+
+Weiler & Blacka           Expires March 9, 2010                [Page 11]
+
+Internet-Draft       DNSSECbis Implementation Notes       September 2009
+
+
+   The errors in the [RFC4035] examples were found by Roy Arends, who
+   also contributed text for Section 5.3 of this document.
+
+   The editors would like to thank Ed Lewis, Danny Mayer, Olafur
+   Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive
+   comments on the text of this document.
+
+
+Authors' Addresses
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7110 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   Email: weiler@tislabs.com
+
+
+   David Blacka
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Email: davidb@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka           Expires March 9, 2010                [Page 12]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
deleted file mode 100644
index ee03583a1306..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-DNSEXT                                                         D. Blacka
-Internet-Draft                                            Verisign, Inc.
-Expires: January 19, 2006                                  July 18, 2005
-
-
-                           DNSSEC Experiments
-                draft-ietf-dnsext-dnssec-experiments-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   In the long history of the development of the DNS security extensions
-   [1] (DNSSEC), a number of alternate methodologies and modifications
-   have been proposed and rejected for practical, rather than strictly
-   technical, reasons.  There is a desire to be able to experiment with
-   these alternate methods in the public DNS.  This document describes a
-   methodology for deploying alternate, non-backwards-compatible, DNSSEC
-   methodologies in an experimental fashion without disrupting the
-   deployment of standard DNSSEC.
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 1]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-Table of Contents
-
-   1.   Definitions and Terminology  . . . . . . . . . . . . . . . .   3
-   2.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   4
-   3.   Experiments  . . . . . . . . . . . . . . . . . . . . . . . .   5
-   4.   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
-   5.   Defining an Experiment . . . . . . . . . . . . . . . . . . .   8
-   6.   Considerations . . . . . . . . . . . . . . . . . . . . . . .   9
-   7.   Transitions  . . . . . . . . . . . . . . . . . . . . . . . .  10
-   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  11
-   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  12
-   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
-     10.1   Normative References . . . . . . . . . . . . . . . . . .  13
-     10.2   Informative References . . . . . . . . . . . . . . . . .  13
-        Author's Address . . . . . . . . . . . . . . . . . . . . . .  13
-        Intellectual Property and Copyright Statements . . . . . . .  14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 2]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-1.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [4]) and the DNS security extensions ([1], [2], and [3].
-
-   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 3]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-2.  Overview
-
-   Historically, experimentation with DNSSEC alternatives has been a
-   problematic endeavor.  There has typically been a desire to both
-   introduce non-backwards-compatible changes to DNSSEC, and to try
-   these changes on real zones in the public DNS.  This creates a
-   problem when the change to DNSSEC would make all or part of the zone
-   using those changes appear bogus (bad) or otherwise broken to
-   existing DNSSEC-aware resolvers.
-
-   This document describes a standard methodology for setting up public
-   DNSSEC experiments.  This methodology addresses the issue of co-
-   existence with standard DNSSEC and DNS by using unknown algorithm
-   identifiers to hide the experimental DNSSEC protocol modifications
-   from standard DNSSEC-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 4]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-3.  Experiments
-
-   When discussing DNSSEC experiments, it is necessary to classify these
-   experiments into two broad categories:
-
-   Backwards-Compatible: describes experimental changes that, while not
-      strictly adhering to the DNSSEC standard, are nonetheless
-      interoperable with clients and server that do implement the DNSSEC
-      standard.
-
-   Non-Backwards-Compatible: describes experiments that would cause a
-      standard DNSSEC-aware resolver to (incorrectly) determine that all
-      or part of a zone is bogus, or to otherwise not interoperable with
-      standard DNSSEC clients and servers.
-
-   Not included in these terms are experiments with the core DNS
-   protocol itself.
-
-   The methodology described in this document is not necessary for
-   backwards-compatible experiments, although it certainly could be used
-   if desired.
-
-   Note that, in essence, this metholodolgy would also be used to
-   introduce a new DNSSEC algorithm, independently from any DNSSEC
-   experimental protocol change.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 5]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-4.  Method
-
-   The core of the methodology is the use of strictly "unknown"
-   algorithms to sign the experimental zone, and more importantly,
-   having only unknown algorithm DS records for the delegation to the
-   zone at the parent.
-
-   This technique works because of the way DNSSEC-compliant validators
-   are expected to work in the presence of a DS set with only unknown
-   algorithms.  From [3], Section 5.2:
-
-      If the validator does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver has no supported
-      authentication path leading from the parent to the child.  The
-      resolver should treat this case as it would the case of an
-      authenticated NSEC RRset proving that no DS RRset exists, as
-      described above.
-
-   And further:
-
-      If the resolver does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver will not be able to
-      verify the authentication path to the child zone.  In this case,
-      the resolver SHOULD treat the child zone as if it were unsigned.
-
-   While this behavior isn't strictly mandatory (as marked by MUST), it
-   is unlikely that a validator would not implement the behavior, or,
-   more to the point, it will not violate this behavior in an unsafe way
-   (see below (Section 6).)
-
-   Because we are talking about experiments, it is RECOMMENDED that
-   private algorithm numbers be used (see [2], appendix A.1.1.  Note
-   that secure handling of private algorithms requires special handing
-   by the validator logic.  See [6] for futher details.)  Normally,
-   instead of actually inventing new signing algorithms, the recommended
-   path is to create alternate algorithm identifiers that are aliases
-   for the existing, known algorithms.  While, strictly speaking, it is
-   only necessary to create an alternate identifier for the mandatory
-   algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be
-   aliased as well.
-
-   It is RECOMMENDED that for a particular DNSSEC experiment, a
-   particular domain name base is chosen for all new algorithms, then
-   the algorithm number (or name) is prepended to it.  For example, for
-   experiment A, the base name of "dnssec-experiment-a.example.com" is
-   chosen.  Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
-   defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-
-   experiment-a.example.com".  However, any unique identifier will
-
-
-
-Blacka                  Expires January 19, 2006                [Page 6]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-   suffice.
-
-   Using this method, resolvers (or, more specificially, DNSSEC
-   validators) essentially indicate their ability to understand the
-   DNSSEC experiment's semantics by understanding what the new algorithm
-   identifiers signify.
-
-   This method creates two classes of DNSSEC-aware servers and
-   resolvers: servers and resolvers that are aware of the experiment
-   (and thus recognize the experiments algorithm identifiers and
-   experimental semantics), and servers and resolvers that are unware of
-   the experiment.
-
-   This method also precludes any zone from being both in an experiment
-   and in a classic DNSSEC island of security.  That is, a zone is
-   either in an experiment and only experimentally validatable, or it
-   isn't.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 7]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-5.  Defining an Experiment
-
-   The DNSSEC experiment must define the particular set of (previously
-   unknown) algorithms that identify the experiment, and define what
-   each unknown algorithm identifier means.  Typically, unless the
-   experiment is actually experimenting with a new DNSSEC algorithm,
-   this will be a mapping of private algorithm identifiers to existing,
-   known algorithms.
-
-   Normally the experiment will choose a DNS name as the algorithm
-   identifier base.  This DNS name SHOULD be under the control of the
-   authors of the experiment.  Then the experiment will define a mapping
-   between known mandatory and optional algorithms into this private
-   algorithm identifier space.  Alternately, the experiment MAY use the
-   OID private algorithm space instead (using algorithm number 254), or
-   may choose non-private algorithm numbers, although this would require
-   an IANA allocation (see below (Section 9).)
-
-   For example, an experiment might specify in its description the DNS
-   name "dnssec-experiment-a.example.com" as the base name, and provide
-   the mapping of "3.dnssec-experiment-a.example.com" is an alias of
-   DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
-   an alias of DNSSEC algorithm 5 (RSASHA1).
-
-   Resolvers MUST then only recognize the experiment's semantics when
-   present in a zone signed by one or more of these private algorithms.
-
-   In general, however, resolvers involved in the experiment are
-   expected to understand both standard DNSSEC and the defined
-   experimental DNSSEC protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 8]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-6.  Considerations
-
-   There are a number of considerations with using this methodology.
-
-   1.  Under some circumstances, it may be that the experiment will not
-       be sufficiently masked by this technique and may cause resolution
-       problem for resolvers not aware of the experiment.  For instance,
-       the resolver may look at the not validatable response and
-       conclude that the response is bogus, either due to local policy
-       or implementation details.  This is not expected to be the common
-       case, however.
-
-   2.  In general, it will not be possible for DNSSEC-aware resolvers
-       not aware of the experiment to build a chain of trust through an
-       experimental zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 9]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-7.  Transitions
-
-   If an experiment is successful, there may be a desire to move the
-   experiment to a standards-track extension.  One way to do so would be
-   to move from private algorithm numbers to IANA allocated algorithm
-   numbers, with otherwise the same meaning.  This would still leave a
-   divide between resolvers that understood the extension versus
-   resolvers that did not.  It would, in essence, create an additional
-   version of DNSSEC.
-
-   An alternate technique might be to do a typecode rollover, thus
-   actually creating a definitive new version of DNSSEC.  There may be
-   other transition techniques available, as well.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 10]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-8.  Security Considerations
-
-   Zones using this methodology will be considered insecure by all
-   resolvers except those aware of the experiment.  It is not generally
-   possible to create a secure delegation from an experimental zone that
-   will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 11]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-9.  IANA Considerations
-
-   IANA may need to allocate new DNSSEC algorithm numbers if that
-   transition approach is taken, or the experiment decides to use
-   allocated numbers to begin with.  No IANA action is required to
-   deploy an experiment using private algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 12]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-10.  References
-
-10.1  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-10.2  Informative References
-
-   [4]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [6]  Weiler, S., "Clarifications and Implementation Notes for
-        DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
-        progress), March 2005.
-
-
-Author's Address
-
-   David Blacka
-   Verisign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: davidb@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 13]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 14]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt
new file mode 100644
index 000000000000..152d96efaca6
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt
@@ -0,0 +1,448 @@
+DNS Extensions working group                             V.Dolmatov, Ed.  
+Internet-Draft                                            Cryptocom Ltd.    
+Intended status: Standards Track                      November 30, 2009
+Expires: May 30, 2010                                 
+
+
+ Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
+                               for DNSSEC
+                 draft-ietf-dnsext-dnssec-gost-05
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 May  10 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   This document describes how to produce signature and hash using 
+   GOST algorithms [DRAFT1, DRAFT2, DRAFT3] for DNSKEY, RRSIG and DS
+   resource records for use in the Domain Name System Security 
+   Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
+
+V.Dolmatov              Expires May  30, 2010               [Page 1]
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
+     2.1.  Using a public key with existing cryptographic libraries. . 3
+     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 3
+   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
+     3.1 RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . . 4
+   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
+     4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5
+   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
+     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
+     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 5
+     6.1.  Support for GOST signatures . . . . . . . . . . . . . . . . 5
+     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
+     6.3.  Byte order  . . . . . . . . . . . . . . . . . . . . . . . . 5
+   7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+   10.  References   . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
+     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical distributed
+   database for Internet Naming.  The DNS has been extended to use
+   cryptographic keys and digital signatures for the verification of the
+   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
+   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
+   Extensions, called DNSSEC.
+
+   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
+   and specifies a list of cryptographic algorithms to use.  This
+   document extends that list with the signature and hash algorithms 
+   GOST [GOST3410, GOST3411],
+   and specifies how to store DNSKEY data and how to produce
+   RRSIG resource records with these hash algorithms.
+
+   Familiarity with DNSSEC  and GOST signature and hash
+   algorithms is assumed in this document.
+
+   The term "GOST" is not officially defined, but is usually used to
+   refer to the collection of the Russian cryptographic algorithms
+   GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. 
+   Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to
+   the GOST R 34.10-2001 and GOST R 34.11-94 in this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+V.Dolmatov              Expires May  30, 2010                [Page 2]
+
+2.  DNSKEY Resource Records
+
+   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
+
+   GOST R 34.10-2001 public keys are stored with the algorithm number 
+   {TBA1}.
+      
+   The wire format of the public key is compatible with 
+   RFC 4491 [RFC4491]:
+
+   According to [GOST3410], a public key is a point on the elliptic
+   curve Q = (x,y).
+
+   The wire representation of a public key MUST contain 66 octets, 
+   where the first octet designates public key parameters, the second
+   octet designates digest parameters next 32 octets contain the 
+   little-endian representation of x and the second 32 octets contain
+   the little-endian representation of y. 
+   This corresponds to the binary representation of (256||256) 
+   from [GOST3410], ch.  5.3.
+
+   The only valid value for both parameters octets is 0.
+   Other parameters octets values are reserved for future use.
+   
+   Corresponding public key parameters are those identified by
+   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
+   and the digest parameters are those identified by
+   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
+
+2.1.  Using a public key with existing cryptographic libraries
+
+   Existing GOST-aware cryptographic libraries at the time of this 
+   document writing are capable to read GOST public keys via a generic
+   X509 API if the key is encoded according to RFC 4491 [RFC4491],
+   section 2.3.2.
+
+   To make this encoding from the wire format of a GOST public key 
+   with the parameters used in this document, prepend the last 64 octets
+   of key data (in other words, substitute first two parameter octets)
+   with the following 37-byte sequence:
+
+   0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 
+   0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
+   0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
+  
+2.2.  GOST DNSKEY RR Example
+
+   Given a private key with the following value (the value of GostAsn1
+   field is split here into two lines to simplify reading; in the 
+   private key file it must be in one line):
+
+   Private-key-format: v1.2
+   Algorithm: {TBA1} (GOST)
+   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S
+             2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E=
+
+V.Dolmatov              Expires May  30, 2010                [Page 3]
+
+   The following DNSKEY RR stores a DNS zone key for example.net
+ 
+   example.net. 86400 IN DNSKEY 256 3 {TBA1} (
+                                AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq
+                                tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6
+                                yB7i836EfzmJo5LP
+                                ) ; key id = 15820
+
+3.  RRSIG Resource Records
+
+   The value of the signature field in the RRSIG RR follows RFC 4490
+   [RFC4490] and is calculated as follows.  The values for the RDATA 
+   fields that precede the signature data are specified 
+   in RFC 4034 [RFC4034].
+
+   hash = GOSTR3411(data)
+
+   where "data" is the wire format data of the resource record set 
+   that is signed, as specified in RFC 4034 [RFC4034].
+   
+   Hash MUST be calculated with GOST R 34.11-94 parameters identified
+   by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+   Signature is calculated from the hash according to the 
+   GOST R 34.10-2001 standard and its wire format is compatible with 
+   RFC 4490 [RFC4490].
+
+   Quoting RFC 4490:
+
+   "The signature algorithm GOST R 34.10-2001 generates a digital
+   signature in the form of two 256-bit numbers, r and s.  Its octet
+   string representation consists of 64 octets, where the first 32
+   octets contain the big-endian representation of s and the second 32
+   octets contain the big-endian representation of r."
+
+3.1. RRSIG RR Example
+
+   With the private key from section 2.2 sign the following RRSet, 
+   consisting of one A record:
+
+   www.example.net. 3600 IN A 192.0.2.1
+
+   Setting the inception date to 2000-01-01 00:00:00 UTC and the 
+   expiration date to 2030-01-01 00:00:00 UTC, the following signature
+   should be created (assuming {TBA1}==249 until proper code is 
+   assigned by IANA)
+
+   www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
+                                  20000101000000 15820 example.net.
+                                  2MIsZWtEx6pcfQrdl376B8sFg0qxsR8XMHpl
+                                  jHh+V6U7Qte7WwI4C3Z1nFMRVf//C9rO2dGB
+                                  rdp+C7wVoOHBqA== )
+ 
+V.Dolmatov              Expires May  30, 2010                [Page 4]
+
+  Note: Several GOST signatures calculated for the same message text 
+   differ because of using of a random element is used in signature 
+   generation process.
+
+4.  DS Resource Records
+
+   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
+   type {TBA2}.The wire format of a digest value is compatible with 
+   RFC4490 [RFC4490], that is digest is in little-endian representation. 
+
+
+   The digest MUST always be calculated with GOST R 34.11-94 parameters
+   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+4.1. DS RR Example
+
+   For key signing key (assuming {TBA1}==249 until proper code is 
+   assigned by IANA)
+
+   example.net. 86400   DNSKEY  257 3 {TBA1} (
+                                AAADr5vmKVdXo780hSRU1YZYWuMZUbEe9R7C
+                                RRLc7Wj2osDXv2XbCnIpTUx8dVLnLKmDBquu
+                                9tCz5oSsZl0cL0R2
+                                ) ; key id = 21649
+
+   The DS RR will be
+
+   example.net. 3600 IN DS 21649 {TBA1} {TBA2} (
+             A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A
+             A44649C6 )
+
+5.  Deployment Considerations
+
+5.1.  Key Sizes
+
+   According to RFC4357 [RFC4357], the key size of GOST public keys
+   MUST be 512 bits.
+
+5.2.  Signature Sizes
+
+   According to the GOST signature algorithm specification [GOST3410],
+   the size of a GOST signature is 512 bits.
+
+5.3.  Digest Sizes
+
+   According to the GOST R 34.11-94 [GOST3411], the size of a GOST 
+   digest is 256 bits.
+
+6.  Implementation Considerations
+
+6.1.  Support for GOST signatures
+
+   DNSSEC aware implementations SHOULD be able to support RRSIG and
+   DNSKEY resource records created with the GOST algorithms as
+   defined in this document.
+
+V.Dolmatov              Expires May  30, 2010                [Page 5]
+
+6.2.  Support for NSEC3 Denial of Existence
+
+    Any DNSSEC-GOST implementation is required to have either NSEC or
+    NSEC3 support.
+
+6.3  Byte order
+
+    Due to the fact that all existing industry implementations of GOST
+    cryptographic libraries are returning GOST blobs in little-endian 
+    format and in order to avoid the necessity for DNSSEC developers 
+    to handle different cryptographic algorithms differently, it was
+    chosen to send these blobs on the wire "as is" without 
+    transformation of endianness.
+
+7.  Security considerations
+
+    Currently, the cryptographic resistance of the GOST 34.10-2001 
+    digital signature algorithm is estimated as 2**128 operations
+    of multiple elliptic curve point computations on prime modulus
+    of order 2**256.
+
+
+    Currently, the cryptographic resistance of GOST 34.11-94 hash
+    algorithm is estimated as 2**128 operations of computations of a
+    step hash function. (There is known method to reduce this 
+    estimate to 2**105 operations, but it demands padding the 
+    colliding message with 1024 random bit blocks each of 256 bit
+    length, thus it cannot be used in any practical implementation).
+
+8.  IANA Considerations
+
+   This document updates the IANA registry "DNS Security Algorithm 
+   Numbers [RFC4034]"
+   (http://www.iana.org/assignments/dns-sec-alg-numbers).  
+   The following entries are added to the registry:
+                                     Zone    Trans.
+   Value  Algorithm         Mnemonic Signing Sec.  References   Status
+   {TBA1} GOST R 34.10-2001 GOST     Y       *     (this memo)  OPTIONAL
+
+   This document updates the RFC 4034 Digest Types assignment
+   (section A.2)by adding the value and status for the GOST R 34.11-94
+   algorithm:
+
+   Value   Algorithm        Status
+   {TBA2}  GOST R 34.11-94  OPTIONAL
+
+9. Acknowledgments
+
+   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
+   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
+   and RFC 4357 [RFC4357] for consistency. The authors of and 
+   contributors to these documents are gratefully acknowledged for 
+   their hard work.
+
+V.Dolmatov              Expires May  30, 2010                [Page 6]
+
+   The following people provided additional feedback and text: Dmitry 
+   Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 
+   and Wouter Wijngaards.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, March 1997.
+
+   [RFC3110]  Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+              Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC4033]  Arends R., Austein R., Larson M., Massey D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends R., Austein R., Larson M., Massey D., and S.
+              Rose, "Resource Records for 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.
+
+   [GOST3410] "Information technology.  Cryptographic data security.
+              Signature and verification processes of [electronic]
+              digital signature.", GOST R 34.10-2001, Gosudarstvennyi
+              Standard of Russian Federation, Government Committee of
+              the Russia for Standards, 2001.  (In Russian)
+
+   [GOST3411] "Information technology.  Cryptographic Data Security.
+              Hashing function.", GOST R 34.11-94, Gosudarstvennyi
+              Standard of Russian Federation, Government Committee of
+              the Russia for Standards, 1994.  (In Russian)
+
+   [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional
+             Cryptographic Algorithms for Use with GOST 28147-89,
+             GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+             Algorithms", RFC 4357, January 2006.
+
+   [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 
+             GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 
+             Algorithms with Cryptographic Message Syntax (CMS)",
+             RFC 4490, May 2006.
+
+   [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 
+             R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 
+             Algorithms with the Internet X.509 Public Key 
+             Infrastructure Certificate and CRL Profile", RFC 4491,
+             May 2006. 
+
+V.Dolmatov              Expires May  30, 2010               [Page 7]
+
+
+10.2.  Informative References
+
+   [RFC4509]  Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [DRAFT1]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
+              "GOST R 34.10-2001 digital signature algorithm"
+              draft-dolmatov-cryptocom-gost34102001-06, 11.10.09
+              work in progress.
+
+
+   [DRAFT2]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
+              "GOST R 34.11-94 Hash function algorithm"
+              draft-dolmatov-cryptocom-gost341194-04, 11.10.09
+              work in progress.
+
+   [DRAFT3]   Dolmatov V., Kabelev D., Ustinov I., Emelyanova I.,
+              "GOST 28147-89 encryption, decryption and MAC algorithms"
+              draft-dolmatov-cryptocom-gost2814789-04, 11.10.09
+              work in progress.
+
+V.Dolmatov              Expires May  30, 2010                [Page 8]
+
+
+Authors' Addresses
+
+
+Vasily Dolmatov, Ed.
+Cryptocom Ltd.
+Kedrova 14, bld.2
+Moscow, 117218, Russian Federation
+
+EMail: dol@cryptocom.ru
+
+Artem Chuprina
+Cryptocom Ltd.
+Kedrova 14, bld.2
+Moscow, 117218, Russian Federation
+
+EMail: ran@cryptocom.ru
+
+Igor Ustinov
+Cryptocom Ltd.
+Kedrova 14, bld.2
+Moscow, 117218, Russian Federation
+
+EMail: igus@cryptocom.ru
+
+V.Dolmatov              Expires May  30, 2010                [Page 9]
+
+
+
+
+
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 7503c66ab318..000000000000
--- 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-dnssec-opt-in-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
deleted file mode 100644
index 17e28e8286e2..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-DNSEXT                                                         R. Arends
-Internet-Draft                                      Telematica Instituut
-Expires: January 19, 2006                                     M. Kosters
-                                                               D. Blacka
-                                                          Verisign, Inc.
-                                                           July 18, 2005
-
-
-                             DNSSEC Opt-In
-                   draft-ietf-dnsext-dnssec-opt-in-07
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
-   4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
-   cryptographically secured.  Maintaining this cryptography is not
-   practical or necessary.  This document describes an experimental
-   "Opt-In" model that allows administrators to omit this cryptography
-   and manage the cost of adopting DNSSEC with large zones.
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 1]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-Table of Contents
-
-   1.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
-   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
-   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  4
-     4.1   Server Considerations  . . . . . . . . . . . . . . . . . .  5
-       4.1.1   Delegations Only . . . . . . . . . . . . . . . . . . .  5
-       4.1.2   Insecure Delegation Responses  . . . . . . . . . . . .  6
-       4.1.3   Wildcards and Opt-In . . . . . . . . . . . . . . . . .  6
-       4.1.4   Dynamic Update . . . . . . . . . . . . . . . . . . . .  7
-     4.2   Client Considerations  . . . . . . . . . . . . . . . . . .  7
-       4.2.1   Delegations Only . . . . . . . . . . . . . . . . . . .  7
-       4.2.2   Validation Process Changes . . . . . . . . . . . . . .  7
-       4.2.3   NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
-       4.2.4   Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
-   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 10
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 12
-   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     11.1  Normative References . . . . . . . . . . . . . . . . . . . 13
-     11.2  Informative References . . . . . . . . . . . . . . . . . . 13
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
-   A.  Implementing Opt-In using "Views"  . . . . . . . . . . . . . . 14
-       Intellectual Property and Copyright Statements . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 2]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-1.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [1]), DNS security extensions ([3], [4], and [5], referred to in this
-   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
-   [10]) is assumed.
-
-   The following abbreviations and terms are used in this document:
-
-   RR: is used to refer to a DNS resource record.
-   RRset: refers to a Resource Record Set, as defined by [8].  In this
-      document, the RRset is also defined to include the covering RRSIG
-      records, if any exist.
-   signed name: refers to a DNS name that has, at minimum, a (signed)
-      NSEC record.
-   unsigned name: refers to a DNS name that does not (at least) have a
-      NSEC record.
-   covering NSEC record/RRset: is the NSEC record used to prove
-      (non)existence of a particular name or RRset.  This means that for
-      a RRset or name 'N', the covering NSEC record has the name 'N', or
-      has an owner name less than 'N' and "next" name greater than 'N'.
-   delegation: refers to a NS RRset with a name different from the
-      current zone apex (non-zone-apex), signifying a delegation to a
-      subzone.
-   secure delegation: refers to a signed name containing a delegation
-      (NS RRset), and a signed DS RRset, signifying a delegation to a
-      signed subzone.
-   insecure delegation: refers to a signed name containing a delegation
-      (NS RRset), but lacking a DS RRset, signifying a delegation to an
-      unsigned subzone.
-   Opt-In insecure delegation: refers to an unsigned name containing
-      only a delegation NS RRset.  The covering NSEC record uses the
-      Opt-In methodology described in this document.
-
-   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [7].
-
-2.  Overview
-
-   The cost to cryptographically secure delegations to unsigned zones is
-   high for large delegation-centric zones and zones where insecure
-   delegations will be updated rapidly.  For these zones, the costs of
-   maintaining the NSEC record chain may be extremely high relative to
-   the gain of cryptographically authenticating existence of unsecured
-   zones.
-
-   This document describes an experimental method of eliminating the
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 3]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   superfluous cryptography present in secure delegations to unsigned
-   zones.  Using "Opt-In", a zone administrator can choose to remove
-   insecure delegations from the NSEC chain.  This is accomplished by
-   extending the semantics of the NSEC record by using a redundant bit
-   in the type map.
-
-3.  Experimental Status
-
-   This document describes an EXPERIMENTAL extension to DNSSEC.  It
-   interoperates with non-experimental DNSSEC using the technique
-   described in [6].  This experiment is identified with the following
-   private algorithms (using algorithm 253):
-
-   "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
-      and
-   "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
-      RSASHA1.
-
-   Servers wishing to sign and serve zones that utilize Opt-In MUST sign
-   the zone with only one or more of these private algorithms.  This
-   requires the signing tools and servers to support private algorithms,
-   as well as Opt-In.
-
-   Resolvers wishing to validate Opt-In zones MUST only do so when the
-   zone is only signed using one or more of these private algorithms.
-
-   The remainder of this document assumes that the servers and resolvers
-   involved are aware of and are involved in this experiment.
-
-4.  Protocol Additions
-
-   In DNSSEC, delegation NS RRsets are not signed, but are instead
-   accompanied by a NSEC RRset of the same name and (possibly) a DS
-   record.  The security status of the subzone is determined by the
-   presence or absence of the DS RRset, cryptographically proven by the
-   NSEC record.  Opt-In expands this definition by allowing insecure
-   delegations to exist within an otherwise signed zone without the
-   corresponding NSEC record at the delegation's owner name.  These
-   insecure delegations are proven insecure by using a covering NSEC
-   record.
-
-   Since this represents a change of the interpretation of NSEC records,
-   resolvers must be able to distinguish between RFC standard DNSSEC
-   NSEC records and Opt-In NSEC records.  This is accomplished by
-   "tagging" the NSEC records that cover (or potentially cover) insecure
-   delegation nodes.  This tag is indicated by the absence of the NSEC
-   bit in the type map.  Since the NSEC bit in the type map merely
-   indicates the existence of the record itself, this bit is redundant
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 4]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   and safe for use as a tag.
-
-   An Opt-In tagged NSEC record does not assert the (non)existence of
-   the delegations that it covers (except for a delegation with the same
-   name).  This allows for the addition or removal of these delegations
-   without recalculating or resigning records in the NSEC chain.
-   However, Opt-In tagged NSEC records do assert the (non)existence of
-   other RRsets.
-
-   An Opt-In NSEC record MAY have the same name as an insecure
-   delegation.  In this case, the delegation is proven insecure by the
-   lack of a DS bit in type map and the signed NSEC record does assert
-   the existence of the delegation.
-
-   Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
-   records and standard DNSSEC NSEC records.  If a NSEC record is not
-   Opt-In, there MUST NOT be any insecure delegations (or any other
-   records) between it and the RRsets indicated by the 'next domain
-   name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
-   insecure delegations between it and the next node indicated by the
-   'next domain name' in the NSEC RDATA.
-
-   In summary,
-
-   o  An Opt-In NSEC type is identified by a zero-valued (or not-
-      specified) NSEC bit in the type bit map of the NSEC record.
-   o  A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
-      the type bit map of the NSEC record.
-
-   and,
-
-   o  An Opt-In NSEC record does not assert the non-existence of a name
-      between its owner name and "next" name, although it does assert
-      that any name in this span MUST be an insecure delegation.
-   o  An Opt-In NSEC record does assert the (non)existence of RRsets
-      with the same owner name.
-
-4.1  Server Considerations
-
-   Opt-In imposes some new requirements on authoritative DNS servers.
-
-4.1.1  Delegations Only
-
-   This specification dictates that only insecure delegations may exist
-   between the owner and "next" names of an Opt-In tagged NSEC record.
-   Signing tools SHOULD NOT generate signed zones that violate this
-   restriction.  Servers SHOULD refuse to load and/or serve zones that
-   violate this restriction.  Servers also SHOULD reject AXFR or IXFR
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 5]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   responses that violate this restriction.
-
-4.1.2  Insecure Delegation Responses
-
-   When returning an Opt-In insecure delegation, the server MUST return
-   the covering NSEC RRset in the Authority section.
-
-   In standard DNSSEC, NSEC records already must be returned along with
-   the insecure delegation.  The primary difference that this proposal
-   introduces is that the Opt-In tagged NSEC record will have a
-   different owner name from the delegation RRset.  This may require
-   implementations to search for the covering NSEC RRset.
-
-4.1.3  Wildcards and Opt-In
-
-   Standard DNSSEC describes the practice of returning NSEC records to
-   prove the non-existence of an applicable wildcard in non-existent
-   name responses.  This NSEC record can be described as a "negative
-   wildcard proof".  The use of Opt-In NSEC records changes the
-   necessity for this practice.  For non-existent name responses when
-   the query name (qname) is covered by an Opt-In tagged NSEC record,
-   servers MAY choose to omit the wildcard proof record, and clients
-   MUST NOT treat the absence of this NSEC record as a validation error.
-
-   The intent of the standard DNSSEC negative wildcard proof requirement
-   is to prevent malicious users from undetectably removing valid
-   wildcard responses.  In order for this cryptographic proof to work,
-   the resolver must be able to prove:
-
-   1.  The exact qname does not exist.  This is done by the "normal"
-       NSEC record.
-   2.  No applicable wildcard exists.  This is done by returning a NSEC
-       record proving that the wildcard does not exist (this is the
-       negative wildcard proof).
-
-   However, if the NSEC record covering the exact qname is an Opt-In
-   NSEC record, the resolver will not be able to prove the first part of
-   this equation, as the qname might exist as an insecure delegation.
-   Thus, since the total proof cannot be completed, the negative
-   wildcard proof NSEC record is not useful.
-
-   The negative wildcard proof is also not useful when returned as part
-   of an Opt-In insecure delegation response for a similar reason: the
-   resolver cannot prove that the qname does or does not exist, and
-   therefore cannot prove that a wildcard expansion is valid.
-
-   The presence of an Opt-In tagged NSEC record does not change the
-   practice of returning a NSEC along with a wildcard expansion.  Even
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 6]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   though the Opt-In NSEC will not be able to prove that the wildcard
-   expansion is valid, it will prove that the wildcard expansion is not
-   masking any signed records.
-
-4.1.4  Dynamic Update
-
-   Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
-   particular, it introduces the need for rules that describe when to
-   add or remove a delegation name from the NSEC chain.  This document
-   does not attempt to define these rules.  Until these rules are
-   defined, servers MUST NOT process DNS Dynamic Update requests against
-   zones that use Opt-In NSEC records.  Servers SHOULD return responses
-   to update requests with RCODE=REFUSED.
-
-4.2  Client Considerations
-
-   Opt-In imposes some new requirements on security-aware resolvers
-   (caching or otherwise).
-
-4.2.1  Delegations Only
-
-   As stated in the "Server Considerations" section above, this
-   specification restricts the namespace covered by Opt-In tagged NSEC
-   records to insecure delegations only.  Thus, resolvers MUST reject as
-   invalid any records that fall within an Opt-In NSEC record's span
-   that are not NS records or corresponding glue records.
-
-4.2.2  Validation Process Changes
-
-   This specification does not change the resolver's resolution
-   algorithm.  However, it does change the DNSSEC validation process.
-   Resolvers MUST be able to use Opt-In tagged NSEC records to
-   cryptographically prove the validity and security status (as
-   insecure) of a referral.  Resolvers determine the security status of
-   the referred-to zone as follows:
-
-   o  In standard DNSSEC, the security status is proven by the existence
-      or absence of a DS RRset at the same name as the delegation.  The
-      existence of the DS RRset indicates that the referred-to zone is
-      signed.  The absence of the DS RRset is proven using a verified
-      NSEC record of the same name that does not have the DS bit set in
-      the type map.  This NSEC record MAY also be tagged as Opt-In.
-   o  Using Opt-In, the security status is proven by the existence of a
-      DS record (for signed) or the presence of a verified Opt-In tagged
-      NSEC record that covers the delegation name.  That is, the NSEC
-      record does not have the NSEC bit set in the type map, and the
-      delegation name falls between the NSEC's owner and "next" name.
-
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 7]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   Using Opt-In does not substantially change the nature of following
-   referrals within DNSSEC.  At every delegation point, the resolver
-   will have cryptographic proof that the referred-to subzone is signed
-   or unsigned.
-
-   When receiving either an Opt-In insecure delegation response or a
-   non-existent name response where that name is covered by an Opt-In
-   tagged NSEC record, the resolver MUST NOT require proof (in the form
-   of a NSEC record) that a wildcard did not exist.
-
-4.2.3  NSEC Record Caching
-
-   Caching resolvers MUST be able to retrieve the appropriate covering
-   Opt-In NSEC record when returning referrals that need them.  This
-   requirement differs from standard DNSSEC in that the covering NSEC
-   will not have the same owner name as the delegation.  Some
-   implementations may have to use new methods for finding these NSEC
-   records.
-
-4.2.4  Use of the AD bit
-
-   The AD bit, as defined by [2] and [5], MUST NOT be set when:
-
-   o  sending a Name Error (RCODE=3) response where the covering NSEC is
-      tagged as Opt-In.
-   o  sending an Opt-In insecure delegation response, unless the
-      covering (Opt-In) NSEC record's owner name equals the delegation
-      name.
-
-   This rule is based on what the Opt-In NSEC record actually proves:
-   for names that exist between the Opt-In NSEC record's owner and
-   "next" names, the Opt-In NSEC record cannot prove the non-existence
-   or existence of the name.  As such, not all data in the response has
-   been cryptographically verified, so the AD bit cannot be set.
-
-5.  Benefits
-
-   Using Opt-In allows administrators of large and/or changing
-   delegation-centric zones to minimize the overhead involved in
-   maintaining the security of the zone.
-
-   Opt-In accomplishes this by eliminating the need for NSEC records for
-   insecure delegations.  This, in a zone with a large number of
-   delegations to unsigned subzones, can lead to substantial space
-   savings (both in memory and on disk).  Additionally, Opt-In allows
-   for the addition or removal of insecure delegations without modifying
-   the NSEC record chain.  Zones that are frequently updating insecure
-   delegations (e.g., TLDs) can avoid the substantial overhead of
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 8]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   modifying and resigning the affected NSEC records.
-
-6.  Example
-
-   Consider the zone EXAMPLE, shown below.  This is a zone where all of
-   the NSEC records are tagged as Opt-In.
-
-   Example A: Fully Opt-In Zone.
-
-         EXAMPLE.               SOA    ...
-         EXAMPLE.               RRSIG  SOA ...
-         EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
-         EXAMPLE.               RRSIG  NS ...
-         EXAMPLE.               DNSKEY ...
-         EXAMPLE.               RRSIG  DNSKEY ...
-         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
-                                       SOA NS RRSIG DNSKEY )
-         EXAMPLE.               RRSIG  NSEC ...
-
-         FIRST-SECURE.EXAMPLE.  A      ...
-         FIRST-SECURE.EXAMPLE.  RRSIG  A ...
-         FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
-         FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
-
-         NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
-         NS.NOT-SECURE.EXAMPLE. A      ...
-
-         NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
-         NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
-         NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
-
-         SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
-         SECOND-SECURE.EXAMPLE. DS     ...
-         SECOND-SECURE.EXAMPLE. RRSIG  DS ...
-         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
-         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
-
-         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
-         NS.UNSIGNED.EXAMPLE.   A      ...
-
-
-   In this example, a query for a signed RRset (e.g., "FIRST-
-   SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
-   SECURE.EXAMPLE A") will result in a standard DNSSEC response.
-
-   A query for a nonexistent RRset will result in a response that
-   differs from standard DNSSEC by: the NSEC record will be tagged as
-   Opt-In, there may be no NSEC record proving the non-existence of a
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 9]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   matching wildcard record, and the AD bit will not be set.
-
-   A query for an insecure delegation RRset (or a referral) will return
-   both the answer (in the Authority section) and the corresponding
-   Opt-In NSEC record to prove that it is not secure.
-
-   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
-
-
-         RCODE=NOERROR, AD=0
-
-         Answer Section:
-
-         Authority Section:
-         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
-         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
-         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
-
-         Additional Section:
-         NS.UNSIGNED.EXAMPLE.   A      ...
-
-   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
-   NSEC record, because there are no insecure delegations that occur
-   between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
-   Example A would still be a valid zone if the NSEC record for EXAMPLE.
-   was changed to the following RR:
-
-         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
-                                       RRSIG DNSKEY NSEC )
-
-   However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
-   SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
-   delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
-   UNSIGNED.EXAMPLE., respectively).
-
-   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
-   part of the NSEC chain and also covered by an Opt-In tagged NSEC
-   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
-   removed from the zone without modifying and resigning the prior NSEC
-   record.  Delegations with names that fall between NOT-SECURE-
-   2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
-   resigning any NSEC records.
-
-7.  Transition Issues
-
-   Opt-In is not backwards compatible with standard DNSSEC and is
-   considered experimental.  Standard DNSSEC compliant implementations
-   would not recognize Opt-In tagged NSEC records as different from
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 10]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   standard NSEC records.  Because of this, standard DNSSEC
-   implementations, if they were to validate Opt-In style responses,
-   would reject all Opt-In insecure delegations within a zone as
-   invalid.  However, by only signing with private algorithms, standard
-   DNSSEC implementations will treat Opt-In responses as unsigned.
-
-   It should be noted that all elements in the resolution path between
-   (and including) the validator and the authoritative name server must
-   be aware of the Opt-In experiment and implement the Opt-In semantics
-   for successful validation to be possible.  In particular, this
-   includes any caching middleboxes between the validator and
-   authoritative name server.
-
-8.  Security Considerations
-
-   Opt-In allows for unsigned names, in the form of delegations to
-   unsigned subzones, to exist within an otherwise signed zone.  All
-   unsigned names are, by definition, insecure, and their validity or
-   existence cannot by cryptographically proven.
-
-   In general:
-
-   o  Records with unsigned names (whether existing or not) suffer from
-      the same vulnerabilities as records in an unsigned zone.  These
-      vulnerabilities are described in more detail in [12] (note in
-      particular sections 2.3, "Name Games" and 2.6, "Authenticated
-      Denial").
-   o  Records with signed names have the same security whether or not
-      Opt-In is used.
-
-   Note that with or without Opt-In, an insecure delegation may have its
-   contents undetectably altered by an attacker.  Because of this, the
-   primary difference in security that Opt-In introduces is the loss of
-   the ability to prove the existence or nonexistence of an insecure
-   delegation within the span of an Opt-In NSEC record.
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete records with unsigned names.  These records are
-   normally NS records, but this also includes signed wildcard
-   expansions (while the wildcard record itself is signed, its expanded
-   name is an unsigned name).
-
-   For example, if a resolver received the following response from the
-   example zone above:
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 11]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
-
-         RCODE=NOERROR
-
-         Answer Section:
-
-         Authority Section:
-         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
-         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
-                                        RRSIG DNSKEY
-         EXAMPLE.                RRSIG  NSEC ...
-
-         Additional Section:
-
-
-   The resolver would have no choice but to believe that the referral to
-   NS.FORGED. is valid.  If a wildcard existed that would have been
-   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
-   have undetectably removed it and replaced it with the forged
-   delegation.
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any record type: an attacker merely has to forge
-   a delegation to nameserver under his/her control and place whatever
-   records needed at the subzone apex.
-
-   While in particular cases, this issue may not present a significant
-   security problem, in general it should not be lightly dismissed.
-   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to Opt-In, and
-   MAY choose to not support Opt-In at all.
-
-9.  IANA Considerations
-
-   None.
-
-10.  Acknowledgments
-
-   The contributions, suggestions and remarks of the following persons
-   (in alphabetic order) to this draft are acknowledged:
-
-      Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
-      Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
-      Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
-      Wellington.
-
-11.  References
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 12]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-11.1  Normative References
-
-   [1]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [2]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-        Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [6]  Blacka, D., "DNSSEC Experiments",
-        draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
-        July 2005.
-
-11.2  Informative References
-
-   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-         RFC 2181, July 1997.
-
-   [9]   Eastlake, D., "Secure Domain Name System Dynamic Update",
-         RFC 2137, April 1997.
-
-   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
-         Status", RFC 3090, March 2001.
-
-   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
-         December 2001.
-
-   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-         System (DNS)", RFC 3833, August 2004.
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 13]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Drienerlolaan 5
-   7522 NB  Enschede
-   NL
-
-   Email: roy.arends@telin.nl
-
-
-   Mark Kosters
-   Verisign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: markk@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-   David Blacka
-   Verisign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: davidb@verisign.com
-   URI:   http://www.verisignlabs.com
-
-Appendix A.  Implementing Opt-In using "Views"
-
-   In many cases, it may be convenient to implement an Opt-In zone by
-   combining two separately maintained "views" of a zone at request
-   time.  In this context, "view" refers to a particular version of a
-   zone, not to any specific DNS implementation feature.
-
-   In this scenario, one view is the secure view, the other is the
-   insecure (or legacy) view.  The secure view consists of an entirely
-   signed zone using Opt-In tagged NSEC records.  The insecure view
-   contains no DNSSEC information.  It is helpful, although not
-   necessary, for the secure view to be a subset (minus DNSSEC records)
-   of the insecure view.
-
-   In addition, the only RRsets that may solely exist in the insecure
-   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 14]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   the zone apex NS RRset) MUST be signed and in the secure view.
-
-   These two views may be combined at request time to provide a virtual,
-   single Opt-In zone.  The following algorithm is used when responding
-   to each query:
-      V_A is the secure view as described above.
-      V_B is the insecure view as described above.
-      R_A is a response generated from V_A, following RFC 2535bis.
-      R_B is a response generated from V_B, following DNS resolution as
-      per RFC 1035 [1].
-      R_C is the response generated by combining R_A with R_B, as
-      described below.
-      A query is DNSSEC-aware if it either has the DO bit [11] turned
-      on, or is for a DNSSEC-specific record type.
-
-
-
-   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
-       generate and return R_B, otherwise
-   2.  Generate R_A.
-   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
-   4.  Generate R_B and combine it with R_A to form R_C:
-          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
-          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
-          record, if R_B's RCODE = NOERROR.
-   5.  Return R_C.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 15]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 16]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
deleted file mode 100644
index 390420abecd6..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-DNS Extensions working group                                   J. Jansen
-Internet-Draft                                                NLnet Labs
-Expires: July 5, 2006                                       January 2006
-
-
-     Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
-                 draft-ietf-dnsext-dnssec-rsasha256-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 5, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
-   resource records for use in the Domain Name System Security
-   Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
-
-
-
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 1]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
-   3.  RSA/SHA-256 RRSIG Resource Records  . . . . . . . . . . . . . . 3
-   4.  Implementation Considerations . . . . . . . . . . . . . . . . . 4
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 2]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical distributed
-   database for Internet Addressing.  The DNS has been extended to use
-   digital signatures and cryptographic keys for the verification of
-   data.  RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
-   Security Extensions.
-
-   RFC4034 describes how to store DNSKEY and RRSIG resource records, and
-   specifies a list of cryptographic algorithms to use.  This document
-   extends that list with the algorithm RSA/SHA-256, and specifies how
-   to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
-   resource records.
-
-   Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
-   this document.
-
-
-2.  RSA/SHA-256 DNSKEY Resource Records
-
-   RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
-   resource records (RRs) with the algorithm number [TBA].
-
-   The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
-   [6].
-
-
-3.  RSA/SHA-256 RRSIG Resource Records
-
-   RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
-   records (RRs) with algorithm number [TBA].
-
-   The value of the signature field in the RRSIG RR is calculated as
-   follows.  The values for the fields that precede the signature data
-   are specified in RFC4034 [2].
-
-   hash = SHA-256(data)
-
-   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-   Where SHA-256 is the message digest algorithm as specified in FIPS
-   180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
-   corresponding hexadecimal value, "e" is the private exponent of the
-   signing RSA key, and "n" is the public modulus of the signing key.
-   The FF octet MUST be repeated the maximum number of times so that the
-   total length of the signature equals the length of the modulus of the
-   signer's public key ("n"). "data" is the data of the resource record
-   set that is signed, as specified in RFC4034 [2].
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 3]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-   The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
-   specified in PKCS 2.1 [4]:
-
-   hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
-
-   This prefix should make the use of standard cryptographic libraries
-   easier.  These specifications are taken directly from PKCS #1 v2.1
-   section 9.2 [4].
-
-
-4.  Implementation Considerations
-
-   DNSSEC aware implementations MUST be able to support RRSIG resource
-   records with the RSA/SHA-256 algorithm.
-
-   If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
-   available for a certain rrset, with a secure path to their keys, the
-   validator SHOULD ignore the SHA-1 signature.  If the RSA/SHA-256
-   signature does not verify the data, and the RSA/SHA-1 does, the
-   validator SHOULD mark the data with the security status from the RSA/
-   SHA-256 signature.
-
-
-5.  IANA Considerations
-
-   IANA has not yet assigned an algorithm number for RSA/SHA-256.
-
-   The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
-   following entry:
-
-                                   Zone
-   Value Algorithm    [Mnemonic] Signing  References   Status
-   ----- ----------- ----------- -------- ----------  ---------
-   [tba] RSA/SHA-256 [RSASHA256]      y        [TBA]  MANDATORY
-
-
-6.  Security Considerations
-
-   Recently, weaknesses have been discovered in the SHA-1 hashing
-   algorithm.  It is therefore strongly encouraged to deploy SHA-256
-   where SHA-1 is used now, as soon as the DNS software supports it.
-
-   SHA-256 is considered sufficiently strong for the immediate future,
-   but predictions about future development in cryptography and
-   cryptanalysis are beyond the scope of this document.
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 4]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-7.  Acknowledgments
-
-   This document is a minor extension to RFC4034 [2].  Also, we try to
-   follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
-   [8] for consistency.  The authors of and contributors to these
-   documents are gratefully acknowledged for their hard work.
-
-   The following people provided additional feedback and text: Jaap
-   Akkerhuis, Miek Gieben and Wouter Wijngaards.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
-        (PKCS) #1: RSA Cryptography Specifications Version 2.1",
-        RFC 3447, February 2003.
-
-   [5]  National Institute of Standards and Technology, "Secure Hash
-        Standard", FIPS PUB 180-2, August 2002.
-
-   [6]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
-        System (DNS)", RFC 3110, May 2001.
-
-8.2.  Informative References
-
-   [7]  Schneier, B., "Applied Cryptography Second Edition: protocols,
-        algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
-        11709-9, 1996.
-
-   [8]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
-        Resource Records (RRs)", Work in Progress Feb 2006.
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 5]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-Author's Address
-
-   Jelte Jansen
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098VA
-   NL
-
-   Email: jelte@NLnetLabs.nl
-   URI:   http://www.nlnetlabs.nl/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 6]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 7]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
deleted file mode 100644
index dd8cbf0682e0..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
+++ /dev/null
@@ -1,839 +0,0 @@
-
-DNS Extensions Working Group                                   R. Arends
-Internet-Draft                                      Telematica Instituut
-Expires: August 25, 2005                                         P. Koch
-                                                                DENIC eG
-                                                             J. Schlyter
-                                                                  NIC-SE
-                                                       February 21, 2005
-
-
-                Evaluating DNSSEC Transition Mechanisms
-                 draft-ietf-dnsext-dnssec-trans-02.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 25, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document collects and summarizes different proposals for
-   alternative and additional strategies for authenticated denial in DNS
-   responses, evaluates these proposals and gives a recommendation for a
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 1]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   way forward.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Transition Mechanisms  . . . . . . . . . . . . . . . . . . . .  3
-     2.1   Mechanisms With Need of Updating DNSSEC-bis  . . . . . . .  4
-       2.1.1   Dynamic NSEC Synthesis . . . . . . . . . . . . . . . .  4
-       2.1.2   Add Versioning/Subtyping to Current NSEC . . . . . . .  5
-       2.1.3   Type Bit Map NSEC Indicator  . . . . . . . . . . . . .  6
-       2.1.4   New Apex Type  . . . . . . . . . . . . . . . . . . . .  6
-       2.1.5   NSEC White Lies  . . . . . . . . . . . . . . . . . . .  7
-       2.1.6   NSEC Optional via DNSSKEY Flag . . . . . . . . . . . .  8
-       2.1.7   New Answer Pseudo RR Type  . . . . . . . . . . . . . .  9
-       2.1.8   SIG(0) Based Authenticated Denial  . . . . . . . . . .  9
-     2.2   Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
-       2.2.1   Partial Type-code and Signal Rollover  . . . . . . . . 10
-       2.2.2   A Complete Type-code and Signal Rollover . . . . . . . 11
-       2.2.3   Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
-   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
-   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     5.1   Normative References . . . . . . . . . . . . . . . . . . . 13
-     5.2   Informative References . . . . . . . . . . . . . . . . . . 13
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
-       Intellectual Property and Copyright Statements . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 2]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-1.  Introduction
-
-   This report shall document the process of dealing with the NSEC
-   walking problem late in the Last Call for
-   [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
-   I-D.ietf-dnsext-dnssec-records].  It preserves some of the discussion
-   that took place in the DNSEXT WG during the first half of June 2004
-   as well as some additional ideas that came up subsequently.
-
-   This is an edited excerpt of the chairs' mail to the WG:
-      The working group consents on not including NSEC-alt in the
-      DNSSEC-bis documents.  The working group considers to take up
-      "prevention of zone enumeration" as a work item.
-      There may be multiple mechanisms to allow for co-existence with
-      DNSSEC-bis.  The chairs allow the working group a little over a
-      week (up to June 12, 2004) to come to consensus on a possible
-      modification to the document to enable gentle rollover.  If that
-      consensus cannot be reached the DNSSEC-bis documents will go out
-      as-is.
-
-   To ease the process of getting consensus, a summary of the proposed
-   solutions and analysis of the pros and cons were written during the
-   weekend.
-
-   This summary includes:
-
-      An inventory of the proposed mechanisms to make a transition to
-      future work on authenticated denial of existence.
-      List the known Pros and Cons, possibly provide new arguments, and
-      possible security considerations of these mechanisms.
-      Provide a recommendation on a way forward that is least disruptive
-      to the DNSSEC-bis specifications as they stand and keep an open
-      path to other methods for authenticated denial of existence.
-
-   The descriptions of the proposals in this document are coarse and do
-   not cover every detail necessary for implementation.  In any case,
-   documentation and further study is needed before implementaion and/or
-   deployment, including those which seem to be solely operational in
-   nature.
-
-2.  Transition Mechanisms
-
-   In the light of recent discussions and past proposals, we have found
-   several ways to allow for transition to future expansion of
-   authenticated denial.  We tried to illuminate the paths and pitfalls
-   in these ways forward.  Some proposals lead to a versioning of
-   DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
-   proposals are 'clean' but may cause delay, while again others may be
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 3]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   plain hacks.
-
-   Some paths do not introduce versioning, and might require the current
-   DNSSEC-bis documents to be fully updated to allow for extensions to
-   authenticated denial mechanisms.  Other paths introduce versioning
-   and do not (or minimally) require DNSSEC-bis documents to be updated,
-   allowing DNSSEC-bis to be deployed, while future versions can be
-   drafted independent from or partially depending on DNSSEC-bis.
-
-2.1  Mechanisms With Need of Updating DNSSEC-bis
-
-   Mechanisms in this category demand updates to the DNSSEC-bis document
-   set.
-
-2.1.1  Dynamic NSEC Synthesis
-
-   This proposal assumes that NSEC RRs and the authenticating RRSIG will
-   be generated dynamically to just cover the (non existent) query name.
-   The owner name is (the) one preceding the name queried for, the Next
-   Owner Name Field has the value of the Query Name Field + 1 (first
-   successor in canonical ordering).  A separate key (the normal ZSK or
-   a separate ZSK per authoritative server) would be used for RRSIGs on
-   NSEC RRs.  This is a defense against enumeration, though it has the
-   presumption of online signing.
-
-2.1.1.1  Coexistence and Migration
-
-   There is no change in interpretation other then that the next owner
-   name might or might not exist.
-
-2.1.1.2  Limitations
-
-   This introduces an unbalanced cost between query and response
-   generation due to dynamic generation of signatures.
-
-2.1.1.3  Amendments to DNSSEC-bis
-
-   The current DNSSEC-bis documents might need to be updated to indicate
-   that the next owner name might not be an existing name in the zone.
-   This is not a real change to the spec since implementers have been
-   warned not to synthesize with previously cached NSEC records.  A
-   specific bit to identify the dynamic signature generating key might
-   be useful as well, to prevent it from being used to fake positive
-   data.
-
-2.1.1.4  Cons
-
-   Unbalanced cost is a ground for DDoS.  Though this protects against
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 4]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   enumeration, it is not really a path for versioning.
-
-2.1.1.5  Pros
-
-   Hardly any amendments to DNSSEC-bis.
-
-2.1.2  Add Versioning/Subtyping to Current NSEC
-
-   This proposal introduces versioning for the NSEC RR type (a.k.a.
-   subtyping) by adding a (one octet) version field to the NSEC RDATA.
-   Version number 0 is assigned to the current (DNSSEC-bis) meaning,
-   making this an 'Must Be Zero' (MBZ) for the to be published docset.
-
-2.1.2.1  Coexistence and Migration
-
-   Since the versioning is done inside the NSEC RR, different versions
-   may coexist.  However, depending on future methods, that may or may
-   not be useful inside a single zone.  Resolvers cannot ask for
-   specific NSEC versions but may be able to indicate version support by
-   means of a to be defined EDNS option bit.
-
-2.1.2.2  Limitations
-
-   There are no technical limitations, though it will cause delay to
-   allow testing of the (currently unknown) new NSEC interpretation.
-
-   Since the versioning and signaling is done inside the NSEC RR, future
-   methods will likely be restricted to a single RR type authenticated
-   denial (as opposed to e.g.  NSEC-alt, which currently proposes three
-   RR types).
-
-2.1.2.3  Amendments to DNSSEC-bis
-
-   Full Update of the current DNSSEC-bis documents to provide for new
-   fields in NSEC, while specifying behavior in case of unknown field
-   values.
-
-2.1.2.4  Cons
-
-   Though this is a clean and clear path without versioning DNSSEC, it
-   takes some time to design, gain consensus, update the current
-   dnssec-bis document, test and implement a new authenticated denial
-   record.
-
-2.1.2.5  Pros
-
-   Does not introduce an iteration to DNSSEC while providing a clear and
-   clean migration strategy.
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 5]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.3  Type Bit Map NSEC Indicator
-
-   Bits in the type-bit-map are reused or allocated to signify the
-   interpretation of NSEC.
-
-   This proposal assumes that future extensions make use of the existing
-   NSEC RDATA syntax, while it may need to change the interpretation of
-   the RDATA or introduce an alternative denial mechanism, invoked by
-   the specific type-bit-map-bits.
-
-2.1.3.1  Coexistence and migration
-
-   Old and new NSEC meaning could coexist, depending how the signaling
-   would be defined.  The bits for NXT, NSEC, RRSIG or other outdated RR
-   types are available  as well as those covering meta/query types or
-   types to be specifically allocated.
-
-2.1.3.2  Limitations
-
-   This mechanism uses an NSEC field that was not designed for that
-   purpose.  Similar methods were discussed during the Opt-In discussion
-   and the Silly-State discussion.
-
-2.1.3.3  Amendments to DNSSEC-bis
-
-   The specific type-bit-map-bits must be allocated and they need to be
-   specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
-   interpretation.  Also, behaviour of the resolver and validator must
-   be documented in case unknown values are encountered for the MBZ
-   field.  Currently the protocol document specifies that the validator
-   MUST ignore the setting of the NSEC and the RRSIG bits, while other
-   bits are only used for the specific purpose of the type-bit-map field
-
-2.1.3.4  Cons
-
-   The type-bit-map was not designed for this purpose.  It is a
-   straightforward hack.  Text in protocol section 5.4 was put in
-   specially to defend against this usage.
-
-2.1.3.5  Pros
-
-   No change needed to the on-the-wire protocol as specified in the
-   current docset.
-
-2.1.4  New Apex Type
-
-   This introduces a new Apex type (parallel to the zone's SOA)
-   indicating the DNSSEC version (or authenticated denial) used in or
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 6]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   for this zone.
-
-2.1.4.1  Coexistence and Migration
-
-   Depending on the design of this new RR type multiple denial
-   mechanisms may coexist in a zone.  Old validators will not understand
-   and thus ignore the new type, so interpretation of the new NSEC
-   scheme may fail, negative responses may appear 'bogus'.
-
-2.1.4.2  Limitations
-
-   A record of this kind is likely to carry additional
-   feature/versioning indications unrelated to the current question of
-   authenticated denial.
-
-2.1.4.3  Amendments to DNSSEC-bis
-
-   The current DNSSEC-bis documents need to be updated to indicate that
-   the absence of this type indicates dnssec-bis, and that the (mere)
-   presence of this type indicated unknown versions.
-
-2.1.4.4  Cons
-
-   The only other 'zone' or 'apex' record is the SOA record.  Though
-   this proposal is not new, it is yet unknown how it might fulfill
-   authenticated denial extensions.  This new RR type would only provide
-   for a generalized signaling mechanism, not the new authenticated
-   denial scheme.  Since it is likely to be general in nature, due to
-   this generality consensus is not to be reached soon.
-
-2.1.4.5  Pros
-
-   This approach would allow for a lot of other per zone information to
-   be transported or signaled to both (slave) servers and resolvers.
-
-2.1.5  NSEC White Lies
-
-   This proposal disables one part of NSEC (the pointer part) by means
-   of a special target (root, apex, owner, ...), leaving intact only the
-   ability to authenticate denial of existence of RR sets, not denial of
-   existence of domain names (NXDOMAIN).  It may be necessary to have
-   one working NSEC to prove the absence of a wildcard.
-
-2.1.5.1  Coexistence and Migration
-
-   The NSEC target can be specified per RR, so standard NSEC and 'white
-   lie' NSEC can coexist in a zone.  There is no need for migration
-   because no versioning is introduced or intended.
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 7]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.5.2  Limitations
-
-   This proposal breaks the protocol and is applicable to certain types
-   of zones only (no wildcard, no deep names, delegation only).  Most of
-   the burden is put on the resolver side and operational consequences
-   are yet to be studied.
-
-2.1.5.3  Amendments to DNSSEC-bis
-
-   The current DNSSEC-bis documents need to be updated to indicate that
-   the NXDOMAIN responses may be insecure.
-
-2.1.5.4  Cons
-
-   Strictly speaking this breaks the protocol and doesn't fully fulfill
-   the requirements for authenticated denial of existence.  Security
-   implications need to be carefully documented: search path problems
-   (forged denial of existence may lead to wrong expansion of non-FQDNs
-   [RFC1535]) and replay attacks to deny existence of records.
-
-2.1.5.5  Pros
-
-   Hardly any amendments to DNSSEC-bis.  Operational "trick" that is
-   available anyway.
-
-2.1.6  NSEC Optional via DNSSKEY Flag
-
-   A new DNSKEY may be defined to declare NSEC optional per zone.
-
-2.1.6.1  Coexistence and Migration
-
-   Current resolvers/validators will not understand the Flag bit and
-   will have to treat negative responses as bogus.  Otherwise, no
-   migration path is needed since NSEC is simply turned off.
-
-2.1.6.2  Limitations
-
-   NSEC can only be made completely optional at the cost of being unable
-   to prove unsecure delegations (absence of a DS RR [RFC3658]).  A next
-   to this approach would just disable authenticated denial for
-   non-existence of nodes.
-
-2.1.6.3  Amendments to DNSSEC-bis
-
-   New DNSKEY Flag to be defined.  Resolver/Validator behaviour needs to
-   be specified in the light of absence of authenticated denial.
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 8]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.6.4  Cons
-
-   Doesn't fully meet requirements.  Operational consequences to be
-   studied.
-
-2.1.6.5  Pros
-
-   Official version of the "trick" presented in (8).  Operational
-   problems can be addressed during future work on validators.
-
-2.1.7  New Answer Pseudo RR Type
-
-   A new pseudo RR type may be defined that will be dynamically created
-   (and signed) by the responding authoritative server.  The RR in the
-   response will cover the QNAME, QCLASS and QTYPE and will authenticate
-   both denial of existence of name (NXDOMAIN) or RRset.
-
-2.1.7.1  Coexistence and Migration
-
-   Current resolvers/validators will not understand the pseudo RR and
-   will thus not be able to process negative responses so testified.  A
-   signaling or solicitation method would have to be specified.
-
-2.1.7.2  Limitations
-
-   This method can only be used with online keys and online signing
-   capacity.
-
-2.1.7.3  Amendments to DNSSEC-bis
-
-   Signaling method needs to be defined.
-
-2.1.7.4  Cons
-
-   Keys have to be held and processed online with all security
-   implications.  An additional flag for those keys identifying them as
-   online or negative answer only keys should be considered.
-
-2.1.7.5  Pros
-
-   Expands DNSSEC authentication to the RCODE.
-
-2.1.8  SIG(0) Based Authenticated Denial
-
-
-2.1.8.1  Coexistence and Migration
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 9]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.8.2  Limitations
-
-
-2.1.8.3  Amendments to DNSSEC-bis
-
-
-2.1.8.4  Cons
-
-
-2.1.8.5  Pros
-
-
-2.2  Mechanisms Without Need of Updating DNSSEC-bis
-
-2.2.1  Partial Type-code and Signal Rollover
-
-   Carefully crafted type code/signal rollover to define a new
-   authenticated denial space that extends/replaces DNSSEC-bis
-   authenticated denial space.  This particular path is illuminated by
-   Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
-   posted to  2004-06-02.
-
-2.2.1.1  Coexistence and Migration
-
-   To protect the current resolver for future versions, a new DNSSEC-OK
-   bit must be allocated to make clear it does or does not understand
-   the future version.  Also, a new DS type needs to be allocated to
-   allow differentiation between a current signed delegation and a
-   'future' signed delegation.  Also, current NSEC needs to be rolled
-   into a new authenticated denial type.
-
-2.2.1.2  Limitations
-
-   None.
-
-2.2.1.3  Amendments to DNSSEC-bis
-
-   None.
-
-2.2.1.4  Cons
-
-   It is cumbersome to carefully craft an TCR that 'just fits'.  The
-   DNSSEC-bis protocol has many 'borderline' cases that needs special
-   consideration.  It might be easier to do a full TCR, since a few of
-   the types and signals need upgrading anyway.
-
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 10]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.2.1.5  Pros
-
-   Graceful adoption of future versions of NSEC, while there are no
-   amendments to DNSSEC-bis.
-
-2.2.2  A Complete Type-code and Signal Rollover
-
-   A new DNSSEC space is defined which can exist independent of current
-   DNSSEC-bis space.
-
-   This proposal assumes that all current DNSSEC type-codes
-   (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
-   future versions of DNSSEC.  Any future version of DNSSEC has its own
-   types to allow for keys, signatures, authenticated denial, etcetera.
-
-2.2.2.1  Coexistence and Migration
-
-   Both spaces can co-exist.  They can be made completely orthogonal.
-
-2.2.2.2  Limitations
-
-   None.
-
-2.2.2.3  Amendments to DNSSEC-bis
-
-   None.
-
-2.2.2.4  Cons
-
-   With this path we abandon the current DNSSEC-bis.  Though it is easy
-   to role specific well-known and well-tested parts into the re-write,
-   once deployment has started this path is very expensive for
-   implementers, registries, registrars and registrants as well as
-   resolvers/users.  A TCR is not to be expected to occur frequently, so
-   while a next generation authenticated denial may be enabled by a TCR,
-   it is likely that that TCR will only be agreed upon if it serves a
-   whole basket of changes or additions.  A quick introduction of
-   NSEC-ng should not be expected from this path.
-
-2.2.2.5  Pros
-
-   No amendments/changes to current DNSSEC-bis docset needed.  It is
-   always there as last resort.
-
-2.2.3  Unknown Algorithm in RRSIG
-
-   This proposal assumes that future extensions make use of the existing
-   NSEC RDATA syntax, while it may need to change the interpretation of
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 11]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   the RDATA or introduce an alternative denial mechanism, invoked by
-   the specific unknown signing algorithm.  The different interpretation
-   would be signaled by use of different signature algorithms in the
-   RRSIG records covering the NSEC RRs.
-
-   When an entire zone is signed with a single unknown algorithm, it
-   will cause implementations that follow current dnssec-bis documents
-   to treat individual RRsets as unsigned.
-
-2.2.3.1  Coexistence and migration
-
-   Old and new NSEC RDATA interpretation or known and unknown Signatures
-   can NOT coexist in a zone since signatures cover complete (NSEC)
-   RRSets.
-
-2.2.3.2  Limitations
-
-   Validating resolvers agnostic of new interpretation will treat the
-   NSEC RRset as "not signed".  This affects wildcard and non-existence
-   proof, as well as proof for (un)secured delegations.  Also, all
-   positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
-   insecure/bogus to an old validator.
-
-   The algorithm version space is split for each future version of
-   DNSSEC.  Violation of the 'modular components' concept.  We use the
-   'validator' to protect the 'resolver' from unknown interpretations.
-
-2.2.3.3  Amendments to DNSSEC-bis
-
-   None.
-
-2.2.3.4  Cons
-
-   The algorithm field was not designed for this purpose.  This is a
-   straightforward hack.
-
-2.2.3.5  Pros
-
-   No amendments/changes to current DNSSEC-bis docset needed.
-
-3.  Recommendation
-
-   The authors recommend that the working group commits to and starts
-   work on a partial TCR, allowing graceful transition towards a future
-   version of NSEC.  Meanwhile, to accomodate the need for an
-   immediately, temporary, solution against zone-traversal, we recommend
-   On-Demand NSEC synthesis.
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 12]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   This approach does not require any mandatory changes to DNSSEC-bis,
-   does not violate the protocol and fulfills the requirements.  As a
-   side effect, it moves the cost of implementation and deployment to
-   the users (zone owners) of this mechanism.
-
-4.  Acknowledgements
-
-   The authors would like to thank Sam Weiler and Mark Andrews for their
-   input and constructive comments.
-
-5.  References
-
-5.1  Normative References
-
-   [I-D.ietf-dnsext-dnssec-intro]
-              Arends, R., Austein, R., Massey, D., Larson, M. and S.
-              Rose, "DNS Security Introduction and Requirements",
-              Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
-              2004.
-
-   [I-D.ietf-dnsext-dnssec-protocol]
-              Arends, R., "Protocol Modifications for the DNS Security
-              Extensions",
-              Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
-              October 2004.
-
-   [I-D.ietf-dnsext-dnssec-records]
-              Arends, R., "Resource Records for the DNS Security
-              Extensions",
-              Internet-Draft draft-ietf-dnsext-dnssec-records-11,
-              October 2004.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
-              SIG(0)s)", RFC 2931, September 2000.
-
-5.2  Informative References
-
-   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
-              With Widely Deployed DNS Software", RFC 1535, October
-              1993.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 13]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-              RFC 2535, March 1999.
-
-   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
-              June 1999.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   Enschede  7523 XC
-   The Netherlands
-
-   Phone: +31 53 4850485
-   Email: roy.arends@telin.nl
-
-
-   Peter Koch
-   DENIC eG
-   Wiesenh"uttenplatz 26
-   Frankfurt  60329
-   Germany
-
-   Phone: +49 69 27235 0
-   Email: pk@DENIC.DE
-
-
-   Jakob Schlyter
-   NIC-SE
-   Box 5774
-   Stockholm  SE-114 87
-   Sweden
-
-   Email: jakob@nic.se
-   URI:   http://www.nic.se/
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 14]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 15]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
deleted file mode 100644
index 2460cb619b67..000000000000
--- 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-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
deleted file mode 100644
index 6bffb70423f4..000000000000
--- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-DNS Extensions                                                O. Kolkman
-Internet-Draft                                                  RIPE NCC
-Expires: June 17, 2004                                       J. Schlyter
-
-                                                                E. Lewis
-                                                                    ARIN
-                                                       December 18, 2003
-
-
-                   DNSKEY RR Secure Entry Point Flag
-              draft-ietf-dnsext-keyrr-key-signing-flag-12
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on June 17, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-   With the Delegation Signer (DS) resource record the concept of a
-   public key acting as a secure entry point has been introduced. During
-   exchanges of public keys with the parent there is a need to
-   differentiate secure entry point keys from other public keys in the
-   DNSKEY resource record (RR) set.  A flag bit in the DNSKEY RR is
-   defined to indicate that DNSKEY is to be used as a secure entry
-   point. The flag bit is intended to assist in operational procedures
-   to correctly generate DS resource records, or to indicate what
-   DNSKEYs are intended for static configuration. The flag bit is not to
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 1]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   be used in the DNS verification protocol. This document updates RFC
-   2535 and RFC 3445.
-
-Table of Contents
-
-   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2. The Secure Entry Point (SEP) Flag  . . . . . . . . . . . . . . . 4
-   3. DNSSEC Protocol Changes  . . . . . . . . . . . . . . . . . . . . 5
-   4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
-   5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
-   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
-   7. Internationalization Considerations  . . . . . . . . . . . . . . 6
-   8. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 6
-      Normative References . . . . . . . . . . . . . . . . . . . . . . 7
-      Informative References . . . . . . . . . . . . . . . . . . . . . 7
-      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
-      Intellectual Property and Copyright Statements . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 2]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-1. Introduction
-
-   "All keys are equal but some keys are more equal than others" [6]
-
-   With the definition of the Delegation Signer Resource Record (DS RR)
-   [5] it has become important to differentiate between the keys in the
-   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
-   other keys in the DNSKEY RR set.  We refer to these public keys as
-   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
-   DS RR or is distributed to resolvers that use the key as the root of
-   a trusted subtree[3].
-
-   In early deployment tests, the use of two (kinds of) key pairs for
-   each zone has been prevalent.  For one kind of key pair the private
-   key is used to sign just the zone's DNSKEY resource record (RR) set.
-   Its public key is intended to be referenced by a DS RR at the parent
-   or configured statically in a resolver.  The private key of the other
-   kind of key pair is used to sign the rest of the zone's data sets.
-   The former key pair is called a key-signing key (KSK) and the latter
-   is called a zone-signing key (ZSK).  In practice there have been
-   usually one of each kind of key pair, but there will be multiples of
-   each at times.
-
-   It should be noted that division of keys pairs into KSK's and ZSK's
-   is not mandatory in any definition of DNSSEC, not even with the
-   introduction of the DS RR.  But, in testing, this distinction has
-   been helpful when designing key roll over (key super-cession)
-   schemes.  Given that the distinction has proven helpful, the labels
-   KSK and ZSK have begun to stick.
-
-   There is a need to differentiate the public keys for the key pairs
-   that are used for key signing from keys that are not used key signing
-   (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
-   be sent for generating DS RRs, which DNSKEYs are to be distributed to
-   resolvers, and which keys are fed to the signer application at the
-   appropriate time.
-
-   In other words, the SEP bit provides an in-band method to communicate
-   a DNSKEY RR's intended use to third parties. As an example we present
-   3 use cases in which the bit is useful:
-
-      The parent is a registry, the parent and the child use secured DNS
-      queries and responses, with a preexisting trust-relation, or plain
-      DNS over a secured channel to exchange the child's  DNSKEY RR
-      sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
-      the SEP bit can be used to isolate the DNSKEYs for which a DS RR
-      needs to be created.
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 3]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-      An administrator has configured a DNSKEY as root for a trusted
-      subtree into security aware resolver. Using a special purpose tool
-      that queries for the KEY RRs from that domain's apex, the
-      administrator will be able to notice the roll over of the trusted
-      anchor by a change of the subset of KEY RRs with the DS flag set.
-
-      A signer might use the SEP bit on the public key to determine
-      which private key to use to exclusively sign the DNSKEY RRset and
-      which private key to use to sign the other RRsets in the zone.
-
-   As demonstrated in the above examples it is important to be able to
-   differentiate the SEP keys from the other keys in a DNSKEY RR set in
-   the flow between signer and (parental) key-collector and in the flow
-   between the signer and the resolver configuration. The SEP flag is to
-   be of no interest to the flow between the verifier and the
-   authoritative data store.
-
-   The reason for the term "SEP" is a result of the observation that the
-   distinction between KSK and ZSK key pairs is made by the signer, a
-   key pair could be used as both a KSK and a ZSK at the same time. To
-   be clear, the term SEP was coined to lessen the confusion caused by
-   the overlap. ( Once this label was applied, it had the side effect of
-   removing the temptation to have both a KSK flag bit and a ZSK flag
-   bit.)
-
-   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
-   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
-   interpreted as described in RFC2119 [1].
-
-2. The Secure Entry Point (SEP) Flag
-
-
-                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |              flags          |S|   protocol    |   algorithm   |
-      |                             |E|               |               |
-      |                             |P|               |               |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                                                               /
-      /                        public key                             /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                                DNSKEY RR Format
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 4]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   This document assigns the 15'th bit in the flags field as the secure
-   entry point (SEP) bit.  If the the bit is set to 1 the key is
-   intended to be used as secure entry point key.  One SHOULD NOT assign
-   special meaning to the key if the bit is set to 0.  Operators can
-   recognize the secure entry point key by the even or odd-ness of the
-   decimal representation of the flag field.
-
-3. DNSSEC Protocol Changes
-
-   The bit MUST NOT be used during the resolving and verification
-   process. The SEP flag is only used to provide a hint about the
-   different administrative properties of the key and therefore the use
-   of the SEP flag does not change the DNS resolution protocol or the
-   resolution process.
-
-4. Operational Guidelines
-
-   The SEP bit is set by the key-pair-generator and MAY be used by the
-   zone signer to decide whether the public part of the key pair is to
-   be prepared for input to a DS RR generation function.  The SEP bit is
-   recommended to be set (to 1) whenever the public key of the key pair
-   will be distributed to the parent zone to build the authentication
-   chain or if the public key is to be distributed for static
-   configuration in verifiers.
-
-   When a key pair is created, the operator needs to indicate whether
-   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
-   the data that is used to compute the 'key tag field' in the SIG RR,
-   changing the SEP bit will change the identity of the key within DNS.
-   In other words, once a key is used to generate signatures, the
-   setting of the SEP bit is to remain constant. If not, a verifier will
-   not be able to find the relevant KEY RR.
-
-   When signing a zone, it is intended that the key(s) with the SEP bit
-   set (if such keys exist) are used to sign the KEY RR set of the zone.
-   The same key can be used to sign the rest of the zone data too.  It
-   is conceivable that not all keys with a SEP bit set will sign the
-   DNSKEY RR set, such keys might be pending retirement or not yet in
-   use.
-
-   When verifying a RR set, the SEP bit is not intended to play a role.
-   How the key is used by the verifier is not intended to be a
-   consideration at key creation time.
-
-   Although the SEP flag provides a hint on which public key is to be
-   used as trusted root, administrators can choose to ignore the fact
-   that a DNSKEY has its SEP bit set or not when configuring a trusted
-   root for their resolvers.
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 5]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   Using the SEP flag a key roll over can be automated. The parent can
-   use an existing trust relation to verify DNSKEY RR sets in which a
-   new DNSKEY RR with the SEP flag appears.
-
-5. Security Considerations
-
-   As stated in Section 3 the flag is not to be used in the resolution
-   protocol or to determine the security status of a key. The flag is to
-   be used for administrative purposes only.
-
-   No trust in a key should be inferred from this flag - trust MUST be
-   inferred from an existing chain of trust or an out-of-band exchange.
-
-   Since this flag might be used for automating public key exchanges, we
-   think the following consideration is in place.
-
-   Automated mechanisms for roll over of the DS RR might be vulnerable
-   to a class of replay attacks.  This might happen after a public key
-   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
-   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
-   RR set with the existing trust relation and creates the new DS RR
-   from the DNSKEY RR that the current DS RR is not pointing to.  This
-   key exchange might be replayed. Parents are encouraged to implement a
-   replay defense. A simple defense can be based on a registry of keys
-   that have been used to generate DS RRs during the most recent roll
-   over. These same considerations apply to entities that configure keys
-   in resolvers.
-
-6. IANA Considerations
-
-   The flag bits  in the DNSKEY RR are assigned by IETF consensus and
-   registered in the DNSKEY Flags registry (created by [4]). This
-   document assigns the 15th bit in the DNSKEY RR as the Secure Entry
-   Point (SEP) bit.
-
-7. Internationalization Considerations
-
-   Although SEP is a popular acronym in many different languages, there
-   are no internationalization considerations.
-
-8. Acknowledgments
-
-   The ideas documented in this document are inspired by communications
-   we had with numerous people and ideas published by other folk. Among
-   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
-   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
-   have contributed ideas and provided feedback.
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 6]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   This document saw the light during a workshop on DNSSEC operations
-   hosted by USC/ISI in August 2002.
-
-Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
-        Status", RFC 3090, March 2001.
-
-   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-        Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
-        in progress), October 2003.
-
-Informative References
-
-   [5]  Gudmundsson, O., "Delegation Signer Resource Record",
-        draft-ietf-dnsext-delegation-signer-15 (work in progress), June
-        2003.
-
-   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
-        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
-
-
-Authors' Addresses
-
-   Olaf M. Kolkman
-   RIPE NCC
-   Singel 256
-   Amsterdam  1016 AB
-   NL
-
-   Phone: +31 20 535 4444
-   EMail: olaf@ripe.net
-   URI:   http://www.ripe.net/
-
-
-   Jakob Schlyter
-   Karl Gustavsgatan 15
-   Goteborg  SE-411 25
-   Sweden
-
-   EMail: jakob@schlyter.se
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 7]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   Edward P. Lewis
-   ARIN
-   3635 Concorde Parkway Suite 200
-   Chantilly, VA  20151
-   US
-
-   Phone: +1 703 227 9854
-   EMail: edlewis@arin.net
-   URI:   http://www.arin.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 8]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 9]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                 [Page 10]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-mdns-43.txt b/doc/draft/draft-ietf-dnsext-mdns-43.txt
deleted file mode 100644
index 5de6e85ecf65..000000000000
--- a/doc/draft/draft-ietf-dnsext-mdns-43.txt
+++ /dev/null
@@ -1,1740 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group                                       Bernard Aboba
-INTERNET-DRAFT                                               Dave Thaler
-Category: Standards Track                                   Levon Esibov
-                    Microsoft Corporation
-29 August 2005
-
-              Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2005.
-
-Abstract
-
-   The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
-   name resolution in scenarios in which conventional DNS name
-   resolution is not possible.  LLMNR supports all current and future
-   DNS formats, types and classes, while operating on a separate port
-   from DNS, and with a distinct resolver cache.  Since LLMNR only
-   operates on the local link, it cannot be considered a substitute for
-   DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 1]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-Table of Contents
-
-1.     Introduction ..........................................    3
-   1.1       Requirements ....................................    4
-   1.2       Terminology .....................................    4
-2.     Name Resolution Using LLMNR ...........................    4
-   2.1       LLMNR Packet Format .............................    6
-   2.2       Sender Behavior .................................    9
-   2.3       Responder Behavior ..............................   10
-   2.4       Unicast Queries and Responses ...................   12
-   2.5       Off-link Detection ..............................   13
-   2.6       Responder Responsibilities ......................   13
-   2.7       Retransmission and Jitter .......................   14
-   2.8       DNS TTL .........................................   15
-   2.9       Use of the Authority and Additional Sections ....   15
-3.     Usage model ...........................................   16
-   3.1       LLMNR Configuration .............................   17
-4.     Conflict Resolution ...................................   18
-   4.1       Uniqueness Verification .........................   19
-   4.2       Conflict Detection and Defense ..................   20
-   4.3       Considerations for Multiple Interfaces ..........   21
-   4.4       API issues ......................................   22
-5.     Security Considerations ...............................   22
-   5.1       Denial of Service ...............................   23
-   5.2       Spoofing ...............,........................   23
-   5.3       Authentication ..................................   24
-   5.4       Cache and Port Separation .......................   25
-6.     IANA considerations ...................................   25
-7.     Constants .............................................   25
-8.     References ............................................   25
-   8.1       Normative References ............................   25
-   8.2       Informative References ..........................   26
-Acknowledgments ..............................................   27
-Authors' Addresses ...........................................   28
-Intellectual Property Statement ..............................   28
-Disclaimer of Validity .......................................   29
-Copyright Statement ..........................................   29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 2]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-1.  Introduction
-
-   This document discusses Link Local Multicast Name Resolution (LLMNR),
-   which is based on the DNS packet format and supports all current and
-   future DNS formats, types and classes.  LLMNR operates on a separate
-   port from the Domain Name System (DNS), with a distinct resolver
-   cache.
-
-   The goal of LLMNR is to enable name resolution in scenarios in which
-   conventional DNS name resolution is not possible.  Usage scenarios
-   (discussed in more detail in Section 3.1) include situations in which
-   hosts are not configured with the address of a DNS server; where the
-   DNS server is unavailable or unreachable; where there is no DNS
-   server authoritative for the name of a host, or where the
-   authoritative DNS server does not have the desired RRs, as described
-   in Section 2.
-
-   Since LLMNR only operates on the local link, it cannot be considered
-   a substitute for DNS.  Link-scope multicast addresses are used to
-   prevent propagation of LLMNR traffic across routers, potentially
-   flooding the network.  LLMNR queries can also be sent to a unicast
-   address, as described in Section 2.4.
-
-   Propagation of LLMNR packets on the local link is considered
-   sufficient to enable name resolution in small networks.  In such
-   networks, if a network has a gateway, then typically the network is
-   able to provide DNS server configuration.  Configuration issues are
-   discussed in Section 3.1.
-
-   In the future, it may be desirable to consider use of multicast name
-   resolution with multicast scopes beyond the link-scope.  This could
-   occur if LLMNR deployment is successful, the need arises for
-   multicast name resolution beyond the link-scope, or multicast routing
-   becomes ubiquitous.  For example, expanded support for multicast name
-   resolution might be required for mobile ad-hoc networks.
-
-   Once we have experience in LLMNR deployment in terms of
-   administrative issues, usability and impact on the network, it will
-   be possible to reevaluate which multicast scopes are appropriate for
-   use with multicast name resolution.  IPv4 administratively scoped
-   multicast usage is specified in "Administratively Scoped IP
-   Multicast" [RFC2365].
-
-   Service discovery in general, as well as discovery of DNS servers
-   using LLMNR in particular, is outside of the scope of this document,
-   as is name resolution over non-multicast capable media.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 3]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-1.1.  Requirements
-
-   In this document, several words are used to signify the requirements
-   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
-   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
-   and "OPTIONAL" in this document are to be interpreted as described in
-   [RFC2119].
-
-1.2.  Terminology
-
-   This document assumes familiarity with DNS terminology defined in
-   [RFC1035].  Other terminology used in this document includes:
-
-Positively Resolved
-     Responses with RCODE set to zero are referred to in this document
-     as "positively resolved".
-
-Routable Address
-     An address other than a Link-Local address.  This includes globally
-     routable addresses, as well as private addresses.
-
-Reachable
-     An LLMNR responder considers one of its addresses reachable over a
-     link if it will respond to an ARP or Neighbor Discovery query for
-     that address received on that link.
-
-Responder
-     A host that listens to LLMNR queries, and responds to those for
-     which it is authoritative.
-
-Sender
-     A host that sends an LLMNR query.
-
-UNIQUE
-     There are some scenarios when multiple responders may respond to
-     the same query.  There are other scenarios when only one responder
-     may respond to a query.  Names for which only a single responder is
-     anticipated are referred to as UNIQUE.  Name uniqueness is
-     configured on the responder, and therefore uniqueness verification
-     is the responder's responsibility.
-
-2.  Name Resolution Using LLMNR
-
-   LLMNR is a peer-to-peer name resolution protocol that is not intended
-   as a replacement for DNS.  LLMNR queries are sent to and received on
-   port 5355.  The IPv4 link-scope multicast address a given responder
-   listens to, and to which a sender sends queries, is 224.0.0.252.  The
-   IPv6 link-scope multicast address a given responder listens to, and
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 4]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
-
-   Typically a host is configured as both an LLMNR sender and a
-   responder.  A host MAY be configured as a sender, but not a
-   responder.  However, a host configured as a responder MUST act as a
-   sender, if only to verify the uniqueness of names as described in
-   Section 4.  This document does not specify how names are chosen or
-   configured.  This may occur via any mechanism, including DHCPv4
-   [RFC2131] or DHCPv6 [RFC3315].
-
-   LLMNR usage MAY be configured manually or automatically on a per
-   interface basis.  By default, LLMNR responders SHOULD be enabled on
-   all interfaces, at all times.  Enabling LLMNR for use in situations
-   where a DNS server has been configured will result in a change in
-   default behavior without a simultaneous update to configuration
-   information.  Where this is considered undesirable, LLMNR SHOULD NOT
-   be enabled by default, so that hosts will neither listen on the link-
-   scope multicast address, nor will they send queries to that address.
-
-   By default, LLMNR queries MAY be sent only when one of the following
-   conditions are met:
-
-   [1] No manual or automatic DNS configuration has been performed.
-       If DNS server address(es) have been configured, then LLMNR
-       SHOULD NOT be used as the primary name resolution mechanism,
-       although it MAY be used as a secondary name resolution
-       mechanism.  A dual stack host SHOULD attempt to reach DNS
-       servers overall protocols on which DNS server address(es) are
-       configured, prior to sending LLMNR queries.  For dual stack
-       hosts configured with DNS server address(es) for one protocol
-       but not another, this inplies that DNS queries SHOULD be sent
-       over the protocol configured with a DNS server, prior to
-       sending LLMNR queries.
-
-   [2] All attempts to resolve the name via DNS on all interfaces
-       have failed after exhausting the searchlist.  This can occur
-       because DNS servers did not respond, or because they
-       responded to DNS queries with RCODE=3 (Authoritative Name
-       Error) or RCODE=0, and an empty answer section.  Where a
-       single resolver call generates DNS queries for A and AAAA RRs,
-       an implementation MAY choose not to send LLMNR queries if any
-       of the DNS queries is successful.  An LLMNR query SHOULD only
-       be sent for the originally requested name;  a searchlist
-       is not used to form additional LLMNR queries.
-
-   While these conditions are necessary for sending an LLMNR query, they
-   are not sufficient.  While an LLMNR sender MAY send a query for any
-   name, it also MAY impose additional conditions on sending LLMNR
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 5]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   queries.  For example, a sender configured with a DNS server MAY send
-   LLMNR queries only for unqualified names and for fully qualified
-   domain names within configured zones.
-
-   A typical sequence of events for LLMNR usage is as follows:
-
-   [a]  DNS servers are not configured or attempts to resolve the
-        name via DNS have failed, after exhausting the searchlist.
-        Also, the name to be queried satisfies the restrictions
-        imposed by the implementation.
-
-   [b]  An LLMNR sender sends an LLMNR query to the link-scope
-        multicast address(es), unless a unicast query is indicated,
-        as specified in Section 2.4.
-
-   [c]  A responder responds to this query only if it is authoritative
-        for the domain name in the query.  A responder responds to a
-        multicast query by sending a unicast UDP response to the sender.
-        Unicast queries are responded to as indicated in Section 2.4.
-
-   [d]  Upon reception of the response, the sender processes it.
-
-   The sections that follow provide further details on sender and
-   responder behavior.
-
-2.1.  LLMNR Packet Format
-
-   LLMNR is based on the DNS packet format defined in [RFC1035] Section
-   4 for both queries and responses.  LLMNR implementations SHOULD send
-   UDP queries and responses only as large as are known to be
-   permissible without causing fragmentation.  When in doubt a maximum
-   packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
-   accept UDP queries and responses as large as the smaller of the link
-   MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
-   octets for the header, VLAN tag and CRC).
-
-2.1.1.  LLMNR Header Format
-
-   LLMNR queries and responses utilize the DNS header format defined in
-   [RFC1035] with exceptions noted below:
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 6]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-                                   1  1  1  1  1  1
-     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                      ID                       |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |QR|   Opcode  | C|TC| T| Z| Z| Z| Z|   RCODE   |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    QDCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ANCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    NSCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ARCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-ID   A 16 bit identifier assigned by the program that generates any kind
-     of query.  This identifier is copied from the query to the response
-     and can be used by the sender to match responses to outstanding
-     queries. The ID field in a query SHOULD be set to a pseudo-random
-     value.  For advice on generation of pseudo-random values, please
-     consult [RFC1750].
-
-QR   Query/Response.  A one bit field, which if set indicates that the
-     message is an LLMNR response; if clear then the message is an LLMNR
-     query.
-
-OPCODE
-     A four bit field that specifies the kind of query in this message.
-     This value is set by the originator of a query and copied into the
-     response.  This specification defines the behavior of standard
-     queries and responses (opcode value of zero).  Future
-     specifications may define the use of other opcodes with LLMNR.
-     LLMNR senders and responders MUST support standard queries (opcode
-     value of zero).  LLMNR queries with unsupported OPCODE values MUST
-     be silently discarded by responders.
-
-C    Conflict.  When set within a request, the 'C'onflict bit indicates
-     that a sender has received multiple LLMNR responses to this query.
-     In an LLMNR response, if the name is considered UNIQUE, then the
-     'C' bit is clear, otherwise it is set.  LLMNR senders do not
-     retransmit queries with the 'C' bit set.  Responders MUST NOT
-     respond to LLMNR queries with the 'C' bit set, but may start the
-     uniqueness verification process, as described in Section 4.2.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 7]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-TC   TrunCation - specifies that this message was truncated due to
-     length greater than that permitted on the transmission channel.
-     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
-     by an LLMNR responder.  If the TC bit is set in an LLMNR response,
-     then the sender SHOULD discard the response and resend the LLMNR
-     query over TCP using the unicast address of the responder as the
-     destination address.  See  [RFC2181] and Section 2.4 of this
-     specification for further discussion of the TC bit.
-
-T    Tentative.  The 'T'entative bit is set in a response if the
-     responder is authoritative for the name, but has not yet verified
-     the uniqueness of the name.  A responder MUST ignore the 'T' bit in
-     a query, if set.  A response with the 'T' bit set is silently
-     discarded by the sender, except if it is a uniqueness query, in
-     which case a conflict has been detected and a responder MUST
-     resolve the conflict as described in Section 4.1.
-
-Z    Reserved for future use.  Implementations of this specification
-     MUST set these bits to zero in both queries and responses.  If
-     these bits are set in a LLMNR query or response, implementations of
-     this specification MUST ignore them.  Since reserved bits could
-     conceivably be used for different purposes than in DNS,
-     implementors are advised not to enable processing of these bits in
-     an LLMNR implementation starting from a DNS code base.
-
-RCODE
-     Response code -- this 4 bit field is set as part of LLMNR
-     responses.  In an LLMNR query, the sender MUST set RCODE to zero;
-     the responder ignores the RCODE and assumes it to be zero.  The
-     response to a multicast LLMNR query MUST have RCODE set to zero.  A
-     sender MUST silently discard an LLMNR response with a non-zero
-     RCODE sent in response to a multicast query.
-
-     If an LLMNR responder is authoritative for the name in a multicast
-     query, but an error is encountered, the responder SHOULD send an
-     LLMNR response with an RCODE of zero, no RRs in the answer section,
-     and the TC bit set.  This will cause the query to be resent using
-     TCP, and allow the inclusion of a non-zero RCODE in the response to
-     the TCP query.  Responding with the TC bit set is preferable to not
-     sending a response, since it enables errors to be diagnosed.
-     Errors include those defined in [RFC2845], such as BADSIG(16),
-     BADKEY(17) and BADTIME(18).
-
-     Since LLMNR responders only respond to LLMNR queries for names for
-     which they are authoritative, LLMNR responders MUST NOT respond
-     with an RCODE of 3; instead, they should not respond at all.
-
-     LLMNR implementations MUST support EDNS0 [RFC2671] and extended
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 8]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-     RCODE values.
-
-QDCOUNT
-     An unsigned 16 bit integer specifying the number of entries in the
-     question section.  A sender MUST place only one question into the
-     question section of an LLMNR query.  LLMNR responders MUST silently
-     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
-     MUST silently discard LLMNR responses with QDCOUNT not equal to
-     one.
-
-ANCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the answer section.  LLMNR responders MUST silently
-     discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
-     An unsigned 16 bit integer specifying the number of name server
-     resource records in the authority records section.  Authority
-     record section processing is described in Section 2.9.  LLMNR
-     responders MUST silently discard LLMNR queries with NSCOUNT not
-     equal to zero.
-
-ARCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the additional records section.  Additional record
-     section processing is described in Section 2.9.
-
-2.2.  Sender Behavior
-
-   A sender MAY send an LLMNR query for any legal resource record  type
-   (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
-   As described in Section 2.4, a sender MAY also send a unicast query.
-
-   The sender MUST anticipate receiving no replies to some LLMNR
-   queries, in the event that no responders are available within the
-   link-scope.  If no response is received, a resolver treats it as a
-   response that the name does not exist (RCODE=3 is returned).  A
-   sender can handle duplicate responses by discarding responses with a
-   source IP address and ID field that duplicate a response already
-   received.
-
-   When multiple valid LLMNR responses are received with the 'C' bit
-   set, they SHOULD be concatenated and treated in the same manner that
-   multiple RRs received from the same DNS server would be.  However,
-   responses with the 'C' bit set SHOULD NOT be concatenated with
-   responses with the 'C' bit clear; instead, only the responses with
-   the 'C' bit set SHOULD be returned.  If valid LLMNR response(s) are
-   received along with error response(s), then the error responses are
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 9]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   silently discarded.
-
-   If error responses are received from both DNS and LLMNR, then the
-   lowest RCODE value should be returned. For example, if either DNS or
-   LLMNR receives a response with RCODE=0, then this should returned to
-   the caller.
-
-   Since the responder may order the RRs in the response so as to
-   indicate preference, the sender SHOULD preserve ordering in the
-   response to the querying application.
-
-2.3.  Responder Behavior
-
-   An LLMNR response MUST be sent to the sender via unicast.
-
-   Upon configuring an IP address, responders typically will synthesize
-   corresponding A, AAAA and PTR RRs so as to be able to respond to
-   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
-   responder has another RR in addition to the SOA RR;  the SOA RR MUST
-   NOT be the only RR that a responder has.  However, in general whether
-   RRs are manually or automatically created is an implementation
-   decision.
-
-   For example, a host configured to have computer name "host1" and to
-   be a member of the "example.com" domain, and with IPv4 address
-   192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
-   authoritative for the following records:
-
-   host1. IN A 192.0.2.1
-          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   host1.example.com. IN A 192.0.2.1
-          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   1.2.0.192.in-addr.arpa. IN PTR host1.
-          IN PTR host1.example.com.
-
-   6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
-   ip6.arpa IN PTR host1.  (line split for formatting reasons)
-            IN PTR host1.example.com.
-
-   An LLMNR responder might be further manually configured with the name
-   of a local mail server with an MX RR included in the "host1." and
-   "host1.example.com." records.
-
-   In responding to queries:
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 10]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
-     address(es) defined in Section 2, and on UDP and TCP port 5355 on
-     the unicast address(es) that could be set as the source address(es)
-     when the responder responds to the LLMNR query.
-
-[b]  Responders MUST direct responses to the port from which the query
-     was sent.  When queries are received via TCP this is an inherent
-     part of the transport protocol.  For queries received by UDP the
-     responder MUST take note of the source port and use that as the
-     destination port in the response.  Responses MUST always be sent
-     from the port to which they were directed.
-
-[c]  Responders MUST respond to LLMNR queries for names and addresses
-     they are authoritative for.  This applies to both forward and
-     reverse lookups, with the exception of queries with the 'C' bit
-     set, which do not elicit a response.
-
-[d]  Responders MUST NOT respond to LLMNR queries for names they are not
-     authoritative for.
-
-[e]  Responders MUST NOT respond using data from the LLMNR or DNS
-     resolver cache.
-
-[f]  If a DNS server is running on a host that supports LLMNR, the DNS
-     server MUST respond to LLMNR queries only for the RRSets relating
-     to the host on which the server is running, but MUST NOT respond
-     for other records for which the server is authoritative.  DNS
-     servers also MUST NOT send LLMNR queries in order to resolve DNS
-     queries.
-
-[g]  If a responder is authoritative for a name, it MUST respond with
-     RCODE=0 and an empty answer section, if the type of query does not
-     match a RR that the responder has.
-
-   As an example, a host configured to respond to LLMNR queries for the
-   name "foo.example.com."  is authoritative for the name
-   "foo.example.com.".  On receiving an LLMNR query for an A RR with the
-   name "foo.example.com." the host authoritatively responds with A
-   RR(s) that contain IP address(es) in the RDATA of the resource
-   record.  If the responder has a AAAA RR, but no A RR, and an A RR
-   query is received, the responder would respond with RCODE=0 and an
-   empty answer section.
-
-   In conventional DNS terminology a DNS server authoritative for a zone
-   is authoritative for all the domain names under the zone apex except
-   for the branches delegated into separate zones.  Contrary to
-   conventional DNS terminology, an LLMNR responder is authoritative
-   only for the zone apex.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 11]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   For example the host "foo.example.com." is not authoritative for the
-   name "child.foo.example.com." unless the host is configured with
-   multiple names, including "foo.example.com."  and
-   "child.foo.example.com.".  As a result, "foo.example.com." cannot
-   reply to an LLMNR query for "child.foo.example.com." with RCODE=3
-   (authoritative name error).  The purpose of limiting the name
-   authority scope of a responder is to prevent complications that could
-   be caused by coexistence of two or more hosts with the names
-   representing child and parent (or grandparent) nodes in the DNS tree,
-   for example, "foo.example.com." and "child.foo.example.com.".
-
-   Without the restriction on authority an LLMNR query for an A resource
-   record for the name "child.foo.example.com." would result in two
-   authoritative responses: RCODE=3 (authoritative name error) received
-   from "foo.example.com.", and a requested A record - from
-   "child.foo.example.com.".  To prevent this ambiguity, LLMNR enabled
-   hosts could perform a dynamic update of the parent (or grandparent)
-   zone with a delegation to a child zone;  for example a host
-   "child.foo.example.com." could send a dynamic update for the NS and
-   glue A record to "foo.example.com.".  However, this approach
-   significantly complicates implementation of LLMNR and would not be
-   acceptable for lightweight hosts.
-
-2.4.  Unicast Queries and Responses
-
-   Unicast queries SHOULD be sent when:
-
-   [a] A sender repeats a query after it received a response
-       with the TC bit set to the previous LLMNR multicast query, or
-
-   [b] The sender queries for a PTR RR of a fully formed IP address
-       within the "in-addr.arpa" or "ip6.arpa" zones.
-
-   Unicast LLMNR queries MUST be done using TCP and the responses MUST
-   be sent using the same TCP connection as the query.  Senders MUST
-   support sending TCP queries, and responders MUST support listening
-   for TCP queries. If the sender of a TCP query receives a response to
-   that query not using TCP, the response MUST be silently discarded.
-
-   Unicast UDP queries MUST be silently discarded.
-
-   If TCP connection setup cannot be completed in order to send a
-   unicast TCP query, this is treated as a response that no records of
-   the specified type and class exist for the specified name (it is
-   treated the same as a response with RCODE=0 and an empty answer
-   section).
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 12]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-2.5.  "Off link" Detection
-
-   A sender MUST select a source address for LLMNR queries that is
-   assigned on the interface on which the query is sent.  The
-   destination address of an LLMNR query MUST be a link-scope multicast
-   address or a unicast address.
-
-   A responder MUST select a source address for responses that is
-   assigned on the interface on which the query was received.  The
-   destination address of an LLMNR response MUST be a unicast address.
-
-   On receiving an LLMNR query, the responder MUST check whether it was
-   sent to a LLMNR multicast addresses defined in Section 2.  If it was
-   sent to another multicast address, then the query MUST be silently
-   discarded.
-
-   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
-   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
-   field in the IPv6 header and the TTL field in the IPv4 header of the
-   response to one (1).  The responder SHOULD set the TTL or Hop Limit
-   settings on the TCP listen socket to one (1) so that SYN-ACK packets
-   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
-   prevents an incoming connection from off-link since the sender will
-   not receive a SYN-ACK from the responder.
-
-   For UDP queries and responses, the Hop Limit field in the IPv6 header
-   and the TTL field in the IPV4 header MAY be set to any value.
-   However, it is RECOMMENDED that the value 255 be used for
-   compatibility with Apple Bonjour [Bonjour].
-
-   Implementation note:
-
-      In the sockets API for IPv4 [POSIX], the IP_TTL and
-      IP_MULTICAST_TTL socket options are used to set the TTL of
-      outgoing unicast and multicast packets. The IP_RECVTTL socket
-      option is available on some platforms to retrieve the IPv4 TTL of
-      received packets with recvmsg().  [RFC2292] specifies similar
-      options for setting and retrieving the IPv6 Hop Limit.
-
-2.6.  Responder Responsibilities
-
-   It is the responsibility of the responder to ensure that RRs returned
-   in LLMNR responses MUST only include values that are valid on the
-   local interface, such as IPv4 or IPv6 addresses valid on the local
-   link or names defended using the mechanism described in Section 4.
-   IPv4 Link-Local addresses are defined in [RFC3927].  IPv6 Link-Local
-   addresses are defined in [RFC2373].  In particular:
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 13]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   [a] If a link-scope IPv6 address is returned in a AAAA RR,
-       that address MUST be valid on the local link over which
-       LLMNR is used.
-
-   [b] If an IPv4 address is returned, it MUST be reachable
-       through the link over which LLMNR is used.
-
-   [c] If a name is returned (for example in a CNAME, MX
-       or SRV RR), the name MUST be resolvable on the local
-       link over which LLMNR is used.
-
-   Where multiple addresses represent valid responses to a query, the
-   order in which the addresses are returned is as follows:
-
-   [d] If the source address of the query is a link-scope address,
-       then the responder SHOULD include a link-scope address first
-       in the response, if available.
-
-   [e] If the source address of the query is a routable address,
-       then the responder MUST include a routable address first
-       in the response, if available.
-
-2.7.  Retransmission and Jitter
-
-   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
-   when to retransmit an LLMNR query.  An LLMNR sender SHOULD either
-   estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
-   high initial timeout.  Suggested constants are described in Section
-   7.
-
-   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
-   then a sender SHOULD repeat the transmission of the query in order to
-   assure that it was received by a host capable of responding to it,
-   while increasing the value of LLMNR_TIMEOUT exponentially.  An LLMNR
-   query SHOULD NOT be sent more than three times.
-
-   Where LLMNR queries are sent using TCP, retransmission is handled by
-   the transport layer.  Queries with the 'C' bit set MUST be sent using
-   multicast UDP and MUST NOT be retransmitted.
-
-   An LLMNR sender cannot know in advance if a query sent using
-   multicast will receive no response, one response, or more than one
-   response.  An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
-   has been received, or if it is necessary to collect all potential
-   responses, such as if a uniqueness verification query is being made.
-   Otherwise an LLMNR sender SHOULD consider a multicast query answered
-   after the first response is received, if that response has the 'C'
-   bit clear.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 14]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   However, if the first response has the 'C' bit set, then the sender
-   SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
-   responses.  When multiple valid answers are received, they may first
-   be concatenated, and then treated in the same manner that multiple
-   RRs received from the same DNS server would.  A unicast query sender
-   considers the query answered after the first response is received, so
-   that it only waits for LLMNR_TIMEOUT if no response has been
-   received.
-
-   Since it is possible for a response with the 'C' bit clear to be
-   followed by a response with the 'C' bit set, an LLMNR sender SHOULD
-   be prepared to process additional responses for the purposes of
-   conflict detection and LLMNR_TIMEOUT estimation, even after it has
-   considered a query answered.
-
-   In order to avoid synchronization, the transmission of each LLMNR
-   query and response SHOULD delayed by a time randomly selected from
-   the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
-   responders responding with names which they have previously
-   determined to be UNIQUE (see Section 4 for details).
-
-2.8.  DNS TTL
-
-   The responder should insert a pre-configured TTL value in the records
-   returned in an LLMNR response.  A default value of 30 seconds is
-   RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc
-   networks), the TTL value may need to be reduced.
-
-   Due to the TTL minimalization necessary when caching an RRset, all
-   TTLs in an RRset MUST be set to the same value.
-
-2.9.  Use of the Authority and Additional Sections
-
-   Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
-   concept of delegation.  In LLMNR, the NS resource record type may be
-   stored and queried for like any other type, but it has no special
-   delegation semantics as it does in the DNS.  Responders MAY have NS
-   records associated with the names for which they are authoritative,
-   but they SHOULD NOT include these NS records in the authority
-   sections of responses.
-
-   Responders SHOULD insert an SOA record into the authority section of
-   a negative response, to facilitate negative caching as specified in
-   [RFC2308]. The TTL of this record is set from the minimum of the
-   MINIMUM field of the SOA record and the TTL of the SOA itself, and
-   indicates how long a resolver may cache the negative answer.  The
-   owner name of the SOA record (MNAME) MUST be set to the query name.
-   The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 15]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   by senders.  Negative responses without SOA records SHOULD NOT be
-   cached.
-
-   In LLMNR, the additional section is primarily intended for use by
-   EDNS0, TSIG and SIG(0).  As a result, unless the 'C' bit is set,
-   senders MAY only include pseudo RR-types in the additional section of
-   a query; unless the 'C' bit is set, responders MUST ignore the
-   additional section of queries containing other RR types.
-
-   In queries where the 'C' bit is set, the sender SHOULD include the
-   conflicting RRs in the additional section.  Since conflict
-   notifications are advisory, responders SHOULD log information from
-   the additional section, but otherwise MUST ignore the additional
-   section.
-
-   Senders MUST NOT cache RRs from the authority or additional section
-   of a response as answers, though they may be used for other purposes
-   such as negative caching.
-
-3.  Usage Model
-
-   Since LLMNR is a secondary name resolution mechanism, its usage is in
-   part determined by the behavior of DNS implementations.  This
-   document does not specify any changes to DNS resolver behavior, such
-   as searchlist processing or retransmission/failover policy.  However,
-   robust DNS resolver implementations are more likely to avoid
-   unnecessary LLMNR queries.
-
-   As noted in [DNSPerf], even when DNS servers are configured, a
-   significant fraction of DNS queries do not receive a response, or
-   result in negative responses due to missing inverse mappings or NS
-   records that point to nonexistent or inappropriate hosts.  This has
-   the potential to result in a large number of unnecessary LLMNR
-   queries.
-
-   [RFC1536] describes common DNS implementation errors and fixes.  If
-   the proposed fixes are implemented, unnecessary LLMNR queries will be
-   reduced substantially, and so implementation of [RFC1536] is
-   recommended.
-
-   For example, [RFC1536] Section 1 describes issues with retransmission
-   and recommends implementation of a retransmission policy based on
-   round trip estimates, with exponential backoff.  [RFC1536] Section 4
-   describes issues with failover, and recommends that resolvers try
-   another server when they don't receive a response to a query.  These
-   policies are likely to avoid unnecessary LLMNR queries.
-
-   [RFC1536] Section 3 describes zero answer bugs, which if addressed
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 16]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   will also reduce unnecessary LLMNR queries.
-
-   [RFC1536] Section 6 describes name error bugs and recommended
-   searchlist processing that will reduce unnecessary RCODE=3
-   (authoritative name) errors, thereby also reducing unnecessary LLMNR
-   queries.
-
-3.1.  LLMNR Configuration
-
-   Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
-   possible for a dual stack host to be configured with the address of a
-   DNS server over IPv4, while remaining unconfigured with a DNS server
-   suitable for use over IPv6.
-
-   In these situations, a dual stack host will send AAAA queries to the
-   configured DNS server over IPv4.  However, an IPv6-only host
-   unconfigured with a DNS server suitable for use over IPv6 will be
-   unable to resolve names using DNS.  Automatic IPv6 DNS configuration
-   mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
-   deployed, and not all DNS servers support IPv6.  Therefore lack of
-   IPv6 DNS configuration may be a common problem in the short term, and
-   LLMNR may prove useful in enabling link-local name resolution over
-   IPv6.
-
-   Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
-   IPv6-only hosts may not be configured with a DNS server.  Where there
-   is no DNS server authoritative for the name of a host or the
-   authoritative DNS server does not support dynamic client update over
-   IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
-   be able to do DNS dynamic update, and other hosts will not be able to
-   resolve its name.
-
-   For example, if the configured DNS server responds to a AAAA RR query
-   sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
-   RCODE=0 and an empty answer section, then a AAAA RR query sent using
-   LLMNR over IPv6 may be successful in resolving the name of an
-   IPv6-only host on the local link.
-
-   Similarly, if a DHCPv4 server is available providing DNS server
-   configuration, and DNS server(s) exist which are authoritative for
-   the A RRs of local hosts and support either dynamic client update
-   over IPv4 or DHCPv4-based dynamic update, then the names of local
-   IPv4 hosts can be resolved over IPv4 without LLMNR.  However,  if no
-   DNS server is authoritative for the names of local hosts, or the
-   authoritative DNS server(s) do not support dynamic update, then LLMNR
-   enables linklocal name resolution over IPv4.
-
-   Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 17]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   configure LLMNR on an interface.  The LLMNR Enable Option, described
-   in [LLMNREnable], can be used to explicitly enable or disable use of
-   LLMNR on an interface.  The LLMNR Enable Option does not determine
-   whether or in which order DNS itself is used for name resolution.
-   The order in which various name resolution mechanisms should be used
-   can be specified using the Name Service Search Option (NSSO) for DHCP
-   [RFC2937], using the LLMNR Enable Option code carried in the NSSO
-   data.
-
-   It is possible that DNS configuration mechanisms will go in and out
-   of service.  In these circumstances, it is possible for hosts within
-   an administrative domain to be inconsistent in their DNS
-   configuration.
-
-   For example, where DHCP is used for configuring DNS servers, one or
-   more DHCP servers can fail.  As a result, hosts configured prior to
-   the outage will be configured with a DNS server, while hosts
-   configured after the outage will not.  Alternatively, it is possible
-   for the DNS configuration mechanism to continue functioning while
-   configured DNS servers fail.
-
-   An outage in the DNS configuration mechanism may result in hosts
-   continuing to use LLMNR even once the outage is repaired.  Since
-   LLMNR only enables linklocal name resolution, this represents a
-   degradation in capabilities.  As a result, hosts without a configured
-   DNS server may wish to periodically attempt to obtain DNS
-   configuration if permitted by the configuration mechanism in use.  In
-   the absence of other guidance, a default retry interval of one (1)
-   minute is RECOMMENDED.
-
-4.  Conflict Resolution
-
-   By default, a responder SHOULD be configured to behave as though its
-   name is UNIQUE on each interface on which LLMNR is enabled.  However,
-   it is also possible to configure multiple responders to be
-   authoritative for the same name.  For example, multiple responders
-   MAY respond to a query for an A or AAAA type record for a cluster
-   name (assigned to multiple hosts in the cluster).
-
-   To detect duplicate use of a name, an administrator can use a name
-   resolution utility which employs LLMNR and lists both responses and
-   responders.  This would allow an administrator to diagnose behavior
-   and potentially to intervene and reconfigure LLMNR responders who
-   should not be configured to respond to the same name.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 18]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-4.1.  Uniqueness Verification
-
-   Prior to sending an LLMNR response with the 'T' bit clear, a
-   responder configured with a UNIQUE name MUST verify that there is no
-   other host within the scope of LLMNR query propagation that is
-   authoritative for the same name on that interface.
-
-   Once a responder has verified that its name is UNIQUE, if it receives
-   an LLMNR query for that name, with the 'C' bit clear, it MUST
-   respond, with the 'T' bit clear. Prior to verifying that its name is
-   UNIQUE, a responder MUST set the 'T' bit in responses.
-
-   Uniqueness verification is carried out when the host:
-
-     - starts up or is rebooted
-     - wakes from sleep (if the network interface was inactive
-       during sleep)
-     - is configured to respond to LLMNR queries on an interface
-       enabled for transmission and reception of IP traffic
-     - is configured to respond to LLMNR queries using additional
-       UNIQUE resource records
-     - verifies the acquisition of a new IP address and configuration
-       on an interface
-
-   To verify uniqueness, a responder MUST send an LLMNR query with the
-   'C' bit clear, over all protocols on which it responds to LLMNR
-   queries (IPv4 and/or IPv6).  It is RECOMMENDED that responders verify
-   uniqueness of a name by sending a query for the name with type='ANY'.
-
-   If no response is received, the sender retransmits the query, as
-   specified in Section 2.7.  If a response is received, the sender MUST
-   check if the source address matches the address of any of its
-   interfaces; if so, then the response is not considered a conflict,
-   since it originates from the sender.  To avoid triggering conflict
-   detection, a responder that detects that it is connected to the same
-   link on multiple interfaces SHOULD set the 'C' bit in responses.
-
-   If a response is received with the 'T' bit clear, the responder MUST
-   NOT use the name in response to LLMNR queries received over any
-   protocol (IPv4 or IPv6).  If a response is received with the 'T' bit
-   set, the responder MUST check if the source IP address in the
-   response, interpreted as an unsigned integer, is less than the source
-   IP address in the query.  If so, the responder MUST NOT use the name
-   in response to LLMNR queries received over any protocol (IPv4 or
-   IPv6).  For the purpose of uniqueness verification, the contents of
-   the answer section in a response is irrelevant.
-
-   Periodically carrying out uniqueness verification in an attempt to
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 19]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   detect name conflicts is not necessary, wastes network bandwidth, and
-   may actually be detrimental.  For example, if network links are
-   joined only briefly, and are separated again before any new
-   communication is initiated, temporary conflicts are benign and no
-   forced reconfiguration is required.  LLMNR responders SHOULD NOT
-   periodically attempt uniqueness verification.
-
-4.2.  Conflict Detection and Defense
-
-   Hosts on disjoint network links may configure the same name for use
-   with LLMNR.  If these separate network links are later joined or
-   bridged together, then there may be multiple hosts which are now on
-   the same link, trying to use the same name.
-
-   In order to enable ongoing detection of name conflicts, when an LLMNR
-   sender receives multiple LLMNR responses to a query, it MUST check if
-   the 'C' bit is clear in any of the responses.  If so, the sender
-   SHOULD send another query for the same name, type and class, this
-   time with the 'C' bit set, with the potentially conflicting resource
-   records included in the additional section.
-
-   Queries with the 'C' bit set are considered advisory and responders
-   MUST verify the existence of a conflict before acting on it.  A
-   responder receiving a query with the 'C' bit set MUST NOT respond.
-
-   If the query is for a UNIQUE name, then the responder MUST send its
-   own query for the same name, type and class, with the 'C' bit clear.
-   If a response is received, the sender MUST check if the source
-   address matches the address of any of its interfaces; if so, then the
-   response is not considered a conflict, since it originates from the
-   sender.  To avoid triggering conflict detection, a responder that
-   detects that it is connected to the same link on multiple interfaces
-   SHOULD set the 'C' bit in responses.
-
-   An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
-   log them.  Upon detecting a conflict, an LLMNR responder MUST
-   immediately stop using the conflicting name in response to LLMNR
-   queries received over any supported protocol, if the source IP
-   address in the response, interpreted as an unsigned integer, is less
-   than the source IP address in the uniqueness verification query.
-
-   After stopping the use of a name, the responder MAY elect to
-   configure a new name.  However, since name reconfiguration may be
-   disruptive, this is not required, and a responder may have been
-   configured to respond to multiple names so that alternative names may
-   already be available.  A host that has stopped the use of a name may
-   attempt uniqueness verification again after the expiration of the TTL
-   of the conflicting response.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 20]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-4.3.  Considerations for Multiple Interfaces
-
-   A multi-homed host may elect to configure LLMNR on only one of its
-   active interfaces.  In many situations this will be adequate.
-   However, should a host need to configure LLMNR on more than one of
-   its active interfaces, there are some additional precautions it MUST
-   take.  Implementers who are not planning to support LLMNR on multiple
-   interfaces simultaneously may skip this section.
-
-   Where a host is configured to issue LLMNR queries on more than one
-   interface, each interface maintains its own independent LLMNR
-   resolver cache, containing the responses to LLMNR queries.
-
-   A multi-homed host checks the uniqueness of UNIQUE records as
-   described in Section 4.  The situation is illustrated in figure 1.
-
-        ----------  ----------
-         |      |    |      |
-        [A]    [myhost]   [myhost]
-
-      Figure 1.  Link-scope name conflict
-
-   In this situation, the multi-homed myhost will probe for, and defend,
-   its host name on both interfaces.  A conflict will be detected on one
-   interface, but not the other.  The multi-homed myhost will not be
-   able to respond with a host RR for "myhost" on the interface on the
-   right (see Figure 1).  The multi-homed host may, however, be
-   configured to use the "myhost" name on the interface on the left.
-
-   Since names are only unique per-link, hosts on different links could
-   be using the same name.  If an LLMNR client sends requests over
-   multiple interfaces, and receives replies from more than one, the
-   result returned to the client is defined by the implementation.  The
-   situation is illustrated in figure 2.
-
-        ----------  ----------
-         |      |    |     |
-        [A]    [myhost]   [A]
-
-
-      Figure 2.  Off-segment name conflict
-
-   If host myhost is configured to use LLMNR on both interfaces, it will
-   send LLMNR queries on both interfaces.  When host myhost sends a
-   query for the host RR for name "A" it will receive a response from
-   hosts on both interfaces.
-
-   Host myhost cannot distinguish between the situation shown in Figure
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 21]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   2, and that shown in Figure 3 where no conflict exists.
-
-                [A]
-               |   |
-           -----   -----
-               |   |
-              [myhost]
-
-      Figure 3.  Multiple paths to same host
-
-   This illustrates that the proposed name conflict resolution mechanism
-   does not support detection or resolution of conflicts between hosts
-   on different links.  This problem can also occur with DNS when a
-   multi-homed host is connected to two different networks with
-   separated name spaces.  It is not the intent of this document to
-   address the issue of uniqueness of names within DNS.
-
-4.4.  API Issues
-
-   [RFC2553] provides an API which can partially solve the name
-   ambiguity problem for applications written to use this API, since the
-   sockaddr_in6 structure exposes the scope within which each scoped
-   address exists, and this structure can be used for both IPv4 (using
-   v4-mapped IPv6 addresses) and IPv6 addresses.
-
-   Following the example in Figure 2, an application on 'myhost' issues
-   the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
-   ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both
-   interfaces and the resolver library will return a list containing
-   multiple addrinfo structures, each with an associated sockaddr_in6
-   structure.  This list will thus contain the IPv4 and IPv6 addresses
-   of both hosts responding to the name 'A'.  Link-local addresses will
-   have a sin6_scope_id value that disambiguates which interface is used
-   to reach the address.  Of course, to the application, Figures 2 and 3
-   are still indistinguishable, but this API allows the application to
-   communicate successfully with any address in the list.
-
-5.  Security Considerations
-
-   LLMNR is a peer-to-peer name resolution protocol designed for use on
-   the local link.  While LLMNR limits the vulnerability of responders
-   to off-link senders, it is possible for an off-link responder to
-   reach a sender.
-
-   In scenarios such as public "hotspots" attackers can be present on
-   the same link.  These threats are most serious in wireless networks
-   such as 802.11, since attackers on a wired network will require
-   physical access to the network, while wireless attackers may mount
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 22]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   attacks from a distance.  Link-layer security such as [IEEE-802.11i]
-   can be of assistance against these threats if it is available.
-
-   This section details security measures available to mitigate threats
-   from on and off-link attackers.
-
-5.1.  Denial of Service
-
-   Attackers may take advantage of LLMNR conflict detection by
-   allocating the same name, denying service to other LLMNR responders
-   and possibly allowing an attacker to receive packets destined for
-   other hosts.  By logging conflicts, LLMNR responders can provide
-   forensic evidence of these attacks.
-
-   An attacker may spoof LLMNR queries from a victim's address in order
-   to mount a denial of service attack.  Responders setting the IPv6 Hop
-   Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
-   response may be able to reach the victim across the Internet.
-
-   While LLMNR responders only respond to queries for which they are
-   authoritative and LLMNR does not provide wildcard query support, an
-   LLMNR response may be larger than the query, and an attacker can
-   generate multiple responses to a query for a name used by multiple
-   responders.  A sender may protect itself against unsolicited
-   responses by silently discarding them as rapidly as possible.
-
-5.2.  Spoofing
-
-   LLMNR is designed to prevent reception of queries sent by an off-link
-   attacker.  LLMNR requires that responders receiving UDP queries check
-   that they are sent to a link-scope multicast address.  However, it is
-   possible that some routers may not properly implement link-scope
-   multicast, or that link-scope multicast addresses may leak into the
-   multicast routing system.  To prevent successful setup of TCP
-   connections by an off-link sender, responders receiving a TCP SYN
-   reply with a TCP SYN-ACK with TTL set to one (1).
-
-   While it is difficult for an off-link attacker to send an LLMNR query
-   to a responder,  it is possible for an off-link attacker to spoof a
-   response to a query (such as an A or AAAA query for a popular
-   Internet host), and by using a TTL or Hop Limit field larger than one
-   (1), for the forged response to reach the LLMNR sender.  Since the
-   forged response will only be accepted if it contains a matching ID
-   field, choosing a pseudo-random ID field within queries provides some
-   protection against off-link responders.
-
-   Since LLMNR queries can be sent when DNS server(s) do not respond, an
-   attacker can execute a denial of service attack on the DNS server(s)
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 23]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   and then poison the LLMNR cache by responding to an LLMNR query with
-   incorrect information.  As noted in "Threat Analysis of the Domain
-   Name System (DNS)" [RFC3833] these threats also exist with DNS, since
-   DNS response spoofing tools are available that can allow an attacker
-   to respond to a query more quickly than a distant DNS server.
-   However, while switched networks or link layer security may make it
-   difficult for an on-link attacker to snoop unicast DNS queries,
-   multicast LLMNR queries are propagated to all hosts on the link,
-   making it possible for an on-link attacker to spoof LLMNR responses
-   without having to guess the value of the ID field in the query.
-
-   Since LLMNR queries are sent and responded to on the local-link, an
-   attacker will need to respond more quickly to provide its own
-   response prior to arrival of the response from a legitimate
-   responder.   If an LLMNR query is sent for an off-link host, spoofing
-   a response in a timely way is not difficult, since a legitimate
-   response will never be received.
-
-   Limiting the situations in which LLMNR queries are sent, as described
-   in Section 2, is the best protection against these attacks.  If LLMNR
-   is given higher priority than DNS among the enabled name resolution
-   mechanisms, a denial of service attack on the DNS server would not be
-   necessary in order to poison the LLMNR cache, since LLMNR queries
-   would be sent even when the DNS server is available.  In addition,
-   the LLMNR cache, once poisoned, would take precedence over the DNS
-   cache, eliminating the benefits of cache separation.  As a result,
-   LLMNR is only used as a name resolution mechanism of last resort.
-
-5.3.  Authentication
-
-   LLMNR is a peer-to-peer name resolution protocol, and as a result,
-   it is often deployed in situations where no trust model can be
-   assumed.  This makes it difficult to apply existing DNS security
-   mechanisms to LLMNR.
-
-   LLMNR does not support "delegated trust" (CD or AD bits).  As a
-   result, unless LLMNR senders are DNSSEC aware, it is not feasible to
-   use DNSSEC [RFC4033] with LLMNR.
-
-   If authentication is desired, and a pre-arranged security
-   configuration is possible, then the following security mechanisms may
-   be used:
-
-[a]  LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
-     [RFC2931] security mechanisms. "DNS Name Service based on Secure
-     Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
-     the use of TSIG to secure LLMNR responses, based on group keys.
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 24]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[b]  IPsec ESP with a null-transform MAY be used to authenticate unicast
-     LLMNR queries and responses or LLMNR responses to multicast
-     queries.  In a small network without a certificate authority, this
-     can be most easily accomplished through configuration of a group
-     pre-shared key for trusted hosts.
-
-   Where these mechanisms cannot be supported, responses to LLMNR
-   queries may be unauthenticated.
-
-5.4.  Cache and Port Separation
-
-   In order to prevent responses to LLMNR queries from polluting the DNS
-   cache, LLMNR implementations MUST use a distinct, isolated cache for
-   LLMNR on each interface.  The use of separate caches is most
-   effective when LLMNR is used as a name resolution mechanism of last
-   resort, since this minimizes the opportunities for poisoning the
-   LLMNR cache, and decreases reliance on it.
-
-   LLMNR operates on a separate port from DNS, reducing the likelihood
-   that a DNS server will unintentionally respond to an LLMNR query.
-
-6.  IANA Considerations
-
-   This specification creates one new name space:  the reserved bits in
-   the LLMNR header.  These are allocated by IETF Consensus, in
-   accordance with BCP 26 [RFC2434].
-
-   LLMNR requires allocation of port 5355 for both TCP and UDP.
-
-   LLMNR requires allocation of link-scope multicast IPv4 address
-   224.0.0.252, as well as link-scope multicast IPv6 address
-   FF02:0:0:0:0:0:1:3.
-
-7.  Constants
-
-   The following timing constants are used in this protocol; they are
-   not intended to be user configurable.
-
-      JITTER_INTERVAL      100 ms
-      LLMNR_TIMEOUT        1 second (if set statically on all interfaces)
-                           100 ms (IEEE 802 media, including IEEE 802.11)
-
-8.  References
-
-8.1.  Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
-          Specification", RFC 1035, November 1987.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 25]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-          Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
-          Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-          RFC 2308, March 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
-          Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
-          Considerations Section in RFCs", BCP 26, RFC 2434, October
-          1998.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
-          August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-          "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-          2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
-          (SIG(0)s)", RFC 2931, September 2000.
-
-8.2.  Informative References
-
-[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
-          (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
-          June 2005.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
-          Caching", IEEE/ACM Transactions on Networking, Volume 10,
-          Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
-          unicast addresses to communicate with recursive DNS servers",
-          Internet draft (work in progress), draft-ietf-ipv6-dns-
-          discovery-07.txt, October 2002.
-
-[IEEE-802.11i]
-          Institute of Electrical and Electronics Engineers, "Supplement
-          to Standard for Telecommunications and Information Exchange
-          Between Systems - LAN/MAN Specific Requirements - Part 11:
-          Wireless LAN Medium Access Control (MAC) and Physical Layer
-          (PHY) Specifications: Specification for Enhanced Security",
-          IEEE 802.11i, July 2004.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 26]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[LLMNREnable]
-          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
-          in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
-          Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
-          Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
-          2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --
-          Portable Operating System Interface (POSIX). Open Group
-          Technical Standard: Base Specifications, Issue 6, December
-          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
-          Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-          Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-          March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
-          RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
-          2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
-          Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
-          2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
-          IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-          System (DNS)", RFC 3833, August 2004.
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
-          of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-          "DNS Security Introduction and Requirement", RFC 4033, March
-          2005.
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 27]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-Acknowledgments
-
-   This work builds upon original work done on multicast DNS by Bill
-   Manning and Bill Woodcock.  Bill Manning's work was funded under
-   DARPA grant #F30602-99-1-0523.  The authors gratefully acknowledge
-   their contribution to the current specification.  Constructive input
-   has also been received from Mark Andrews, Rob Austein, Randy Bush,
-   Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
-   Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
-   Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
-   Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
-   St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
-   Bernard Aboba
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 706 6605
-   EMail: bernarda@microsoft.com
-
-   Dave Thaler
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 703 8835
-   EMail: dthaler@microsoft.com
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   EMail: levone@microsoft.com
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 28]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-Open Issues
-
-   Open issues with this specification are tracked on the following web
-   site:
-
-   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 29]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-nsec3-04.txt b/doc/draft/draft-ietf-dnsext-nsec3-04.txt
deleted file mode 100644
index 8c6c5b1ba080..000000000000
--- a/doc/draft/draft-ietf-dnsext-nsec3-04.txt
+++ /dev/null
@@ -1,2352 +0,0 @@
-
-
-
-Network Working Group                                          B. Laurie
-Internet-Draft                                                 G. Sisson
-Expires: August 5, 2006                                        R. Arends
-                                                                 Nominet
-                                                           February 2006
-
-
-             DNSSEC Hash Authenticated Denial of Existence
-                       draft-ietf-dnsext-nsec3-04
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 5, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The DNS Security Extensions introduces the NSEC resource record for
-   authenticated denial of existence.  This document introduces a new
-   resource record as an alternative to NSEC that provides measures
-   against zone enumeration and allows for gradual expansion of
-   delegation-centric zones.
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 1]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
-     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  NSEC versus NSEC3  . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  5
-     3.1.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  6
-       3.1.1.  The Hash Function Field  . . . . . . . . . . . . . . .  6
-       3.1.2.  The Opt-In Flag Field  . . . . . . . . . . . . . . . .  7
-       3.1.3.  The Iterations Field . . . . . . . . . . . . . . . . .  8
-       3.1.4.  The Salt Length Field  . . . . . . . . . . . . . . . .  8
-       3.1.5.  The Salt Field . . . . . . . . . . . . . . . . . . . .  8
-       3.1.6.  The Next Hashed Ownername Field  . . . . . . . . . . .  9
-       3.1.7.  The Type Bit Maps Field  . . . . . . . . . . . . . . .  9
-     3.2.  The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
-   4.  Creating Additional NSEC3 RRs for Empty Non-Terminals  . . . . 11
-   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 11
-   6.  Including NSEC3 RRs in a Zone  . . . . . . . . . . . . . . . . 11
-   7.  Responding to NSEC3 Queries  . . . . . . . . . . . . . . . . . 12
-   8.  Special Considerations . . . . . . . . . . . . . . . . . . . . 13
-     8.1.  Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
-     8.2.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     8.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
-     8.4.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
-       8.4.1.  Avoiding Hash Collisions during generation . . . . . . 16
-       8.4.2.  Second Preimage Requirement Analysis . . . . . . . . . 16
-       8.4.3.  Possible Hash Value Truncation Method  . . . . . . . . 17
-       8.4.4.  Server Response to a Run-time Collision  . . . . . . . 17
-       8.4.5.  Parameters that Cover the Zone . . . . . . . . . . . . 18
-   9.  Performance Considerations . . . . . . . . . . . . . . . . . . 18
-   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
-     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
-   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
-   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 22
-   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 27
-     B.1.  answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
-       B.1.1.  Authenticating the Example DNSKEY RRset  . . . . . . . 29
-     B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
-     B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 32
-       B.3.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 33
-     B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . . 34
-     B.5.  Referral to Unsigned Zone using the Opt-In Flag  . . . . . 35
-     B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 2]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-     B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
-     B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 39
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
-   Intellectual Property and Copyright Statements . . . . . . . . . . 42
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 3]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-1.  Introduction
-
-1.1.  Rationale
-
-   The DNS Security Extensions included the NSEC RR to provide
-   authenticated denial of existence.  Though the NSEC RR meets the
-   requirements for authenticated denial of existence, it introduced a
-   side-effect in that the contents of a zone can be enumerated.  This
-   property introduces undesired policy issues.
-
-   An enumerated zone can be used either directly as a source of
-   probable e-mail addresses for spam, or indirectly as a key for
-   multiple WHOIS queries to reveal registrant data which many
-   registries may be under strict legal obligations to protect.  Many
-   registries therefore prohibit copying of their zone file; however the
-   use of NSEC RRs renders these policies unenforceable.
-
-   A second problem was the requirement that the existence of all record
-   types in a zone - including unsigned delegation points - must be
-   accounted for, despite the fact that unsigned delegation point
-   records are not signed.  This requirement has a side-effect that the
-   overhead of signed zones is not related to the increase in security
-   of subzones.  This requirement does not allow the zones' size to grow
-   in relation to the growth of signed subzones.
-
-   In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been
-   proposed as a measure against these side effects but at the time were
-   regarded as secondary over the need to have a stable DNSSEC
-   specification.  With (draft-vixie-dnssec-ter) [14] a graceful
-   transition path to future enhancements is introduced, while current
-   DNSSEC deployment can continue.  This document presents the NSEC3
-   Resource Record which mitigates these issues with the NSEC RR.
-
-   The reader is assumed to be familiar with the basic DNS and DNSSEC
-   concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
-   4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
-   [6], RFC2181 [7] and RFC2308 [8].
-
-1.2.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [9].
-
-1.3.  Terminology
-
-   The practice of discovering the contents of a zone, i.e. enumerating
-   the domains within a zone, is known as "zone enumeration".  Zone
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 4]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   enumeration was not practical prior to the introduction of DNSSEC.
-
-   In this document the term "original ownername" refers to a standard
-   ownername.  Because this proposal uses the result of a hash function
-   over the original (unmodified) ownername, this result is referred to
-   as "hashed ownername".
-
-   "Hash order" means the order in which hashed ownernames are arranged
-   according to their numerical value, treating the leftmost (lowest
-   numbered) octet as the most significant octet.  Note that this is the
-   same as the canonical ordering specified in RFC 4034 [4].
-
-   An "empty non-terminal" is a domain name that owns no resource
-   records but has subdomains that do.
-
-   The "closest encloser" of a (nonexistent) domain name is the longest
-   domain name, including empty non-terminals, that matches the
-   rightmost part of the nonexistent domain name.
-
-   "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
-   specified in RFC 3548bis [15].
-
-
-2.  NSEC versus NSEC3
-
-   This document does NOT obsolete the NSEC record, but gives an
-   alternative for authenticated denial of existence.  NSEC and NSEC3
-   RRs can not co-exist in a zone.  See draft-vixie-dnssec-ter [14] for
-   a signaling mechanism to allow for graceful transition towards NSEC3.
-
-
-3.  The NSEC3 Resource Record
-
-   The NSEC3 RR provides Authenticated Denial of Existence for DNS
-   Resource Record Sets.
-
-   The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
-   RR's original ownername.  It includes the next hashed ownername in
-   the hash order of the zone.  The complete set of NSEC3 RRs in a zone
-   indicates which RRsets exist for the original ownername of the RRset
-   and form a chain of hashed ownernames in the zone.  This information
-   is used to provide authenticated denial of existence for DNS data, as
-   described in RFC 4035 [5].  To provide protection against zone
-   enumeration, the ownernames used in the NSEC3 RR are cryptographic
-   hashes of the original ownername prepended to the name of the zone.
-   The NSEC3 RR indicates which hash function is used to construct the
-   hash, which salt is used, and how many iterations of the hash
-   function are performed over the original ownername.  The hashing
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 5]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   technique is described fully in Section 5.
-
-   Hashed ownernames of unsigned delegations may be excluded from the
-   chain.  An NSEC3 record which span covers the hash of an unsigned
-   delegation's ownername is referred to as an Opt-In NSEC3 record and
-   is indicated by the presence of a flag.
-
-   The ownername for the NSEC3 RR is the base32 encoding of the hashed
-   ownername prepended to the name of the zone..
-
-   The type value for the NSEC3 RR is XX.
-
-   The NSEC3 RR RDATA format is class independent and is described
-   below.
-
-   The class MUST be the same as the original ownername's class.
-
-   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [8].
-
-3.1.  NSEC3 RDATA Wire Format
-
-   The RDATA of the NSEC3 RR is as shown below:
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   | Hash Function |O|                Iterations                   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Salt Length  |                     Salt                      /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                     Next Hashed Ownername                     /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                         Type Bit Maps                         /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   "O" is the Opt-In Flag field.
-
-3.1.1.  The Hash Function Field
-
-   The Hash Function field identifies the cryptographic hash function
-   used to construct the hash-value.
-
-   The values are as defined for the DS record (see RFC 3658 [10]).
-
-   On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
-   function value.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 6]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-3.1.2.  The Opt-In Flag Field
-
-   The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
-   delegations.
-
-   In DNSSEC, NS RRsets at delegation points are not signed, and may be
-   accompanied by a DS record.  The security status of the subzone is
-   determined by the presence or absence of the DS RRset,
-   cryptographically proven by the NSEC record or the signed DS RRset.
-   The presence of the Opt-In flag expands this definition by allowing
-   insecure delegations to exist within an otherwise signed zone without
-   the corresponding NSEC3 record at the delegation's (hashed) owner
-   name.  These delegations are proven insecure by using a covering
-   NSEC3 record.
-
-   Resolvers must be able to distinguish between NSEC3 records and
-   Opt-In NSEC3 records.  This is accomplished by setting the Opt-In
-   flag of the NSEC3 records that cover (or potentially cover) insecure
-   delegation nodes.
-
-   An Opt-In NSEC3 record does not assert the existence or non-existence
-   of the insecure delegations that it covers.  This allows for the
-   addition or removal of these delegations without recalculating or
-   resigning records in the NSEC3 chain.  However, Opt-In NSEC3 records
-   do assert the (non)existence of other, authoritative RRsets.
-
-   An Opt-In NSEC3 record MAY have the same original owner name as an
-   insecure delegation.  In this case, the delegation is proven insecure
-   by the lack of a DS bit in type map and the signed NSEC3 record does
-   assert the existence of the delegation.
-
-   Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
-   non-Opt-In NSEC3 records.  If an NSEC3 record is not Opt-In, there
-   MUST NOT be any hashed ownernames of insecure delegations (nor any
-   other records) between it and the RRsets indicated by the 'Next
-   Hashed Ownername' in the NSEC3 RDATA.  If it is Opt-In, there MUST
-   only be hashed ownernames of insecure delegations between it and the
-   next node indicated by the 'Next Hashed Ownername' in the NSEC3
-   RDATA.
-
-   In summary,
-   o  An Opt-In NSEC3 type is identified by an Opt-In Flag field value
-      of 1.
-   o  A non Opt-In NSEC3 type is identified by an Opt-In Flag field
-      value of 0.
-   and,
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 7]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   o  An Opt-In NSEC3 record does not assert the non-existence of a hash
-      ownername between its ownername and next hashed ownername,
-      although it does assert that any hashed name in this span MUST be
-      of an insecure delegation.
-   o  An Opt-In NSEC3 record does assert the (non)existence of RRsets
-      with the same hashed owner name.
-
-3.1.3.  The Iterations Field
-
-   The Iterations field defines the number of times the hash has been
-   iterated.  More iterations results in greater resiliency of the hash
-   value against dictionary attacks, but at a higher cost for both the
-   server and resolver.  See Section 5 for details of this field's use.
-
-   Iterations make an attack more costly by making the hash computation
-   more computationally intensive, e.g. by iterating the hash function a
-   number of times.
-
-   When generating a few hashes this performance loss will not be a
-   problem, as a validator can handle a delay of a few milliseconds.
-   But when doing a dictionary attack it will also multiply the attack
-   workload by a factor, which is a problem for the attacker.
-
-3.1.4.  The Salt Length Field
-
-   The salt length field defines the length of the salt in octets.
-
-3.1.5.  The Salt Field
-
-   The Salt field is not present when the Salt Length Field has a value
-   of 0.
-
-   The Salt field is appended to the original ownername before hashing
-   in order to defend against precalculated dictionary attacks.  See
-   Section 5 for details on how the salt is used.
-
-   Salt is used to make dictionary attacks using precomputation more
-   costly.  A dictionary can only be computed after the attacker has the
-   salt, hence a new salt means that the dictionary has to be
-   regenerated with the new salt.
-
-   There MUST be a complete set of NSEC3 records covering the entire
-   zone that use the same salt value.  The requirement exists so that,
-   given any qname within a zone, at least one covering NSEC3 RRset may
-   be found.  While it may be theoretically possible to produce a set of
-   NSEC3s that use different salts that cover the entire zone, it is
-   computationally infeasible to generate such a set.  See Section 8.2
-   for further discussion.
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 8]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   The salt value SHOULD be changed from time to time - this is to
-   prevent the use of a precomputed dictionary to reduce the cost of
-   enumeration.
-
-3.1.6.  The Next Hashed Ownername Field
-
-   The Next Hashed Ownername field contains the next hashed ownername in
-   hash order.  That is, given the set of all hashed owernames, the Next
-   Hashed Ownername contains the hash value that immediately follows the
-   owner hash value for the given NSEC3 record.  The value of the Next
-   Hashed Ownername Field in the last NSEC3 record in the zone is the
-   same as the ownername of the first NSEC3 RR in the zone in hash
-   order.
-
-   Hashed ownernames of glue RRsets MUST NOT be listed in the Next
-   Hashed Ownername unless at least one authoritative RRset exists at
-   the same ownername.  Hashed ownernames of delegation NS RRsets MUST
-   be listed if the Opt-In bit is clear.
-
-   Note that the Next Hashed Ownername field is not encoded, unlike the
-   NSEC3 RR's ownername.  It is the unmodified binary hash value.  It
-   does not include the name of the containing zone.
-
-   The length of this field is the length of the hash value produced by
-   the hash function selected by the Hash Function field.
-
-3.1.7.  The Type Bit Maps Field
-
-   The Type Bit Maps field identifies the RRset types which exist at the
-   NSEC3 RR's original ownername.
-
-   The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
-   generation, and MUST be ignored during processing.
-
-   The RR type space is split into 256 window blocks, each representing
-   the low-order 8 bits of the 16-bit RR type space.  Each block that
-   has at least one active RR type is encoded using a single octet
-   window number (from 0 to 255), a single octet bitmap length (from 1
-   to 32) indicating the number of octets used for the window block's
-   bitmap, and up to 32 octets (256 bits) of bitmap.
-
-   Blocks are present in the NSEC3 RR RDATA in increasing numerical
-   order.
-
-   "|" denotes concatenation
-
-   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 9]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   Each bitmap encodes the low-order 8 bits of RR types within the
-   window block, in network bit order.  The first bit is bit 0.  For
-   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
-   to RR type 2 (NS), and so forth.  For window block 1, bit 1
-   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
-   1, it indicates that an RRset of that type is present for the NSEC3
-   RR's ownername.  If a bit is set to 0, it indicates that no RRset of
-   that type is present for the NSEC3 RR's ownername.
-
-   Since bit 0 in window block 0 refers to the non-existing RR type 0,
-   it MUST be set to 0.  After verification, the validator MUST ignore
-   the value of bit 0 in window block 0.
-
-   Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11]
-   (section 3.1) or within the range reserved for assignment only to
-   QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
-   zone data.  If encountered, they must be ignored upon reading.
-
-   Blocks with no types present MUST NOT be included.  Trailing zero
-   octets in the bitmap MUST be omitted.  The length of each block's
-   bitmap is determined by the type code with the largest numerical
-   value, within that block, among the set of RR types present at the
-   NSEC3 RR's actual ownername.  Trailing zero octets not specified MUST
-   be interpreted as zero octets.
-
-3.2.  The NSEC3 RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Opt-In Flag Field is represented as an unsigned decimal integer.
-   The value is either 0 or 1.
-
-   The Hash field is presented as a mnemonic of the hash or as an
-   unsigned decimal integer.  The value has a maximum of 127.
-
-   The Iterations field is presented as an unsigned decimal integer.
-
-   The Salt Length field is not presented.
-
-   The Salt field is represented as a sequence of case-insensitive
-   hexadecimal digits.  Whitespace is not allowed within the sequence.
-   The Salt Field is represented as "-" (without the quotes) when the
-   Salt Length field has value 0.
-
-   The Next Hashed Ownername field is represented as a sequence of case-
-   insensitive base32 digits, without whitespace.
-
-   The Type Bit Maps Field is represented as a sequence of RR type
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 10]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   mnemonics.  When the mnemonic is not known, the TYPE representation
-   as described in RFC 3597 [12] (section 5) MUST be used.
-
-
-4.  Creating Additional NSEC3 RRs for Empty Non-Terminals
-
-   In order to prove the non-existence of a record that might be covered
-   by a wildcard, it is necessary to prove the existence of its closest
-   encloser.  A closest encloser might be an empty non-terminal.
-
-   Additional NSEC3 RRs are generated for empty non-terminals.  These
-   additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
-   existing RRs in the zone except that their type-maps only indicated
-   the existence of an NSEC3 RRset and an RRSIG RRset.
-
-   This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
-   not appear at names that did not exist before the zone was signed.
-   [Comment.1]
-
-
-5.  Calculation of the Hash
-
-   Define H(x) to be the hash of x using the hash function selected by
-   the NSEC3 record and || to indicate concatenation.  Then define:
-
-   IH(salt,x,0)=H(x || salt)
-
-   IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
-
-   Then the calculated hash of an ownername is
-   IH(salt,ownername,iterations-1), where the ownername is the canonical
-   form.
-
-   The canonical form of the ownername is the wire format of the
-   ownername where:
-   1.  The ownername is fully expanded (no DNS name compression) and
-       fully qualified;
-   2.  All uppercase US-ASCII letters are replaced by the corresponding
-       lowercase US-ASCII letters;
-   3.  If the ownername is a wildcard name, the ownername is in its
-       original unexpanded form, including the "*" label (no wildcard
-       substitution);
-   This form is as defined in section 6.2 of RFC 4034 ([4]).
-
-
-6.  Including NSEC3 RRs in a Zone
-
-   Each ownername within the zone that owns authoritative RRsets MUST
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 11]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   have a corresponding NSEC3 RR.  Ownernames that correspond to
-   unsigned delegations MAY have a corresponding NSEC3 RR, however, if
-   there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
-   set to 1.  Other non-authoritative RRs are not included in the set of
-   NSEC3 RRs.
-
-   Each empty non-terminal MUST have an NSEC3 record.
-
-   The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
-   value field in the zone SOA RR.
-
-   The type bitmap of every NSEC3 resource record in a signed zone MUST
-   indicate the presence of both the NSEC3 RR type itself and its
-   corresponding RRSIG RR type.
-
-   The following steps describe the proper construction of NSEC3
-   records.  [Comment.2]
-   1.  For each unique original ownername in the zone, add an NSEC3
-       RRset.  If Opt-In is being used, ownernames of unsigned
-       delegations may be excluded, but must be considered for empty-
-       non-terminals.  The ownername of the NSEC3 RR is the hashed
-       equivalent of the original owner name, prepended to the zone
-       name.  The Next Hashed Ownername field is left blank for the
-       moment.  If Opt-In is being used, set the Opt-In bit to one.
-   2.  For each RRset at the original owner name, set the corresponding
-       bit in the type bit map.
-   3.  If the difference in number of labels between the apex and the
-       original ownername is greater then 1, additional NSEC3s need to
-       be added for every empty non-terminal between the apex and the
-       original ownername.  This process may generate NSEC3 RRs with
-       duplicate hashed ownernames.
-   4.  Sort the set of NSEC3 RRs into hash order.  Hash order is the
-       ascending numerical order of the non-encoded hash values.
-   5.  Combine NSEC3 RRs with identical hashed ownernames by replacing
-       with a single NSEC3 RR with the type map consisting of the union
-       of the types represented by the set of NSEC3 RRs.
-   6.  In each NSEC3 RR, insert the Next Hashed Ownername by using the
-       value of the next NSEC3 RR in hash order.  The Next Hashed
-       Ownername of the last NSEC3 in the zone contains the value of the
-       hashed ownername of the first NSEC3 in the hash order.
-
-
-7.  Responding to NSEC3 Queries
-
-   Since NSEC3 ownernames are not represented in the NSEC3 chain like
-   other zone ownernames, direct queries for NSEC3 ownernames present a
-   special case.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 12]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   The special case arises when the following are all true:
-   o  The QNAME equals an existing NSEC3 ownername, and
-   o  There are no other record types that exist at QNAME, and
-   o  The QTYPE does not equal NSEC3.
-   These conditions describe a particular case: the answer should be a
-   NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to
-   include in the authority section.
-
-   However, the NSEC3 RRset with ownername equal to QNAME is able to
-   prove its own existence.  Thus, when answering this query, the
-   authoritative server MUST include the NSEC3 RRset whose ownername
-   equals QNAME.  This RRset proves that QNAME is an existing name with
-   types NSEC3 and RRSIG.  The authoritative server MUST also include
-   the NSEC3 RRset that covers the hash of QNAME.  This RRset proves
-   that no other types exist.
-
-   When validating a NOERROR/NODATA response, validators MUST check for
-   a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
-   (validated) NSEC3 RRset as proof that QNAME exists.  The validator
-   MUST also check for an NSEC3 RRset that covers the hash of QNAME as
-   proof that QTYPE doesn't exist.
-
-   Other cases where the QNAME equals an existing NSEC3 ownername may be
-   answered normally.
-
-
-8.  Special Considerations
-
-   The following paragraphs clarify specific behaviour explain special
-   considerations for implementations.
-
-8.1.  Proving Nonexistence
-
-   If a wildcard resource record appears in a zone, its asterisk label
-   is treated as a literal symbol and is treated in the same way as any
-   other ownername for purposes of generating NSEC3 RRs.  RFC 4035 [5]
-   describes the impact of wildcards on authenticated denial of
-   existence.
-
-   In order to prove there exist no RRs for a domain, as well as no
-   source of synthesis, an RR must be shown for the closest encloser,
-   and non-existence must be shown for all closer labels and for the
-   wildcard at the closest encloser.
-
-   This can be done as follows.  If the QNAME in the query is
-   omega.alfa.beta.example, and the closest encloser is beta.example
-   (the nearest ancestor to omega.alfa.beta.example), then the server
-   should return an NSEC3 that demonstrates the nonexistence of
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 13]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
-   *.beta.example, and an NSEC3 that demonstrates the existence of
-   beta.example.  This takes between one and three NSEC3 records, since
-   a single record can, by chance, prove more than one of these facts.
-
-   When a verifier checks this response, then the existence of
-   beta.example together with the non-existence of alfa.beta.example
-   proves that the closest encloser is indeed beta.example.  The non-
-   existence of *.beta.example shows that there is no wildcard at the
-   closest encloser, and so no source of synthesis for
-   omega.alfa.beta.example.  These two facts are sufficient to satisfy
-   the resolver that the QNAME cannot be resolved.
-
-   In practice, since the NSEC3 owner and next names are hashed, if the
-   server responds with an NSEC3 for beta.example, the resolver will
-   have to try successively longer names, starting with example, moving
-   to beta.example, alfa.beta.example, and so on, until one of them
-   hashes to a value that matches the interval (but not the ownername
-   nor next owner name) of one of the returned NSEC3s (this name will be
-   alfa.beta.example).  Once it has done this, it knows the closest
-   encloser (i.e. beta.example), and can then easily check the other two
-   required proofs.
-
-   Note that it is not possible for one of the shorter names tried by
-   the resolver to be denied by one of the returned NSEC3s, since, by
-   definition, all these names exist and so cannot appear within the
-   range covered by an NSEC3.  Note, however, that the first name that
-   the resolver tries MUST be the apex of the zone, since names above
-   the apex could be denied by one of the returned NSEC3s.
-
-8.2.  Salting
-
-   Augmenting original ownernames with salt before hashing increases the
-   cost of a dictionary of pre-generated hash-values.  For every bit of
-   salt, the cost of a precomputed dictionary doubles (because there
-   must be an entry for each word combined with each possible salt
-   value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
-   salt, multiplying the cost by 2^2040.  This means that an attacker
-   must, in practice, recompute the dictionary each time the salt is
-   changed.
-
-   There MUST be at least one complete set of NSEC3s for the zone using
-   the same salt value.
-
-   The salt SHOULD be changed periodically to prevent precomputation
-   using a single salt.  It is RECOMMENDED that the salt be changed for
-   every resigning.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 14]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   Note that this could cause a resolver to see records with different
-   salt values for the same zone.  This is harmless, since each record
-   stands alone (that is, it denies the set of ownernames whose hashes,
-   using the salt in the NSEC3 record, fall between the two hashes in
-   the NSEC3 record) - it is only the server that needs a complete set
-   of NSEC3 records with the same salt in order to be able to answer
-   every possible query.
-
-   There is no prohibition with having NSEC3 with different salts within
-   the same zone.  However, in order for authoritative servers to be
-   able to consistently find covering NSEC3 RRs, the authoritative
-   server MUST choose a single set of parameters (algorithm, salt, and
-   iterations) to use when selecting NSEC3s.  In the absence of any
-   other metadata, the server does this by using the parameters from the
-   zone apex NSEC3, recognizable by the presence of the SOA bit in the
-   type map.  If there is more than one NSEC3 record that meets this
-   description, then the server may arbitrarily choose one.  Because of
-   this, if there is a zone apex NSEC3 RR within a zone, it MUST be part
-   of a complete NSEC3 set.  Conversely, if there exists an incomplete
-   set of NSEC3 RRs using the same parameters within a zone, there MUST
-   NOT be an NSEC3 RR using those parameters with the SOA bit set.
-
-8.3.  Iterations
-
-   Setting the number of iterations used allows the zone owner to choose
-   the cost of computing a hash, and so the cost of generating a
-   dictionary.  Note that this is distinct from the effect of salt,
-   which prevents the use of a single precomputed dictionary for all
-   time.
-
-   Obviously the number of iterations also affects the zone owner's cost
-   of signing the zone as well as the verifiers cost of verifying the
-   zone.  We therefore impose an upper limit on the number of
-   iterations.  We base this on the number of iterations that
-   approximately doubles the cost of signing the zone.
-
-   A zone owner MUST NOT use a value higher than shown in the table
-   below for iterations.  A resolver MAY treat a response with a higher
-   value as bogus.
-
-                       +--------------+------------+
-                       | RSA Key Size | Iterations |
-                       +--------------+------------+
-                       | 1024         | 3,000      |
-                       | 2048         | 20,000     |
-                       | 4096         | 150,000    |
-                       +--------------+------------+
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 15]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                       +--------------+------------+
-                       | DSA Key Size | Iterations |
-                       +--------------+------------+
-                       | 1024         | 1,500      |
-                       | 2048         | 5,000      |
-                       +--------------+------------+
-
-   This table is based on 150,000 SHA-1's per second, 50 RSA signs per
-   second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1
-   sign per second for 4096 bit keys, 100 DSA signs per second for 1024
-   bit keys and 30 signs per second for 2048 bit keys.
-
-   Note that since RSA verifications are 10-100 times faster than
-   signatures (depending on key size), in the case of RSA the legal
-   values of iterations can substantially increase the cost of
-   verification.
-
-8.4.  Hash Collision
-
-   Hash collisions occur when different messages have the same hash
-   value.  The expected number of domain names needed to give a 1 in 2
-   chance of a single collision is about 2^(n/2) for a hash of length n
-   bits (i.e. 2^80 for SHA-1).  Though this probability is extremely
-   low, the following paragraphs deal with avoiding collisions and
-   assessing possible damage in the event of an attack using hash
-   collisions.
-
-8.4.1.  Avoiding Hash Collisions during generation
-
-   During generation of NSEC3 RRs, hash values are supposedly unique.
-   In the (academic) case of a collision occurring, an alternative salt
-   MUST be chosen and all hash values MUST be regenerated.
-
-8.4.2.  Second Preimage Requirement Analysis
-
-   A cryptographic hash function has a second-preimage resistance
-   property.  The second-preimage resistance property means that it is
-   computationally infeasible to find another message with the same hash
-   value as a given message, i.e. given preimage X, to find a second
-   preimage X' != X such that hash(X) = hash(X').  The work factor for
-   finding a second preimage is of the order of 2^160 for SHA-1.  To
-   mount an attack using an existing NSEC3 RR, an adversary needs to
-   find a second preimage.
-
-   Assuming an adversary is capable of mounting such an extreme attack,
-   the actual damage is that a response message can be generated which
-   claims that a certain QNAME (i.e. the second pre-image) does exist,
-   while in reality QNAME does not exist (a false positive), which will
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 16]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   either cause a security aware resolver to re-query for the non-
-   existent name, or to fail the initial query.  Note that the adversary
-   can't mount this attack on an existing name but only on a name that
-   the adversary can't choose and does not yet exist.
-
-8.4.3.  Possible Hash Value Truncation Method
-
-   The previous sections outlined the low probability and low impact of
-   a second-preimage attack.  When impact and probability are low, while
-   space in a DNS message is costly, truncation is tempting.  Truncation
-   might be considered to allow for shorter ownernames and rdata for
-   hashed labels.  In general, if a cryptographic hash is truncated to n
-   bits, then the expected number of domains required to give a 1 in 2
-   probability of a single collision is approximately 2^(n/2) and the
-   work factor to produce a second preimage is 2^n.
-
-   An extreme hash value truncation would be truncating to the shortest
-   possible unique label value.  This would be unwise, since the work
-   factor to produce second preimages would then approximate the size of
-   the zone (sketch of proof: if the zone has k entries, then the length
-   of the names when truncated down to uniqueness should be proportional
-   to log_2(k).  Since the work factor to produce a second pre-image is
-   2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where
-   C is some constant), i.e.  C'k - a work factor of k).
-
-   Though the mentioned truncation can be maximized to a certain
-   extreme, the probability of collision increases exponentially for
-   every truncated bit.  Given the low impact of hash value collisions
-   and limited space in DNS messages, the balance between truncation
-   profit and collision damage may be determined by local policy.  Of
-   course, the size of the corresponding RRSIG RR is not reduced, so
-   truncation is of limited benefit.
-
-   Truncation could be signaled simply by reducing the length of the
-   first label in the ownername.  Note that there would have to be a
-   corresponding reduction in the length of the Next Hashed Ownername
-   field.
-
-8.4.4.  Server Response to a Run-time Collision
-
-   In the astronomically unlikely event that a server is unable to prove
-   nonexistence because the hash of the name that does not exist
-   collides with a name that does exist, the server is obviously broken,
-   and should, therefore, return a response with an RCODE of 2 (server
-   failure).
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 17]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-8.4.5.  Parameters that Cover the Zone
-
-   Secondary servers (and perhaps other entities) need to reliably
-   determine which NSEC3 parameters (that is, hash, salt and iterations)
-   are present at every hashed ownername, in order to be able to choose
-   an appropriate set of NSEC3 records for negative responses.  This is
-   indicated by the parameters at the apex: any set of parameters that
-   is used in an NSEC3 record whose original ownername is the apex of
-   the zone MUST be present throughout the zone.
-
-   A method to determine which NSEC3 in a complete chain corresponds to
-   the apex is to look for a NSEC3 RRset which has the SOA bit set in
-   the RDATA bit type maps field.
-
-
-9.  Performance Considerations
-
-   Iterated hashes impose a performance penalty on both authoritative
-   servers and resolvers.  Therefore, the number of iterations should be
-   carefully chosen.  In particular it should be noted that a high value
-   for iterations gives an attacker a very good denial of service
-   attack, since the attacker need not bother to verify the results of
-   their queries, and hence has no performance penalty of his own.
-
-   On the other hand, nameservers with low query rates and limited
-   bandwidth are already subject to a bandwidth based denial of service
-   attack, since responses are typically an order of magnitude larger
-   than queries, and hence these servers may choose a high value of
-   iterations in order to increase the difficulty of offline attempts to
-   enumerate their namespace without significantly increasing their
-   vulnerability to denial of service attacks.
-
-
-10.  IANA Considerations
-
-   IANA needs to allocate a RR type code for NSEC3 from the standard RR
-   type space (type XXX requested).  IANA needs to open a new registry
-   for the NSEC3 Hash Functions.  The range for this registry is 0-127.
-   Defined types are:
-
-      0 is reserved.
-      1 is SHA-1 ([13]).
-      127 is experimental.
-
-
-11.  Security Considerations
-
-   The NSEC3 records are still susceptible to dictionary attacks (i.e.
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 18]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   the attacker retrieves all the NSEC3 records, then calculates the
-   hashes of all likely domain names, comparing against the hashes found
-   in the NSEC3 records, and thus enumerating the zone).  These are
-   substantially more expensive than enumerating the original NSEC
-   records would have been, and in any case, such an attack could also
-   be used directly against the name server itself by performing queries
-   for all likely names, though this would obviously be more detectable.
-   The expense of this off-line attack can be chosen by setting the
-   number of iterations in the NSEC3 RR.
-
-   Domains are also susceptible to a precalculated dictionary attack -
-   that is, a list of hashes for all likely names is computed once, then
-   NSEC3 is scanned periodically and compared against the precomputed
-   hashes.  This attack is prevented by changing the salt on a regular
-   basis.
-
-   Walking the NSEC3 RRs will reveal the total number of records in the
-   zone, and also what types they are.  This could be mitigated by
-   adding dummy entries, but certainly an upper limit can always be
-   found.
-
-   Hash collisions may occur.  If they do, it will be impossible to
-   prove the non-existence of the colliding domain - however, this is
-   fantastically unlikely, and, in any case, DNSSEC already relies on
-   SHA-1 to not collide.
-
-   Responses to queries where QNAME equals an NSEC3 ownername that has
-   no other types may be undetectably changed from a NOERROR/NODATA
-   response to a NAME ERROR response.
-
-   The Opt-In Flag (O) allows for unsigned names, in the form of
-   delegations to unsigned subzones, to exist within an otherwise signed
-   zone.  All unsigned names are, by definition, insecure, and their
-   validity or existence cannot by cryptographically proven.
-
-   In general:
-      Records with unsigned names (whether existing or not) suffer from
-      the same vulnerabilities as records in an unsigned zone.  These
-      vulnerabilities are described in more detail in [16] (note in
-      particular sections 2.3, "Name Games" and 2.6, "Authenticated
-      Denial").
-      Records with signed names have the same security whether or not
-      Opt-In is used.
-
-   Note that with or without Opt-In, an insecure delegation may be
-   undetectably altered by an attacker.  Because of this, the primary
-   difference in security when using Opt-In is the loss of the ability
-   to prove the existence or nonexistence of an insecure delegation
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 19]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   within the span of an Opt-In NSEC3 record.
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete records with unsigned names.  These records are
-   normally NS records, but this also includes signed wildcard
-   expansions (while the wildcard record itself is signed, its expanded
-   name is an unsigned name).
-
-   For example, if a resolver received the following response from the
-   example zone above:
-
-   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
-
-           RCODE=NOERROR
-
-           Answer Section:
-
-           Authority Section:
-           DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
-           EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
-                                          RRSIG DNSKEY
-           abcd...                 RRSIG  NSEC3 ...
-
-           Additional Section:
-
-   The resolver would have no choice but to accept that the referral to
-   NS.FORGED. is valid.  If a wildcard existed that would have been
-   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
-   have undetectably removed it and replaced it with the forged
-   delegation.
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any record type: an attacker merely has to forge
-   a delegation to nameserver under his/her control and place whatever
-   records needed at the subzone apex.
-
-   While in particular cases, this issue may not present a significant
-   security problem, in general it should not be lightly dismissed.
-   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to using Opt-In,
-   and MAY choose to not support Opt-In at all.
-
-
-12.  References
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 20]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-12.1.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities",
-         STD 13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033,
-         March 2005.
-
-   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Protocol Modifications for the DNS Security Extensions",
-         RFC 4035, March 2005.
-
-   [6]   Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
-         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-         April 1997.
-
-   [7]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-         RFC 2181, July 1997.
-
-   [8]   Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-         RFC 2308, March 1998.
-
-   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [10]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-         RFC 3658, December 2003.
-
-   [11]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain
-         Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
-         September 2000.
-
-   [12]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-   [13]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
-         RFC 3174, September 2001.
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 21]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-12.2.  Informative References
-
-   [14]  Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)",
-         draft-vixie-dnssec-ter-01 (work in progress), June 2004.
-
-   [15]  Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data
-         Encodings.", draft-josefsson-rfc3548bis-00 (work in progress),
-         October 2005.
-
-   [16]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-         System (DNS)", RFC 3833, August 2004.
-
-Editorial Comments
-
-   [Comment.1]  Although, strictly speaking, the names *did* exist.
-
-   [Comment.2]  Note that this method makes it impossible to detect
-                (extremely unlikely) hash collisions.
-
-
-Appendix A.  Example Zone
-
-   This is a zone showing its NSEC3 records.  They can also be used as
-   test vectors for the hash algorithm.
-
-   The data in the example zone is currently broken, as it uses a
-   different base32 alphabet.  This shall be fixed in the next release.
-
-
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600 )
-                  3600 RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-                  3600 NS     ns1.example.
-                  3600 NS     ns2.example.
-                  3600 RRSIG  NS 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
-                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
-                              1SH5r/wfjuCg+g== )
-                  3600 MX     1 xx.example.
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 22]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                  3600 RRSIG  MX 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
-                              NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
-                              S/o/g5C8VM6ftQ== )
-                  3600 DNSKEY 257 3 5 (
-                              AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
-                              cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
-                              zsYKWJ7BvR2894hX
-                              ) ; Key ID = 21960
-                  3600 DNSKEY 256 3 5 (
-                              AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
-                              5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
-                              ExXT48OGGdbfIme5
-                              ) ; Key ID = 62699
-                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
-                              xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
-                              mTkunTYzqWJrmQ== )
-                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
-                              20050612112304 21960 example.
-                              SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
-                              ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
-                              3w7ZY2UWyYIvpw== )
-   5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              7nomf47k3vlidh4vxahhpp47l3tgv7a2
-                              NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
-                              Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
-                              sb7KfbaUo/vzAg== )
-   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
-                              MX NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
-                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
-                              MEFQmc/gEuxojA== )
-   a.example.     3600 IN NS  ns1.a.example.
-                  3600 IN NS  ns2.a.example.
-                  3600 DS     58470 5 1 3079F1593EBAD6DC121E202A8B
-                              766A6A4837206C )
-                  3600 RRSIG  DS 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 23]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              20050612112304 62699 example.
-                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
-                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
-                              0kx7rGKTc3RQDA== )
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-   ai.example.    3600 IN A   192.0.2.9
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
-                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
-                              ZXW5S+1VjMZYzQ== )
-                  3600 HINFO  "KLH-10" "ITS"
-                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
-                              tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
-                              VGNmbgPnqDVPiA== )
-                  3600 AAAA   2001:db8:0:0:0:0:f00:baa9
-                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
-                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
-                              l5/UqLCJJ9BDMg== )
-   b.example.     3600 IN NS  ns1.b.example.
-                  3600 IN NS  ns2.b.example.
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              gmnfcccja7wkax3iv26bs75myptje3qk
-                              MX DNSKEY NS SOA NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
-                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
-                              MOiKMSHozVebqw== )
-   gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
-                              DS NS NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
-                              ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
-                              OwQBGbOegrW/Zw== )
-   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 24]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              kcll7fqfnisuhfekckeeqnmbbd4maanu
-                              NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
-                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
-                              94Zbq3k8lgdpZA== )
-   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3  1 1 1 (
-                              deadbeaf
-                              n42hbhnjj333xdxeybycax5ufvntux5d
-                              MX NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
-                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
-                              TOLtc5jPrkL4zQ== )
-   n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              nimwfwcnbeoodmsc6npv3vuaagaevxxu
-                              A NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
-                              91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
-                              xFPFGRIW3wKnrA== )
-   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
-                              HINFO A AAAA NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
-                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
-                              jL33Wm1p07TBdw== )
-   ns1.example.   3600 A      192.0.2.1
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
-                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
-                              nWWLepz1PjjShQ== )
-   ns2.example.   3600 A      192.0.2.2
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
-                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
-                              AkeTJu3J3auUiA== )
-   vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 25]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              wbyijvpnyj33pcpi3i44ecnibnaj7eiw
-                              HINFO A AAAA NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
-                              kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
-                              5SNSHIyfpfsi6A== )
-   *.w.example.   3600 MX     1 ai.example.
-                  3600 RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
-                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
-                              gQlgxEwhvQDEaQ== )
-   x.w.example.   3600 MX     1 xx.example.
-                  3600 RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
-                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
-                              U9VazOa1KEIq1w== )
-   x.y.w.example. 3600 MX     1 xx.example.
-                  3600 RRSIG  MX 5 4 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
-                              uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
-                              9VrQvJjwbllAfA== )
-   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
-                              A NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
-                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
-                              oorBv4xkb0flXw== )
-   xx.example.    3600 A      192.0.2.10
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
-                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
-                              cxwCXWj82GVGdw== )
-                  3600 HINFO  "KLH-10" "TOPS-20"
-                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
-                              OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
-                              KMf4DgNBDj+dIQ== )
-                  3600 AAAA   2001:db8:0:0:0:0:f00:baaa
-                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 26]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              20050612112304 62699 example.
-                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
-                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
-                              rzKKwb8J04/ILw== )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
-                              MX NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
-                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
-                              OcFlrPGPMm48/A== )
-
-
-Appendix B.  Example Responses
-
-   The examples in this section show response messages using the signed
-   zone example in Appendix A.
-
-B.1.  answer
-
-   A successful query to an authoritative server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 27]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   x.w.example.        IN MX
-
-   ;; Answer
-   x.w.example.   3600 IN MX  1 xx.example.
-   x.w.example.   3600 IN RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
-                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
-                              U9VazOa1KEIq1w== )
-
-   ;; Authority
-   example.       3600 IN NS  ns1.example.
-   example.       3600 IN NS  ns2.example.
-   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
-                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
-                              1SH5r/wfjuCg+g== )
-
-   ;; Additional
-   xx.example.    3600 IN A   192.0.2.10
-   xx.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
-                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
-                              cxwCXWj82GVGdw== )
-   xx.example.    3600 IN AAAA   2001:db8::f00:baaa
-   xx.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
-                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
-                              rzKKwb8J04/ILw== )
-   ns1.example.   3600 IN A   192.0.2.1
-   ns1.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
-                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
-                              nWWLepz1PjjShQ== )
-   ns2.example.   3600 IN A   192.0.2.2
-   ns2.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
-                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
-                              AkeTJu3J3auUiA== )
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 28]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   The query returned an MX RRset for "x.w.example".  The corresponding
-   RRSIG RR indicates that the MX RRset was signed by an "example"
-   DNSKEY with algorithm 5 and key tag 62699.  The resolver needs the
-   corresponding DNSKEY RR in order to authenticate this answer.  The
-   discussion below describes how a resolver might obtain this DNSKEY
-   RR.
-
-   The RRSIG RR indicates the original TTL of the MX RRset was 3600,
-   and, for the purpose of authentication, the current TTL is replaced
-   by 3600.  The RRSIG RR's labels field value of 3 indicates that the
-   answer was not the result of wildcard expansion.  The "x.w.example"
-   MX RRset is placed in canonical form, and, assuming the current time
-   falls between the signature inception and expiration dates, the
-   signature is authenticated.
-
-B.1.1.  Authenticating the Example DNSKEY RRset
-
-   This example shows the logical authentication process that starts
-   from a configured root DNSKEY RRset (or DS RRset) and moves down the
-   tree to authenticate the desired "example" DNSKEY RRset.  Note that
-   the logical order is presented for clarity.  An implementation may
-   choose to construct the authentication as referrals are received or
-   to construct the authentication chain only after all RRsets have been
-   obtained, or in any other combination it sees fit.  The example here
-   demonstrates only the logical process and does not dictate any
-   implementation rules.
-
-   We assume the resolver starts with a configured DNSKEY RRset for the
-   root zone (or a configured DS RRset for the root zone).  The resolver
-   checks whether this configured DNSKEY RRset is present in the root
-   DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
-   RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
-   root DNSKEY RRset, and whether the signature lifetime is valid.  If
-   all these conditions are met, all keys in the DNSKEY RRset are
-   considered authenticated.  The resolver then uses one (or more) of
-   the root DNSKEY RRs to authenticate the "example" DS RRset.  Note
-   that the resolver may have to query the root zone to obtain the root
-   DNSKEY RRset or "example" DS RRset.
-
-   Once the DS RRset has been authenticated using the root DNSKEY, the
-   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
-   RR that matches one of the authenticated "example" DS RRs.  If such a
-   matching "example" DNSKEY is found, the resolver checks whether this
-   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
-   lifetime is valid.  If these conditions are met, all keys in the
-   "example" DNSKEY RRset are considered authenticated.
-
-   Finally, the resolver checks that some DNSKEY RR in the "example"
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 29]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   DNSKEY RRset uses algorithm 5 and has a key tag of 62699.  This
-   DNSKEY is used to authenticate the RRSIG included in the response.
-   If multiple "example" DNSKEY RRs match this algorithm and key tag,
-   then each DNSKEY RR is tried, and the answer is authenticated if any
-   of the matching DNSKEY RRs validate the signature as described above.
-
-B.2.  Name Error
-
-   An authoritative name error.  The NSEC3 RRs prove that the name does
-   not exist and that no covering wildcard exists.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 30]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=3
-   ;;
-   ;; Question
-   a.c.x.w.example.         IN A
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
-                              MX NSEC3 RRSIG )
-   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
-                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
-                              MEFQmc/gEuxojA== )
-   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
-                              HINFO A AAAA NSEC3 RRSIG )
-   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
-                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
-                              jL33Wm1p07TBdw== )
-   ;; Additional
-   ;; (empty)
-
-   The query returned two NSEC3 RRs that prove that the requested data
-   does not exist and no wildcard applies.  The negative reply is
-   authenticated by verifying both NSEC3 RRs.  The NSEC3 RRs are
-   authenticated in a manner identical to that of the MX RRset discussed
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 31]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   above.  At least one of the owner names of the NSEC3 RRs will match
-   the closest encloser.  At least one of the NSEC3 RRs prove that there
-   exists no longer name.  At least one of the NSEC3 RRs prove that
-   there exists no wildcard RRsets that should have been expanded.  The
-   closest encloser can be found by hashing the apex ownername (The SOA
-   RR's ownername, or the ownername of the DNSKEY RRset referred by an
-   RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
-   if that fails, continue by adding labels.  In other words, the
-   resolver first hashes example, checks for a matching NSEC3 ownername,
-   then hashes w.example, checks, and finally hashes w.x.example and
-   checks.
-
-   In the above example, the name 'x.w.example' hashes to
-   '7nomf47k3vlidh4vxahhpp47l3tgv7a2'.  This indicates that this might
-   be the closest encloser.  To prove that 'c.x.w.example' and
-   '*.x.w.example' do not exists, these names are hashed to respectively
-   'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
-   'cvljzyf6nsckjowghch4tt3nohocpdka'.  The two NSEC3 records prove that
-   these hashed ownernames do not exists, since the names are within the
-   given intervals.
-
-B.3.  No Data Error
-
-   A "no data" response.  The NSEC3 RR proves that the name exists and
-   that the requested RR type does not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 32]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   ns1.example.        IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
-                              A NSEC3 RRSIG )
-   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
-                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
-                              oorBv4xkb0flXw== )
-   ;; Additional
-   ;; (empty)
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
-   but the requested RR type does not exist (type MX is absent in the
-   type code list of the NSEC RR).  The negative reply is authenticated
-   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
-   identical to that of the MX RRset discussed above.
-
-B.3.1.  No Data Error, Empty Non-Terminal
-
-   A "no data" response because of an empty non-terminal.  The NSEC3 RR
-   proves that the name exists and that the requested RR type does not.
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 33]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   y.w.example.        IN A
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              kcll7fqfnisuhfekckeeqnmbbd4maanu
-                              NSEC3 RRSIG )
-   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
-                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
-                              94Zbq3k8lgdpZA== )
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
-   but the requested RR type does not exist (Type A is absent in the
-   type-bit-maps of the NSEC3 RR).  The negative reply is authenticated
-   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
-   identical to that of the MX RRset discussed above.  Note that, unlike
-   generic empty non terminal proof using NSECs, this is identical to
-   proving a No Data Error.  This example is solely mentioned to be
-   complete.
-
-B.4.  Referral to Signed Zone
-
-   Referral to a signed zone.  The DS RR contains the data which the
-   resolver will need to validate the corresponding DNSKEY RR in the
-   child zone's apex.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 34]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR DO RCODE=0
-   ;;
-
-   ;; Question
-   mc.a.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   a.example.     3600 IN NS  ns1.a.example.
-   a.example.     3600 IN NS  ns2.a.example.
-   a.example.     3600 IN DS  58470 5 1 (
-                              3079F1593EBAD6DC121E202A8B766A6A4837
-                              206C )
-   a.example.     3600 IN RRSIG  DS 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
-                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
-                              0kx7rGKTc3RQDA== )
-
-   ;; Additional
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-
-   The query returned a referral to the signed "a.example." zone.  The
-   DS RR is authenticated in a manner identical to that of the MX RRset
-   discussed above.  This DS RR is used to authenticate the "a.example"
-   DNSKEY RRset.
-
-   Once the "a.example" DS RRset has been authenticated using the
-   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
-   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
-   matching "a.example" DNSKEY is found, the resolver checks whether
-   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
-   the signature lifetime is valid.  If all these conditions are met,
-   all keys in the "a.example" DNSKEY RRset are considered
-   authenticated.
-
-B.5.  Referral to Unsigned Zone using the Opt-In Flag
-
-   The NSEC3 RR proves that nothing for this delegation was signed in
-   the parent zone.  There is no proof that the delegation exists
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 35]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR DO RCODE=0
-   ;;
-   ;; Question
-   mc.b.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   b.example.     3600 IN NS  ns1.b.example.
-   b.example.     3600 IN NS  ns2.b.example.
-   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3  1 1 1 (
-                              deadbeaf
-                              n42hbhnjj333xdxeybycax5ufvntux5d
-                              MX NSEC3 RRSIG )
-   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
-                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
-                              TOLtc5jPrkL4zQ== )
-
-   ;; Additional
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-
-   The query returned a referral to the unsigned "b.example." zone.  The
-   NSEC3 proves that no authentication leads from "example" to
-   "b.example", since the hash of "b.example"
-   ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
-   the NSEC3 opt-in bit is set.  The NSEC3 RR is authenticated in a
-   manner identical to that of the MX RRset discussed above.
-
-B.6.  Wildcard Expansion
-
-   A successful query that was answered via wildcard expansion.  The
-   label count in the answer's RRSIG RR indicates that a wildcard RRset
-   was expanded to produce this response, and the NSEC3 RR proves that
-   no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 36]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN MX
-
-   ;; Answer
-   a.z.w.example. 3600 IN MX  1 ai.example.
-   a.z.w.example. 3600 IN RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
-                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
-                              gQlgxEwhvQDEaQ== )
-   ;; Authority
-   example.       3600 NS     ns1.example.
-   example.       3600 NS     ns2.example.
-   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
-                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
-                              1SH5r/wfjuCg+g== )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
-                              MX NSEC3 RRSIG )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
-                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
-                              OcFlrPGPMm48/A== )
-   ;; Additional
-   ai.example.    3600 IN A   192.0.2.9
-   ai.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
-                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
-                              ZXW5S+1VjMZYzQ== )
-   ai.example.    3600 AAAA   2001:db8::f00:baa9
-   ai.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
-                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
-                              l5/UqLCJJ9BDMg== )
-
-   The query returned an answer that was produced as a result of
-   wildcard expansion.  The answer section contains a wildcard RRset
-   expanded as it would be in a traditional DNS response, and the
-   corresponding RRSIG indicates that the expanded wildcard MX RRset was
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 37]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
-   The RRSIG indicates that the original TTL of the MX RRset was 3600,
-   and, for the purpose of authentication, the current TTL is replaced
-   by 3600.  The RRSIG labels field value of 2 indicates that the answer
-   is the result of wildcard expansion, as the "a.z.w.example" name
-   contains 4 labels.  The name "a.z.w.example" is replaced by
-   "*.w.example", the MX RRset is placed in canonical form, and,
-   assuming that the current time falls between the signature inception
-   and expiration dates, the signature is authenticated.
-
-   The NSEC3 proves that no closer match (exact or closer wildcard)
-   could have been used to answer this query, and the NSEC3 RR must also
-   be authenticated before the answer is considered valid.
-
-B.7.  Wildcard No Data Error
-
-   A "no data" response for a name covered by a wildcard.  The NSEC3 RRs
-   prove that the matching wildcard name does not have any RRs of the
-   requested type and that no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 38]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN AAAA
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
-                              MX NSEC3 RRSIG )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
-                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
-                              OcFlrPGPMm48/A== )
-   ;; Additional
-   ;; (empty)
-
-   The query returned NSEC3 RRs that prove that the requested data does
-   not exist and no wildcard applies.  The negative reply is
-   authenticated by verifying both NSEC3 RRs.
-
-B.8.  DS Child Zone No Data Error
-
-   A "no data" response for a QTYPE=DS query that was mistakenly sent to
-   a name server for the child zone.
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 39]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   example.            IN DS
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              gmnfcccja7wkax3iv26bs75myptje3qk
-                              MX DNSKEY NS SOA NSEC3 RRSIG )
-   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
-                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
-                              MOiKMSHozVebqw== )
-
-   ;; Additional
-   ;; (empty)
-
-   The query returned NSEC RRs that shows the requested was answered by
-   a child server ("example" server).  The NSEC RR indicates the
-   presence of an SOA RR, showing that the answer is from the child .
-   Queries for the "example" DS RRset should be sent to the parent
-   servers ("root" servers).
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 40]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-Authors' Addresses
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London  W3 7LR
-   England
-
-   Phone: +44 (20) 8735 0686
-   Email: ben@algroup.co.uk
-
-
-   Geoffrey Sisson
-   Nominet
-
-
-   Roy Arends
-   Nominet
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 41]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 42]
-
diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/draft/draft-ietf-dnsext-nsid-01.txt
deleted file mode 100644
index 90d1a0609d42..000000000000
--- 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-06.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
deleted file mode 100644
index 5b6d655297e8..000000000000
--- a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
+++ /dev/null
@@ -1,464 +0,0 @@
-
-INTERNET-DRAFT                                DSA Information in the DNS
-OBSOLETES: RFC 2536                               Donald E. Eastlake 3rd
-                                                   Motorola Laboratories
-Expires: January 2006                                          July 2005
-
-
-            DSA Keying and Signature Information in the DNS
-            --- ------ --- --------- ----------- -- --- ---
-               
-                         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
-   .
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   The standard method of encoding US Government Digital Signature
-   Algorithm keying and signature information for use in the Domain Name
-   System is specified.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. DSA Keying Information..................................3
-      3. DSA Signature Information...............................4
-      4. Performance Considerations..............................4
-      5. Security Considerations.................................5
-      6. IANA Considerations.....................................5
-      Copyright and Disclaimer...................................5
-
-      Normative References.......................................7
-      Informative References.....................................7
-
-      Authors Address............................................8
-      Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information [RFC 1034, 1035]. The DNS has been extended to
-   include digital signatures and cryptographic keys as described in
-   [RFC 4033, 4034, 4035] and additional work is underway which would
-   require the storage of keying and signature information in the DNS.
-
-   This document describes how to encode US Government Digital Signature
-   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
-   US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
-   When DSA public keys are stored in the DNS, the structure of the
-   relevant part of the RDATA part of the RR being used is the fields
-   listed below in the order given.
-
-   The period of key validity is not included in this data but is
-   indicated separately, for example by an RR such as RRSIG which signs
-   and authenticates the RR containing the keying information.
-
-        Field     Size
-        -----     ----
-         T         1  octet
-         Q        20  octets
-         P        64 + T*8  octets
-         G        64 + T*8  octets
-         Y        64 + T*8  octets
-
-   As described in [FIPS 186-2] and [Schneier], T is a key size
-   parameter chosen such that 0 <= T <= 8.  (The meaning if the T octet
-   is greater than 8 is reserved and the remainder of the data may have
-   a different format in that case.)  Q is a prime number selected at
-   key generation time such that 2**159 < Q < 2**160. Thus Q is always
-   20 octets long and, as with all other fields, is stored in "big-
-   endian" network order.  P, G, and Y are calculated as directed by the
-   [FIPS 186-2] key generation algorithm [Schneier].  P is in the range
-   2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long.  G
-   and Y are quantities modulo P and so can be up to the same length as
-   P and are allocated fixed size fields with the same number of octets
-   as P.
-
-   During the key generation process, a random number X must be
-   generated such that 1 <= X <= Q-1.  X is the private key and is used
-   in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-        Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
-   The portion of the RDATA area used for US Digital Signature Algorithm
-   signature information is shown below with fields in the order they
-   are listed and the contents of each multi-octet field in "big-endian"
-   network order.
-
-        Field     Size
-        -----     ----
-         T         1 octet
-         R        20 octets
-         S        20 octets
-
-   First, the data signed must be determined.  Then the following steps
-   are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
-   specified in the public key [Schneier]:
-
-        hash = SHA-1 ( data )
-
-        Generate a random K such that 0 < K < Q.
-
-        R = ( G**K mod P ) mod Q
-
-        S = ( K**(-1) * (hash + X*R) ) mod Q
-
-   For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
-   3174].
-
-   Since Q is 160 bits long, R and S can not be larger than 20 octets,
-   which is the space allocated.
-
-   T is copied from the public key.  It is not logically necessary in
-   the SIG but is present so that values of T > 8 can more conveniently
-   be used as an escape for extended versions of DSA or other algorithms
-   as later standardized.
-
-
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA [RFC
-   3110] and DSA.  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower than
-   RSA when the RSA public exponent is chosen to be small, as is
-   recommended for some applications.
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC 2671] to make larger transfers more efficient, it
-   is still advisable at this time to make reasonable efforts to
-   minimize the size of RR sets containing keying and/or signature
-   inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
-   Keys retrieved from the DNS should not be trusted unless (1) they
-   have been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
-   current DSA standard may limit the security of DSA.  For particular
-   applications, implementors are encouraged to consider the range of
-   available algorithms and key sizes.
-
-   DSA assumes the ability to frequently generate high quality random
-   numbers.  See [random] for guidance.  DSA is designed so that if
-   biased rather than random numbers are used, high bandwidth covert
-   channels are possible.  See [Schneier] and more recent research.  The
-   leakage of an entire DSA private key in only two DSA signatures has
-   been demonstrated.  DSA provides security only if trusted
-   implementations, including trusted random number generation, are
-   used.
-
-
-
-6. IANA Considerations
-
-   Allocation of meaning to values of the T parameter that are not
-   defined herein (i.e., > 8 ) requires an IETF standards actions.  It
-   is intended that values unallocated herein be used to cover future
-   extensions of the DSS standard.
-
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2005).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except
-   as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Normative References
-
-   [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
-   Signature Standard, 27 January 2000.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-
-
-Informative References
-
-   [RFC 1034] - "Domain names - concepts and facilities", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 1035] - "Domain names - implementation and specification", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
-   1999.
-
-   [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
-   (DNS)", D.  Eastlake 3rd. May 2001.
-
-   [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
-   Jones, September 2001.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-   "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [Schneier] - "Applied Cryptography Second Edition: protocols,
-   algorithms, and source code in C" (second edition), Bruce Schneier,
-   1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Authors Address
-
-   Donald E. Eastlake 3rd
-   Motorola Labortories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554(w)
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in January 2006.
-
-   Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
deleted file mode 100644
index 2ec9dbec512e..000000000000
--- a/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                           August 30, 2005
-Expires: March 3, 2006
-
-
-          Storing Certificates in the Domain Name System (DNS)
-                    draft-ietf-dnsext-rfc2538bis-04
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 3, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   Cryptographic public keys are frequently published and their
-   authenticity demonstrated by certificates.  A CERT resource record
-   (RR) is defined so that such certificates and related certificate
-   revocation lists can be stored in the Domain Name System (DNS).
-
-   This document obsoletes RFC 2538.
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 1]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  The CERT Resource Record . . . . . . . . . . . . . . . . . . .  3
-     2.1.  Certificate Type Values  . . . . . . . . . . . . . . . . .  4
-     2.2.  Text Representation of CERT RRs  . . . . . . . . . . . . .  5
-     2.3.  X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.  Appropriate Owner Names for CERT RRs . . . . . . . . . . . . .  6
-     3.1.  Content-based X.509 CERT RR Names  . . . . . . . . . . . .  7
-     3.2.  Purpose-based X.509 CERT RR Names  . . . . . . . . . . . .  8
-     3.3.  Content-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
-     3.4.  Purpose-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
-     3.5.  Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . .  9
-   4.  Performance Considerations . . . . . . . . . . . . . . . . . . 10
-   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
-   9.  Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
-   Appendix A.  Copying conditions  . . . . . . . . . . . . . . . . . 12
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 2]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-1.  Introduction
-
-   Public keys are frequently published in the form of a certificate and
-   their authenticity is commonly demonstrated by certificates and
-   related certificate revocation lists (CRLs).  A certificate is a
-   binding, through a cryptographic digital signature, of a public key,
-   a validity interval and/or conditions, and identity, authorization,
-   or other information.  A certificate revocation list is a list of
-   certificates that are revoked, and incidental information, all signed
-   by the signer (issuer) of the revoked certificates.  Examples are
-   X.509 certificates/CRLs in the X.500 directory system or OpenPGP
-   certificates/revocations used by OpenPGP software.
-
-   Section 2 below specifies a CERT resource record (RR) for the storage
-   of certificates in the Domain Name System [1] [2].
-
-   Section 3 discusses appropriate owner names for CERT RRs.
-
-   Sections 4, 5, and 6 below cover performance, IANA, and security
-   considerations, respectively.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [3].
-
-
-2.  The CERT Resource Record
-
-   The CERT resource record (RR) has the structure given below.  Its RR
-   type code is 37.
-
-                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |             type              |             key tag           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   algorithm   |                                               /
-   +---------------+            certificate or CRL                 /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The type field is the certificate type as defined in section 2.1
-   below.
-
-   The key tag field is the 16 bit value computed for the key embedded
-   in the certificate, using the RRSIG Key Tag algorithm described in
-   Appendix B of [10].  This field is used as an efficiency measure to
-   pick which CERT RRs may be applicable to a particular key.  The key
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 3]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   tag can be calculated for the key in question and then only CERT RRs
-   with the same key tag need be examined.  However, the key must always
-   be transformed to the format it would have as the public key portion
-   of a DNSKEY RR before the key tag is computed.  This is only possible
-   if the key is applicable to an algorithm (and limits such as key size
-   limits) defined for DNS security.  If it is not, the algorithm field
-   MUST BE zero and the tag field is meaningless and SHOULD BE zero.
-
-   The algorithm field has the same meaning as the algorithm field in
-   DNSKEY and RRSIG RRs [10], except that a zero algorithm field
-   indicates the algorithm is unknown to a secure DNS, which may simply
-   be the result of the algorithm not having been standardized for
-   DNSSEC.
-
-2.1.  Certificate Type Values
-
-   The following values are defined or reserved:
-
-       Value  Mnemonic  Certificate Type
-       -----  --------  ----------------
-           0            reserved
-           1  PKIX      X.509 as per PKIX
-           2  SPKI      SPKI certificate
-           3  PGP       OpenPGP packet
-           4  IPKIX     The URL of an X.509 data object
-           5  ISPKI     The URL of an SPKI certificate
-           6  IPGP      The URL of an OpenPGP packet
-       7-252            available for IANA assignment
-         253  URI       URI private
-         254  OID       OID private
-   255-65534            available for IANA assignment
-       65535            reserved
-
-   The PKIX type is reserved to indicate an X.509 certificate conforming
-   to the profile being defined by the IETF PKIX working group.  The
-   certificate section will start with a one-byte unsigned OID length
-   and then an X.500 OID indicating the nature of the remainder of the
-   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
-   not include their X.500 directory type designating OID as a prefix.)
-
-   The SPKI type is reserved to indicate the SPKI certificate format
-   [13], for use when the SPKI documents are moved from experimental
-   status.
-
-   The PGP type indicates an OpenPGP packet as described in [6] and its
-   extensions and successors.  Two uses are to transfer public key
-   material and revocation signatures.  The data is binary, and MUST NOT
-   be encoded into an ASCII armor.  An implementation SHOULD process
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 4]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   transferable public keys as described in section 10.1 of [6], but it
-   MAY handle additional OpenPGP packets.
-
-   The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
-   content that would have been in the "certificate, CRL or URL" field
-   of the corresponding (PKIX, SPKI or PGP) packet types.  These types
-   are known as "indirect".  These packet types MUST be used when the
-   content is too large to fit in the CERT RR, and MAY be used at the
-   implementer's discretion.  They SHOULD NOT be used where the entire
-   UDP packet would have fit in 512 bytes.
-
-   The URI private type indicates a certificate format defined by an
-   absolute URI.  The certificate portion of the CERT RR MUST begin with
-   a null terminated URI [5] and the data after the null is the private
-   format certificate itself.  The URI SHOULD be such that a retrieval
-   from it will lead to documentation on the format of the certificate.
-   Recognition of private certificate types need not be based on URI
-   equality but can use various forms of pattern matching so that, for
-   example, subtype or version information can also be encoded into the
-   URI.
-
-   The OID private type indicates a private format certificate specified
-   by an ISO OID prefix.  The certificate section will start with a one-
-   byte unsigned OID length and then a BER encoded OID indicating the
-   nature of the remainder of the certificate section.  This can be an
-   X.509 certificate format or some other format.  X.509 certificates
-   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
-   type, not the OID private type.  Recognition of private certificate
-   types need not be based on OID equality but can use various forms of
-   pattern matching such as OID prefix.
-
-2.2.  Text Representation of CERT RRs
-
-   The RDATA portion of a CERT RR has the type field as an unsigned
-   decimal integer or as a mnemonic symbol as listed in section 2.1
-   above.
-
-   The key tag field is represented as an unsigned decimal integer.
-
-   The algorithm field is represented as an unsigned decimal integer or
-   a mnemonic symbol as listed in [10].
-
-   The certificate / CRL portion is represented in base 64 [14] and may
-   be divided up into any number of white space separated substrings,
-   down to single base 64 digits, which are concatenated to obtain the
-   full signature.  These substrings can span lines using the standard
-   parenthesis.
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 5]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   Note that the certificate / CRL portion may have internal sub-fields,
-   but these do not appear in the master file representation.  For
-   example, with type 254, there will be an OID size, an OID, and then
-   the certificate / CRL proper.  But only a single logical base 64
-   string will appear in the text representation.
-
-2.3.  X.509 OIDs
-
-   OIDs have been defined in connection with the X.500 directory for
-   user certificates, certification authority certificates, revocations
-   of certification authority, and revocations of user certificates.
-   The following table lists the OIDs, their BER encoding, and their
-   length-prefixed hex format for use in CERT RRs:
-
-       id-at-userCertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
-              == 0x 03 55 04 24
-       id-at-cACertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
-              == 0x 03 55 04 25
-       id-at-authorityRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
-              == 0x 03 55 04 26
-       id-at-certificateRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
-              == 0x 03 55 04 27
-
-
-3.  Appropriate Owner Names for CERT RRs
-
-   It is recommended that certificate CERT RRs be stored under a domain
-   name related to their subject, i.e., the name of the entity intended
-   to control the private key corresponding to the public key being
-   certified.  It is recommended that certificate revocation list CERT
-   RRs be stored under a domain name related to their issuer.
-
-   Following some of the guidelines below may result in the use in DNS
-   names of characters that require DNS quoting which is to use a
-   backslash followed by the octal representation of the ASCII code for
-   the character (e.g., \000 for NULL).
-
-   The choice of name under which CERT RRs are stored is important to
-   clients that perform CERT queries.  In some situations, the clients
-   may not know all information about the CERT RR object it wishes to
-   retrieve.  For example, a client may not know the subject name of an
-   X.509 certificate, or the e-mail address of the owner of an OpenPGP
-   key.  Further, the client might only know the hostname of a service
-   that uses X.509 certificates or the Key ID of an OpenPGP key.
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 6]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   Therefore, two owner name guidelines are defined: content-based owner
-   names and purpose-based owner names.  A content-based owner name is
-   derived from the content of the CERT RR data; for example, the
-   Subject field in an X.509 certificate or the User ID field in OpenPGP
-   keys.  A purpose-based owner name is a name that a client retrieving
-   CERT RRs MUST already know; for example, the host name of an X.509
-   protected service or the Key ID of an OpenPGP key.  The content-based
-   and purpose-based owner name MAY be the same; for example, when a
-   client looks up a key based on the From: address of an incoming
-   e-mail.
-
-   Implementations SHOULD use the purpose-based owner name guidelines
-   described in this document, and MAY use CNAMEs of content-based owner
-   names (or other names), pointing to the purpose-based owner name.
-
-3.1.  Content-based X.509 CERT RR Names
-
-   Some X.509 versions permit multiple names to be associated with
-   subjects and issuers under "Subject Alternate Name" and "Issuer
-   Alternate Name".  For example, X.509v3 has such Alternate Names with
-   an ASN.1 specification as follows:
-
-        GeneralName ::= CHOICE {
-           otherName                  [0] INSTANCE OF OTHER-NAME,
-           rfc822Name                 [1] IA5String,
-           dNSName                    [2] IA5String,
-           x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
-           directoryName              [4] EXPLICIT Name,
-           ediPartyName               [5] EDIPartyName,
-           uniformResourceIdentifier  [6] IA5String,
-           iPAddress                  [7] OCTET STRING,
-           registeredID               [8] OBJECT IDENTIFIER
-        }
-
-   The recommended locations of CERT storage are as follows, in priority
-   order:
-   1.  If a domain name is included in the identification in the
-       certificate or CRL, that should be used.
-   2.  If a domain name is not included but an IP address is included,
-       then the translation of that IP address into the appropriate
-       inverse domain name should be used.
-   3.  If neither of the above is used, but a URI containing a domain
-       name is present, that domain name should be used.
-   4.  If none of the above is included but a character string name is
-       included, then it should be treated as described for OpenPGP
-       names below.
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 7]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   5.  If none of the above apply, then the distinguished name (DN)
-       should be mapped into a domain name as specified in [4].
-
-   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
-   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
-   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
-   uri .  The storage locations
-   recommended, in priority order, would be
-   1.  john-doe.com,
-   2.  www.secure.john-doe.com, and
-   3.  Doe.com.xy.
-
-   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
-   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
-   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
-   (c) string "James Hacker ".  The
-   storage locations recommended, in priority order, would be
-   1.  widget.foo.example,
-   2.  201.13.251.10.in-addr.arpa, and
-   3.  hacker.mail.widget.foo.example.
-
-3.2.  Purpose-based X.509 CERT RR Names
-
-   Due to the difficulty for clients that do not already possess a
-   certificate to reconstruct the content-based owner name, purpose-
-   based owner names are recommended in this section.  Recommendations
-   for purpose-based owner names vary per scenario.  The following table
-   summarizes the purpose-based X.509 CERT RR owner name guidelines for
-   use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
-
-    Scenario             Owner name
-    ------------------   ----------------------------------------------
-    S/MIME Certificate   Standard translation of an RFC 2822 email
-                         address.  Example: An S/MIME certificate for
-                         "postmaster@example.org" will use a standard
-                         hostname translation of the owner name,
-                         "postmaster.example.org".
-
-    TLS Certificate      Hostname of the TLS server.
-
-    IPSEC Certificate    Hostname of the IPSEC machine and/or, for IPv4
-                         or IPv6 addresses, the fully qualified domain
-                         name in the appropriate reverse domain.
-
-   An alternate approach for IPSEC is to store raw public keys [15].
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 8]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-3.3.  Content-based OpenPGP CERT RR Names
-
-   OpenPGP signed keys (certificates) use a general character string
-   User ID [6].  However, it is recommended by OpenPGP that such names
-   include the RFC 2822 [8] email address of the party, as in "Leslie
-   Example ".  If such a format is used, the CERT
-   should be under the standard translation of the email address into a
-   domain name, which would be leslie.host.example in this case.  If no
-   RFC 2822 name can be extracted from the string name, no specific
-   domain name is recommended.
-
-   If a user has more than one email address, the CNAME type can be used
-   to reduce the amount of data stored in the DNS.  Example:
-
-      $ORIGIN example.org.
-      smith        IN CERT PGP 0 0 
-      john.smith   IN CNAME smith
-      js           IN CNAME smith
-
-3.4.  Purpose-based OpenPGP CERT RR Names
-
-   Applications that receive an OpenPGP packet containing encrypted or
-   signed data but do not know the email address of the sender will have
-   difficulties constructing the correct owner name and cannot use the
-   content-based owner name guidelines.  However, these clients commonly
-   know the key fingerprint or the Key ID.  The key ID is found in
-   OpenPGP packets, and the key fingerprint is commonly found in
-   auxilliary data that may be available.  In this case, use of an owner
-   name identical to the key fingerprint and the key ID expressed in
-   hexadecimal [14] is recommended.  Example:
-
-      $ORIGIN example.org.
-      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
-      F835EDA21E94B565716F                     IN CERT PGP ...
-      B565716F                                 IN CERT PGP ...
-
-   If the same key material is stored for several owner names, the use
-   of CNAME may be used to avoid data duplication.  Note that CNAME is
-   not always applicable, because it maps one owner name to the other
-   for all purposes, which may be sub-optimal when two keys with the
-   same Key ID are stored.
-
-3.5.  Owner names for IPKIX, ISPKI, and IPGP
-
-   These types are stored under the same owner names, both purpose- and
-   content-based, as the PKIX, SPKI and PGP types.
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 9]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-4.  Performance Considerations
-
-   Current Domain Name System (DNS) implementations are optimized for
-   small transfers, typically not more than 512 bytes including
-   overhead.  While larger transfers will perform correctly and work is
-   underway to make larger transfers more efficient, it is still
-   advisable at this time to make every reasonable effort to minimize
-   the size of certificates stored within the DNS.  Steps that can be
-   taken may include using the fewest possible optional or extension
-   fields and using short field values for necessary variable length
-   fields.
-
-   The RDATA field in the DNS protocol may only hold data of size 65535
-   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
-   more than 64kb of payload, even if the corresponding certificate or
-   certificate revocation list is larger.  This document addresses this
-   by defining "indirect" data types for each normal type.
-
-
-5.  Contributors
-
-   The majority of this document is copied verbatim from RFC 2538, by
-   Donald Eastlake 3rd and Olafur Gudmundsson.
-
-
-6.  Acknowledgements
-
-   Thanks to David Shaw and Michael Graff for their contributions to
-   earlier works that motivated, and served as inspiration for, this
-   document.
-
-   This document was improved by suggestions and comments from Olivier
-   Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
-   Sloderbeck, Samuel Weiler, and Florian Weimer.  No doubt the list is
-   incomplete.  We apologize to anyone we left out.
-
-
-7.  Security Considerations
-
-   By definition, certificates contain their own authenticating
-   signature.  Thus, it is reasonable to store certificates in non-
-   secure DNS zones or to retrieve certificates from DNS with DNS
-   security checking not implemented or deferred for efficiency.  The
-   results MAY be trusted if the certificate chain is verified back to a
-   known trusted key and this conforms with the user's security policy.
-
-   Alternatively, if certificates are retrieved from a secure DNS zone
-   with DNS security checking enabled and are verified by DNS security,
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 10]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   the key within the retrieved certificate MAY be trusted without
-   verifying the certificate chain if this conforms with the user's
-   security policy.
-
-   If an organization chooses to issue certificates for it's employees,
-   placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
-   is in use, it is possible for someone to enumerate all employees of
-   the organization.  This is usually not considered desirable, for the
-   same reason enterprise phone listings are not often publicly
-   published and are even mark confidential.
-
-   When the URI type is used, it should be understood that it introduces
-   an additional indirection that may allow for a new attack vector.
-   One method to secure that indirection is to include a hash of the
-   certificate in the URI itself.
-
-   CERT RRs are not used by DNSSEC [9], so there are no security
-   considerations related to CERT RRs and securing the DNS itself.
-
-   If DNSSEC is used, then the non-existence of a CERT RR and,
-   consequently, certificates or revocation lists can be securely
-   asserted.  Without DNSSEC, this is not possible.
-
-
-8.  IANA Considerations
-
-   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
-   only be assigned by an IETF standards action [7].  This document
-   assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE.  Certificate
-   types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
-   based on RFC documentation of the certificate type.  The availability
-   of private types under 0x00FD and 0x00FE should satisfy most
-   requirements for proprietary or private types.
-
-   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
-   particular, the CERT RR requires that algorithm number 0 remain
-   reserved, as described in Section 2.  The IANA is directed to
-   reference the CERT RR as a user of this registry and value 0, in
-   particular.
-
-
-9.  Changes since RFC 2538
-
-   1.   Editorial changes to conform with new document requirements,
-        including splitting reference section into two parts and
-        updating the references to point at latest versions, and to add
-        some additional references.
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 11]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
-        to align with RFC 2440.
-   3.   In section 2.1, clarify that OpenPGP public key data are binary,
-        not the ASCII armored format, and reference 10.1 in RFC 2440 on
-        how to deal with OpenPGP keys, and acknowledge that
-        implementations may handle additional packet types.
-   4.   Clarify that integers in the representation format are decimal.
-   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
-        terminology.  Improve reference for Key Tag Algorithm
-        calculations.
-   6.   Add examples that suggest use of CNAME to reduce bandwidth.
-   7.   In section 3, appended the last paragraphs that discuss
-        "content-based" vs "purpose-based" owner names.  Add section 3.2
-        for purpose-based X.509 CERT owner names, and section 3.4 for
-        purpose-based OpenPGP CERT owner names.
-   8.   Added size considerations.
-   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
-        from the experimental status.
-   10.  Added indirect types IPKIX, ISPKI, and IPGP.
-
-
-Appendix A.  Copying conditions
-
-   Regarding the portion of this document that was written by Simon
-   Josefsson ("the author", for the remainder of this section), the
-   author makes no guarantees and is not responsible for any damage
-   resulting from its use.  The author grants irrevocable permission to
-   anyone to use, modify, and distribute it in any way that does not
-   diminish the rights of anyone else to use, modify, and distribute it,
-   provided that redistributed derivative works do not contain
-   misleading author or version information.  Derivative works need not
-   be licensed under similar terms.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities",
-         STD 13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 12]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
-         January 1998.
-
-   [5]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifiers (URI): Generic Syntax", RFC 2396,
-         August 1998.
-
-   [6]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-         "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [7]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434,
-         October 1998.
-
-   [8]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
-   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033,
-         March 2005.
-
-   [10]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-10.2.  Informative References
-
-   [11]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-         RFC 2246, January 1999.
-
-   [12]  Kent, S. and R. Atkinson, "Security Architecture for the
-         Internet Protocol", RFC 2401, November 1998.
-
-   [13]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
-         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
-         September 1999.
-
-   [14]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [15]  Richardson, M., "A Method for Storing IPsec Keying Material in
-         DNS", RFC 4025, March 2005.
-
-   [16]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
-         (S/MIME) Version 3.1 Message Specification", RFC 3851,
-         July 2004.
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 13]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-Author's Address
-
-   Simon Josefsson
-
-   Email: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 14]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 15]
-
diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
deleted file mode 100644
index 5e6cb1d09e2a..000000000000
--- a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
+++ /dev/null
@@ -1,580 +0,0 @@
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539                               Donald E. Eastlake 3rd
-                                                   Motorola Laboratories
-Expires: January 2006                                          July 2005
-
-
-
-
-        Storage of Diffie-Hellman Keying Information in the DNS
-        ------- -- -------------- ------ ----------- -- --- ---
-               
-
-
-
-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
-   .
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   The standard method for encoding Diffie-Hellman keys in the Domain
-   Name System is specified.
-
-
-
-Copyright
-
-   Copyright (C) The Internet Society 2005.
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
-   Part of the format for Diffie-Hellman keys and the description
-   thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
-   and Hemma Prafullchandra.  In addition, the following persons
-   provided useful comments that were incorporated into the predecessor
-   of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright..................................................1
-
-      Acknowledgements...........................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      1.1 About This Document....................................3
-      1.2 About Diffie-Hellman...................................3
-      2. Encoding Diffie-Hellman Keying Information..............4
-      3. Performance Considerations..............................5
-      4. IANA Considerations.....................................5
-      5. Security Considerations.................................5
-      Copyright and Disclaimer...................................5
-
-      Normative References.......................................7
-      Informative Refences.......................................7
-
-      Author Address.............................................8
-      Expiration and File Name...................................8
-
-      Appendix A: Well known prime/generator pairs...............9
-      A.1. Well-Known Group 1:  A 768 bit prime..................9
-      A.2. Well-Known Group 2:  A 1024 bit prime.................9
-      A.3. Well-Known Group 3:  A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   similar information [RFC 1034, 1035]. The DNS has been extended to
-   include digital signatures and cryptographic keys as described in
-   [RFC 4033, 4034, 4035] and additonal work is underway which would use
-   the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
-   This document describes how to store Diffie-Hellman keys in the DNS.
-   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
-   [Schneier, RFC 2631].
-
-
-
-1.2 About Diffie-Hellman
-
-   Diffie-Hellman requires two parties to interact to derive keying
-   information which can then be used for authentication.  Thus Diffie-
-   Hellman is inherently a key agreement algorithm. As a result, no
-   format is defined for Diffie-Hellman "signature information".  For
-   example, assume that two parties have local secrets "i" and "j".
-   Assume they each respectively calculate X and Y as follows:
-
-        X = g**i ( mod p )
-
-        Y = g**j ( mod p )
-
-   They exchange these quantities and then each calculates a Z as
-   follows:
-
-        Zi = Y**i ( mod p )
-
-        Zj = X**j ( mod p )
-
-   Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
-   secret between the two parties that an adversary who does not know i
-   or j will not be able to learn from the exchanged messages (unless
-   the adversary can derive i or j by performing a discrete logarithm
-   mod p which is hard for strong p and g).
-
-   The private key for each party is their secret i (or j).  The public
-   key is the pair p and g, which must be the same for the parties, and
-   their individual X (or Y).
-
-   For further information about Diffie-Hellman and precautions to take
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-   in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
-   When Diffie-Hellman keys appear within the RDATA portion of a RR,
-   they are encoded as shown below.
-
-   The period of key validity is not included in this data but is
-   indicated separately, for example by an RR such as RRSIG which signs
-   and authenticates the RR containing the keying information.
-
-                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |           KEY flags           |    protocol   |  algorithm=2  |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |     prime length (or flag)    |  prime (p) (or special)       /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /  prime (p)  (variable length) |       generator length        |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       | generator (g) (variable length)                               |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |     public value length       | public value (variable length)/
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /  public value (g^i mod p)    (variable length)                |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Prime length is the length of the Diffie-Hellman prime (p) in bytes
-   if it is 16 or greater.  Prime contains the binary representation of
-   the Diffie-Hellman prime with most significant byte first (i.e., in
-   network order). If "prime length" field is 1 or 2, then the "prime"
-   field is actually an unsigned index into a table of 65,536
-   prime/generator pairs and the generator length SHOULD be zero.  See
-   Appedix A for defined table entries and Section 4 for information on
-   allocating additional table entries.  The meaning of a zero or 3
-   through 15 value for "prime length" is reserved.
-
-   Generator length is the length of the generator (g) in bytes.
-   Generator is the binary representation of generator with most
-   significant byte first.  PublicValueLen is the Length of the Public
-   Value (g**i (mod p)) in bytes.  PublicValue is the binary
-   representation of the DH public value with most significant byte
-   first.
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC 2671] to make larger transfers more efficient. But
-   it is still advisable at this time to make reasonable efforts to
-   minimize the size of RR sets containing keying information consistent
-   with adequate security.
-
-
-
-4. IANA Considerations
-
-   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
-   an IETF consensus as defined in [RFC 2434].
-
-   Well known prime/generator pairs number 0x0000 through 0x07FF can
-   only be assigned by an IETF standards action. [RFC 2539], the
-   Proposed Standard predecessor of this document, assigned 0x0001
-   through 0x0002. This document additionally assigns 0x0003.  Pairs
-   number 0s0800 through 0xBFFF can be assigned based on RFC
-   documentation. Pairs number 0xC000 through 0xFFFF are available for
-   private use and are not centrally coordinated. Use of such private
-   pairs outside of a closed environment may result in conflicts and/or
-   security failures.
-
-
-
-5. Security Considerations
-
-   Keying information retrieved from the DNS should not be trusted
-   unless (1) it has been securely obtained from a secure resolver or
-   independently verified by the user and (2) this secure resolver and
-   secure obtainment or independent verification conform to security
-   policies acceptable to the user.  As with all cryptographic
-   algorithms, evaluating the necessary strength of the key is important
-   and dependent on security policy.
-
-   In addition, the usual Diffie-Hellman key strength considerations
-   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
-   should be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2005).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except
-   as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Normative References
-
-   [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
-   1999.
-
-   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
-   in RFCs", T.  Narten, H. Alvestrand, October 1998.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-
-
-Informative Refences
-
-   [RFC 1034] - "Domain names - concepts and facilities", P.
-   Mockapetris, November 1987.
-
-   [RFC 1035] - "Domain names - implementation and specification", P.
-   Mockapetris, November 1987.
-
-   [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
-   System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
-   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
-   1999.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
-   Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
-   and Sons.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Author Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in January 2006.
-
-   Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
-   These numbers are copied from the IPSEC effort where the derivation of
-   these values is more fully explained and additional information is
-   available.
-   Richard Schroeppel performed all the mathematical and computational
-   work for this appendix.
-
-
-
-A.1. Well-Known Group 1:  A 768 bit prime
-
-   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
-   decimal value is
-          155251809230070893513091813125848175563133404943451431320235
-          119490296623994910210725866945387659164244291000768028886422
-          915080371891804634263272761303128298374438082089019628850917
-          0691316593175367469551763119843371637221007210577919
-
-   Prime modulus: Length (32 bit words): 24, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2:  A 1024 bit prime
-
-   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
-   Its decimal value is
-         179769313486231590770839156793787453197860296048756011706444
-         423684197180216158519368947833795864925541502180565485980503
-         646440548199239100050792877003355816639229553136239076508735
-         759914822574862575007425302077447712589550957937778424442426
-         617334727629299387668709205606050270810842907692932019128194
-         467627007
-
-   Prime modulus:  Length (32 bit words): 32, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
-            FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3:  A 1536 bit prime
-
-   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804 }.
-   Its decimal value is
-            241031242692103258855207602219756607485695054850245994265411
-            694195810883168261222889009385826134161467322714147790401219
-            650364895705058263194273070680500922306273474534107340669624
-            601458936165977404102716924945320037872943417032584377865919
-            814376319377685986952408894019557734611984354530154704374720
-            774996976375008430892633929555996888245787241299381012913029
-            459299994792636526405928464720973038494721168143446471443848
-            8520940127459844288859336526896320919633919
-
-   Prime modulus Length (32 bit words): 48, Data (hex):
-              FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-              29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-              EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-              E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-              EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
-              C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
-              83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-              670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words):  1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 10]
-
diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt
new file mode 100644
index 000000000000..ba1b4147f4db
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt
@@ -0,0 +1,616 @@
+
+
+
+DNSEXT Working Group                                            M. Graff
+Internet-Draft                                                  P. Vixie
+Obsoletes: 2671 (if approved)                Internet Systems Consortium
+Intended status: Standards Track                           July 28, 2009
+Expires: January 29, 2010
+
+
+                  Extension Mechanisms for DNS (EDNS0)
+                 draft-ietf-dnsext-rfc2671bis-edns0-02
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 29, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   The Domain Name System's wire protocol includes a number of fixed
+   fields whose range has been or soon will be exhausted and does not
+
+
+
+Graff & Vixie           Expires January 29, 2010                [Page 1]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+   allow requestors to advertise their capabilities to responders.  This
+   document describes backward compatible mechanisms for allowing the
+   protocol to grow.
+
+   This document updates the EDNS0 specification based on 10 years of
+   operational experience.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
+   3.  EDNS Support Requirement . . . . . . . . . . . . . . . . . . .  3
+   4.  Affected Protocol Elements . . . . . . . . . . . . . . . . . .  3
+     4.1.  Message Header . . . . . . . . . . . . . . . . . . . . . .  3
+     4.2.  Label Types  . . . . . . . . . . . . . . . . . . . . . . .  4
+     4.3.  UDP Message Size . . . . . . . . . . . . . . . . . . . . .  4
+   5.  Extended Label Types . . . . . . . . . . . . . . . . . . . . .  4
+   6.  OPT pseudo-RR  . . . . . . . . . . . . . . . . . . . . . . . .  4
+     6.1.  OPT Record Behavior  . . . . . . . . . . . . . . . . . . .  4
+     6.2.  OPT Record Format  . . . . . . . . . . . . . . . . . . . .  5
+     6.3.  Requestor's Payload Size . . . . . . . . . . . . . . . . .  6
+     6.4.  Responder's Payload Size . . . . . . . . . . . . . . . . .  6
+     6.5.  Payload Size Selection . . . . . . . . . . . . . . . . . .  7
+     6.6.  Middleware Boxes . . . . . . . . . . . . . . . . . . . . .  7
+     6.7.  Extended RCODE . . . . . . . . . . . . . . . . . . . . . .  7
+     6.8.  OPT Options Type Allocation Procedure  . . . . . . . . . .  8
+   7.  Transport Considerations . . . . . . . . . . . . . . . . . . .  8
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graff & Vixie           Expires January 29, 2010                [Page 2]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+1.  Introduction
+
+   DNS [RFC1035] specifies a Message Format and within such messages
+   there are standard formats for encoding options, errors, and name
+   compression.  The maximum allowable size of a DNS Message is fixed.
+   Many of DNS's protocol limits are too small for uses which are or
+   which are desired to become common.  There is no way for
+   implementations to advertise their capabilities.
+
+   Unextended agents will not know how to interpret the protocol
+   extensions detailed here.  In practice, these clients will be
+   upgraded when they have need of a new feature, and only new features
+   will make use of the extensions.  Extended agents must be prepared
+   for behaviour of unextended clients in the face of new protocol
+   elements, and fall back gracefully to unextended DNS.  [RFC2671]
+   originally proposed extensions to the basic DNS protocol to overcome
+   these deficiencies.  This memo refines that specification and
+   obsoletes [RFC2671].
+
+
+2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+3.  EDNS Support Requirement
+
+   EDNS support is manditory in a modern world.  DNSSEC requires EDNS
+   support, and many other featres are made possible only by EDNS
+   support to request or advertise them.
+
+
+4.  Affected Protocol Elements
+
+4.1.  Message Header
+
+   The DNS Message Header's (see , section 4.1.1 [RFC1035]) second full
+   16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a
+   number of 1-bit flags.  The original reserved Z bits have been
+   allocated to various purposes, and most of the RCODE values are now
+   in use.  More flags and more possible RCODEs are needed.  The OPT
+   pseudo-RR specified below contains subfields that carry a bit field
+   extension of the RCODE field and additional flag bits, respectively.
+
+
+
+
+
+
+Graff & Vixie           Expires January 29, 2010                [Page 3]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+4.2.  Label Types
+
+   The first two bits of a wire format domain label are used to denote
+   the type of the label. ,section 4.1.4 [RFC1035] allocates two of the
+   four possible types and reserves the other two.  More label types
+   were proposed in [RFC2671] section 3.
+
+4.3.  UDP Message Size
+
+   DNS Messages are limited to 512 octets in size when sent over UDP.
+   While the minimum maximum reassembly buffer size still allows a limit
+   of 512 octets of UDP payload, most of the hosts now connected to the
+   Internet are able to reassemble larger datagrams.  Some mechanism
+   must be created to allow requestors to advertise larger buffer sizes
+   to responders.  To this end, the OPT pseudo-RR specified below
+   contains a maximum payload size field.
+
+
+5.  Extended Label Types
+
+   The first octet in the on-the-wire representation of a DNS label
+   specifies the label type; the basic DNS specification [RFC1035]
+   dedicates the two most significant bits of that octet for this
+   purpose.
+
+   This document reserves DNS label type 0b01 for use as an indication
+   for Extended Label Types.  A specific extended label type is selected
+   by the 6 least significant bits of the first octet.  Thus, Extended
+   Label Types are indicated by the values 64-127 (0b01xxxxxx) in the
+   first octet of the label.
+
+   This document does not describe any specific Extended Label Type.
+
+   In practice, Extended Label Types are difficult to use due to support
+   in clients and intermediate gateways.  Therefore, the registry of
+   Extended Label Types is requested to be closed.  They cause
+   interoperability problems and at present no defined label types are
+   in use.
+
+
+6.  OPT pseudo-RR
+
+6.1.  OPT Record Behavior
+
+   One OPT pseudo-RR (RR type 41) MAY be added to the additional data
+   section of a request.  If present in requests, compliant responders
+   which implement EDNS MUST include an OPT record in non-truncated
+   responses, and SHOULD attempt to include them in all responses.  An
+
+
+
+Graff & Vixie           Expires January 29, 2010                [Page 4]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+   OPT is called a pseudo-RR because it pertains to a particular
+   transport level message and not to any actual DNS data.  OPT RRs MUST
+   NOT be cached, forwarded, or stored in or loaded from master files.
+   The quantity of OPT pseudo-RRs per message MUST be either zero or
+   one, but not greater.
+
+6.2.  OPT Record Format
+
+   An OPT RR has a fixed part and a variable set of options expressed as
+   {attribute, value} pairs.  The fixed part holds some DNS meta data
+   and also a small collection of basic extension elements which we
+   expect to be so popular that it would be a waste of wire space to
+   encode them as {attribute, value} pairs.
+
+   The fixed part of an OPT RR is structured as follows:
+
+       +------------+--------------+------------------------------+
+       | Field Name | Field Type   | Description                  |
+       +------------+--------------+------------------------------+
+       | NAME       | domain name  | empty (root domain)          |
+       | TYPE       | u_int16_t    | OPT                          |
+       | CLASS      | u_int16_t    | requestor's UDP payload size |
+       | TTL        | u_int32_t    | extended RCODE and flags     |
+       | RDLEN      | u_int16_t    | describes RDATA              |
+       | RDATA      | octet stream | {attribute,value} pairs      |
+       +------------+--------------+------------------------------+
+
+                               OPT RR Format
+
+   The variable part of an OPT RR is encoded in its RDATA and is
+   structured as zero or more of the following:
+
+
+                  +0 (MSB)                            +1 (LSB)
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    0: |                          OPTION-CODE                          |
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    2: |                         OPTION-LENGTH                         |
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    4: |                                                               |
+       /                          OPTION-DATA                          /
+       /                                                               /
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+
+
+
+
+
+
+
+Graff & Vixie           Expires January 29, 2010                [Page 5]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+   OPTION-CODE
+         Assigned by Expert Review.
+
+   OPTION-LENGTH
+         Size (in octets) of OPTION-DATA.
+
+   OPTION-DATA
+         Varies per OPTION-CODE.
+
+   Order of appearance of option tuples is never relevant.  Any option
+   whose meaning is affected by other options is so affected no matter
+   which one comes first in the OPT RDATA.
+
+   Any OPTION-CODE values not understood by a responder or requestor
+   MUST be ignored.  Specifications of such options might wish to
+   include some kind of signalled acknowledgement.  For example, an
+   option specification might say that if a responder sees option XYZ,
+   it SHOULD include option XYZ in its response.
+
+6.3.  Requestor's Payload Size
+
+   The requestor's UDP payload size (which OPT stores in the RR CLASS
+   field) is the number of octets of the largest UDP payload that can be
+   reassembled and delivered in the requestor's network stack.  Note
+   that path MTU, with or without fragmentation, may be smaller than
+   this.  Values lower than 512 MUST be treated as equal to 512.
+
+   Note that a 512-octet UDP payload requires a 576-octet IP reassembly
+   buffer.  Choosing 1280 for IPv4 over Ethernet would be reasonable.
+   The consequence of choosing too large a value may be an ICMP message
+   from an intermediate gateway, or even a silent drop of the response
+   message.
+
+   The requestor's maximum payload size can change over time, and MUST
+   therefore not be cached for use beyond the transaction in which it is
+   advertised.
+
+6.4.  Responder's Payload Size
+
+   The responder's maximum payload size can change over time, but can be
+   reasonably expected to remain constant between two sequential
+   transactions; for example, a meaningless QUERY to discover a
+   responder's maximum UDP payload size, followed immediately by an
+   UPDATE which takes advantage of this size.  (This is considered
+   preferrable to the outright use of TCP for oversized requests, if
+   there is any reason to suspect that the responder implements EDNS,
+   and if a request will not fit in the default 512 payload size limit.)
+
+
+
+
+Graff & Vixie           Expires January 29, 2010                [Page 6]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+6.5.  Payload Size Selection
+
+   Due to transaction overhead, it is unwise to advertise an
+   architectural limit as a maximum UDP payload size.  Just because your
+   stack can reassemble 64KB datagrams, don't assume that you want to
+   spend more than about 4KB of state memory per ongoing transaction.
+
+   A requestor MAY choose to implement a fallback to smaller advertised
+   sizes to work around firewall or other network limitations.  A
+   requestor SHOULD choose to use a fallback mechanism which begins with
+   a large size, such as 4096.  If that fails, a fallback around the
+   1220 byte range SHOULD be tried, as it has a reasonable chance to fit
+   within a single Ethernet frame.  Failing that, a requestor MAY choose
+   a 512 byte packet, which with large answers may cause a TCP retry.
+
+6.6.  Middleware Boxes
+
+   Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes.
+
+   Middleware boxes which simply forward requests to a recursive
+   resolver MUST NOT modify the OPT record contents in either direction.
+
+6.7.  Extended RCODE
+
+   The extended RCODE and flags (which OPT stores in the RR TTL field)
+   are structured as follows:
+
+                  +0 (MSB)                            +1 (LSB)
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    0: |         EXTENDED-RCODE        |            VERSION            |
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    2: | DO|                           Z                               |
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   EXTENDED-RCODE
+         Forms upper 8 bits of extended 12-bit RCODE.  Note that
+         EXTENDED-RCODE value "0" indicates that an unextended RCODE is
+         in use (values "0" through "15").
+
+   VERSION
+         Indicates the implementation level of whoever sets it.  Full
+         conformance with this specification is indicated by version
+         ``0.''  Requestors are encouraged to set this to the lowest
+         implemented level capable of expressing a transaction, to
+         minimize the responder and network load of discovering the
+         greatest common implementation level between requestor and
+         responder.  A requestor's version numbering strategy MAY
+         ideally be a run time configuration option.
+
+
+
+Graff & Vixie           Expires January 29, 2010                [Page 7]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+         If a responder does not implement the VERSION level of the
+         request, then it answers with RCODE=BADVERS.  All responses
+         MUST be limited in format to the VERSION level of the request,
+         but the VERSION of each response SHOULD be the highest
+         implementation level of the responder.  In this way a requestor
+         will learn the implementation level of a responder as a side
+         effect of every response, including error responses and
+         including RCODE=BADVERS.
+
+   DO
+         DNSSEC OK bit as defined by [RFC3225].
+
+   Z
+         Set to zero by senders and ignored by receivers, unless
+         modified in a subsequent specification.
+
+6.8.  OPT Options Type Allocation Procedure
+
+   Allocations assigned by expert review.  TBD
+
+
+7.  Transport Considerations
+
+   The presence of an OPT pseudo-RR in a request should be taken as an
+   indication that the requestor fully implements the given version of
+   EDNS, and can correctly understand any response that conforms to that
+   feature's specification.
+
+   Lack of presence of an OPT record in a request MUST be taken as an
+   indication that the requestor does not implement any part of this
+   specification and that the responder MUST NOT use any protocol
+   extension described here in its response.
+
+   Responders who do not implement these protocol extensions MUST
+   respond with FORMERR messages without any OPT record.
+
+   If there is a problem with processing the OPT record itself, such as
+   an option value that is badly formatted or includes out of range
+   values, a FORMERR MAY be retured.  If this occurs the response MUST
+   include an OPT record.  This MAY be used to distinguish between
+   servers whcih do not implement EDNS and format errors within EDNS.
+
+   If EDNS is used in a request, and the response arrives with TC set
+   and with no EDNS OPT RR, a requestor SHOULD assume that truncation
+   prevented the OPT RR from being appended by the responder, and
+   further, that EDNS is not used in the response.  Correspondingly, an
+   EDNS responder who cannot fit all necessary elements (including an
+   OPT RR) into a response, SHOULD respond with a normal (unextended)
+
+
+
+Graff & Vixie           Expires January 29, 2010                [Page 8]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+   DNS response, possibly setting TC if the response will not fit in the
+   unextended response message's 512-octet size.
+
+
+8.  Security Considerations
+
+   Requestor-side specification of the maximum buffer size may open a
+   new DNS denial of service attack if responders can be made to send
+   messages which are too large for intermediate gateways to forward,
+   thus leading to potential ICMP storms between gateways and
+   responders.
+
+   Announcing very large UDP buffer sizes may result in dropping by
+   firewalls.  This could cause retransmissions with no hope of success.
+   Some devices reject fragmented UDP packets.
+
+   Announcing too small UDP buffer sizes may result in fallback to TCP.
+   This is especially important with DNSSEC, where answers are much
+   larger.
+
+
+9.  IANA Considerations
+
+   The IANA has assigned RR type code 41 for OPT.
+
+   [RFC2671] specified a number of IANA sub-registries within "DOMAIN
+   NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option
+   Codes", "EDNS Version Numbers", and "Domain System Response Code."
+   IANA is advised to re-parent these subregistries to this document.
+
+   RFC 2671 created an extended label type registry.  We request that
+   this registry be closed.
+
+   This document assigns extended label type 0bxx111111 as "Reserved for
+   future extended label types."  We request that IANA record this
+   assignment.
+
+   This document assigns option code 65535 to "Reserved for future
+   expansion."
+
+   This document expands the RCODE space from 4 bits to 12 bits.  This
+   will allow IANA to assign more than the 16 distinct RCODE values
+   allowed in RFC 1035 [RFC1035].
+
+   This document assigns EDNS Extended RCODE "16" to "BADVERS".
+
+   IESG approval should be required to create new entries in the EDNS
+   Extended Label Type or EDNS Version Number registries, while any
+
+
+
+Graff & Vixie           Expires January 29, 2010                [Page 9]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+   published RFC (including Informational, Experimental, or BCP) should
+   be grounds for allocation of an EDNS Option Code.
+
+
+10.  Acknowledgements
+
+   Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
+   Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
+   Narten were each instrumental in creating and refining this
+   specification.
+
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
+              RFC 3225, December 2001.
+
+11.2.  Informative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+Authors' Addresses
+
+   Michael Graff
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, California  94063
+   US
+
+   Phone: +1 650.423.1304
+   Email: mgraff@isc.org
+
+
+
+
+
+
+
+
+
+
+Graff & Vixie           Expires January 29, 2010               [Page 10]
+
+Internet-Draft              EDNS0 Extensions                   July 2009
+
+
+   Paul Vixie
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, California  94063
+   US
+
+   Phone: +1 650.423.1301
+   Email: vixie@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graff & Vixie           Expires January 29, 2010               [Page 11]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt
new file mode 100644
index 000000000000..3b9a35aeaf7f
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt
@@ -0,0 +1,953 @@
+
+
+
+DNS Extensions Working Group                                     S. Rose
+Internet-Draft                                                      NIST
+Obsoletes: 2672 (if approved)                              W. Wijngaards
+Updates: 3363,4294                                            NLnet Labs
+(if approved)                                          November 12, 2009
+Intended status: Standards Track
+Expires: May 16, 2010
+
+
+                 Update to DNAME Redirection in the DNS
+                 draft-ietf-dnsext-rfc2672bis-dname-18
+
+Abstract
+
+   The DNAME record provides redirection for a sub-tree of the domain
+   name tree in the DNS system.  That is, all names that end with a
+   particular suffix are redirected to another part of the DNS.  This is
+   a revision of the original specification in RFC 2672, also aligning
+   RFC 3363 and RFC 4294 with this revision.
+
+Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Status of This Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 May 16, 2010.
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                  [Page 1]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                  [Page 2]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+
+   2.  The DNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
+     2.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  The DNAME Substitution . . . . . . . . . . . . . . . . . .  5
+     2.3.  DNAME Owner Name not Redirected Itself . . . . . . . . . .  6
+     2.4.  Names Next to and Below a DNAME Record . . . . . . . . . .  7
+     2.5.  Compression of the DNAME record. . . . . . . . . . . . . .  7
+
+   3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     3.1.  CNAME synthesis  . . . . . . . . . . . . . . . . . . . . .  8
+     3.2.  Server algorithm . . . . . . . . . . . . . . . . . . . . .  8
+     3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 10
+     3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 10
+
+   4.  DNAME Discussions in Other Documents . . . . . . . . . . . . . 11
+
+   5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 12
+     5.1.  Canonical hostnames cannot be below DNAME owners . . . . . 12
+     5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12
+     5.3.  DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13
+       5.3.1.  Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13
+       5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 13
+       5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 13
+       5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 13
+         5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . 13
+         5.3.4.2.  Valid Name Error Response Involving DNAME in
+                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 14
+         5.3.4.3.  Response With Synthesized CNAME  . . . . . . . . . 14
+
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
+
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
+
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                  [Page 3]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+1.  Introduction
+
+   DNAME is a DNS Resource Record type originally defined in RFC 2672
+   [RFC2672].  DNAME provides redirection from a part of the DNS name
+   tree to another part of the DNS name tree.
+
+   The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
+   (potentially) return data corresponding to a domain name different
+   from the queried domain name.  The difference between the two
+   resource records is that the CNAME RR directs the lookup of data at
+   its owner to another single name, a DNAME RR directs lookups for data
+   at descendents of its owner's name to corresponding names under a
+   different (single) node of the tree.
+
+   Take for example, looking through a zone (see RFC 1034 [RFC1034],
+   section 4.3.2, step 3) for the domain name "foo.example.com" and a
+   DNAME resource record is found at "example.com" indicating that all
+   queries under "example.com" be directed to "example.net".  The lookup
+   process will return to step 1 with the new query name of
+   "foo.example.net".  Had the query name been "www.foo.example.com" the
+   new query name would be "www.foo.example.net".
+
+   This document is a revision of the original specification of DNAME in
+   RFC 2672 [RFC2672].  DNAME was conceived to help with the problem of
+   maintaining address-to-name mappings in a context of network
+   renumbering.  With a careful set-up, a renumbering event in the
+   network causes no change to the authoritative server that has the
+   address-to-name mappings.  Examples in practice are classless reverse
+   address space delegations.
+
+   Another usage of DNAME lies in aliasing of name spaces.  For example,
+   a zone administrator may want sub-trees of the DNS to contain the
+   same information.  Examples include punycode alternates for domain
+   spaces.
+
+   This revision to DNAME does not change the wire format or the
+   handling of DNAME Resource Records.  Discussion is added on problems
+   that may be encountered when using DNAME.
+
+2.  The DNAME Resource Record
+
+2.1.  Format
+
+   The DNAME RR has mnemonic DNAME and type code 39 (decimal).  It is
+   not class-sensitive.
+
+
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                  [Page 4]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+   Its RDATA is comprised of a single field, , which contains a
+   fully qualified domain name that must be sent in uncompressed form
+   [RFC1035], [RFC3597].  The  field MUST be present.  The
+   presentation format of  is that of a domain name [RFC1035].
+
+              DNAME 
+
+   The effect of the DNAME RR is the substitution of the record's
+    for its owner name, as a suffix of a domain name.  This
+   substitution has to be applied for every DNAME RR found in the
+   resolution process, which allows fairly lengthy valid chains of DNAME
+   RRs.
+
+   Details of the substitution process, methods to avoid conflicting
+   resource records, and rules for specific corner cases are given in
+   the following subsections.
+
+2.2.  The DNAME Substitution
+
+   When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third
+   step, "start matching down, label by label, in the zone" and a node
+   is found to own a DNAME resource record a DNAME substitution occurs.
+   The name being sought may be the original query name or a name that
+   is the result of a CNAME resource record being followed or a
+   previously encountered DNAME.  As in the case when finding a CNAME
+   resource record or NS resource record set, the processing of a DNAME
+   will happen prior to finding the desired domain name.
+
+   A DNAME substitution is performed by replacing the suffix labels of
+   the name being sought matching the owner name of the DNAME resource
+   record with the string of labels in the RDATA field.  The matching
+   labels end with the root label in all cases.  Only whole labels are
+   replaced.  See the table of examples for common cases and corner
+   cases.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                  [Page 5]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+   In the table below, the QNAME refers to the query name.  The owner is
+   the DNAME owner domain name, and the target refers to the target of
+   the DNAME record.  The result is the resulting name after performing
+   the DNAME substitution on the query name. "no match" means that the
+   query did not match the DNAME and thus no substitution is performed
+   and a possible error message is returned (if no other result is
+   possible).  Thus every line contains one example substitution.  In
+   the examples below, 'cyc' and 'shortloop' contain loops.
+
+    QNAME            owner  DNAME   target         result
+    ---------------- -------------- -------------- -----------------
+    com.             example.com.   example.net.   
+    example.com.     example.com.   example.net.   
+    a.example.com.   example.com.   example.net.   a.example.net.
+    a.b.example.com. example.com.   example.net.   a.b.example.net.
+    ab.example.com.  b.example.com. example.net.   
+    foo.example.com. example.com.   example.net.   foo.example.net.
+    a.x.example.com. x.example.com. example.net.   a.example.net.
+    a.example.com.   example.com.   y.example.net. a.y.example.net.
+    cyc.example.com. example.com.   example.com.   cyc.example.com.
+    cyc.example.com. example.com.   c.example.com. cyc.c.example.com.
+    shortloop.x.x.   x.             .              shortloop.x.
+    shortloop.x.     x.             .              shortloop.
+
+                   Table 1. DNAME Substitution Examples.
+
+   It is possible for DNAMEs to form loops, just as CNAMEs can form
+   loops.  DNAMEs and CNAMEs can chain together to form loops.  A single
+   corner case DNAME can form a loop.  Resolvers and servers should be
+   cautious in devoting resources to a query, but be aware that fairly
+   long chains of DNAMEs may be valid.  Zone content administrators
+   should take care to insure that there are no loops that could occur
+   when using DNAME or DNAME/CNAME redirection.
+
+   The domain name can get too long during substitution.  For example,
+   suppose the target name of the DNAME RR is 250 octets in length
+   (multiple labels), if an incoming QNAME that has a first label over 5
+   octets in length, the result would be a name over 255 octets.  If
+   this occurs the server returns an RCODE of YXDOMAIN [RFC2136].  The
+   DNAME record and its signature (if the zone is signed) are included
+   in the answer as proof for the YXDOMAIN (value 6) RCODE.
+
+2.3.  DNAME Owner Name not Redirected Itself
+
+   Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
+   owner name; the owner name of a DNAME is not redirected itself.  The
+   domain name that owns a DNAME record is allowed to have other
+   resource record types at that domain name, except DNAMEs, CNAMEs or
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                  [Page 6]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+   other types that have restrictions on what they can co-exist with.
+   DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
+   the owner name is the zone apex.
+
+   If a DNAME record is present at the zone apex, there is still a need
+   to have the customary SOA and NS resource records there as well.
+   Such a DNAME cannot be used to mirror a zone completely, as it does
+   not mirror the zone apex.
+
+   These rules also allow DNAME records to be queried through RFC 1034
+   [RFC1034] compliant, DNAME-unaware caches.
+
+2.4.  Names Next to and Below a DNAME Record
+
+   Resource records MUST NOT exist at any sub-domain of the owner of a
+   DNAME RR.  To get the contents for names subordinate to that owner
+   name, the DNAME redirection must be invoked and the resulting target
+   queried.  A server MAY refuse to load a zone that has data at a sub-
+   domain of a domain name owning a DNAME RR.  If the server does load
+   the zone, those names below the DNAME RR will be occluded as
+   described in RFC 2136 [RFC2136], section 7.18.  Also a server SHOULD
+   refuse to load a zone subordinate to the owner of a DNAME record in
+   the ancestor zone.  See Section 5.2 for further discussion related to
+   dynamic update.
+
+   DNAME is a singleton type, meaning only one DNAME is allowed per
+   name.  The owner name of a DNAME can only have one DNAME RR, and no
+   CNAME RRs can exist at that name.  These rules make sure that for a
+   single domain name only one redirection exists, and thus no confusion
+   which one to follow.  A server SHOULD refuse to load a zone that
+   violates these rules.
+
+2.5.  Compression of the DNAME record.
+
+   The DNAME owner name can be compressed like any other owner name.
+   The DNAME RDATA target name MUST NOT be sent out in compressed form,
+   so that a DNAME RR can be treated as an unknown type [RFC3597].
+
+   Although the previous DNAME specification [RFC2672] (that is
+   obsoleted by this specification) talked about signaling to allow
+   compression of the target name, such signaling has never been
+   specified and this document also does not specify this signaling
+   behavior.
+
+   RFC 2672 (obsoleted by this document) stated that the EDNS version
+   had a meaning for understanding of DNAME and DNAME target name
+   compression.  This document revises RFC 2672, in that there is no
+   EDNS version signaling for DNAME.
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                  [Page 7]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+3.  Processing
+
+   The DNAME RR causes type NS additional section processing.  This
+   refers to action at step 6 of the server algorithm outlined in
+   section 3.2.
+
+3.1.  CNAME synthesis
+
+   When preparing a response, a server performing a DNAME substitution
+   will in all cases include the relevant DNAME RR in the answer
+   section.  A CNAME RR with TTL equal to the corresponding DNAME RR is
+   synthesized and included in the answer section.  The owner name of
+   the CNAME is the QNAME of the query.  The DNSSEC specification
+   [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
+   not have to be signed.  The DNAME has an RRSIG and a validating
+   resolver can check the CNAME against the DNAME record and validate
+   the signature over the DNAME RR.
+
+   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
+   equal to the TTL of the corresponding DNAME record.  A TTL of zero
+   means that the CNAME can be discarded immediately after processing
+   the answer.
+
+   Servers MUST be able to answer a query for a synthesized CNAME.  Like
+   other query types this invokes the DNAME, and synthesizes the CNAME
+   into the answer.
+
+3.2.  Server algorithm
+
+   Below is the server algorithm, which appeared in RFC 2672 Section
+   4.1.
+
+   1.  Set or clear the value of recursion available in the response
+       depending on whether the name server is willing to provide
+       recursive service.  If recursive service is available and
+       requested via the RD bit in the query, go to step 5, otherwise
+       step 2.
+
+
+   2.  Search the available zones for the zone which is the nearest
+       ancestor to QNAME.  If such a zone is found, go to step 3,
+       otherwise step 4.
+
+
+   3.  Start matching down, label by label, in the zone.  The matching
+       process can terminate several ways:
+
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                  [Page 8]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+       A.  If the whole of QNAME is matched, we have found the node.
+
+           If the data at the node is a CNAME, and QTYPE does not match
+           CNAME, copy the CNAME RR into the answer section of the
+           response, change QNAME to the canonical name in the CNAME RR,
+           and go back to step 1.
+
+           Otherwise, copy all RRs which match QTYPE into the answer
+           section and go to step 6.
+
+
+       B.  If a match would take us out of the authoritative data, we
+           have a referral.  This happens when we encounter a node with
+           NS RRs marking cuts along the bottom of a zone.
+
+           Copy the NS RRs for the sub-zone into the authority section
+           of the reply.  Put whatever addresses are available into the
+           additional section, using glue RRs if the addresses are not
+           available from authoritative data or the cache.  Go to step
+           4.
+
+
+       C.  If at some label, a match is impossible (i.e., the
+           corresponding label does not exist), look to see whether the
+           last label matched has a DNAME record.
+
+           If a DNAME record exists at that point, copy that record into
+           the answer section.  If substitution of its  for its
+            in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
+           perform the substitution and continue.  The server MUST
+           synthesize a CNAME record as described above and include it
+           in the answer section.  Go back to step 1.
+
+           If there was no DNAME record, look to see if the "*" label
+           exists.
+
+           If the "*" label does not exist, check whether the name we
+           are looking for is the original QNAME in the query or a name
+           we have followed due to a CNAME or DNAME.  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.  If the data at the node with the "*" label is
+           a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                  [Page 9]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+           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.  Otherwise, Go to step 6.
+
+
+   4.  Start matching down in the cache.  If QNAME is found in the
+       cache, copy all RRs attached to it that match QTYPE into the
+       answer section.  If QNAME is not found in the cache but a DNAME
+       record is present at an ancestor of QNAME, copy that DNAME record
+       into the answer section.  If there was no delegation from
+       authoritative data, look for the best one from the cache, and put
+       it in the authority section.  Go to step 6.
+
+
+   5.  Use the local resolver or a copy of its algorithm to answer the
+       query.  Store the results, including any intermediate CNAMEs and
+       DNAMEs, in the answer section of the response.
+
+
+   6.  Using local data only, attempt to add other RRs which may be
+       useful to the additional section of the query.  Exit.
+
+   Note that there will be at most one ancestor with a DNAME as
+   described in step 4 unless some zone's data is in violation of the
+   no-descendants limitation in section 3.  An implementation might take
+   advantage of this limitation by stopping the search of step 3c or
+   step 4 when a DNAME record is encountered.
+
+3.3.  Wildcards
+
+   The use of DNAME in conjunction with wildcards is discouraged
+   [RFC4592].  Thus records of the form "*.example.com DNAME
+   example.net" SHOULD NOT be used.
+
+   The interaction between the expansion of the wildcard and the
+   redirection of the DNAME is non-deterministic.  Because the
+   processing is non-deterministic, DNSSEC validating resolvers may not
+   be able to validate a wildcarded DNAME.
+
+   A server MAY give a warning that the behavior is unspecified if such
+   a wildcarded DNAME is loaded.  The server MAY refuse it, refuse to
+   load the zone or refuse dynamic updates.
+
+3.4.  Acceptance and Intermediate Storage
+
+   Recursive caching name servers can encounter data at names below the
+   owner name of a DNAME RR, due to a change at the authoritative server
+   where data from before and after the change resides in the cache.
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                 [Page 10]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+   This conflict situation is a transitional phase that ends when the
+   old data times out.  The caching name server can opt to store both
+   old and new data and treat each as if the other did not exist, or
+   drop the old data, or drop the longer domain name.  In any approach,
+   consistency returns after the older data TTL times out.
+
+   Recursive caching name servers MUST perform CNAME synthesis on behalf
+   of clients.
+
+   If a recursive caching name server encounters a DNAME RR which
+   contradicts information already in the cache (excluding CNAME
+   records), it SHOULD NOT cache the DNAME RR, but it MAY cache the
+   CNAME record received along with it, subject to the rules for CNAME.
+
+4.  DNAME Discussions in Other Documents
+
+   In [RFC2181], in Section 10.3., the discussion on MX and NS records
+   touches on redirection by CNAMEs, but this also holds for DNAMEs.
+
+   Excerpt from 10.3.  MX and NS records (in RFC 2181).
+
+           The domain name used as the value of a NS resource record,
+           or part of the value of a MX resource record must not be
+           an alias.  Not only is the specification clear on this
+           point, but using an alias in either of these positions
+           neither works as well as might be hoped, nor well fulfills
+           the ambition that may have led to this approach.  This
+           domain name must have as its value one or more address
+           records.  Currently those will be A records, however in
+           the future other record types giving addressing
+           information may be acceptable.  It can also have other
+           RRs, but never a CNAME RR.
+
+   The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
+   The opening premise of this section is demonstrably wrong, and so the
+   conclusion based on that premise is wrong.  In particular, [RFC3363]
+   deprecates the use of DNAME in the IPv6 reverse tree, which is then
+   carried forward as a recommendation in [RFC4294].  Based on the
+   experience gained in the meantime, [RFC3363] should be revised,
+   dropping all constraints on having DNAME RRs in these zones.  This
+   would greatly improve the manageability of the IPv6 reverse tree.
+   These changes are made explicit below.
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                 [Page 11]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+   In [RFC3363], the paragraph
+
+     "The issues for DNAME in the reverse mapping tree appears to be
+     closely tied to the need to use fragmented A6 in the main tree: if
+     one is necessary, so is the other, and if one isn't necessary, the
+     other isn't either.  Therefore, in moving RFC 2874 to experimental,
+     the intent of this document is that use of DNAME RRs in the reverse
+     tree be deprecated."
+
+   is to be replaced with the word "DELETED".
+
+   In [RFC4294], the reference to DNAME was left in as an editorial
+   oversight.  The paragraph
+
+     "Those nodes are NOT RECOMMENDED to support the experimental A6 and
+     DNAME Resource Records [RFC3363]."
+
+   is to be replaced by
+
+     "Those nodes are NOT RECOMMENDED to support the experimental
+     A6 Resource Record [RFC3363]."
+
+5.  Other Issues with DNAME
+
+   There are several issues to be aware of about the use of DNAME.
+
+5.1.  Canonical hostnames cannot be below DNAME owners
+
+   The names listed as target names of MX, NS, PTR and SRV [RFC2782]
+   records must be canonical hostnames.  This means no CNAME or DNAME
+   redirection may be present during DNS lookup of the address records
+   for the host.  This is discussed in RFC 2181 [RFC2181], section 10.3,
+   and RFC 1912 [RFC1912], section 2.4.  For SRV see RFC 2782 [RFC2782]
+   page 4.
+
+   The upshot of this is that although the lookup of a PTR record can
+   involve DNAMEs, the name listed in the PTR record can not fall under
+   a DNAME.  The same holds for NS, SRV and MX records.  For example,
+   when punycode alternates for a zone use DNAME then the NS, MX, SRV
+   and PTR records that point to that zone must use names without
+   punycode in their RDATA.  What must be done then is to have the
+   domain names with DNAME substitution already applied to it as the MX,
+   NS, PTR, SRV data.  These are valid canonical hostnames.
+
+5.2.  Dynamic Update and DNAME
+
+   DNAME records can be added, changed and removed in a zone using
+   dynamic update transactions.  Adding a DNAME RR to a zone occludes
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                 [Page 12]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+   any domain names that may exist under the added DNAME.
+
+   A server MUST reject a dynamic update message that attempts to add a
+   DNAME RR at a name that already has a CNAME RR or another DNAME RR
+   associated with that name.
+
+5.3.  DNSSEC and DNAME
+
+   The following subsections specify the behavior of implementations
+   that understand both DNSSEC and DNAME (synthesis).
+
+5.3.1.  Signed DNAME, Unsigned Synthesized CNAME
+
+   In any response, a signed DNAME RR indicates a non-terminal
+   redirection of the query.  There might or might not be a server
+   synthesized CNAME in the answer section; if there is, the CNAME will
+   never be signed.  For a DNSSEC validator, verification of the DNAME
+   RR and then checking that the CNAME was properly synthesized is
+   sufficient proof.
+
+5.3.2.  DNAME Bit in NSEC Type Map
+
+   In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
+   map SHOULD be checked to see that there was no DNAME that could have
+   been applied.  If the DNAME bit in the type bit map is set and the
+   query name is a subdomain of the closest encloser that is asserted,
+   then DNAME substitution should have been done, but the substitution
+   has not been done as specified.
+
+5.3.3.  DNAME Chains as Strong as the Weakest Link
+
+   A response can contain a chain of DNAME and CNAME redirections.  That
+   chain can end in a positive answer or a negative (no name error or no
+   data error) reply.  Each step in that chain results in resource
+   records added to the answer or authority section of the response.
+   Only if all steps are secure can the AD bit be set for the response.
+   If one of the steps is bogus, the result is bogus.
+
+5.3.4.  Validators Must Understand DNAME
+
+   Below are examples of why DNSSEC validators MUST understand DNAME.
+   In the examples below, SOA records, wildcard denial NSECs and other
+   material not under discussion has been omitted.
+
+5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error
+
+
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                 [Page 13]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
+   ;; Question
+   foo.bar.example.com. IN A
+   ;; Authority
+   bar.example.com. NSEC dub.example.com. A DNAME
+   bar.example.com. RRSIG NSEC [valid signature]
+
+   If this is the received response, then only by understanding that the
+   DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
+   have been redirected by the DNAME, the validator can see that it is a
+   BOGUS reply from an attacker that collated existing records from the
+   DNS to create a confusing reply.
+
+   If the DNAME bit had not been set in the NSEC record above then the
+   answer would have validated as a correct name error response.
+
+5.3.4.2.  Valid Name Error Response Involving DNAME in Bitmap
+
+   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
+   ;; Question
+   cee.example.com. IN A
+   ;; Authority
+   bar.example.com. NSEC dub.example.com. A DNAME
+   bar.example.com. RRSIG NSEC [valid signature]
+
+   This response has the same NSEC records as the example above, but
+   with this query name (cee.example.com), the answer is validated,
+   because 'cee' does not get redirected by the DNAME at 'bar'.
+
+5.3.4.3.  Response With Synthesized CNAME
+
+   ;; Header: QR AA DO RCODE=0(NOERROR)
+   ;; Question
+   foo.bar.example.com. IN A
+   ;; Answer
+   bar.example.com. DNAME bar.example.net.
+   bar.example.com. RRSIG DNAME [valid signature]
+   foo.bar.example.com. CNAME foo.bar.example.net.
+
+   The response shown above has the synthesized CNAME included.
+   However, the CNAME has no signature, since the server does not sign
+   online.  So this response cannot be trusted.  It could be altered by
+   an attacker to be foo.bar.example.com CNAME bla.bla.example.  The
+   DNAME record does have its signature included, since it does not
+   change.  The validator must verify the DNAME signature and then
+   recursively resolve further to query for the foo.bar.example.net A
+   record.
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                 [Page 14]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+6.  IANA Considerations
+
+   The DNAME Resource Record type code 39 (decimal) originally has been
+   registered by [RFC2672].  IANA should update the DNS resource record
+   registry to point to this document for RR type 39.
+
+7.  Security Considerations
+
+   DNAME redirects queries elsewhere, which may impact security based on
+   policy and the security status of the zone with the DNAME and the
+   redirection zone's security status.  For validating resolvers, the
+   lowest security status of the links in the chain of CNAME and DNAME
+   redirections is applied to the result.
+
+   If a validating resolver accepts wildcarded DNAMEs, this creates
+   security issues.  Since the processing of a wildcarded DNAME is non-
+   deterministic and the CNAME that was substituted by the server has no
+   signature, the resolver may choose a different result than what the
+   server meant, and consequently end up at the wrong destination.  Use
+   of wildcarded DNAMEs is discouraged in any case [RFC4592].
+
+   A validating resolver MUST understand DNAME, according to [RFC4034].
+   The examples in Section 5.3.4 illustrate this need.
+
+8.  Acknowledgments
+
+   The authors of this draft would like to acknowledge Matt Larson for
+   beginning this effort to address the issues related to the DNAME RR
+   type.  The authors would also like to acknowledge Paul Vixie, Ed
+   Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
+   Hoenes and Kevin Darcy for their review and comments on this
+   document.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                 [Page 15]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+              RFC 2136, April 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [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.
+
+   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
+              System", RFC 4592, July 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+9.2.  Informative References
+
+   [RFC1912]  Barr, D., "Common DNS Operational and Configuration
+              Errors", RFC 1912, February 1996.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
+              RFC 2672, August 1999.
+
+   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+              Hain, "Representing Internet Protocol version 6 (IPv6)
+              Addresses in the Domain Name System (DNS)", RFC 3363,
+              August 2002.
+
+   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
+              April 2006.
+
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                 [Page 16]
+
+Internet-Draft              DNAME Redirection              November 2009
+
+
+Authors' Addresses
+
+   Scott Rose
+   NIST
+   100 Bureau Dr.
+   Gaithersburg, MD  20899
+   USA
+
+   Phone: +1-301-975-8439
+   Fax:   +1-301-975-6238
+   EMail: scottr@nist.gov
+
+
+   Wouter Wijngaards
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   Phone: +31-20-888-4551
+   EMail: wouter@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards         Expires May 16, 2010                 [Page 17]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt
new file mode 100644
index 000000000000..ee35cb91af8e
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                             A. Gustafsson
+                                          Araneus Information Systems Oy
+                                                      September 23, 2009
+
+Intended status: Draft Standard
+Obsoletes: RFC3597
+
+           Handling of Unknown DNS Resource Record (RR) Types
+                  draft-ietf-dnsext-rfc3597-bis-00.txt
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors. All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   Extending the Domain Name System (DNS) with new Resource Record (RR)
+   types should not requires changes to name server software.  This
+   document specifies how new RR types are transparently handled by DNS
+   software.
+
+
+
+
+Expires March 2010           Standards Track                    [Page 1]
+
+draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
+
+
+1.  Introduction
+
+   The DNS [RFC1034] is designed to be extensible to support new
+   services through the introduction of new resource record (RR) types.
+   Nevertheless, DNS implementations have historically required software
+   changes to support new RR types, not only at the authoritative DNS
+   server providing the new information and the client making use of it,
+   but also at all slave servers for the zone containing it, and in some
+   cases also at caching name servers and forwarders used by the client.
+   Because the deployment of new DNS software is slow and expensive,
+   this has been a significant impediment to supporting new services in
+   the DNS.
+
+   [RFC3597] defined DNS implementation behavior and procedures for
+   defining new RR types aimed at simplifying the deployment of new RR
+   types by allowing them to be treated transparently by existing
+   implementations.  Thanks to the widespread adoption of that
+   specification, much of the DNS is now capable of handling new record
+   types without software changes.
+
+   This document is a self-contained revised specification supplanting
+   and obsoleting [RFC3597].
+
+2.  Definitions
+
+   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].
+
+   An "RR of unknown type" is an RR whose RDATA format is not known to
+   the DNS implementation at hand, and whose type is not an assigned
+   QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within
+   the range reserved in that section for assignment only to QTYPEs and
+   Meta-TYPEs.  Such an RR cannot be converted to a type-specific text
+   format, compressed, or otherwise handled in a type-specific way.
+
+   In the case of a type whose RDATA format is class specific, an RR is
+   considered to be of unknown type when the RDATA format for that
+   combination of type and class is not known.
+
+3.  Transparency
+
+   To enable new RR types to be deployed without server changes, name
+   servers and resolvers MUST handle RRs of unknown type transparently.
+   That is, they must treat the RDATA section of such RRs as
+   unstructured binary data, storing and transmitting it without change
+   [RFC1123].
+
+
+
+
+Expires March 2010           Standards Track                    [Page 2]
+
+draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
+
+
+   To ensure the correct operation of equality comparison (section 6)
+   and of the DNSSEC canonical form (section 7) when an RR type is known
+   to some but not all of the servers involved, servers MUST also
+   exactly preserve the RDATA of RRs of known type, except for changes
+   due to compression or decompression where allowed by section 4 of
+   this document.  In particular, the character case of domain names
+   that are not subject to compression MUST be preserved.
+
+4.  Domain Name Compression
+
+   RRs containing compression pointers in the RDATA part cannot be
+   treated transparently, as the compression pointers are only
+   meaningful within the context of a DNS message.  Transparently
+   copying the RDATA into a new DNS message would cause the compression
+   pointers to point at the corresponding location in the new message,
+   which now contains unrelated data.  This would cause the compressed
+   name to be corrupted.
+
+   To avoid such corruption, servers MUST NOT compress domain names
+   embedded in the RDATA of types that are class-specific or not well-
+   known.  This requirement was stated in [RFC1123] without defining the
+   term "well-known"; it is hereby specified that only the RR types
+   defined in [RFC1035] are to be considered "well-known".
+
+   Receiving servers MUST decompress domain names in RRs of well-known
+   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
+   NXT, NAPTR, and SRV to ensure interoperability with implementations
+   predating [RFC3597].
+
+   Specifications for new RR types that contain domain names within
+   their RDATA MUST NOT allow the use of name compression for those
+   names, and SHOULD explicitly state that the embedded domain names
+   MUST NOT be compressed.
+
+   As noted in [RFC1123], the owner name of an RR is always eligible for
+   compression.
+
+5.  Text Representation
+
+   In the "type" field of a master file line, an unknown RR type is
+   represented by the word "TYPE" immediately followed by the decimal RR
+   type number, with no intervening whitespace.  In the "class" field,
+   an unknown class is similarly represented as the word "CLASS"
+   immediately followed by the decimal class number.
+
+   This convention allows types and classes to be distinguished from
+   each other and from TTL values, allowing the "[] []
+    " and "[] []  " forms of
+
+
+
+Expires March 2010           Standards Track                    [Page 3]
+
+draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
+
+
+   [RFC1035] to both be unambiguously parsed.
+
+   The RDATA section of an RR of unknown type is represented as a
+   sequence of white space separated words as follows:
+
+      The special token \# (a backslash immediately followed by a hash
+      sign), which identifies the RDATA as having the generic encoding
+      defined herein rather than a traditional type-specific encoding.
+
+      An unsigned decimal integer specifying the RDATA length in octets.
+
+      Zero or more words of hexadecimal data encoding the actual RDATA
+      field, each containing an even number of hexadecimal digits.
+
+   If the RDATA is of zero length, the text representation contains only
+   the \# token and the single zero representing the length.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires March 2010           Standards Track                    [Page 4]
+
+draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
+
+
+   An implementation MAY also choose to represent some RRs of known type
+   using the above generic representations for the type, class and/or
+   RDATA, which carries the benefit of making the resulting master file
+   portable to servers where these types are unknown.  Using the generic
+   representation for the RDATA of an RR of known type can also be
+   useful in the case of an RR type where the text format varies
+   depending on a version, protocol, or similar field (or several)
+   embedded in the RDATA when such a field has a value for which no text
+   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
+   0.
+
+   Even though an RR of known type represented in the \# format is
+   effectively treated as an unknown type for the purpose of parsing the
+   RDATA text representation, all further processing by the server MUST
+   treat it as a known type and take into account any applicable type-
+   specific rules regarding compression, canonicalization, etc.
+
+   The following are examples of RRs represented in this manner,
+   illustrating various combinations of generic and type-specific
+   encodings for the different fields of the master file format:
+
+      a.example.   CLASS32     TYPE731         \# 6 abcd (
+                                               ef 01 23 45 )
+      b.example.   HS          TYPE62347       \# 0
+      e.example.   IN          A               \# 4 C0000201
+      e.example.   CLASS1      TYPE1           192.0.2.1
+
+6.  Equality Comparison
+
+   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
+   to be compared for equality.  Two RRs of the same unknown type are
+   considered equal when their RDATA is bitwise equal.  To ensure that
+   the outcome of the comparison is identical whether the RR is known to
+   the server or not, specifications for new RR types MUST NOT specify
+   type-specific comparison rules.
+
+   This implies that embedded domain names, being included in the
+   overall bitwise comparison, are compared in a case-sensitive manner.
+
+   As a result, when a new RR type contains one or more embedded domain
+   names, it is possible to have multiple RRs owned by the same name
+   that differ only in the character case of the embedded domain
+   name(s).  This is similar to the existing possibility of multiple TXT
+   records differing only in character case, and not expected to cause
+   any problems in practice.
+
+
+
+
+
+
+Expires March 2010           Standards Track                    [Page 5]
+
+draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
+
+
+7.  DNSSEC Considerations
+
+   The rules for the DNSSEC canonical form and ordering were updated to
+   support transparent treatment of unknown types in [RFC3597].  Those
+   updates have subsequently been integrated into the base DNSSEC
+   specification, such that the DNSSEC canonical form and ordering are
+   now specified in [RFC4034] or its successors rather than in this
+   document.
+
+8.  Additional Section Processing
+
+   Unknown RR types cause no additional section processing.  Future RR
+   type specifications MAY specify type-specific additional section
+   processing rules, but any such processing MUST be optional as it can
+   only be performed by servers for which the RR type in case is known.
+
+9.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+10.  Security Considerations
+
+   This specification is not believed to cause any new security
+   problems, nor to solve any existing ones.
+
+11.  Normative References
+
+   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
+               Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
+               Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5395]   Eastlake, D., "Domain Name System (DNS) IANA
+               Considerations", BCP 42, RFC 5395, November 2008.
+
+12.  Informative References
+
+   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
+               Means for Expressing Location Information in the Domain
+               Name System", RFC 1876, January 1996.
+
+
+
+
+Expires March 2010           Standards Track                    [Page 6]
+
+draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
+
+
+   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+   [RFC3597]   Gustafsson, A., "Handling of Unknown DNS Resource Record
+               (RR) Types", RFC 3597, September 2003.
+
+   [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "Resource Records for the DNS Security Extensions",
+               RFC 4034, March 2005.
+
+14.  Author's Address
+
+   Andreas Gustafsson
+   Araneus Information Systems Oy
+   PL 110
+   02321 Espoo
+   Finland
+
+   Phone: +358 40 547 2099
+   EMail: gson@araneus.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires March 2010           Standards Track                    [Page 7]
+
diff --git a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
deleted file mode 100644
index 0af13c616f99..000000000000
--- a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
+++ /dev/null
@@ -1,755 +0,0 @@
-
-
-Network Working Group                                          B. Laurie
-Internet-Draft                                                   Nominet
-Expires: March 2, 2005                                         R. Loomis
-                                                                    SAIC
-                                                          September 2004
-
-
-
-      Requirements related to DNSSEC Signed Proof of Non-Existence
-         draft-ietf-dnsext-signed-nonexistence-requirements-01
-
-
-Status of this Memo
-
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on March 2, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
-   DNSSEC-bis uses the NSEC record to provide authenticated denial of
-   existence of RRsets.  NSEC also has the side-effect of permitting
-   zone enumeration, even if zone transfers have been forbidden.
-   Because some see this as a problem, this document has been assembled
-   to detail the possible requirements for denial of existence A/K/A
-   signed proof of non-existence.
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 1]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-Table of Contents
-
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Non-purposes . . . . . . . . . . . . . . . . . . . . . . . .   3
-   3.   Zone Enumeration . . . . . . . . . . . . . . . . . . . . . .   3
-   4.   Zone Enumeration II  . . . . . . . . . . . . . . . . . . . .   4
-   5.   Zone Enumeration III . . . . . . . . . . . . . . . . . . . .   4
-   6.   Exposure of Contents . . . . . . . . . . . . . . . . . . . .   4
-   7.   Zone Size  . . . . . . . . . . . . . . . . . . . . . . . . .   4
-   8.   Single Method  . . . . . . . . . . . . . . . . . . . . . . .   5
-   9.   Empty Non-terminals  . . . . . . . . . . . . . . . . . . . .   5
-   10.  Prevention of Precomputed Dictionary Attacks . . . . . . . .   6
-   11.  DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . .   6
-   12.  Non-overlap of denial records with possible zone records . .   7
-   13.  Exposure of Private Keys . . . . . . . . . . . . . . . . . .   7
-   14.  Minimisation of Zone Signing Cost  . . . . . . . . . . . . .   8
-   15.  Minimisation of Asymmetry  . . . . . . . . . . . . . . . . .   8
-   16.  Minimisation of Client Complexity  . . . . . . . . . . . . .   8
-   17.  Completeness . . . . . . . . . . . . . . . . . . . . . . . .   8
-   18.  Purity of Namespace  . . . . . . . . . . . . . . . . . . . .   8
-   19.  Replay Attacks . . . . . . . . . . . . . . . . . . . . . . .   8
-   20.  Compatibility with NSEC  . . . . . . . . . . . . . . . . . .   8
-   21.  Compatibility with NSEC II . . . . . . . . . . . . . . . . .   9
-   22.  Compatibility with NSEC III  . . . . . . . . . . . . . . . .   9
-   23.  Coexistence with NSEC  . . . . . . . . . . . . . . . . . . .   9
-   24.  Coexistence with NSEC II . . . . . . . . . . . . . . . . . .   9
-   25.  Protocol Design  . . . . . . . . . . . . . . . . . . . . . .   9
-   26.  Process  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
-   27.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9
-   28.  Requirements notation  . . . . . . . . . . . . . . . . . . .   9
-   29.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
-   30.  References . . . . . . . . . . . . . . . . . . . . . . . . .  10
-   30.1   Normative References . . . . . . . . . . . . . . . . . . .  10
-   30.2   Informative References . . . . . . . . . . . . . . . . . .  10
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  10
-        Intellectual Property and Copyright Statements . . . . . . .  11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 2]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-1.  Introduction
-
-
-   NSEC records allow trivial enumeration of zones - a situation that
-   has existed for several years but which has recently been raised as a
-   significant concern for DNSSECbis deployment in several zones.
-   Alternate proposals have been made that make zone enumeration more
-   difficult, and some previous proposals to modify DNSSEC had related
-   requirements/desirements that are relevant to the discussion.  In
-   addition the original designs for NSEC/NXT records were based on
-   working group discussions and the choices made were not always
-   documented with context and requirements-- so some of those choices
-   may need to be restated as requirements.  Overall, the working group
-   needs to better understand the requirements for denial of existence
-   (and certain other requirements related to DNSSECbis deployment) in
-   order to evaluate the proposals that may replace NSEC.
-
-
-   In the remainder of this document, "NSEC++" is used as shorthand for
-   "a denial of existence proof that will replace NSEC".  "NSECbis" has
-   also been used as shorthand for this, but we avoid that usage since
-   NSECbis will not be part of DNSSECbis and therefore there might be
-   some confusion.
-
-
-2.  Non-purposes
-
-
-   This document does not currently document the reasons why zone
-   enumeration might be "bad" from a privacy, security, business, or
-   other perspective--except insofar as those reasons result in
-   requirements.  Once the list of requirements is complete and vaguely
-   coherent, the trade-offs (reducing zone enumeration will have X cost,
-   while providing Y benefit) may be revisited.  The editors of this
-   compendium received inputs on the potential reasons why zone
-   enumeration is bad (and there was significant discussion on the
-   DNSEXT WG mailing list) but that information fell outside the scope
-   of this document.
-
-
-   Note also that this document does not assume that NSEC *must* be
-   replaced with NSEC++, if the requirements can be met through other
-   methods (e.g., "white lies" with the current NSEC).  As is stated
-   above, this document is focused on requirements collection and
-   (ideally) prioritization rather than on the actual implementation.
-
-
-3.  Zone Enumeration
-
-
-   Authenticated denial should not permit trivial zone enumeration.
-
-
-   Additional discussion:  NSEC (and NXT before it) provide a linked
-   list that could be "walked" to trivially enumerate all the signed
-   records in a zone.  This requirement is primarily (though not
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 3]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   exclusively) important for zones that either are delegation-only/
-   -mostly or do not have reverse lookup (PTR) records configured, since
-   enterprises that have PTR records for all A records have already
-   provided a similar capability to enumerate the contents of DNS zones.
-
-
-   Contributor: various
-
-
-4.  Zone Enumeration II
-
-
-   Zone enumeration should be at least as difficult as it would be to
-   effect a dictionary attack using simple DNS queries to do the same in
-   an unsecured zone.
-
-
-   (Editor comment: it is not clear how to measure difficulty in this
-   case.  Some examples could be monetary cost, bandwidth, processing
-   power or some combination of these.  It has also been suggested that
-   the requirement is that the graph of difficulty of enumeration vs.
-   the fraction of the zone enumerated should be approximately the same
-   shape in the two cases)
-
-
-   Contributor: Nominet
-
-
-5.  Zone Enumeration III
-
-
-   Enumeration of a zone with random contents should computationally
-   infeasible.
-
-
-   Editor comment: this is proposed as a way of evaluating the
-   effectiveness of a proposal rather than as a requirement anyone would
-   actually have in practice.
-
-
-   Contributor: Alex Bligh
-
-
-6.  Exposure of Contents
-
-
-   NSEC++ should not expose any of the contents of the zone (apart from
-   the NSEC++ records themselves, of course).
-
-
-   Editor comment: this is a weaker requirement than prevention of
-   enumeration, but certainly any zone that satisfied this requirement
-   would also satisfy the trivial prevention of enumeration requirement.
-
-
-   Contributor: Ed Lewis
-
-
-7.  Zone Size
-
-
-   Requirement:  NSEC++ should make it possible to take precautions
-   against trivial zone size estimates.  Since not all zone owners care
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 4]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   about others estimation of the size of a zone, it is not always
-   necessary to prohibit trivial estimation of the size of the zone but
-   NSEC++ should allow such measures.
-
-
-   Additional Discussion: Even with proposals based on obfuscating names
-   with hashes it is trivial to give very good estimates of the number
-   of domains in a certain zone.  Just send 10 random queries and look
-   at the range between the two hash values returned in each NSEC++.  As
-   hash output can be assumed to follow a rectangular random
-   distribution, using the mean difference between the two values, you
-   can estimate the total number of records.  It is probably sufficient
-   to look at even one NSEC++, since the two hash values should follow a
-   (I believe) Poisson distribution.
-
-
-   The concern is motivated by some wording remembered from NSEC, which
-   stated that NSEC MUST only be present for existing owner names in the
-   zone, and MUST NOT be present for non-existing owner names.  If
-   similar wording were carried over to NSEC++, introducing bogus owner
-   names in the hash chain (an otherwise simple solution to guard
-   against trivial estimates of zone size) wouldn't be allowed.
-
-
-   One simple attempt at solving this is to describe in the
-   specifications how zone signer tools can add a number of random
-   "junk" records.
-
-
-   Editor's comment: it is interesting that obfuscating names might
-   actually make it easier to estimate zone size.
-
-
-   Contributor: Simon Josefsson.
-
-
-8.  Single Method
-
-
-   Requirement:  A single NSEC++ method must be able to carry both
-   old-style denial (i.e.  plain labels) and whatever the new style
-   looks like.  Having two separate denial methods could result in
-   cornercases where one method can deny the other and vice versa.
-
-
-   Additional discussion:  This requirement can help -bis folks to a
-   smooth upgrade to -ter.  First they'd change the method while the
-   content is the same, then they can change content of the method.
-
-
-   Contributor: Roy Arends.
-
-
-9.  Empty Non-terminals
-
-
-   Requirement:  Empty-non-terminals (ENT) should remain empty.  In
-   other words, adding NSEC++ records to an existing DNS structure
-   should not cause the creation of NSEC++ records (or related records)
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 5]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   at points that are otherwise ENT.
-
-
-   Additional discussion:  Currently NSEC complies with ENT requirement:
-   b.example.com NSEC a.c.example.com implies the existence of an ENT
-   with ownername c.example.com.  NSEC2 breaks that requirement, since
-   the ownername is entirely hashed causing the structure to disappear.
-   This is why EXIST was introduced.  But EXIST causes ENT to be
-   non-empty-terminals.  Next to the dissappearance of ENT, it causes
-   (some) overhead since an EXIST record needs a SIG, NSEC2 and
-   SIG(NSEC2).  DNSNR honours this requirement by hashing individual
-   labels instead of ownernames.  However this causes very long labels.
-   Truncation is a measure against very long ownernames, but that is
-   controversial.  There is a fair discussion of the validity of
-   truncation in the DNSNR draft, but that hasn't got proper review yet.
-
-
-   Contributor: Roy Arends.
-
-
-   (Editor comment: it is not clear to us that an EXIST record needs an
-   NSEC2 record, since it is a special purpose record only used for
-   denial of existence)
-
-
-10.  Prevention of Precomputed Dictionary Attacks
-
-
-   Requirement:  NSEC++ needs to provide a method to reduce the
-   effectiveness of precomputed dictionary attacks.
-
-
-   Additional Discussion:  Salt is a measure against dictionary attacks.
-   There are other possible measures (such as iterating hashes in
-   NSEC2).  The salt needs to be communicated in every response, since
-   it is needed in every verification.  Some have suggested to move the
-   salt to a special record instead of the denial record.  I think this
-   is not wise.  Response size has more priority over zone size.  An
-   extra record causes a larger response than a larger existing record.
-
-
-   Contributor: Roy Arends.
-
-
-   (Editor comment: the current version of NSEC2 also has the salt in
-   every NSEC2 record)
-
-
-11.  DNSSEC-Adoption and Zone-Growth Relationship
-
-
-   Background:  Currently with NSEC, when a delegation centric zone
-   deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
-   when the DNSSEC-adoption rate of the subzones remains low--because
-   each delegation point creates at least one NSEC record and
-   corresponding signature in the parent even if the child is not
-   signed.
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 6]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   Requirements:  A delegation-only (or delegation-mostly) zone that is
-   signed but which has no signed child zones should initially need only
-   to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
-   minimal set of NSEC++ records to cover zone contents.  Further,
-   during the transition of a delegation-only zone from 0% signed
-   children to 100% signed children, the growth in the delegation-only
-   zone should be roughly proportional to the percentage of signed child
-   zones.
-
-
-   Additional Discussion: This is why DNSNR has the Authoritative Only
-   bit.  This is similar to opt-in for delegations only.  This (bit) is
-   currently the only method to help delegation-centric zone cope with
-   zone-growth due to DNSSEC adoption.  As an example, A delegation only
-   zone which deploys DNSSEC with the help of this bit, needs to add
-   SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex.  No
-   more than that.
-
-
-   Contributor: Roy Arends.
-
-
-12.  Non-overlap of denial records with possible zone records
-
-
-   Requirement:  NSEC++ records should in some way be differentiated
-   from regular zone records, so that there is no possibility that a
-   record in the zone could be duplicated by a non-existence proof
-   (NSEC++) record.
-
-
-   Additional discussion:  This requirement is derived from a discussion
-   on the DNSEXT mailing list related to copyrights and domain names.
-   As was outlined there, one solution is to put NSEC++ records in a
-   separate namespace, e.g.: $ORIGIN co.uk.
-   873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
-   delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
-   ; for amazon.co.uk.
-
-
-   Contributor: various
-
-
-   (Editor comment:  One of us still does not see why a conflict
-   matters.  Even if there is an apparent conflict or overlap, the
-   "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
-   other name _never_ appears in NSEC2 records.)
-
-
-13.  Exposure of Private Keys
-
-
-   Private keys associated with the public keys in the DNS should be
-   exposed as little as possible.  It is highly undesirable for private
-   keys to be distributed to nameservers, or to otherwise be available
-   in the run-time environment of nameservers.
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 7]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   Contributors: Nominet, Olaf Kolkman, Ed Lewis
-
-
-14.  Minimisation of Zone Signing Cost
-
-
-   The additional cost of creating an NSEC++ signed zone should not
-   significantly exceed the cost of creating an ordinary signed zone.
-
-
-   Contributor: Nominet
-
-
-15.  Minimisation of Asymmetry
-
-
-   Nameservers should have to do as little additional work as necessary.
-   More precisely, it is desirable for any increase in cost incurred by
-   the nameservers to be offset by a proportionate increase in cost to
-   DNS `clients', e.g.  stub and/or `full-service' resolvers.
-
-
-   Contributor: Nominet
-
-
-16.  Minimisation of Client Complexity
-
-
-   Caching, wildcards, CNAMEs, DNAMEs should continue to work without
-   adding too much complexity at the client side.
-
-
-   Contributor: Olaf Kolkman
-
-
-17.  Completeness
-
-
-   A proof of nonexistence should be possible for all nonexistent data
-   in the zone.
-
-
-   Contributor: Olaf Kolkman
-
-
-18.  Purity of Namespace
-
-
-   The name space should not be muddied with fake names or data sets.
-
-
-   Contributor: Ed Lewis
-
-
-19.  Replay Attacks
-
-
-   NSEC++ should not allow a replay to be used to deny existence of an
-   RR that actually exists.
-
-
-   Contributor: Ed Lewis
-
-
-20.  Compatibility with NSEC
-
-
-   NSEC++ should not introduce changes incompatible with NSEC.
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 8]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   Contributor: Ed Lewis
-
-
-21.  Compatibility with NSEC II
-
-
-   NSEC++ should differ from NSEC in a way that is transparent to the
-   resolver or validator.
-
-
-   Contributor: Ed Lewis
-
-
-22.  Compatibility with NSEC III
-
-
-   NSEC++ should differ from NSEC as little as possible whilst achieving
-   other requirements.
-
-
-   Contributor: Alex Bligh
-
-
-23.  Coexistence with NSEC
-
-
-   NSEC++ should be optional, allowing NSEC to be used instead.
-
-
-   Contributor: Ed Lewis, Alex Bligh
-
-
-24.  Coexistence with NSEC II
-
-
-   NSEC++ should not impose extra work on those content with NSEC.
-
-
-   Contributor: Ed Lewis
-
-
-25.  Protocol Design
-
-
-   A good security protocol would allow signing the nonexistence of some
-   selected names without revealing anything about other names.
-
-
-   Contributor: Dan Bernstein
-
-
-26.  Process
-
-
-   Clearly not all of these requirements can be met.  Therefore the next
-   phase of this document will be to either prioritise them or narrow
-   them down to a non-contradictory set, which should then allow us to
-   judge proposals on the basis of their fit.
-
-
-27.  Acknowledgements
-
-
-28.  Requirements notation
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 9]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   document are to be interpreted as            described in [RFC2119].
-
-
-29.  Security Considerations
-
-
-   There are currently no security considerations called out in this
-   draft.  There will be security considerations in the choice of which
-   requirements will be implemented, but there are no specific security
-   requirements during the requirements collection process.
-
-
-30.  References
-
-
-30.1  Normative References
-
-
-   [dnssecbis-protocol]
-              "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
-              Month 2004.
-
-
-30.2  Informative References
-
-
-   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
-              3", BCP 9, RFC 2026, October 1996.
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
-              Procedures", BCP 25, RFC 2418, September 1998.
-
-
-
-Authors' Addresses
-
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London  W3 7LR
-   England
-
-
-   Phone: +44 (20) 8735 0686
-   EMail: ben@algroup.co.uk
-
-
-
-   Rip Loomis
-   Science Applications International Corporation
-   7125 Columbia Gateway Drive, Suite 300
-   Columbia, MD  21046
-   US
-
-
-   EMail: gilbert.r.loomis@saic.com
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                 [Page 10]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                 [Page 11]
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
deleted file mode 100644
index 9c73c68befdc..000000000000
--- a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
+++ /dev/null
@@ -1,1292 +0,0 @@
-
-
-
-
-
-DNS Extensions                                              Yuji Kamite
-Internet-Draft                                       NTT Communications
-Expires: April 15, 2005                                 Masaya Nakayama
-                                                The University of Tokyo
-                                                       October 14, 2004
-
-
-
-                      TKEY Secret Key Renewal Mode
-                 draft-ietf-dnsext-tkey-renewal-mode-05
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 15, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document defines a new mode in TKEY and proposes an atomic
-   method for changing secret keys used for TSIG periodically.
-   Originally, TKEY provides methods of setting up shared secrets other
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 1]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   than manual exchange, but it cannot control timing of key renewal
-   very well though it can add or delete shared keys separately. This
-   proposal is a systematical key renewal procedure intended for
-   preventing signing DNS messages with old and non-safe keys
-   permanently.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1   Defined Words  . . . . . . . . . . . . . . . . . . . . . .  3
-     1.2   New Format and Assigned Numbers  . . . . . . . . . . . . .  4
-     1.3   Overview of Secret Key Renewal Mode  . . . . . . . . . . .  4
-   2.  Shared Secret Key Renewal  . . . . . . . . . . . . . . . . . .  5
-     2.1   Key Usage Time Check . . . . . . . . . . . . . . . . . . .  5
-     2.2   Partial Revocation . . . . . . . . . . . . . . . . . . . .  6
-     2.3   Key Renewal Message Exchange . . . . . . . . . . . . . . .  7
-       2.3.1   Query for Key Renewal  . . . . . . . . . . . . . . . .  7
-       2.3.2   Response for Key Renewal . . . . . . . . . . . . . . .  7
-       2.3.3   Attributes of Generated Key  . . . . . . . . . . . . .  8
-       2.3.4   TKEY RR structure  . . . . . . . . . . . . . . . . . .  8
-     2.4   Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
-       2.4.1   Query for Key Adoption . . . . . . . . . . . . . . . . 10
-       2.4.2   Response for Key Adoption  . . . . . . . . . . . . . . 10
-     2.5   Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
-       2.5.1   DH Exchange for Key Renewal  . . . . . . . . . . . . . 11
-       2.5.2   Server Assigned Keying for Key Renewal . . . . . . . . 12
-       2.5.3   Resolver Assigned Keying for Key Renewal . . . . . . . 13
-     2.6   Considerations about Non-compliant Hosts . . . . . . . . . 14
-   3.  Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
-   4.  Compulsory Key Revocation  . . . . . . . . . . . . . . . . . . 15
-     4.1   Compulsory Key Revocation by Server  . . . . . . . . . . . 15
-     4.2   Authentication Methods Considerations  . . . . . . . . . . 15
-   5.  Special Considerations for Two Servers' Case   . . . . . . . . 16
-     5.1   To Cope with Collisions of Renewal Requests  . . . . . . . 16
-   6.  Key Name Considerations  . . . . . . . . . . . . . . . . . . . 17
-   7.  Example Usage of Secret Key Renewal Mode   . . . . . . . . . . 17
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
-  10.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
-  11.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-    11.1   Normative References . . . . . . . . . . . . . . . . . . . 21
-    11.2   Informative References . . . . . . . . . . . . . . . . . . 21
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
-       Intellectual Property and Copyright Statements . . . . . . . . 23
-
-
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 2]
-
-INTERNET-DRAFT                                              October 2004
-
-
-1.  Introduction
-
-   TSIG [RFC2845] provides DNS message integrity and the
-   request/transaction authentication by means of message authentication
-   codes (MAC). TSIG is a practical solution in view of calculation
-   speed and availability. However, TSIG does not have exchanging
-   mechanism of shared secret keys between server and resolver, and
-   administrators might have to exchange secret keys manually. TKEY
-   [RFC2930] is introduced to solve such problem and it can exchange
-   secrets for TSIG via networks.
-
-   In various modes of TKEY, a server and a resolver can add or delete a
-   secret key be means of TKEY message exchange. However, the existing
-   TKEY does not care fully about the management of keys which became
-   too old, or dangerous after long time usage.
-
-   It is ideal that the number of secret which a pair of hosts share
-   should be limited only one, because having too many keys for the same
-   purpose might not only be a burden to resolvers for managing and
-   distinguishing according to servers to query, but also does not seem
-   to be safe in terms of storage and protection against attackers.
-   Moreover, perhaps holding old keys long time might give attackers
-   chances to compromise by scrupulous calculation.
-
-   Therefore, when a new shared secret is established by TKEY, the
-   previous old secret should be revoked immediately. To accomplish
-   this, DNS servers must support a protocol for key renewal. This
-   document specifies procedure to refresh secret keys between two hosts
-   which is defined within the framework of TKEY, and it is called "TKEY
-   Secret Key Renewal Mode".
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
-   "OPTIONAL" in this document are to be interpreted as described in
-   [RFC2119].
-
-
-1.1.  Defined Words
-
-   * Inception Time: Beginning of the shared secret key lifetime. This
-   value is determined when the key is generated.
-
-   * Expiry Limit: Time limit of the key's validity. This value is
-   determined when a new key is generated. After Expiry Limit, server
-   and client (resolver) must not authenticate TSIG signed with the key.
-   Therefore, Renewal to the next key should be carried out before
-   Expiry Limit.
-
-   * Partial Revocation Time: Time when server judges the key is too old
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 3]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   and must be updated. It must be between Inception Time and Expiry
-   Limit.  This value is determined by server freely following its
-   security policy. e.g., If the time from Inception to Partial
-   Revocation is short, renewal will be carried out more often, which
-   might be safer.
-
-   * Revocation Time: Time when the key becomes invalid and can be
-   removed. This value is not determined in advance because it is the
-   actual time when revocation is completed.
-
-   * Adoption Time: Time when the new key is adopted as the next key
-   formally. After Adoption, the key is valid and server and client can
-   generate or verify TSIG making use of it. Adoption Time also means
-   the time when it becomes possible to remove the previous key, so
-   Revocation and Adoption are usually done at the same time.
-
-
-                  Partial
-    Inception     Revocation    Revocation         Expiry Limit
-     |                |              |             |
-     |----------------|- - - - - - >>|- (revoked) -|
-     |                |              |             |
-    previous key      |      |       |
-                             |- - - -|-------------------->> time
-                             |       |               new key
-                         Inception   Adoption
-
-
-1.2.  New Format and Assigned Numbers
-
-   TSIG
-         ERROR = (PartialRevoke), TBD
-
-   TKEY
-         Mode  = (server assignment for key renewal), TBD
-         Mode  = (Diffie-Hellman exchange for key renewal), TBD
-         Mode  = (resolver assignment for key renewal), TBD
-         Mode  = (key adoption), TBD
-
-
-1.3.  Overview of Secret Key Renewal Mode
-
-   When a server receives a query from a client signed with a TSIG key,
-   It always checks if the present time is within the range of usage
-   duration it considers safe. If it is judged that the key is too old,
-   i.e., after Partial Revocation Time, the server comes to be in
-   Partial Revocation state about the key, and this key is called
-   partially revoked.
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 4]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   In this state, if a client sends a normal query (e.g., question about
-   A RR) other than TKEY Renewal request with TSIG signed with the old
-   key, the server returns an error message to notify that the time to
-   renew has come. This is called "PartialRevoke" error message. It is
-   server's choice whether it returns PartialRevoke or not. If and only
-   if the server is ready for changing its own key, it decides to return
-   PartialRevoke.
-
-   The client which got this error is able to notice that it is
-   necessary to refresh the secret. To make a new shared secret, it
-   sends a TKEY Renewal request, in which several keying methods are
-   available. It can make use of TSIG authentication signed with the
-   partially revoked key mentioned above.
-
-   After new secret establishment, the client sends a TKEY Adoption
-   request for renewal confirmation. This can also be authenticated with
-   the partially revoked key. If this is admitted by the server, the new
-   key is formally adopted, and at the same time the corresponding old
-   secret is invalidated. Then the client can send the first query again
-   signed with the new key.
-
-   Key renewal procedure is executed based on two-phase commit
-   mechanism. The first phase is the TKEY Renewal request and its
-   response, which means preparatory confirmation for key update. The
-   second phase is Adoption request and its response. If the server gets
-   request and client receives the response successfully, they can
-   finish renewal process. If any error happens and renewal process
-   fails during these phases, client should roll back to the beginning
-   of the first phase, and send TKEY Renewal request again. This
-   rollback can be done until the Expiry Limit of the key.
-
-
-2.  Shared Secret Key Renewal
-
-   Suppose a server and a client agree to change their TSIG keys
-   periodically. Key renewal procedure is defined between two hosts.
-
-2.1.  Key Usage Time Check
-
-   Whenever a server receives a query with TSIG and can find a key that
-   is used for signing it, the server checks its Inception Time, Partial
-   Revocation Time and Expiry Limit (this information is usually
-   memorized by the server).
-
-   When the present time is before Inception Time, the server MUST NOT
-   verify TSIG with the key, and server acts the same way as when the
-   key used by the client is not recognized. It follows [RFC2845] 4.5.1.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 5]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   When the present time is equal to Inception Time, or between
-   Inception Time and Partial Revocation Time, the behavior of the
-   server is the same as when a valid key is found. It follows [RFC2845]
-   4.5.2 and 4.5.3.
-
-   When the present time is the same as the Partial Revocation Time, or
-   between the Partial Revocation Time and Expiry Limit, the server
-   comes to be in Partial Revocation state about the TSIG key and
-   behaves according to the next section.
-
-   When the present time is the same as the Expiry Time or after it, the
-   server MUST NOT verify TSIG with the key, and returns error messages
-   in the same way as when the key used by the client is not recognized.
-   It follows [RFC2845] 4.5.1.
-
-
-2.2.  Partial Revocation
-
-   In Partial Revocation state, we say the server has partially revoked
-   the key and the key has become a "partially revoked key".
-
-   If server has received a query signed with the partially revoked key
-   for TKEY Renewal request (See section 2.3.) or Key Adoption request
-   (See section 2.4.), then server does proper process following each
-   specification. If it is for TKEY key deletion request ([RFC2930]
-   4.2), server MAY process usual deletion operation defined therein.
-
-   If server receives other types of query signed with the partially
-   revoked key, and both the corresponding MAC and signed TIME are
-   verified, then server begins returning answer whose TSIG error code
-   is "PartialRevoke" (See section 9.). Server MUST randomly but with
-   increasing frequency return PartialRevoke when in the Partial
-   Revocation state.
-
-   Server can decide when it actually sends PartialRevoke, checking if
-   it is appropriate time for renewal. Server MUST NOT return
-   PartialRevoke if this is apart long lived TSIG transaction (such as
-   AXFR) that started before the Partial Revocation Time.
-
-   If the client receives PartialRevoke and understands it, then it MUST
-   retry the query with the old key unless a new key has been adopted.
-   Client SHOULD start the process to renew the TSIG key. For key
-   renewal procedure, see details in Section 2.3 and 2.4.
-
-   PartialRevoke period (i.e., time while server returns PartialRevoke
-   randomely) SHOULD be small, say 2-5% of key lifetime. This is
-   server's choice.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 6]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   Server MUST keep track of clients ignoring PartialRevoke, thus
-   indicating ignorance of this TKEY mode.
-
-   PartialRevoke error messages have the role to inform clients of the
-   keys' partial revocation and urge them to send TKEY Renewal requests.
-   These error responses MUST be signed with those partial revoked keys
-   if the queries are signed with them. They are sent only when the
-   signing keys are found to be partially revoked. If the MAC of TSIG
-   cannot be verified with the partially revoked keys, servers MUST NOT
-   return PartialRevoke error with MAC, but MUST return another error
-   such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
-   words, a server informs its key's partial revocation only when the
-   MAC in the received query is valid.
-
-
-2.3.  Key Renewal Message Exchange
-
-2.3.1.  Query for Key Renewal
-
-   If a client has received a PartialRevoke error and authenticated the
-   response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
-   this document, we call it Renewal request, too.) to the server. The
-   request MUST be signed with TSIG or SIG(0) [RFC2931] for
-   authentication. If TSIG is selected, the client can sign it with the
-   partial revoked key.
-
-   Key Renewal can use one of several keying methods which is indicated
-   in "Mode" field of TKEY RR, and its message structure is dependent on
-   that method.
-
-
-2.3.2.  Response for Key Renewal
-
-   The server which has received Key Renewal request first tries to
-   verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
-   verified with the partially revoked key, the request MUST be
-   authenticated.
-
-   After authentication, server must check existing old key's validity.
-   If the partially revoked key indicated in the request TKEY's OldName
-   and OldAlgorithm field (See section 2.3.4.) does not exist at the
-   server, "BADKEY" [RFC2845] is given in Error field for response. If
-   any other error happens, server returns appropriate error messages
-   following the specification described in section 2.5. If there are no
-   errors, server returns a Key Renewal answer. This answer MUST be
-   signed with TSIG or SIG(0) for authentication.
-
-   When this answer is successfully returned and no error is detected by
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 7]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   client, a new shared secret can be established. The details of
-   concrete keying procedure are given in the section 2.5.
-
-   Note:
-      Sometimes Adoption message and new Renewal request will cross on
-      the wire. In this case the newly generated key Adoption message is
-      resent.
-
-
-2.3.3.  Attributes of Generated Key
-
-   As a result of this message exchange, client comes to know the newly
-   generated key's attributes such as key's name, Inception Time and
-   Expiry Limit. They are decided by the server and told to the client;
-   in particular, however, once the server has decided Expiry Limit and
-   returned a response, it should obey the decision as far as it can. In
-   other words, they SHOULD NOT change time values for checking Expiry
-   Limit in the future without any special reason, such as security
-   issue like "Emergency Compulsory Revocation" described in section 8.
-
-   On the other hand, Partial Revocation Time of this generated key is
-   not decided based on the request, and not informed to the client. The
-   server can determine any value as long as it is between Inception
-   Time and Expiry Limit. However, the period from Inception to Partial
-   Revocation SHOULD be fixed as the server side's configuration or be
-   set the same as the corresponding old key's one.
-
-   Note:
-      Even if client sends Key Renewal request though the key described
-      in OldName has not been partially revoked yet, server does renewal
-      processes.  At the moment when the server accepts such requests
-      with valid authentication, it MUST forcibly consider the key is
-      already partially revoked, that is, the key's Partial Revocation
-      Time must be changed into the present time (i.e., the time when
-      the server receives the request).
-
-
-2.3.4.  TKEY RR structure
-
-   TKEY RR for Key Renewal message has the structure given below. In
-   principle, format and definition for each field follows [RFC2930].
-   Note that each keying scheme sometimes needs different interpretation
-   of RDATA field; for detail, see section 2.5.
-
-        Field        Type         Comment
-        -------      ------       -------
-        NAME         domain       used for a new key, see below
-        TYPE         u_int16_t    (defined in [RFC2930])
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 8]
-
-INTERNET-DRAFT                                              October 2004
-
-
-        CLASS        u_int16_t    (defined in [RFC2930])
-        TTL          u_int32_t    (defined in [RFC2930])
-        RDLEN        u_int16_t    (defined in [RFC2930])
-        RDATA:
-         Algorithm:   domain       algorithm for a new key
-         Inception:   u_int32_t    about the keying material
-         Expiration:  u_int32_t    about the keying material
-         Mode:        u_int16_t    scheme for key agreement
-                                   see section 9.
-         Error:       u_int16_t    see description below
-         Key Size:    u_int16_t    see description below
-         Key Data:    octet-stream
-         Other Size:  u_int16_t    (defined in [RFC2930])
-                                   size of other data
-         Other Data:               newly defined: see description below
-
-
-     For "NAME" field, both non-root and root name are allowed. It may
-     be used for a new key's name in the same manner as [RFC2930] 2.1.
-
-     "Algorithm" specifies which algorithm is used for agreed keying
-     material, which is used for identification of the next key.
-
-     "Inception" and "Expiration" are used for the valid period of
-     keying material. The meanings differ somewhat according to whether
-     the message is request or answer, and its keying scheme.
-
-     "Key Data" has different meanings according to keying schemes.
-
-     "Mode" field stores the value in accordance with the keying method,
-     and see section 2.5. Servers and clients supporting TKEY Renewal
-     method MUST implement "Diffie-Hellman exchange for key renewal"
-     scheme. All other modes are OPTIONAL.
-
-     "Error" is an extended RCODE which includes "PartialRevoke" value
-     too. See section 9.
-
-     "Other Data" field has the structure given below.  They describe
-     attributes of the key to be renewed.
-
-        in Other Data filed:
-
-          Field            Type       Comment
-          -------          ------     -------
-          OldNAME          domain     name of the old key
-          OldAlgorithm     domain     algorithm of the old key
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 9]
-
-INTERNET-DRAFT                                              October 2004
-
-
-          "OldName" indicates the name of the previous key (usually,
-          this is partially revoked key's name that client noticed by
-          PartialRevoke answer from server), and "OldAlogirthm"
-          indicates its algorithm.
-
-
-2.4.  Key Adoption
-
-2.4.1.  Query for Key Adoption
-
-   After receiving a TKEY Renewal answer, the client gets the same
-   secret as the server. Then, it sends a TKEY Adoption request. The
-   request's question section's QNAME field is the same as the NAME
-   filed of TKEY written below. In additional section, there is one TKEY
-   RR that has the structure and values described below.
-
-     "NAME" field is the new key's name to be adopted which was already
-     generated by Renewal message exchange. "Algorithm" is its
-     algorithm. "Inception" means the key's Inception Time, and
-     "Expiration" means Expiry Limit.
-
-     "Mode" field is the value of "key adoption". See section 9.
-
-     "Other Data" field in Adoption has the same structure as that of
-     Renewal request message. "OldName" means the previous old key, and
-     "OldAlogirthm" means its algorithm.
-
-   Key Adoption request MUST be signed with TSIG or SIG(0) for
-   authentication. The client can sign TSIG with the previous key. Note
-   that until Adoption is finished, the new key is treated as invalid,
-   thus it cannot be used for authentication immediately.
-
-
-2.4.2.  Response for Key Adoption
-
-   The server which has received Adoption request, it verifies TSIG or
-   SIG(0) accompanying it. If the TSIG is signed with the partially
-   revoked key and can be verified, the message MUST be authenticated.
-
-   If the next new key indicated by the request TKEY's "NAME" is not
-   present at the server, BADNAME [RFC2845] is given in Error field and
-   the error message is returned.
-
-   If the next key exists but it has not been adopted formally yet, the
-   server confirms the previous key's existence indicated by the
-   "OldName" and "OldAlgorithm" field. If it succeeds, the server
-   executes Adoption of the next key and Revocation of the previous key.
-   Response message duplicates the request's TKEY RR with NOERROR,
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 10]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   including "OldName" and "OldAlgorithm" that indicate the revoked key.
-
-   If the next key exists but it is already adopted, the server returns
-   a response message regardless of the substance of the request TKEY's
-   "OldName". In this response, Response TKEY RR has the same data as
-   the request's one except as to its "Other Data" that is changed into
-   null (i.e., "Other Size" is zero), which is intended for telling the
-   client that the previous key name was ignored, and the new key is
-   already available.
-
-   Client sometimes has to retry Adoption request. Suppose the client
-   sent request signed with the partially revoked key, but its response
-   did not return successfully (e.g., due to the drop of UDP packet).
-   Client will probably retry Adoption request; however, the request
-   will be refused in the form of TSIG "BADKEY" error because the
-   previous key was already revoked. In this case, client will
-   retransmit Adoption request signed with the next key, and expect a
-   response which has null "Other Data" for confirming the completion of
-   renewal.
-
-
-2.5.  Keying Schemes
-
-   In Renewal message exchanges, there are no limitations as to which
-   keying method is actually used. The specification of keying
-   algorithms is independent of the general procedure of Renewal that is
-   described in section 2.3.
-
-   Now this document specifies three algorithms in this section, but
-   other future documents can make extensions defining other methods.
-
-
-2.5.1.  DH Exchange for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.1. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as keying material
-   computation, are the exactly same as the specification of [RFC2930]
-   4.1.
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. KEY RR is
-      the client's Diffie-Hellman public key [RFC2539].
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 11]
-
-INTERNET-DRAFT                                              October 2004
-
-
-      TKEY "Mode" field stores the value of "DH exchange for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3. If
-      any incompatible DH key is found in the request, "BADKEY"
-      [RFC2845] is given in Error field for response. "FORMERR" is given
-      if the query included no DH KEY.
-
-      If there are no errors, the server processes a response according
-      to Diffie-Hellman algorithm and returns the answer. In this
-      answer, there is one TKEY RR in answer section and KEY RR(s) in
-      additional section.
-
-      As long as no error has occurred, all values of TKEY are equal to
-      that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
-      Inception, Expiration, Key Size and Key Data.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-      TKEY "Key Data" is used as an additional nonce, following
-      [RFC2930] 4.1.
-
-      The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
-      the additional section and a server Diffie-Hellman KEY RR will
-      also be present in the answer section, following [RFC2930] 4.1.
-
-
-2.5.2.  Server Assigned Keying for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.4. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as secret encrypting
-   method, are the exactly same as the specification of [RFC2930] 4.4.
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 12]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. KEY RR is
-      used in encrypting the response.
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-      TKEY "Mode" field stores the value of "server assignment for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is provided following the specification of
-      [RFC2930] 4.4.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3.
-      "FORMERR" is given if the query specified no encryption key.
-
-      If there are no errors, the server response contains one TKEY RR
-      in the answer section, and echoes the KEY RR provided in the query
-      in the additional information section.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-      TKEY "Key Data" is the assigned keying data encrypted under the
-      public key in the resolver provided KEY RR, which is the same as
-      [RFC2930] 4.4.
-
-
-2.5.3.  Resolver Assigned Keying for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.5. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as secret encrypting
-   method, are the exactly same as the specification of [RFC2930] 4.5.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 13]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. TKEY RR
-      has the encrypted keying material and KEY RR is the server public
-      key used to encrypt the data.
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-      TKEY "Mode" field stores the value of "resolver assignment for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is the encrypted keying material.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3.
-      "FORMERR" is given if the server does not have the corresponding
-      private key for the KEY RR that was shown sin the request.
-
-      If there are no errors, the server returns a response. The
-      response contains a TKEY RR in the answer section to tell the
-      shared key's name and its usage time values.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-
-2.6.  Considerations about Non-compliant Hosts
-
-   Key Renewal requests and responses must be exchanged between hosts
-   which can understand them and do proper processes. PartialRevoke
-   error messages will be only ignored if they should be returned to
-   non-compliant hosts.
-
-   Note that server does not inform actively the necessity of renewal to
-   clients, but inform it as responses invoked by client's query.
-   Server needs not care whether the PartialRevoke errors has reached
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 14]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   client or not. If client has not received yet because of any reasons
-   such as packet drops, it will resend the queries, and finally will be
-   able to get PartialRevoke information.
-
-
-3.  Secret Storage
-
-   Every server keeps all secrets and attached information, e.g.,
-   Inception Time, Expiry Limit, etc. safely to be able to recover from
-   unexpected stop. To accomplish this, formally adopted keys SHOULD be
-   memorized not only on memory, but also be stored in the form of some
-   files. It will become more secure if they are stored in ecrypted
-   form.
-
-
-4.  Compulsory Key Revocation
-
-4.1.  Compulsory Key Revocation by Server
-
-   There is a rare but possible case that although servers have already
-   partially revoked keys, clients do not try to send any Renewal
-   requests. If this state continues, in the future it will become the
-   time of Expiry Limit. After Expiry Limit, the keys will be expired
-   and completely removed, so this is called Compulsory Key Revocation
-   by server.
-
-   If Expiry Limit is too distant from the Partial Revocation Time, then
-   even though very long time passes, clients will be able to refresh
-   secrets only if they add TSIG signed with those old partially revoked
-   keys into requests, which is not safe.
-
-   On the other hand, if Expiry Limit is too close to Partial Revocation
-   Time, perhaps clients might not be able to notice their keys' Partial
-   Revocation by getting "PartialRevoke" errors.
-
-   Therefore, servers should set proper Expiry Limit to their keys,
-   considering both their keys' safety, and enough time for clients to
-   send requests and process renewal.
-
-
-4.2.  Authentication Methods Considerations
-
-   It might be ideal to provide both SIG(0) and TSIG as authentication
-   methods. For example:
-
-     A client and a server start SIG(0) authentication at first, to
-     establish TSIG shared keys by means of "Query for Diffie-Hellman
-     Exchanged Keying" as described in [RFC2930] 4.1. Once they get
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 15]
-
-INTERNET-DRAFT                                              October 2004
-
-
-     shared secret, they keep using TSIG for queries and responses.
-     After a while the server returns a "ParitalRevoke" error and they
-     begin a key renewal process. Both TSIG signed with partially
-     revoked keys and SIG(0) are okay for authentication, but TSIG would
-     be easier to use considering calculation efficiency.
-
-     Suppose now client is halted for long time with some reason.
-     Because server does not execute any renewal process, it will
-     finally do Compulsory Revocation. Even if client restarts and sends
-     a key Renewal request, it will fail because old key is already
-     deleted at server.
-
-     At this moment, however, if client also uses SIG(0) as another
-     authentication method, it can make a new shared key again and
-     recover successfully by sending "Query for Diffie-Hellman Exchanged
-     Keying" with SIG(0).
-
-
-5.  Special Considerations for Two servers' Case
-
-   This section refers to the case where both hosts are DNS servers
-   which can act as full resolvers as well and using one shared key
-   only. If one server (called Server A) wants to refresh a shared key
-   (called "Key A-B"), it will await a TKEY Renewal request from the
-   other server (called Server B). However, perhaps Server A wants to
-   refresh the key right now.
-
-   In this case, Server A is allowed to send a Renewal request to Server
-   B, if Server A knows the Key A-B is too old and wants to renew it
-   immediately.
-
-   Note that the initiative in key renewal belongs to Server A because
-   it can notice the Partial Revocation Time and decide key renewal. If
-   Server B has information about Partial Revocation Time as well, it
-   can also decide for itself to send Renewal request to Server A.
-   However, it is not essential for both two servers have information
-   about key renewal timing.
-
-5.1.  To Cope with Collisions of Renewal Requests
-
-   At least one of two hosts which use Key Renewal must know their key
-   renewal information such as Partial Revocation Time. It is okay that
-   both hosts have it.
-
-   Provided that both two servers know key renewal timing information,
-   there is possibility for them to begin partial revocation and sending
-   Renewal requests to each other at the same time. Such collisions will
-   not happen so often because Renewal requests are usually invoked when
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 16]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   hosts want to send queries, but it is possible.
-
-   When one of two servers tries to send Renewal requests, it MUST
-   protect old secrets that it has partially revoked and prevent it from
-   being refreshed by any requests from the other server (i.e., it must
-   lock the old secret during the process of renewal). While the server
-   is sending Renewal requests and waiting responses, it ignores the
-   other server's Renewal requests.
-
-   Therefore, servers might fail to change secrets by means of their own
-   requests to others. After failure they will try to resend, but they
-   should wait for random delays by the next retries. If they get any
-   Renewal requests from others while they are waiting, their shared
-   keys may be refreshed, then they do not need to send any Renewal
-   requests now for themselves.
-
-
-6.  Key Name Considerations
-
-   Since both servers and clients have only to distinguish new secrets
-   and old ones, keys' names do not need to be specified strictly.
-   However, it is recommended that some serial number or key generation
-   time be added to the name and that the names of keys between the same
-   pair of hosts should have some common labels among their keys. For
-   example, suppose A.example.com. and B.example.com. share the key
-   ".A.example.com.B.example.com." such as
-   "10010.A.example.com.B.example.com.". After key renewal, they change
-   their secret and name into "10011.A.example.com.B.example.com."
-
-   Servers and clients must be able to use keys properly for each query.
-   Because TSIG secret keys themselves do not have any particular IDs to
-   be distinguished and would be identified by their names and
-   algorithm, it must be understood correctly what keys are refreshed.
-
-
-7.  Example Usage of Secret Key Renewal Mode
-
-   This is an example of Renewal mode usage where a Server,
-   server.example.com, and a Client, client.exmple.com have an initial
-   shared secret key named "00.client.example.com.server.example.com".
-
-     (1) The time values for key
-     "00.client.example.com.server.example.com" was set as follows:
-     Inception Time is at 1:00, Expiry Limit is at 21:00.
-
-     (2) At Server, renewal time has been set: Partial Revocation Time
-     is at 20:00.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 17]
-
-INTERNET-DRAFT                                              October 2004
-
-
-     (3) Suppose the present time is 19:55. If Client sends a query
-     signed with key "00.client.example.com.server.example.com" to ask
-     the IP address of "www.example.com", finally it will get a proper
-     answer from Server with valid TSIG (NOERROR).
-
-     (4) At 20:05. Client sends a query to ask the IP address of
-     "www2.example.com". It is signed with key
-     "00.client.example.com.server.example.com". Server returns an
-     answer for the IP address. However, server has begun retuning
-     PartialRevoke Error randomely. This answer includes valid TSIG MAC
-     signed with "00.client.example.com.server.example.com", and its
-     Error Code indicates PartialRevoke. Client understands that the
-     current key is partially revoked.
-
-     (5) At 20:06. Client sends a Renewal request to Server. This
-     request is signed with key
-     "00.client.example.com.server.example.com". It includes data such
-     as:
-
-      Question Section:
-         QNAME = 01.client.example.com. (Client can set this freely)
-         TYPE  = TKEY
-
-      Additional Section:
-         01.client.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (DH exchange for key renewal)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-      Additional Section also contains a KEY RR for DH and a TSIG RR.
-
-     (6) As soon as Server receives this request, it verifies TSIG. It
-     is signed with the partially revoked key
-     "00.client.example.com.server.example.com". and Server accepts the
-     request. It creates a new key by Diffie-Hellman calculation and
-     returns an answer which includes data such as:
-
-      Answer Section:
-         01.client.example.com.server.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (DH exchange for key renewal)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 18]
-
-INTERNET-DRAFT                                              October 2004
-
-
-     Answer Section also contains KEY RRs for DH.
-
-      Additional Section also contains a TSIG RR.
-     This response is signed with key
-     "00.client.example.com.server.example.com" without error.
-
-     At the same time, Server decides to set the Partial Revocation Time
-     of this new key "01.client.example.com.server.example.com." as next
-     day's 15:00.
-
-     (7) Client gets the response and checks TSIG MAC, and calculates
-     Diffie-Hellman. It will get a new key, and it has been named
-     "01.client.example.com.server.example.com" by Server.
-
-     (8) At 20:07. Client sends an Adoption request to Server. This
-     request is signed with the previous key
-     "00.client.example.com.server.example.com". It includes:
-
-      Question Section:
-         QNAME = 01.client.example.com.server.example.com.
-         TYPE  = TKEY
-
-      Additional Section:
-         01.client.example.com.server.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (key adoption)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-     Additional Section also contains a TSIG RR.
-
-     (9) Server verifies the query's TSIG. It is signed with the
-     previous key and authenticated. It returns a response whose TKEY RR
-     is the same as the request's one. The response is signed with key
-     "00.client.example.com.server.example.com.". As soon as the
-     response is sent, Server revokes and removes the previous key. At
-     the same time, key "01.client.example.com.server.example.com." is
-     validated.
-
-     (10) Client acknowledges the success of Adoption by receiving the
-     response.  Then, it retries to send an original question about
-     "www2.example.com". It is signed with the adopted key
-     "01.client.example.com.server.example.com", so Server authenticates
-     it and returns an answer.
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 19]
-
-INTERNET-DRAFT                                              October 2004
-
-
-     (11) This key is used until next day's 15:00. After that, it will
-     be partially revoked again.
-
-
-8.  Security Considerations
-
-   This document considers about how to refresh shared secret. Secret
-   changed by this method is used at servers in support of TSIG
-   [RFC2845].
-
-   [RFC2104] says that current attacks to HMAC do not indicate a
-   specific recommended frequency for key changes but periodic key
-   refreshment is a fundamental security practice that helps against
-   potential weaknesses of the function and keys, and limits the damage
-   of an exposed key. TKEY Secret Key Renewal provides the method of
-   periodical key refreshment.
-
-   In TKEY Secret Key Renewal, clients need to send two requests
-   (Renewal and Adoption) and spend time to finish their key renewal
-   processes. Thus the usage period of secrets should be considered
-   carefully based on both TKEY processing performance and security.
-
-   This document specifies the procedure of periodical key renewal, but
-   actually there is possibility for servers to have no choice other
-   than revoking their secret keys immediately especially when the keys
-   are found to be compromised by attackers. This is called "Emergency
-   Compulsory Revocation". For example, suppose the original Expiry
-   Limit was set at 21:00, Partial Revocation Time at 20:00 and
-   Inception Time at 1:00.  if at 11:00 the key is found to be
-   compromised, the server sets Expiry Limit forcibly to be 11:00 or
-   before it.
-
-   Consequently, once Compulsory Revocation (See section 4.) is carried
-   out, normal renewal process described in this document cannot be done
-   any more as far as the key is concerned. However, after such
-   accidents happened, the two hosts are able to establish secret keys
-   and begin renewal procedure only if they have other (non-compromised)
-   shared TSIG keys or safe SIG(0) keys for the authentication of
-   initial secret establishment such as Diffie-Hellman Exchanged Keying.
-
-
-9.  IANA Considerations
-
-   IANA needs to allocate a value for "DH exchange for key renewal",
-   "server assignment for key renewal", "resolver assignment for key
-   renewal" and "key adoption" in the mode filed of TKEY. It also needs
-   to allocate a value for "PartialRevoke" from the extended RCODE
-   space.
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 20]
-
-INTERNET-DRAFT                                              October 2004
-
-
-10.  Acknowledgements
-
-   The authors would like to thank Olafur Gudmundsson, whose helpful
-   input and comments contributed greatly to this document.
-
-
-11.  References
-
-11.1.  Normative References
-
-[RFC2119]
-     Bradner, S., "Key words for use in RFCs to Indicate Requirement
-     Levels", RFC 2119, March 1997.
-
-[RFC2539]
-     D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
-     System (DNS)", RFC 2539, March 1999.
-
-[RFC2845]
-     Vixie, P., Gudmundsson, O., Eastlake, D. and B.  Wellington,
-     "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
-     May 2000.
-
-[RFC2930]
-     D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
-     RFC 2930, September 2000.
-
-[RFC2931]
-     D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
-     )", RFC 2931, September 2000.
-
-11.2.  Informative References
-
-[RFC2104]
-     H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
-     Authentication", RFC2104, February 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 21]
-
-INTERNET-DRAFT                                              October 2004
-
-
-Authors' Addresses
-
-   Yuji Kamite
-   NTT Communications Corporation
-   Tokyo Opera City Tower
-   3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
-   163-1421, Japan
-   EMail: y.kamite@ntt.com
-
-
-   Masaya Nakayama
-   Information Technology Center, The University of Tokyo
-   2-11-16 Yayoi, Bunkyo-ku, Tokyo
-   113-8658, Japan
-   EMail: nakayama@nc.u-tokyo.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 22]
-
-INTERNET-DRAFT                                              October 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 23]
-
-
-
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
deleted file mode 100644
index a5988264e407..000000000000
--- a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
+++ /dev/null
@@ -1,1501 +0,0 @@
-Network Working Group                                           J. Ihren
-Internet-Draft                                             Autonomica AB
-Expires: April 18, 2005                                       O. Kolkman
-                                                                RIPE NCC
-                                                              B. Manning
-                                                                  EP.net
-                                                        October 18, 2004
-
-
-
-  An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
-                         DNSSEC Trust Anchors.
-               draft-ietf-dnsext-trustupdate-threshold-00
-
-
-Status of this Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on April 18, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   The DNS Security Extensions (DNSSEC) works by validating so called
-   chains of authority.  The start of these chains of authority are
-   usually public keys that are anchored in the DNS clients.  These keys
-   are known as the so called trust anchors.
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 1]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   This memo describes a method how these client trust anchors can be
-   replaced using the DNS validation and querying mechanisms (in-band)
-   when the key pairs used for signing by zone owner are rolled.
-
-
-   This memo also describes a method to establish the validity of trust
-   anchors for initial configuration, or priming, using out of band
-   mechanisms.
-
-
-Table of Contents
-
-
-   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1   Key Signing Keys, Zone Signing Keys and Secure Entry
-           Points . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Introduction and Background  . . . . . . . . . . . . . . . . .  5
-     2.1   Dangers of Stale Trust Anchors . . . . . . . . . . . . . .  5
-   3.  Threshold-based Trust Anchor Rollover  . . . . . . . . . . . .  7
-     3.1   The Rollover . . . . . . . . . . . . . . . . . . . . . . .  7
-     3.2   Threshold-based Trust Update . . . . . . . . . . . . . . .  8
-     3.3   Possible Trust Update States . . . . . . . . . . . . . . .  9
-     3.4   Implementation notes . . . . . . . . . . . . . . . . . . . 10
-     3.5   Possible transactions  . . . . . . . . . . . . . . . . . . 11
-       3.5.1   Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
-       3.5.2   Addition of a new DNSKEY (no removal)  . . . . . . . . 12
-       3.5.3   Removal of old DNSKEY (no addition)  . . . . . . . . . 12
-       3.5.4   Multiple DNSKEYs replaced  . . . . . . . . . . . . . . 12
-     3.6   Removal of trust anchors for a trust point . . . . . . . . 12
-     3.7   No need for resolver-side overlap of old and new keys  . . 13
-   4.  Bootstrapping automatic rollovers  . . . . . . . . . . . . . . 14
-     4.1   Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
-       4.1.1   Bootstrapping trust anchors using a priming key  . . . 14
-       4.1.2   Distribution of priming keys . . . . . . . . . . . . . 15
-   5.  The Threshold Rollover Mechanism vs Priming  . . . . . . . . . 16
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
-     6.1   Threshold-based Trust Update Security Considerations . . . 17
-     6.2   Priming Key Security Considerations  . . . . . . . . . . . 17
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 20
-   8.2   Informative References . . . . . . . . . . . . . . . . . . . 20
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
-   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
-   B.  Document History . . . . . . . . . . . . . . . . . . . . . . . 23
-     B.1   prior to version 00  . . . . . . . . . . . . . . . . . . . 23
-     B.2   version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23
-       Intellectual Property and Copyright Statements . . . . . . . . 24
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 2]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-1.  Terminology
-
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in
-   RFC2119 [1].
-
-
-   The term "zone" refers to the unit of administrative control in the
-   Domain Name System.  In this document "name server" denotes a DNS
-   name server that is authoritative (i.e.  knows all there is to know)
-   for a DNS zone.  A "zone owner" is the entity responsible for signing
-   and publishing a zone on a name server.  The terms "authentication
-   chain", "bogus", "trust anchors" and "Island of Security" are defined
-   in [4].  Throughout this document we use the term "resolver" to mean
-   "Validating Stub Resolvers" as defined in [4].
-
-
-   We use the term "security apex" as the zone for which a trust anchor
-   has been configured (by validating clients) and which is therefore,
-   by definition, at the root of an island of security.  The
-   configuration of trust anchors is a client side issue.  Therefore a
-   zone owner may not always know if their zone has become a security
-   apex.
-
-
-   A "stale anchor" is a trust anchor (a public key) that relates to a
-   key that is not used for signing.  Since trust anchors indicate that
-   a zone is supposed to be secure a validator will mark the all data in
-   an island of security as bogus when all trust anchors become stale.
-
-
-   It is assumed that the reader is familiar with public key
-   cryptography concepts [REF: Schneier Applied Cryptography] and is
-   able to distinguish between the private and public parts of a key
-   based on the context in which we use the term "key".  If there is a
-   possible ambiguity we will explicitly mention if a private or a
-   public part of a key is used.
-
-
-   The term "administrator" is used loosely throughout the text.  In
-   some cases an administrator is meant to be a person, in other cases
-   the administrator may be a process that has been delegated certain
-   responsibilities.
-
-
-1.1  Key Signing Keys, Zone Signing Keys and Secure Entry Points
-
-
-   Although the DNSSEC protocol does not make a distinction between
-   different keys the operational practice is that a distinction is made
-   between zone signing keys and key signing keys.  A key signing key is
-   used to exclusively sign the DNSKEY Resource Record (RR) set at the
-   apex of a zone and the zone signing keys sign all the data in the
-   zone (including the DNSKEY RRset at the apex).
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 3]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   Keys that are intended to be used as the start of the authentication
-   chain for a particular zone, either because they are pointed to by a
-   parental DS RR or because they are configured as a trust anchor, are
-   called Secure Entry Point (SEP) keys.  In practice these SEP keys
-   will be key signing keys.
-
-
-   In order for the mechanism described herein to work the keys that are
-   intended to be used as secure entry points MUST have the SEP [2] flag
-   set.  In the examples it is assumed that keys with the SEP flag set
-   are used as key signing keys and thus exclusively sign the DNSKEY
-   RRset published at the apex of the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 4]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-2.  Introduction and Background
-
-
-   When DNSSEC signatures are validated the resolver constructs a chain
-   of authority from a pre-configured trust anchor to the DNSKEY
-   Resource Record (RR), which contains the public key that validates
-   the signature stored in an RRSIG RR.  DNSSEC is designed so that the
-   administrator of a resolver can validate data in multiple islands of
-   security by configuring multiple trust anchors.
-
-
-   It is expected that resolvers will have more than one trust anchor
-   configured.  Although there is no deployment experience it is not
-   unreasonable to expect resolvers to be configured with a number of
-   trust anchors that varies between order 1 and order 1000.  Because
-   zone owners are expected to roll their keys, trust anchors will have
-   to be maintained (in the resolver end) in order not to become stale.
-
-
-   Since there is no global key maintenance policy for zone owners and
-   there are no mechanisms in the DNS to signal the key maintenance
-   policy it may be very hard for resolvers administrators to keep their
-   set of trust anchors up to date.  For instance, if there is only one
-   trust anchor configured and the key maintenance policy is clearly
-   published, through some out of band trusted channel, then a resolver
-   administrator can probably keep track of key rollovers and update the
-   trust anchor manually.  However, with an increasing number of trust
-   anchors all rolled according to individual policies that are all
-   published through different channels this soon becomes an
-   unmanageable problem.
-
-
-2.1  Dangers of Stale Trust Anchors
-
-
-   Whenever a SEP key at a security apex is rolled there exists a danger
-   that "stale anchors" are created.  A stale anchor is a trust anchor
-   (i.e.  a public key configured in a validating resolver) that relates
-   to a private key that is no longer used for signing.
-
-
-   The problem with a stale anchors is that they will (from the
-   validating resolvers point of view) prove data to be false even
-   though it is actually correct.  This is because the data is either
-   signed by a new key or is no longer signed and the resolver expects
-   data to be signed by the old (now stale) key.
-
-
-   This situation is arguably worse than not having a trusted key
-   configured for the secure entry point, since with a stale key no
-   lookup is typically possible (presuming that the default
-   configuration of a validating recursive nameserver is to not give out
-   data that is signed but failed to verify.
-
-
-   The danger of making configured trust anchors become stale anchors
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 5]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   may be a reason for zone owners not to roll their keys.  If a
-   resolver is configured with many trust anchors that need manual
-   maintenance it may be easy to not notice a key rollover at a security
-   apex, resulting in a stale anchor.
-
-
-   In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
-   track key rollovers and modify the configured trust anchors
-   accordingly.  The mechanism is stateless and does not need protocol
-   extensions.  The proposed design is that this mechanism is
-   implemented as a "trust updating machine" that is run entirely
-   separate from the validating resolver except that the trust updater
-   will have influence over the trust anchors used by the latter.
-
-
-   In Section 4 we describe a method [Editors note: for now only the
-   frame work and a set of requirements] to install trust anchors.  This
-   method can be used at first configuration or when the trust anchors
-   became stale (typically due to a failure to track several rollover
-   events).
-
-
-   The choice for which domains trust anchors are to be configured is a
-   local policy issue.  So is the choice which trust anchors has
-   prevalence if there are multiple chains of trust to a given piece of
-   DNS data (e.g.  when a parent zone and its child both have trust
-   anchors configured).  Both issues are out of the scope of this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 6]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-3.  Threshold-based Trust Anchor Rollover
-
-
-3.1  The Rollover
-
-
-   When a key pair is replaced all signatures (in DNSSEC these are the
-   RRSIG records) created with the old key will be replaced by new
-   signatures created by the new key.  Access to the new public key is
-   needed to verify these signatures.
-
-
-   Since zone signing keys are in "the middle" of a chain of authority
-   they can be verified using the signature made by a key signing key.
-   Rollover of zone signing keys is therefore transparent to validators
-   and requires no action in the validator end.
-
-
-   But if a key signing key is rolled a resolver can determine its
-   authenticity by either following the authorization chain from the
-   parents DS record, an out-of-DNS authentication mechanism or by
-   relying on other trust anchors known for the zone in which the key is
-   rolled.
-
-
-   The threshold trust anchor rollover mechanism (or trust update),
-   described below, is based on using existing trust anchors to verify a
-   subset of the available signatures.  This is then used as the basis
-   for a decision to accept the new keys as valid trust anchors.
-
-
-   Our example pseudo zone below contains a number of key signing keys
-   numbered 1 through Y and two zone signing keys A and B.  During a key
-   rollover key 2 is replaced by key Y+1.  The zone content changes
-   from:
-
-
-          example.com.  DNSKEY key1
-          example.com.  DNSKEY key2
-          example.com.  DNSKEY key3
-          ...
-          example.com.  DNSKEY keyY
-
-
-          example.com.  DNSKEY keyA
-          example.com.  DNSKEY keyB
-
-
-          example.com.  RRSIG DNSKEY ... (key1)
-          example.com.  RRSIG DNSKEY ... (key2)
-          example.com.  RRSIG DNSKEY ... (key3)
-          ...
-          example.com.  RRSIG DNSKEY ... (keyY)
-          example.com.  RRSIG DNSKEY ... (keyA)
-          example.com.  RRSIG DNSKEY ... (keyB)
-
-
-    to:
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 7]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-          example.com.  DNSKEY key1
-          example.com.  DNSKEY key3
-          ...
-          example.com.  DNSKEY keyY
-          example.com.  DNSKEY keyY+1
-
-
-          example.com.  RRSIG DNSKEY ... (key1)
-          example.com.  RRSIG DNSKEY ... (key3)
-          ...
-          example.com.  RRSIG DNSKEY ... (keyY)
-          example.com.  RRSIG DNSKEY ... (keyY+1)
-          example.com.  RRSIG DNSKEY ... (keyA)
-          example.com.  RRSIG DNSKEY ... (keyB)
-
-
-   When the rollover becomes visible to the verifying stub resolver it
-   will be able to verify the RRSIGs associated with key1, key3 ...
-   keyY.  There will be no RRSIG by key2 and the RRSIG by keyY+1 will
-   not be used for validation, since that key is previously unknown and
-   therefore not trusted.
-
-
-   Note that this example is simplified.  Because of operational
-   considerations described in [5] having a period during which the two
-   key signing keys are both available is necessary.
-
-
-3.2  Threshold-based Trust Update
-
-
-   The threshold-based trust update algorithm applies as follows.  If
-   for a particular secure entry point
-   o  if the DNSKEY RRset in the zone has been replaced by a more recent
-      one (as determined by comparing the RRSIG inception dates)
-   and
-   o  if at least M configured trust anchors directly verify the related
-      RRSIGs over the new DNSKEY RRset
-   and
-   o  the number of configured trust anchors that verify the related
-      RRSIGs over the new DNSKEY RRset exceed a locally defined minimum
-      number that should be greater than one
-   then all the trust anchors for the particular secure entry point are
-   replaced by the set of keys from the zones DNSKEY RRset that have the
-   SEP flag set.
-
-
-   The choices for the rollover acceptance policy parameter M is left to
-   the administrator of the resolver.  To be certain that a rollover is
-   accepted up by resolvers using this mechanism zone owners should roll
-   as few SEP keys at a time as possible (preferably just one).  That
-   way they comply to the most strict rollover acceptance policy of
-   M=N-1.
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 8]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   The value of M has an upper bound, limited by the number of of SEP
-   keys a zone owner publishes (i.e.  N).  But there is also a lower
-   bound, since it will not be safe to base the trust in too few
-   signatures.  The corner case is M=1 when any validating RRSIG will be
-   sufficient for a complete replacement of the trust anchors for that
-   secure entry point.  This is not a recommended configuration, since
-   that will allow an attacker to initiate rollover of the trust anchors
-   himself given access to just one compromised key.  Hence M should in
-   be strictly larger than 1 as shown by the third requirement above.
-
-
-   If the rollover acceptance policy is M=1 then the result for the
-   rollover in our example above should be that the local database of
-   trust anchors is updated by removing key "key2" from and adding key
-   "keyY+1" to the key store.
-
-
-3.3  Possible Trust Update States
-
-
-   We define five states for trust anchor configuration at the client
-   side.
-   PRIMING: There are no trust anchors configured.  There may be priming
-      keys available for initial priming of trust anchors.
-   IN-SYNC: The set of trust anchors configured exactly matches the set
-      of SEP keys used by the zone owner to sign the zone.
-   OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
-      set of SEP keys used by the zone owner to sign the zone but there
-      are enough SEP key in use by the zone owner that is also in the
-      trust anchor configuration.
-   UNSYNCABLE: There is not enough overlap between the configured trust
-      anchors and the set of SEP keys used to sign the zone for the new
-      set to be accepted by the validator (i.e.  the number of
-      signatures that verify is not sufficient).
-   STALE: There is no overlap between the configured trust anchors and
-      the set of SEP keys used to sign the zone.  Here validation of
-      data is no longer possible and hence we are in a situation where
-      the trust anchors are stale.
-
-
-   Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of
-   the automatic trust update mechanism.  The PRIMING state is where a
-   validator is located before acquiring an up-to-date set of trust
-   anchors.  The transition from PRIMING to IN-SYNC is manual (see
-   Section 4 below).
-
-
-   Example: assume a secure entry point with four SEP keys and a
-   validator with the policy that it will accept any update to the set
-   of trust anchors as long as no more than two signatures fail to
-   validate (i.e.  M >= N-2) and at least two signature does validate
-   (i.e.  M >= 2).  In this case the rollover of a single key will move
-   the validator from IN-SYNC to OUT-OF-SYNC.  When the trust update
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 9]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   state machine updates the trust anchors it returns to state IN-SYNC.
-
-
-   If if for some reason it fails to update the trust anchors then the
-   next rollover (of a different key) will move the validator from
-   OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys
-   that are configured as trust anchors and that is sufficient to accpt
-   an automatic update of the trust anchors.
-
-
-   The UNSYNCABLE state is where a validator is located if it for some
-   reason fails to incorporate enough updates to the trust anchors to be
-   able to accept new updates according to its local policy.  In this
-   example (i.e.  with the policy specified above) this will either be
-   because M < N-2 or M < 2, which does not suffice to authenticate a
-   successful update of trust anchors.
-
-
-   Continuing with the previous example where two of the four SEP keys
-   have already rolled, but the validator has failed to update the set
-   of trust anchors.  When the third key rolls over there will only be
-   one trust anchor left that can do successful validation.  This is not
-   sufficient to enable automatic update of the trust anchors, hence the
-   new state is UNSYNCABLE.  Note, however, that the remaining
-   up-to-date trust anchor is still enough to do successful validation
-   so the validator is still "working" from a DNSSEC point of view.
-
-
-   The STALE state, finally, is where a validator ends up when it has
-   zero remaining current trust anchors.  This is a dangerous state,
-   since the stale trust anchors will cause all validation to fail.  The
-   escape is to remove the stale trust anchors and thereby revert to the
-   PRIMING state.
-
-
-3.4  Implementation notes
-
-
-   The DNSSEC protocol specification ordains that a DNSKEY to which a DS
-   record points should be self-signed.  Since the keys that serve as
-   trust anchors and the keys that are pointed to by DS records serve
-   the same purpose, they are both secure entry points, we RECOMMEND
-   that zone owners who want to facilitate the automated rollover scheme
-   documented herein self-sign DNSKEYs with the SEP bit set and that
-   implementation check that DNSKEYs with the SEP bit set are
-   self-signed.
-
-
-   In order to maintain a uniform way of determining that a keyset in
-   the zone has been replaced by a more recent set the automatic trust
-   update machine SHOULD only accept new DNSKEY RRsets if the
-   accompanying RRSIGs show a more recent inception date than the
-   present set of trust anchors.  This is also needed as a safe guard
-   against possible replay attacks where old updates are replayed
-   "backwards" (i.e.  one change at a time, but going in the wrong
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 10]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   direction, thereby luring the validator into the UNSYNCABLE and
-   finally STALE states).
-
-
-   In order to be resilient against failures the implementation should
-   collect the DNSKEY RRsets from (other) authoritative servers if
-   verification of the self signatures fails.
-
-
-   The threshold-based trust update mechanism SHOULD only be applied to
-   algorithms, as represented in the algorithm field in the DNSKEY/RRSIG
-   [3], that the resolver is aware of.  In other words the SEP keys of
-   unknown algorithms should not be used when counting the number of
-   available signatures (the N constant) and the SEP keys of unknown
-   algorithm should not be entered as trust anchors.
-
-
-   When in state UNSYNCABLE or STALE manual intervention will be needed
-   to return to the IN-SYNC state.  These states should be flagged.  The
-   most appropriate action is human audit possibly followed by
-   re-priming (Section 4) the keyset (i.e.  manual transfer to the
-   PRIMING state through removal of the configured trust anchors).
-
-
-   An implementation should regularly probe the the authoritative
-   nameservers for new keys.  Since there is no mechanism to publish
-   rollover frequencies this document RECOMMENDS zone owners not to roll
-   their key signing keys more often than once per month and resolver
-   administrators to probe for key rollsovers (and apply the threshold
-   criterion for acceptance of trust update) not less often than once
-   per month.  If the rollover frequency is higher than the probing
-   frequency then trust anchors may become stale.  The exact relation
-   between the frequencies depends on the number of SEP keys rolled by
-   the zone owner and the value M configured by the resolver
-   administrator.
-
-
-   In all the cases below a transaction where the threshold criterion is
-   not satisfied should be considered bad (i.e.  possibly spoofed or
-   otherwise corrupted data).  The most appropriate action is human
-   audit.
-
-
-   There is one case where a "bad" state may be escaped from in an
-   automated fashion.  This is when entering the STALE state where all
-   DNSSEC validation starts to fail.  If this happens it is concievable
-   that it is better to completely discard the stale trust anchors
-   (thereby reverting to the PRIMING state where validation is not
-   possible).  A local policy that automates removal of stale trust
-   anchors is therefore suggested.
-
-
-3.5  Possible transactions
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 11]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-3.5.1  Single DNSKEY replaced
-
-
-   This is probably the most typical transaction on the zone owners
-   part.  The result should be that if the threshold criterion is
-   satisfied then the key store is updated by removal of the old trust
-   anchor and addition of the new key as a new trust anchor.  Note that
-   if the DNSKEY RRset contains exactly M keys replacement of keys is
-   not possible, i.e.  for automatic rollover to work M must be stricly
-   less than N.
-
-
-3.5.2  Addition of a new DNSKEY (no removal)
-
-
-   If the threshold criterion is satisfied then the new key is added as
-   a configured trust anchor.  Not more than N-M keys can be added at
-   once, since otherwise the algorithm will fail.
-
-
-3.5.3  Removal of old DNSKEY (no addition)
-
-
-   If the threshold criterion is satisfied then the old key is removed
-   from being a configured trust anchor.  Note that it is not possible
-   to reduce the size of the DNSKEY RRset to a size smaller than the
-   minimum required value for M.
-
-
-3.5.4  Multiple DNSKEYs replaced
-
-
-   Arguably it is not a good idea for the zone administrator to replace
-   several keys at the same time, but from the resolver point of view
-   this is exactly what will happen if the validating resolver for some
-   reason failed to notice a previous rollover event.
-
-
-   Not more than N-M keys can be replaced at one time or the threshold
-   criterion will not be satisfied.  Or, expressed another way: as long
-   as the number of changed keys is less than or equal to N-M the
-   validator is in state OUT-OF-SYNC.  When the number of changed keys
-   becomes greater than N-M the state changes to UNSYNCABLE and manual
-   action is needed.
-
-
-3.6  Removal of trust anchors for a trust point
-
-
-   If the parent of a secure entry point gets signed and it's trusted
-   keys get configured in the key store of the validating resolver then
-   the configured trust anchors for the child should be removed entirely
-   unless explicitly configured (in the utility configuration) to be an
-   exception.
-
-
-   The reason for such a configuration would be that the resolver has a
-   local policy that requires maintenance of trusted keys further down
-   the tree hierarchy than strictly needed from the point of view.
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 12]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   The default action when the parent zone changes from unsigned to
-   signed should be to remove the configured trust anchors for the
-   child.  This form of "garbage collect" will ensure that the automatic
-   rollover machinery scales as DNSSEC deployment progresses.
-
-
-3.7  No need for resolver-side overlap of old and new keys
-
-
-   It is worth pointing out that there is no need for the resolver to
-   keep state about old keys versus new keys, beyond the requirement of
-   tracking signature inception time for the covering RRSIGs as
-   described in Section 3.4.
-
-
-   From the resolver point of view there are only trusted and not
-   trusted keys.  The reason is that the zone owner needs to do proper
-   maintenance of RRSIGs regardless of the resolver rollover mechanism
-   and hence must ensure that no key rolled out out the DNSKEY set until
-   there cannot be any RRSIGs created by this key still legally cached.
-
-
-   Hence the rollover mechanism is entirely stateless with regard to the
-   keys involved: as soon as the resolver (or in this case the rollover
-   tracking utility) detects a change in the DNSKEY RRset (i.e.  it is
-   now in the state OUT-OF-SYNC) with a sufficient number of matching
-   RRSIGs the configured trust anchors are immediately updated (and
-   thereby the machine return to state IN-SYNC).  I.e.  the rollover
-   machine changes states (mostly oscillating between IN-SYNC and
-   OUT-OF-SYNC), but the status of the DNSSEC keys is stateless.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 13]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-4.  Bootstrapping automatic rollovers
-
-
-   It is expected that with the ability to automatically roll trust
-   anchors at trust points will follow a diminished unwillingness to
-   roll these keys, since the risks associated with stale keys are
-   minimized.
-
-
-   The problem of "priming" the trust anchors, or bringing them into
-   sync (which could happen if a resolver is off line for a long period
-   in which a set of SEP keys in a zone 'evolve' away from its trust
-   anchor configuration) remains.
-
-
-   For (re)priming we can rely on out of band technology and we propose
-   the following framework.
-
-
-4.1  Priming Keys
-
-
-   If all the trust anchors roll somewhat frequently (on the order of
-   months or at most about a year) then it will not be possible to
-   design a device, or a software distribution that includes trust
-   anchors, that after being manufactured is put on a shelf for several
-   key rollover periods before being brought into use (since no trust
-   anchors that were known at the time of manufacture remain active).
-
-
-   To alleviate this we propose the concept of "priming keys".  Priming
-   keys are ordinary DNSSEC Key Signing Keys with the characteristic
-   that
-   o  The private part of a priming key signs the DNSKEY RRset at the
-      security apex, i.e.  at least one RRSIG DNSKEY is created by a
-      priming key rather than by an "ordinary" trust anchor
-   o  the public parts of priming keys are not included in the DNSKEY
-      RRset.  Instead the public parts of priming keys are only
-      available out-of-band.
-   o  The public parts of the priming keys have a validity period.
-      Within this period they can be used to obtain trust anchors.
-   o  The priming key pairs are long lived (relative to the key rollover
-      period.)
-
-
-4.1.1  Bootstrapping trust anchors using a priming key
-
-
-   To install the trust anchors for a particular security apex an
-   administrator of a validating resolver will need to:
-   o  query for the DNSKEY RRset of the zone at the security apex;
-   o  verify the self signatures of all DNSKEYs in the RRset;
-   o  verify the signature of the RRSIG made with a priming key --
-      verification using one of the public priming keys that is valid at
-      that moment is sufficient;
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 14]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   o  create the trust anchors by extracting the DNSKEY RRs with the SEP
-      flag set.
-   The SEP keys with algorithms unknown to the validating resolver
-   SHOULD be ignored during the creation of the trust anchors.
-
-
-4.1.2  Distribution of priming keys
-
-
-   The public parts of the priming keys SHOULD be distributed
-   exclusively through out-of-DNS mechanisms.  The requirements for a
-   distribution mechanism are:
-   o  it can carry the "validity" period for the priming keys;
-   o  it can carry the self-signature of the priming keys;
-   o  and it allows for verification using trust relations outside the
-      DNS.
-   A distribution mechanism would benefit from:
-   o  the availability of revocation lists;
-   o  the ability of carrying zone owners policy information such as
-      recommended values for "M" and "N" and a rollover frequency;
-   o  and the technology on which is based is readily available.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 15]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-5.  The Threshold Rollover Mechanism vs Priming
-
-
-   There is overlap between the threshold-based trust updater and the
-   Priming method.  One could exclusively use the Priming method for
-   maintaining the trust anchors.  However the priming method probably
-   relies on "non-DNS' technology and may therefore not be available for
-   all devices that have a resolver.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 16]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-6.  Security Considerations
-
-
-6.1  Threshold-based Trust Update Security Considerations
-
-
-   A clear issue for resolvers will be how to ensure that they track all
-   rollover events for the zones they have configure trust anchors for.
-   Because of temporary outages validating resolvers may have missed a
-   rollover of a KSK.  The parameters that determine the robustness
-   against failures are: the length of the period between rollovers
-   during which the KSK set is stable and validating resolvers can
-   actually notice the change; the number of available KSKs (i.e.  N)
-   and the number of signatures that may fail to validate (i.e.  N-M).
-
-
-   With a large N (i.e.  many KSKs) and a small value of M this
-   operation becomes more robust since losing one key, for whatever
-   reason, will not be crucial.  Unfortunately the choice for the number
-   of KSKs is a local policy issue for the zone owner while the choice
-   for the parameter M is a local policy issue for the resolver
-   administrator.
-
-
-   Higher values of M increase the resilience against attacks somewhat;
-   more signatures need to verify for a rollover to be approved.  On the
-   other hand the number of rollover events that may pass unnoticed
-   before the resolver reaches the UNSYNCABLE state goes down.
-
-
-   The threshold-based trust update intentionally does not provide a
-   revocation mechanism.  In the case that a sufficient number of
-   private keys of a zone owner are simultaneously compromised the the
-   attacker may use these private keys to roll the trust anchors of (a
-   subset of) the resolvers.  This is obviously a bad situation but it
-   is not different from most other public keys systems.
-
-
-   However, it is important to point out that since any reasonable trust
-   anchor rollover policy (in validating resolvers) will require more
-   than one RRSIG to validate this proposal does provide security
-   concious zone administrators with the option of not storing the
-   individual private keys in the same location and thereby decreasing
-   the likelihood of simultaneous compromise.
-
-
-6.2  Priming Key Security Considerations
-
-
-   Since priming keys are not included in the DNSKEY RR set they are
-   less sensitive to packet size constraints and can be chosen
-   relatively large.  The private parts are only needed to sign the
-   DNSKEY RR set during the validity period of the particular priming
-   key pair.  Note that the private part of the priming key is used each
-   time when a DNSKEY RRset has to be resigned.  In practice there is
-   therefore little difference between the usage pattern of the private
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 17]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   part of key signing keys and priming keys.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 18]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-7.  IANA Considerations
-
-
-   NONE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 19]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-8.  References
-
-
-8.1  Normative References
-
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
-        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
-        RFC 3757, May 2004.
-
-
-   [3]  Arends, R., "Resource Records for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-records-10 (work in progress),
-        September 2004.
-
-
-8.2  Informative References
-
-
-   [4]  Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
-        "DNS Security Introduction and Requirements",
-        draft-ietf-dnsext-dnssec-intro-12 (work in progress), September
-        2004.
-
-
-   [5]  Kolkman, O., "DNSSEC Operational Practices",
-        draft-ietf-dnsop-dnssec-operational-practices-01 (work in
-        progress), May 2004.
-
-
-   [6]  Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and CRL Profile", RFC
-        2459, January 1999.
-
-
-
-Authors' Addresses
-
-
-   Johan Ihren
-   Autonomica AB
-   Bellmansgatan 30
-   Stockholm  SE-118 47
-   Sweden
-
-
-   EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 20]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   Olaf M. Kolkman
-   RIPE NCC
-   Singel 256
-   Amsterdam  1016 AB
-   NL
-
-
-   Phone: +31 20 535 4444
-   EMail: olaf@ripe.net
-   URI:   http://www.ripe.net/
-
-
-
-   Bill Manning
-   EP.net
-   Marina del Rey, CA  90295
-   USA
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 21]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-Appendix A.  Acknowledgments
-
-
-   The present design for in-band automatic rollovers of DNSSEC trust
-   anchors is the result of many conversations and it is no longer
-   possible to remember exactly who contributed what.
-
-
-   In addition we've also had appreciated help from (in no particular
-   order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
-   Larson and Mark Kosters.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 22]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-Appendix B.  Document History
-
-
-   This appendix will be removed if and when the document is submitted
-   to the RFC editor.
-
-
-   The version you are reading is tagged as $Revision: 1.1.230.1 $.
-
-
-   Text between square brackets, other than references, are editorial
-   comments and will be removed.
-
-
-B.1  prior to version 00
-
-
-   This draft was initially published as a personal submission under the
-   name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.
-
-
-   Kolkman documented the ideas provided by Ihren and Manning.  In the
-   process of documenting (and prototyping) Kolkman changed some of the
-   details of the M-N algorithms working.  Ihren did not have a chance
-   to review the draft before Kolkman posted;
-
-
-   Kolkman takes responsibilities for omissions, fuzzy definitions and
-   mistakes.
-
-
-B.2  version 00
-   o  The name of the draft was changed as a result of the draft being
-      adopted as a working group document.
-   o  A small section on the concept of stale trust anchors was added.
-   o  The different possible states are more clearly defined, including
-      examples of transitions between states.
-   o  The terminology is changed throughout the document.  The old term
-      "M-N" is replaced by "threshold" (more or less).  Also the
-      interpretation of the constants M and N is significantly
-      simplified to bring the usage more in line with "standard"
-      threshold terminlogy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 23]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 24] 
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
deleted file mode 100644
index 7cb9063dc279..000000000000
--- a/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-
-Network Working Group                                         M. StJohns
-Internet-Draft                                             Nominum, Inc.
-Expires: July 14, 2006                                  January 10, 2006
-
-
-               Automated Updates of DNSSEC Trust Anchors
-                draft-ietf-dnsext-trustupdate-timers-02
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 14, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a means for automated, authenticated and
-   authorized updating of DNSSEC "trust anchors".  The method provides
-   protection against single key compromise of a key in the trust point
-   key set.  Based on the trust established by the presence of a current
-   anchor, other anchors may be added at the same place in the
-   hierarchy, and, ultimately, supplant the existing anchor.
-
-   This mechanism, if adopted, will require changes to resolver
-   management behavior (but not resolver resolution behavior), and the
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 1]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   addition of a single flag bit to the DNSKEY record.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Compliance Nomenclature  . . . . . . . . . . . . . . . . .  3
-     1.2.  Changes since -00  . . . . . . . . . . . . . . . . . . . .  3
-   2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  4
-     2.1.  Revocation . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  Add Hold-Down  . . . . . . . . . . . . . . . . . . . . . .  5
-     2.3.  Remove Hold-down . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  Active Refresh . . . . . . . . . . . . . . . . . . . . . .  6
-     2.5.  Resolver Parameters  . . . . . . . . . . . . . . . . . . .  6
-       2.5.1.  Add Hold-Down Time . . . . . . . . . . . . . . . . . .  6
-       2.5.2.  Remove Hold-Down Time  . . . . . . . . . . . . . . . .  6
-       2.5.3.  Minimum Trust Anchors per Trust Point  . . . . . . . .  6
-   3.  Changes to DNSKEY RDATA Wire Format  . . . . . . . . . . . . .  6
-   4.  State Table  . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     4.1.  Events . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     4.2.  States . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     4.3.  Trust Point Deletion . . . . . . . . . . . . . . . . . . .  8
-   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     5.1.  Adding A Trust Anchor  . . . . . . . . . . . . . . . . . .  9
-     5.2.  Deleting a Trust Anchor  . . . . . . . . . . . . . . . . .  9
-     5.3.  Key Roll-Over  . . . . . . . . . . . . . . . . . . . . . .  9
-     5.4.  Active Key Compromised . . . . . . . . . . . . . . . . . .  9
-     5.5.  Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-     7.1.  Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
-     7.2.  Multiple Key Compromise  . . . . . . . . . . . . . . . . . 10
-     7.3.  Dynamic Updates  . . . . . . . . . . . . . . . . . . . . . 11
-   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
-   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 2]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-1.  Introduction
-
-   As part of the reality of fielding DNSSEC (Domain Name System
-   Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
-   community has come to the realization that there will not be one
-   signed name space, but rather islands of signed name space each
-   originating from specific points (i.e. 'trust points') in the DNS
-   tree.  Each of those islands will be identified by the trust point
-   name, and validated by at least one associated public key.  For the
-   purpose of this document we'll call the association of that name and
-   a particular key a 'trust anchor'.  A particular trust point can have
-   more than one key designated as a trust anchor.
-
-   For a DNSSEC-aware resolver to validate information in a DNSSEC
-   protected branch of the hierarchy, it must have knowledge of a trust
-   anchor applicable to that branch.  It may also have more than one
-   trust anchor for any given trust point.  Under current rules, a chain
-   of trust for DNSSEC-protected data that chains its way back to ANY
-   known trust anchor is considered 'secure'.
-
-   Because of the probable balkanization of the DNSSEC tree due to
-   signing voids at key locations, a resolver may need to know literally
-   thousands of trust anchors to perform its duties. (e.g.  Consider an
-   unsigned ".COM".)  Requiring the owner of the resolver to manually
-   manage this many relationships is problematic.  It's even more
-   problematic when considering the eventual requirement for key
-   replacement/update for a given trust anchor.  The mechanism described
-   herein won't help with the initial configuration of the trust anchors
-   in the resolvers, but should make trust point key replacement/
-   rollover more viable.
-
-   As mentioned above, this document describes a mechanism whereby a
-   resolver can update the trust anchors for a given trust point, mainly
-   without human intervention at the resolver.  There are some corner
-   cases discussed (e.g. multiple key compromise) that may require
-   manual intervention, but they should be few and far between.  This
-   document DOES NOT discuss the general problem of the initial
-   configuration of trust anchors for the resolver.
-
-1.1.  Compliance Nomenclature
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, [RFC2119].
-
-1.2.  Changes since -00
-
-   Added the concept of timer triggered resolver queries to refresh the
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 3]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   resolvers view of the trust anchor key RRSet.
-
-   Re-submitted expired draft as -01.  Updated DNSSEC RFC References.
-
-   Draft -02.  Added the IANA Considerations section.  Added text to
-   describe what happens if all trust anchors at a trust point are
-   deleted.
-
-
-2.  Theory of Operation
-
-   The general concept of this mechanism is that existing trust anchors
-   can be used to authenticate new trust anchors at the same point in
-   the DNS hierarchy.  When a new SEP key is added to a trust point
-   DNSKEY RRSet, and when that RRSet is validated by an existing trust
-   anchor, then the new key can be added to the set of trust anchors.
-
-   There are some issues with this approach which need to be mitigated.
-   For example, a compromise of one of the existing keys could allow an
-   attacker to add their own 'valid' data.  This implies a need for a
-   method to revoke an existing key regardless of whether or not that
-   key is compromised.  As another example assuming a single key
-   compromise, an attacker could add a new key and revoke all the other
-   old keys.
-
-2.1.  Revocation
-
-   Assume two trust anchor keys A and B. Assume that B has been
-   compromised.  Without a specific revocation bit, B could invalidate A
-   simply by sending out a signed trust point key set which didn't
-   contain A. To fix this, we add a mechanism which requires knowledge
-   of the private key of a DNSKEY to revoke that DNSKEY.
-
-   A key is considered revoked when the resolver sees the key in a self-
-   signed RRSet and the key has the REVOKE bit (see Section 6 below) set
-   to '1'.  Once the resolver sees the REVOKE bit, it MUST NOT use this
-   key as a trust anchor or for any other purposes except validating the
-   RRSIG over the DNSKEY RRSet specifically for the purpose of
-   validating the revocation.  Unlike the 'Add' operation below,
-   revocation is immediate and permanent upon receipt of a valid
-   revocation at the resolver.
-
-   N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
-   than one without the bit set.  This affects the matching of a DNSKEY
-   to DS records in the parent, or the fingerprint stored at a resolver
-   used to configure a trust point. [msj3]
-
-   In the given example, the attacker could revoke B because it has
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 4]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   knowledge of B's private key, but could not revoke A.
-
-2.2.  Add Hold-Down
-
-   Assume two trust point keys A and B. Assume that B has been
-   compromised.  An attacker could generate and add a new trust anchor
-   key - C (by adding C to the DNSKEY RRSet and signing it with B), and
-   then invalidate the compromised key.  This would result in the both
-   the attacker and owner being able to sign data in the zone and have
-   it accepted as valid by resolvers.
-
-   To mitigate, but not completely solve, this problem, we add a hold-
-   down time to the addition of the trust anchor.  When the resolver
-   sees a new SEP key in a validated trust point DNSKEY RRSet, the
-   resolver starts an acceptance timer, and remembers all the keys that
-   validated the RRSet.  If the resolver ever sees the DNSKEY RRSet
-   without the new key but validly signed, it stops the acceptance
-   process and resets the acceptance timer.  If all of the keys which
-   were originally used to validate this key are revoked prior to the
-   timer expiring, the resolver stops the acceptance process and resets
-   the timer.
-
-   Once the timer expires, the new key will be added as a trust anchor
-   the next time the validated RRSet with the new key is seen at the
-   resolver.  The resolver MUST NOT treat the new key as a trust anchor
-   until the hold down time expires AND it has retrieved and validated a
-   DNSKEY RRSet after the hold down time which contains the new key.
-
-   N.B.: Once the resolver has accepted a key as a trust anchor, the key
-   MUST be considered a valid trust anchor by that resolver until
-   explictly revoked as described above.
-
-   In the given example, the zone owner can recover from a compromise by
-   revoking B and adding a new key D and signing the DNSKEY RRSet with
-   both A and B.
-
-   The reason this does not completely solve the problem has to do with
-   the distributed nature of DNS.  The resolver only knows what it sees.
-   A determined attacker who holds one compromised key could keep a
-   single resolver from realizing that key had been compromised by
-   intercepting 'real' data from the originating zone and substituting
-   their own (e.g. using the example, signed only by B).  This is no
-   worse than the current situation assuming a compromised key.
-
-2.3.  Remove Hold-down
-
-   A new key which has been seen by the resolver, but hasn't reached
-   it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 5]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   zone owner.  If the resolver sees a validated DNSKEY RRSet without
-   this key, it waits for the remove hold-down time and then, if the key
-   hasn't reappeared, SHOULD discard any information about the key.
-
-2.4.  Active Refresh
-
-   A resolver which has been configured for automatic update of keys
-   from a particular trust point MUST query that trust point (e.g. do a
-   lookup for the DNSKEY RRSet and related RRSIG records) no less often
-   than the lesser of 15 days or half the original TTL for the DNSKEY
-   RRSet or half the RRSIG expiration interval.  The expiration interval
-   is the amount of time from when the RRSIG was last retrieved until
-   the expiration time in the RRSIG.
-
-   If the query fails, the resolver MUST repeat the query until
-   satisfied no more often than once an hour and no less often than the
-   lesser of 1 day or 10% of the original TTL or 10% of the original
-   expiration interval.
-
-2.5.  Resolver Parameters
-
-2.5.1.  Add Hold-Down Time
-
-   The add hold-down time is 30 days or the expiration time of the TTL
-   of the first trust point DNSKEY RRSet which contained the key,
-   whichever is greater.  This ensures that at least two validated
-   DNSKEY RRSets which contain the new key MUST be seen by the resolver
-   prior to the key's acceptance.
-
-2.5.2.  Remove Hold-Down Time
-
-   The remove hold-down time is 30 days.
-
-2.5.3.  Minimum Trust Anchors per Trust Point
-
-   A compliant resolver MUST be able to manage at least five SEP keys
-   per trust point.
-
-
-3.  Changes to DNSKEY RDATA Wire Format
-
-   Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
-   flag.  If this bit is set to '1', AND the resolver sees an
-   RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
-   consider this key permanently invalid for all purposes except for
-   validing the revocation.
-
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 6]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-4.  State Table
-
-   The most important thing to understand is the resolver's view of any
-   key at a trust point.  The following state table describes that view
-   at various points in the key's lifetime.  The table is a normative
-   part of this specification.  The initial state of the key is 'Start'.
-   The resolver's view of the state of the key changes as various events
-   occur.
-
-   [msj1] This is the state of a trust point key as seen from the
-   resolver.  The column on the left indicates the current state.  The
-   header at the top shows the next state.  The intersection of the two
-   shows the event that will cause the state to transition from the
-   current state to the next.
-
-                             NEXT STATE
-           --------------------------------------------------
-    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
-   ----------------------------------------------------------
-   Start   |       |NewKey  |       |       |       |       |
-   ----------------------------------------------------------
-   AddPend |KeyRem |        |AddTime|       |       |
-   ----------------------------------------------------------
-   Valid   |       |        |       |KeyRem |Revbit |       |
-   ----------------------------------------------------------
-   Missing |       |        |KeyPres|       |Revbit |       |
-   ----------------------------------------------------------
-   Revoked |       |        |       |       |       |RemTime|
-   ----------------------------------------------------------
-   Removed |       |        |       |       |       |       |
-   ----------------------------------------------------------
-
-4.1.  Events
-   NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
-      That key will become a new trust anchor for the named trust point
-      after its been present in the RRSet for at least 'add time'.
-   KeyPres The key has returned to the valid DNSKEY RRSet.
-   KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
-      this key.
-   AddTime The key has been in every valid DNSKEY RRSet seen for at
-      least the 'add time'.
-   RemTime A revoked key has been missing from the trust point DNSKEY
-      RRSet for sufficient time to be removed from the trust set.
-   RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
-      "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
-      signed by this key.
-
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 7]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-4.2.  States
-   Start The key doesn't yet exist as a trust anchor at the resolver.
-      It may or may not exist at the zone server, but hasn't yet been
-      seen at the resolver.
-   AddPend The key has been seen at the resolver, has its 'SEP' bit set,
-      and has been included in a validated DNSKEY RRSet.  There is a
-      hold-down time for the key before it can be used as a trust
-      anchor.
-   Valid The key has been seen at the resolver and has been included in
-      all validated DNSKEY RRSets from the time it was first seen up
-      through the hold-down time.  It is now valid for verifying RRSets
-      that arrive after the hold down time.  Clarification: The DNSKEY
-      RRSet does not need to be continuously present at the resolver
-      (e.g. its TTL might expire).  If the RRSet is seen, and is
-      validated (i.e. verifies against an existing trust anchor), this
-      key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
-   Missing This is an abnormal state.  The key remains as a valid trust
-      point key, but was not seen at the resolver in the last validated
-      DNSKEY RRSet.  This is an abnormal state because the zone operator
-      should be using the REVOKE bit prior to removal.  [Discussion
-      item: Should a missing key be considered revoked after some period
-      of time?]
-   Revoked This is the state a key moves to once the resolver sees an
-      RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
-      this key with its REVOKE bit set to '1'.  Once in this state, this
-      key MUST permanently be considered invalid as a trust anchor.
-   Removed After a fairly long hold-down time, information about this
-      key may be purged from the resolver.  A key in the removed state
-      MUST NOT be considered a valid trust anchor.
-
-4.3.  Trust Point Deletion
-
-   A trust point which has all of its trust anchors revoked is
-   considered deleted and is treated as if the trust point was never
-   configured.  If there are no superior trust points, data at and below
-   the deleted trust point are considered insecure.  If there there ARE
-   superior trust points, data at and below the deleted trust point are
-   evaluated with respect to the superior trust point.
-
-
-5.  Scenarios
-
-   The suggested model for operation is to have one active key and one
-   stand-by key at each trust point.  The active key will be used to
-   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
-   RRSet, but the resolver will accept it as a trust anchor if/when it
-   sees the signature on the trust point DNSKEY RRSet.
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 8]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   Since the stand-by key is not in active signing use, the associated
-   private key may (and SHOULD) be provided with additional protections
-   not normally available to a key that must be used frequently.  E.g.
-   locked in a safe, split among many parties, etc.  Notionally, the
-   stand-by key should be less subject to compromise than an active key,
-   but that will be dependent on operational concerns not addressed
-   here.
-
-5.1.  Adding A Trust Anchor
-
-   Assume an existing trust anchor key 'A'.
-   1.  Generate a new key pair.
-   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
-       Key bits.
-   3.  Add the DNSKEY to the RRSet.
-   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
-       'A'.
-   5.  Wait a while.
-
-5.2.  Deleting a Trust Anchor
-
-   Assume existing trust anchors 'A' and 'B' and that you want to revoke
-   and delete 'A'.
-   1.  Set the revolcation bit on key 'A'.
-   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.
-   'A' is now revoked.  The operator SHOULD include the revoked 'A' in
-   the RRSet for at least the remove hold-down time, but then may remove
-   it from the DNSKEY RRSet.
-
-5.3.  Key Roll-Over
-
-   Assume existing keys A and B. 'A' is actively in use (i.e. has been
-   signing the DNSKEY RRSet.)  'B' was the stand-by key. (i.e. has been
-   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
-   used to sign the RRSet.)
-   1.  Generate a new key pair 'C'.
-   2.  Add 'C' to the DNSKEY RRSet.
-   3.  Set the revocation bit on key 'A'.
-   4.  Sign the RRSet with 'A' and 'B'.
-   'A' is now revoked, 'B' is now the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  The operator SHOULD include
-   the revoked 'A' in the RRSet for at least the remove hold-down time,
-   but may then remove it from the DNSKEY RRSet.
-
-5.4.  Active Key Compromised
-
-   This is the same as the mechanism for Key Roll-Over (Section 5.3)
-   above assuming 'A' is the active key.
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 9]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-5.5.  Stand-by Key Compromised
-
-   Using the same assumptions and naming conventions as Key Roll-Over
-   (Section 5.3) above:
-   1.  Generate a new key pair 'C'.
-   2.  Add 'C' to the DNSKEY RRSet.
-   3.  Set the revocation bit on key 'B'.
-   4.  Sign the RRSet with 'A' and 'B'.
-   'B' is now revoked, 'A' remains the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  'B' SHOULD continue to be
-   included in the RRSet for the remove hold-down time.
-
-
-6.  IANA Considerations
-
-   The IANA will need to assign a bit in the DNSKEY flags field (see
-   section 4.3 of [RFC3755]) for the REVOKE bit.  There are no other
-   IANA actions required.
-
-
-7.  Security Considerations
-
-7.1.  Key Ownership vs Acceptance Policy
-
-   The reader should note that, while the zone owner is responsible
-   creating and distributing keys, it's wholly the decision of the
-   resolver owner as to whether to accept such keys for the
-   authentication of the zone information.  This implies the decision
-   update trust anchor keys based on trust for a current trust anchor
-   key is also the resolver owner's decision.
-
-   The resolver owner (and resolver implementers) MAY choose to permit
-   or prevent key status updates based on this mechanism for specific
-   trust points.  If they choose to prevent the automated updates, they
-   will need to establish a mechanism for manual or other out-of-band
-   updates outside the scope of this document.
-
-7.2.  Multiple Key Compromise
-
-   This scheme permits recovery as long as at least one valid trust
-   anchor key remains uncompromised.  E.g. if there are three keys, you
-   can recover if two of them are compromised.  The zone owner should
-   determine their own level of comfort with respect to the number of
-   active valid trust anchors in a zone and should be prepared to
-   implement recovery procedures once they detect a compromise.  A
-   manual or other out-of-band update of all resolvers will be required
-   if all trust anchor keys at a trust point are compromised.
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 10]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-7.3.  Dynamic Updates
-
-   Allowing a resolver to update its trust anchor set based in-band key
-   information is potentially less secure than a manual process.
-   However, given the nature of the DNS, the number of resolvers that
-   would require update if a trust anchor key were compromised, and the
-   lack of a standard management framework for DNS, this approach is no
-   worse than the existing situation.
-
-8.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-Editorial Comments
-
-   [msj1]  msj: N.B. This table is preliminary and will be revised to
-           match implementation experience.  For example, should there
-           be a state for "Add hold-down expired, but haven't seen the
-           new RRSet"?
-
-   [msj2]  msj: To be assigned.
-
-   [msj3]  msj: For discussion: What's the implementation guidance for
-           resolvers currently with respect to the non-assigned flag
-           bits?  If they consider the flag bit when doing key matching
-           at the trust anchor, they won't be able to match.
-
-
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 11]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-Author's Address
-
-   Michael StJohns
-   Nominum, Inc.
-   2385 Bay Road
-   Redwood City, CA  94063
-   USA
-
-   Phone: +1-301-528-4729
-   Email: Mike.StJohns@nominum.com
-   URI:   www.nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 12]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 13]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt b/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt
new file mode 100644
index 000000000000..72d38aa267ab
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt
@@ -0,0 +1,336 @@
+
+
+
+DNSext Working Group                                           F. Dupont
+Internet-Draft                                                       ISC
+Updates: 2845,2930,4635                                      May 8, 2009
+(if approved)
+Intended status: Standards Track
+Expires: November 9, 2009
+
+
+     Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records
+              draft-ietf-dnsext-tsig-md5-deprecated-03.txt
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.  This document may contain material
+   from IETF Documents or IETF Contributions published or made publicly
+   available before November 10, 2008.  The person(s) controlling the
+   copyright in some of this material may not have granted the IETF
+   Trust the right to allow modifications of such material outside the
+   IETF Standards Process.  Without obtaining an adequate license from
+   the person(s) controlling the copyright in such materials, this
+   document may not be modified outside the IETF Standards Process, and
+   derivative works of it may not be created outside the IETF Standards
+   Process, except to format it for publication as an RFC or to
+   translate it into languages other than English.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on November 9, 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+Dupont                  Expires November 9, 2009                [Page 1]
+
+Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   The main purpose of this document is to deprecate the use of HMAC-MD5
+   as an algorithm for the TSIG (secret key transaction authentication)
+   resource record in the DNS (domain name system), and the use of MD5
+   in TKEY (secret key establishment for DNS).
+
+
+1.  Introduction
+
+   The secret key transaction authentication for DNS (TSIG, [RFC2845])
+   was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm.
+   When the MD5 [RFC1321] security came to be considered lower than
+   expected, [RFC4635] standardized new TSIG algorithms based on SHA
+   [RFC3174][RFC3874][RFC4634] digests.
+
+   But [RFC4635] did not deprecate the HMAC-MD5 algorithm.  This
+   document is targeted to complete the process, in detail:
+   1.  Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm
+       name registry managed by the IANA under the IETF Review Policy
+       [RFC5226]
+   2.  Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for
+       implementations
+   3.  Provide a keying material derivation for the secret key
+       establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman
+       exchange with SHA256 [RFC4634] in place of MD5 [RFC1321]
+   4.  Finally recommend the use of HMAC-SHA256.
+
+   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.  Implementation Requirements
+
+   The table of section 3 of [RFC4635] is replaced by:
+
+
+
+
+
+
+
+
+
+Dupont                  Expires November 9, 2009                [Page 2]
+
+Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
+
+
+             +-------------------+--------------------------+
+             | Requirement Level | Algorithm Name           |
+             +-------------------+--------------------------+
+             | Optional          | HMAC-MD5.SIG-ALG.REG.INT |
+             | Optional          | gss-tsig                 |
+             | Mandatory         | hmac-sha1                |
+             | Optional          | hmac-sha224              |
+             | Mandatory         | hmac-sha256              |
+             | Optional          | hmac-sha384              |
+             | Optional          | hmac-sha512              |
+             +-------------------+--------------------------+
+
+   Implementations that support TSIG MUST also implement HMAC-SHA1 and
+   HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level)
+   and MAY implement GSS-TSIG and the other algorithms listed above
+   (i.e., algorithms at a "not Mandatory" requirement level).
+
+
+3.  TKEY keying material derivation
+
+   When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying
+   material is derived from the shared secret and TKEY resource record
+   data using MD5 [RFC1321] at the end of section 4.1 page 9.
+
+   This is amended into:
+
+         keying material =
+              XOR ( DH value, SHA256 ( query data | DH value ) |
+                              SHA256 ( server data | DH value ) )
+
+   using the same conventions.
+
+
+4.  IANA Consideration
+
+   This document extends the "TSIG Algorithm Names - per [] and
+   [RFC2845]" located at
+   http://www.iana.org/assignments/tsig-algorithm-names by adding a new
+   column to the registry "Compliance Requirement".
+
+   The registry should contain the following:
+
+
+
+
+
+
+
+
+
+
+Dupont                  Expires November 9, 2009                [Page 3]
+
+Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
+
+
+    +--------------------------+------------------------+-------------+
+    | Algorithm Name           | Compliance Requirement | Reference   |
+    +--------------------------+------------------------+-------------+
+    | gss-tsig                 | Optional               | [RFC3645]   |
+    | HMAC-MD5.SIG-ALG.REG.INT | Optional               | [][RFC2845] |
+    | hmac-sha1                | Mandatory              | [RFC4635]   |
+    | hmac-sha224              | Optional               | [RFC4635]   |
+    | hmac-sha256              | Mandatory              | [RFC4635]   |
+    | hmac-sha384              | Optional               | [RFC4635]   |
+    | hmac-sha512              | Optional               | [RFC4635]   |
+    +--------------------------+------------------------+-------------+
+
+   where [] is this document.
+
+
+5.  Availability Considerations
+
+   MD5 is no longer universally available and its use may lead to
+   increasing operation issues.  SHA1 is likely to suffer from the same
+   kind of problem.  In summary MD5 has reached end-of-life and SHA1
+   will likely follow in the near term.
+
+   According to [RFC4635], implementations which support TSIG are
+   REQUIRED to implement HMAC-SHA256.
+
+
+6.  Security Considerations
+
+   This document does not assume anything about the cryptographic
+   security of different hash algorithms.  Its purpose is a better
+   availability of some security mechanisms in a predictable time frame.
+
+   Requirement levels are adjusted for TSIG and related specifications
+   (i.e., TKEY):
+      The support of HMAC-MD5 is changed from mandatory to optional.
+      The use of MD5 and HMAC-MD5 is NOT RECOMMENDED.
+      The use of HMAC-SHA256 is RECOMMENDED.
+
+
+7.  Acknowledgments
+
+   Olafur Gudmundsson kindly helped in the procedure to deprecate the
+   MD5 use in TSIG, i.e., the procedure which led to this memo.  Alfred
+   Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some
+   improvements.
+
+
+8.  References
+
+
+
+Dupont                  Expires November 9, 2009                [Page 4]
+
+Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
+
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC4635]  Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers",
+              RFC 4635, August 2006.
+
+8.2.  Informative References
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              April 1992.
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              February 1997.
+
+   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+              (SHA1)", RFC 3174, September 2001.
+
+   [RFC3645]  Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
+              and R. Hall, "Generic Security Service Algorithm for
+              Secret Key Transaction Authentication for DNS (GSS-TSIG)",
+              RFC 3645, October 2003.
+
+   [RFC3874]  Housley, R., "A 224-bit One-way Hash Function: SHA-224",
+              RFC 3874, September 2004.
+
+   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
+              (SHA and HMAC-SHA)", RFC 4634, July 2006.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", RFC 5226, BCP 26,
+              May 2008.
+
+
+
+
+
+
+
+
+
+
+Dupont                  Expires November 9, 2009                [Page 5]
+
+Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
+
+
+Author's Address
+
+   Francis Dupont
+   ISC
+
+   Email: Francis.Dupont@fdupont.fr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dupont                  Expires November 9, 2009                [Page 6]
+
diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
deleted file mode 100644
index 00476ae507ee..000000000000
--- a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
+++ /dev/null
@@ -1,522 +0,0 @@
-
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-UPDATES RFC 2845                                   Motorola Laboratories
-Expires: July 2006                                          January 2006
-
-                  HMAC SHA TSIG Algorithm Identifiers
-                  ---- --- ---- --------- -----------
-                  
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   This draft is intended to be become a Proposed Standard RFC.
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNSEXT working group mailing list .
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   Use of the Domain Name System TSIG resource record requires
-   specification of a cryptographic message authentication code.
-   Currently identifiers have been specified only for the HMAC MD5
-   (Message Digest) and GSS (Generic Security Service) TSIG algorithms.
-   This document standardizes identifiers and implementation
-   requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
-   algorithms and standardizes how to specify and handle the truncation
-   of HMAC values in TSIG.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-
-      2. Algorithms and Identifiers..............................4
-
-      3. Specifying Truncation...................................5
-      3.1 Truncation Specification...............................5
-
-      4. TSIG Truncation Policy and Error Provisions.............6
-
-      5. IANA Considerations.....................................7
-      6. Security Considerations.................................7
-      7. Copyright and Disclaimer................................7
-
-      8. Normative References....................................8
-      9. Informative References..................................8
-
-      Author's Address...........................................9
-      Additional IPR Provisions..................................9
-      Expiration and File Name...................................9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
-   [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
-   authenticate DNS (Domain Name System [STD 13]) queries and responses.
-   This RR contains a domain name syntax data item which names the
-   authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG-
-   ALG.REG.INT name for authentication codes using the HMAC [RFC 2104]
-   algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also
-   registered "gss-tsig" as an identifier for TSIG authentication where
-   the cryptographic operations are delegated to the Generic Security
-   Service (GSS) [RFC 3645].
-
-   It should be noted that use of TSIG presumes prior agreement, between
-   the resolver and server involved, as to the algorithm and key to be
-   used.
-
-   In Section 2, this document specifies additional names for TSIG
-   authentication algorithms based on US NIST SHA (United States,
-   National Institute of Science and Technology, Secure Hash Algorithm)
-   algorithms and HMAC and specifies the implementation requirements for
-   those algorithms.
-
-   In Section 3, this document specifies the effect of inequality
-   between the normal output size of the specified hash function and the
-   length of MAC (message authentication code) data given in the TSIG
-   RR. In particular, it specifies that a shorter length field value
-   specifies truncation and a longer length field is an error.
-
-   In Section 4, policy restrictions and implications related to
-   truncation and a new error code to indicate truncation shorter than
-   permitted by policy are described and specified.
-
-   The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
-   defined in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
-   TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
-   queries and responses.  They are intended to be efficient symmetric
-   authentication codes based on a shared secret. (Asymmetric signatures
-   can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
-   can be used for transaction signatures.) Used with a strong hash
-   function, HMAC [RFC 2104] provides a way to calculate such symmetric
-   authentication codes. The only specified HMAC based TSIG algorithm
-   identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
-   The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
-   compared with the 128 bits for MD5, and additional hash algorithms in
-   the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
-   and 512 bits, may be preferred in some cases particularly since
-   increasingly successful cryptanalytic attacks are being made on the
-   shorter hashes.
-
-   Use of TSIG between a DNS resolver and server is by mutual agreement.
-   That agreement can include the support of additional algorithms and
-   criteria as to which algorithms and truncations are acceptable,
-   subject to the restriction and guidelines in Section 3 and 4 below.
-   Key agreement can be by the TKEY mechanism [RFC 2930] or other
-   mutually agreeable method.
-
-   The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
-   included in the table below for convenience.  Implementations which
-   support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
-   implement gss-tsig and the other algorithms listed below.
-
-         Mandatory      HMAC-MD5.SIG-ALG.REG.INT
-         Optional       gss-tsig
-         Mandatory      hmac-sha1
-         Optional       hmac-sha224
-         Mandatory      hmac-sha256
-         Optional       hamc-sha384
-         Optional       hmac-sha512
-
-   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
-   When space is at a premium and the strength of the full length of an
-   HMAC is not needed, it is reasonable to truncate the HMAC output and
-   use the truncated value for authentication. HMAC SHA-1 truncated to
-   96 bits is an option available in several IETF protocols including
-   IPSEC and TLS.
-
-   The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
-   size of the MAC field in octets. But [RFC 2845] does not specify what
-   to do if this MAC size differs from the length of the output of HMAC
-   for a particular hash function. Truncation is indicated by a MAC size
-   less than the HMAC size as specified below.
-
-
-
-3.1 Truncation Specification
-
-   The specification for TSIG handling is changed as follows:
-
-   1. If "MAC size" field is greater than HMAC output length:
-         This case MUST NOT be generated and if received MUST cause the
-      packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
-   2. If "MAC size" field equals HMAC output length:
-         Operation is as described in [RFC 2845] with the entire output
-      HMAC output present.
-
-   3. "MAC size" field is less than HMAC output length but greater than
-      that specified in case 4 below:
-         This is sent when the signer has truncated the HMAC output to
-      an allowable length, as described in RFC 2104, taking initial
-      octets and discarding trailing octets. TSIG truncation can only be
-      to an integral number of octets. On receipt of a packet with
-      truncation thus indicated, the locally calculated MAC is similarly
-      truncated and only the truncated values compared for
-      authentication. The request MAC used when calculating the TSIG MAC
-      for a reply is the truncated request MAC.
-
-   4. "MAC size" field is less than the larger of 10 (octets) and half
-      the length of the hash function in use:
-         With the exception of certain TSIG error messages described in
-      RFC 2845 section 3.2 where it is permitted that the MAC size be
-      zero, this case MUST NOT be generated and if received MUST cause
-      the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
-      size limit for this case can also, for the hash functions
-      mentioned in this document, be stated as less than half the hash
-      function length for hash functions other than MD5 and less than 10
-      octets for MD5.
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-4. TSIG Truncation Policy and Error Provisions
-
-   Use of TSIG is by mutual agreement between a resolver and server.
-   Implicit in such "agreement" are criterion as to acceptable keys and
-   algorithms and, with the extensions in this document, truncations.
-   Note that it is common for implementations to bind the TSIG secret
-   key or keys that may be in place at a resolver and server to
-   particular algorithms. Thus such implementations only permit the use
-   of an algorithm if there is an associated key in place. Receipt of an
-   unknown, unimplemented, or disabled algorithm typically results in a
-   BADKEY error.
-
-      Local policies MAY require the rejection of TSIGs even though they
-   use an algorithm for which implementation is mandatory.
-
-      When a local policy permits acceptance of a TSIG with a particular
-   algorithm and a particular non-zero amount of truncation it SHOULD
-   also permit the use of that algorithm with lesser truncation (a
-   longer MAC) up to the full HMAC output.
-
-      Regardless of a lower acceptable truncated MAC length specified by
-   local policy, a reply SHOULD be sent with a MAC at least as long as
-   that in the corresponding request unless the request specified a MAC
-   length longer than the HMAC output.
-
-      Implementations permitting multiple acceptable algorithms and/or
-   truncations SHOULD permit this list to be ordered by presumed
-   strength and SHOULD allow different truncations for the same
-   algorithm to be treated as separate entities in this list. When so
-   implemented, policies SHOULD accept a presumed stronger algorithm and
-   truncation than the minimum strength required by the policy.
-
-      If a TSIG is received with truncation which is permitted under
-   Section 3 above but the MAC is too short for the local policy in
-   force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-5. IANA Considerations
-
-   This document, on approval for publication as a standards track RFC,
-   (1) registers the new TSIG algorithm identifiers listed in Section 2
-   with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
-   Section 4. [RFC 2845]
-
-
-
-6. Security Considerations
-
-   For all of the message authentication code algorithms listed herein,
-   those producing longer values are believed to be stronger; however,
-   while there have been some arguments that mild truncation can
-   strengthen a MAC by reducing the information available to an
-   attacker, excessive truncation clearly weakens authentication by
-   reducing the number of bits an attacker has to try to break the
-   authentication by brute force [RFC 2104].
-
-   Significant progress has been made recently in cryptanalysis of hash
-   function of the type used herein, all of which ultimately derive from
-   the design of MD4. While the results so far should not effect HMAC,
-   the stronger SHA-1 and SHA-256 algorithms are being made mandatory
-   due to caution.
-
-   See the Security Considerations section of [RFC 2845].  See also the
-   Security Considerations section of [RFC 2104] from which the limits
-   on truncation in this RFC were taken.
-
-
-
-7. Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-8. Normative References
-
-   [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
-   Federal Information Processing Standard, with Change Notice 1,
-   February 2004.
-
-   [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
-   1321, April 1992.
-
-   [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-   Hashing for Message Authentication", RFC 2104, February 1997.
-
-   [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
-   RFC 2845, May 2000.
-
-   [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
-   1 (SHA1)", RFC 3174, September 2001.
-
-   [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
-   September 2004,
-
-   [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
-   (SHA)", draft-eastlake-sha2-*.txt, work in progress.
-
-   [STD 13]
-         Mockapetris, P., "Domain names - concepts and facilities", STD
-         13, RFC 1034, November 1987.
-
-         Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-
-
-9. Informative References.
-
-   [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
-   (TKEY RR)", RFC 2930, September 2000.
-
-   [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
-   Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
-   J., and R. Hall, "Generic Security Service Algorithm for Secret Key
-   Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
-   2003.
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554 (w)
-
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Additional IPR Provisions
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed
-   to pertain to the implementation or use of the technology
-   described in this document or the extent to which any license
-   under such rights might or might not be available; nor does it
-   represent that it has made any independent effort to identify any
-   such rights.  Information on the procedures with respect to
-   rights in RFC documents can be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use
-   of such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository
-   at http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention
-   any copyrights, patents or patent applications, or other
-   proprietary rights that may cover technology that may be required
-   to implement this standard.  Please address the information to the
-   IETF at ietf-ipr@ietf.org.
-
-
-
-Expiration and File Name
-
-   This draft expires in July 2006.
-
-   Its file name is draft-ietf-dnsext-tsig-sha-06.txt
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
deleted file mode 100644
index 9cf88a5831f6..000000000000
--- 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 "*.", where  is any domain name.
-#  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   
-        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  
-        _ssh._tcp.host2.example. 3600     SRV  
-        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:
-            ..
-      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   
-                               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-default-local-zones-09.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt
new file mode 100644
index 000000000000..7e81e4c4bf55
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt
@@ -0,0 +1,729 @@
+
+
+
+Network Working Group                                         M. Andrews
+Internet-Draft                                                       ISC
+Intended status: BCP                                   November 19, 2009
+Expires: May 23, 2010
+
+
+                        Locally-served DNS Zones
+                draft-ietf-dnsop-default-local-zones-09
+
+Abstract
+
+   Experience with the Domain Name System (DNS) has shown that there are
+   a number of DNS zones all iterative resolvers and recursive
+   nameservers should automatically serve, unless configured otherwise.
+   RFC 4193 specifies that this should occur for D.F.IP6.ARPA.  This
+   document extends the practice to cover the IN-ADDR.ARPA zones for RFC
+   1918 address space and other well known zones with similar
+   characteristics.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 May 23, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+
+
+
+Andrews                   Expires May 23, 2010                  [Page 1]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                   Expires May 23, 2010                  [Page 2]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Effects on sites using RFC 1918 addresses. . . . . . . . . . .  4
+   3.  Changes to Iterative Resolver Behaviour. . . . . . . . . . . .  4
+   4.  Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  RFC1918 Zones  . . . . . . . . . . . . . . . . . . . . . .  5
+     4.2.  RFC3330 Zones  . . . . . . . . . . . . . . . . . . . . . .  6
+     4.3.  Local IPv6 Unicast Addresses . . . . . . . . . . . . . . .  6
+     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  6
+     4.5.  IPv6 Link Local Addresses  . . . . . . . . . . . . . . . .  7
+     4.6.  IPv6 Example Prefix  . . . . . . . . . . . . . . . . . . .  7
+   5.  Zones that are Out-Of-Scope  . . . . . . . . . . . . . . . . .  7
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+   Appendix A.  Change History [To Be Removed on Publication] . . . . 10
+     A.1.  draft-ietf-dnsop-default-local-zones-09.txt  . . . . . . . 10
+     A.2.  draft-ietf-dnsop-default-local-zones-08.txt  . . . . . . . 10
+     A.3.  draft-ietf-dnsop-default-local-zones-07.txt  . . . . . . . 10
+     A.4.  draft-ietf-dnsop-default-local-zones-06.txt  . . . . . . . 10
+     A.5.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 11
+     A.6.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 11
+     A.7.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 11
+     A.8.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 11
+     A.9.  draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
+     A.10. draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
+     A.11. draft-andrews-full-service-resolvers-03.txt  . . . . . . . 11
+     A.12. draft-andrews-full-service-resolvers-02.txt  . . . . . . . 12
+   Appendix B.  Proposed Status [To Be Removed on Publication]  . . . 12
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                   Expires May 23, 2010                  [Page 3]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+1.  Introduction
+
+   Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035])
+   has shown that there are a number of DNS zones that all iterative
+   resolvers and recursive nameservers SHOULD automatically serve,
+   unless intentionally configured otherwise.  These zones include, but
+   are not limited to, the IN-ADDR.ARPA zones for the address space
+   allocated by [RFC1918] and the IP6.ARPA zones for locally assigned
+   unique local IPv6 addresses defined in [RFC4193].
+
+   This recommendation is made because data has shown that significant
+   leakage of queries for these name spaces is occurring, despite
+   instructions to restrict them, and because it has therefore become
+   necessary to deploy sacrificial name servers to protect the immediate
+   parent name servers for these zones from excessive, unintentional,
+   query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
+   [I-D.draft-ietf-dnsop-as112-under-attack-help-help].  There is every
+   expectation that the query load will continue to increase unless
+   steps are taken as outlined here.
+
+   Additionally, queries from clients behind badly configured firewalls
+   that allow outgoing queries for these name spaces but drop the
+   responses, put a significant load on the root servers (forward but no
+   reverse zones configured).  They also cause operational load for the
+   root server operators as they have to reply to enquiries about why
+   the root servers are "attacking" these clients.  Changing the default
+   configuration will address all these issues for the zones listed in
+   Section 4.
+
+   [RFC4193] recommends that queries for D.F.IP6.ARPA be handled
+   locally.  This document extends the recommendation to cover the IN-
+   ADDR.ARPA zones for [RFC1918] and other well known IN-ADDR.ARPA and
+   IP6.ARPA zones for which queries should not appear on the public
+   Internet.
+
+   It is hoped that by doing this the number of sacrificial servers
+   [AS112] will not have to be increased, and may in time be reduced.
+
+   This recommendation should also help DNS responsiveness for sites
+   which are using [RFC1918] addresses but do not follow the last
+   paragraph in Section 3 of [RFC1918].
+
+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].
+
+
+
+
+Andrews                   Expires May 23, 2010                  [Page 4]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+2.  Effects on sites using RFC 1918 addresses.
+
+   For most sites using [RFC1918] addresses, the changes here will have
+   little or no detrimental effect.  If the site does not already have
+   the reverse tree populated the only effect will be that the name
+   error responses will be generated locally rather than remotely.
+
+   For sites that do have the reverse tree populated, most will either
+   have a local copy of the zones or will be forwarding the queries to
+   servers which have local copies of the zone.  Therefore this
+   recommendation will not be relevant.
+
+   The most significant impact will be felt at sites that make use of
+   delegations for [RFC1918] addresses and have populated these zones.
+   These sites will need to override the default configuration expressed
+   in this document to allow resolution to continue.  Typically, such
+   sites will be fully disconnected from the Internet and have their own
+   root servers for their own non-Internet DNS tree.
+
+
+3.  Changes to Iterative Resolver Behaviour.
+
+   Unless configured otherwise, an iterative resolver will now return
+   authoritatively (aa=1) name errors (RCODE=3) for queries within the
+   zones in Section 4, with the obvious exception of queries for the
+   zone name itself where SOA, NS and "no data" responses will be
+   returned as appropriate to the query type.  One common way to do this
+   all at once is to serve empty (SOA and NS only) zones.
+
+   An implementation of this recommendation MUST provide a mechanism to
+   disable this new behaviour, and SHOULD allow this decision on a zone
+   by zone basis.
+
+   If using empty zones one SHOULD NOT use the same NS and SOA records
+   as used on the public Internet servers as that will make it harder to
+   detect the origin of the responses and thus any leakage to the public
+   Internet servers.  This document recommends that the NS record
+   defaults to the name of the zone and the SOA MNAME defaults to the
+   name of the only NS RR's target.  The SOA RNAME should default to
+   "nobody.invalid."  [RFC2606].  Implementations SHOULD provide a
+   mechanism to set these values.  No address records need to be
+   provided for the name server.
+
+   Below is an example of a generic empty zone in master file format.
+   It will produce a negative cache TTL of 3 hours.
+
+   @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
+   @ 10800 IN NS @
+
+
+
+Andrews                   Expires May 23, 2010                  [Page 5]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+   The SOA RR is needed to support negative caching [RFC2308] of name
+   error responses and to point clients to the primary master for DNS
+   dynamic updates.
+
+   SOA values of particular importance are the MNAME, the SOA RR's TTL
+   and the negTTL value.  Both TTL values SHOULD match.  The rest of the
+   SOA timer values MAY be chosen arbitrarily since they are not
+   intended to control any zone transfer activity.
+
+   The NS RR is needed as some UPDATE [RFC2136] clients use NS queries
+   to discover the zone to be updated.  Having no address records for
+   the name server is expected to abort UPDATE processing in the client.
+
+
+4.  Lists Of Zones Covered
+
+   The following subsections are intended to seed the IANA registry as
+   requested in the IANA Considerations Section.  The zone name is the
+   entity to be registered.
+
+4.1.  RFC1918 Zones
+
+   The following zones correspond to the IPv4 address space reserved in
+   [RFC1918].
+
+                         +----------------------+
+                         | Zone                 |
+                         +----------------------+
+                         | 10.IN-ADDR.ARPA      |
+                         | 16.172.IN-ADDR.ARPA  |
+                         | 17.172.IN-ADDR.ARPA  |
+                         | 18.172.IN-ADDR.ARPA  |
+                         | 19.172.IN-ADDR.ARPA  |
+                         | 20.172.IN-ADDR.ARPA  |
+                         | 21.172.IN-ADDR.ARPA  |
+                         | 22.172.IN-ADDR.ARPA  |
+                         | 23.172.IN-ADDR.ARPA  |
+                         | 24.172.IN-ADDR.ARPA  |
+                         | 25.172.IN-ADDR.ARPA  |
+                         | 26.172.IN-ADDR.ARPA  |
+                         | 27.172.IN-ADDR.ARPA  |
+                         | 28.172.IN-ADDR.ARPA  |
+                         | 29.172.IN-ADDR.ARPA  |
+                         | 30.172.IN-ADDR.ARPA  |
+                         | 31.172.IN-ADDR.ARPA  |
+                         | 168.192.IN-ADDR.ARPA |
+                         +----------------------+
+
+
+
+
+Andrews                   Expires May 23, 2010                  [Page 6]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+4.2.  RFC3330 Zones
+
+   The following zones correspond to those address ranges from [RFC3330]
+   that are not expected to appear as source or destination addresses on
+   the public Internet and to not have a unique name to associate with.
+
+   The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
+   attempt to discourage any practice to provide a PTR RR for
+   1.0.0.127.IN-ADDR.ARPA locally.  In fact, a meaningful reverse
+   mapping should exist, but the exact setup is out of the scope of this
+   document.  Similar logic applies to the reverse mapping for ::1
+   (Section 4.3).  The recommendations made here simply assume no other
+   coverage for these domains exists.
+
+         +------------------------------+------------------------+
+         | Zone                         | Description            |
+         +------------------------------+------------------------+
+         | 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK    |
+         | 127.IN-ADDR.ARPA             | IPv4 LOOP-BACK NETWORK |
+         | 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL        |
+         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET          |
+         | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST         |
+         +------------------------------+------------------------+
+
+4.3.  Local IPv6 Unicast Addresses
+
+   The reverse mappings ([RFC3596], Section 2.5 IP6.ARPA Domain) for the
+   IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291],
+   Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
+
+               +-------------------------------------------+
+               | Zone                                      |
+               +-------------------------------------------+
+               | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
+               |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
+               | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
+               |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
+               +-------------------------------------------+
+
+   Note: Line breaks and a escapes '\' have been inserted above for
+   readability and to adhere to line width constraints.  They are not
+   parts of the zone names.
+
+4.4.  IPv6 Locally Assigned Local Addresses
+
+   Section 4.4 of [RFC4193] already required special treatment of:
+
+
+
+
+
+Andrews                   Expires May 23, 2010                  [Page 7]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+                             +--------------+
+                             | Zone         |
+                             +--------------+
+                             | D.F.IP6.ARPA |
+                             +--------------+
+
+4.5.  IPv6 Link Local Addresses
+
+   IPv6 Link-Local Addresses as of [RFC4291], Section 2.5.6 are covered
+   by four distinct reverse DNS zones:
+
+                            +----------------+
+                            | Zone           |
+                            +----------------+
+                            | 8.E.F.IP6.ARPA |
+                            | 9.E.F.IP6.ARPA |
+                            | A.E.F.IP6.ARPA |
+                            | B.E.F.IP6.ARPA |
+                            +----------------+
+
+4.6.  IPv6 Example Prefix
+
+   IPv6 example prefix [RFC3849].
+
+                       +--------------------------+
+                       | Zone                     |
+                       +--------------------------+
+                       | 8.B.D.0.1.0.0.2.IP6.ARPA |
+                       +--------------------------+
+
+   Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as a example here.
+
+
+5.  Zones that are Out-Of-Scope
+
+   IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and
+   2.5.7), and IPv6 Non-Locally Assigned Local addresses ([RFC4193]) are
+   not covered here.
+
+   It is expected that IPv6 site-local addresses will be self correcting
+   as IPv6 implementations remove support for site-local addresses.
+   However, sacrificial servers for the zones C.E.F.IP6.ARPA through
+   F.E.F.IP6.ARPA may still need to be deployed in the short term if the
+   traffic becomes excessive.
+
+   For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC4193],
+   there has been no decision made about whether the Regional Internet
+   Registries (RIRs) will provide delegations in this space or not.  If
+
+
+
+Andrews                   Expires May 23, 2010                  [Page 8]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+   they don't, then C.F.IP6.ARPA will need to be added to the list in
+   Section 4.4.  If they do, then registries will need to take steps to
+   ensure that name servers are provided for these addresses.
+
+   This document also ignores IP6.INT.  IP6.INT has been wound up with
+   only legacy resolvers now generating reverse queries under IP6.INT
+   [RFC4159].
+
+   This document has also deliberately ignored names immediately under
+   the root domain.  While there is a subset of queries to the root name
+   servers which could be addressed using the techniques described here
+   (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
+   amount of traffic that requires a different strategy (e.g. lookups
+   for unqualified hostnames, IPv6 addresses).
+
+
+6.  IANA Considerations
+
+   This document requests that IANA establish a registry of zones which
+   require this default behaviour.  The initial contents of this
+   registry are defined in Section 4.  Implementors are encouraged to
+   periodically check this registry and adjust their implementations to
+   reflect changes therein.
+
+   This registry can be amended through "IETF Review" as per [RFC5226].
+
+   IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
+   deployed in the reverse tree, delegations for these zones are made in
+   the manner described in Section 7.
+
+
+7.  Security Considerations
+
+   During the initial deployment phase, particularly where [RFC1918]
+   addresses are in use, there may be some clients that unexpectedly
+   receive a name error rather than a PTR record.  This may cause some
+   service disruption until their recursive name server(s) have been re-
+   configured.
+
+   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
+   namespaces, the zones listed above will need to be delegated as
+   insecure delegations, or be within insecure zones.  This will allow
+   DNSSEC validation to succeed for queries in these spaces despite not
+   being answered from the delegated servers.
+
+   It is recommended that sites actively using these namespaces secure
+   them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
+   anchors.  This will protect the clients from accidental import of
+
+
+
+Andrews                   Expires May 23, 2010                  [Page 9]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+   unsigned responses from the Internet.
+
+
+8.  Acknowledgements
+
+   This work was supported by the US National Science Foundation
+   (research grant SCI-0427144) and DNS-OARC.
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
+              SPECIFICATION", STD 13, RFC 1035, November 1987.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2398, March 1998.
+
+   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+              Names", BCP 32, RFC 2606, June 1999.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IPv6", RFC 3596, October 2003.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
+              August 2005.
+
+   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", RFC 4193, October 2005.
+
+
+
+Andrews                   Expires May 23, 2010                 [Page 10]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              October 2008.
+
+9.2.  Informative References
+
+   [AS112]    "AS112 Project", .
+
+   [I-D.draft-ietf-dnsop-as112-ops]
+              Abley, J. and W. Maton, "AS112 Nameserver Operations",
+              draft-ietf-dnsop-as112-ops-01 (work in progress),
+              November 2007.
+
+   [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
+              Abley, J. and W. Maton, "I'm Being Attacked by
+              PRISONER.IANA.ORG!",
+              draft-ietf-dnsop-as112-under-attack-help-help-01 (work in
+              progress), November 2007.
+
+   [RFC3330]  "Special-Use IPv4 Addresses", RFC 3330, September 2002.
+
+   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
+              Reserved for Documentation", RFC 3849, July 2004.
+
+
+Appendix A.  Change History [To Be Removed on Publication]
+
+A.1.  draft-ietf-dnsop-default-local-zones-09.txt
+
+   refresh awaiting writeup
+
+A.2.  draft-ietf-dnsop-default-local-zones-08.txt
+
+   editorial, reference updates
+
+A.3.  draft-ietf-dnsop-default-local-zones-07.txt
+
+   none, expiry prevention
+
+A.4.  draft-ietf-dnsop-default-local-zones-06.txt
+
+   add IPv6 example prefix
+
+
+
+
+
+
+Andrews                   Expires May 23, 2010                 [Page 11]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+A.5.  draft-ietf-dnsop-default-local-zones-05.txt
+
+   none, expiry prevention
+
+A.6.  draft-ietf-dnsop-default-local-zones-04.txt
+
+   Centrally Assigned Local addresses -> Non-Locally Assigned Local
+   address
+
+A.7.  draft-ietf-dnsop-default-local-zones-03.txt
+
+   expanded section 4 descriptions
+
+   Added references [RFC2136], [RFC3596],
+   [I-D.draft-ietf-dnsop-as112-ops] and
+   [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
+
+   Revised language.
+
+A.8.  draft-ietf-dnsop-default-local-zones-02.txt
+
+   RNAME now "nobody.invalid."
+
+   Revised language.
+
+A.9.  draft-ietf-dnsop-default-local-zones-01.txt
+
+   Revised impact description.
+
+   Updated to reflect change in IP6.INT status.
+
+A.10.  draft-ietf-dnsop-default-local-zones-00.txt
+
+   Adopted by DNSOP.
+
+   "Author's Note" re-titled "Zones that are Out-Of-Scope"
+
+   Add note that these zone are expected to seed the IANA registry.
+
+   Title changed.
+
+A.11.  draft-andrews-full-service-resolvers-03.txt
+
+   Added "Proposed Status".
+
+
+
+
+
+
+
+Andrews                   Expires May 23, 2010                 [Page 12]
+
+Internet-Draft          Locally-served DNS Zones           November 2009
+
+
+A.12.  draft-andrews-full-service-resolvers-02.txt
+
+   Added 0.IN-ADDR.ARPA.
+
+
+Appendix B.  Proposed Status [To Be Removed on Publication]
+
+   This Internet-Draft is being submitted for eventual publication as an
+   RFC with a proposed status of Best Current Practice.
+
+
+Author's Address
+
+   Mark P. Andrews
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   US
+
+   Email: Mark_Andrews@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                   Expires May 23, 2010                 [Page 13]
+
+
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
deleted file mode 100644
index 8ca68a8b2b75..000000000000
--- a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
+++ /dev/null
@@ -1,2016 +0,0 @@
-
-
-
-DNSOP                                                         O. Kolkman
-Internet-Draft                                                 R. Gieben
-Obsoletes: 2541 (if approved)                                 NLnet Labs
-Expires: September 7, 2006                                 March 6, 2006
-
-
-                      DNSSEC Operational Practices
-          draft-ietf-dnsop-dnssec-operational-practices-08.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 7, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a set of practices for operating the DNS with
-   security extensions (DNSSEC).  The target audience is zone
-   administrators deploying DNSSEC.
-
-   The document discusses operational aspects of using keys and
-   signatures in the DNS.  It discusses issues as key generation, key
-   storage, signature generation, key rollover and related policies.
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 1]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   This document obsoletes RFC 2541, as it covers more operational
-   ground and gives more up to date requirements with respect to key
-   sizes and the new DNSSEC specification.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  The Use of the Term 'key'  . . . . . . . . . . . . . . . .  4
-     1.2.  Time Definitions . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Keeping the Chain of Trust Intact  . . . . . . . . . . . . . .  5
-   3.  Keys Generation and Storage  . . . . . . . . . . . . . . . . .  6
-     3.1.  Zone and Key Signing Keys  . . . . . . . . . . . . . . . .  6
-       3.1.1.  Motivations for the KSK and ZSK Separation . . . . . .  7
-       3.1.2.  KSKs for High Level Zones  . . . . . . . . . . . . . .  8
-     3.2.  Key Generation . . . . . . . . . . . . . . . . . . . . . .  8
-     3.3.  Key Effectivity Period . . . . . . . . . . . . . . . . . .  9
-     3.4.  Key Algorithm  . . . . . . . . . . . . . . . . . . . . . .  9
-     3.5.  Key Sizes  . . . . . . . . . . . . . . . . . . . . . . . . 10
-     3.6.  Private Key Storage  . . . . . . . . . . . . . . . . . . . 12
-   4.  Signature generation, Key Rollover and Related Policies  . . . 12
-     4.1.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12
-       4.1.1.  Time Considerations  . . . . . . . . . . . . . . . . . 13
-     4.2.  Key Rollovers  . . . . . . . . . . . . . . . . . . . . . . 14
-       4.2.1.  Zone Signing Key Rollovers . . . . . . . . . . . . . . 15
-       4.2.2.  Key Signing Key Rollovers  . . . . . . . . . . . . . . 19
-       4.2.3.  Difference Between ZSK and KSK Rollovers . . . . . . . 20
-       4.2.4.  Automated Key Rollovers  . . . . . . . . . . . . . . . 21
-     4.3.  Planning for Emergency Key Rollover  . . . . . . . . . . . 22
-       4.3.1.  KSK Compromise . . . . . . . . . . . . . . . . . . . . 22
-       4.3.2.  ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24
-       4.3.3.  Compromises of Keys Anchored in Resolvers  . . . . . . 24
-     4.4.  Parental Policies  . . . . . . . . . . . . . . . . . . . . 24
-       4.4.1.  Initial Key Exchanges and Parental Policies
-               Considerations . . . . . . . . . . . . . . . . . . . . 24
-       4.4.2.  Storing Keys or Hashes?  . . . . . . . . . . . . . . . 25
-       4.4.3.  Security Lameness  . . . . . . . . . . . . . . . . . . 25
-       4.4.4.  DS Signature Validity Period . . . . . . . . . . . . . 26
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
-   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28
-   Appendix A.  Terminology . . . . . . . . . . . . . . . . . . . . . 29
-   Appendix B.  Zone Signing Key Rollover Howto . . . . . . . . . . . 30
-   Appendix C.  Typographic Conventions . . . . . . . . . . . . . . . 31
-   Appendix D.  Document Details and Changes  . . . . . . . . . . . . 33
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 2]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-     D.1.  draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33
-     D.2.  draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33
-     D.3.  draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33
-     D.4.  draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33
-     D.5.  draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34
-     D.6.  draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34
-     D.7.  draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34
-     D.8.  draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34
-     D.9.  draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
-   Intellectual Property and Copyright Statements . . . . . . . . . . 36
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 3]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-1.  Introduction
-
-   This document describes how to run a DNSSEC (DNS SECure) enabled
-   environment.  It is intended for operators who have knowledge of the
-   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC.  See
-   RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the
-   newly introduced Resource Records and finally RFC 4035 [6] for the
-   protocol changes.
-
-   During workshops and early operational deployment tests, operators
-   and system administrators have gained experience about operating the
-   DNS with security extensions (DNSSEC).  This document translates
-   these experiences into a set of practices for zone administrators.
-   At the time of writing, there exists very little experience with
-   DNSSEC in production environments; this document should therefore
-   explicitly not be seen as representing 'Best Current Practices'.
-
-   The procedures herein are focused on the maintenance of signed zones
-   (i.e. signing and publishing zones on authoritative servers).  It is
-   intended that maintenance of zones such as re-signing or key
-   rollovers be transparent to any verifying clients on the Internet.
-
-   The structure of this document is as follows.  In Section 2 we
-   discuss the importance of keeping the "chain of trust" intact.
-   Aspects of key generation and storage of private keys are discussed
-   in Section 3; the focus in this section is mainly on the private part
-   of the key(s).  Section 4 describes considerations concerning the
-   public part of the keys.  Since these public keys appear in the DNS
-   one has to take into account all kinds of timing issues, which are
-   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
-   rollover, or supercession, of keys.  Finally Section 4.4 discusses
-   considerations on how parents deal with their children's public keys
-   in order to maintain chains of trust.
-
-   The typographic conventions used in this document are explained in
-   Appendix C.
-
-   Since this is a document with operational suggestions and there are
-   no protocol specifications, the RFC 2119 [9] language does not apply.
-
-   This document obsoletes RFC 2541 [12].
-
-1.1.  The Use of the Term 'key'
-
-   It is assumed that the reader is familiar with the concept of
-   asymmetric keys on which DNSSEC is based (Public Key Cryptography
-   [18]).  Therefore, this document will use the term 'key' rather
-   loosely.  Where it is written that 'a key is used to sign data' it is
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 4]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   assumed that the reader understands that it is the private part of
-   the key pair that is used for signing.  It is also assumed that the
-   reader understands that the public part of the key pair is published
-   in the DNSKEY resource record and that it is the public part that is
-   used in key exchanges.
-
-1.2.  Time Definitions
-
-   In this document we will be using a number of time related terms.
-   The following definitions apply:
-   o  "Signature validity period"
-         The period that a signature is valid.  It starts at the time
-         specified in the signature inception field of the RRSIG RR and
-         ends at the time specified in the expiration field of the RRSIG
-         RR.
-   o  "Signature publication period"
-         Time after which a signature (made with a specific key) is
-         replaced with a new signature (made with the same key).  This
-         replacement takes place by publishing the relevant RRSIG in the
-         master zone file.
-         After one stops publishing an RRSIG in a zone it may take a
-         while before the RRSIG has expired from caches and has actually
-         been removed from the DNS.
-   o  "Key effectivity period"
-         The period during which a key pair is expected to be effective.
-         This period is defined as the time between the first inception
-         time stamp and the last expiration date of any signature made
-         with this key, regardless of any discontinuity in the use of
-         the key.
-         The key effectivity period can span multiple signature validity
-         periods.
-   o  "Maximum/Minimum Zone Time to Live (TTL)"
-         The maximum or minimum value of the TTLs from the complete set
-         of RRs in a zone.  Note that the minimum TTL is not the same as
-         the MINIMUM field in the SOA RR.  See [11] for more
-         information.
-
-
-2.  Keeping the Chain of Trust Intact
-
-   Maintaining a valid chain of trust is important because broken chains
-   of trust will result in data being marked as Bogus (as defined in [4]
-   section 5), which may cause entire (sub)domains to become invisible
-   to verifying clients.  The administrators of secured zones have to
-   realize that their zone is, to verifying clients, part of a chain of
-   trust.
-
-   As mentioned in the introduction, the procedures herein are intended
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 5]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   to ensure that maintenance of zones, such as re-signing or key
-   rollovers, will be transparent to the verifying clients on the
-   Internet.
-
-   Administrators of secured zones will have to keep in mind that data
-   published on an authoritative primary server will not be immediately
-   seen by verifying clients; it may take some time for the data to be
-   transferred to other secondary authoritative nameservers and clients
-   may be fetching data from caching non-authoritative servers.  In this
-   light it is good to note that the time for a zone transfer from
-   master to slave is negligible when using NOTIFY [8] and IXFR [7],
-   increasing by reliance on AXFR, and more if you rely on the SOA
-   timing parameters for zone refresh.
-
-   For the verifying clients it is important that data from secured
-   zones can be used to build chains of trust regardless of whether the
-   data came directly from an authoritative server, a caching nameserver
-   or some middle box.  Only by carefully using the available timing
-   parameters can a zone administrator assure that the data necessary
-   for verification can be obtained.
-
-   The responsibility for maintaining the chain of trust is shared by
-   administrators of secured zones in the chain of trust.  This is most
-   obvious in the case of a 'key compromise' when a trade off between
-   maintaining a valid chain of trust and replacing the compromised keys
-   as soon as possible must be made.  Then zone administrators will have
-   to make a trade off, between keeping the chain of trust intact -
-   thereby allowing for attacks with the compromised key - or to
-   deliberately break the chain of trust and making secured sub domains
-   invisible to security aware resolvers.  Also see Section 4.3.
-
-
-3.  Keys Generation and Storage
-
-   This section describes a number of considerations with respect to the
-   security of keys.  It deals with the generation, effectivity period,
-   size and storage of private keys.
-
-3.1.  Zone and Key Signing Keys
-
-   The DNSSEC validation protocol does not distinguish between different
-   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
-   practice operators use Key Signing and Zone Signing Keys and use the
-   so-called (Secure Entry Point) SEP [3] flag to distinguish between
-   them during operations.  The dynamics and considerations are
-   discussed below.
-
-   To make zone re-signing and key rollover procedures easier to
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 6]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   implement, it is possible to use one or more keys as Key Signing Keys
-   (KSK).  These keys will only sign the apex DNSKEY RRSet in a zone.
-   Other keys can be used to sign all the RRSets in a zone and are
-   referred to as Zone Signing Keys (ZSK).  In this document we assume
-   that KSKs are the subset of keys that are used for key exchanges with
-   the parent and potentially for configuration as trusted anchors - the
-   SEP keys.  In this document we assume a one-to-one mapping between
-   KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
-
-3.1.1.  Motivations for the KSK and ZSK Separation
-
-   Differentiating between the KSK and ZSK functions has several
-   advantages:
-
-   o  No parent/child interaction is required when ZSKs are updated.
-   o  The KSK can be made stronger (i.e. using more bits in the key
-      material).  This has little operational impact since it is only
-      used to sign a small fraction of the zone data.  Also the KSK is
-      only used to verify the zone's key set, not for other RRSets in
-      the zone.
-   o  As the KSK is only used to sign a key set, which is most probably
-      updated less frequently than other data in the zone, it can be
-      stored separately from and in a safer location than the ZSK.
-   o  A KSK can have a longer key effectivity period.
-
-   For almost any method of key management and zone signing the KSK is
-   used less frequently than the ZSK.  Once a key set is signed with the
-   KSK all the keys in the key set can be used as ZSK.  If a ZSK is
-   compromised, it can be simply dropped from the key set.  The new key
-   set is then re-signed with the KSK.
-
-   Given the assumption that for KSKs the SEP flag is set, the KSK can
-   be distinguished from a ZSK by examining the flag field in the DNSKEY
-   RR.  If the flag field is an odd number it is a KSK.  If it is an
-   even number it is a ZSK.
-
-   The zone signing key can be used to sign all the data in a zone on a
-   regular basis.  When a zone signing key is to be rolled, no
-   interaction with the parent is needed.  This allows for "Signature
-   Validity Periods" on the order of days.
-
-   The key signing key is only to be used to sign the DNSKEY RRs in a
-   zone.  If a key signing key is to be rolled over, there will be
-   interactions with parties other than the zone administrator.  These
-   can include the registry of the parent zone or administrators of
-   verifying resolvers that have the particular key configured as secure
-   entry points.  Hence, the key effectivity period of these keys can
-   and should be made much longer.  Although, given a long enough key,
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 7]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   the Key Effectivity Period can be on the order of years we suggest
-   planning for a key effectivity of the order of a few months so that a
-   key rollover remains an operational routine.
-
-3.1.2.  KSKs for High Level Zones
-
-   Higher level zones are generally more sensitive than lower level
-   zones.  Anyone controlling or breaking the security of a zone thereby
-   obtains authority over all of its sub domains (except in the case of
-   resolvers that have locally configured the public key of a sub
-   domain, in which case this, and only this, sub domain wouldn't be
-   affected by the compromise of the parent zone).  Therefore, extra
-   care should be taken with high level zones and strong keys should
-   used.
-
-   The root zone is the most critical of all zones.  Someone controlling
-   or compromising the security of the root zone would control the
-   entire DNS name space of all resolvers using that root zone (except
-   in the case of resolvers that have locally configured the public key
-   of a sub domain).  Therefore, the utmost care must be taken in the
-   securing of the root zone.  The strongest and most carefully handled
-   keys should be used.  The root zone private key should always be kept
-   off line.
-
-   Many resolvers will start at a root server for their access to and
-   authentication of DNS data.  Securely updating the trust anchors in
-   an enormous population of resolvers around the world will be
-   extremely difficult.
-
-3.2.  Key Generation
-
-   Careful generation of all keys is a sometimes overlooked but
-   absolutely essential element in any cryptographically secure system.
-   The strongest algorithms used with the longest keys are still of no
-   use if an adversary can guess enough to lower the size of the likely
-   key space so that it can be exhaustively searched.  Technical
-   suggestions for the generation of random keys will be found in RFC
-   4086 [15].  One should carefully assess if the random number
-   generator used during key generation adheres to these suggestions.
-
-   Keys with a long effectivity period are particularly sensitive as
-   they will represent a more valuable target and be subject to attack
-   for a longer time than short period keys.  It is strongly recommended
-   that long term key generation occur off-line in a manner isolated
-   from the network via an air gap or, at a minimum, high level secure
-   hardware.
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 8]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-3.3.  Key Effectivity Period
-
-   For various reasons keys in DNSSEC need to be changed once in a
-   while.  The longer a key is in use, the greater the probability that
-   it will have been compromised through carelessness, accident,
-   espionage, or cryptanalysis.  Furthermore when key rollovers are too
-   rare an event, they will not become part of the operational habit and
-   there is risk that nobody on-site will remember the procedure for
-   rollover when the need is there.
-
-   From a purely operational perspective a reasonable key effectivity
-   period for Key Signing Keys is 13 months, with the intent to replace
-   them after 12 months.  An intended key effectivity period of a month
-   is reasonable for Zone Signing Keys.
-
-   For key sizes that matches these effectivity periods see Section 3.5.
-
-   As argued in Section 3.1.2 securely updating trust anchors will be
-   extremely difficult.  On the other hand the "operational habit"
-   argument does also apply to trust anchor reconfiguration.  If a short
-   key-effectivity period is used and the trust anchor configuration has
-   to be revisited on a regular basis the odds that the configuration
-   tends to be forgotten is smaller.  The trade-off is against a system
-   that is so dynamic that administrators of the validating clients will
-   not be able to follow the modifications.
-
-   Key effectivity periods can be made very short, as in the order of a
-   few minutes.  But when replacing keys one has to take the
-   considerations from Section 4.1 and Section 4.2 into account.
-
-3.4.  Key Algorithm
-
-   There are currently three different types of algorithms that can be
-   used in DNSSEC: RSA, DSA and elliptic curve cryptography.  The latter
-   is fairly new and has yet to be standardized for usage in DNSSEC.
-
-   RSA has been developed in an open and transparent manner.  As the
-   patent on RSA expired in 2000, its use is now also free.
-
-   DSA has been developed by NIST.  The creation of signatures takes
-   roughly the same time as with RSA, but is 10 to 40 times as slow for
-   verification [18].
-
-   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
-   key.  The current known attacks on RSA can be defeated by making your
-   key longer.  As the MD5 hashing algorithm is showing (theoretical)
-   cracks, we recommend the usage of SHA-1.
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 9]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   At the time of publication it is known that the SHA-1 hash has
-   cryptanalysis issues.  There is work in progress on addressing these
-   issues.  We recommend the use of public key algorithms based on
-   hashes stronger than SHA-1, e.g.  SHA-256, as soon as these
-   algorithms are available in protocol specifications (See [20] and
-   [21] ) and implementations.
-
-3.5.  Key Sizes
-
-   When choosing key sizes, zone administrators will need to take into
-   account how long a key will be used, how much data will be signed
-   during the key publication period (See Section 8.10 of [18]) and,
-   optionally, how large the key size of the parent is.  As the chain of
-   trust really is "a chain", there is not much sense in making one of
-   the keys in the chain several times larger then the others.  As
-   always, it's the weakest link that defines the strength of the entire
-   chain.  Also see Section 3.1.1 for a discussion of how keys serving
-   different roles (ZSK v.  KSK) may need different key sizes.
-
-   Generating a key of the correct size is a difficult problem, RFC 3766
-   [14] tries to deal with that problem.  The first part of the
-   selection procedure in Section 1 of the RFC states:
-
-      1. Determine the attack resistance necessary to satisfy the
-         security requirements of the application.  Do this by
-         estimating the minimum number of computer operations that
-         the attacker will be forced to do in order to compromise
-         the security of the system and then take the logarithm base
-         two of that number.  Call that logarithm value "n".
-
-         A 1996 report recommended 90 bits as a good all-around choice
-         for system security.  The 90 bit number should be increased
-         by about 2/3 bit/year, or about 96 bits in 2005.
-
-   [14] goes on to explain how this number "n" can be used to calculate
-   the key sizes in public key cryptography.  This culminated in the
-   table given below (slightly modified for our purpose):
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 10]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-      +-------------+-----------+--------------+
-      | System      |           |              |
-      | requirement | Symmetric | RSA or DSA   |
-      | for attack  | key size  | modulus size |
-      | resistance  | (bits)    | (bits)       |
-      | (bits)      |           |              |
-      +-------------+-----------+--------------+
-      |     70      |     70    |      947     |
-      |     80      |     80    |     1228     |
-      |     90      |     90    |     1553     |
-      |    100      |    100    |     1926     |
-      |    150      |    150    |     4575     |
-      |    200      |    200    |     8719     |
-      |    250      |    250    |    14596     |
-      +-------------+-----------+--------------+
-
-   The key sizes given are rather large.  This is because these keys are
-   resilient against a trillionaire attacker.  Assuming this rich
-   attacker will not attack your key and that the key is rolled over
-   once a year, we come to the following recommendations about KSK
-   sizes; 1024 bits low value domains, 1300 for medium value and 2048
-   for the high value domains.
-
-   Whether a domain is of low, medium, high value depends solely on the
-   views of the zone owner.  One could for instance view leaf nodes in
-   the DNS as of low value and TLDs or the root zone of high value.  The
-   suggested key sizes should be safe for the next 5 years.
-
-   As ZSKs can be rolled over more easily (and thus more often) the key
-   sizes can be made smaller.  But as said in the introduction of this
-   paragraph, making the ZSKs' key sizes too small (in relation to the
-   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
-   size to about 100 bits.
-
-   Note that nobody can see into the future, and that these key sizes
-   are only provided here as a guide.  Further information can be found
-   in [17] and Section 7.5 of [18].  It should be noted though that [17]
-   is already considered overly optimistic about what key sizes are
-   considered safe.
-
-   One final note concerning key sizes.  Larger keys will increase the
-   sizes of the RRSIG and DNSKEY records and will therefore increase the
-   chance of DNS UDP packet overflow.  Also the time it takes to
-   validate and create RRSIGs increases with larger keys, so don't
-   needlessly double your key sizes.
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 11]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-3.6.  Private Key Storage
-
-   It is recommended that, where possible, zone private keys and the
-   zone file master copy that is to be signed, be kept and used in off-
-   line, non-network connected, physically secure machines only.
-   Periodically an application can be run to add authentication to a
-   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
-   transferred.
-
-   When relying on dynamic update to manage a signed zone [10], be aware
-   that at least one private key of the zone will have to reside on the
-   master server.  This key is only as secure as the amount of exposure
-   the server receives to unknown clients and the security of the host.
-   Although not mandatory one could administer the DNS in the following
-   way.  The master that processes the dynamic updates is unavailable
-   from generic hosts on the Internet, it is not listed in the NS RR
-   set, although its name appears in the SOA RRs MNAME field.  The
-   nameservers in the NS RR set are able to receive zone updates through
-   NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism.  This
-   approach is known as the "hidden master" setup.
-
-   The ideal situation is to have a one way information flow to the
-   network to avoid the possibility of tampering from the network.
-   Keeping the zone master file on-line on the network and simply
-   cycling it through an off-line signer does not do this.  The on-line
-   version could still be tampered with if the host it resides on is
-   compromised.  For maximum security, the master copy of the zone file
-   should be off net and should not be updated based on an unsecured
-   network mediated communication.
-
-   In general keeping a zone-file off-line will not be practical and the
-   machines on which zone files are maintained will be connected to a
-   network.  Operators are advised to take security measures to shield
-   unauthorized access to the master copy.
-
-   For dynamically updated secured zones [10] both the master copy and
-   the private key that is used to update signatures on updated RRs will
-   need to be on-line.
-
-
-4.  Signature generation, Key Rollover and Related Policies
-
-4.1.  Time in DNSSEC
-
-   Without DNSSEC all times in DNS are relative.  The SOA fields
-   REFRESH, RETRY and EXPIRATION are timers used to determine the time
-   elapsed after a slave server synchronized with a master server.  The
-   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 12]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   are used to determine how long a forwarder should cache data after it
-   has been fetched from an authoritative server.  By using a signature
-   validity period, DNSSEC introduces the notion of an absolute time in
-   the DNS.  Signatures in DNSSEC have an expiration date after which
-   the signature is marked as invalid and the signed data is to be
-   considered Bogus.
-
-4.1.1.  Time Considerations
-
-   Because of the expiration of signatures, one should consider the
-   following:
-   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
-      of your signature validity period.
-         If the TTL would be of similar order as the signature validity
-         period, then all RRSets fetched during the validity period
-         would be cached until the signature expiration time.  Section
-         7.1 of [4] suggests that "the resolver may use the time
-         remaining before expiration of the signature validity period of
-         a signed RRSet as an upper bound for the TTL".  As a result
-         query load on authoritative servers would peak at signature
-         expiration time, as this is also the time at which records
-         simultaneously expire from caches.
-         To avoid query load peaks we suggest the TTL on all the RRs in
-         your zone to be at least a few times smaller than your
-         signature validity period.
-   o  We suggest the Signature Publication Period to end at least one
-      Maximum Zone TTL duration before the end of the Signature Validity
-      Period.
-         Re-signing a zone shortly before the end of the signature
-         validity period may cause simultaneous expiration of data from
-         caches.  This in turn may lead to peaks in the load on
-         authoritative servers.
-   o  We suggest the minimum zone TTL to be long enough to both fetch
-      and verify all the RRs in the trust chain.  In workshop
-      environments it has been demonstrated [19] that a low TTL (under 5
-      to 10 minutes) caused disruptions because of the following two
-      problems:
-         1.  During validation, some data may expire before the
-         validation is complete.  The validator should be able to keep
-         all data, until is completed.  This applies to all RRs needed
-         to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the
-         final answers i.e. the RRSet that is returned for the initial
-         query.
-         2.  Frequent verification causes load on recursive nameservers.
-         Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
-         caching.  The TTL on those should be relatively long.
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 13]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   o  Slave servers will need to be able to fetch newly signed zones
-      well before the RRSIGs in the zone served by the slave server pass
-      their signature expiration time.
-         When a slave server is out of sync with its master and data in
-         a zone is signed by expired signatures it may be better for the
-         slave server not to give out any answer.
-         Normally a slave server that is not able to contact a master
-         server for an extended period will expire a zone.  When that
-         happens the server will respond differently to queries for that
-         zone.  Some servers issue SERVFAIL while others turn off the
-         'AA' bit in the answers.  The time of expiration is set in the
-         SOA record and is relative to the last successful refresh
-         between the master and the slave server.  There exists no
-         coupling between the signature expiration of RRSIGs in the zone
-         and the expire parameter in the SOA.
-         If the server serves a DNSSEC zone then it may well happen that
-         the signatures expire well before the SOA expiration timer
-         counts down to zero.  It is not possible to completely prevent
-         this from happening by tweaking the SOA parameters.
-         However, the effects can be minimized where the SOA expiration
-         time is equal or shorter than the signature validity period.
-         The consequence of an authoritative server not being able to
-         update a zone, whilst that zone includes expired signatures, is
-         that non-secure resolvers will continue to be able to resolve
-         data served by the particular slave servers while security
-         aware resolvers will experience problems because of answers
-         being marked as Bogus.
-         We suggest the SOA expiration timer being approximately one
-         third or one fourth of the signature validity period.  It will
-         allow problems with transfers from the master server to be
-         noticed before the actual signature times out.
-         We also suggest that operators of nameservers that supply
-         secondary services develop 'watch dogs' to spot upcoming
-         signature expirations in zones they slave, and take appropriate
-         action.
-         When determining the value for the expiration parameter one has
-         to take the following into account: What are the chances that
-         all my secondaries expire the zone; How quickly can I reach an
-         administrator of secondary servers to load a valid zone?  All
-         these arguments are not DNSSEC specific but may influence the
-         choice of your signature validity intervals.
-
-4.2.  Key Rollovers
-
-   A DNSSEC key cannot be used forever (see Section 3.3).  So key
-   rollovers -- or supercessions, as they are sometimes called -- are a
-   fact of life when using DNSSEC.  Zone administrators who are in the
-   process of rolling their keys have to take into account that data
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 14]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   published in previous versions of their zone still lives in caches.
-   When deploying DNSSEC, this becomes an important consideration;
-   ignoring data that may be in caches may lead to loss of service for
-   clients.
-
-   The most pressing example of this occurs when zone material signed
-   with an old key is being validated by a resolver which does not have
-   the old zone key cached.  If the old key is no longer present in the
-   current zone, this validation fails, marking the data Bogus.
-   Alternatively, an attempt could be made to validate data which is
-   signed with a new key against an old key that lives in a local cache,
-   also resulting in data being marked Bogus.
-
-4.2.1.  Zone Signing Key Rollovers
-
-   For zone signing key rollovers there are two ways to make sure that
-   during the rollover data still cached can be verified with the new
-   key sets or newly generated signatures can be verified with the keys
-   still in caches.  One schema, described in Section 4.2.1.2, uses
-   double signatures; the other uses key pre-publication
-   (Section 4.2.1.1).  The pros, cons and recommendations are described
-   in Section 4.2.1.3.
-
-4.2.1.1.  Pre-publish Key Rollover
-
-   This section shows how to perform a ZSK rollover without the need to
-   sign all the data in a zone twice - the so-called "pre-publish
-   rollover".This method has advantages in the case of a key compromise.
-   If the old key is compromised, the new key has already been
-   distributed in the DNS.  The zone administrator is then able to
-   quickly switch to the new key and remove the compromised key from the
-   zone.  Another major advantage is that the zone size does not double,
-   as is the case with the double signature ZSK rollover.  A small
-   "HOWTO" for this kind of rollover can be found in Appendix B.
-
-   Pre-publish Key Rollover involves four stages as follows:
-
-    initial         new DNSKEY       new RRSIGs      DNSKEY removal
-
-    SOA0            SOA1             SOA2            SOA3
-    RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
-
-    DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
-    DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
-                    DNSKEY11         DNSKEY11
-    RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
-    RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 15]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   initial: Initial version of the zone: DNSKEY 1 is the key signing
-      key.  DNSKEY 10 is used to sign all the data of the zone, the zone
-      signing key.
-   new DNSKEY: DNSKEY 11 is introduced into the key set.  Note that no
-      signatures are generated with this key yet, but this does not
-      secure against brute force attacks on the public key.  The minimum
-      duration of this pre-roll phase is the time it takes for the data
-      to propagate to the authoritative servers plus TTL value of the
-      key set.
-   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) DNSKEY 11 is
-      used to sign the data in the zone exclusively (i.e. all the
-      signatures from DNSKEY 10 are removed from the zone).  DNSKEY 10
-      remains published in the key set.  This way data that was loaded
-      into caches from version 1 of the zone can still be verified with
-      key sets fetched from version 2 of the zone.
-      The minimum time that the key set including DNSKEY 10 is to be
-      published is the time that it takes for zone data from the
-      previous version of the zone to expire from old caches i.e. the
-      time it takes for this zone to propagate to all authoritative
-      servers plus the Maximum Zone TTL value of any of the data in the
-      previous version of the zone.
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
-      only containing DNSKEY 1 and DNSKEY 11 is re-signed with the
-      DNSKEY 1.
-
-   The above scheme can be simplified by always publishing the "future"
-   key immediately after the rollover.  The scheme would look as follows
-   (we show two rollovers); the future key is introduced in "new DNSKEY"
-   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
-   (II)":
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 16]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-       initial             new RRSIGs          new DNSKEY
-
-       SOA0                SOA1                SOA2
-       RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
-
-       DNSKEY1             DNSKEY1             DNSKEY1
-       DNSKEY10            DNSKEY10            DNSKEY11
-       DNSKEY11            DNSKEY11            DNSKEY12
-       RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
-       RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
-
-
-       new RRSIGs (II)     new DNSKEY (II)
-
-       SOA3                SOA4
-       RRSIG12(SOA3)       RRSIG12(SOA4)
-
-       DNSKEY1             DNSKEY1
-       DNSKEY11            DNSKEY12
-       DNSKEY12            DNSKEY13
-       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
-       RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
-
-
-   Pre-Publish Key Rollover, showing two rollovers.
-
-   Note that the key introduced in the "new DNSKEY" phase is not used
-   for production yet; the private key can thus be stored in a
-   physically secure manner and does not need to be 'fetched' every time
-   a zone needs to be signed.
-
-4.2.1.2.  Double Signature Zone Signing Key Rollover
-
-   This section shows how to perform a ZSK key rollover using the double
-   zone data signature scheme, aptly named "double sig rollover".
-
-   During the "new DNSKEY" stage the new version of the zone file will
-   need to propagate to all authoritative servers and the data that
-   exists in (distant) caches will need to expire, requiring at least
-   the maximum Zone TTL.
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 17]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   Double Signature Zone Signing Key Rollover involves three stages as
-   follows:
-
-       initial             new DNSKEY         DNSKEY removal
-
-       SOA0                SOA1               SOA2
-       RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
-                           RRSIG11(SOA1)
-
-       DNSKEY1             DNSKEY1            DNSKEY1
-       DNSKEY10            DNSKEY10           DNSKEY11
-                           DNSKEY11
-       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
-       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
-                           RRSIG11(DNSKEY)
-
-   initial: Initial Version of the zone: DNSKEY 1 is the key signing
-      key.  DNSKEY 10 is used to sign all the data of the zone, the zone
-      signing key.
-   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
-      introduced into the key set and all the data in the zone is signed
-      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
-      continue until all data from version 0 of the zone has expired
-      from remote caches.  This will take at least the maximum Zone TTL
-      of version 0 of the zone.
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
-      signatures from DNSKEY 10 are removed from the zone.  The key set,
-      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
-
-   At every instance, RRSIGs from the previous version of the zone can
-   be verified with the DNSKEY RRSet from the current version and the
-   other way around.  The data from the current version can be verified
-   with the data from the previous version of the zone.  The duration of
-   the "new DNSKEY" phase and the period between rollovers should be at
-   least the Maximum Zone TTL.
-
-   Making sure that the "new DNSKEY" phase lasts until the signature
-   expiration time of the data in initial version of the zone is
-   recommended.  This way all caches are cleared of the old signatures.
-   However, this duration could be considerably longer than the Maximum
-   Zone TTL, making the rollover a lengthy procedure.
-
-   Note that in this example we assumed that the zone was not modified
-   during the rollover.  New data can be introduced in the zone as long
-   as it is signed with both keys.
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 18]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-4.2.1.3.  Pros and Cons of the Schemes
-
-   Pre-publish Key Rollover: This rollover does not involve signing the
-      zone data twice.  Instead, before the actual rollover, the new key
-      is published in the key set and thus available for cryptanalysis
-      attacks.  A small disadvantage is that this process requires four
-      steps.  Also the pre-publish scheme involves more parental work
-      when used for KSK rollovers as explained in Section 4.2.3.
-   Double Signature Zone-signing Key Rollover: The drawback of this
-      signing scheme is that during the rollover the number of
-      signatures in your zone doubles, this may be prohibitive if you
-      have very big zones.  An advantage is that it only requires three
-      steps.
-
-4.2.2.  Key Signing Key Rollovers
-
-   For the rollover of a key signing key the same considerations as for
-   the rollover of a zone signing key apply.  However we can use a
-   double signature scheme to guarantee that old data (only the apex key
-   set) in caches can be verified with a new key set and vice versa.
-   Since only the key set is signed with a KSK, zone size considerations
-   do not apply.
-
-
-       initial        new DNSKEY        DS change       DNSKEY removal
-     Parent:
-       SOA0           -------->         SOA1            -------->
-       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
-       DS1            -------->         DS2             -------->
-       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
-
-
-     Child:
-       SOA0            SOA1             -------->       SOA2
-       RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
-                                        -------->
-       DNSKEY1         DNSKEY1          -------->       DNSKEY2
-                       DNSKEY2          -------->
-       DNSKEY10        DNSKEY10         -------->       DNSKEY10
-       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
-                       RRSIG2 (DNSKEY)  -------->
-       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)
-
-   Stages of Deployment for Key Signing Key Rollover.
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 19]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   initial: Initial version of the zone.  The parental DS points to
-      DNSKEY1.  Before the rollover starts the child will have to verify
-      what the TTL is of the DS RR that points to DNSKEY1 - it is needed
-      during the rollover and we refer to the value as TTL_DS.
-   new DNSKEY: During the "new DNSKEY" phase the zone administrator
-      generates a second KSK, DNSKEY2.  The key is provided to the
-      parent and the child will have to wait until a new DS RR has been
-      generated that points to DNSKEY2.  After that DS RR has been
-      published on all servers authoritative for the parent's zone, the
-      zone administrator has to wait at least TTL_DS to make sure that
-      the old DS RR has expired from caches.
-   DS change: The parent replaces DS1 with DS2.
-   DNSKEY removal: DNSKEY1 has been removed.
-
-   The scenario above puts the responsibility for maintaining a valid
-   chain of trust with the child.  It also is based on the premises that
-   the parent only has one DS RR (per algorithm) per zone.  An
-   alternative mechanism has been considered.  Using an established
-   trust relation, the interaction can be performed in-band, and the
-   removal of the keys by the child can possibly be signaled by the
-   parent.  In this mechanism there are periods where there are two DS
-   RRs at the parent.  Since at the moment of writing the protocol for
-   this interaction has not been developed, further discussion is out of
-   scope for this document.
-
-4.2.3.  Difference Between ZSK and KSK Rollovers
-
-   Note that KSK rollovers and ZSK rollovers are different in the sense
-   that a KSK rollover requires interaction with the parent (and
-   possibly replacing of trust anchors) and the ensuing delay while
-   waiting for it.
-
-   A zone key rollover can be handled in two different ways: pre-publish
-   (Section Section 4.2.1.1) and double signature (Section
-   Section 4.2.1.2).
-
-   As the KSK is used to validate the key set and because the KSK is not
-   changed during a ZSK rollover, a cache is able to validate the new
-   key set of the zone.  The pre-publish method would also work for a
-   KSK rollover.  The records that are to be pre-published are the
-   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
-   We first describe the rollover scheme and then indicate these
-   drawbacks.
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 20]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-     initial         new DS           new DNSKEY      DS/DNSKEY removal
-   Parent:
-     SOA0            SOA1             -------->       SOA2
-     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
-     DS1             DS1              -------->       DS2
-                     DS2              -------->
-     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
-
-
-
-   Child:
-     SOA0            -------->        SOA1            SOA1
-     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
-                     -------->
-     DNSKEY1         -------->        DNSKEY2         DNSKEY2
-                     -------->
-     DNSKEY10        -------->        DNSKEY10        DNSKEY10
-     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
-     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
-   Stages of Deployment for a Pre-publish Key Signing Key rollover.
-
-   When the child zone wants to roll it notifies the parent during the
-   "new DS" phase and submits the new key (or the corresponding DS) to
-   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
-   and DNSKEY2 respectively.  During the rollover ("new DNSKEY" phase),
-   which can take place as soon as the new DS set propagated through the
-   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
-   ("DS/DNSKEY removal" phase) it can notify the parent that the old DS
-   record can be deleted.
-
-   The drawbacks of this scheme are that during the "new DS" phase the
-   parent cannot verify the match between the DS2 RR and DNSKEY2 using
-   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
-   "security lame" key (See Section 4.4.3).  Finally the child-parent
-   interaction consists of two steps.  The "double signature" method
-   only needs one interaction.
-
-4.2.4.  Automated Key Rollovers
-
-   As keys must be renewed periodically, there is some motivation to
-   automate the rollover process.  Consider that:
-
-   o  ZSK rollovers are easy to automate as only the child zone is
-      involved.
-   o  A KSK rollover needs interaction between parent and child.  Data
-      exchange is needed to provide the new keys to the parent,
-      consequently, this data must be authenticated and integrity must
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 21]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-      be guaranteed in order to avoid attacks on the rollover.
-
-4.3.  Planning for Emergency Key Rollover
-
-   This section deals with preparation for a possible key compromise.
-   Our advice is to have a documented procedure ready for when a key
-   compromise is suspected or confirmed.
-
-   When the private material of one of your keys is compromised it can
-   be used for as long as a valid trust chain exists.  A trust chain
-   remains intact for:
-   o  as long as a signature over the compromised key in the trust chain
-      is valid,
-   o  as long as a parental DS RR (and signature) points to the
-      compromised key,
-   o  as long as the key is anchored in a resolver and is used as a
-      starting point for validation (this is generally the hardest to
-      update).
-
-   While a trust chain to your compromised key exists, your name-space
-   is vulnerable to abuse by anyone who has obtained illegitimate
-   possession of the key.  Zone operators have to make a trade off if
-   the abuse of the compromised key is worse than having data in caches
-   that cannot be validated.  If the zone operator chooses to break the
-   trust chain to the compromised key, data in caches signed with this
-   key cannot be validated.  However, if the zone administrator chooses
-   to take the path of a regular roll-over, the malicious key holder can
-   spoof data so that it appears to be valid.
-
-4.3.1.  KSK Compromise
-
-   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
-   as long as the compromised KSK is configured as trust anchor or a
-   parental DS points to it.
-
-   A compromised KSK can be used to sign the key set of an attacker's
-   zone.  That zone could be used to poison the DNS.
-
-   Therefore when the KSK has been compromised, the trust anchor or the
-   parental DS, should be replaced as soon as possible.  It is local
-   policy whether to break the trust chain during the emergency
-   rollover.  The trust chain would be broken when the compromised KSK
-   is removed from the child's zone while the parent still has a DS
-   pointing to the compromised KSK (the assumption is that there is only
-   one DS at the parent.  If there are multiple DSs this does not apply
-   -- however the chain of trust of this particular key is broken).
-
-   Note that an attacker's zone still uses the compromised KSK and the
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 22]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   presence of a parental DS would cause the data in this zone to appear
-   as valid.  Removing the compromised key would cause the attacker's
-   zone to appear as valid and the child's zone as Bogus.  Therefore we
-   advise not to remove the KSK before the parent has a DS to a new KSK
-   in place.
-
-4.3.1.1.  Keeping the Chain of Trust Intact
-
-   If we follow this advice the timing of the replacement of the KSK is
-   somewhat critical.  The goal is to remove the compromised KSK as soon
-   as the new DS RR is available at the parent.  And also make sure that
-   the signature made with a new KSK over the key set with the
-   compromised KSK in it expires just after the new DS appears at the
-   parent.  Thus removing the old cruft in one swoop.
-
-   The procedure is as follows:
-   1.  Introduce a new KSK into the key set, keep the compromised KSK in
-       the key set.
-   2.  Sign the key set, with a short validity period.  The validity
-       period should expire shortly after the DS is expected to appear
-       in the parent and the old DSs have expired from caches.
-   3.  Upload the DS for this new key to the parent.
-   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
-       to appear in the authoritative servers and then wait as long as
-       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
-       and modify/extend the expiration time.
-   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
-       key set using your "normal" validity interval.
-
-   An additional danger of a key compromise is that the compromised key
-   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
-   nameserver changes at the parent.  When that happens the domain may
-   be in dispute.  An authenticated out-of-band and secure notify
-   mechanism to contact a parent is needed in this case.
-
-   Note that this is only a problem when the DNSKEY and or DS records
-   are used for authentication at the parent.
-
-4.3.1.2.  Breaking the Chain of Trust
-
-   There are two methods to break the chain of trust.  The first method
-   causes the child zone to appear as 'Bogus' to validating resolvers.
-   The other causes the the child zone to appear as 'insecure'.  These
-   are described below.
-
-   In the method that causes the child zone to appear as 'Bogus' to
-   validating resolvers, the child zone replaces the current KSK with a
-   new one and resigns the key set.  Next it sends the DS of the new key
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 23]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   to the parent.  Only after the parent has placed the new DS in the
-   zone, the child's chain of trust is repaired.
-
-   An alternative method of breaking the chain of trust is by removing
-   the DS RRs from the parent zone altogether.  As a result the child
-   zone would become insecure.
-
-4.3.2.  ZSK Compromise
-
-   Primarily because there is no parental interaction required when a
-   ZSK is compromised, the situation is less severe than with a KSK
-   compromise.  The zone must still be re-signed with a new ZSK as soon
-   as possible.  As this is a local operation and requires no
-   communication between the parent and child this can be achieved
-   fairly quickly.  However, one has to take into account that just as
-   with a normal rollover the immediate disappearance of the old
-   compromised key may lead to verification problems.  Also note that as
-   long as the RRSIG over the compromised ZSK is not expired the zone
-   may be still at risk.
-
-4.3.3.  Compromises of Keys Anchored in Resolvers
-
-   A key can also be pre-configured in resolvers.  For instance, if
-   DNSSEC is successfully deployed the root key may be pre-configured in
-   most security aware resolvers.
-
-   If trust-anchor keys are compromised, the resolvers using these keys
-   should be notified of this fact.  Zone administrators may consider
-   setting up a mailing list to communicate the fact that a SEP key is
-   about to be rolled over.  This communication will of course need to
-   be authenticated e.g. by using digital signatures.
-
-   End-users faced with the task of updating an anchored key should
-   always validate the new key.  New keys should be authenticated out-
-   of-band, for example, looking them up on an SSL secured announcement
-   website.
-
-4.4.  Parental Policies
-
-4.4.1.  Initial Key Exchanges and Parental Policies Considerations
-
-   The initial key exchange is always subject to the policies set by the
-   parent.  When designing a key exchange policy one should take into
-   account that the authentication and authorization mechanisms used
-   during a key exchange should be as strong as the authentication and
-   authorization mechanisms used for the exchange of delegation
-   information between parent and child.  I.e. there is no implicit need
-   in DNSSEC to make the authentication process stronger than it was in
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 24]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   DNS.
-
-   Using the DNS itself as the source for the actual DNSKEY material,
-   with an out-of-band check on the validity of the DNSKEY, has the
-   benefit that it reduces the chances of user error.  A DNSKEY query
-   tool can make use of the SEP bit [3] to select the proper key from a
-   DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is
-   sent.  It can validate the self-signature over a key; thereby
-   verifying the ownership of the private key material.  Fetching the
-   DNSKEY from the DNS ensures that the chain of trust remains intact
-   once the parent publishes the DS RR indicating the child is secure.
-
-   Note: the out-of-band verification is still needed when the key-
-   material is fetched via the DNS.  The parent can never be sure
-   whether the DNSKEY RRs have been spoofed or not.
-
-4.4.2.  Storing Keys or Hashes?
-
-   When designing a registry system one should consider which of the
-   DNSKEYs and/or the corresponding DSs to store.  Since a child zone
-   might wish to have a DS published using a message digest algorithm
-   not yet understood by the registry, the registry can't count on being
-   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
-   that registry systems at least support storing DS records.
-
-   It may also be useful to store DNSKEYs, since having them may help
-   during troubleshooting and, as long as the child's chosen message
-   digest is supported, the overhead of generating DS records from them
-   is minimal.  Having an out-of-band mechanism, such as a registry
-   directory (e.g.  Whois), to find out which keys are used to generate
-   DS Resource Records for specific owners and/or zones may also help
-   with troubleshooting.
-
-   The storage considerations also relate to the design of the customer
-   interface and the method by which data is transferred between
-   registrant and registry; Will the child zone administrator be able to
-   upload DS RRs with unknown hash algorithms or does the interface only
-   allow DNSKEYs?  In the registry-registrar model one can use the
-   DNSSEC EPP protocol extension [16] which allows transfer of DS RRs
-   and optionally DNSKEY RRs.
-
-4.4.3.  Security Lameness
-
-   Security Lameness is defined as what happens when a parent has a DS
-   RR pointing to a non-existing DNSKEY RR.  When this happens the
-   child's zone may be marked as "Bogus" by verifying DNS clients.
-
-   As part of a comprehensive delegation check the parent could, at key
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 25]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   exchange time, verify that the child's key is actually configured in
-   the DNS.  However if a parent does not understand the hashing
-   algorithm used by child the parental checks are limited to only
-   comparing the key id.
-
-   Child zones should be very careful removing DNSKEY material,
-   specifically SEP keys, for which a DS RR exists.
-
-   Once a zone is "security lame", a fix (e.g. removing a DS RR) will
-   take time to propagate through the DNS.
-
-4.4.4.  DS Signature Validity Period
-
-   Since the DS can be replayed as long as it has a valid signature, a
-   short signature validity period over the DS minimizes the time a
-   child is vulnerable in the case of a compromise of the child's
-   KSK(s).  A signature validity period that is too short introduces the
-   possibility that a zone is marked Bogus in case of a configuration
-   error in the signer.  There may not be enough time to fix the
-   problems before signatures expire.  Something as mundane as operator
-   unavailability during weekends shows the need for DS signature
-   validity periods longer than 2 days.  We recommend an absolute
-   minimum for a DS signature validity period of a few days.
-
-   The maximum signature validity period of the DS record depends on how
-   long child zones are willing to be vulnerable after a key compromise.
-   On the other hand shortening the DS signature validity interval
-   increases the operational risk for the parent.  Therefore the parent
-   may have policy to use a signature validity interval that is
-   considerably longer than the child would hope for.
-
-   A compromise between the operational constraints of the parent and
-   minimizing damage for the child may result in a DS signature validity
-   period somewhere between the order of a week to order of months.
-
-   In addition to the signature validity period, which sets a lower
-   bound on the number of times the zone owner will need to sign the
-   zone data and which sets an upper bound to the time a child is
-   vulnerable after key compromise, there is the TTL value on the DS
-   RRs.  Shortening the TTL means that the authoritative servers will
-   see more queries.  But on the other hand, a short TTL lowers the
-   persistence of DS RRSets in caches thereby increases the speed with
-   which updated DS RRSets propagate through the DNS.
-
-
-5.  IANA Considerations
-
-   This overview document introduces no new IANA considerations.
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 26]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-6.  Security Considerations
-
-   DNSSEC adds data integrity to the DNS.  This document tries to assess
-   the operational considerations to maintain a stable and secure DNSSEC
-   service.  Not taking into account the 'data propagation' properties
-   in the DNS will cause validation failures and may make secured zones
-   unavailable to security aware resolvers.
-
-
-7.  Acknowledgments
-
-   Most of the ideas in this draft were the result of collective efforts
-   during workshops, discussions and try outs.
-
-   At the risk of forgetting individuals who were the original
-   contributors of the ideas we would like to acknowledge people who
-   were actively involved in the compilation of this document.  In
-   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
-   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
-   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
-   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch.
-
-   Some material in this document has been copied from RFC 2541 [12].
-
-   Mike StJohns designed the key exchange between parent and child
-   mentioned in the last paragraph of Section 4.2.2
-
-   Section 4.2.4 was supplied by G. Guette and O. Courtay.
-
-   Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
-   the spelling and style issues.
-
-   Kolkman and Gieben take the blame for introducing all miscakes(SIC).
-
-   Kolkman was employed by the RIPE NCC while working on this document.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 27]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
-        RFC 3757, May 2004.
-
-   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [6]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-8.2.  Informative References
-
-   [7]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-         August 1996.
-
-   [8]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
-         (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [10]  Eastlake, D., "Secure Domain Name System Dynamic Update",
-         RFC 2137, April 1997.
-
-   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-         RFC 2308, March 1998.
-
-   [12]  Eastlake, D., "DNS Security Operational Considerations",
-         RFC 2541, March 1999.
-
-   [13]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-         RFC 3658, December 2003.
-
-   [14]  Orman, H. and P. Hoffman, "Determining Strengths For Public
-         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
-         April 2004.
-
-   [15]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-         Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [16]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
-         Mapping for the Extensible Provisioning Protocol (EPP)",
-         RFC 4310, December 2005.
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 28]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   [17]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", The Journal of Cryptology 14 (255-293), 2001.
-
-   [18]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
-         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
-         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
-         1996.
-
-   [19]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
-
-   [20]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
-         Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt
-         (work in progress), January 2006.
-
-   [21]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
-         Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt
-         (work in progress), January 2006.
-
-
-Appendix A.  Terminology
-
-   In this document there is some jargon used that is defined in other
-   documents.  In most cases we have not copied the text from the
-   documents defining the terms but given a more elaborate explanation
-   of the meaning.  Note that these explanations should not be seen as
-   authoritative.
-
-   Anchored Key: A DNSKEY configured in resolvers around the globe.
-      This key is hard to update, hence the term anchored.
-   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
-      "Bogus" when a signature of a RRSet does not validate against a
-      DNSKEY.
-   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
-      exclusively for signing the apex key set.  The fact that a key is
-      a KSK is only relevant to the signing tool.
-   Key size: The term 'key size' can be substituted by 'modulus size'
-      throughout the document.  It is mathematically more correct to use
-      modulus size, but as this is a document directed at operators we
-      feel more at ease with the term key size.
-   Private and Public Keys: DNSSEC secures the DNS through the use of
-      public key cryptography.  Public key cryptography is based on the
-      existence of two (mathematically related) keys, a public key and a
-      private key.  The public keys are published in the DNS by use of
-      the DNSKEY Resource Record (DNSKEY RR).  Private keys should
-      remain private.
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 29]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   Key Rollover: A key rollover (also called key supercession in some
-      environments) is the act of replacing one key pair by another at
-      the end of a key effectivity period.
-   Secure Entry Point key or SEP Key: A KSK that has a parental DS
-      record pointing to it or is configured as a trust anchor.
-      Although not required by the protocol we recommend that the SEP
-      flag [3] is set on these keys.
-   Self-signature: This is only applies to signatures over DNSKEYs; a
-      signature made with DNSKEY x, over DNSKEY x is called a self-
-      signature.  Note: without further information self-signatures
-      convey no trust, they are useful to check the authenticity of the
-      DNSKEY, i.e. they can be used as a hash.
-   Singing the Zone File: The term used for the event where an
-      administrator joyfully signs its zone file while producing melodic
-      sound patterns.
-   Signer: The system that has access to the private key material and
-      signs the Resource Record sets in a zone.  A signer may be
-      configured to sign only parts of the zone e.g. only those RRSets
-      for which existing signatures are about to expire.
-   Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is
-      used for signing all data in a zone.  The fact that a key is a ZSK
-      is only relevant to the signing tool.
-   Zone Administrator: The 'role' that is responsible for signing a zone
-      and publishing it on the primary authoritative server.
-
-
-Appendix B.  Zone Signing Key Rollover Howto
-
-   Using the pre-published signature scheme and the most conservative
-   method to assure oneself that data does not live in caches, here
-   follows the "HOWTO".
-   Step 0: The preparation: Create two keys and publish both in your key
-      set.  Mark one of the keys as "active" and the other as
-      "published".  Use the "active" key for signing your zone data.
-      Store the private part of the "published" key, preferably off-
-      line.
-      The protocol does not provide for attributes to mark a key as
-      active or published.  This is something you have to do on your
-      own, through the use of a notebook or key management tool.
-   Step 1: Determine expiration: At the beginning of the rollover make a
-      note of the highest expiration time of signatures in your zone
-      file created with the current key marked as "active".
-      Wait until the expiration time marked in Step 1 has passed
-   Step 2: Then start using the key that was marked as "published" to
-      sign your data i.e. mark it as "active".  Stop using the key that
-      was marked as "active", mark it as "rolled".
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 30]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   Step 3: It is safe to engage in a new rollover (Step 1) after at
-      least one "signature validity period".
-
-
-Appendix C.  Typographic Conventions
-
-   The following typographic conventions are used in this document:
-   Key notation: A key is denoted by DNSKEYx, where x is a number or an
-      identifier, x could be thought of as the key id.
-   RRSet notations: RRs are only denoted by the type.  All other
-      information - owner, class, rdata and TTL - is left out.  Thus:
-      "example.com 3600 IN A 192.0.2.1" is reduced to "A".  RRSets are a
-      list of RRs.  A example of this would be: "A1, A2", specifying the
-      RRSet containing two "A" records.  This could again be abbreviated
-      to just "A".
-   Signature notation: Signatures are denoted as RRSIGx(RRSet), which
-      means that RRSet is signed with DNSKEYx.
-   Zone representation: Using the above notation we have simplified the
-      representation of a signed zone by leaving out all unnecessary
-      details such as the names and by representing all data by "SOAx"
-   SOA representation: SOAs are represented as SOAx, where x is the
-      serial number.
-   Using this notation the following signed zone:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 31]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
-                            2006022100   ; serial
-                            86400        ; refresh (  24 hours)
-                            7200         ; retry   (   2 hours)
-                            3600000      ; expire  (1000 hours)
-                            28800 )      ; minimum (   8 hours)
-                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  cmL62SI6iAX46xGNQAdQ... )
-                     86400  NS      a.iana-servers.net.
-                     86400  NS      b.iana-servers.net.
-                     86400  RRSIG   NS 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  SO5epiJei19AjXoUpFnQ ... )
-                     86400  DNSKEY  256 3 5 (
-                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
-                     86400  DNSKEY  257 3 5 (
-                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  J4zCe8QX4tXVGjV4e1r9... )
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 15 example.net.
-                                  keVDCOpsSeDReyV6O... )
-                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  obj3HEp1GjnmhRjX... )
-   a.example.net.    86400  IN TXT  "A label"
-                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  IkDMlRdYLmXH7QJnuF3v... )
-                     86400  NSEC    b.example.com. TXT RRSIG NSEC
-                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  bZMjoZ3bHjnEz0nIsPMM... )
-                     ...
-
-   is reduced to the following representation:
-
-       SOA2006022100
-       RRSIG14(SOA2006022100)
-       DNSKEY14
-       DNSKEY15
-
-       RRSIG14(KEY)
-       RRSIG15(KEY)
-
-   The rest of the zone data has the same signature as the SOA record,
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 32]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   i.e a RRSIG created with DNSKEY 14.
-
-
-Appendix D.  Document Details and Changes
-
-   This section is to be removed by the RFC editor if and when the
-   document is published.
-
-   $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14
-   2005/03/21 15:51:41 dnssec Exp $
-
-D.1.  draft-ietf-dnsop-dnssec-operational-practices-00
-
-   Submission as working group document.  This document is a modified
-   and updated version of draft-kolkman-dnssec-operational-practices-00.
-
-D.2.  draft-ietf-dnsop-dnssec-operational-practices-01
-
-   changed the definition of "Bogus" to reflect the one in the protocol
-   draft.
-
-   Bad to Bogus
-
-   Style and spelling corrections
-
-   KSK - SEP mapping made explicit.
-
-   Updates from Sam Weiler added
-
-D.3.  draft-ietf-dnsop-dnssec-operational-practices-02
-
-   Style and errors corrected.
-
-   Added Automatic rollover requirements from I-D.ietf-dnsop-key-
-   rollover-requirements.
-
-D.4.  draft-ietf-dnsop-dnssec-operational-practices-03
-
-   Added the definition of Key effectivity period and used that term
-   instead of Key validity period.
-
-   Modified the order of the sections, based on a suggestion by Rip
-   Loomis.
-
-   Included parts from RFC 2541 [12].  Most of its ground was already
-   covered.  This document obsoletes RFC 2541 [12].  Section 3.1.2
-   deserves some review as it in contrast to RFC 2541 does _not_ give
-   recomendations about root-zone keys.
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 33]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   added a paragraph to Section 4.4.4
-
-D.5.  draft-ietf-dnsop-dnssec-operational-practices-04
-
-   Somewhat more details added about the pre-publish KSK rollover.  Also
-   moved that subsection down a bit.
-
-   Editorial and content nits that came in during wg last call were
-   fixed.
-
-D.6.  draft-ietf-dnsop-dnssec-operational-practices-05
-
-   Applied some another set of comments that came in _after_ the the
-   WGLC.
-
-   Applied comments from Hilarie Orman and made a referece to RFC 3766.
-   Deleted of a lot of key length discussion and took over the
-   recommendations from RFC 3766.
-
-   Reworked all the heading of the rollover figures
-
-D.7.  draft-ietf-dnsop-dnssec-operational-practices-06
-
-   One comment from Scott Rose applied.
-
-   Marcos Sanz gave a lots of editorial nits.  Almost all are
-   incorporated.
-
-D.8.  draft-ietf-dnsop-dnssec-operational-practices-07
-
-   Peter Koch's comments applied.
-
-   SHA-1/SHA-256 remarks added
-
-D.9.  draft-ietf-dnsop-dnssec-operational-practices-08
-
-   IESG comments applied.  Added headers and some captions to the tables
-   and applied all the nits.
-
-   IESG DISCUSS comments applied
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 34]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-Authors' Addresses
-
-   Olaf M. Kolkman
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098 VA
-   The Netherlands
-
-   Email: olaf@nlnetlabs.nl
-   URI:   http://www.nlnetlabs.nl
-
-
-   Miek Gieben
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098 VA
-   The Netherlands
-
-   Email: miek@nlnetlabs.nl
-   URI:   http://www.nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 35]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 36]
-
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
deleted file mode 100644
index bf2afcdfb3ac..000000000000
--- a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
+++ /dev/null
@@ -1,1848 +0,0 @@
-
-
-
-DNS Operations WG                                          J. Jeong, Ed.
-Internet-Draft                              ETRI/University of Minnesota
-Expires: November 6, 2005                                    May 5, 2005
-
-
-      IPv6 Host Configuration of DNS Server Information Approaches
-             draft-ietf-dnsop-ipv6-dns-configuration-06.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 6, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes three approaches for IPv6 recursive DNS
-   server address configuration.  It details the operational attributes
-   of three solutions: RA option, DHCPv6 option, and Well-known anycast
-   addresses for recursive DNS servers.  Additionally, it suggests the
-   deployment scenarios in four kinds of networks, such as ISP,
-   Enterprise, 3GPP, and Unmanaged networks, considering multi-solution
-   resolution.  Therefore, this document will give the audience a
-
-
-
-Jeong                   Expires November 6, 2005                [Page 1]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   guideline for IPv6 host DNS configuration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 2]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.  IPv6 DNS Configuration Approaches  . . . . . . . . . . . . . .  7
-     3.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . .  7
-       3.1.1   Advantages . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.2   Disadvantages  . . . . . . . . . . . . . . . . . . . .  8
-       3.1.3   Observations . . . . . . . . . . . . . . . . . . . . .  9
-     3.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . .  9
-       3.2.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 11
-       3.2.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 12
-       3.2.3   Observations . . . . . . . . . . . . . . . . . . . . . 12
-     3.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 12
-       3.3.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 13
-       3.3.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 14
-       3.3.3   Observations . . . . . . . . . . . . . . . . . . . . . 14
-   4.  Interworking among IPv6 DNS Configuration Approaches . . . . . 15
-   5.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
-     5.1   ISP Network  . . . . . . . . . . . . . . . . . . . . . . . 16
-       5.1.1   RA Option Approach . . . . . . . . . . . . . . . . . . 16
-       5.1.2   DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17
-       5.1.3   Well-known Anycast Addresses Approach  . . . . . . . . 17
-     5.2   Enterprise Network . . . . . . . . . . . . . . . . . . . . 17
-     5.3   3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18
-       5.3.1   Currently Available Mechanisms and Recommendations . . 19
-       5.3.2   RA Extension . . . . . . . . . . . . . . . . . . . . . 19
-       5.3.3   Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20
-       5.3.4   Well-known Addresses . . . . . . . . . . . . . . . . . 21
-       5.3.5   Recommendations  . . . . . . . . . . . . . . . . . . . 21
-     5.4   Unmanaged Network  . . . . . . . . . . . . . . . . . . . . 22
-       5.4.1   Case A: Gateway does not provide IPv6 at all . . . . . 22
-       5.4.2   Case B: A dual-stack gateway connected to a
-               dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22
-       5.4.3   Case C: A dual-stack gateway connected to an
-               IPv4-only ISP  . . . . . . . . . . . . . . . . . . . . 22
-       5.4.4   Case D: A gateway connected to an IPv6-only ISP  . . . 23
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
-     6.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . . 25
-     6.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . . 25
-     6.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 25
-   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
-     9.1   Normative References . . . . . . . . . . . . . . . . . . . 29
-     9.2   Informative References . . . . . . . . . . . . . . . . . . 29
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
-   A.  Link-layer Multicast Acknowledgements for RA Option  . . . . . 32
-
-
-
-Jeong                   Expires November 6, 2005                [Page 3]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-       Intellectual Property and Copyright Statements . . . . . . . . 33
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 4]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-1.  Introduction
-
-   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
-   Autoconfiguration provide the ways to configure either fixed or
-   mobile nodes with one or more IPv6 addresses, default routes and some
-   other parameters [3][4].  To support the access to additional
-   services in the Internet that are identified by a DNS name, such as a
-   web server, the configuration of at least one recursive DNS server is
-   also needed for DNS name resolution.
-
-   This document describes three approaches of recursive DNS server
-   address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
-   option [5]-[7], and (c) Well-known anycast addresses for recursive
-   DNS servers [9].  Also, it suggests the applicable scenarios for four
-   kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP
-   network, and (d) Unmanaged network.
-
-   This document is just an analysis of each possible approach, and does
-   not make any recommendation on a particular one or on a combination
-   of particular ones.  Some approaches may even not be adopted at all
-   as a result of further discussion.
-
-   Therefore, the objective of this document is to help the audience
-   select the approaches suitable for IPv6 host configuration of
-   recursive DNS servers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 5]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-2.  Terminology
-
-   This document uses the terminology described in [3]-[9].  In
-   addition, a new term is defined below:
-
-   o  Recursive DNS Server (RDNSS): A Recursive DNS Server is a name
-      server that offers the recursive service of DNS name resolution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 6]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-3.  IPv6 DNS Configuration Approaches
-
-   In this section, the operational attributes of the three solutions
-   are described in detail.
-
-3.1  RA Option
-
-   The RA approach is to define a new ND option called the RDNSS option
-   that contains a recursive DNS server address.  Existing ND transport
-   mechanisms (i.e., advertisements and solicitations) are used.  This
-   works in the same way that nodes learn about routers and prefixes.
-   An IPv6 host can configure the IPv6 addresses of one or more RDNSSes
-   via RA message periodically sent by a router or solicited by a Router
-   Solicitation (RS) [8].
-
-   This approach needs RDNSS information to be configured in the routers
-   doing the advertisements.  The configuration of RDNSS addresses can
-   be performed manually by an operator or other ways, such as automatic
-   configuration through a DHCPv6 client running on the router.  When
-   advertising more than one RDNSS option, an RA message includes as
-   many RDNSS options as RDNSSes.
-
-   Through the ND protocol and RDNSS option along with a prefix
-   information option, an IPv6 host can perform its network
-   configuration of its IPv6 address and RDNSS simultaneously [3][4].
-   The RA option for RDNSS can be used on any network that supports the
-   use of ND.
-
-   However, it is worth noting that some link layers, such as Wireless
-   LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast,
-   which means that they cannot guarantee the timely delivery of RA
-   messages [25]-[28].  This is discussed in Appendix A.
-
-   The RA approach is useful in some mobile environments where the
-   addresses of the RDNSSes are changing because the RA option includes
-   a lifetime field that allows client to use RDNSSes nearer to the
-   client.  This can be configured to a value that will require the
-   client to time out the entry and switch over to another RDNSS address
-   [8].  However, from the viewpoint of implementation, the lifetime
-   field would seem to make matters a bit more complex.  Instead of just
-   writing to a DNS configuration file, such as resolv.conf for the list
-   of RDNSS addresses, we have to have a daemon around (or a program
-   that is called at the defined intervals) that keeps monitoring the
-   lifetime of RDNSSes all the time.
-
-   The preference value of RDNSS, included in the RDNSS option, allows
-   IPv6 hosts to select primary RDNSS among several RDNSSes; this can be
-   used for the load balancing of RDNSSes [8].
-
-
-
-Jeong                   Expires November 6, 2005                [Page 7]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-3.1.1  Advantages
-
-   The RA option for RDNSS has a number of advantages.  These include:
-
-   1.  The RA option is an extension of existing ND/Autoconfig
-       mechanisms [3][4], and does not require a change in the base ND
-       protocol.
-
-   2.  This approach, like ND, works well on a variety of link types
-       including point-to-point links, point-to-multipoint, and
-       multipoint-to-multipoint (i.e., Ethernet LANs), etc.  RFC 2461
-       [3] states, however, that there may be some link types on which
-       ND is not feasible; on such links, some other mechanisms will be
-       needed for DNS configuration.
-
-   3.  All of the information a host needs to run the basic Internet
-       applications such as the email, web, ftp, etc., can be obtained
-       with the addition of this option to ND and address
-       autoconfiguration.  The use of a single mechanism is more
-       reliable and easier to provide than when the RDNSS information is
-       learned via another protocol mechanism.  Debugging problems when
-       multiple protocol mechanisms are being used is harder and much
-       more complex.
-
-   4.  This mechanism works over a broad range of scenarios and
-       leverages IPv6 ND.  This works well on links that support
-       broadcast reliably (e.g., Ethernet LANs) but not necessarily on
-       other links (e.g., Wireless LANs): Refer to Appendix A.  Also,
-       this works well on links that are high performance (e.g.,
-       Ethernet LANs) and low performance (e.g., Cellular networks).  In
-       the latter case, by combining the RDNSS information with the
-       other information in the RA, the host can learn all of the
-       information needed to use most Internet applications, such as the
-       web in a single packet.  This not only saves bandwidth where this
-       is an issue, but also minimizes the delay needed to learn the
-       RDNSS information.
-
-   5.  The RA approach could be used as a model for other similar types
-       of configuration information.  New RA options for other server
-       addresses, such as NTP server address, that are common to all
-       clients on a subnet would be easy to define.
-
-
-3.1.2  Disadvantages
-
-   1.  ND is mostly implemented in the kernel of operating system.
-       Therefore, if ND supports the configuration of some additional
-       services, such as DNS servers, ND should be extended in the
-
-
-
-Jeong                   Expires November 6, 2005                [Page 8]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-       kernel, and complemented by a user-land process.  DHCPv6,
-       however, has more flexibility for the extension of service
-       discovery because it is an application layer protocol.
-
-   2.  The current ND framework should be modified to facilitate the
-       synchronization between another ND cache for RDNSSes in the
-       kernel space and the DNS configuration file in the user space.
-       Because it is unacceptable to write and rewrite to the DNS
-       configuration file (e.g., resolv.conf) from the kernel, another
-       approach is needed.  One simple approach to solve this is to have
-       a daemon listening to what the kernel conveys, and to have the
-       daemon do these steps, but such a daemon is not needed with the
-       current ND framework.
-
-   3.  It is necessary to configure RDNSS addresses at least at one
-       router on every link where this information needs to be
-       configured via the RA option.
-
-
-3.1.3  Observations
-
-   The proposed RDNSS RA option along with the IPv6 ND and
-   Autoconfiguration allows a host to obtain all of the information it
-   needs to access the basic Internet services like the web, email, ftp,
-   etc.  This is preferable in the environments where hosts use RAs to
-   autoconfigure their addresses and all the hosts on the subnet share
-   the same router and server addresses.  If the configuration
-   information can be obtained from a single mechanism, it is preferable
-   because it does not add additional delay, and it uses a minimum of
-   bandwidth.  The environments like this include the homes, public
-   cellular networks, and enterprise environments where no per host
-   configuration is needed, but exclude public WLAN hot spots.
-
-   DHCPv6 is preferable where it is being used for address configuration
-   and if there is a need for host specific configuration [5]-[7].  The
-   environments like this are most likely to be the enterprise
-   environments where the local administration chooses to have per host
-   configuration control.
-
-Note
-
-   The observation section is based on what the proponents of each
-   approach think makes a good overall solution.
-
-3.2  DHCPv6 Option
-
-   DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
-   which a host can obtain a list of IP addresses of recursive DNS
-
-
-
-Jeong                   Expires November 6, 2005                [Page 9]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   servers [7].  The DNS Recursive Name Server option carries a list of
-   IPv6 addresses of RDNSSes to which the host may send DNS queries.
-   The DNS servers are listed in the order of preference for use by the
-   DNS resolver on the host.
-
-   The DNS Recursive Name Server option can be carried in any DHCPv6
-   Reply message, in response to either a Request or an Information
-   request message.  Thus, the DNS Recursive Name Server option can be
-   used either when DHCPv6 is used for address assignment, or when
-   DHCPv6 is used only for other configuration information as stateless
-   DHCPv6 [6].
-
-   Stateless DHCPv6 can be deployed either using DHCPv6 servers running
-   on general-purpose computers, or on router hardware.  Several router
-   vendors currently implement stateless DHCPv6 servers.  Deploying
-   stateless DHCPv6 in routers has the advantage that no special
-   hardware is required, and should work well for networks where DHCPv6
-   is needed for very straightforward configuration of network devices.
-
-   However, routers can also act as DHCPv6 relay agents.  In this case,
-   the DHCPv6 server need not be on the router - it can be on a general
-   purpose computer.  This has the potential to give the operator of the
-   DHCPv6 server more flexibility in how the DHCPv6 server responds to
-   individual clients - clients can easily be given different
-   configuration information based on their identity, or for any other
-   reason.  Nothing precludes adding this flexibility to a router, but
-   generally in current practice, DHCP servers running on general-
-   purpose hosts tend to have more configuration options than those that
-   are embedded in routers.
-
-   DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
-   clients that use a stateful configuration assignment.  To do this,
-   the DHCPv6 server sends a Reconfigure message to the client.  The
-   client validates the Reconfigure message, and then contacts the
-   DHCPv6 server to obtain updated configuration information.  Using
-   this mechanism, it is currently possible to propagate new
-   configuration information to DHCPv6 clients as this information
-   changes.
-
-   The DHC Working Group is currently studying an additional mechanism
-   through which configuration information, including the list of
-   RDNSSes, can be updated.  The lifetime option for DHCPv6 [10] assigns
-   a lifetime to configuration information obtained through DHCPv6.  At
-   the expiration of the lifetime, the host contacts the DHCPv6 server
-   to obtain updated configuration information, including the list of
-   RDNSSes.  This lifetime gives the network administrator another
-   mechanism to configure hosts with new RDNSSes by controlling the time
-   at which the host refreshes the list.
-
-
-
-Jeong                   Expires November 6, 2005               [Page 10]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   The DHC Working Group has also discussed the possibility of defining
-   an extension to DHCPv6 that would allow the use of multicast to
-   provide configuration information to multiple hosts with a single
-   DHCPv6 message.  Because of the lack of deployment experience, the WG
-   has deferred consideration of multicast DHCPv6 configuration at this
-   time.  Experience with DHCPv4 has not identified a requirement for
-   multicast message delivery, even in large service provider networks
-   with tens of thousands of hosts that may initiate a DHCPv4 message
-   exchange simultaneously.
-
-3.2.1  Advantages
-
-   The DHCPv6 option for RDNSS has a number of advantages.  These
-   include:
-
-   1.  DHCPv6 currently provides a general mechanism for conveying
-       network configuration information to clients.  So configuring
-       DHCPv6 servers allows the network administrator to configure
-       RDNSSes along with the addresses of other network services, as
-       well as location-specific information like time zones.
-
-   2.  As a consequence, when the network administrator goes to
-       configure DHCPv6, all the configuration information can be
-       managed through a single service, typically with a single user
-       interface and a single configuration database.
-
-   3.  DHCPv6 allows for the configuration of a host with information
-       specific to that host, so that hosts on the same link can be
-       configured with different RDNSSes as well as with other
-       configuration information.  This capability is important in some
-       network deployments such as service provider networks or WiFi hot
-       spots.
-
-   4.  A mechanism exists for extending DHCPv6 to support the
-       transmission of additional configuration that has not yet been
-       anticipated.
-
-   5.  Hosts that require other configuration information such as the
-       addresses of SIP servers and NTP servers are likely to need
-       DHCPv6 for other configuration information.
-
-   6.  The specification for configuration of RDNSSes through DHCPv6 is
-       available as an RFC.  No new protocol extensions such as new
-       options are necessary.
-
-   7.  Interoperability among independent implementations has been
-       demonstrated.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 11]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-3.2.2  Disadvantages
-
-   The DHCPv6 option for RDNSS has a few disadvantages.  These include:
-
-   1.  Update currently requires message from server (however, see
-       [10]).
-
-   2.  Because DNS information is not contained in RA messages, the host
-       must receive two messages from the router, and must transmit at
-       least one message to the router.  On networks where bandwidth is
-       at a premium, this is a disadvantage, although on most networks
-       it is not a practical concern.
-
-   3.  Increased latency for initial configuration - in addition to
-       waiting for an RA message, the client must now exchange packets
-       with a DHCPv6 server; even if it is locally installed on a
-       router, this will slightly extend the time required to configure
-       the client.  For clients that are moving rapidly from one network
-       to another, this will be a disadvantage.
-
-
-3.2.3  Observations
-
-   In the general case, on general-purpose networks, stateless DHCPv6
-   provides significant advantages and no significant disadvantages.
-   Even in the case where bandwidth is at a premium and low latency is
-   desired, if hosts require other configuration information in addition
-   to a list of RDNSSes or if hosts must be configured selectively,
-   those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
-   name server option will be advantageous.
-
-   However, we are aware of some applications where it would be
-   preferable to put the RDNSS information into an RA packet; for
-   example, on a cell phone network, where bandwidth is at a premium and
-   extremely low latency is desired.  The final DNS configuration draft
-   should be written so as to allow these special applications to be
-   handled using DNS information in the RA packet.
-
-3.3  Well-known Anycast Addresses
-
-   Anycast uses the same routing system as unicast [11].  However,
-   administrative entities are local ones.  The local entities may
-   accept unicast routes (including default routes) to anycast servers
-   from adjacent entities.  The administrative entities should not
-   advertise their peers routes to their internal anycast servers, if
-   they want to prohibit external access from some peers to the servers.
-   If some advertisement is inevitable (such as the case with default
-   routes), the packets to the servers should be blocked at the boundary
-
-
-
-Jeong                   Expires November 6, 2005               [Page 12]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   of the entities.  Thus, for this anycast, not only unicast routing
-   but also unicast ND protocols can be used as is.
-
-   First of all, the well-known anycast addresses approach is much
-   different from that discussed at IPv6 Working Group in the past [9].
-   It should be noted that "anycast" in this memo is simpler than that
-   of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be
-   prohibited to have multiple servers on a single link sharing an
-   anycast address.  That is, on a link, an anycast address is assumed
-   to be unique.  DNS clients today already have redundancy by having
-   multiple well-known anycast addresses configured as RDNSS addresses.
-   There is no point in having multiple RDNSSes sharing an anycast
-   address on a single link.
-
-   The approach with well-known anycast addresses is to set multiple
-   well-known anycast addresses in clients' resolver configuration files
-   from the beginning, say, as factory default.  Thus, there is no
-   transport mechanism and no packet format [9].
-
-   An anycast address is an address shared by multiple servers (in this
-   case, the servers are RDNSSes).  A request from a client to the
-   anycast address is routed to a server selected by the routing system.
-   However, it is a bad idea to mandate "site" boundary on anycast
-   addresses, because most users just do not have their own servers and
-   want to access their ISPs' across their site boundaries.  Larger
-   sites may also depend on their ISPs or may have their own RDNSSes
-   within "site" boundaries.
-
-3.3.1  Advantages
-
-   The basic advantage of the well-known addresses approach is that it
-   uses no transport mechanism.  Thus,
-
-   1.  There is no delay to get the response and no further delay by
-       packet losses.
-
-   2.  The approach can be combined with any other configuration
-       mechanisms, such as the RA-based approach and DHCP based
-       approach, as well as the factory default configuration.
-
-   3.  The approach works over any environment where DNS works.
-
-   Another advantage is that the approach needs to configure DNS servers
-   as a router, but nothing else.  Considering that DNS servers do need
-   configuration, the amount of overall configuration effort is
-   proportional to the number of the DNS servers and scales linearly.
-   It should be noted that, in the simplest case where a subscriber to
-   an ISP does not have any DNS server, the subscriber naturally
-
-
-
-Jeong                   Expires November 6, 2005               [Page 13]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   accesses DNS servers of the ISP even though the subscriber and the
-   ISP do nothing and there is no protocol to exchange DNS server
-   information between the subscriber and the ISP.
-
-3.3.2  Disadvantages
-
-   Well-known anycast addresses approach requires that DNS servers (or
-   routers near it as a proxy) act as routers to advertise their anycast
-   addresses to the routing system, which requires some configuration
-   (see the last paragraph of the previous section on the scalability of
-   the effort).
-
-3.3.3  Observations
-
-   If other approaches are used in addition, the well-known anycast
-   addresses should also be set in RA or DHCP configuration files to
-   reduce the configuration effort of users.
-
-   The redundancy by multiple RDNSSes is better provided by multiple
-   servers having different anycast addresses than multiple servers
-   sharing the same anycast address because the former approach allows
-   stale servers to still generate routes to their anycast addresses.
-   Thus, in a routing domain (or domains sharing DNS servers), there
-   will be only one server having an anycast address unless the domain
-   is so large that load distribution is necessary.
-
-   Small ISPs will operate one RDNSS at each anycast address which is
-   shared by all the subscribers.  Large ISPs may operate multiple
-   RDNSSes at each anycast address to distribute and reduce load, where
-   the boundary between RDNSSes may be fixed (redundancy is still
-   provided by multiple addresses) or change dynamically.  DNS packets
-   with the well-known anycast addresses are not expected (though not
-   prohibited) to cross ISP boundaries, as ISPs are expected to be able
-   to take care of themselves.
-
-   Because "anycast" in this memo is simpler than that of RFC 1546 [11]
-   and RFC 3513 [12] where it is assumed to be administratively
-   prohibited to have multiple servers on a single link sharing an
-   anycast address, anycast in this memo should be implemented as
-   UNICAST of RFC 2461 [3] and RFC 3513 [12].  As a result, ND-related
-   instability disappears.  Thus, anycast in well-known anycast
-   addresses approach can and should use the anycast address as a source
-   unicast (according to RFC 3513 [12]) address of packets of UDP and
-   TCP responses.  With TCP, if a route flips and packets to an anycast
-   address are routed to a new server, it is expected that the flip is
-   detected by ICMP or sequence number inconsistency and the TCP
-   connection is reset and retried.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 14]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-4.  Interworking among IPv6 DNS Configuration Approaches
-
-   Three approaches can work together for IPv6 host configuration of
-   RDNSS.  This section shows a consideration on how these approaches
-   can interwork each other.
-
-   For ordering between RA and DHCP approaches, the O (Other stateful
-   configuration) flag in RA message can be used [8][32].  If no RDNSS
-   option is included, an IPv6 host may perform DNS configuration
-   through DHCPv6 [5]-[7] regardless of whether the O flag is set or
-   not.
-
-   The well-known anycast addresses approach fully interworks with the
-   other approaches.  That is, the other approaches can remove the
-   configuration effort on servers by using the well-known addresses as
-   the default configuration.  Moreover, the clients preconfigured with
-   the well-known anycast addresses can be further configured to use
-   other approaches to override the well-known addresses, if the
-   configuration information from other approaches is available.
-   Otherwise, all the clients need to have the well-known anycast
-   addresses preconfigured.  In order to use the anycast approach along
-   with two other approaches, there are three choices as follows:
-
-   1.  The first choice is that well-known addresses are used as last
-       resort, when an IPv6 host cannot get RDNSS information through RA
-       and DHCP.  The well-known anycast addresses have to be
-       preconfigured in all of IPv6 hosts' resolver configuration files.
-
-   2.  The second is that an IPv6 host can configure well-known
-       addresses as the most preferable in its configuration file even
-       though either an RA option or DHCP option is available.
-
-   3.  The last is that the well-known anycast addresses can be set in
-       RA or DHCP configuration to reduce the configuration effort of
-       users.  According to either the RA or DHCP mechanism, the well-
-       known addresses can be obtained by an IPv6 host.  Because this
-       approach is the most convenient for users, the last option is
-       recommended.
-
-
-Note
-
-   This section does not necessarily mean this document suggests
-   adopting all these three approaches and making them interwork in the
-   way described here.  In fact, some approaches may even not be adopted
-   at all as a result of further discussion.
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 15]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-5.  Deployment Scenarios
-
-   Regarding the DNS configuration on the IPv6 host, several mechanisms
-   are being considered at the DNSOP Working Group such as RA option,
-   DHCPv6 option and well-known preconfigured anycast addresses as of
-   today, and this document is a final result from the long thread.  In
-   this section, we suggest four applicable scenarios of three
-   approaches for IPv6 DNS configuration.
-
-Note
-
-   In the applicable scenarios, authors do not implicitly push any
-   specific approaches into the restricted environments.  No enforcement
-   is in each scenario and all mentioned scenarios are probable.  The
-   main objective of this work is to provide a useful guideline for IPv6
-   DNS configuration.
-
-5.1  ISP Network
-
-   A characteristic of ISP network is that multiple Customer Premises
-   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
-   routers and each PE connects multiple CPE devices to the backbone
-   network infrastructure [13].  The CPEs may be hosts or routers.
-
-   In the case where the CPE is a router, there is a customer network
-   that is connected to the ISP backbone through the CPE.  Typically,
-   each customer network gets a different IPv6 prefix from an IPv6 PE
-   router, but the same RDNSS configuration will be distributed.
-
-   This section discusses how the different approaches to distributing
-   DNS information are compared in an ISP network.
-
-5.1.1  RA Option Approach
-
-   When the CPE is a host, the RA option for RDNSS can be used to allow
-   the CPE to get RDNSS information as well as /64 prefix information
-   for stateless address autoconfiguration at the same time when the
-   host is attached to a new subnet [8].  Because an IPv6 host must
-   receive at least one RA message for stateless address
-   autoconfiguration and router configuration, the host could receive
-   RDNSS configuration information in that RA without the overhead of an
-   additional message exchange.
-
-   When the CPE is a router, the CPE may accept the RDNSS information
-   from the RA on the interface connected to the ISP, and copy that
-   information into the RAs advertised in the customer network.
-
-   This approach is more valuable in the mobile host scenario, in which
-
-
-
-Jeong                   Expires November 6, 2005               [Page 16]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   the host must receive at least an RA message for detecting a new
-   network, than in other scenarios generally although administrator
-   should configure RDNSS information on the routers.  Secure ND [14]
-   can provide extended security when using RA messages.
-
-5.1.2  DHCPv6 Option Approach
-
-   DHCPv6 can be used for RDNSS configuration through the use of the DNS
-   option, and can provide other configuration information in the same
-   message with RDNSS configuration [5]-[7].  The DHCPv6 DNS option is
-   already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or
-   stateless DHCP [6] is nowhere as complex as a full DHCPv6
-   implementation.  DHCP is a client-server model protocol, so ISPs can
-   handle user identification on its network intentionally, and also
-   authenticated DHCP [15] can be used for secure message exchange.
-
-   The expected model for deployment of IPv6 service by ISPs is to
-   assign a prefix to each customer, which will be used by the customer
-   gateway to assign a /64 prefix to each network in the customer's
-   network.  Prefix delegation with DHCP (DHCPv6 PD) has already been
-   adopted by ISPs for automating the assignment of the customer prefix
-   to the customer gateway [17].  DNS configuration can be carried in
-   the same DHCPv6 message exchange used for DHCPv6 to efficiently
-   provide that information, along with any other configuration
-   information needed by the customer gateway or customer network.  This
-   service model can be useful to Home or SOHO subscribers.  The Home or
-   SOHO gateway, which is a customer gateway for ISP, can then pass that
-   RDNSS configuration information to the hosts in the customer network
-   through DHCP.
-
-5.1.3  Well-known Anycast Addresses Approach
-
-   The well-known anycast addresses approach is also a feasible and
-   simple mechanism for ISP [9].  The use of well-known anycast
-   addresses avoids some of the security risks in rogue messages sent
-   through an external protocol like RA or DHCPv6.  The configuration of
-   hosts for the use of well-known anycast addresses requires no
-   protocol or manual configuration, but the configuration of routing
-   for the anycast addresses requires intervention on the part of the
-   network administrator.  Also, the number of special addresses would
-   be equal to the number of RDNSSes that could be made available to
-   subscribers.
-
-5.2  Enterprise Network
-
-   Enterprise network is defined as a network that has multiple internal
-   links, one or more router connections, to one or more Providers and
-   is actively managed by a network operations entity [16].  An
-
-
-
-Jeong                   Expires November 6, 2005               [Page 17]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   enterprise network can get network prefixes from an ISP by either
-   manual configuration or prefix delegation [17].  In most cases,
-   because an enterprise network manages its own DNS domains, it
-   operates its own DNS servers for the domains.  These DNS servers
-   within enterprise network process recursive DNS name resolution
-   requests from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
-   enterprise network can be performed like in Section 4, in which three
-   approaches can be used together as follows:
-
-   1.  An IPv6 host can decide which approach is or may be used in its
-       subnet with the O flag in RA message [8][32].  As the first
-       choice in Section 4, well-known anycast addresses can be used as
-       a last resort when RDNSS information cannot be obtained through
-       either an RA option or DHCP option.  This case needs IPv6 hosts
-       to preconfigure the well-known anycast addresses in their DNS
-       configuration files.
-
-   2.  When the enterprise prefers the well-known anycast approach to
-       others, IPv6 hosts should preconfigure the well-known anycast
-       addresses like in the first choice.
-
-   3.  The last choice, a more convenient and transparent way, does not
-       need IPv6 hosts to preconfigure the well-known anycast addresses
-       because the addresses are delivered to IPv6 hosts via either the
-       RA option or DHCPv6 option as if they were unicast addresses.
-       This way is most recommended for the sake of user's convenience.
-
-
-5.3  3GPP Network
-
-   The IPv6 DNS configuration is a missing part of IPv6
-   autoconfiguration and an important part of the basic IPv6
-   functionality in the 3GPP User Equipment (UE).  The higher level
-   description of the 3GPP architecture can be found in [18], and
-   transition to IPv6 in 3GPP networks is analyzed in [19] and [20].
-
-   In the 3GPP architecture, there is a dedicated link between the UE
-   and the GGSN called the Packet Data Protocol (PDP) Context.  This
-   link is created through the PDP Context activation procedure [21].
-   There is a separate PDP context type for IPv4 and IPv6 traffic.  If a
-   3GPP UE user is communicating using IPv6 (having an active IPv6 PDP
-   context), it cannot be assumed that (s)he has simultaneously an
-   active IPv4 PDP context, and DNS queries could be done using IPv4.  A
-   3GPP UE can thus be an IPv6 node, and it needs to somehow discover
-   the address of the RDNSS.  Before IP-based services (e.g., web
-   browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses
-   need to be discovered in the 3GPP UE.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 18]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   Section 5.3.1 briefly summarizes currently available mechanisms in
-   3GPP networks and recommendations. 5.3.2 analyzes the Router
-   Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
-   mechanism, and 5.3.4 analyzes the Well-known addresses approach.
-   Section 5.3.5 finally summarizes the recommendations.
-
-5.3.1  Currently Available Mechanisms and Recommendations
-
-   3GPP has defined a mechanism, in which RDNSS addresses can be
-   received in the PDP context activation (a control plane mechanism).
-   That is called the Protocol Configuration Options Information Element
-   (PCO-IE) mechanism [22].  The RDNSS addresses can also be received
-   over the air (using text messages), or typed in manually in the UE.
-   Note that the two last mechanisms are not very well scalable.  The UE
-   user most probably does not want to type IPv6 RDNSS addresses
-   manually in his/her UE.  The use of well-known addresses is briefly
-   discussed in section 5.3.4.
-
-   It is seen that the mechanisms above most probably are not sufficient
-   for the 3GPP environment.  IPv6 is intended to operate in a zero-
-   configuration manner, no matter what the underlying network
-   infrastructure is.  Typically, the RDNSS address is needed to make an
-   IPv6 node operational - and the DNS configuration should be as simple
-   as the address autoconfiguration mechanism.  It must also be noted
-   that there will be additional IP interfaces in some near future 3GPP
-   UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such
-   as PCO-IE [22]) do not work for those IP interfaces.  In other words,
-   a good IPv6 DNS configuration mechanism should also work in a multi-
-   access network environment.
-
-   From a 3GPP point of view, the best IPv6 DNS configuration solution
-   is feasible for a very large number of IPv6-capable UEs (can be even
-   hundreds of millions in one operator's network), is automatic and
-   thus requires no user action.  It is suggested to standardize a
-   lightweight, stateless mechanism that works in all network
-   environments.  The solution could then be used for 3GPP, 3GPP2, WLAN
-   and other access network technologies.  A light, stateless IPv6 DNS
-   configuration mechanism is thus not only needed in 3GPP networks, but
-   also 3GPP networks and UEs would certainly benefit from the new
-   mechanism.
-
-5.3.2  RA Extension
-
-   Router Advertisement extension [8] is a lightweight IPv6 DNS
-   configuration mechanism that requires minor changes in the 3GPP UE
-   IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
-   the 3GPP architecture) IPv6 stack.  This solution can be specified in
-   the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs
-
-
-
-Jeong                   Expires November 6, 2005               [Page 19]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   and GGSNs
-
-   In this solution, an IPv6-capable UE configures DNS information via
-   RA message sent by its default router (GGSN), i.e., RDNSS option for
-   recursive DNS server is included in the RA message.  This solution is
-   easily scalable for a very large number of UEs.  The operator can
-   configure the RDNSS addresses in the GGSN as a part of normal GGSN
-   configuration.  The IPv6 RDNSS address is received in the Router
-   Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS
-   addresses can be avoided.
-
-   If thinking about the cons, this mechanism still requires
-   standardization effort in the IETF, and the end nodes and routers
-   need to support this mechanism.  The equipment software update
-   should, however, be pretty straightforward, and new IPv6 equipment
-   could support RA extension already from the beginning.
-
-5.3.3  Stateless DHCPv6
-
-   DHCPv6-based solution needs the implementation of Stateless DHCP [6]
-   and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the
-   operator's network.  A possible configuration is such that the GGSN
-   works as a DHCP relay.
-
-   Pros for Stateless DHCPv6-based solution are
-
-   1.  Stateless DHCPv6 is a standardized mechanism.
-
-   2.  DHCPv6 can be used for receiving other configuration information
-       than RDNSS addresses, e.g., SIP server addresses.
-
-   3.  DHCPv6 works in different network environments.
-
-   4.  When DHCPv6 service is deployed through a single, centralized
-       server, the RDNSS configuration information can be updated by the
-       network administrator at a single source.
-
-   Some issues with DHCPv6 in 3GPP networks are listed below:
-
-   1.  DHCPv6 requires an additional server in the network unless the
-       (Stateless) DHCPv6 functionality is integrated into a router
-       already existing, and that means one box more to be maintained.
-
-   2.  DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
-       (3GPP Stateless Address Autoconfiguration is typically used), and
-       not automatically implemented in 3GPP IPv6 UEs.
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 20]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   3.  Scalability and reliability of DHCPv6 in very large 3GPP networks
-       (with tens or hundreds of millions of UEs) may be an issue, at
-       least the redundancy needs to be taken care of.  However, if the
-       DHCPv6 service is integrated into the network elements, such as a
-       router operating system, scalability and reliability is
-       comparable with other DNS configuration approaches.
-
-   4.  It is sub-optimal to utilize the radio resources in 3GPP networks
-       for DHCPv6 messages if there is a simpler alternative available.
-
-       *  The use of Stateless DHCPv6 adds one round trip delay to the
-          case in which the UE can start transmitting data right after
-          the Router Advertisement.
-
-   5.  If the DNS information (suddenly) changes, Stateless DHCPv6 can
-       not automatically update the UE, see [23].
-
-
-5.3.4  Well-known Addresses
-
-   Using well-known addresses is also a feasible and a light mechanism
-   for 3GPP UEs.  Those well-known addresses can be preconfigured in the
-   UE software and the operator makes the corresponding configuration on
-   the network side.  So this is a very easy mechanism for the UE, but
-   requires some configuration work in the network.  When using well-
-   known addresses, UE forwards queries to any of the preconfigured
-   addresses.  In the current proposal [9], IPv6 anycast addresses are
-   suggested.
-
-Note
-
-   The IPv6 DNS configuration proposal based on the use of well-known
-   site-local addresses developed at the IPv6 Working Group was seen as
-   a feasible mechanism for 3GPP UEs, but opposition by some people in
-   the IETF and finally deprecating IPv6 site-local addresses made it
-   impossible to standardize it.  Note that this mechanism is
-   implemented in some existing operating systems today (also in some
-   3GPP UEs) as a last resort of IPv6 DNS configuration.
-
-5.3.5  Recommendations
-
-   It is suggested that a lightweight, stateless DNS configuration
-   mechanism is specified as soon as possible.  From a 3GPP UE and
-   network point of view, the Router Advertisement based mechanism looks
-   most promising.  The sooner a light, stateless mechanism is
-   specified, the sooner we can get rid of using well-known site-local
-   addresses for IPv6 DNS configuration.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 21]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-5.4  Unmanaged Network
-
-   There are 4 deployment scenarios of interest in unmanaged networks
-   [24]:
-
-   1.  A gateway which does not provide IPv6 at all;
-
-   2.  A dual-stack gateway connected to a dual-stack ISP;
-
-   3.  A dual-stack gateway connected to an IPv4-only ISP; and
-
-   4.  A gateway connected to an IPv6-only ISP.
-
-
-5.4.1  Case A: Gateway does not provide IPv6 at all
-
-   In this case, the gateway does not provide IPv6; the ISP may or may
-   not provide IPv6.  Automatic or Configured tunnels are the
-   recommended transition mechanisms for this scenario.
-
-   The case where dual-stack hosts behind an NAT, that need access to an
-   IPv6 RDNSS, cannot be entirely ruled out.  The DNS configuration
-   mechanism has to work over the tunnel, and the underlying tunneling
-   mechanism could be implementing NAT traversal.  The tunnel server
-   assumes the role of a relay (both for DHCP and Well-known anycast
-   addresses approaches).
-
-   RA-based mechanism is relatively straightforward in its operation,
-   assuming the tunnel server is also the IPv6 router emitting RAs.
-   Well-known anycast addresses approach seems also simple in operation
-   across the tunnel, but the deployment model using Well-known anycast
-   addresses in a tunneled environment is unclear or not well
-   understood.
-
-5.4.2  Case B: A dual-stack gateway connected to a dual-stack ISP
-
-   This is similar to a typical IPv4 home user scenario, where DNS
-   configuration parameters are obtained using DHCP.  Except that
-   Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
-   DHCP server is stateful (maintains the state for clients).
-
-5.4.3  Case C: A dual-stack gateway connected to an IPv4-only ISP
-
-   This is similar to Case B. If a gateway provides IPv6 connectivity by
-   managing tunnels, then it is also supposed to provide access to an
-   RDNSS.  Like this, the tunnel for IPv6 connectivity originates from
-   the dual-stack gateway instead of the host.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 22]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-5.4.4  Case D: A gateway connected to an IPv6-only ISP
-
-   This is similar to Case B.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 23]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-6.  Security Considerations
-
-   As security requirements depend solely on applications and are
-   different application by application, there can be no generic
-   requirement defined at IP or application layer for DNS.
-
-   However, it should be noted that cryptographic security requires
-   configured secret information that full autoconfiguration and
-   cryptographic security are mutually exclusive.  People insisting on
-   secure full autoconfiguration will get false security, false
-   autoconfiguration or both.
-
-   In some deployment scenarios [19], where cryptographic security is
-   required for applications, the secret information for the
-   cryptographic security is preconfigured through which application
-   specific configuration data, including those for DNS, can be securely
-   configured.  It should be noted that if applications requiring
-   cryptographic security depend on DNS, the applications also require
-   cryptographic security to DNS.  Therefore, the full autoconfiguration
-   of DNS is not acceptable.
-
-   However, with full autoconfiguration, weaker but still reasonable
-   security is being widely accepted and will continue to be acceptable.
-   That is, with full autoconfiguration, which means there is no
-   cryptographic security for the autoconfiguration, it is already
-   assumed that the local environment is secure enough that the
-   information from the local autoconfiguration server has acceptable
-   security even without cryptographic security.  Thus, the
-   communication between the local DNS client and local DNS server has
-   acceptable security.
-
-   In autoconfiguring recursive servers, DNSSEC may be overkill, because
-   DNSSEC [29] needs the configuration and reconfiguration of clients at
-   root key roll-over [30][31].  Even if additional keys for secure key
-   roll-over are added at the initial configuration, they are as
-   vulnerable as the original keys to some forms of attacks, such as
-   social hacking.  Another problem of using DNSSEC and
-   autoconfiguration together is that DNSSEC requires secure time, which
-   means secure communication with autoconfigured time servers, which
-   requires configured secret information.  Therefore, in order that the
-   autoconfiguration may be secure, it requires configured secret
-   information.
-
-   If DNSSEC [29] is used and the signatures are verified on the client
-   host, the misconfiguration of a DNS server may be simply denial of
-   service.  Also, if local routing environment is not reliable, clients
-   may be directed to a false resolver with the same IP address as the
-   true one.
-
-
-
-Jeong                   Expires November 6, 2005               [Page 24]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-6.1  RA Option
-
-   The security of RA option for RDNSS is the same as the ND protocol
-   security [3][8].  The RA option does not add any new vulnerability.
-
-   It should be noted that the vulnerability of ND is not worse and is a
-   subset of the attacks that any node attached to a LAN can do
-   independently of ND.  A malicious node on a LAN can promiscuously
-   receive packets for any router's MAC address and send packets with
-   the router's MAC address as the source MAC address in the L2 header.
-   As a result, the L2 switches send packets addressed to the router to
-   the malicious node.  Also, this attack can send redirects that tell
-   the hosts to send their traffic somewhere else.  The malicious node
-   can send unsolicited RA or NA replies, answer RS or NS requests, etc.
-   All of this can be done independently of implementing ND.  Therefore,
-   the RA option for RDNSS does not add to the vulnerability.
-
-   Security issues regarding the ND protocol were discussed at IETF SEND
-   (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND
-   security has been published [14].
-
-6.2  DHCPv6 Option
-
-   The DNS Recursive Name Server option may be used by an intruder DHCP
-   server to cause DHCP clients to send DNS queries to an intruder DNS
-   recursive name server [7].  The results of these misdirected DNS
-   queries may be used to spoof DNS names.
-
-   To avoid attacks through the DNS Recursive Name Server option, the
-   DHCP client SHOULD require DHCP authentication (see section
-   "Authentication of DHCP messages" in RFC 3315 [5]) before installing
-   a list of DNS recursive name servers obtained through authenticated
-   DHCP.
-
-6.3  Well-known Anycast Addresses
-
-   Well-known anycast addresses does not require configuration security
-   since there is no protocol [9].
-
-   The DNS server with the preconfigured addresses are still reasonably
-   reliable, if local environment is reasonably secure, that is, there
-   is no active attackers receiving queries to the anycast addresses of
-   the servers and reply to them.
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 25]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-7.  Contributors
-
-   Ralph Droms
-   Cisco Systems, Inc.
-   1414 Massachusetts Ave.
-   Boxboro, MA  01719
-   US
-
-   Phone: +1 978 936 1674
-   Email: rdroms@cisco.com
-
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA  94043
-   US
-
-   Phone: +1 650 625 2004
-   Email: bob.hinden@nokia.com
-
-
-   Ted Lemon
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA  94043
-   US
-
-   Email: Ted.Lemon@nominum.com
-
-
-   Masataka Ohta
-   Tokyo Institute of Technology
-   2-12-1, O-okayama, Meguro-ku
-   Tokyo  152-8552
-   Japan
-
-   Phone: +81 3 5734 3299
-   Fax:   +81 3 5734 3299
-   Email: mohta@necom830.hpcl.titech.ac.jp
-
-
-   Soohong Daniel Park
-   Mobile Platform Laboratory, SAMSUNG Electronics
-   416 Maetan-3dong, Yeongtong-Gu
-   Suwon, Gyeonggi-Do  443-742
-   Korea
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 26]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   Phone: +82 31 200 4508
-   Email: soohong.park@samsung.com
-
-
-   Suresh Satapati
-   Cisco Systems, Inc.
-   San Jose, CA  95134
-   US
-
-   Email: satapati@cisco.com
-
-
-   Juha Wiljakka
-   Nokia
-   Visiokatu 3
-   FIN-33720, TAMPERE
-   Finland
-
-   Phone: +358 7180 48372
-   Email: juha.wiljakka@nokia.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 27]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-8.  Acknowledgements
-
-   This draft has greatly benefited from inputs by David Meyer, Rob
-   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
-   Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
-   Also, Tony Bonanno proofread this draft.  The authors appreciate
-   their contribution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 28]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-9.  References
-
-9.1  Normative References
-
-   [1]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
-        February 2004.
-
-   [2]  Bradner, S., "Intellectual Property Rights in IETF Technology",
-        RFC 3668, February 2004.
-
-   [3]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
-        for IP Version 6 (IPv6)", RFC 2461, December 1998.
-
-   [4]  Thomson, S. and T. Narten, "IPv6 Stateless Address
-        Autoconfiguration", RFC 2462, December 1998.
-
-   [5]  Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6
-        (DHCPv6)", RFC 3315, July 2003.
-
-   [6]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
-        Service for IPv6", RFC 3736, April 2004.
-
-   [7]  Droms, R., Ed., "DNS Configuration options for Dynamic Host
-        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
-        December 2003.
-
-9.2  Informative References
-
-   [8]   Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS
-         Discovery based on Router Advertisement",
-         draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress),
-         February 2005.
-
-   [9]   Ohta, M., "Preconfigured DNS Server Addresses",
-         draft-ohta-preconfigured-dns-01.txt (Work in Progress),
-         February 2004.
-
-   [10]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
-         Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in
-         Progress), January 2005.
-
-   [11]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
-         Service", RFC 1546, November 1993.
-
-   [12]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-         Addressing Architecture", RFC 3513, April 2003.
-
-   [13]  Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6
-
-
-
-Jeong                   Expires November 6, 2005               [Page 29]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-         into ISP Networks", RFC 4029, March 2005.
-
-   [14]  Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971,
-         March 2005.
-
-   [15]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
-         RFC 3118, June 2001.
-
-   [16]  Bound, J., Ed., "IPv6 Enterprise Network Scenarios",
-         draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress),
-         July 2004.
-
-   [17]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
-         Configuration Protocol (DHCP) version 6", RFC 3633,
-         December 2003.
-
-   [18]  Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP
-         Standards", RFC 3314, September 2002.
-
-   [19]  Soininen, J., Ed., "Transition Scenarios for 3GPP Networks",
-         RFC 3574, August 2003.
-
-   [20]  Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP
-         Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in
-         Progress), October 2004.
-
-   [21]  3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
-         Service description; Stage 2 (Release 5)", December 2002.
-
-   [22]  3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
-         specification; Core network protocols; Stage 3 (Release 5)",
-         June 2003.
-
-   [23]  Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
-         Requirements for Stateless DHCPv6",
-         draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in
-         Progress), October 2004.
-
-   [24]  Huitema, C., Ed., "Unmanaged Networks IPv6 Transition
-         Scenarios", RFC 3750, April 2004.
-
-   [25]  ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access
-         Control (MAC) and Physical Layer (PHY) Specifications",
-         March 1999.
-
-   [26]  IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control
-         (MAC) and Physical Layer (PHY) specifications: High-speed
-         Physical Layer in the 5 GHZ Band", September 1999.
-
-
-
-Jeong                   Expires November 6, 2005               [Page 30]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   [27]  IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control
-         (MAC) and Physical Layer (PHY) specifications: Higher-Speed
-         Physical Layer Extension in the 2.4 GHz Band", September 1999.
-
-   [28]  IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access
-         Control (MAC) and Physical Layer (PHY) specifications: Further
-         Higher Data Rate Extension in the 2.4 GHz Band", April 2003.
-
-   [29]  Eastlake, D., "Domain Name System Security Extensions",
-         RFC 2535, March 1999.
-
-   [30]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
-         draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in
-         Progress), December 2004.
-
-   [31]  Guette, G. and O. Courtay, "Requirements for Automated Key
-         Rollover in DNSSEC",
-         draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in
-         Progress), January 2005.
-
-   [32]  Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
-         and O Flags of IPv6 Router Advertisement",
-         draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress),
-         March 2005.
-
-
-Author's Address
-
-   Jaehoon Paul Jeong (editor)
-   ETRI/Department of Computer Science and Engineering
-   University of Minnesota
-   117 Pleasant Street SE
-   Minneapolis, MN  55455
-   US
-
-   Phone: +1 651 587 7774
-   Fax:   +1 612 625 2002
-   Email: jjeong@cs.umn.edu
-   URI:   http://www.cs.umn.edu/~jjeong/
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 31]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-Appendix A.  Link-layer Multicast Acknowledgements for RA Option
-
-   One benefit of an RA option [8] is to be able to multicast the
-   advertisements, reducing the need for duplicated unicast
-   communications.
-
-   However, some link-layers may not support this as well as others.
-   Consider, for example, WLAN networks where multicast is unreliable.
-   The unreliability problem is caused by lack of ACK for multicast,
-   especially on the path from the Access Point (AP) to the Station
-   (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11
-   a/b/g [25]-[28].  That is, a multicast packet is unacknowledged on
-   the path from the AP to the STA, but acknowledged in the reverse
-   direction from the STA to the AP [25].  For example, when a router is
-   placed at wired network connected to an AP, a host may sometimes not
-   receive RA message advertised through the AP.  Therefore, the RA
-   option solution might not work well on a congested medium that uses
-   unreliable multicast for RA.
-
-   The fact that this problem has not been addressed in Neighbor
-   Discovery [3] indicates that the extra link-layer acknowledgements
-   have not been considered a serious problem till now.
-
-   A possible mitigation technique could be to map all-nodes link- local
-   multicast address to the link-layer broadcast address, and to rely on
-   the ND retransmissions for message delivery in order to achieve more
-   reliability.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 32]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 33]
-
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
deleted file mode 100644
index 1276f9f91d62..000000000000
--- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
+++ /dev/null
@@ -1,1682 +0,0 @@
-
-
-
-
-DNS Operations WG                                              A. Durand
-Internet-Draft                                    SUN Microsystems, Inc.
-Expires: January 17, 2006                                       J. Ihren
-                                                              Autonomica
-                                                               P. Savola
-                                                               CSC/FUNET
-                                                           July 16, 2005
-
-
-          Operational Considerations and Issues with IPv6 DNS
-                draft-ietf-dnsop-ipv6-dns-issues-11.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 17, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This memo presents operational considerations and issues with IPv6
-   Domain Name System (DNS), including a summary of special IPv6
-   addresses, documentation of known DNS implementation misbehaviour,
-   recommendations and considerations on how to perform DNS naming for
-   service provisioning and for DNS resolver IPv6 support,
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 1]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   considerations for DNS updates for both the forward and reverse
-   trees, and miscellaneous issues.  This memo is aimed to include a
-   summary of information about IPv6 DNS considerations for those who
-   have experience with IPv4 DNS.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1   Representing IPv6 Addresses in DNS Records . . . . . . . .  4
-     1.2   Independence of DNS Transport and DNS Records  . . . . . .  4
-     1.3   Avoiding IPv4/IPv6 Name Space Fragmentation  . . . . . . .  5
-     1.4   Query Type '*' and A/AAAA Records  . . . . . . . . . . . .  5
-   2.  DNS Considerations about Special IPv6 Addresses  . . . . . . .  5
-     2.1   Limited-scope Addresses  . . . . . . . . . . . . . . . . .  6
-     2.2   Temporary Addresses  . . . . . . . . . . . . . . . . . . .  6
-     2.3   6to4 Addresses . . . . . . . . . . . . . . . . . . . . . .  6
-     2.4   Other Transition Mechanisms  . . . . . . . . . . . . . . .  6
-   3.  Observed DNS Implementation Misbehaviour . . . . . . . . . . .  7
-     3.1   Misbehaviour of DNS Servers and Load-balancers . . . . . .  7
-     3.2   Misbehaviour of DNS Resolvers  . . . . . . . . . . . . . .  7
-   4.  Recommendations for Service Provisioning using DNS . . . . . .  7
-     4.1   Use of Service Names instead of Node Names . . . . . . . .  8
-     4.2   Separate vs the Same Service Names for IPv4 and IPv6 . . .  8
-     4.3   Adding the Records Only when Fully IPv6-enabled  . . . . .  9
-     4.4   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
-       4.4.1   TTL With Courtesy Additional Data  . . . . . . . . . . 10
-       4.4.2   TTL With Critical Additional Data  . . . . . . . . . . 10
-     4.5   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 11
-   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 11
-     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
-     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 13
-     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 13
-   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 13
-     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
-     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 14
-   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 15
-     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
-     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
-     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 16
-     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
-     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 18
-   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
-     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 19
-     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 19
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
-   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 20
-   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 20
-     11.1  Normative References . . . . . . . . . . . . . . . . . . . 20
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 2]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-     11.2  Informative References . . . . . . . . . . . . . . . . . . 22
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
-   A.  Unique Local Addressing Considerations for DNS . . . . . . . . 25
-   B.  Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25
-     B.1   Description of Additional Data Scenarios . . . . . . . . . 26
-     B.2   Which Additional Data to Keep, If Any? . . . . . . . . . . 27
-     B.3   Discussion of the Potential Problems . . . . . . . . . . . 28
-       Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 3]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-1.  Introduction
-
-   This memo presents operational considerations and issues with IPv6
-   DNS; it is meant to be an extensive summary and a list of pointers
-   for more information about IPv6 DNS considerations for those with
-   experience with IPv4 DNS.
-
-   The purpose of this document is to give information about various
-   issues and considerations related to DNS operations with IPv6; it is
-   not meant to be a normative specification or standard for IPv6 DNS.
-
-   The first section gives a brief overview of how IPv6 addresses and
-   names are represented in the DNS, how transport protocols and
-   resource records (don't) relate, and what IPv4/IPv6 name space
-   fragmentation means and how to avoid it; all of these are described
-   at more length in other documents.
-
-   The second section summarizes the special IPv6 address types and how
-   they relate to DNS.  The third section describes observed DNS
-   implementation misbehaviours which have a varying effect on the use
-   of IPv6 records with DNS.  The fourth section lists recommendations
-   and considerations for provisioning services with DNS.  The fifth
-   section in turn looks at recommendations and considerations about
-   providing IPv6 support in the resolvers.  The sixth and seventh
-   sections describe considerations with forward and reverse DNS
-   updates, respectively.  The eighth section introduces several
-   miscellaneous IPv6 issues relating to DNS for which no better place
-   has been found in this memo.  Appendix A looks briefly at the
-   requirements for unique local addressing.
-
-1.1  Representing IPv6 Addresses in DNS Records
-
-   In the forward zones, IPv6 addresses are represented using AAAA
-   records.  In the reverse zones, IPv6 address are represented using
-   PTR records in the nibble format under the ip6.arpa. tree.  See
-   [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
-   for background information.
-
-   In particular one should note that the use of A6 records in the
-   forward tree or Bitlabels in the reverse tree is not recommended
-   [RFC3363].  Using DNAME records is not recommended in the reverse
-   tree in conjunction with A6 records; the document did not mean to
-   take a stance on any other use of DNAME records [RFC3364].
-
-1.2  Independence of DNS Transport and DNS Records
-
-   DNS has been designed to present a single, globally unique name space
-   [RFC2826].  This property should be maintained, as described here and
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 4]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   in Section 1.3.
-
-   The IP version used to transport the DNS queries and responses is
-   independent of the records being queried: AAAA records can be queried
-   over IPv4, and A records over IPv6.  The DNS servers must not make
-   any assumptions about what data to return for Answer and Authority
-   sections based on the underlying transport used in a query.
-
-   However, there is some debate whether the addresses in Additional
-   section could be selected or filtered using hints obtained from which
-   transport was being used; this has some obvious problems because in
-   many cases the transport protocol does not correlate with the
-   requests, and because a "bad" answer is in a way worse than no answer
-   at all (consider the case where the client is led to believe that a
-   name received in the additional record does not have any AAAA records
-   at all).
-
-   As stated in [RFC3596]:
-
-      The IP protocol version used for querying resource records is
-      independent of the protocol version of the resource records; e.g.,
-      IPv4 transport can be used to query IPv6 records and vice versa.
-
-
-1.3  Avoiding IPv4/IPv6 Name Space Fragmentation
-
-   To avoid the DNS name space from fragmenting into parts where some
-   parts of DNS are only visible using IPv4 (or IPv6) transport, the
-   recommendation is to always keep at least one authoritative server
-   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
-   See DNS IPv6 transport guidelines [RFC3901] for more information.
-
-1.4  Query Type '*' and A/AAAA Records
-
-   QTYPE=* is typically only used for debugging or management purposes;
-   it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
-   any available RRsets, not *all* the RRsets, because the caches do not
-   necessarily have all the RRsets and have no way of guaranteeing that
-   they have all the RRsets.  Therefore, to get both A and AAAA records
-   reliably, two separate queries must be made.
-
-2.  DNS Considerations about Special IPv6 Addresses
-
-   There are a couple of IPv6 address types which are somewhat special;
-   these are considered here.
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 5]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-2.1  Limited-scope Addresses
-
-   The IPv6 addressing architecture [RFC3513] includes two kinds of
-   local-use addresses: link-local (fe80::/10) and site-local
-   (fec0::/10).  The site-local addresses have been deprecated [RFC3879]
-   but are discussed with unique local addresses in Appendix A.
-
-   Link-local addresses should never be published in DNS (whether in
-   forward or reverse tree), because they have only local (to the
-   connected link) significance [I-D.durand-dnsop-dont-publish].
-
-2.2  Temporary Addresses
-
-   Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
-   "privacy addresses") use a random number as the interface identifier.
-   Having DNS AAAA records that are updated to always contain the
-   current value of a node's temporary address would defeat the purpose
-   of the mechanism and is not recommended.  However, it would still be
-   possible to return a non-identifiable name (e.g., the IPv6 address in
-   hexadecimal format), as described in [RFC3041].
-
-2.3  6to4 Addresses
-
-   6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
-   a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
-
-   If the reverse DNS population would be desirable (see Section 7.1 for
-   applicability), there are a number of possible ways to do so.
-
-   The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
-   autonomous reverse-delegation system that anyone being capable of
-   communicating using a specific 6to4 address would be able to set up a
-   reverse delegation to the corresponding 6to4 prefix.  This could be
-   deployed by e.g., Regional Internet Registries (RIRs).  This is a
-   practical solution, but may have some scalability concerns.
-
-2.4  Other Transition Mechanisms
-
-   6to4 is mentioned as a case of an IPv6 transition mechanism requiring
-   special considerations.  In general, mechanisms which include a
-   special prefix may need a custom solution; otherwise, for example
-   when IPv4 address is embedded as the suffix or not embedded at all,
-   special solutions are likely not needed.
-
-   Note that it does not seem feasible to provide reverse DNS with
-   another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
-   teredo]; this is because the IPv6 address is based on the IPv4
-   address and UDP port of the current NAT mapping which is likely to be
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 6]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   relatively short-lived.
-
-3.  Observed DNS Implementation Misbehaviour
-
-   Several classes of misbehaviour in DNS servers, load-balancers and
-   resolvers have been observed.  Most of these are rather generic, not
-   only applicable to IPv6 -- but in some cases, the consequences of
-   this misbehaviour are extremely severe in IPv6 environments and
-   deserve to be mentioned.
-
-3.1  Misbehaviour of DNS Servers and Load-balancers
-
-   There are several classes of misbehaviour in certain DNS servers and
-   load-balancers which have been noticed and documented [RFC4074]: some
-   implementations silently drop queries for unimplemented DNS records
-   types, or provide wrong answers to such queries (instead of a proper
-   negative reply).  While typically these issues are not limited to
-   AAAA records, the problems are aggravated by the fact that AAAA
-   records are being queried instead of (mainly) A records.
-
-   The problems are serious because when looking up a DNS name, typical
-   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
-   to query the AAAA records of the name, and after receiving a
-   response, query the A records.  This is done in a serial fashion --
-   if the first query is never responded to (instead of properly
-   returning a negative answer), significant timeouts will occur.
-
-   In consequence, this is an enormous problem for IPv6 deployments, and
-   in some cases, IPv6 support in the software has even been disabled
-   due to these problems.
-
-   The solution is to fix or retire those misbehaving implementations,
-   but that is likely not going to be effective.  There are some
-   possible ways to mitigate the problem, e.g., by performing the
-   lookups somewhat in parallel and reducing the timeout as long as at
-   least one answer has been received; but such methods remain to be
-   investigated; slightly more on this is included in Section 5.
-
-3.2  Misbehaviour of DNS Resolvers
-
-   Several classes of misbehaviour have also been noticed in DNS
-   resolvers [I-D.ietf-dnsop-bad-dns-res].  However, these do not seem
-   to directly impair IPv6 use, and are only referred to for
-   completeness.
-
-4.  Recommendations for Service Provisioning using DNS
-
-   When names are added in the DNS to facilitate a service, there are
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 7]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   several general guidelines to consider to be able to do it as
-   smoothly as possible.
-
-4.1  Use of Service Names instead of Node Names
-
-   It makes sense to keep information about separate services logically
-   separate in the DNS by using a different DNS hostname for each
-   service.  There are several reasons for doing this, for example:
-
-   o  It allows more flexibility and ease for migration of (only a part
-      of) services from one node to another,
-
-   o  It allows configuring different properties (e.g., TTL) for each
-      service, and
-
-   o  It allows deciding separately for each service whether to publish
-      the IPv6 addresses or not (in cases where some services are more
-      IPv6-ready than others).
-
-   Using SRV records [RFC2782] would avoid these problems.
-   Unfortunately, those are not sufficiently widely used to be
-   applicable in most cases.  Hence an operation technique is to use
-   service names instead of node names (or, "hostnames").  This
-   operational technique is not specific to IPv6, but required to
-   understand the considerations described in Section 4.2 and
-   Section 4.3.
-
-   For example, assume a node named "pobox.example.com" provides both
-   SMTP and IMAP service.  Instead of configuring the MX records to
-   point at "pobox.example.com", and configuring the mail clients to
-   look up the mail via IMAP from "pobox.example.com", one could use
-   e.g., "smtp.example.com" for SMTP (for both message submission and
-   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
-   Note that in the specific case of SMTP relaying, the server itself
-   must typically also be configured to know all its names to ensure
-   loops do not occur.  DNS can provide a layer of indirection between
-   service names and where the service actually is, and using which
-   addresses.  (Obviously, when wanting to reach a specific node, one
-   should use the hostname rather than a service name.)
-
-4.2  Separate vs the Same Service Names for IPv4 and IPv6
-
-   The service naming can be achieved in basically two ways: when a
-   service is named "service.example.com" for IPv4, the IPv6-enabled
-   service could either be added to "service.example.com", or added
-   separately under a different name, e.g., in a sub-domain, like,
-   "service.ipv6.example.com".
-
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 8]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   These two methods have different characteristics.  Using a different
-   name allows for easier service piloting, minimizing the disturbance
-   to the "regular" users of IPv4 service; however, the service would
-   not be used transparently, without the user/application explicitly
-   finding it and asking for it -- which would be a disadvantage in most
-   cases.  When the different name is under a sub-domain, if the
-   services are deployed within a restricted network (e.g., inside an
-   enterprise), it's possible to prefer them transparently, at least to
-   a degree, by modifying the DNS search path; however, this is a
-   suboptimal solution.  Using the same service name is the "long-term"
-   solution, but may degrade performance for those clients whose IPv6
-   performance is lower than IPv4, or does not work as well (see
-   Section 4.3 for more).
-
-   In most cases, it makes sense to pilot or test a service using
-   separate service names, and move to the use of the same name when
-   confident enough that the service level will not degrade for the
-   users unaware of IPv6.
-
-4.3  Adding the Records Only when Fully IPv6-enabled
-
-   The recommendation is that AAAA records for a service should not be
-   added to the DNS until all of following are true:
-
-   1.  The address is assigned to the interface on the node.
-
-   2.  The address is configured on the interface.
-
-   3.  The interface is on a link which is connected to the IPv6
-       infrastructure.
-
-   In addition, if the AAAA record is added for the node, instead of
-   service as recommended, all the services of the node should be IPv6-
-   enabled prior to adding the resource record.
-
-   For example, if an IPv6 node is isolated from an IPv6 perspective
-   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
-   that it should not have an address in the DNS.
-
-   Consider the case of two dual-stack nodes, which both have IPv6
-   enabled, but the server does not have (global) IPv6 connectivity.  As
-   the client looks up the server's name, only A records are returned
-   (if the recommendations above are followed), and no IPv6
-   communication, which would have been unsuccessful, is even attempted.
-
-   The issues are not always so black-and-white.  Usually it's important
-   that the service offered using both protocols is of roughly equal
-   quality, using the appropriate metrics for the service (e.g.,
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 9]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   latency, throughput, low packet loss, general reliability, etc.) --
-   this is typically very important especially for interactive or real-
-   time services.  In many cases, the quality of IPv6 connectivity may
-   not yet be equal to that of IPv4, at least globally -- this has to be
-   taken into consideration when enabling services.
-
-4.4  The Use of TTL for IPv4 and IPv6 RRs
-
-   The behaviour of DNS caching when different TTL values are used for
-   different RRsets of the same name calls for explicit discussion.  For
-   example, let's consider two unrelated zone fragments:
-
-      example.com.        300    IN    MX     foo.example.com.
-      foo.example.com.    300    IN    A      192.0.2.1
-      foo.example.com.    100    IN    AAAA   2001:db8::1
-
-   ...
-
-      child.example.com.    300  IN    NS     ns.child.example.com.
-      ns.child.example.com. 300  IN    A      192.0.2.1
-      ns.child.example.com. 100  IN    AAAA   2001:db8::1
-
-   In the former case, we have "courtesy" additional data; in the
-   latter, we have "critical" additional data.  See more extensive
-   background discussion of additional data handling in Appendix B.
-
-4.4.1  TTL With Courtesy Additional Data
-
-   When a caching resolver asks for the MX record of example.com, it
-   gets back "foo.example.com".  It may also get back either one or both
-   of the A and AAAA records in the additional section.  The resolver
-   must explicitly query for both A and AAAA records [RFC2821].
-
-   After 100 seconds, the AAAA record is removed from the cache(s)
-   because its TTL expired.  It could be argued to be useful for the
-   caching resolvers to discard the A record when the shorter TTL (in
-   this case, for the AAAA record) expires; this would avoid the
-   situation where there would be a window of 200 seconds when
-   incomplete information is returned from the cache.  Further argument
-   for discarding is that in the normal operation, the TTL values are so
-   high that very likely the incurred additional queries would not be
-   noticeable, compared to the obtained performance optimization.  The
-   behaviour in this scenario is unspecified.
-
-4.4.2  TTL With Critical Additional Data
-
-   The difference to courtesy additional data is that the A/AAAA records
-   served by the parent zone cannot be queried explicitly.  Therefore
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 10]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   after 100 seconds the AAAA record is removed from the cache(s), but
-   the A record remains.  Queries for the remaining 200 seconds
-   (provided that there are no further queries from the parent which
-   could refresh the caches) only return the A record, leading to a
-   potential opererational situation with unreachable servers.
-
-   Similar cache flushing strategies apply in this scenario; the record.
-
-4.5  IPv6 Transport Guidelines for DNS Servers
-
-   As described in Section 1.3 and [RFC3901], there should continue to
-   be at least one authoritative IPv4 DNS server for every zone, even if
-   the zone has only IPv6 records.  (Note that obviously, having more
-   servers with robust connectivity would be preferable, but this is the
-   minimum recommendation; also see [RFC2182].)
-
-5.  Recommendations for DNS Resolver IPv6 Support
-
-   When IPv6 is enabled on a node, there are several things to consider
-   to ensure that the process is as smooth as possible.
-
-5.1  DNS Lookups May Query IPv6 Records Prematurely
-
-   The system library that implements the getaddrinfo() function for
-   looking up names is a critical piece when considering the robustness
-   of enabling IPv6; it may come in basically three flavours:
-
-   1.  The system library does not know whether IPv6 has been enabled in
-       the kernel of the operating system: it may start looking up AAAA
-       records with getaddrinfo() and AF_UNSPEC hint when the system is
-       upgraded to a system library version which supports IPv6.
-
-   2.  The system library might start to perform IPv6 queries with
-       getaddrinfo() only when IPv6 has been enabled in the kernel.
-       However, this does not guarantee that there exists any useful
-       IPv6 connectivity (e.g., the node could be isolated from the
-       other IPv6 networks, only having link-local addresses).
-
-   3.  The system library might implement a toggle which would apply
-       some heuristics to the "IPv6-readiness" of the node before
-       starting to perform queries; for example, it could check whether
-       only link-local IPv6 address(es) exists, or if at least one
-       global IPv6 address exists.
-
-   First, let us consider generic implications of unnecessary queries
-   for AAAA records: when looking up all the records in the DNS, AAAA
-   records are typically tried first, and then A records.  These are
-   done in serial, and the A query is not performed until a response is
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 11]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   received to the AAAA query.  Considering the misbehaviour of DNS
-   servers and load-balancers, as described in Section 3.1, the look-up
-   delay for AAAA may incur additional unnecessary latency, and
-   introduce a component of unreliability.
-
-   One option here could be to do the queries partially in parallel; for
-   example, if the final response to the AAAA query is not received in
-   0.5 seconds, start performing the A query while waiting for the
-   result (immediate parallelism might be unoptimal, at least without
-   information sharing between the look-up threads, as that would
-   probably lead to duplicate non-cached delegation chain lookups).
-
-   An additional concern is the address selection, which may, in some
-   circumstances, prefer AAAA records over A records even when the node
-   does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
-   In some cases, the implementation may attempt to connect or send a
-   datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
-   incurring very long protocol timeouts, instead of quickly failing
-   back to IPv4.
-
-   Now, we can consider the issues specific to each of the three
-   possibilities:
-
-   In the first case, the node performs a number of completely useless
-   DNS lookups as it will not be able to use the returned AAAA records
-   anyway.  (The only exception is where the application desires to know
-   what's in the DNS, but not use the result for communication.)  One
-   should be able to disable these unnecessary queries, for both latency
-   and reliability reasons.  However, as IPv6 has not been enabled, the
-   connections to IPv6 addresses fail immediately, and if the
-   application is programmed properly, the application can fall
-   gracefully back to IPv4 [RFC4038].
-
-   The second case is similar to the first, except it happens to a
-   smaller set of nodes when IPv6 has been enabled but connectivity has
-   not been provided yet; similar considerations apply, with the
-   exception that IPv6 records, when returned, will be actually tried
-   first which may typically lead to long timeouts.
-
-   The third case is a bit more complex: optimizing away the DNS lookups
-   with only link-locals is probably safe (but may be desirable with
-   different lookup services which getaddrinfo() may support), as the
-   link-locals are typically automatically generated when IPv6 is
-   enabled, and do not indicate any form of IPv6 connectivity.  That is,
-   performing DNS lookups only when a non-link-local address has been
-   configured on any interface could be beneficial -- this would be an
-   indication that either the address has been configured either from a
-   router advertisement, DHCPv6 [RFC3315], or manually.  Each would
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 12]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   indicate at least some form of IPv6 connectivity, even though there
-   would not be guarantees of it.
-
-   These issues should be analyzed at more depth, and the fixes found
-   consensus on, perhaps in a separate document.
-
-5.2  Obtaining a List of DNS Recursive Resolvers
-
-   In scenarios where DHCPv6 is available, a host can discover a list of
-   DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
-   option [RFC3646].  This option can be passed to a host through a
-   subset of DHCPv6 [RFC3736].
-
-   The IETF is considering the development of alternative mechanisms for
-   obtaining the list of DNS recursive name servers when DHCPv6 is
-   unavailable or inappropriate.  No decision about taking on this
-   development work has been reached as of this writing (Aug 2004)
-   [I-D.ietf-dnsop-ipv6-dns-configuration].
-
-   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
-   under consideration for development include the use of well-known
-   addresses [I-D.ohta-preconfigured-dns] and the use of Router
-   Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns-
-   discovery].
-
-   Note that even though IPv6 DNS resolver discovery is a recommended
-   procedure, it is not required for dual-stack nodes in dual-stack
-   networks as IPv6 DNS records can be queried over IPv4 as well as
-   IPv6.  Obviously, nodes which are meant to function without manual
-   configuration in IPv6-only networks must implement the DNS resolver
-   discovery function.
-
-5.3  IPv6 Transport Guidelines for Resolvers
-
-   As described in Section 1.3 and [RFC3901], the recursive resolvers
-   should be IPv4-only or dual-stack to be able to reach any IPv4-only
-   DNS server.  Note that this requirement is also fulfilled by an IPv6-
-   only stub resolver pointing to a dual-stack recursive DNS resolver.
-
-6.  Considerations about Forward DNS Updating
-
-   While the topic of how to enable updating the forward DNS, i.e., the
-   mapping from names to the correct new addresses, is not specific to
-   IPv6, it should be considered especially due to the advent of
-   Stateless Address Autoconfiguration [RFC2462].
-
-   Typically forward DNS updates are more manageable than doing them in
-   the reverse DNS, because the updater can often be assumed to "own" a
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 13]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   certain DNS name -- and we can create a form of security relationship
-   with the DNS name and the node which is allowed to update it to point
-   to a new address.
-
-   A more complex form of DNS updates -- adding a whole new name into a
-   DNS zone, instead of updating an existing name -- is considered out
-   of scope for this memo as it could require zone-wide authentication.
-   Adding a new name in the forward zone is a problem which is still
-   being explored with IPv4, and IPv6 does not seem to add much new in
-   that area.
-
-6.1  Manual or Custom DNS Updates
-
-   The DNS mappings can also be maintained by hand, in a semi-automatic
-   fashion or by running non-standardized protocols.  These are not
-   considered at more length in this memo.
-
-6.2  Dynamic DNS
-
-   Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
-   mechanism for dynamically updating the DNS.  It works equally well
-   with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
-   address configuration.  It is important to consider how each of these
-   behave if IP address-based authentication, instead of stronger
-   mechanisms [RFC3007], was used in the updates.
-
-   1.  manual addresses are static and can be configured
-
-   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
-       on the deployment, and could or could not be configured on the
-       DNS server for the long term
-
-   3.  SLAAC addresses are typically stable for a long time, but could
-       require work to be configured and maintained.
-
-   As relying on IP addresses for Dynamic DNS is rather insecure at
-   best, stronger authentication should always be used; however, this
-   requires that the authorization keying will be explicitly configured
-   using unspecified operational methods.
-
-   Note that with DHCP it is also possible that the DHCP server updates
-   the DNS, not the host.  The host might only indicate in the DHCP
-   exchange which hostname it would prefer, and the DHCP server would
-   make the appropriate updates.  Nonetheless, while this makes setting
-   up a secure channel between the updater and the DNS server easier, it
-   does not help much with "content" security, i.e., whether the
-   hostname was acceptable -- if the DNS server does not include
-   policies, they must be included in the DHCP server (e.g., a regular
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 14]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   host should not be able to state that its name is "www.example.com").
-   DHCP-initiated DDNS updates have been extensively described in
-   [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
-   [I-D.ietf-dnsext-dhcid-rr].
-
-   The nodes must somehow be configured with the information about the
-   servers where they will attempt to update their addresses, sufficient
-   security material for authenticating themselves to the server, and
-   the hostname they will be updating.  Unless otherwise configured, the
-   first could be obtained by looking up the authoritative name servers
-   for the hostname; the second must be configured explicitly unless one
-   chooses to trust the IP address-based authentication (not a good
-   idea); and lastly, the nodename is typically pre-configured somehow
-   on the node, e.g., at install time.
-
-   Care should be observed when updating the addresses not to use longer
-   TTLs for addresses than are preferred lifetimes for the addresses, so
-   that if the node is renumbered in a managed fashion, the amount of
-   stale DNS information is kept to the minimum.  That is, if the
-   preferred lifetime of an address expires, the TTL of the record needs
-   be modified unless it was already done before the expiration.  For
-   better flexibility, the DNS TTL should be much shorter (e.g., a half
-   or a third) than the lifetime of an address; that way, the node can
-   start lowering the DNS TTL if it seems like the address has not been
-   renewed/refreshed in a while.  Some discussion on how an
-   administrator could manage the DNS TTL is included in [I-D.ietf-
-   v6ops-renumbering-procedure]; this could be applied to (smart) hosts
-   as well.
-
-7.  Considerations about Reverse DNS Updating
-
-   Updating the reverse DNS zone may be difficult because of the split
-   authority over an address.  However, first we have to consider the
-   applicability of reverse DNS in the first place.
-
-7.1  Applicability of Reverse DNS
-
-   Today, some applications use reverse DNS to either look up some hints
-   about the topological information associated with an address (e.g.
-   resolving web server access logs), or as a weak form of a security
-   check, to get a feel whether the user's network administrator has
-   "authorized" the use of the address (on the premises that adding a
-   reverse record for an address would signal some form of
-   authorization).
-
-   One additional, maybe slightly more useful usage is ensuring that the
-   reverse and forward DNS contents match (by looking up the pointer to
-   the name by the IP address from the reverse tree, and ensuring that a
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 15]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   record under the name in the forward tree points to the IP address)
-   and correspond to a configured name or domain.  As a security check,
-   it is typically accompanied by other mechanisms, such as a user/
-   password login; the main purpose of the reverse+forward DNS check is
-   to weed out the majority of unauthorized users, and if someone
-   managed to bypass the checks, he would still need to authenticate
-   "properly".
-
-   It may also be desirable to store IPsec keying material corresponding
-   to an IP address in the reverse DNS, as justified and described in
-   [RFC4025].
-
-   It is not clear whether it makes sense to require or recommend that
-   reverse DNS records be updated.  In many cases, it would just make
-   more sense to use proper mechanisms for security (or topological
-   information lookup) in the first place.  At minimum, the applications
-   which use it as a generic authorization (in the sense that a record
-   exists at all) should be modified as soon as possible to avoid such
-   lookups completely.
-
-   The applicability is discussed at more length in [I-D.ietf-dnsop-
-   inaddr-required].
-
-7.2  Manual or Custom DNS Updates
-
-   Reverse DNS can of course be updated using manual or custom methods.
-   These are not further described here, except for one special case.
-
-   One way to deploy reverse DNS would be to use wildcard records, for
-   example, by configuring one name for a subnet (/64) or a site (/48).
-   As a concrete example, a site (or the site's ISP) could configure the
-   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
-   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN PTR
-   site.example.com."  Naturally, such a name could not be verified from
-   the forward DNS, but would at least provide some form of "topological
-   information" or "weak authorization" if that is really considered to
-   be useful.  Note that this is not actually updating the DNS as such,
-   as the whole point is to avoid DNS updates completely by manually
-   configuring a generic name.
-
-7.3  DDNS with Stateless Address Autoconfiguration
-
-   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
-   some regard, while being more difficult in another, as described
-   below.
-
-   The address space administrator decides whether the hosts are trusted
-   to update their reverse DNS records or not.  If they are trusted and
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 16]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   deployed at the same site (e.g., not across the Internet), a simple
-   address-based authorization is typically sufficient (i.e., check that
-   the DNS update is done from the same IP address as the record being
-   updated); stronger security can also be used [RFC3007].  If they
-   aren't allowed to update the reverses, no update can occur.  However,
-   such address-based update authorization operationally requires that
-   ingress filtering [RFC3704] has been set up at the border of the site
-   where the updates occur, and as close to the updater as possible.
-
-   Address-based authorization is simpler with reverse DNS (as there is
-   a connection between the record and the address) than with forward
-   DNS.  However, when a stronger form of security is used, forward DNS
-   updates are simpler to manage because the host can be assumed to have
-   an association with the domain.  Note that the user may roam to
-   different networks, and does not necessarily have any association
-   with the owner of that address space -- so, assuming stronger form of
-   authorization for reverse DNS updates than an address association is
-   generally infeasible.
-
-   Moreover, the reverse zones must be cleaned up by an unspecified
-   janitorial process: the node does not typically know a priori that it
-   will be disconnected, and cannot send a DNS update using the correct
-   source address to remove a record.
-
-   A problem with defining the clean-up process is that it is difficult
-   to ensure that a specific IP address and the corresponding record are
-   no longer being used.  Considering the huge address space, and the
-   unlikelihood of collision within 64 bits of the interface
-   identifiers, a process which would remove the record after no traffic
-   has been seen from a node in a long period of time (e.g., a month or
-   year) might be one possible approach.
-
-   To insert or update the record, the node must discover the DNS server
-   to send the update to somehow, similar to as discussed in
-   Section 6.2.  One way to automate this is looking up the DNS server
-   authoritative (e.g., through SOA record) for the IP address being
-   updated, but the security material (unless the IP address-based
-   authorization is trusted) must also be established by some other
-   means.
-
-   One should note that Cryptographically Generated Addresses [RFC3972]
-   (CGAs) may require a slightly different kind of treatment.  CGAs are
-   addresses where the interface identifier is calculated from a public
-   key, a modifier (used as a nonce), the subnet prefix, and other data.
-   Depending on the usage profile, CGAs might or might not be changed
-   periodically due to e.g., privacy reasons.  As the CGA address is not
-   predicatable, a reverse record can only reasonably be inserted in the
-   DNS by the node which generates the address.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 17]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-7.4  DDNS with DHCP
-
-   With DHCPv4, the reverse DNS name is typically already inserted to
-   the DNS that reflects to the name (e.g., "dhcp-67.example.com").  One
-   can assume similar practice may become commonplace with DHCPv6 as
-   well; all such mappings would be pre-configured, and would require no
-   updating.
-
-   If a more explicit control is required, similar considerations as
-   with SLAAC apply, except for the fact that typically one must update
-   a reverse DNS record instead of inserting one (if an address
-   assignment policy that reassigns disused addresses is adopted) and
-   updating a record seems like a slightly more difficult thing to
-   secure.  However, it is yet uncertain how DHCPv6 is going to be used
-   for address assignment.
-
-   Note that when using DHCP, either the host or the DHCP server could
-   perform the DNS updates; see the implications in Section 6.2.
-
-   If disused addresses were to be reassigned, host-based DDNS reverse
-   updates would need policy considerations for DNS record modification,
-   as noted above.  On the other hand, if disused address were not to be
-   assigned, host-based DNS reverse updates would have similar
-   considerations as SLAAC in Section 7.3.  Server-based updates have
-   similar properties except that the janitorial process could be
-   integrated with DHCP address assignment.
-
-7.5  DDNS with Dynamic Prefix Delegation
-
-   In cases where a prefix, instead of an address, is being used and
-   updated, one should consider what is the location of the server where
-   DDNS updates are made.  That is, where the DNS server is located:
-
-   1.  At the same organization as the prefix delegator.
-
-   2.  At the site where the prefixes are delegated to.  In this case,
-       the authority of the DNS reverse zone corresponding to the
-       delegated prefix is also delegated to the site.
-
-   3.  Elsewhere; this implies a relationship between the site and where
-       DNS server is located, and such a relationship should be rather
-       straightforward to secure as well.  Like in the previous case,
-       the authority of the DNS reverse zone is also delegated.
-
-   In the first case, managing the reverse DNS (delegation) is simpler
-   as the DNS server and the prefix delegator are in the same
-   administrative domain (as there is no need to delegate anything at
-   all); alternatively, the prefix delegator might forgo DDNS reverse
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 18]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   capability altogether, and use e.g., wildcard records (as described
-   in Section 7.2).  In the other cases, it can be slighly more
-   difficult, particularly as the site will have to configure the DNS
-   server to be authoritative for the delegated reverse zone, implying
-   automatic configuration of the DNS server -- as the prefix may be
-   dynamic.
-
-   Managing the DDNS reverse updates is typically simple in the second
-   case, as the updated server is located at the local site, and
-   arguably IP address-based authentication could be sufficient (or if
-   not, setting up security relationships would be simpler).  As there
-   is an explicit (security) relationship between the parties in the
-   third case, setting up the security relationships to allow reverse
-   DDNS updates should be rather straightforward as well (but IP
-   address-based authentication might not be acceptable).  In the first
-   case, however, setting up and managing such relationships might be a
-   lot more difficult.
-
-8.  Miscellaneous DNS Considerations
-
-   This section describes miscellaneous considerations about DNS which
-   seem related to IPv6, for which no better place has been found in
-   this document.
-
-8.1  NAT-PT with DNS-ALG
-
-   The DNS-ALG component of NAT-PT mangles A records  to look like AAAA
-   records to the IPv6-only nodes.  Numerous problems have been
-   identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl].  This is
-   a strong reason not to use NAT-PT in the first place.
-
-8.2  Renumbering Procedures and Applications' Use of DNS
-
-   One of the most difficult problems of systematic IP address
-   renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
-   an application which looks up a DNS name disregards information such
-   as TTL, and uses the result obtained from DNS as long as it happens
-   to be stored in the memory of the application.  For applications
-   which run for a long time, this could be days, weeks or even months;
-   some applications may be clever enough to organize the data
-   structures and functions in such a manner that look-ups get refreshed
-   now and then.
-
-   While the issue appears to have a clear solution, "fix the
-   applications", practically this is not reasonable immediate advice;
-   the TTL information is not typically available in the APIs and
-   libraries (so, the advice becomes "fix the applications, APIs and
-   libraries"), and a lot more analysis is needed on how to practically
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 19]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   go about to achieve the ultimate goal of avoiding using the names
-   longer than expected.
-
-9.  Acknowledgements
-
-   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
-   provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
-   Nordmark and Bob Gilligan.  Havard Eidnes and Michael Patton provided
-   useful feedback and improvements.  Scott Rose, Rob Austein, Masataka
-   Ohta, and Mark Andrews helped in clarifying the issues regarding
-   additional data and the use of TTL.  Jefsey Morfin, Ralph Droms,
-   Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
-   Rob Austein provided useful feedback during the WG last call.  Thomas
-   Narten provided extensive feedback during the IESG evaluation.
-
-10.  Security Considerations
-
-   This document reviews the operational procedures for IPv6 DNS
-   operations and does not have security considerations in itself.
-
-   However, it is worth noting that in particular with Dynamic DNS
-   Updates, security models based on the source address validation are
-   very weak and cannot be recommended -- they could only be considered
-   in the environments where ingress filtering [RFC3704] has been
-   deployed.  On the other hand, it should be noted that setting up an
-   authorization mechanism (e.g., a shared secret, or public-private
-   keys) between a node and the DNS server has to be done manually, and
-   may require quite a bit of time and expertise.
-
-   To re-emphasize what was already stated, the reverse+forward DNS
-   check provides very weak security at best, and the only
-   (questionable) security-related use for them may be in conjunction
-   with other mechanisms when authenticating a user.
-
-11.  References
-
-11.1  Normative References
-
-   [I-D.ietf-dnsop-ipv6-dns-configuration]
-              Jeong, J., "IPv6 Host Configuration of DNS Server
-              Information Approaches",
-              draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
-              progress), May 2005.
-
-   [I-D.ietf-ipv6-unique-local-addr]
-              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-              Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
-              progress), January 2005.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 20]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   [I-D.ietf-v6ops-renumbering-procedure]
-              Baker, F., "Procedures for Renumbering an IPv6 Network
-              without a Flag Day",
-              draft-ietf-v6ops-renumbering-procedure-05 (work in
-              progress), March 2005.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
-              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
-              July 1997.
-
-   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
-              Autoconfiguration", RFC 2462, December 1998.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-              April 2001.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
-              Stateless Address Autoconfiguration in IPv6", RFC 3041,
-              January 2001.
-
-   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
-              via IPv4 Clouds", RFC 3056, February 2001.
-
-   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
-              August 2001.
-
-   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
-              and M. Carney, "Dynamic Host Configuration Protocol for
-              IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
-              Hain, "Representing Internet Protocol version 6 (IPv6)
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 21]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-              Addresses in the Domain Name System (DNS)", RFC 3363,
-              August 2002.
-
-   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
-              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
-              August 2002.
-
-   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
-              (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-              "DNS Extensions to Support IP Version 6", RFC 3596,
-              October 2003.
-
-   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
-              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
-              December 2003.
-
-   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
-              (DHCP) Service for IPv6", RFC 3736, April 2004.
-
-   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
-              Addresses", RFC 3879, September 2004.
-
-   [RFC3901]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
-              Guidelines", BCP 91, RFC 3901, September 2004.
-
-   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
-              Castro, "Application Aspects of IPv6 Transition",
-              RFC 4038, March 2005.
-
-   [RFC4074]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against
-              DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
-
-11.2  Informative References
-
-   [I-D.durand-dnsop-dont-publish]
-              Durand, A. and T. Chown, "To publish, or not to publish,
-              that is the question.", draft-durand-dnsop-dont-publish-00
-              (work in progress), February 2005.
-
-   [I-D.huitema-v6ops-teredo]
-              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
-              NATs", draft-huitema-v6ops-teredo-05 (work in progress),
-              April 2005.
-
-   [I-D.huston-6to4-reverse-dns]
-              Huston, G., "6to4 Reverse DNS Delegation",
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 22]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-              draft-huston-6to4-reverse-dns-03 (work in progress),
-              October 2004.
-
-   [I-D.ietf-dhc-ddns-resolution]
-              Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
-              DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in
-              progress), June 2005.
-
-   [I-D.ietf-dhc-fqdn-option]
-              Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
-              draft-ietf-dhc-fqdn-option-10 (work in progress),
-              February 2005.
-
-   [I-D.ietf-dnsext-dhcid-rr]
-              Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for
-              encoding DHCP information (DHCID RR)",
-              draft-ietf-dnsext-dhcid-rr-09 (work in progress),
-              February 2005.
-
-   [I-D.ietf-dnsop-bad-dns-res]
-              Larson, M. and P. Barber, "Observed DNS Resolution
-              Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in
-              progress), October 2004.
-
-   [I-D.ietf-dnsop-inaddr-required]
-              Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
-              draft-ietf-dnsop-inaddr-required-06 (work in progress),
-              February 2005.
-
-   [I-D.ietf-v6ops-3gpp-analysis]
-              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
-              Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
-              progress), October 2004.
-
-   [I-D.ietf-v6ops-mech-v2]
-              Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
-              for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
-              (work in progress), March 2005.
-
-   [I-D.ietf-v6ops-natpt-to-exprmntl]
-              Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
-              Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
-              in progress), July 2005.
-
-   [I-D.ietf-v6ops-onlinkassumption]
-              Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
-              Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
-              (work in progress), May 2005.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 23]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   [I-D.ietf-v6ops-v6onbydefault]
-              Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
-              IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
-              (work in progress), July 2004.
-
-   [I-D.jeong-dnsop-ipv6-dns-discovery]
-              Jeong, J., "IPv6 DNS Configuration based on Router
-              Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04
-              (work in progress), February 2005.
-
-   [I-D.ohta-preconfigured-dns]
-              Ohta, M., "Preconfigured DNS Server Addresses",
-              draft-ohta-preconfigured-dns-01 (work in progress),
-              February 2004.
-
-   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
-              Translation - Protocol Translation (NAT-PT)", RFC 2766,
-              February 2000.
-
-   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-              specifying the location of services (DNS SRV)", RFC 2782,
-              February 2000.
-
-   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
-              Unique DNS Root", RFC 2826, May 2000.
-
-   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
-              Networks", BCP 84, RFC 3704, March 2004.
-
-   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
-              RFC 3972, March 2005.
-
-   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
-              Material in DNS", RFC 4025, March 2005.
-
-
-Authors' Addresses
-
-   Alain Durand
-   SUN Microsystems, Inc.
-   17 Network circle UMPL17-202
-   Menlo Park, CA  94025
-   USA
-
-   Email: Alain.Durand@sun.com
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 24]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm
-   Sweden
-
-   Email: johani@autonomica.se
-
-
-   Pekka Savola
-   CSC/FUNET
-   Espoo
-   Finland
-
-   Email: psavola@funet.fi
-
-Appendix A.  Unique Local Addressing Considerations for DNS
-
-   Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have
-   replaced the now-deprecated site-local addresses [RFC3879].  From the
-   perspective of the DNS, the locally generated unique local addresses
-   (LUL) and site-local addresses have similar properties.
-
-   The interactions with DNS come in two flavors: forward and reverse
-   DNS.
-
-   To actually use local addresses within a site, this implies the
-   deployment of a "split-faced" or a fragmented DNS name space, for the
-   zones internal to the site, and the outsiders' view to it.  The
-   procedures to achieve this are not elaborated here.  The implication
-   is that local addresses must not be published in the public DNS.
-
-   To faciliate reverse DNS (if desired) with local addresses, the stub
-   resolvers must look for DNS information from the local DNS servers,
-   not e.g. starting from the root servers, so that the local
-   information may be provided locally.  Note that the experience of
-   private addresses in IPv4 has shown that the root servers get loaded
-   for requests for private address lookups in any case.  This
-   requirement is discussed in [I-D.ietf-ipv6-unique-local-addr].
-
-Appendix B.  Behaviour of Additional Data in IPv4/IPv6 Environments
-
-   DNS responses do not always fit in a single UDP packet.  We'll
-   examine the cases which happen when this is due to too much data in
-   the Additional Section.
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 25]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-B.1  Description of Additional Data Scenarios
-
-   There are two kinds of additional data:
-
-   1.  "critical" additional data; this must be included in all
-       scenarios, with all the RRsets, and
-
-   2.  "courtesy" additional data; this could be sent in full, with only
-       a few RRsets, or with no RRsets, and can be fetched separately as
-       well, but at the cost of additional queries.
-
-   The responding server can algorithmically determine which type the
-   additional data is by checking whether it's at or below a zone cut.
-
-   Only those additional data records (even if sometimes carelessly
-   termed "glue") are considered "critical" or real "glue" if and only
-   if they meet the abovementioned condition, as specified in Section
-   4.2.1 of [RFC1034].
-
-   Remember that resource record sets (RRsets) are never "broken up", so
-   if a name has 4 A records and 5 AAAA records, you can either return
-   all 9, all 4 A records, all 5 AAAA records or nothing.  In
-   particular, notice that for the "critical" additional data getting
-   all the RRsets can be critical.
-
-   In particular, [RFC2181] specifies (in Section 9) that:
-
-   a.  if all the "critical" RRsets do not fit, the sender should set
-       the TC bit, and the recipient should discard the whole response
-       and retry using mechanism allowing larger responses such as TCP.
-
-   b.  "courtesy" additional data should not cause the setting of TC
-       bit, but instead all the non-fitting additional data RRsets
-       should be removed.
-
-   An example of the "courtesy" additional data is A/AAAA records in
-   conjunction with MX records as shown in Section 4.4; an example of
-   the "critical" additional data is shown below (where getting both the
-   A and AAAA RRsets is critical w.r.t. to the NS RR):
-
-      child.example.com.    IN   NS ns.child.example.com.
-      ns.child.example.com. IN    A 192.0.2.1
-      ns.child.example.com. IN AAAA 2001:db8::1
-
-   When there is too much "courtesy" additional data, at least the non-
-   fitting RRsets should be removed [RFC2181]; however, as the
-   additional data is not critical, even all of it could be safely
-   removed.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 26]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   When there is too much "critical" additional data, TC bit will have
-   to be set, and the recipient should ignore the response and retry
-   using TCP; if some data were to be left in the UDP response, the
-   issue is which data could be retained.
-
-   Failing to discard the response with TC bit or omitting critical
-   information but not setting TC bit lead to an unrecoverable problem.
-   Omitting only some of the RRsets if all would not fit (but not
-   setting TC bit) leads to a performance problem.  These are discussed
-   in the next two subsections.
-
-B.2  Which Additional Data to Keep, If Any?
-
-   If the implementation decides to keep as much data (whether
-   "critical" or "courtesy") as possible in the UDP responses, it might
-   be tempting to use the transport of the DNS query as a hint in either
-   of these cases: return the AAAA records if the query was done over
-   IPv6, or return the A records if the query was done over IPv4.
-   However, this breaks the model of independence of DNS transport and
-   resource records, as noted in Section 1.2.
-
-   With courtesy additional data, as long as enough RRsets will be
-   removed so that TC will not be set, it is allowed to send as many
-   complete RRsets as the implementations prefers.  However, the
-   implementations are also free to omit all such RRsets, even if
-   complete.  Omitting all the RRsets (when removing only some would
-   suffice) may create a performance penalty, whereby the client may
-   need to issue one or more additional queries to obtain necessary
-   and/or consistent information.
-
-   With critical additional data, the alternatives are either returning
-   nothing (and absolutely requiring a retry with TCP) or returning
-   something (working also in the case if the recipient does not discard
-   the response and retry using TCP) in addition to setting the TC bit.
-   If the process for selecting "something" from the critical data would
-   otherwise be practically "flipping the coin" between A and AAAA
-   records, it could be argued that if one looked at the transport of
-   the query, it would have a larger possibility of being right than
-   just 50/50.  In other words, if the returned critical additional data
-   would have to be selected somehow, using something more sophisticated
-   than a random process would seem justifiable.
-
-   That is, leaving in some intelligently selected critical additional
-   data is a tradeoff between creating an optimization for those
-   resolvers which ignore the "should discard" recommendation, and
-   causing a protocol problem by propagating inconsistent information
-   about "critical" records in the caches.
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 27]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   Similarly, leaving in the complete courtesy additional data RRsets
-   instead of removing all the RRsets is a performance tradeoff as
-   described in the next section.
-
-B.3  Discussion of the Potential Problems
-
-   As noted above, the temptation for omitting only some of the
-   additional data could be problematic.  This is discussed more below.
-
-   For courtesy additional data, this causes a potential performance
-   problem as this requires that the clients issue re-queries for the
-   potentially omitted RRsets.  For critical additional data, this
-   causes a potential unrecoverable problem if the response is not
-   discarded and the query not re-tried with TCP, as the nameservers
-   might be reachable only through the omitted RRsets.
-
-   If an implementation would look at the transport used for the query,
-   it is worth remembering that often the host using the records is
-   different from the node requesting them from the authoritative DNS
-   server (or even a caching resolver).  So, whichever version the
-   requestor (e.g., a recursive server in the middle) uses makes no
-   difference to the ultimate user of the records, whose transport
-   capabilities might differ from those of the requestor.  This might
-   result in e.g., inappropriately returning A records to an IPv6-only
-   node, going through a translation, or opening up another IP-level
-   session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
-   Therefore, at least in many scenarios, it would be very useful if the
-   information returned would be consistent and complete -- or if that
-   is not feasible, return no misleading information but rather leave it
-   to the client to query again.
-
-   The problem of too much additional data seems to be an operational
-   one: the zone administrator entering too many records which will be
-   returned either truncated (or missing some RRsets, depending on
-   implementations) to the users.  A protocol fix for this is using
-   EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
-   pushing up the relevant threshold.  Further, DNS server
-   implementations should rather omit courtesy additional data
-   completely rather than including only some RRsets [RFC2181].  An
-   operational fix for this is having the DNS server implementations
-   return a warning when the administrators create zones which would
-   result in too much additional data being returned.  Further, DNS
-   server implementations should warn of or disallow such zone
-   configurations which are recursive or otherwise difficult to manage
-   by the protocol.
-
-   Additionally, to avoid the case where an application would not get an
-   address at all due to some of courtesy additional data being omitted,
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 28]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   the resolvers should be able to query the specific records of the
-   desired protocol, not just rely on getting all the required RRsets in
-   the additional section.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 29]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 30]
-
-
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
deleted file mode 100644
index b2e2341be9f1..000000000000
--- a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
+++ /dev/null
@@ -1,300 +0,0 @@
-Internet Engineering Task Force                         A.Durand
-INTERNET-DRAFT                             SUN Microsystems,inc.
-November, 24, 2003                                      J. Ihren
-Expires May 25, 2004                                  Autonomica
-
-
-               DNS IPv6 transport operational guidelines
-          
-
-
-
-Status of this Memo
-
-   This memo provides information to the Internet community. It does not
-   specify an Internet standard of any kind. This memo is in full
-   conformance with all provisions of Section 10 of RFC2026
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet- Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-
-Abstract
-
-   This memo provides guidelines and Best Current Practice to operate
-   DNS in a world where queries and responses are carried in a mixed
-   environment of IPv4 and IPv6 networks.
-
-
-Acknowledgment
-
-   This document is the result of many conversations that happened in
-   the DNS community at IETF and elsewhere since 2001. During that
-   period of time, a number of Internet drafts have been published to
-   clarify various aspects of the issues at stake. This document focuses
-   on the conclusion of those discussions.
-
-   The authors would like to acknowledge the role of Pekka Savola in his
-   thorough review of the document.
-
-
-1. Terminology
-
-   The phrase "IPv4 name server" indicates a name server available over
-   IPv4 transport. It does not imply anything about what DNS data is
-   served. Likewise, "IPv6 name server" indicates a name server
-   available over IPv6 transport. The phrase "dual-stack DNS server"
-   indicates a DNS server that is actually configured to run both
-   protocols, IPv4 and IPv6, and not merely a server running on a system
-   capable of running both but actually configured to run only one.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [2119].
-
-
-2. Introduction to the Problem of Name Space Fragmentation:
-     following the referral chain
-
-   The caching resolver that tries to look up a name starts out at the
-   root, and follows referrals until it is referred to a nameserver that
-   is authoritative for the name.  If somewhere down the chain of
-   referrals it is referred to a nameserver that is only accessible over
-   an unavailable type of transport, a traditional nameserver is unable
-   to finish the task.
-
-   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
-   only a matter of time until this starts to happen. The complete DNS
-   hierarchy then starts to fragment into a graph where authoritative
-   nameservers for certain nodes are only accessible over a certain
-   transport. What is feared is that a node using only a particular
-   version of IP, querying information about another node using the same
-   version of IP can not do it because, somewhere in the chain of
-   servers accessed during the resolution process, one or more of them
-   will only be accessible with the other version of IP.
-
-   With all DNS data only available over IPv4 transport everything is
-   simple. IPv4 resolvers can use the intended mechanism of following
-   referrals from the root and down while IPv6 resolvers have to work
-   through a "translator", i.e. they have to use a second name server on
-   a so-called "dual stack" host as a "forwarder" since they cannot
-   access the DNS data directly.
-
-   With all DNS data only available over IPv6 transport everything would
-   be equally simple, with the exception of old legacy IPv4 name servers
-   having to switch to a forwarding configuration.
-
-   However, the second situation will not arise in a foreseeable time.
-   Instead, it is expected that the transition will be from IPv4 only to
-   a mixture of IPv4 and IPv6, with DNS data of theoretically three
-   categories depending on whether it is available only over IPv4
-   transport, only over IPv6 or both.
-
-   Having DNS data available on both transports is the best situation.
-   The major question is how to ensure that it as quickly as possible
-   becomes the norm. However, while it is obvious that some DNS data
-   will only be available over v4 transport for a long time it is also
-   obvious that it is important to avoid fragmenting the name space
-   available to IPv4 only hosts. I.e. during transition it is not
-   acceptable to break the name space that we presently have available
-   for IPv4-only hosts.
-
-
-3. Policy Based Avoidance of Name Space Fragmentation
-
-   Today there are only a few DNS "zones" on the public Internet that
-   are  available over IPv6 transport, and most of them can be regarded
-   as "experimental". However, as soon as the root and top level domains
-   are available over IPv6 transport, it is reasonable to expect that it
-   will become more common to have zones served by IPv6 servers.
-
-   Having those zones served only by IPv6-only name server would not be
-   a good development, since this will fragment the previously
-   unfragmented IPv4 name space and there are strong reasons to find a
-   mechanism to avoid it.
-
-   The RECOMMENDED approach to maintain name space continuity is to use
-   administrative policies, as described in the next section.
-
-
-4. DNS IPv6 Transport RECOMMENDED Guidelines
-
-   In order to preserve name space continuity, the following administrative
-   policies are RECOMMENDED:
-      - every recursive DNS server SHOULD be either IPv4-only or dual
-      stack,
-      - every single DNS zone SHOULD be served by at least one IPv4
-      reachable DNS server.
-
-   This rules out IPv6-only DNS servers performing full recursion and
-   DNS zones served only by IPv6-only DNS servers.  However, one could
-   very well design a configuration where a chain of IPv6 only DNS
-   servers forward queries to a set of dual stack DNS servers actually
-   performing those recursive queries.  This approach could be revisited
-   if/when translation techniques between IPv4 and IPv6 were to be
-   widely deployed.
-
-   In order to help enforcing the second point, the optional operational
-   zone validation processes SHOULD ensure that there is at least one
-   IPv4 address record available for the name servers of any child
-   delegations within the zone.
-
-
-5. Security Considerations
-
-   Being a critical piece of the Internet infrastructure, the DNS is a
-   potential value target and thus should be protected.  Great care
-   should be taken not to weaken the security of DNS while introducing
-   IPv6 operation.
-
-   Keeping the DNS name space from fragmenting is a critical thing for
-   the availability and the operation of the Internet; this memo
-   addresses this issue by clear and simple operational guidelines.
-
-   The RECOMMENDED guidelines are compatible with the operation of
-   DNSSEC and do not introduce any new security issues.
-
-
-6. Author Addresses
-
-   Alain Durand
-   SUN Microsystems, Inc
-   17 Network circle UMPK17-202
-   Menlo Park, CA, 94025
-   USA
-   Mail: Alain.Durand@sun.com
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm, Sweden
-   Mail: johani@autonomica.se
-
-
-7. Normative References
-
-   [2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
-           Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-8. Full Copyright Statement
-
-   "Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
deleted file mode 100644
index 6bece56182cf..000000000000
--- a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
+++ /dev/null
@@ -1,389 +0,0 @@
-
-DNSOP                                                          G. Guette
-Internet-Draft                                             IRISA / INRIA
-Expires: July 19, 2005                                        O. Courtay
-                                                             Thomson R&D
-                                                        January 18, 2005
-
-           Requirements for Automated Key Rollover in DNSSEC
-           draft-ietf-dnsop-key-rollover-requirements-02.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable 
-   patent or other IPR claims of which I am aware have been disclosed, 
-   and any of which I become aware will be disclosed, in accordance with 
-   RFC 3668.  
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 19, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document describes problems that appear during an automated
-   rollover and gives the requirements for the design of communication
-   between parent zone and child zone during an automated rollover
-   process.  This document is essentially about in-band key rollover.
-
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 1]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
-   3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
-   4.   Messages authentication and information exchanged  . . . . . . 5
-   5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
-   6.   Security consideration . . . . . . . . . . . . . . . . . . . . 6
-   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
-   A.   Documents details and changes  . . . . . . . . . . . . . . . . 7
-        Intellectual Property and Copyright Statements . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 2]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-1.  Introduction
-
-   The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
-   cryptography and digital signatures.  It stores the public part of
-   keys in DNSKEY Resource Records (RRs).  Because old keys and
-   frequently used keys are vulnerable, they must be renewed
-   periodically.  In DNSSEC, this is the case for Zone Signing Keys
-   (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
-   exchanges between parents and children is necessary for large zones
-   because there are too many changes to handle.
-
-   Let us consider for example a zone with 100000 secure delegations.
-   If the child zones change their keys once a year on average, that
-   implies 300 changes per day for the parent zone.  This amount of
-   changes is hard to manage manually.
-
-   Automated rollover is optional and resulting from an agreement
-   between the administrator of the parent zone and the administrator of
-   the child zone.  Of course, key rollover can also be done manually by
-   administrators.
-
-   This document describes the requirements for a protocol to perform
-   the automated key rollover process and focusses on interaction
-   between parent and child zone.
-
-2.  The Key Rollover Process
-
-   Key rollover consists of renewing the DNSSEC keys used to sign
-   resource records in a given DNS zone file.  There are two types of
-   rollover, ZSK rollovers and KSK rollovers.
-
-   During a ZSK rollover, all changes are local to the zone that renews
-   its key: there is no need to contact other zones administrators to
-   propagate the performed changes because a ZSK has no associated DS
-   record in the parent zone.
-
-   During a KSK rollover, new DS RR(s) must be created and stored in the
-   parent zone.  In consequence, data must be exchanged between child
-   and parent zones.
-
-   The key rollover is built from two parts of different nature:
-   o  An algorithm that generates new keys and signs the zone file.  It
-      can be local to the zone,
-   o  the interaction between parent and child zones.
-
-   One example of manual key rollover [3] is:
-   o  The child zone creates a new KSK,
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 3]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-   o  the child zone waits for the creation of the DS RR in its parent
-      zone,
-   o  the child zone deletes the old key,
-   o  the parent zone deletes the old DS RR.
-
-   This document concentrates on defining interactions between entities
-   present in key rollover process.
-
-3.  Basic Requirements
-
-   This section provides the requirements for automated key rollover in
-   case of normal use.  Exceptional case like emergency rollover is
-   specifically described later in this document.
-
-   The main condition during a key rollover is that the chain of trust
-   must be preserved to every validating DNS client.  No matter if this
-   client retrieves some of the RRs from recursive caching name server
-   or from the authoritative servers for the zone involved in the
-   rollover.
-
-   Automated key rollover solution may be interrupted by a manual
-   intervention.  This manual intervention should not compromise the
-   security state of the chain of trust.  If the chain is safe before
-   the manual intervention, the chain of trust must remain safe during
-   and after the manual intervention
-
-   Two entities act during a KSK rollover: the child zone and its parent
-   zone.  These zones are generally managed by different administrators.
-   These administrators should agree on some parameters like
-   availability of automated rollover, the maximum delay between
-   notification of changes in the child zone and the resigning of the
-   parent zone.  The child zone needs to know this delay to schedule its
-   changes and/or to verify that the changes had been taken into account
-   in the parent zone.  Hence, the child zone can also avoid some
-   critical cases where all child key are changed prior to the DS RR
-   creation.
-
-   By keeping some resource records during a given time, the recursive
-   cache servers can act on the automated rollover.  The existence of
-   recursive cache servers must be taken into account by automated
-   rollover solution.
-
-   Indeed, during an automated key rollover a name server could have to
-   retrieve some DNSSEC data.  An automated key rollover solution must
-   ensure that these data are not old DNSSEC material retrieved from a
-   recursive name server.
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 4]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-4.  Messages authentication and information exchanged
-
-   This section addresses in-band rollover, security of out-of-band
-   mechanisms is out of scope of this document.
-
-   The security provided by DNSSEC must not be compromised by the key
-   rollover, thus every exchanged message must be authenticated to avoid
-   fake rollover messages from malicious parties.
-
-   Once the changes related to a KSK are made in a child zone, there are
-   two ways for the parent zone to take this changes into account:
-   o  the child zone notify directly or not directly its parent zone in
-      order to create the new DS RR and store this DS RR in parent zone
-      file,
-   o  or the parent zone poll the child zone.
-
-   In both cases, the parent zone must receive all the child keys that
-   need the creation of associated DS RRs in the parent zone.
-
-   Because errors could occur during the transmission of keys between
-   child and parent, the key exchange protocol must be fault tolerant.
-   Should an error occured during the automated key rollover, an
-   automated key rollover solution must be able to keep the zone files
-   in a consistent state.
-
-5.  Emergency Rollover
-
-   Emergency key rollover is a special case of rollover decided by the
-   zone administrator generally for security reasons.  In consequence,
-   emergency key rollover can break some of the requirement described
-   above.
-
-   A zone key might be compromised and an attacker can use the
-   compromised key to create and sign fake records.  To avoid this, the
-   zone administrator may change the compromised key or all its keys as
-   soon as possible, without waiting for the creation of new DS RRs in
-   its parent zone.
-
-   Fast changes may break the chain of trust.  The part of DNS tree
-   having this zone as apex can become unverifiable, but the break of
-   the chain of trust is necessary if the administrator wants to prevent
-   the compromised key from being used (to spoof DNS data).
-
-   Parent and child zones sharing an automated rollover mechanism,
-   should have an out-of-band way to re-establish a consistent state at
-   the delegation point (DS and DNSKEY RRs).  This allows to avoid that
-   a malicious party uses the compromised key to roll the zone keys.
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 5]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-6.  Security consideration
-
-   The automated key rollover process in DNSSEC allows automated renewal
-   of any kind of DNS key (ZSK or KSK).  It is essential that parent
-   side and child side can do mutual authentication.  Moreover,
-   integrity of the material exchanged between the parent and child zone
-   must be provided to ensure the right DS are created.
-
-   As in any application using public key cryptography, in DNSSEC a key
-   may be compromised.  What to do in such a case can be describe in the
-   zone local policy and can violate some requirements described in this
-   draft.  The emergency rollover can break the chain of trust in order
-   to protect the zone against the use of the compromised key.
-
-7.  Acknowledgments
-
-   The authors want to thank members of IDsA project for their
-   contribution to this document.
-
-8  Normative References
-
-   [1]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-        RFC 3658, December 2003.
-
-   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
-        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
-        RFC 3757, May 2004.
-
-   [3]  Kolkman, O., "DNSSEC Operational Practices",
-        draft-ietf-dnsop-dnssec-operational-practice-01 (work in
-        progress), May 2004.
-
-   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [5]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-        "Resource Records for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-records-11 (work in progress), October
-        2004.
-
-   [6]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-        "DNS Security Introduction and Requirements",
-        draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
-        2004.
-
-   [7]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 6]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-        2004.
-
-Authors' Addresses
-
-   Gilles Guette
-   IRISA / INRIA
-   Campus de Beaulieu
-   35042  Rennes CEDEX
-   FR
-
-   EMail: gilles.guette@irisa.fr
-   URI:   http://www.irisa.fr
-
-   Olivier Courtay
-   Thomson R&D
-   1, avenue Belle Fontaine
-   35510  Cesson S?vign? CEDEX
-   FR
-
-   EMail: olivier.courtay@thomson.net
-
-Appendix A.  Documents details and changes
-
-   This section is to be removed by the RFC editor if and when the
-   document is published.
-
-   Section about NS RR rollover has been removed
-
-   Remarks from Samuel Weiler and Rip Loomis added
-
-   Clarification about in-band rollover and in emergency section
-
-   Section 3, details about recursive cache servers added
-
-
-
-
-
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 7]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-Intellectual Property Statement
-
-     The IETF takes no position regarding the validity or scope of any 
-     intellectual property or other rights that might be claimed to 
-     pertain to the implementation or use of the technology described 
-     in this document or the extent to which any license under such 
-     rights might or might not be available; neither does it represent 
-     that it has made any effort to identify any such rights. 
-     Information on the IETF's procedures with respect to rights in 
-     IETF Documents can be found in BCP 78 and 79.   
-          
-     Copies of IPR disclosures made to the IETF Secretariat and any 
-     assurances of licenses to be made available, or the result of an 
-     attempt made to obtain a general license or permission for the use 
-     of such proprietary rights by implementers or users of this 
-     specification can be obtained from the IETF on-line IPR repository 
-     at http://www.ietf.org/ipr. 
-      
-     The IETF invites any interested party to bring to its attention 
-     any copyrights, patents or patent applications, or other 
-     proprietary rights which may cover technology that may be required 
-     to implement this standard. Please address the information to the 
-     IETF at ietf-ipr.org. 
-      
-    
- Full Copyright Statement 
-    
-   Copyright (C) The Internet Society (2005).  This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-    
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-         
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 8]
diff --git a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt
new file mode 100644
index 000000000000..f64e8dd572ec
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt
@@ -0,0 +1,952 @@
+
+
+
+DNSOP                                                        W. Hardaker
+Internet-Draft                                              Sparta, Inc.
+Intended status: Informational                         February 12, 2009
+Expires: August 16, 2009
+
+
+        Requirements for Management of Name Servers for the DNS
+          draft-ietf-dnsop-name-server-management-reqs-02.txt
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 16, 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Abstract
+
+   Management of name servers for the Domain Name Service (DNS) has
+   traditionally been done using vendor-specific monitoring,
+
+
+
+Hardaker                 Expires August 16, 2009                [Page 1]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   configuration and control methods.  Although some service monitoring
+   platforms can test the functionality of the DNS itself there is not a
+   interoperable way to manage (monitor, control and configure) the
+   internal aspects of a name server itself.
+
+   This document discusses the requirements of a management system for
+   DNS name servers.  A management solution that is designed to manage
+   the DNS can use this document as a shopping list of needed features.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  4
+       1.1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . .  5
+       1.1.2.  Document Layout and Requirements . . . . . . . . . . .  5
+   2.  Management Architecture Requirements . . . . . . . . . . . . .  5
+     2.1.  Expected Deployment Scenarios  . . . . . . . . . . . . . .  5
+       2.1.1.  Zone Size Constraints  . . . . . . . . . . . . . . . .  5
+       2.1.2.  Name Server Discovery  . . . . . . . . . . . . . . . .  6
+       2.1.3.  Configuration Data Volatility  . . . . . . . . . . . .  6
+       2.1.4.  Protocol Selection . . . . . . . . . . . . . . . . . .  6
+       2.1.5.  Common Data Model  . . . . . . . . . . . . . . . . . .  6
+       2.1.6.  Operational Impact . . . . . . . . . . . . . . . . . .  7
+     2.2.  Name Server Types  . . . . . . . . . . . . . . . . . . . .  7
+   3.  Management Operation Types . . . . . . . . . . . . . . . . . .  7
+     3.1.  Control Requirements . . . . . . . . . . . . . . . . . . .  8
+       3.1.1.  Needed Control Operations  . . . . . . . . . . . . . .  8
+       3.1.2.  Asynchronous Status Notifications  . . . . . . . . . .  8
+     3.2.  Configuration Requirements . . . . . . . . . . . . . . . .  9
+       3.2.1.  Served Zone Modification . . . . . . . . . . . . . . .  9
+       3.2.2.  Trust Anchor Management  . . . . . . . . . . . . . . .  9
+       3.2.3.  Security Expectations  . . . . . . . . . . . . . . . .  9
+       3.2.4.  TSIG Key Management  . . . . . . . . . . . . . . . . .  9
+       3.2.5.  DNS Protocol Authorization Management  . . . . . . . .  9
+     3.3.  Monitoring Requirements  . . . . . . . . . . . . . . . . . 10
+     3.4.  Alarm and Event Requirements . . . . . . . . . . . . . . . 10
+   4.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 11
+     4.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 11
+     4.2.  Integrity Protection . . . . . . . . . . . . . . . . . . . 11
+     4.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 11
+     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 11
+     4.5.  Solution Impacts on Security . . . . . . . . . . . . . . . 12
+   5.  Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
+     5.1.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . 12
+       5.1.1.  Vendor Extensions  . . . . . . . . . . . . . . . . . . 13
+       5.1.2.  Extension Identification . . . . . . . . . . . . . . . 13
+       5.1.3.  Name-Space Collision Protection  . . . . . . . . . . . 13
+
+
+
+Hardaker                 Expires August 16, 2009                [Page 2]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+   8.  Document History . . . . . . . . . . . . . . . . . . . . . . . 13
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
+   Appendix A.  Deployment Scenarios  . . . . . . . . . . . . . . . . 15
+     A.1.  Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
+     A.2.  Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
+     A.3.  DNSSEC Management  . . . . . . . . . . . . . . . . . . . . 16
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 16, 2009                [Page 3]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+1.  Introduction
+
+   Management of name servers for the Domain Name Service (DNS)
+   [RFC1034] [RFC1035] has traditionally been done using vendor-specific
+   monitoring, configuration and control methods.  Although some service
+   monitoring platforms can test the functionality of the DNS itself
+   there is not a interoperable way to manage (monitor, control and
+   configure) the internal aspects of a name server itself.
+
+   Previous standardization work within the IETF resulted in the
+   creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
+   to achieve significant implementation and deployment.  The perceived
+   reasons behind the failure for the two MIB modules are further
+   documented in [RFC3197].
+
+   This document discusses the requirements of a management system for
+   DNS name servers.  A management solution that is designed to manage
+   the DNS can use this document as a shopping list of needed features.
+
+   Specifically out of scope for this document are requirements
+   associated with management of stub resolvers.  It is not the intent
+   of this document to document stub resolver requirements, although
+   some of the requirements listed are applicable to stub resolvers as
+   well.
+
+   Also out of scope for this document is management of the host or
+   other components of the host upon which the name server software is
+   running.  This document only discusses requirements for managing the
+   name server component of a system.
+
+   The task of creating a management system for managing DNS servers is
+   not expected to be a small one.  It is likely that components of the
+   solution will need to be designed in parts over time and these
+   requirements take this into consideration.  In particular,
+   Section 5.1 discusses the need for future extensibility of the base
+   management solution.  This document is intended to be a road-map
+   towards a desired outcome and is not intended to define an "all-or-
+   nothing" system.  Successful interoperable management of name servers
+   even in part is expected to be beneficial to network operators
+   compared to the entirely custom solutions that are used at the time
+   of this writing.
+
+1.1.  Requirements notation
+
+   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].
+
+
+
+
+Hardaker                 Expires August 16, 2009                [Page 4]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+1.1.1.  Terminology
+
+   This document is consistent with the terminology defined in Section 2
+   of [RFC4033].  Additional terminology needed for this document is
+   described below:
+
+   Name Server:  When we are discussing servers that don't fall into a
+      more specific type of server category defined in other documents,
+      this document will refer to them generically as "name servers".
+      In particular "name servers" can be considered to be any valid
+      combination of authoritative, recursive, validating, or security-
+      aware.  The more specific name server labels will be used when
+      this document refers only to a specific type of server.  However,
+      the term "name server", in this document, will not include stub
+      resolvers.
+
+1.1.2.  Document Layout and Requirements
+
+   The document is written so that each numbered section will contain
+   only a single requirement if it contains one at all.  Each
+   requirement will contain needed wording from the terminology
+   described in Section 1.1.  Subsections, however, might exist with
+   additional related requirements.  The document is laid out in this
+   way so that a specific requirement can be uniquely referred to using
+   the section number itself and the document version from which it
+   came.
+
+
+2.  Management Architecture Requirements
+
+   This section discusses requirements that reflect the needs of the
+   expected deployment environments.
+
+2.1.  Expected Deployment Scenarios
+
+   DNS zones vary greatly in the type of content published within them.
+   Name Servers, too, are deployed with a wide variety of configurations
+   to support the diversity of the deployed content.  It is important
+   that a management solution trying to meet the criteria specified in
+   this document consider supporting the largest number of potential
+   deployment cases as possible.  Further deployment scenarios that are
+   not used as direct examples of specific requirements are listed in
+   Appendix A.
+
+2.1.1.  Zone Size Constraints
+
+   The management solution MUST support both name servers that are
+   serving a small number of potentially very large zones (e.g.  Top
+
+
+
+Hardaker                 Expires August 16, 2009                [Page 5]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   Level Domains (TLDs)) as well as name servers that are serving a very
+   large number of small zones.  These scenarios are both commonly seen
+   deployments.
+
+2.1.2.  Name Server Discovery
+
+   Large enterprise network deployments may contain multiple name
+   servers operating within the boundaries of the enterprise network.
+   These name servers may each be serving multiple zones both in and out
+   of the parent enterprise's zone.  Finding and managing large
+   quantities of name servers would be a useful feature of the resulting
+   management solution.  The management solution MAY support the ability
+   to discover previously unknown instances of name servers operating
+   within a deployed network.
+
+2.1.3.  Configuration Data Volatility
+
+   Configuration data is defined as data that relates only to the
+   configuration of a server and the zones it serves.  It specifically
+   does not include data from the zone contents that is served through
+   DNS itself.  The solution MUST support servers that remain fairly
+   statically configured over time as well as servers that have numerous
+   zones being added and removed within an hour.  Both of these
+   scenarios are also commonly seen deployments.
+
+2.1.4.  Protocol Selection
+
+   There are many requirements in this document for many different types
+   of management operations (see Section 3 for further details).  It is
+   possible that no one protocol will ideally fill all the needs of the
+   requirements listed in this document and thus multiple protocols
+   might be needed to produce a completely functional management system.
+   Multiple protocols might be used to create the complete management
+   solution, but the number of protocols used SHOULD be reduced to a
+   reasonable minimum number.
+
+2.1.5.  Common Data Model
+
+   Defining a standardized protocol (or set of protocols) to use for
+   managing name servers would be a step forward in achieving an
+   interoperable management solution.  However, just defining a protocol
+   to use by itself would not achieve the complete end goal of a
+   complete interoperable management solution.  Devices also need to
+   represent their internal management interface using a common
+   management data model.  The solution MUST create a common data model
+   that management stations can make use of when sending or collecting
+   data from a managed device so it can successfully manage equipment
+   from vendors as if they were generic DNS servers.  This common data
+
+
+
+Hardaker                 Expires August 16, 2009                [Page 6]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   model is needed for of the operations discussion in Section 3.  Note
+   that this does not preclude the fact that name server vendors might
+   provide additional management infrastructure beyond a base management
+   specification, as discussed further in Section 5.1.
+
+2.1.6.  Operational Impact
+
+   It is impossible to add new features to an existing server (such as
+   the inclusion of a management infrastructure) and not impact the
+   existing service and/or server in some fashion.  At a minimum, for
+   example, more memory, disk and/or CPU resources will be required to
+   implement a new management system.  However, the impact to the
+   existing DNS service MUST be minimized since the DNS service itself
+   is still the primary service to be offered by the modified name
+   server.
+
+2.2.  Name Server Types
+
+   There are multiple ways in which name servers can be deployed.  Name
+   servers can take on any of the following roles:
+
+   o  Master Servers
+
+   o  Slave Servers
+
+   o  Recursive Servers
+
+   The management solution SHOULD support all of these types of name
+   servers as they are all equally important.  Note that "Recursive
+   Servers" can be further broken down by the security sub-roles they
+   might implement, as defined in section 2 of [RFC4033].  These sub-
+   roles are also important to support within any management solution.
+
+   As stated earlier, the management of stub resolvers is considered out
+   of scope for this documents.
+
+
+3.  Management Operation Types
+
+   Management operations can traditionally be broken into four
+   categories:
+
+   o  Control
+
+   o  Configuration
+
+   o  Health and Monitoring
+
+
+
+
+Hardaker                 Expires August 16, 2009                [Page 7]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   o  Alarms and Events
+
+   This section discusses requirements for each of these four management
+   types in detail.
+
+3.1.  Control Requirements
+
+   The management solution MUST be capable of performing basic service
+   control operations.
+
+3.1.1.  Needed Control Operations
+
+   These operations SHOULD include, at a minimum, the following
+   operations:
+
+   o  Starting the name server
+
+   o  Reloading the service configuration
+
+   o  Reloading zone data
+
+   o  Restarting the name server
+
+   o  Stopping the name server
+
+   Note that no restriction is placed on how the management system
+   implements these operations.  In particular, at least "starting the
+   name server" will require a minimal management system component to
+   exist independently of the name server itself.
+
+3.1.2.  Asynchronous Status Notifications
+
+   Some control operations might take a long time to complete.  As an
+   example, some name servers take a long time to perform reloads of
+   large zones.  Because of these timing issues, the management solution
+   SHOULD take this into consideration and offer a mechanism to ease the
+   burden associated with awaiting the status of a long-running command.
+   This could, for example, result in the use of asynchronous
+   notifications for returning the status of a long-running task or it
+   might require the management station to poll for the status of a
+   given task using monitoring commands.  These and other potential
+   solutions need to be evaluated carefully to select one that balances
+   the result delivery needs with the perceived implementation costs.
+
+   Also, see the related discussion in Section 3.4 on notification
+   messages for supporting delivery of alarm and event messages.
+
+
+
+
+
+Hardaker                 Expires August 16, 2009                [Page 8]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+3.2.  Configuration Requirements
+
+   Many features of name servers need to be configured before the server
+   can be considered functional.  The management solution MUST be able
+   to provide name servers with configuration data.  The most important
+   data to be configured, for example, is the served zone data itself.
+
+3.2.1.  Served Zone Modification
+
+   The ability to add, modify and delete zones being served by name
+   servers is needed.  Although there are already solutions for zone
+   content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
+   AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
+   might be used as part of the final management solution, the
+   management system SHOULD still be able to natively create a new zone
+   (with enough minimal data to allow the other mechanisms to function
+   as well) as well as delete a zone.  This might be, for example, a
+   management operation that at least allows for the creation of the
+   initial SOA record for a new zone as that's the minimum amount of
+   zone data needed for the other operations to function.
+
+3.2.2.  Trust Anchor Management
+
+   The solution SHOULD support the ability to add, modify and delete
+   trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
+   [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155].  These trust
+   anchors might be configured using the data from the DNSKEY Resource
+   Records (RRs) themselves or by using Delegation Signer (DS)
+   fingerprints.
+
+3.2.3.  Security Expectations
+
+   DNSSEC Validating resolvers need to make policy decisions about the
+   requests being processed.  For example, they need to be configured
+   with a list of zones expected to be secured by DNSSEC.  The
+   management solution SHOULD be able to add, modify and delete
+   attributes of DNSSEC security policies.
+
+3.2.4.  TSIG Key Management
+
+   TSIG [RFC2845] allows transaction level authentication of DNS
+   traffic.  The management solution SHOULD be able to add, modify and
+   delete TSIG keys known to the name server.
+
+3.2.5.  DNS Protocol Authorization Management
+
+   The management solution SHOULD have the ability to add, modify and
+   delete authorization settings for the DNS protocols itself.  Do not
+
+
+
+Hardaker                 Expires August 16, 2009                [Page 9]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   confuse this with the ability to manage the authorization associated
+   with the management protocol itself, which is discussed later in
+   Section 4.4.  There are a number of authorization settings that are
+   used by a name server.  Example authorization settings that the
+   solution might need to cover are:
+
+   o  Access to operations on zone data (e.g.  DDNS)
+
+   o  Access to certain zone data from certain sources (e.g. from
+      particular network subnets)
+
+   o  Access to specific DNS protocol services (e.g. recursive service)
+
+   Note: the above list is expected to be used as a collection of
+   examples and is not a complete list of needed authorization
+   protections.
+
+3.3.  Monitoring Requirements
+
+   Monitoring is the process of collecting aspects of the internal state
+   of a name server at a given moment in time.  The solution MUST be
+   able to monitor the health of a name server to determine its
+   operational status, load and other internal attributes.  Example
+   management tasks that the solution might need to cover are:
+
+   o  Number of requests sent, responses sent, average response latency
+      and other performance counters
+
+   o  Server status (e.g. "serving data", "starting up", "shutting
+      down", ...)
+
+   o  Access control violations
+
+   o  List of zones being served
+
+   o  Detailed statistics about clients interacting with the name server
+      (e.g. top 10 clients requesting data).
+
+   Note: the above list is expected to be used as a collection of
+   examples and is not a complete list of needed monitoring operations.
+   In particular, some monitoring statistics are expected to be
+   computationally or resource expensive and are considered to be "nice
+   to haves" as opposed to "necessary to have".
+
+3.4.  Alarm and Event Requirements
+
+   Events occurring at the name server that trigger alarm notifications
+   can quickly inform a management station about critical issues.  A
+
+
+
+Hardaker                 Expires August 16, 2009               [Page 10]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   management solution SHOULD include support for delivery of alarm
+   conditions.
+
+   Example alarm conditions might include:
+
+   o  The server's status is changing. (e.g it is starting up, reloading
+      configuration, restarting or shutting down)
+
+   o  A needed resource (e.g. memory or disk space) is exhausted or
+      nearing exhaustion
+
+   o  An authorization violation was detected
+
+   o  The server has not received any data traffic (e.g.  DNS requests
+      or NOTIFYs) recently (AKA the "lonely warning").  This condition
+      might indicate a problem with its deployment.
+
+
+4.  Security Requirements
+
+   The management solution will need to be appropriately secured against
+   attacks on the management infrastructure.
+
+4.1.  Authentication
+
+   The solution MUST support mutual authentication.  The management
+   client needs to be assured that the management operations are being
+   transferred to and from the correct name server.  The managed name
+   server needs to authenticate the system that is accessing the
+   management infrastructure within itself.
+
+4.2.  Integrity Protection
+
+   Management operations MUST be protected from modification while in
+   transit from the management client to the server.
+
+4.3.  Confidentiality
+
+   The management solution MUST support message confidentiality.  The
+   potential transfer of sensitive configuration is expected (such as
+   TSIG keys or security policies).  The solution does not, however,
+   necessarily need to provide confidentiality to data that would
+   normally be carried without confidentiality by the DNS system itself.
+
+4.4.  Authorization
+
+   The solution SHOULD be capable of providing a fine-grained
+   authorization model for any management protocols it introduces to the
+
+
+
+Hardaker                 Expires August 16, 2009               [Page 11]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   completed system.  This authorization differs from the authorization
+   previously discussed in Section 3.2.5 in that this requirement is
+   concerned solely with authorization of the management system itself.
+
+   There are a number of authorization settings that might be used by a
+   managed system to determine whether the managing entity has
+   authorization to perform the given management task.  Example
+   authorization settings that the solution might need to cover are:
+
+   o  Access to the configuration that specifies which zones are to be
+      served
+
+   o  Access to the management system infrastructure
+
+   o  Access to other control operations
+
+   o  Access to other configuration operations
+
+   o  Access to monitoring operations
+
+   Note: the above list is expected to be used as a collection of
+   examples and is not a complete list of needed authorization
+   protections.
+
+4.5.  Solution Impacts on Security
+
+   The solution MUST minimize the security risks introduced to the
+   complete name server system.  It is impossible to add new
+   infrastructure to a server and not impact the security in some
+   fashion as the introduction of a management protocol alone will
+   provide a new avenue for potential attack.  Although the added
+   management benefits will be worth the increased risks, the solution
+   still needs to minimize this impact as much as possible.
+
+
+5.  Other Requirements
+
+5.1.  Extensibility
+
+   The management solution is expected to change and expand over time as
+   lessons are learned and new DNS features are deployed.  Thus, the
+   solution MUST be flexible and be able to accommodate new future
+   management operations.  The solution might, for example, make use of
+   protocol versioning or capability description exchanges to ensure
+   that management stations and name servers that weren't written to the
+   same specification version can still interoperate to the best of
+   their combined ability.
+
+
+
+
+Hardaker                 Expires August 16, 2009               [Page 12]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+5.1.1.  Vendor Extensions
+
+   It MUST be possible for vendors to extend the standardized management
+   model with vendor-specific extensions to support additional features
+   offered by their products.
+
+5.1.2.  Extension Identification
+
+   It MUST be possible for a management station to understand which
+   parts of returned data are specific to a given vendor or other
+   standardized extension.  The data returned needs to be appropriately
+   marked through the use of name spaces or similar mechanisms to ensure
+   that the base management model data can be logically separated from
+   extension data without needing to understand the extension data
+   itself.
+
+5.1.3.  Name-Space Collision Protection
+
+   It MUST be possible to protect against multiple extensions
+   conflicting with each other.  The use of name-space protection
+   mechanisms for communicated management variables is common practice
+   to protect against problems.  Name-space identification techniques
+   also frequently solve the "Extension Identification" requirement
+   discussed in Section 5.1.2 as well.
+
+
+6.  Security Considerations
+
+   Any management protocol that meets the criteria discussed in this
+   document needs to support the criteria discussed in Section 4 in
+   order to protect the management infrastructure itself.  The DNS is a
+   core Internet service and management traffic that protects it could
+   be the target of attacks designed to subvert that service.  Because
+   the management infrastructure will be adding additional interfaces to
+   that service, it is critical that the management infrastructure
+   support adequate protections against network attacks.
+
+
+7.  IANA Considerations
+
+   No action is required from IANA for this document.
+
+
+8.  Document History
+
+   A requirement gathering discussion was held at the December 2007 IETF
+   meeting in Vancouver, BC, Canada and a follow up meeting was held at
+   the March 2008 IETF meeting in Philadelphia.  This document is a
+
+
+
+Hardaker                 Expires August 16, 2009               [Page 13]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   compilation of the results of those discussions as well as
+   discussions on the DCOMA mailing list.
+
+
+9.  Acknowledgments
+
+   This draft is the result of discussions within the DCOMA design team
+   chaired by Jaap Akkerhuis.  This team consisted of a large number of
+   people all of whom provided valuable insight and input into the
+   discussions surrounding name server management.  The text of this
+   document was written from notes taken during meetings as well as from
+   contributions sent to the DCOMA mailing list.  This work documents
+   the consensus of the DCOMA design team.
+
+   In particular, the following team members contributed significantly
+   to the text in the document:
+
+      Stephane Bortzmeyer
+
+      Stephen Morris
+
+      Phil Regnauld
+
+   Further editing contributions and wording suggestions were made by:
+   Alfred Hoenes.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              August 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+
+
+
+Hardaker                 Expires August 16, 2009               [Page 14]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [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.
+
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+              Trust Anchors", RFC 5011, September 2007.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+10.2.  Informative References
+
+   [RFC1611]  Austein, R. and J. Saperia, "DNS Server MIB Extensions",
+              RFC 1611, May 1994.
+
+   [RFC1612]  Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
+              RFC 1612, May 1994.
+
+   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
+              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+              July 1997.
+
+   [RFC3197]  Austein, R., "Applicability Statement for DNS MIB
+              Extensions", RFC 3197, November 2001.
+
+
+Appendix A.  Deployment Scenarios
+
+   This appendix documents some additional deployment scenarios that
+   have been traditionally difficult to manage.  They are provided as
+
+
+
+Hardaker                 Expires August 16, 2009               [Page 15]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   guidance to protocol developers as data points of real-world name
+   server management problems.
+
+A.1.  Non-Standard Zones
+
+   If an organization uses non-standard zones (for example a purely-
+   local TLD), synchronizing all the name servers for these zones is
+   usually a time-consuming task.  It is made worse when two
+   organizations with conflicting zones merge.  This situation is not a
+   recommended deployment scenario (and is even heavily discouraged) but
+   it is, unfortunately, seen in the wild.
+
+   It is typically implemented using "forwarding" zones.  But there is
+   no way to ensure automatically that all the resolvers have the same
+   set of zones to forward at any given time.  New zones might be added
+   to a local forwarding recursive server, for example, without
+   modifying the rest of the deployed forwarding servers.  It is hoped
+   that a management solution which could handle the configuration of
+   zone forwarding would finally allow management of servers deployed in
+   this fashion.
+
+A.2.  Redundancy Sharing
+
+   For reliability reasons it is recommended that zone operators follow
+   the guidelines documented in [RFC2182] which recommends that multiple
+   name servers be configured for each zone and that the name servers
+   are separated both physically and via connectivity routes.  A common
+   solution is to establish DNS-serving partnerships: "I'll host your
+   zones and you'll host mine".  Both entities benefit from increased
+   DNS reliability via the wider service distribution.  This frequently
+   occurs between cooperating but otherwise unrelated entities (such as
+   between two distinct companies) as well as between affiliated
+   organizations (such as between branch offices within a single
+   company).
+
+   The configuration of these relationships are currently required to be
+   manually configured and maintained.  Changes to the list of zones
+   that are cross-hosted are manually negotiated between the cooperating
+   network administrators and configured by hand.  A management protocol
+   with the ability to provide selective authorization, as discussed in
+   Section 4.4, would solve many of the management difficulties between
+   cooperating organizations.
+
+A.3.  DNSSEC Management
+
+   There are many different DNSSEC deployment strategies that may be
+   used for mission-critical zones.  The following list describes some
+   example deployment scenarios that might warrant different management
+
+
+
+Hardaker                 Expires August 16, 2009               [Page 16]
+
+Internet-Draft     Name Server Management Requirements     February 2009
+
+
+   strategies.
+
+      All contents and DNSSEC keying information controlled and operated
+      by a single organization
+
+      Zone contents controlled and operated by one organization, all
+      DNSSEC keying information controlled and operated by a second
+      organization.
+
+      Zone contents controlled and operated by one organization, zone
+      signing keys (ZSKs) controlled and operated by a second
+      organization, and key signing keys (KSKs) controlled and operated
+      by a third organization.
+
+   Although this list is not exhaustive in the potential ways that zone
+   data can be divided up, it should be sufficient to illustrate the
+   potential ways in which zone data can be controlled by multiple
+   entities.
+
+   The end result of all of these strategies, however, will be the same:
+   a live zone containing DNSSEC related resource records.  Many of the
+   above strategies are merely different ways of preparing a zone for
+   serving.  A management solution that includes support for managing
+   DNSSEC zone data may wish to take into account these potential
+   management scenarios.
+
+
+Author's Address
+
+   Wes Hardaker
+   Sparta, Inc.
+   P.O. Box 382
+   Davis, CA  95617
+   US
+
+   Phone: +1 530 792 1913
+   Email: ietf@hardakers.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 16, 2009               [Page 17]
+
diff --git a/doc/draft/draft-ietf-dnsop-respsize-02.txt b/doc/draft/draft-ietf-dnsop-respsize-02.txt
deleted file mode 100644
index 63fe2de521ae..000000000000
--- a/doc/draft/draft-ietf-dnsop-respsize-02.txt
+++ /dev/null
@@ -1,480 +0,0 @@
-
-
-
-
-
-
-   DNSOP Working Group                                     Paul Vixie, ISC
-   INTERNET-DRAFT                                         Akira Kato, WIDE
-                               July 2005
-
-                           DNS Response Size Issues
-
-   Status of this Memo
-      By submitting this Internet-Draft, each author represents that any
-      applicable patent or other IPR claims of which he or she is aware
-      have been or will be disclosed, and any of which he or she becomes
-      aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-      Internet-Drafts are working documents of the Internet Engineering
-      Task Force (IETF), its areas, and its working groups.  Note that
-      other groups may also distribute working documents as Internet-
-      Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of six months
-      and may be updated, replaced, or obsoleted by other documents at any
-      time.  It is inappropriate to use Internet-Drafts as reference
-      material or to cite them other than as "work in progress."
-
-      The list of current Internet-Drafts can be accessed at
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-      The list of Internet-Draft Shadow Directories can be accessed at
-      http://www.ietf.org/shadow.html.
-
-   Copyright Notice
-
-      Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-
-
-
-                                    Abstract
-
-      With a mandated default minimum maximum message size of 512 octets,
-      the DNS protocol presents some special problems for zones wishing to
-      expose a moderate or high number of authority servers (NS RRs).  This
-      document explains the operational issues caused by, or related to
-      this response size limit.
-
-
-
-
-
-
-   Expires December 2005                                           [Page 1]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   1 - Introduction and Overview
-
-   1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
-   octets.  Even though this limitation was due to the required minimum UDP
-   reassembly limit for IPv4, it is a hard DNS protocol limit and is not
-   implicitly relaxed by changes in transport, for example to IPv6.
-
-   1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
-   responses by mutual agreement of the requestor and responder.  However,
-   deployment of EDNS0 cannot be expected to reach every Internet resolver
-   in the short or medium term.  The 512 octet message size limit remains
-   in practical effect at this time.
-
-   1.3. Since DNS responses include a copy of the request, the space
-   available for response data is somewhat less than the full 512 octets.
-   For negative responses, there is rarely a space constraint.  For
-   positive and delegation responses, though, every octet must be carefully
-   and sparingly allocated.  This document specifically addresses
-   delegation response sizes.
-
-   2 - Delegation Details
-
-   2.1. A delegation response will include the following elements:
-
-      Header Section: fixed length (12 octets)
-      Question Section: original query (name, class, type)
-      Answer Section: (empty)
-      Authority Section: NS RRset (nameserver names)
-      Additional Section: A and AAAA RRsets (nameserver addresses)
-
-   2.2. If the total response size would exceed 512 octets, and if the data
-   that would not fit belonged in the question, answer, or authority
-   section, then the TC bit will be set (indicating truncation) which may
-   cause the requestor to retry using TCP, depending on what information
-   was desired and what information was omitted.  If a retry using TCP is
-   needed, the total cost of the transaction is much higher.  (See [RFC1123
-   6.1.3.2] for details on the protocol requirement that UDP be attempted
-   before falling back to TCP.)
-
-   2.3. RRsets are never sent partially unless truncation occurs, in which
-   case the final apparent RRset in the final nonempty section must be
-   considered "possibly damaged".  With or without truncation, the glue
-   present in the additional data section should be considered "possibly
-   incomplete", and requestors should be prepared to re-query for any
-   damaged or missing RRsets.  For multi-transport name or mail services,
-
-
-
-   Expires December 2005                                           [Page 2]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A)
-   RRset is present.
-
-   2.4. DNS label compression allows a domain name to be instantiated only
-   once per DNS message, and then referenced with a two-octet "pointer"
-   from other locations in that same DNS message.  If all nameserver names
-   in a message are similar (for example, all ending in ".ROOT-
-   SERVERS.NET"), then more space will be available for uncompressable data
-   (such as nameserver addresses).
-
-   2.5. The query name can be as long as 255 characters of presentation
-   data, which can be up to 256 octets of network data.  In this worst case
-   scenario, the question section will be 260 octets in size, which would
-   leave only 240 octets for the authority and additional sections (after
-   deducting 12 octets for the fixed length header.)
-
-   2.6. Average and maximum question section sizes can be predicted by the
-   zone owner, since they will know what names actually exist, and can
-   measure which ones are queried for most often.  For cost and performance
-   reasons, the majority of requests should be satisfied without truncation
-   or TCP retry.
-
-   2.7. Requestors who deliberately send large queries to force truncation
-   are only increasing their own costs, and cannot effectively attack the
-   resources of an authority server since the requestor would have to retry
-   using TCP to complete the attack.  An attack that always used TCP would
-   have a lower cost.
-
-   2.8. The minimum useful number of address records is two, since with
-   only one address, the probability that it would refer to an unreachable
-   server is too high.  Truncation which occurs after two address records
-   have been added to the additional data section is therefore less
-   operationally significant than truncation which occurs earlier.
-
-   2.9. The best case is no truncation.  This is because many requestors
-   will retry using TCP by reflex, or will automatically re-query for
-   RRsets that are "possibly truncated", without considering whether the
-   omitted data was actually necessary.
-
-   2.10. Each added NS RR for a zone will add a minimum of between 16 and
-   44 octets to every untruncated referral or negative response from the
-   zone's authority servers (16 octets for an NS RR, 16 octets for an A RR,
-   and 28 octets for an AAAA RR), in addition to whatever space is taken by
-   the nameserver name (NS NSDNAME and A/AAAA owner name).
-
-
-
-
-   Expires December 2005                                           [Page 3]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   3 - Analysis
-
-   3.1. An instrumented protocol trace of a best case delegation response
-   follows.  Note that 13 servers are named, and 13 addresses are given.
-   This query was artificially designed to exactly reach the 512 octet
-   limit.
-
-      ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
-      ;; QUERY SECTION:
-      ;;  [23456789.123456789.123456789.\
-           123456789.123456789.123456789.com A IN]        ;; @80
-
-      ;; AUTHORITY SECTION:
-      com.                 86400 NS  E.GTLD-SERVERS.NET.  ;; @112
-      com.                 86400 NS  F.GTLD-SERVERS.NET.  ;; @128
-      com.                 86400 NS  G.GTLD-SERVERS.NET.  ;; @144
-      com.                 86400 NS  H.GTLD-SERVERS.NET.  ;; @160
-      com.                 86400 NS  I.GTLD-SERVERS.NET.  ;; @176
-      com.                 86400 NS  J.GTLD-SERVERS.NET.  ;; @192
-      com.                 86400 NS  K.GTLD-SERVERS.NET.  ;; @208
-      com.                 86400 NS  L.GTLD-SERVERS.NET.  ;; @224
-      com.                 86400 NS  M.GTLD-SERVERS.NET.  ;; @240
-      com.                 86400 NS  A.GTLD-SERVERS.NET.  ;; @256
-      com.                 86400 NS  B.GTLD-SERVERS.NET.  ;; @272
-      com.                 86400 NS  C.GTLD-SERVERS.NET.  ;; @288
-      com.                 86400 NS  D.GTLD-SERVERS.NET.  ;; @304
-
-      ;; ADDITIONAL SECTION:
-      A.GTLD-SERVERS.NET.  86400 A   192.5.6.30           ;; @320
-      B.GTLD-SERVERS.NET.  86400 A   192.33.14.30         ;; @336
-      C.GTLD-SERVERS.NET.  86400 A   192.26.92.30         ;; @352
-      D.GTLD-SERVERS.NET.  86400 A   192.31.80.30         ;; @368
-      E.GTLD-SERVERS.NET.  86400 A   192.12.94.30         ;; @384
-      F.GTLD-SERVERS.NET.  86400 A   192.35.51.30         ;; @400
-      G.GTLD-SERVERS.NET.  86400 A   192.42.93.30         ;; @416
-      H.GTLD-SERVERS.NET.  86400 A   192.54.112.30        ;; @432
-      I.GTLD-SERVERS.NET.  86400 A   192.43.172.30        ;; @448
-      J.GTLD-SERVERS.NET.  86400 A   192.48.79.30         ;; @464
-      K.GTLD-SERVERS.NET.  86400 A   192.52.178.30        ;; @480
-      L.GTLD-SERVERS.NET.  86400 A   192.41.162.30        ;; @496
-      M.GTLD-SERVERS.NET.  86400 A   192.55.83.30         ;; @512
-
-      ;; MSG SIZE  sent: 80  rcvd: 512
-
-
-
-
-
-   Expires December 2005                                           [Page 4]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   3.2. For longer query names, the number of address records supplied will
-   be lower.  Furthermore, it is only by using a common parent name (which
-   is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
-   fit.  The following output from a response simulator demonstrates these
-   properties:
-
-      % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
-      a.dns.br requires 10 bytes
-      b.dns.br requires 4 bytes
-      c.dns.br requires 4 bytes
-      d.dns.br requires 4 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
-      For average size query (64 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 4 (green)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-      % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
-      ns-ext.isc.org requires 16 bytes
-      ns.psg.com requires 12 bytes
-      ns.ripe.net requires 13 bytes
-      ns.eu.int requires 11 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
-      For average size query (64 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 4 (green)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-   (Note: The response simulator program is shown in Section 5.)
-
-   Here we use the term "green" if all address records could fit, or
-   "orange" if two or more could fit, or "red" if fewer than two could fit.
-   It's clear that without a common parent for nameserver names, much space
-   would be lost.  For these examples we use an average/common name size of
-   15 octets, befitting our assumption of GTLD-SERVERS.NET as our common
-   parent name.
-
-
-
-
-   Expires December 2005                                           [Page 5]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   We're assuming an average query name size of 64 since that is the
-   typical average maximum size seen in trace data at the time of this
-   writing.  If Internationalized Domain Name (IDN) or any other technology
-   which results in larger query names be deployed significantly in advance
-   of EDNS, then new measurements and new estimates will have to be made.
-
-   4 - Conclusions
-
-   4.1. The current practice of giving all nameserver names a common parent
-   (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
-   responses and allows for more nameservers to be enumerated than would
-   otherwise be possible.  (Note that in this case it is wise to serve the
-   common parent domain's zone from the same servers that are named within
-   it, in order to limit external dependencies when all your eggs are in a
-   single basket.)
-
-   4.2. Thirteen (13) seems to be the effective maximum number of
-   nameserver names usable traditional (non-extended) DNS, assuming a
-   common parent domain name, and given that response truncation is
-   undesirable as an average case, and assuming mostly IPv4-only
-   reachability (only A RRs exist, not AAAA RRs).
-
-   4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
-   prototypical delegation that currently contains thirteen (13) IPv4
-   nameserver addresses (A RRs) for thirteen (13) nameserver names under a
-   common parent, would not have a significant negative operational impact
-   on the domain name system.
-
-   5 - Source Code
-
-   #!/usr/bin/perl
-   #
-   # SYNOPSIS
-   #    repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
-   #        if all queries are assumed to have zone suffux, such as "jp" in
-   #     JP TLD servers, specify it in -z option
-   #
-   use strict;
-   use Getopt::Std;
-   my ($sz_msg) = (512);
-   my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
-   my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
-   my (%namedb, $name, $nssect, %opts, $optz);
-   my $n_ns = 0;
-
-
-
-
-   Expires December 2005                                           [Page 6]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   getopt('z', opts);
-   if (defined($opts{'z'})) {
-        server_name_len($opts{'z'}); # just register it
-   }
-
-   foreach $name (@ARGV) {
-        my $len;
-        $n_ns++;
-        $len = server_name_len($name);
-           print "$name requires $len bytes\n";
-        $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + $sz_rdlen + $len;
-   }
-   print "# of NS: $n_ns\n";
-   arsect(255, $nssect, $n_ns, "maximum");
-   arsect(64, $nssect, $n_ns, "average");
-
-   sub server_name_len {
-       my ($name) = @_;
-       my (@labels, $len, $n, $suffix);
-
-       $name =~ tr/A-Z/a-z/;
-       @labels = split(/./, $name);
-       $len = length(join('.', @labels)) + 2;
-       for ($n = 0; $#labels >= 0; $n++, shift @labels) {
-           $suffix = join('.', @labels);
-           return length($name) - length($suffix) + $sz_ptr
-               if (defined($namedb{$suffix}));
-           $namedb{$suffix} = 1;
-       }
-       return $len;
-   }
-
-   sub arsect {
-       my ($sz_query, $nssect, $n_ns, $cond) = @_;
-       my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
-       $ansect = $sz_query + 1 + $sz_type + $sz_class;
-       $space = $sz_msg - $sz_header - $ansect - $nssect;
-       $n_a = atmost(int($space / $sz_rr_a), $n_ns);
-       $n_a_aaaa = atmost(int($space / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
-       $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) / $sz_rr_aaaa), $n_ns);
-       printf "For %s size query (%d byte):\n", $cond, $sz_query;
-       printf "if only A is considered:     ";
-       printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
-       printf "if A and AAAA are condered:  ";
-       printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
-
-
-
-   Expires December 2005                                           [Page 7]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-       printf "if prefer_glue A is assumed: ";
-       printf "# of A is %d, # of AAAA is %d (%s)\n",
-           $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
-   }
-
-   sub judge {
-       my ($n, $n_ns) = @_;
-       return "green" if ($n >= $n_ns);
-       return "yellow" if ($n >= 2);
-       return "orange" if ($n == 1);
-       return "red";
-   }
-
-   sub atmost {
-       my ($a, $b) = @_;
-       return 0 if ($a < 0);
-       return $b if ($a > $b);
-       return $a;
-   }
-
-   Security Considerations
-
-   The recommendations contained in this document have no known security
-   implications.
-
-   IANA Considerations
-
-   This document does not call for changes or additions to any IANA
-   registry.
-
-   IPR Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except as
-   set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
-   IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-   Expires December 2005                                           [Page 8]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   Authors' Addresses
-
-   Paul Vixie
-      950 Charter Street
-      Redwood City, CA 94063
-      +1 650 423 1301
-      vixie@isc.org
-
-   Akira Kato
-      University of Tokyo, Information Technology Center
-      2-11-16 Yayoi Bunkyo
-      Tokyo 113-8658, JAPAN
-      +81 3 5841 2750
-      kato@wide.ad.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-   Expires December 2005                                           [Page 9]
-
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsop-respsize-06.txt b/doc/draft/draft-ietf-dnsop-respsize-06.txt
new file mode 100644
index 000000000000..b041925afbcc
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-respsize-06.txt
@@ -0,0 +1,640 @@
+
+
+
+
+
+
+   DNSOP Working Group                                     Paul Vixie, ISC
+   INTERNET-DRAFT                                         Akira Kato, WIDE
+                             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 c6ec7e42a559..000000000000
--- 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/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
deleted file mode 100644
index 3353b3bb423f..000000000000
--- a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
+++ /dev/null
@@ -1,1588 +0,0 @@
-
-                                                            Mark Foster 
-Internet Draft                                              Tom McGarry 
-Document:                 James Yu 
-                                                          NeuStar, Inc. 
-Category: Informational                                   June 24, 2002 
- 
- 
-              Number Portability in the GSTN: An Overview 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [RFC].  
- 
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. Internet-Drafts are draft documents valid for a maximum of 
-   six months and may be updated, replaced, or obsoleted by other 
-   documents at any time. It is inappropriate to use Internet- Drafts 
-   as reference material or to cite them other than as "work in 
-   progress."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt. 
-     
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
- 
-   Copyright Notice 
- 
-      Copyright (C) The Internet Society (2002).  All rights reserved. 
-    
-    
-   Abstract 
-    
-   This document provides an overview of E.164 telephone number 
-   portability (NP) in the Global Switched Telephone Network (GSTN).    
-   NP is a regulatory imperative seeking to liberalize local telephony 
-   service competition, by enabling end-users to retain telephone 
-   numbers while changing service providers.  NP changes the 
-   fundamental nature of a dialed E.164 number from a hierarchical 
-   physical routing address to a virtual address, thereby requiring the 
-   transparent translation of the later to the former.  In addition, 
-   there are various regulatory constraints that establish relevant 
-   parameters for NP implementation, most of which are not network 
-   technology specific.  Consequently, the implementation of NP 
-   behavior consistent with applicable regulatory constraints, as well 
-   as the need for interoperation with the existing GSTN NP 
-   implementations, are relevant topics for numerous areas of IP 
-   telephony work-in-progress at IETF. 
-  
-Foster,McGarry,Yu         Expired on December 23, 2002        [Page 1] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-    
-   Table of Contents 
-    
-    1.  Introduction ...............................................  2 
-    2.  Abbreviations and Acronyms .................................  4 
-    3.  Types of Number Portability ................................  5 
-    4.  Service Provider Number Portability Schemes ................  7 
-       4.1   All Call Query (ACQ) ..................................  7 
-       4.2   Query on Release (QoR) ................................  8 
-       4.3   Call Dropback .........................................  9 
-       4.4   Onward Routing (OR) ...................................  9 
-       4.5   Comparisons of the Four Schemes ....................... 10 
-    5.  Database Queries in the NP Environment ..................... 11 
-       5.1   U.S. and Canada ....................................... 12 
-       5.2   Europe ................................................ 13 
-    6.  Call Routing in the NP Environment ......................... 14 
-       6.1   U.S. and Canada ....................................... 14 
-       6.2   Europe ................................................ 15 
-    7.  NP Implementations for Geographic E.164 Numbers ............ 17 
-    8.  Number Conservation Method Enabled By NP ................... 20 
-       8.1   Block Pooling ......................................... 20 
-       8.2   ITN Pooling ........................................... 21 
-    9.  Potential Implications ..................................... 21 
-   10.  Security Considerations .................................... 24 
-   11.  IANA Considerations ........................................ 24 
-   12.  Normative References ....................................... 24 
-   13.  Informative References ..................................... 25 
-   14.  Acknowledgement ............................................ 25 
-   15.  AuthorsË Addresses ......................................... 25 
-    
- 
-    
-1. Introduction 
-    
-   This document provides an overview of E.164 telephone number 
-   portability in the Global Switched Telephone Network (GSTN).  There 
-   are considered to be three types of number portability (NP): service 
-   provider portability (SPNP), location portability (not to be 
-   confused with terminal mobility), and service portability. 
-    
-   Service provider portability (SPNP), the focus of the present draft, 
-   is a regulatory imperative in many countries seeking to liberalize 
-   telephony service competition, especially local service.  
-   Historically, local telephony service (as compared to long distance 
-   or international service) has been regulated as a utility-like form 
-   of service.  While a number of countries had begun liberalization 
-   (e.g. privatization, de-regulation, or re-regulation) some years 
-   ago, the advent of NP is relatively recent (since ~1995). 
-    
-   E.164 numbers can be non-geographic and geographic numbers.  Non-
-   geographic numbers do not reveal the locations information of those 
-   numbers.  Geographic E.164 numbers were intentionally designed as 
-   hierarchical routing addresses which could systematically be digit-
-   analyzed to ascertain the country, serving network provider, serving 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 2] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   end-office switch, and specific line of the called party.  As such, 
-   without NP a subscriber wishing to change service providers would 
-   incur a number change as a consequence of being served off of a 
-   different end-office switch operated by the new service provider.  
-   The cost and convenience impact to the subscriber of changing 
-   numbers is seen as barrier to competition.  Hence NP has become 
-   associated with GSTN infrastructure enhancements associated with a 
-   competitive environment driven by regulatory directives. 
-    
-   Forms of SPNP have been deployed or are being deployed widely in the 
-   GSTN in various parts of the world, including the U.S., Canada, 
-   Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). 
-   Other regions, such as South America (e.g. Brazil) are actively 
-   considering it. 
-    
-   Implementation of NP within a national telephony infrastructure 
-   entails potentially significant changes to numbering administration, 
-   network element signaling, call routing and processing, billing, 
-   service management, and other functions. 
-    
-   NP changes the fundamental nature of a dialed E.164 number from a 
-   hierarchical physical routing address to a virtual address.  NP 
-   implementations attempt to encapsulate the impacts to the GSTN and 
-   make NP transparent to subscribers by incorporating a translation 
-   function to map a dialed, potentially ported E.164 address, into a 
-   network routing address (either a number prefix or another E.164 
-   address) which can be hierarchically routed. 
-    
-   This is roughly analogous to the use of network address translation 
-   on IP addresses to enable IP address portability by containing the 
-   impact of the address change to the edge of the network and retain 
-   the use of CIDR blocks in the core which can be route aggregated by 
-   the network service provider to the rest of the internet. 
-    
-   NP bifurcates the historical role of a subscriberËs E.164 address 
-   into two or more data elements (a dialed or virtual address, and a 
-   network routing address) that must be made available to network 
-   elements through an NP translations database, carried by forward 
-   call signaling, and recorded on call detail records.  Not only is 
-   call processing and routing affected, but also so is SS7/C7 
-   messaging.  A number of TCAP-based SS7 messaging sets utilize an 
-   E.164 address as an application-level network element address in the 
-   global title address (GTA) field of the SCCP message header.  
-   Consequently, SS7/C7 signaling transfer points (STPs) and gateways 
-   need to be able to perform n-digit global title translation (GTT) to 
-   translate a dialed E.164 address into its network address 
-   counterpart via the NP database. 
-    
-   In addition, there are various national regulatory constraints that 
-   establish relevant parameters for NP implementation, most of which 
-   are not network technology specific.  Consequently, implementations 
-   of NP behavior in IP telephony consistent with applicable regulatory 
-   constraints, as well as the need for interoperation with the 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 3] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   existing GSTN NP implementations, are relevant topics for numerous 
-   areas of IP telephony work-in-progress at IETF. 
-    
-   This document describes three types of number portability and the 
-   four schemes that have been standardized to support SPNP for 
-   geographic E.164 numbersspecifically.  Following that, specific 
-   information regarding the call routing and database query 
-   implementations are described for several regions (North American 
-   and Europe) and industries (wireless vs. wireline). The Number 
-   Portability Database (NPDB) interfaces and the call routing schemes 
-   that are used in the North America and Europe are described to show 
-   the variety of standards that may be implemented worldwide.  A 
-   glance of the NP implementations worldwide is provided.  Number 
-   pooling is briefly discussed to show how NP is being enhanced in the 
-   U.S. to conserve North American area codes.  The conclusion briefly 
-   touches the potential impacts of NP on IP & Telecommunications 
-   Interoperability.  Appendix A provides some specific technical and 
-   regulatory information on NP in North America.  Appendix B describes 
-   the number portability administration process that manages the 
-   number portability database in North America. 
-    
-    
-2. Abbreviations and Acronyms 
-    
-   ACQ     All Call Query 
-   AIN     Advanced Intelligent Network 
-   AMPS    Advanced Mobile Phone System 
-   ANSI    American National Standards Institute 
-   CDMA    Code Division Multiple Access 
-   CdPA    Called Party Address 
-   CdPN    Called Party Number 
-   CH      Code Holder 
-   CMIP    Common Management Information Protocol 
-   CS1     Capability Set 1 
-   CS2     Capability Set 2 
-   DN      Directory Number 
-   DNS     Domain Name System 
-   ETSI    European Technical Standards Institute 
-   FCI     Forward Call Indicator 
-   GAP     Generic Address Parameter 
-   GMSC    Gateway Mobile Services Switching Center or Gateway Mobile 
-           Switching Center 
-   GSM     Global System for Mobile Communications 
-   GSTN    Global Switched Telephone Network 
-   GW      Gateways 
-   HLR     Home Location Register 
-   IAM     Initial Address Message 
-   IETF    Internet Engineering Task Force 
-   ILNP    Interim LNP 
-   IN      Intelligent Network 
-   INAP    Intelligent Network Application Part 
-   INP     Interim NP     
-   IP      Internet Protocol 
-   IS-41   Interim Standards Number 41 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 4] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   ISDN    Integrated Services Digital Network 
-   ISUP    ISDN User Part 
-   ITN     Individual Telephony Number  
-   ITU     International Telecommunication Union 
-   ITU-TS  ITU-Telecommunication Sector 
-   LDAP    Lightweight Directory Access Protocol  
-   LEC     Local Exchange Carrier 
-   LERG    Local Exchange Routing Guide 
-   LNP     Local Number Portability 
-   LRN     Location Routing Number 
-   MAP     Mobile Application Part 
-   MNP     Mobile Number Portability 
-   MSRN    Mobile Station Roaming Number 
-   MTP     Message Transfer Part 
-   NANP    North American Numbering Plan 
-   NP      Number Portability 
-   NPDB    Number Portability Database 
-   NRN     Network Routing Number 
-   OR      Onward Routing 
-   OSS     Operation Support System 
-   PCS     Personal Communication Services 
-   PNTI    Ported Number Translation Indicator 
-   PODP    Public Office Dialing Plan 
-   PUC     Public Utility Commission 
-   QoR     Query on Release 
-   RN      Routing Number 
-   RTP     Return to Pivot 
-   SCCP    Signaling Connection Control Part 
-   SCP     Service Control Point  
-   SIP     Session Initiation Protocol 
-   SMR     Special Mobile Radio 
-   SMS     Service Management System 
-   SPNP    Service Provider Number Portability 
-   SRF     Signaling Relaying Function 
-   SRI     Send Routing Information 
-   SS7     Signaling System Number 7 
-   STP     Signaling Transfer Point 
-   TCAP    Transaction Capabilities Application Part 
-   TDMA    Time Division Multiple Access 
-   TN      Telephone Number 
-   TRIP    Telephony Routing Information Protocol 
-   URL     Universal Resource Locator 
-   U.S.    United States 
-    
-    
-3. Types of Number Portability 
-    
-   As there are several types of E.164 numbers (telephone numbers, or 
-   just TN) in the GSTN, there are correspondingly several types of 
-   E.164 NP in the GSTN.  First there are so-call non-geographic E.164 
-   numbers, commonly used for service-specific applications such as 
-   freephone (800 or 0800).  Portability of these numbers is called 
-   non-geographic number portability (NGNP).  NGNP, for example, was 
-   deployed in the U.S. in 1986-92. 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 5] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-    
-   Geographic number portability, which includes traditional fixed or 
-   wireline numbers as well as mobile numbers which are allocated out 
-   of geographic number range prefixes, is called NP or GNP or in the 
-   U.S. local number portability (LNP). 
-    
-   Number portability allows the telephony subscribers in the Global 
-   Switched Telephone Network (GSTN) to keep their phone numbers when 
-   they change their service providers or subscribed services, or when 
-   they move to a new location.   
-    
-   The ability to change the service provider while keeping the same 
-   phone number is called service provider portability (SPNP) also 
-   known as "operator portability." 
-    
-   The ability to change the subscriberËs fixed service location while 
-   keeping the same phone number is called location portability. 
-    
-   The ability to change the subscribed services (e.g., from the plain 
-   old telephone service to Integrated Services Digital Network (ISDN) 
-   services) while keeping the same phone number is called service 
-   portability.  Another aspect of service portability is to allow the 
-   subscribers to enjoy the subscribed services in the same way when 
-   they roam outside their home networks as is supported by the 
-   cellular/wireless networks. 
-    
-   In addition, mobile number portability (MNP) refers to specific NP 
-   implementation in mobile networks either as part of a broader NP 
-   implementation in the GSTN or on a stand-alone basis.  Where 
-   interoperation of LNP and MNP is supported, service portability 
-   between fixed and mobile service types is possible. 
-    
-   At present, SPNP has been the primary form of NP deployed due to its 
-   relevance in enabling local service competition. 
-    
-   Also in use in the GSTN are the terms interim NP (INP) or Interim 
-   LNP (ILNP) and true NP.  Interim NP usually refers to the use of 
-   remote call forwarding-like measures to forward calls to ported 
-   numbers through the donor network to the new service network.  These 
-   are considered interim relative to true NP, which seeks to remove 
-   the donor network or old service provider from the call or signaling 
-   path altogether.  Often the distinction between interim and true NP 
-   is a national regulatory matter relative to the 
-   technical/operational requirements imposed on NP in that country. 
-    
-   Implementations of true NP in certain countries (e.g. U.S., Canada, 
-   Spain, Belgium, Denmark) may pose specific requirements for IP 
-   telephony implementations as a result of regulatory and industry 
-   requirements for providing call routing and signaling independent of 
-   the donor network or last previous serving network. 
-    
-    
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 6] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
- 
-4. Service Provider Number Portability Schemes 
-    
-   Four schemes can be used to support service provider portability and 
-   are briefly described below.  But first, some further terms are 
-   introduced. 
-    
-   The donor network is the network that first assigned a telephone 
-   number (e.g., TN +1-202-533-1234) to a subscriber, out of a number 
-   range administratively (e.g., +1 202-533) assigned to it.  The 
-   current service provider (new SP) or new serving network is the 
-   network that currently serves the ported number. The old serving 
-   network (or old SP) is the network that previously served the ported 
-   number before the number was ported to the new serving network. 
-   Since a TN can port a number of times, the old SP is not necessarily 
-   the same as the donor network, except for the first time the TN 
-   ports away, or if the TN ports back into the donor network and away 
-   again.  While the new SP and old SP roles are transitory as a TN 
-   ports around, the donor network is always the same for any 
-   particular TN based on the service provider to whom the subtending 
-   number range was administratively assigned.  See the discussion 
-   below on number pooling, as this enhancement to NP further 
-   bifurcates the role of donor network into two (the number range or 
-   code holder network, and the block holder network). 
-    
-   To simplify the illustration, all the transit networks are ignored, 
-   the originating or donor network is the one that performs the 
-   database queries or call redirection, and the dialed directory 
-   number (TN) has been ported out of the donor network before.  
-    
-   It is assumed that the old serving network, the new serving network 
-   and the donor network are different networks so as to show which 
-   networks are involved in call handling and routing and database 
-   queries in each of four schemes.  Please note that the port of the 
-   number (process of moving it from one network to another) happened 
-   prior to the call setup and is not included in the call steps.  
-   Information carried in the signaling messages to support each of the 
-   four schemes is not discussed to simplify the explanation. 
-    
-    
-4.1 All Call Query (ACQ) 
-    
-   Figure 1 shows the call steps for the ACQ scheme.  Those call steps 
-   are as follows: 
- 
-   (1) The Originating Network receives a call from the caller and 
-       sends a query to a centrally administered Number Portability 
-       Database (NPDB), a copy of which is usually resident on a 
-       network element within its network or through a third party 
-       provider. 
-   (2) The NPDB returns the routing number associated with the dialed 
-       directory number.  The routing number is discussed later in 
-       Section 6. 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 7] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   (3) The Originating Network uses the routing number to route the 
-       call to the new serving network. 
-    
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    ported   | Old Serv. | 
-   |    NPDB     |    +-------->|  Network  |<------------|  Network  | 
-   +-------------+    |         +-----------+             +-----------+ 
-       ^  |           | 
-       |  |           | 
-      1|  |         3.| 
-       |  | 2.        | 
-       |  |           | 
-       |  v           | 
-    +----------+      |         +----------+           +----------+ 
-    |   Orig.  |------+         |   Donor  |           | Internal | 
-    |  Network |                |  Network |           |   NPDB   | 
-    +----------+                +----------+           +----------+ 
-    
-    
-              Figure 1 - All Call Query (ACQ) Scheme. 
- 
- 
-4.2 Query on Release (QoR) 
- 
-  Figure 2 shows the call steps for the QoR scheme.  Those call steps 
-  are as follows: 
-    
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    ported   | Old Serv. | 
-   |    NPDB     |              |  Network  |<------------|  Network  | 
-   +-------------+              +-----------+             +-----------+ 
-       ^  |                          ^ 
-       |  | 4.                       | 
-     3.|  |              5.          | 
-       |  |   +----------------------+ 
-       |  |   | 
-       |  v   | 
-    +----------+      2.        +----------+           +----------+ 
-    |   Orig.  |<---------------|   Donor  |           | Internal | 
-    |  Network |--------------->|  Network |           |   NPDB   | 
-    +----------+      1.        +----------+           +----------+ 
-    
-                   
-                Figure 2 - Query on Release (QoR) Scheme. 
-    
-   (1) The Originating Network receives a call from the caller and 
-       routes the call to the donor network. 
-   (2) The donor network releases the call and indicates that the 
-       dialed directory number has been ported out of that switch. 
-   (3) The Originating Network sends a query to its copy of the 
-       centrally administered NPDB. 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 8] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   (4) The NPDB returns the routing number associated with the dialed 
-       directory number.   
-   (5) The Originating Network uses the routing number to route the 
-       call to the new serving network. 
-    
-    
-4.3 Call Dropback 
-    
-  Figure 3 shows the call steps for the Dropback scheme.  This scheme 
-  is also known as "Return to Pivot (RTP)."  Those call steps are as 
-  follows: 
-    
-   (1) The Originating Network receives a call from the caller and 
-       routes the call to the donor network. 
-   (2) The donor network detects that the dialed directory number has 
-       been ported out of the donor switch and checks with an internal 
-       network-specific NPDB.  
-   (3) The internal NPDB returns the routing number associated with the 
-       dialed directory number. 
-   (4) The donor network releases the call by providing the routing 
-       number. 
-   (5) The Originating Network uses the routing number to route the 
-       call to the new serving network. 
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    porting  | Old Serv. | 
-   |    NPDB     |              |  Network  |<------------|  Network  | 
-   +-------------+              +-----------+             +-----------+ 
-                                    /\ 
-                                     | 
-                           5.        | 
-            +------------------------+ 
-            | 
-            | 
-    +----------+       4.       +----------+     3.    +----------+ 
-    |   Orig.  |<---------------|   Donor  |<----------| Internal | 
-    |  Network |--------------->|  Network |---------->|   NPDB   | 
-    +----------+      1.        +----------+    2.     +----------+ 
-    
-                   
-                      Figure 3 - Dropback Scheme. 
-    
-    
-4.4 Onward Routing (OR) 
-    
-  Figure 4 shows the call steps for the OR scheme.  Those call steps 
-  are as follows: 
-    
-   (1) The Originating Network receives a call from the caller and 
-       routes the call to the donor network. 
-   (2) The donor network detects that the dialed directory number has 
-       been ported out of the donor switch and checks with an internal 
-       network-specific NPDB.  
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 9] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   (3) The internal NPDB returns the routing number associated with the 
-       dialed directory number. 
-   (4) The donor network uses the routing number to route the call to 
-       the new serving network. 
- 
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    porting  | Old Serv. | 
-   |    NPDB     |              |  Network  |<------------|  Network  | 
-   +-------------+              +-----------+             +-----------+ 
-                                    /\ 
-                                     | 
-                                   4.| 
-                                     | 
-    +----------+                +----------+     3.    +----------+ 
-    |   Orig.  |                |   Donor  |<----------| Internal | 
-    |  Network |--------------->|  Network |---------->|   NPDB   | 
-    +----------+      1.        +----------+    2.     +----------+ 
-    
-                   
-                 Figure 4 - Onward Routing (OR) Scheme. 
- 
-4.5 Comparisons of the Four Schemes 
-    
-   Only the ACQ scheme does not involve the donor network when routing 
-   the call to the new serving network of the dialed ported number.  
-   The other three schemes involve call setup to or signaling with the 
-   donor network.   
-    
-   Only the OR scheme requires the setup of two physical call segments, 
-   one from the Originating Network to the donor network and the other 
-   from the donor network to the new serving network.  The OR scheme is 
-   the least efficient in terms of using the network transmission 
-   facilities.  The QoR and Dropback schemes set up calls to the donor 
-   network first but release the call back to the Originating Network 
-   that then initiates a new call to the Current Serving Network.  For 
-   the QoR and Dropback schemes, circuits are still reserved one by one 
-   between the Originating Network and the donor network when the 
-   Originating Network sets up the call towards the donor network.  
-   Those circuits are released one by one when the call is released 
-   from the donor network back to the Originating Network.  The ACQ 
-   scheme is the most efficient in terms of using the switching and 
-   transmission facilities for the call. 
-    
-   Both the ACQ and QoR schemes involve Centralized NPDBs for the 
-   Originating Network to retrieve the routing information.  
-   Centralized NPDB means that the NPDB contains ported number 
-   information from multiple networks.  This is in contrast to the 
-   internal network-specific NPDB that is used for the Dropback and OR 
-   schemes.  The internal NPDB only contains information about the 
-   numbers that were ported out of the donor network.  The internal 
-   NPDB can be a stand-alone database that contains information about 
-   all or some ported-out numbers from the donor network.  It can also 
-   reside on the donor switch and only contains information about those 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 10] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   numbers ported out of the donor switch.  In that case, no query to a 
-   stand-alone internal NPDB is required.  The donor switch for a 
-   particular phone number is the switch to which the number range is 
-   assigned from which that phone number was originally assigned. 
-    
-   For example, number ranges in the North American Numbering Plan 
-   (NANP) are usually assigned in the form of central office codes (CO 
-   codes) comprising a six-digit prefix formatted as a NPA+NXX.  Thus a 
-   switch serving +1-202-533 would typically serve +1-202-533-0000 
-   through +1-202-533-9999. In major cities, switches usually host 
-   several CO codes.  NPA stands for Numbering Plan Area that is also 
-   known as the area code.  It is three-digit long and has the format 
-   of NXX where N is any digit from 2 to 9 and X is any digit from 0 to 
-   9.  NXX in the NPA+NXX format is known as the office code that has 
-   the same format as the NPA.  When a NPA+NXX code is set as 
-   Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a 
-   "portable NPA+NXX" code. 
-    
-   Similarly, in other national E.164 numbering plans, number ranges 
-   cover a contiguous range of numbers within that range.  Once a 
-   number within that range has ported away from the donor network, all 
-   numbers in that range are considered potentially ported and should 
-   be queried in the NPDB. 
-    
-   The ACQ scheme has two versions.  One version is for the Originating 
-   Network to always query the NPDB when a call is received from the 
-   caller regardless whether the dialed directory number belongs to any 
-   number range that is portable or has at least one number ported out. 
-   The other version is to check whether the dialed directory number 
-   belongs to any number range that is portable or has at least one 
-   number ported out.  If yes, an NPDB query is sent. If not, no NPDB 
-   query is sent.  The former performs better when there are many 
-   portable number ranges.  The latter performs better when there are 
-   not too many portable number ranges at the expense of checking every 
-   call to see whether NPDB query is needed.  The latter ACQ scheme is 
-   similar to the QoR scheme except that the QoR scheme uses call setup 
-   and relies on the donor network to indicate "number ported out" 
-   before launching the NPDB query. 
-    
-    
-5. Database Queries in the NP Environment 
-    
-   As indicated earlier, the ACQ and QoR schemes require that a switch 
-   query the NPDB for routing information.  Various standards have been 
-   defined for the switch-to-NPDB interface.  Those interfaces with 
-   their protocol stacks are briefly described below.  The term "NPDB" 
-   is used for a stand-alone database that may support just one or some 
-   or all of the interfaces mentioned below.  The NPDB query contains 
-   the dialed directory number and the NPDB response contains the 
-   routing number.  There are certainly other information that is sent 
-   in the query and response.  The primary interest is to get the 
-   routing number from the NPDB to the switch for call routing. 
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 11] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-5.1 U.S. and Canada 
-    
-   One of the following five NPDB interfaces can be used to query an 
-   NPDB: 
-    
-   (a) Advanced Intelligent Network (AIN) using the American National 
-       Standards Institute (ANSI)  version of the Intelligent Network 
-       Application Part (INAP) [ANSI SS] [ANSI DB].  The INAP is 
-       carried on top of the protocol stack that includes the (ANSI) 
-       Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling 
-       Connection Control Part (SCCP), and ANSI Transaction 
-       Capabilities Application Part (TCAP).  This interface can be 
-       used by the wireline or wireless switches, is specific to the NP 
-       implementation in North America, and is modeled on the Public 
-       Office Dialing Plan (PODP) trigger defined in the Advanced 
-       Intelligent Network (AIN) 0.1 call model.  
-    
-   (b) Intelligent Network (IN), which is similar to the one used for 
-       querying the 800 databases.  The IN protocol is carried on top 
-       of the protocol stack that includes the ANSI MTP Levels 1 
-       through 3, ANSI SCCP, and ANSI TCAP.  This interface can be used 
-       by the wireline or wireless switches. 
-    
-   (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the 
-       protocol stack that includes the ANSI MTP Levels 1 through 3, 
-       ANSI SCCP, and ANSI TCAP.  This interface can be used by the IS-
-       41 based cellular/Personal Communication Services (PCS) wireless 
-       switches (e.g., AMPS, TDMA and CDMA).  Cellular systems use 
-       spectrum at 800 MHz range and PCS systems use spectrum at 1900 
-       MHz range. 
-    
-   (d) Global System for Mobile Communication Mobile Application Part 
-       (GSM MAP) [GSM], which is carried on top of the protocol stack 
-       that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and 
-       International Telecommunication Union - Telecommunication Sector  
-       (ITU-TS) TCAP.  It can be used by the PCS1900 wireless switches 
-       that are based on the GSM technologies.  GSM is a series of 
-       wireless standards defined by the European Telecommunications 
-       Standards Institute (ETSI). 
-    
-   (e) ISUP triggerless translation.  NP translations are performed 
-       transparently to the switching network by the signaling network 
-       (e.g. Signaling Transfer Points (STPs) or signaling gateways).  
-       ISUP IAM messages are examined to determine if the CdPN field 
-       has already been translated, and if not, an NPDB query is 
-       performed, and the appropriate parameters in the IAM message 
-       modified to reflect the results of the translation.   The 
-       modified IAM message is forwarded by the signaling node on to 
-       the designated DPC in a transparent manner to continue call 
-       setup.  The NPDB can be integrated with the signaling node or be 
-       accessed via an API locally or by a query to a remote NPDB using 
-       a proprietary protocol or the schemes described above. 
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 12] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   Wireline switches have the choice of using either (a), (b), or (e).  
-   IS-41 based wireless switches have the choice of using (a), (b), 
-   (c), or (e).  PCS1900 wireless switches have the choice of using 
-   (a), (b), (d), or (e). In the United States, service provider 
-   portability will be supported by both the wireline and wireless 
-   systems, not only within the wireline or wireless domain but also 
-   across the wireline/wireless boundary.  However, this is not true in 
-   Europe where service provider portability is usually supported only 
-   within the wireline or wireless domain, not across the 
-   wireline/wireless boundary due to explicit use of service-specific 
-   number range prefixes.  The reason is to avoid caller confusion 
-   about the call charge. GSM systems in Europe are assigned 
-   distinctive destination network codes, and the caller pays a higher 
-   charge when calling a GSM directory number. 
-    
-      
-5.2 Europe 
-    
-   One of the following two interfaces can be used to query an NPDB: 
-    
-   (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is 
-       carried on top of the protocol stack that includes the ITU-TS 
-       MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. 
-    
-   (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is 
-       carried on top of the protocol stack that includes the ITU-TS 
-       MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, 
-       and ITU-TS TCAP. 
-    
-   Wireline switches have the choice of using either (a) or (b); 
-   however, all the implementations in Europe so far are based on CS1.  
-   As indicated earlier that number portability in Europe does not go 
-   across the wireline/wireless boundary.  The wireless switches can 
-   also use (a) or (b) to query the NPDBs if those NPDBs contains 
-   ported wireless directory numbers.  The term "Mobile Number 
-   Portability (MNP)" is used for the support of service provider 
-   portability by the GSM networks in Europe.  
-    
-   In most, if not all, cases in Europe, the calls to the wireless 
-   directory numbers are routed to the wireless donor network first.  
-   Over there, an internal NPDB is queried to determine whether the 
-   dialed wireless directory number has been ported out or not.  In 
-   this case, the interface to the internal NPDB is not subject to 
-   standardization. 
-
-   MNP in Europe can also be supported via MNP Signaling Relay Function 
-   (MNP-SRF).  Again, an internal NPDB or a database integrated at the 
-   MNP-SRF is used to modify the SCCP Called Party Address parameter in 
-   the GSM MAP messages so that they can be re-directed to the wireless 
-   serving network.   Call routing involving MNP will be explained in 
-   Section 6.2. 
-    
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 13] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-6. Call Routing in the NP Environment 
- 
-   This section discusses the call routing after the routing 
-   information has been retrieved either through an NPDB query or an 
-   internal database lookup at the donor switch, or from the Integrated 
-   Services Digital Network User Part (ISUP) signaling message (e.g., 
-   for the Dropback scheme).  For the ACQ, QoR and Dropback schemes, it 
-   is the Originating Network that has the routing information and is 
-   ready to route the call.  For the OR scheme, it is the donor network 
-   that has the routing information and is ready to route the call.   
-    
-   A number of triggering schemes may be employed that determine where 
-   in the call path the NPDB query is performed.  In the U.S. an ŸN-1÷ 
-   policy is used, which essentially says that for domestic calls, the 
-   originating local carriers performs the query, otherwise, the long 
-   distance carrier is expected to.  To ensure independence of the 
-   actual trigger policy employed in any one carrier, forward call 
-   signaling is used to flag that an NPDB query has already been 
-   performed and to therefore suppress any subsequent NP triggers that 
-   may be encountered in downstream switches, in downstream networks.  
-   This allows the earliest able network in the call path to perform 
-   the query without introducing additional costs and call setup delays 
-   were redundant queries performed downstream. 
-    
-     
-6.1 U.S. and Canada 
-    
-   In the U.S. and Canada, a ten-digit North American Numbering Plan 
-   (NANP) number called Location Routing Number (LRN) is assigned to 
-   every switch involved in NP.  In the NANP, a switch is not reachable 
-   unless it has a unique number range (CO code) assigned to it.  
-   Consequently, the LRN for a switch is always assigned out of a CO 
-   code that is assigned to that switch. 
-    
-   The LRN assigned to a switch currently serving a particular ported 
-   telephone number is returned as the network routing address in the 
-   NPDB response.  The service portability scheme that was adopted in 
-   the North America is very often referred to as the LRN scheme or 
-   method. 
-    
-   LRN serves as a network address for terminating calls served off 
-   that switch using ported numbers.  The LRN is assigned by the switch 
-   operator using any of the unique CO codes (NPA+NXX) assigned to that 
-   switch.  The LRN is considered a non-dialable address, as the same 
-   10-digit number value may be assigned to a line on that switch.  A 
-   switch may have more than one LRN. 
-    
-   During call routing/processing, a switch performs an NPDB query to 
-   obtain the LRN associated with the dialed directory number. NPDB 
-   queries are performed for all the dialed directory numbers whose 
-   NPA+NXX codes are marked as portable NPA+NXX at that switch. When 
-   formulating the ISUP Initial Address Message (IAM) to be sent to the 
-   next switch, the switch puts the ten-digit LRN in the ISUP Called 
-   Party Number (CdPN) parameter and the originally dialed directory 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 14] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   number in the ISUP Generic Address parameter (GAP).  A new code in 
-   the GAP was defined to indicate that the address information in the 
-   GAP is the dialed directory number. A new bit in the ISUP Forward 
-   Call Indicator (FCI) parameter, the Ported Number Translation 
-   Indicator (PNTI) bit, is set to imply that NPDB query has already 
-   been performed.  All the switches in the downstream will not perform 
-   the NPDB query if the PNTI bit is set. 
-    
-   When the terminating switch receives the IAM and sees the PNTI bit 
-   in the FCI parameter set and its own LRN in the CdPN parameter, it 
-   retrieves the originally dialed directory number from the GAP and 
-   uses the dialed directory number to terminate the call. 
-    
-   A dialed directory number with a portable NPA+NXX does not imply 
-   that directory number has been ported.  The NPDBs currently do not 
-   store records for non-ported directory numbers.  In that case, the 
-   NPDB will return the same dialed directory number instead of the 
-   LRN.  The switch will then set the PNTI bit but keep the dialed 
-   directory number in the CdPN parameter. 
-    
-   In the real world environment, the Originating Network is not always 
-   the one that performs the NPDB query.  For example, it is usually 
-   the long distance carriers that query the NPDBs for long distance 
-   calls.  In that case, the Originating Network operated by the local 
-   exchange carrier (LEC) simply routes the call to the long distance 
-   carrier that is to handle that call.   A wireless network acting as 
-   the Originating Network can also route the call to the 
-   interconnected local exchange carrier network if it does not want to 
-   support the NPDB interface at its mobile switches. 
-    
-    
-6.2 Europe 
-    
-   In some European countries, a routing number is prefixed to the 
-   dialed directory number.  The ISUP CdPN parameter in the IAM will 
-   contain the routing prefix and the dialed directory number.  For 
-   example, United Kingdom uses routing prefixes with the format of 
-   5XXXXX and Italy uses C600XXXXX as the routing prefix.  The networks 
-   use the information in the ISUP CdPN parameter to route the call to 
-   the New/Current Serving Network. 
-    
-   The routing prefix can identify the Current Serving Network or the 
-   Current Serving Switch of a ported number.  For the former case, 
-   another query to the "internal" NPDB at the Current Serving Network 
-   is required to identify the Current Serving Switch before routing 
-   the call to that switch.  This shields the Current Serving Switch 
-   information for a ported number from the other networks at the 
-   expense of an additional NPDB query.  Another routing number, may be 
-   meaningful within the Current Serving Network, will replace the 
-   previously prefixed routing number in the ISUP CdPN parameter.  For 
-   the latter case, the call is routed to the Current Serving Switch 
-   without an additional NPDB query. 
-    
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 15] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   When the terminating switch receives the IAM and sees its own 
-   routing prefix in the CdPN parameter, it retrieves the originally 
-   dialed directory number after the routing prefix, and uses the 
-   dialed directory number to terminate the call.  
-    
-   The call routing example described above shows one of the three 
-   methods that can be used to transport the Directory Number (DN) and 
-   the Routing Number (RN) in the ISUP IAM message.  In addition, some 
-   other information may be added/modified as is listed in the ETSI 302 
-   097 document [ETSIISUP], which is based on the ITU-T Recommendation 
-   Q.769.1 [ITUISUP].  The three methods and the enhancements in the 
-   ISUP to support number portability are briefly described below 
-    
-   (a) Two separate parameters with the CdPN parameter containing the 
-      RN and a new Called Directory Number (CdDN) parameter containing 
-      the DN.  A new value for the Nature of Address (NOA) indicator in 
-      the CdPN parameter is defined to indicate that the RN is in the 
-      CdPN parameter.  The switches use the CdPN parameter to route the 
-      call as is done today. 
-    
-   (b) Two separate parameters with the CdPN parameter containing the 
-      DN and a new Network Routing Number (NRN) parameter containing 
-      the RN.  This method requires that the switches use the NRN 
-      parameter to route the call. 
-    
-   (c) Concatenated parameter with the CdPN parameter containing the RN 
-      plus the DN.  A new Nature of Address (NOA) indicator in the CdPN 
-      parameter is defined to indicate that the RN is concatenated with 
-      the DN in the CdPN parameter.  Some countries may not use new NOA 
-      value because the routing prefix does not overlap with the dialed 
-      directory numbers.  But if the routing prefix overlaps with the 
-      dialed directory numbers, a new NOA value must be assigned.  For 
-      example, Spain uses "XXXXXX" as the routing prefix to identify 
-      the new serving network and uses a new NOA value of 126. 
-    
-   There is also a network option to add a new ISUP parameter called 
-   Number Portability Forwarding Information parameter.  This parameter 
-   has a four-bit Number Portability Status Indicator field that can 
-   provide an indication whether number portability query is done for 
-   the called directory number and whether the called directory number 
-   is ported or not if the number portability query is done. 
- 
-   Please note that all those NP enhancements for a ported number can 
-   only be used in the country that defined them.  This is because 
-   number portability is supported within a nation.  Within each 
-   nation, the telecommunications industry or the regulatory bodies can 
-   decide which method or methods to use.  Number portability related 
-   parameters and coding are usually not passed across the national 
-   boundaries unless the interconnection agreements allow that.  For 
-   example, a UK routing prefix can only be used in UK, and would cause 
-   routing problem if it appears outside UK. 
-    
-
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 16] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   As indicated earlier, an originating wireless network can query the 
-   NPDB and concatenate the RN with DN in the CdPN parameter and route 
-   the call directly to the Current Serving Network.   
-    
-   If NPDBs do not contain information about the wireless directory 
-   numbers, the call, originated from either a wireline or a wireless 
-   network, will be routed to the Wireless donor network.  Over there, 
-   an internal NPDB is queried to retrieve the RN that then is 
-   concatenated with the DN in the CdPN parameter. 
-    
-   There are several ways of realizing MNP.  When MNP-SRF is supported, 
-   the Gateway Mobile Services Switching Center (GMSC) at the wireless 
-   donor network, when receiving a call from the wireline network, can 
-   send the GSM MAP Send Routing Information (SRI) message to the MNP-
-   SRF.  The MNP-SRF interrogates an internal or integrated NPDB for 
-   the RN of the MNP-SRF of the wireless Current Serving Network and 
-   prefixes the RN to the dialed wireless directory number in the 
-   global title address information in the SCCP Called Party Address 
-   (CdPA) parameter.  This SRI message will be routed to the MNP-SRF of 
-   the wireless Current Serving Network, which then responds with an 
-   acknowledgement by providing the RN plus the dialed wireless 
-   directory number as the Mobile Station Roaming Number (MSRN).  The 
-   GMSC of the wireless donor network formulates the ISUP IAM with the 
-   RN plus the dialed wireless directory number in the CdPN parameter 
-   and routes the call to the wireless Current Serving Network.  A GMSC 
-   of the wireless Current Serving Network receives the call and sends 
-   an SRI message to the associated MNP-SRF where the global title 
-   address information of the SCCP CdPA parameter contains only the 
-   dialed wireless directory number.  The MNP-SRF then replaces the 
-   global title address information in the SCCP CdPA parameter with the 
-   address information associated with a Home Location Register (HLR) 
-   that hosts the dialed wireless directory number and forwards the 
-   message to that HLR after verifying that the dialed wireless 
-   directory number is a ported-in number.   The HLR then returns an 
-   acknowledgement by providing an MSRN for the GMSC to route the call 
-   to the MSC that currently serves the mobile station that is 
-   associated with the dialed wireless directory number.  Please see 
-   [MNP] for details and additional scenarios. 
-    
-    
-7. NP Implementations for Geographic E.164 Numbers 
- 
-   This section shows the known SPNP implementations worldwide.  
-    
-   +-------------+----------------------------------------------------+ 
-   +   Country   +             SPNP Implementation                    + 
-   +-------------+----------------------------------------------------+ 
-   +  Argentina  + Analyzing operative viability now. Will determine  + 
-   +             + whether portability should be made obligatory      + 
-   +             + after a technical solution has been determined.    + 
-   +-------------+----------------------------------------------------+ 
-   +  Australia  + NP supported by wireline operators since 11/30/99. + 
-   +             + NP among wireless operators in March/April 2000,   + 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 17] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   +             + but may be delayed to 1Q01. The access provider    + 
-   +             + or long distance provider has the obligation to    + 
-   +             + route the call to the correct destination. The     + 
-   +             + donor network is obligated to maintain and make    + 
-   +             + available a register of numbers ported away from   +  
-   +             + its network.  Telstra uses onward routing via an   + 
-   +             + on-switch solution.                                + 
-   +-------------+----------------------------------------------------+ 
-   +   Austria   + Uses onward routing at the donor network.  Routing + 
-   +             + prefix is "86xx" where "xx" identifies the         + 
-   +             + recipient network.                                 + 
-   +-------------+----------------------------------------------------+ 
-   +  Belgium    + ACQ selected by the industry. Routing prefix is    + 
-   +             + "Cxxxx" where "xxxx" identifies the recipient      + 
-   +             + switch. Another routing prefix is "C00xx" with "xx"+ 
-   +             + identifying the recipient network.  Plan to use NOA+ 
-   +             + to identify concatenated numbers and abandon the   + 
-   +             + hexadecimal routing prefix.                        + 
-   +-------------+----------------------------------------------------+ 
-   +  Brazil     + Considering NP for wireless users.                 + 
-   +-------------+----------------------------------------------------+ 
-   +  Chile      + There has been discussions lately on NP.           + 
-   +-------------+----------------------------------------------------+ 
-   +  Colombia   + There was an Article 3.1 on NP to support NP prior + 
-   +             + to December 31, 1999 when NP became technically    + 
-   +             + possible. Regulator has not yet issued regulations + 
-   +             + concerning this matter.                            + 
-   +-------------+----------------------------------------------------+ 
-   +  Denmark    + Uses ACQ. Routing number not passed between        + 
-   +             + operators; however, NOA is set to "112" to         + 
-   +             + indicate "ported number."  QoR can be used based   + 
-   +             + on bilateral agreements.                           +        
-   +-------------+----------------------------------------------------+ 
-   +  Finland    + Uses ACQ.  Routing prefix is "1Dxxy" where "xxy"   + 
-   +             + identifies the recipient network and service type. + 
-   +-------------+----------------------------------------------------+ 
-   +  France     + Uses onward routing.  Routing prefix is "Z0xxx"    + 
-   +             + where "xxx" identifies the recipient switch.       + 
-   +-------------+----------------------------------------------------+ 
-   +  Germany    + The originating network needs to do necessary      + 
-   +             + rerouting.  Operators decide their own solution(s).+ 
-   +             + Deutsche Telekom uses ACQ.  Routing prefix is      + 
-   +             + "Dxxx" where "xxx" identifies the recipient        + 
-   +             + network.                                           + 
-   +-------------+----------------------------------------------------+ 
-   +  Hong Kong  + Recipient network informs other networks about     + 
-   +             + ported-in numbers.  Routing prefix is "14x" where  + 
-   +             + "14x" identifies the recipient network, or a       + 
-   +             + routing number of "4x" plus 7 or 8 digits is used  +  
-   +             + where "4x" identifies the recipient network and    + 
-   +             + the rest of digits identify the called party.      + 
-   +-------------+----------------------------------------------------+ 
-   +  Ireland    + Operators choose their own solution but use onward + 
-   +             + routing now. Routing prefix is "1750" as the intra-+ 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 18] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   +             + network routing code (network-specific) and        + 
-   +             + "1752xxx" to "1759xxx" for GNP where "xxx"         + 
-   +             + identifies the recipient switch.                   + 
-   +-------------+----------------------------------------------------+ 
-   +  Italy      + Uses onward routing. Routing prefix is "C600xxxxx" + 
-   +             + where "xxxxx" identifies the recipient switch.     + 
-   +             + Telecom Italia uses IN solution and other operators+              
-   +             + use on-switch solution.                            + 
-   +-------------+----------------------------------------------------+ 
-   +  Japan      + Uses onward routing.  Donor switch uses IN to get  + 
-   +             + routing number.                                    + 
-   +-------------+----------------------------------------------------+ 
-   +  Mexico     + NP is considered in the Telecom law; however, the  + 
-   +             + regulator (Cofetel) or the new local entrants have + 
-   +             + started no initiatives on this process.            + 
-   +-------------+----------------------------------------------------+ 
-   + Netherlands + Operators decide NP scheme to use.  Operators have + 
-   +             + chosen ACQ or QoR.  KPN implemented IN solution    + 
-   +             + similar to U.S. solution.  Routing prefix is not   + 
-   +             + passed between operators.                          + 
-   +-------------+----------------------------------------------------+ 
-   +  Norway     + OR for short-term and ACQ for long-term.  QoR is   + 
-   +             + optional. Routing prefix can be "xxx" with NOA=8,  + 
-   +             + or "142xx" with NOA=3 where "xxx" or "xx"          + 
-   +             + identifies the recipient network.                  + 
-   +------------ +----------------------------------------------------+ 
-   +  Peru       + Wireline NP may be supported in 2001.              + 
-   +-------------+----------------------------------------------------+ 
-   +  Portugal   + No NP today.                                       + 
-   +-------------+----------------------------------------------------+ 
-   +  Spain      + Uses ACQ.  Telefonica uses QoR within its network. + 
-   +             + Routing prefix is  "xxyyzz" where "xxyyzz"         + 
-   +             + identifies the recipient network.  NOA is set to   + 
-   +             + 126.                                               + 
-   +-------------+----------------------------------------------------+ 
-   +  Sweden     + Standardized the ACQ but OR for operators without  + 
-   +             + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + 
-   +             + with NOA=3 where "xxx" identifies the recipient    + 
-   +             + network. But operators decide NP scheme to use.    + 
-   +             + Telia uses onward routing between operators.       + 
-   +-------------+----------------------------------------------------+ 
-   + Switzerland + Uses OR now and QoR in 2001.  Routing prefix is    + 
-   +             + "980xxx" where "xxx" identifies the recipient      +        
-   +             + network.                                           + 
-   +-------------+----------------------------------------------------+ 
-   +  UK         + Uses onward routing. Routing prefix is "5xxxxx"    + 
-   +             + where "xxxxx" identifies the recipient switch. NOA + 
-   +             + is 126. BT uses the dropback scheme in some parts  + 
-   +             + of its network.                                    + 
-   +-------------+----------------------------------------------------+ 
-   +  US         + Uses ACQ.  "Location Routing Number (LRN)" is used + 
-   +             + in the Called Party Number parameter.  Called party+ 
-   +             + number is carried in the Generic Address Parameter + 
-   +             + Use a PNTI indicator in the Forward Call Indicator + 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 19] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   +             + parameter to indicate that NPDB dip has been       + 
-   +             + performed.                                         + 
-   +-------------+----------------------------------------------------+ 
-    
-    
-8. Number Conservation Methods Enabled by NP 
- 
-   In addition to porting numbers NP provides the ability for number 
-   administrators to assign numbering resources to operators in smaller 
-   increments.  Today it is common for numbering resources to be 
-   assigned to telephone operators in a large block of consecutive 
-   telephone numbers (TNs).  For example, in North America each of 
-   these blocks contains 10,000 TNs and is of the format NXX+0000 to 
-   NXX+9999.  Operators are assigned a specific NXX, or block.  That 
-   operator is referred to as the block holder.  In that block there 
-   are 10,000 TNs with line numbers ranging from 0000 to 9999.   
-    
-   Instead of assigning an entire block to the operator NP allows the 
-   administrator to assign a sub-block or even an individual telephone 
-   number.  This is referred to as block pooling and individual 
-   telephone number (ITN) pooling, respectively.  
-     
-    
-8.1 Block Pooling 
-    
-   Block Pooling refers to the process whereby the number administrator 
-   assigns a range of numbers defined by a logical sub-block of the 
-   existing block.  Using North America as an example, block pooling 
-   would allow the administrator to assign sub-blocks of 1,000 TNs to 
-   multiple operators.  That is, NXX+0000 to NXX+0999 can be assigned 
-   to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, 
-   NXX-2000 to 2999 can be assigned to operator C, etc.  In this 
-   example block pooling divides one block of 10,000 TNs into ten 
-   blocks of 1,000 TNs.   
-    
-   Porting the sub-blocks from the block holder enables block pooling.  
-   Using the example above operator A is the block holder, as well as, 
-   the holder of the first sub-block, NXX+0000 to NXX+0999.  The second 
-   sub-block, NXX+1000 to NXX+1999, is ported from operator A to 
-   operator B.  The third sub-block, NXX+2000 to NXX+2999, is ported 
-   from operator A to operator C, and so on.  NP administrative 
-   processes and call processing will enable proper and efficient 
-   routing.   
-    
-   From a number administration and NP administration perspective block 
-   pooling introduces a new concept, that of the sub-block holder.  
-   Block pooling requires coordination between the number 
-   administrator, the NP administrator, the block holder, and the sub-
-   block holder.  Block pooling must be implemented in a manner that 
-   allows for NP within the sub-blocks.  Each TN can have a different 
-   serving operator, sub-block holder, and block holder. 
-      
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 20] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-8.2 ITN Pooling 
-    
-   ITN pooling refers to the process whereby the number administrator 
-   assigns individual telephone numbers to operators.  Using the North 
-   American example, one block of 10,000 TNs can be divided into 10,000 
-   ITNs.  ITN is more commonly deployed in freephone services.   
-    
-   In ITN the block is not assigned to an operator but to a central 
-   administrator.  The administrator then assigns ITNs to operators.  
-   NP administrative processes and call processing will enable proper 
-   and efficient routing. 
-    
- 
-9. Potential Implications 
-    
-   There are three general areas of impact to IP telephony work-in-
-   progress at IETF: 
-    
-   - Interoperation between NP in GSTN and IP telephony 
-   - NP implementation or emulation in IP telephony 
-   - Interconnection to NP administrative environment 
-    
-   A good understanding of how number portability is supported in the 
-   GSTN is important when addressing the interworking issues between 
-   IP-based networks and the GSTN.  This is especially important when 
-   the IP-based network needs to route the calls to the GSTN.  As shown 
-   in Section 5, there are a variety of standards with various protocol 
-   stacks for the switch-to-NPDB interface.  Not only that, the 
-   national variations of the protocol standards make it very 
-   complicated to deal with in a global environment.  If an entity in 
-   the IP-based network needs to query those existing NPDBs for routing 
-   number information to terminate the calls to the destination GSTN, 
-   it would be impractical, if not an impossible, job for that entity 
-   to support all those interface standards to access the NPDBs in many 
-   countries. 
-    
-   Several alternatives may address this particular problem.  One 
-   alternative is to use certain entities in the IP-based networks for 
-   dealing with NP query, similar to the International Switches that 
-   are used in the GSTN to interwork different national ISUP 
-   variations.  This will force signaling information associated with 
-   the calls to certain NP-capable networks in the terminating GSTN to 
-   be routed to those IP entities that support the NP functions.  Those 
-   IP entities then query the NPDBs in the terminating country.   This 
-   will limit the number of NPDB interfaces that certain IP entities 
-   need to support.  Another alternative can be to define a "common" 
-   interface to be supported by all the NPDBs so that all the IP 
-   entities use that standardized protocol to query them.   The 
-   existing NPDBs can support this additional interface, or new NPDBs 
-   can be deployed that contain the same information but support the 
-   common IP interface. The candidates for such a common interface 
-   include Lightweight Directory Access Protocol (LDAP) and SIP 
-   [SIP](e.g., using the SIP redirection capability).  Certainly 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 21] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   another possibility is to use interworking function to convert from 
-   one protocol to another. 
-    
-   IP-based networks can handle the domestic calls between two GSTNs.  
-   If the originating GSTN has performed NPDB query, SIP will need to 
-   transport and make use of some of the ISUP signaling information 
-   even if ISUP signaling may be encapsulated in SIP.  Also, IP-based 
-   networks may perform the NPDB queries, as the N-1 carrier.  In that 
-   case, SIP also needs to transport the NP related information while 
-   the call is being routed to the destination GSTN.  There are three 
-   pieces of NP related information that SIP needs to transport.  They 
-   are 1) the called directory number, 2) a routing number, and 3) a 
-   NPDB dip indicator.  The NPDB dip indicator is needed so that the 
-   terminating GSTN will not perform another NPDB dip.  The routing 
-   number is needed so that it is used to route the call to the 
-   destination network or switch in the destination GSTN.  The called 
-   directory number is needed so that the terminating GSTN switch can 
-   terminate the call.  When the routing number is present, the NPDB 
-   dip indicator may not be present because there are cases where 
-   routing number is added for routing the call even if NP is not 
-   involved.  One issue is how to transport the NP related information 
-   via SIP.  The SIP Universal Resource Locator (URL) is one mechanism.  
-   Another better choice may be to add an extension to the "tel" URL 
-   [TEL] that is also supported by SIP.  Please see [TELNP] for the 
-   proposed extensions to the "tel" URL to support NP and freephone 
-   service.  Those extensions to the "tel" URL will be automatically 
-   supported by SIP because they can be carried as the optional 
-   parameters in the user portion of the "sip" URL. 
-    
-   For a called directory number that belongs to a country that 
-   supports NP, and if the IP-based network is to perform the NPDB 
-   query, the logical step is to perform the NPDB dip first to retrieve 
-   the routing number and use that routing number to select the correct 
-   IP telephony gateways that can reach the serving switch that serves 
-   the called directory number.  Therefore, if the "rn" parameter is 
-   present in the "tel" URL or sip URL in the SIP INVITE message, it 
-   instead of the called directory number should be used for making 
-   routing decisions assuming that no other higher priority routing-
-   related parameters such as the Ÿcic÷ are present.  If "rn" is not 
-   present, then the dialed directory number can be used as the routing 
-   number for making routing decisions.   
-    
-   Telephony Routing Information Protocol (TRIP) [TRIP] is a policy 
-   driven inter-administrative domain protocol for advertising the 
-   reachability of telephony destinations between location servers, and 
-   for advertising attributes of the routes to those destinations.  
-   With the NP in mind, it is very important to know that it is the 
-   routing number, if present, not the called directory number that 
-   should be used to check against the TRIP tables for making the 
-   routing decisions.   
-    
-   Overlap signaling exists in the GSTN today.  For a call routing from 
-   the originating GSTN to the IP-based network that involves overlap 
-   signaling, NP will impact the call processing within the IP-based 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 22] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   networks if they must deal with the overlap signaling.  The entities 
-   in the IP-based networks that are to retrieve the NP information 
-   (e.g., the routing number) must collect a complete called directory 
-   number information before retrieving the NP information for a ported 
-   number.  Otherwise, the information retrieval won't be successful.   
-   This is an issue for the IP-based networks if the originating GSTN 
-   does not handle the overlap signaling by collecting the complete 
-   called directory number. 
-    
-   The IETF enum working group is defining the use of Domain Name 
-   System (DNS) for identifying available services associated with a 
-   particular E.164 number [ENUM].  [ENUMPO] outlines the principles 
-   for the operation of a telephone number service that resolves 
-   telephone numbers into Internet domain name addresses and service-
-   specific directory discovery.  [ENUMPO] implements a three-level 
-   approach where the first level is the mapping of the telephone 
-   number delegation tree to the authority to which the number has been 
-   delegated, the second level is the provision of the requested DNS 
-   resource records from a service registrar, and the third level is 
-   the provision of service specific data from the service provider 
-   itself.  NP certainly must be considered at the first level because 
-   the telephony service providers do not "own" or control the 
-   telephone numbers under the NP environment; therefore, they may not 
-   be the proper entities to have the authority for a given E.164 
-   number.  Not only that, there is a regulatory requirement on NP in 
-   some countries that the donor network should not be relied on to 
-   reach the delegated authority during the DNS process .  The 
-   delegated authority for a given E.164 number is likely to be an 
-   entity designated by the end user that owns/controls a specific 
-   telephone number or one that is designated by the service registrar. 
-    
-   Since the telephony service providers may have the need to use ENUM 
-   for their network-related services (e.g., map an E.164 number to a 
-   HLR Identifier in the wireless networks), their ENUM records must be 
-   collocated with those of the telephony subscribers.  If that is the 
-   case, NP will impact ENUM when a telephony subscriber who has ENUM 
-   service changes the telephony service provider.  This is because 
-   that the ENUM records from the new telephony service provider must 
-   replace those from the old telephony service provider.  To avoid the 
-   NP impact on ENUM, it is recommended that the telephony service 
-   providers use a different domain tree for their network-related 
-   service.  For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a 
-   domain tree different from e164.arpa should be used for Ÿcarrier÷ 
-   ENUM. 
-    
-   The IP-based networks also may need to support some forms of number 
-   portability in the future if E.164 numbers [E164] are assigned to 
-   the IP-based end users.  One method is to assign a GSTN routing 
-   number for each IP-based network domain or entity in a NP-capable 
-   country.  This may increase the number of digits in the routing 
-   number to incorporate the IP entities and impact the existing 
-   routing in the GSTN.  Another method is to associate each IP entity 
-   with a particular GSTN gateway.  At that particular GSTN gateway, 
-   the called directory number then is used to locate the IP-entity 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 23] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   that serves that dialed directory number.  Yet, another method can 
-   be to assign a special routing number so that the call to an end 
-   user currently served by an IP entity is routed to the nearest GSTN 
-   gateway.  The called directory number then is used to locate the IP-
-   entity that serves that dialed directory number.  A mechanism can be 
-   developed or used for the IP-based network to locate the IP entity 
-   that serves a particular dialed directory number.  Many other types 
-   of networks use E.164 numbers to identify the end users or terminals 
-   in those networks.  Number portability among GSTN, IP-based network 
-   and those various types of networks may also need to be supported in 
-   the future. 
-    
- 
-10. Security Considerations 
- 
-   This document does not raise any security issues. 
- 
- 
-11. IANA Considerations 
- 
-   This document introduces no new values for IANA registration. 
-    
- 
-12. Normative References  
- 
-   [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability -
-        Operator Services Switching Systems," April 1999. 
-    
-   [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability -
-        Switching Systems," April 1999. 
-             
-   [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability 
-        Database and Global Title Translation," April 1999.         
-          
-   [CS1] ITU-T Q-series  Recommendations - Supplement 4, "Number 
-        portability Capability set 1 requirements for service provider 
-        portability (All call query and onward routing)," May 1998. 
-    
-   [CS2] ITU-T Q-series  Recommendations - Supplement 5, "Number 
-        portability -Capability set 2 requirements for service provider 
-        portability (Query on release and Dropback)," March 1999. 
-    
-   [E164] ITU-T Recommendation E.164, "The International Public 
-        Telecommunications Numbering Plan," 1997. 
-    
-   [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. 
-    
-   [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital 
-        Network (ISDN); Signalling System No.7 (SS7); ISDN User Part 
-        (ISUP); Enhancement for support of Number Portability (NP) 
-        [ITU-T Recommendation Q.769.1 (2000), modified] 
-    
-   [GSM]  GSM 09.02: "Digital cellular telecommunications system (Phase 
-        2+); Mobile Application Part (MAP) specification". 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 24] 
-
-Number Portability in the GSTN: An Overview              March 1, 2002 
- 
- 
- 
-   [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for 
-        Wireless Number Portability Phase II (December 1998)"Number 
-        Portability Network Support," April 1998. 
-    
-   [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - 
-        ISDN User Part Enhancements for the Support of Number 
-        Portability," December 1999. 
-    
-   [MNP] ETSI EN 301 716 (2000-10) European Standard 
-        (Telecommunications series) Digital cellular telecommunications 
-        system (Phase 2+); Support of Mobile Number Portability (MNP); 
-        Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 
-        Release 1998). 
-    
-   [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- 
-        Revision 3," October 1996. 
-    
- 
-13. Informative References  
- 
-   [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific 
-        Provisioning: Principles of Operations," draft-ietf-enum-
-        operation-02.txt, February 23, 2001. 
-    
-   [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: 
-        Session Initiation Protocol," February 27, 2002. 
-    
-   [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis-
-        04.txt, "URIs for Telephone Calls," May 24, 2002. 
- 
-   [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL 
-        to support Number Portability and Freephone Service," June 14, 
-        2002. 
-    
-   [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony 
-        Routing Information Protocol (TRIP)," January 2002. 
-    
-    
-14. Acknowledgment 
-    
-   The authors would like to thank Monika Muench for providing 
-   information on ISUP and MNP. 
-    
-    
-15. Authors' Addresses 
-    
-   Mark D. Foster 
-   NeuStar, Inc. 
-   1120 Vermont Avenue, NW, 
-   Suite 400 
-   Washington, D.C. 20005 
-   United States 
-  
-Foster,McGarry,Yu           Expired on August 31, 2002        [Page 25] 
-
-Number Portability in the GSTN: An Overview              March 1, 2002 
- 
- 
-    
-   Phone: +1-202-533-2800 
-   Fax:   +1-202-533-2987 
-   Email: mark.foster@neustar.biz 
-          
-   Tom McGarry 
-   NeuStar, Inc. 
-   1120 Vermont Avenue, NW, 
-   Suite 400 
-   Washington, D.C. 20005 
-   United States 
-    
-   Phone: +1-202-533-2810 
-   Fax:   +1-202-533-2987 
-   Email: tom.mcgarry@neustar.biz 
-    
-   James Yu 
-   NeuStar, Inc. 
-   1120 Vermont Avenue, NW,  
-   Suite 400 
-   Washington, D.C. 20005 
-   United States 
-    
-   Phone: +1-202-533-2814 
-   Fax:   +1-202-533-2987 
-   Email: james.yu@neustar.biz 
-    
-    
-    
-Full Copyright Statement 
- 
-   "Copyright (C) The Internet Society (2002). All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works. However, this 
-   document itself may not be modified in any way, such as by removing 
-   the copyright notice or references to the Internet Society or other 
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-
-  
-Foster,McGarry,Yu           Expired on August 31, 2002        [Page 26] 
-
-Number Portability in the GSTN: An Overview              March 1, 2002 
- 
- 
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-    
-Acknowledgement 
- 
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
- 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Foster,McGarry,Yu           Expired on August 31, 2002        [Page 27] 
-
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
deleted file mode 100644
index 2d5c87eb3caa..000000000000
--- a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
+++ /dev/null
@@ -1,1200 +0,0 @@
-
-
-
-
-
-
-IPv6 Working Group                                 John Loughney (ed)
-Internet-Draft                                                  Nokia
-                                                     January 14, 2004
-
-Expires: July 14, 2004
-
-
-
-                         IPv6 Node Requirements
-                draft-ietf-ipv6-node-requirements-08.txt
-
-
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document defines requirements for IPv6 nodes.  It is expected
-   that IPv6 will be deployed in a wide range of devices and situations.
-   Specifying the requirements for IPv6 nodes allows IPv6 to function
-   well and interoperate in a large number of situations and
-   deployments.
-
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 1]
-
-
-
-
-
-Internet-Draft
-
-
-Table of Contents
-
-   1.   Introduction
-   1.1 Requirement Language
-   1.2  Scope of this Document
-   1.3  Description of IPv6 Nodes
-   2.   Abbreviations Used in This Document
-   3.   Sub-IP Layer
-   3.1  Transmission of IPv6 Packets over Ethernet Networks - RFC2464
-   3.2  IP version 6 over PPP - RFC2472
-   3.3  IPv6 over ATM Networks - RFC2492
-   4.   IP Layer
-   4.1  Internet Protocol Version 6 - RFC2460
-   4.2  Neighbor Discovery for IPv6 - RFC2461
-   4.3  Path MTU Discovery & Packet Size
-   4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
-   4.5  Addressing
-   4.6  Multicast Listener Discovery (MLD) for IPv6 - RFC2710
-   5.   Transport and DNS
-   5.1  Transport Layer
-   5.2  DNS
-   5.3  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
-   6.   IPv4 Support and Transition
-   6.1  Transition Mechanisms
-   7.   Mobility
-   8.   Security
-   8.1  Basic Architecture
-   8.2  Security Protocols
-   8.3  Transforms and Algorithms
-   8.4  Key Management Methods
-   9.   Router Functionality
-   9.1  General
-   10.  Network Management
-   10.1 MIBs
-   11.  Security Considerations
-   12.  References
-   12.1 Normative
-   12.2 Non-Normative
-   13.  Authors and Acknowledgements
-   14.  Editor's Address
-   Notices
-
-
-
-
-
-
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 2]
-
-
-
-
-
-Internet-Draft
-
-
-1. Introduction
-
-   The goal of this document is to define the common functionality
-   required from both IPv6 hosts and routers.  Many IPv6 nodes will
-   implement optional or additional features, but all IPv6 nodes can be
-   expected to implement the mandatory requirements listed in this
-   document.
-
-   This document tries to avoid discussion of protocol details, and
-   references RFCs for this purpose.  In case of any conflicting text,
-   this document takes less precedence than the normative RFCs, unless
-   additional clarifying text is included in this document.
-
-   Although the document points to different specifications, it should
-   be noted that in most cases, the granularity of requirements are
-   smaller than a single specification, as many specifications define
-   multiple, independent pieces, some of which may not be mandatory.
-
-   As it is not always possible for an implementer to know the exact
-   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
-   that they should adhere to Jon Postel's Robustness Principle:
-
-      Be conservative in what you do, be liberal in what you accept from
-      others [RFC-793].
-
-1.1 Requirement Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC-2119].
-
-1.2 Scope of this Document
-
-   IPv6 covers many specifications.  It is intended that IPv6 will be
-   deployed in many different situations and environments.  Therefore,
-   it is important to develop the requirements for IPv6 nodes, in order
-   to ensure interoperability.
-
-   This document assumes that all IPv6 nodes meet the minimum
-   requirements specified here.
-
-1.3 Description of IPv6 Nodes
-
-   From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we
-   have the following definitions:
-
-      Description of an IPv6 Node
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 3]
-
-
-
-
-
-Internet-Draft
-
-
-       - a device that implements IPv6
-
-      Description of an IPv6 router
-
-       - a node that forwards IPv6 packets not explicitly addressed to
-         itself.
-
-      Description of an IPv6 Host
-
-       - any node that is not a router.
-
-2. Abbreviations Used in This Document
-
-   ATM   Asynchronous Transfer Mode
-
-   AH    Authentication Header
-
-   DAD   Duplicate Address Detection
-
-   ESP   Encapsulating Security Payload
-
-   ICMP  Internet Control Message Protocol
-
-   IKE   Internet Key Exchange
-
-   MIB   Management Information Base
-
-   MLD   Multicast Listener Discovery
-
-   MTU   Maximum Transfer Unit
-
-   NA    Neighbor Advertisement
-
-   NBMA  Non-Broadcast Multiple Access
-
-   ND    Neighbor Discovery
-
-   NS    Neighbor Solicitation
-
-   NUD   Neighbor Unreachability Detection
-
-   PPP   Point-to-Point Protocol
-
-   PVC   Permanent Virtual Circuit
-
-   SVC   Switched Virtual Circuit
-
-3. Sub-IP Layer
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 4]
-
-
-
-
-
-Internet-Draft
-
-
-   An IPv6 node must include support for one or more IPv6 link-layer
-   specifications.  Which link-layer specifications are included will
-   depend upon what link-layers are supported by the hardware available
-   on the system.  It is possible for a conformant IPv6 node to support
-   IPv6 on some of its interfaces and not on others.
-
-   As IPv6 is run over new layer 2 technologies, it is expected that new
-   specifications will be issued.  This section highlights some major
-   layer 2 technologies and is not intended to be complete.
-
-3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
-
-   Nodes supporting IPv6 over Ethernet interfaces MUST implement
-   Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
-
-3.2 IP version 6 over PPP - RFC2472
-
-   Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-
-   2472].
-
-3.3 IPv6 over ATM Networks - RFC2492
-
-   Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
-   Networks [RFC-2492].  Additionally, RFC 2492 states:
-
-      A minimally conforming IPv6/ATM driver SHALL support the PVC mode
-      of operation. An IPv6/ATM driver that supports the full SVC mode
-      SHALL also support PVC mode of operation.
-
-4. IP Layer
-
-4.1 Internet Protocol Version 6 - RFC2460
-
-   The Internet Protocol Version 6 is specified in [RFC-2460]. This
-   specification MUST be supported.
-
-   Unrecognized options in Hop-by-Hop Options or Destination Options
-   extensions MUST be processed as described in RFC 2460.
-
-   The node MUST follow the packet transmission rules in RFC 2460.
-
-   Nodes MUST always be able to send, receive and process fragment
-   headers.  All conformant IPv6 implementations MUST be capable of
-   sending and receving IPv6 packets; forwarding functionality MAY be
-   supported
-
-   RFC 2460 specifies extension headers and the processing for these
-   headers.
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 5]
-
-
-
-
-
-Internet-Draft
-
-
-      A full implementation of IPv6 includes implementation of the
-      following extension headers: Hop-by-Hop Options, Routing (Type 0),
-      Fragment, Destination Options, Authentication and Encapsulating
-      Security Payload. [RFC-2460]
-
-   An IPv6 node MUST be able to process these headers.  It should be
-   noted that there is some discussion about the use of Routing Headers
-   and possible security threats [IPv6-RH] caused by them.
-
-4.2 Neighbor Discovery for IPv6 - RFC2461
-
-   Neighbor Discovery SHOULD be supported.  RFC 2461 states:
-
-      "Unless specified otherwise (in a document that covers operating
-      IP over a particular link type) this document applies to all link
-      types. However, because ND uses link-layer multicast for some of
-      its services, it is possible that on some link types (e.g., NBMA
-      links) alternative protocols or mechanisms to implement those
-      services will be specified (in the appropriate document covering
-      the operation of IP over a particular link type).  The services
-      described in this document that are not directly dependent on
-      multicast, such as Redirects, Next-hop determination, Neighbor
-      Unreachability Detection, etc., are expected to be provided as
-      specified in this document.  The details of how one uses ND on
-      NBMA links is an area for further study."
-
-   Some detailed analysis of Neighbor Discovery follows:
-
-   Router Discovery is how hosts locate routers that reside on an
-   attached link. Router Discovery MUST be supported for
-   implementations.
-
-   Prefix Discovery is how hosts discover the set of address prefixes
-   that define which destinations are on-link for an attached link.
-   Prefix discovery MUST be supported for implementations. Neighbor
-   Unreachability Detection (NUD) MUST be supported for all paths
-   between hosts and neighboring nodes. It is not required for paths
-   between routers.  However, when a node receives a unicast Neighbor
-   Solicitation (NS) message (that may be a NUD's NS), the node MUST
-   respond to it (i.e. send a unicast Neighbor Advertisement).
-
-   Duplicate Address Detection MUST be supported on all links supporting
-   link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take
-   place on all unicast addresses).
-
-   A host implementation MUST support sending Router Solicitations.
-
-   Receiving and processing Router Advertisements MUST be supported for
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 6]
-
-
-
-
-
-Internet-Draft
-
-
-   host implementations. The ability to understand specific Router
-   Advertisement options is dependent on supporting the specification
-   where the RA is specified.
-
-   Sending and Receiving Neighbor Solicitation (NS) and Neighbor
-   Advertisement (NA) MUST be supported. NS and NA messages are required
-   for Duplicate Address Detection (DAD).
-
-   Redirect functionality SHOULD be supported. If the node is a router,
-   Redirect functionality MUST be supported.
-
-4.3 Path MTU Discovery & Packet Size
-
-4.3.1 Path MTU Discovery - RFC1981
-
-   Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
-   implementations MAY choose to not support it and avoid large packets.
-   The rules in RFC 2460 MUST be followed for packet fragmentation and
-   reassembly.
-
-4.3.2 IPv6 Jumbograms - RFC2675
-
-   IPv6 Jumbograms [RFC-2675] MAY be supported.
-
-4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
-
-   ICMPv6 [RFC-2463] MUST be supported.
-
-4.5 Addressing
-
-4.5.1 IP Version 6 Addressing Architecture - RFC3513
-
-   The IPv6 Addressing Architecture [RFC-3513] MUST be supported.
-
-4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462
-
-   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
-   This specification MUST be supported for nodes that are hosts.
-
-   Nodes that are routers MUST be able to generate link local addresses
-   as described in RFC 2462 [RFC-2462].
-
-   From 2462:
-
-      The autoconfiguration process specified in this document applies
-      only to hosts and not routers. Since host autoconfiguration uses
-      information advertised by routers, routers will need to be
-      configured by some other means. However, it is expected that
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 7]
-
-
-
-
-
-Internet-Draft
-
-
-      routers will generate link-local addresses using the mechanism
-      described in this document. In addition, routers are expected to
-      successfully pass the Duplicate Address Detection procedure
-      described in this document on all addresses prior to assigning
-      them to an interface.
-
-   Duplicate Address Detection (DAD) MUST be supported.
-
-4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041
-
-   Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
-   SHOULD be supported.  It is recommended that this behavior be
-   configurable on a connection basis within each application when
-   available.  It is noted that a number of applications do not work
-   with addresses generated with this method, while other applications
-   work quite well with them.
-
-4.5.4 Default Address Selection for IPv6 - RFC3484
-
-   The rules specified in the Default Address Selection for IPv6 [RFC-
-   3484] document MUST be implemented. It is expected that IPv6 nodes
-   will need to deal with multiple addresses.
-
-4.5.5 Stateful Address Autoconfiguration
-
-   Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
-   3315] is the standard stateful address configuration protocol; see
-   section 5.3 for DHCPv6 support.
-
-   Nodes which do not support Stateful Address Autoconfiguration may be
-   unable to obtain any IPv6 addresses aside from link-local addresses
-   when it receives a router advertisement with the 'M' flag (Managed
-   address configuration) set and which contains no prefixes advertised
-   for Stateless Address Autoconfiguration (see section 4.5.2).
-   Additionally, such nodes will be unable to obtain other configuration
-   information such as the addresses of DNS servers when it is connected
-   to a link over which the node receives a router advertisement in
-   which the 'O' flag ("Other stateful configuration") is set.
-
-4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
-
-   Nodes that need to join multicast groups SHOULD implement MLDv2
-   [MLDv2]. However, if the node has applications, which only need
-   support for Any- Source Multicast [RFC3569], the node MAY implement
-   MLDv1 [MLDv1] instead. If the node has applications, which need
-   support for Source- Specific Multicast [RFC3569, SSMARCH], the node
-   MUST support MLDv2 [MLDv2].
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 8]
-
-
-
-
-
-Internet-Draft
-
-
-   When MLD is used, the rules in "Source Address Selection for the
-   Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
-   followed.
-
-5. Transport Layer and DNS
-
-5.1 Transport Layer
-
-5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147
-
-   This specification MUST be supported if jumbograms are implemented
-   [RFC- 2675].
-
-5.2 DNS
-
-   DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363]
-   and [RFC-3596] MAY be supported.  Not all nodes will need to resolve
-   names. All nodes that need to resolve names SHOULD implement stub-
-   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
-   support for:
-
-    - AAAA type Resource Records [RFC-3596];
-    - reverse addressing in ip6.arpa using PTR records [RFC-3152];
-    - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
-      octets.
-
-   Those nodes are RECOMMENDED to support DNS security extentions
-   [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT].
-
-   Those nodes are NOT RECOMMENDED to support the experimental A6 and
-   DNAME Resource Records [RFC-3363].
-
-5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732
-
-   RFC 2732 MUST be supported if applications on the node use URL's.
-
-5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315
-
-5.3.1 Managed Address Configuration
-
-   Those IPv6 Nodes that use DHCP for address assignment initiate DHCP
-   to obtain IPv6 addresses and other configuration information upon
-   receipt of a Router Advertisement with the 'M' flag set, as described
-   in section 5.5.3 of RFC 2462.  In addition, in the absence of a
-   router, those IPv6 Nodes that use DHCP for address assignment MUST
-   initiate DHCP to obtain IPv6 addresses and other configuration
-   information, as described in section 5.5.2 of RFC 2462.  Those IPv6
-   nodes that do not use DHCP for address assignment can ignore the 'M'
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 9]
-
-
-
-
-
-Internet-Draft
-
-
-   flag in Router Advertisements.
-
-5.3.2 Other Configuration Information
-
-   Those IPv6 Nodes that use DHCP to obtain other configuration
-   information initiate DHCP for other configuration information upon
-   receipt of a Router Advertisement with the 'O' flag set, as described
-   in section 5.5.3 of RFC 2462.  Those IPv6 nodes that do not use DHCP
-   for other configuration information can ignore the 'O' flag in Router
-   Advertisements.
-
-   An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to
-   obtain other configuration information.
-
-6. IPv4 Support and Transition
-
-   IPv6 nodes MAY support IPv4.
-
-6.1 Transition Mechanisms
-
-6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893
-
-   If an IPv6 node implements dual stack and tunneling, then RFC2893
-   MUST be supported.
-
-   RFC 2893 is currently being updated.
-
-7. Mobile IP
-
-   The Mobile IPv6 [MIPv6] specification defines requirements for the
-   following types of nodes:
-
-       - mobile nodes
-       - correspondent nodes with support for route optimization
-       - home agents
-       - all IPv6 routers
-
-   Hosts MAY support mobile node functionality described in Section 8.5
-   of [MIPv6], including support of generic packet tunneling [RFC-2473]
-   and secure home agent communications [MIPv6-HASEC].
-
-   Hosts SHOULD support route optimization requirements for
-   correspondent nodes described in Section 8.2 of [MIPv6].
-
-   Routers SHOULD support the generic mobility-related requirements for
-   all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY
-   support the home agent functionality described in Section 8.4 of
-   [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC].
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 10]
-
-
-
-
-
-Internet-Draft
-
-
-8. Security
-
-   This section describes the specification of IPsec for the IPv6 node.
-
-8.1 Basic Architecture
-
-   Security Architecture for the Internet Protocol [RFC-2401] MUST be
-   supported. RFC-2401 is being updated by the IPsec Working Group.
-
-8.2 Security Protocols
-
-   ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported.
-   RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group.
-
-
-8.3 Transforms and Algorithms
-
-   Current IPsec RFCs specify the support of certain transforms and
-   algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96.
-   The requirements for these are discussed first, and then additional
-   algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed.
-
-   NULL encryption algorithm [RFC-2410] MUST be supported for providing
-   integrity service and also for debugging use.
-
-   The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD
-   NOT be supported. Security issues related to the use of DES are
-   discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as
-   required by the existing IPsec RFCs, but as it is currently viewed as
-   an inherently weak algorithm, and no longer fulfills its intended
-   role.
-
-   The NULL authentication algorithm [RFC-2406] MUST be supported within
-   ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC-
-   2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP,
-   described in [RFC-2403] MUST be supported. An implementer MUST refer
-   to Keyed- Hashing for Message Authentication [RFC-2104].
-
-   3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
-   and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES-
-   CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected
-   to be a widely available, secure algorithm that is required for
-   interoperability. It is not required by the current IPsec RFCs, but
-   is expected to become required in the future.
-
-   In addition to the above requirements, "Cryptographic Algorithm
-   Implementation Requirements For ESP And AH" [CRYPTREQ] contains the
-   current set of mandatory to implement algorithms for ESP and AH as
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 11]
-
-
-
-
-
-Internet-Draft
-
-
-   well as specifying algorithms that should be implemented because they
-   may be promoted to mandatory at some future time.  It is RECOMMENDED
-   that IPv6 nodes conform to the requirements in this document.
-
-8.4 Key Management Methods
-
-   Manual keying MUST be supported.
-
-   IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast
-   traffic. Where key refresh, anti-replay features of AH and ESP, or
-   on- demand creation of Security Associations (SAs) is required,
-   automated keying MUST be supported. Note that the IPsec WG is working
-   on the successor to IKE [IKE2]. Key management methods for multicast
-   traffic are also being worked on by the MSEC WG.
-
-   "Cryptographic Algorithms for use in the Internet Key Exchange
-   Version 2" [IKEv2ALGO] defines the current set of mandatory to
-   implement algorithms for use of IKEv2 as well as specifying
-   algorithms that should be implemented because they made be promoted
-   to mandatory at some future time. It is RECOMMENDED that IPv6 nodes
-   implementing IKEv2 conform to the requirements in this
-   document.
-
-9. Router-Specific Functionality
-
-   This section defines general host considerations for IPv6 nodes that
-   act as routers.  Currently, this section does not discuss routing-
-   specific requirements.
-
-9.1 General
-
-9.1.1 IPv6 Router Alert Option - RFC2711
-
-
-   The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
-   Hop Header that is used in conjunction with some protocols (e.g.,
-   RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will
-   need to be implemented whenever protocols that mandate its usage are
-   implemented. See Section 4.6.
-
-9.1.2 Neighbor Discovery for IPv6 - RFC2461
-
-   Sending Router Advertisements and processing Router Solicitation MUST
-   be supported.
-
-10. Network Management
-
-   Network Management MAY be supported by IPv6 nodes.  However, for IPv6
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 12]
-
-
-
-
-
-Internet-Draft
-
-
-   nodes that are embedded devices, network management may be the only
-   possibility to control these nodes.
-
-10.1 Management Information Base Modules (MIBs)
-
-   The following two MIBs SHOULD be supported by nodes that support an
-   SNMP agent.
-
-10.1.1  IP Forwarding Table MIB
-
-   IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes
-   that support an SNMP agent.
-
-10.1.2 Management Information Base for the Internet Protocol (IP)
-
-   IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an
-   SNMP agent.
-
-11. Security Considerations
-
-   This draft does not affect the security of the Internet, but
-   implementations of IPv6 are expected to support a minimum set of
-   security features to ensure security on the Internet.  "IP Security
-   Document Roadmap" [RFC-2411] is important for everyone to read.
-
-   The security considerations in RFC2460 describe the following:
-
-      The security features of IPv6 are described in the Security
-      Architecture for the Internet Protocol [RFC-2401].
-
-12. References
-
-12.1 Normative
-
-   [CRYPTREQ]     D. Eastlake 3rd, "Cryptographic Algorithm Implementa-
-                  tion Requirements For ESP And AH", draft-ietf-ipsec-
-                  esp-ah-algorithms-01.txt, January 2004.
-
-   [IKEv2ALGO]    J. Schiller, "Cryptographic Algorithms for use in the
-                  Internet Key Exchange Version 2", draft-ietf-ipsec-
-                  ikev2-algorithms-04.txt, Work in Progress.
-
-   [DHCPv6-SL]    R. Droms, "A Guide to Implementing Stateless DHCPv6
-                  Service", draft- ietf-dhc-dhcpv6-stateless-00.txt,
-                  Work in Progress.
-
-   [MIPv6]        J. Arkko, D. Johnson and C. Perkins, "Mobility Support
-                  in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 13]
-
-
-
-
-
-Internet-Draft
-
-
-                  progress.
-
-   [MIPv6-HASEC]  J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec
-                  to Protect Mobile IPv6 Signaling between Mobile Nodes
-                  and Home Agents", draft-ietf- mobileip-mipv6-ha-
-                  ipsec-06.txt, Work in Progress.
-
-   [MLDv2]        Vida, R. et al., "Multicast Listener Discovery Version
-                  2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in
-                  Progress.
-
-   [RFC-1035]     Mockapetris, P., "Domain names - implementation and
-                  specification", STD 13, RFC 1035, November 1987.
-
-   [RFC-1981]     McCann, J., Mogul, J. and Deering, S., "Path MTU
-                  Discovery for IP version 6", RFC 1981, August 1996.
-
-   [RFC-2096BIS]  Haberman, B. and Wasserman, M., "IP Forwarding Table
-                  MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in
-                  Progress.
-
-   [RFC-2011BIS]  Routhier, S (ed), "Management Information Base for the
-                  Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-
-                  update-07.txt, Work in progress.
-
-   [RFC-2104]     Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:
-                  Keyed-Hashing for Message Authentication", RFC 2104,
-                  February 1997.
-
-   [RFC-2119]     Bradner, S., "Key words for use in RFCs to Indicate
-                  Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC-2401]     Kent, S. and Atkinson, R., "Security Architecture for
-                  the Internet Protocol", RFC 2401, November 1998.
-
-   [RFC-2402]     Kent, S. and Atkinson, R.,  "IP Authentication
-                  Header", RFC 2402, November 1998.
-
-   [RFC-2403]     Madson, C., and Glenn, R., "The Use of HMAC-MD5 within
-                  ESP and AH", RFC 2403, November 1998.
-
-   [RFC-2404]     Madson, C., and Glenn, R., "The Use of HMAC-SHA-1
-                  within ESP and AH", RFC 2404, November 1998.
-
-   [RFC-2405]     Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
-                  Algorithm With Explicit IV", RFC 2405, November 1998.
-
-   [RFC-2406]     Kent, S. and Atkinson, R., "IP Encapsulating Security
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 14]
-
-
-
-
-
-Internet-Draft
-
-
-                  Protocol (ESP)", RFC 2406, November 1998.
-
-   [RFC-2407]     Piper, D., "The Internet IP Security Domain of
-                  Interpretation for ISAKMP", RFC 2407, November 1998.
-
-   [RFC-2408]     Maughan, D., Schertler, M., Schneider, M., and Turner,
-                  J., "Internet Security Association and Key Management
-                  Protocol (ISAKMP)", RFC 2408, November 1998.
-
-   [RFC-2409]     Harkins, D., and Carrel, D., "The Internet Key
-                  Exchange (IKE)", RFC 2409, November 1998.
-
-   [RFC-2410]     Glenn, R. and Kent, S., "The NULL Encryption Algorithm
-                  and Its Use With IPsec", RFC 2410, November 1998.
-
-   [RFC-2451]     Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher
-                  Algorithms", RFC 2451, November 1998.
-
-   [RFC-2460]     Deering, S. and Hinden, R., "Internet Protocol, Ver-
-                  sion 6 (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC-2461]     Narten, T., Nordmark, E. and Simpson, W., "Neighbor
-                  Discovery for IP Version 6 (IPv6)", RFC 2461, December
-                  1998.
-
-   [RFC-2462]     Thomson, S. and Narten, T., "IPv6 Stateless Address
-                  Autoconfiguration", RFC 2462.
-
-   [RFC-2463]     Conta, A. and Deering, S., "ICMP for the Internet Pro-
-                  tocol Version 6 (IPv6)", RFC 2463, December 1998.
-
-   [RFC-2472]     Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
-                  2472, December 1998.
-
-   [RFC-2473]     Conta, A. and Deering, S., "Generic Packet Tunneling
-                  in IPv6 Specification", RFC 2473, December 1998.  Xxx
-                  add
-
-   [RFC-2671]     Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                  2671, August 1999.
-
-   [RFC-2710]     Deering, S., Fenner, W. and Haberman, B., "Multicast
-                  Listener Discovery (MLD) for IPv6", RFC 2710, October
-                  1999.
-
-   [RFC-2711]     Partridge, C. and Jackson, A., "IPv6 Router Alert
-                  Option", RFC 2711, October 1999.
-
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 15]
-
-
-
-
-
-Internet-Draft
-
-
-   [RFC-3041]     Narten, T. and Draves, R., "Privacy Extensions for
-                  Stateless Address Autoconfiguration in IPv6", RFC
-                  3041, January 2001.
-
-   [RFC-3152]     Bush, R., "Delegation of IP6.ARPA", RFC 3152, August
-                  2001.
-
-   [RFC-3315]     Bound, J. et al., "Dynamic Host Configuration Protocol
-                  for IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-   [RFC-3363]     Bush, R., et al., "Representing Internet Protocol ver-
-                  sion 6 (IPv6) Addresses in the Domain Name System
-                  (DNS)", RFC 3363, August 2002.
-
-   [RFC-3484]     Draves, R., "Default Address Selection for IPv6", RFC
-                  3484, February 2003.
-
-   [RFC-3513]     Hinden, R. and Deering, S. "IP Version 6 Addressing
-                  Architecture", RFC 3513, April 2003.
-
-   [RFC-3590]     Haberman, B., "Source Address Selection for the Multi-
-                  cast Listener Discovery (MLD) Protocol", RFC 3590,
-                  September 2003.
-
-   [RFC-3596]     Thomson, S., et al., "DNS Extensions to support IP
-                  version 6", RFC 3596, October 2003.
-
-   [RFC-3602]     S. Frankel, "The AES-CBC Cipher Algorithm and Its Use
-                  with IPsec", RFC 3602, September 2003.
-
-12.2 Non-Normative
-
-   [ANYCAST]      Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast",
-                  draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in
-                  Progress.
-
-   [DESDIFF]      Biham, E., Shamir, A., "Differential Cryptanalysis of
-                  DES-like cryptosystems", Journal of Cryptology Vol 4, Jan
-                  1991.
-
-   [DESCRACK]     Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
-   
-   [DESINT]       Bellovin, S., "An Issue With DES-CBC When Used Without
-                  Strong Integrity", Proceedings of the 32nd IETF, Danvers,
-                  MA, April 1995.
-
-   [DHCPv6-SL]    Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser-
-                  vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 16]
-
-
-
-
-
-Internet-Draft
-
-
-                  Progress.
-
-   [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
-                  S., "DNS Security Introduction and Requirements" draft-
-                  ietf-dnsext-dnssec-intro- 06.txt, Work in Progress.
-
-   [DNSSEC-REC]   Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
-                  S., "Resource Records for the DNS Security Extensions",
-                  draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro-
-                  gress.
-
-   [DNSSEC-PROT]  Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
-                  S., "Protocol Modifications for the DNS Security Exten-
-                  sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work
-                  in Progress.
-
-   [IKE2]         Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto-
-                  col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress.
-  
-   [IPv6-RH]      P. Savola, "Security of IPv6 Routing Header and Home
-                  Address Options", draft-savola-ipv6-rh-ha-security-
-                  03.txt, Work in Progress, March 2002.
-
-   [MC-THREAT]    Ballardie A. and Crowcroft, J.; Multicast-Specific Secu-
-                  rity Threats and Counter-Measures; In Proceedings "Sympo-
-                  sium on Network and Distributed System Security", Febru-
-                  ary 1995, pp.2-16.
-
-   [RFC-793]      Postel, J., "Transmission Control Protocol", RFC 793,
-                  August 1980.
-
-   [RFC-1034]     Mockapetris, P., "Domain names - concepts and facili-
-                  ties", RFC 1034, November 1987.
-
-   [RFC-2147]     Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147,
-                  May 1997.
-
-   [RFC-2205]     Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and
-                  S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC
-                  2205, September 1997.
-
-   [RFC-2464]     Crawford, M., "Transmission of IPv6 Packets over Ethernet
-                  Networks", RFC 2462, December 1998.
-
-   [RFC-2492]     G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over
-                  ATM Networks", RFC 2492, January 1999.
-
-   [RFC-2675]     Borman, D., Deering, S. and Hinden, B., "IPv6
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 17]
-
-
-
-
-
-Internet-Draft
-
-
-                  Jumbograms", RFC 2675, August 1999.
-
-   [RFC-2732]     R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
-                  IPv6 Addresses in URL's", RFC 2732, December 1999.
-
-   [RFC-2851]     M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
-                  "Textual Conventions for Internet Network Addresses", RFC
-                  2851, June 2000.
-
-   [RFC-2893]     Gilligan, R. and Nordmark, E., "Transition Mechanisms for
-                  IPv6 Hosts and Routers", RFC 2893, August 2000.
-
-   [RFC-3569]     S. Bhattacharyya, Ed., "An Overview of Source-Specific
-                  Multicast (SSM)", RFC 3569, July 2003.
-
-   [SSM-ARCH]     H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
-                  draft-ietf- ssm-arch-03.txt, Work in Progress.
-
-13. Authors and Acknowledgements
-
-   This document was written by the IPv6 Node Requirements design team:
-
-      Jari Arkko
-      [jari.arkko@ericsson.com]
-
-      Marc Blanchet
-      [marc.blanchet@viagenie.qc.ca]
-
-      Samita Chakrabarti
-      [samita.chakrabarti@eng.sun.com]
-
-      Alain Durand
-      [alain.durand@sun.com]
-
-      Gerard Gastaud
-      [gerard.gastaud@alcatel.fr]
-
-      Jun-ichiro itojun Hagino
-      [itojun@iijlab.net]
-
-      Atsushi Inoue
-      [inoue@isl.rdc.toshiba.co.jp]
-
-      Masahiro Ishiyama
-      [masahiro@isl.rdc.toshiba.co.jp]
-
-      John Loughney
-      [john.loughney@nokia.com]
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 18]
-
-
-
-
-
-Internet-Draft
-
-
-      Rajiv Raghunarayan
-      [raraghun@cisco.com]
-
-      Shoichi Sakane
-      [shouichi.sakane@jp.yokogawa.com]
-
-      Dave Thaler
-      [dthaler@windows.microsoft.com]
-
-      Juha Wiljakka
-      [juha.wiljakka@Nokia.com]
-
-   The authors would like to thank Ran Atkinson, Jim Bound, Brian Car-
-   penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten,
-   Juha Ollila and Pekka Savola for their comments.
-
-14. Editor's Contact Information
-
-   Comments or questions regarding this document should be sent to the
-   IPv6 Working Group mailing list (ipv6@ietf.org) or to:
-
-      John Loughney
-      Nokia Research Center
-      Itamerenkatu 11-13
-      00180 Helsinki
-      Finland
-
-      Phone: +358 50 483 6242
-      Email: John.Loughney@Nokia.com
-
-Notices
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to per-
-   tain to the implementation or use of the technology described in this
-   document or the extent to which any license under such rights might
-   or might not be available; neither does it represent that it has made
-   any effort to identify any such rights.  Information on the IETF's
-   procedures with respect to rights in standards-track and standards-
-   related documentation can be found in BCP-11.  Copies of claims of
-   rights made available for publication and any assurances of licenses
-   to be made available, or the result of an attempt made to obtain a
-   general license or permission for the use of such proprietary rights
-   by implementors or users of this specification can be obtained from
-   the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 19]
-
-
-
-
-
-Internet-Draft
-
-
-   rights, which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 20]
-
-
diff --git a/doc/draft/draft-ietf-secsh-dns-05.txt b/doc/draft/draft-ietf-secsh-dns-05.txt
deleted file mode 100644
index a272d81b0a60..000000000000
--- a/doc/draft/draft-ietf-secsh-dns-05.txt
+++ /dev/null
@@ -1,614 +0,0 @@
-Secure Shell Working Group                                   J. Schlyter
-Internet-Draft                                                   OpenSSH
-Expires: March 5, 2004                                        W. Griffin
-                                                                  SPARTA
-                                                       September 5, 2003
-
-
-           Using DNS to Securely Publish SSH Key Fingerprints
-                      draft-ietf-secsh-dns-05.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 5, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-   This document describes a method to verify SSH host keys using
-   DNSSEC. The document defines a new DNS resource record that contains
-   a standard SSH key fingerprint.
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 1]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    SSH Host Key Verification  . . . . . . . . . . . . . . . . .  3
-   2.1   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.2   Implementation Notes . . . . . . . . . . . . . . . . . . . .  3
-   2.3   Fingerprint Matching . . . . . . . . . . . . . . . . . . . .  4
-   2.4   Authentication . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.    The SSHFP Resource Record  . . . . . . . . . . . . . . . . .  4
-   3.1   The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . .  5
-   3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . .  5
-   3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . .  5
-   3.1.3 Fingerprint  . . . . . . . . . . . . . . . . . . . . . . . .  5
-   3.2   Presentation Format of the SSHFP RR  . . . . . . . . . . . .  6
-   4.    Security Considerations  . . . . . . . . . . . . . . . . . .  6
-   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7
-         Normative References . . . . . . . . . . . . . . . . . . . .  8
-         Informational References . . . . . . . . . . . . . . . . . .  8
-         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  9
-   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
-         Intellectual Property and Copyright Statements . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 2]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-1. Introduction
-
-   The SSH [6] protocol provides secure remote login and other secure
-   network services over an insecure network.  The security of the
-   connection relies on the server authenticating itself to the client
-   as well as the user authenticating itself to the server.
-
-   If a connection is established to a server whose public key is not
-   already known to the client, a fingerprint of the key is presented to
-   the user for verification.  If the user decides that the fingerprint
-   is correct and accepts the key, the key is saved locally and used for
-   verification for all following connections. While some
-   security-conscious users verify the fingerprint out-of-band before
-   accepting the key, many users blindly accept the presented key.
-
-   The method described here can provide out-of-band verification by
-   looking up a fingerprint of the server public key in the DNS [1][2]
-   and using DNSSEC [5] to verify the lookup.
-
-   In order to distribute the fingerprint using DNS, this document
-   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
-
-   Basic understanding of the DNS system [1][2] and the DNS security
-   extensions [5] is assumed by this document.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [3].
-
-2. SSH Host Key Verification
-
-2.1 Method
-
-   Upon connection to a SSH server, the SSH client MAY look up the SSHFP
-   resource record(s) for the host it is connecting to.  If the
-   algorithm and fingerprint of the key received from the SSH server
-   match the algorithm and fingerprint of one of the SSHFP resource
-   record(s) returned from DNS, the client MAY accept the identity of
-   the server.
-
-2.2 Implementation Notes
-
-   Client implementors SHOULD provide a configurable policy used to
-   select the order of methods used to verify a host key. This document
-   defines one method: Fingerprint storage in DNS. Another method
-   defined in the SSH Architecture [6] uses local files to store keys
-   for comparison. Other methods that could be defined in the future
-   might include storing fingerprints in LDAP or other databases. A
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 3]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   configurable policy will allow administrators to determine which
-   methods they want to use and in what order the methods should be
-   prioritized. This will allow administrators to determine how much
-   trust they want to place in the different methods.
-
-   One specific scenario for having a configurable policy is where
-   clients do not use fully qualified host names to connect to servers.
-   In this scenario, the implementation SHOULD verify the host key
-   against a local database before verifying the key via the fingerprint
-   returned from DNS. This would help prevent an attacker from injecting
-   a DNS search path into the local resolver and forcing the client to
-   connect to a different host.
-
-2.3 Fingerprint Matching
-
-   The public key and the SSHFP resource record are matched together by
-   comparing algorithm number and fingerprint.
-
-      The public key algorithm and the SSHFP algorithm number MUST
-      match.
-
-      A message digest of the public key, using the message digest
-      algorithm specified in the SSHFP fingerprint type, MUST match the
-      SSHFP fingerprint.
-
-
-2.4 Authentication
-
-   A public key verified using this method MUST NOT be trusted if the
-   SSHFP resource record (RR) used for verification was not
-   authenticated by a trusted SIG RR.
-
-   Clients that do validate the DNSSEC signatures themselves SHOULD use
-   standard DNSSEC validation procedures.
-
-   Clients that do not validate the DNSSEC signatures themselves MUST
-   use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
-   between themselves and the entity performing the signature
-   validation.
-
-3. The SSHFP Resource Record
-
-   The SSHFP resource record (RR) is used to store a fingerprint of a
-   SSH public host key that is associated with a Domain Name System
-   (DNS) name.
-
-   The RR type code for the SSHFP RR is TBA.
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 4]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-3.1 The SSHFP RDATA Format
-
-   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
-   type and the fingerprint of the public host key.
-
-         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-         |   algorithm   |    fp type    |                               /
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
-         /                                                               /
-         /                          fingerprint                          /
-         /                                                               /
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1.1 Algorithm Number Specification
-
-   This algorithm number octet describes the algorithm of the public
-   key.  The following values are assigned:
-
-          Value    Algorithm name
-          -----    --------------
-          0        reserved
-          1        RSA
-          2        DSS
-
-   Reserving other types requires IETF consensus [4].
-
-3.1.2 Fingerprint Type Specification
-
-   The fingerprint type octet describes the message-digest algorithm
-   used to calculate the fingerprint of the public key.  The following
-   values are assigned:
-
-          Value    Fingerprint type
-          -----    ----------------
-          0        reserved
-          1        SHA-1
-
-   Reserving other types requires IETF consensus [4].
-
-   For interoperability reasons, as few fingerprint types as possible
-   should be reserved.  The only reason to reserve additional types is
-   to increase security.
-
-3.1.3 Fingerprint
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 5]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   The fingerprint is calculated over the public key blob as described
-   in [7].
-
-   The message-digest algorithm is presumed to produce an opaque octet
-   string output which is placed as-is in the RDATA fingerprint field.
-
-3.2 Presentation Format of the SSHFP RR
-
-   The RDATA of the presentation format of the SSHFP resource record
-   consists of two numbers (algorithm and fingerprint type) followed by
-   the fingerprint itself presented in hex, e.g:
-
-         host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
-
-   The use of mnemonics instead of numbers is not allowed.
-
-4. Security Considerations
-
-   Currently, the amount of trust a user can realistically place in a
-   server key is proportional to the amount of attention paid to
-   verifying that the public key presented actually corresponds to the
-   private key of the server. If a user accepts a key without verifying
-   the fingerprint with something learned through a secured channel, the
-   connection is vulnerable to a man-in-the-middle attack.
-
-   The overall security of using SSHFP for SSH host key verification is
-   dependent on the security policies of the SSH host administrator and
-   DNS zone administrator (in transferring the fingerprint), detailed
-   aspects of how verification is done in the SSH implementation, and in
-   the client's diligence in accessing the DNS in a secure manner.
-
-   One such aspect is in which order fingerprints are looked up (e.g.
-   first checking local file and then SSHFP).  We note that in addition
-   to protecting the first-time transfer of host keys, SSHFP can
-   optionally be used for stronger host key protection.
-
-      If SSHFP is checked first, new SSH host keys may be distributed by
-      replacing the corresponding SSHFP in DNS.
-
-      If SSH host key verification can be configured to require SSHFP,
-      SSH host key revocation can be implemented by removing the
-      corresponding SSHFP from DNS.
-
-   As stated in Section 2.2, we recommend that SSH implementors provide
-   a policy mechanism to control the order of methods used for host key
-   verification. One specific scenario for having a configurable policy
-   is where clients use unqualified host names to connect to servers. In
-   this case, we recommend that SSH implementations check the host key
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 6]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   against a local database before verifying the key via the fingerprint
-   returned from DNS. This would help prevent an attacker from injecting
-   a DNS search path into the local resolver and forcing the client to
-   connect to a different host.
-
-   A different approach to solve the DNS search path issue would be for
-   clients to use a trusted DNS search path, i.e., one not acquired
-   through DHCP or other autoconfiguration mechanisms. Since there is no
-   way with current DNS lookup APIs to tell whether a search path is
-   from a trusted source, the entire client system would need to be
-   configured with this trusted DNS search path.
-
-   Another dependency is on the implementation of DNSSEC itself.  As
-   stated in Section 2.4, we mandate the use of secure methods for
-   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
-   is especially important if SSHFP is to be used as a basis for host
-   key rollover and/or revocation, as described above.
-
-   Since DNSSEC only protects the integrity of the host key fingerprint
-   after it is signed by the DNS zone administrator, the fingerprint
-   must be transferred securely from the SSH host administrator to the
-   DNS zone administrator.  This could be done manually between the
-   administrators or automatically using secure DNS dynamic update [11]
-   between the SSH server and the nameserver.  We note that this is no
-   different from other key enrollment situations, e.g. a client sending
-   a certificate request to a certificate authority for signing.
-
-5. IANA Considerations
-
-   IANA needs to allocate a RR type code for SSHFP from the standard RR
-   type space (type 44 requested).
-
-   IANA needs to open a new registry for the SSHFP RR type for public
-   key algorithms.  Defined types are:
-
-         0 is reserved
-         1 is RSA
-         2 is DSA
-
-    Adding new reservations requires IETF consensus [4].
-
-   IANA needs to open a new registry for the SSHFP RR type for
-   fingerprint types.  Defined types are:
-
-         0 is reserved
-         1 is SHA-1
-
-    Adding new reservations requires IETF consensus [4].
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 7]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Normative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [5]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [6]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
-        Lehtinen, "SSH Protocol Architecture",
-        draft-ietf-secsh-architecture-14 (work in progress), July 2003.
-
-   [7]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
-        Lehtinen, "SSH Transport Layer Protocol",
-        draft-ietf-secsh-transport-16 (work in progress), July 2003.
-
-Informational References
-
-   [8]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
-         Roadmap", RFC 2411, November 1998.
-
-   [9]   Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-         2845, May 2000.
-
-   [10]  Eastlake, D., "DNS Request and Transaction Signatures (
-         SIG(0)s)", RFC 2931, September 2000.
-
-   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 8]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Authors' Addresses
-
-   Jakob Schlyter
-   OpenSSH
-   812 23rd Avenue SE
-   Calgary, Alberta  T2G 1N8
-   Canada
-
-   EMail: jakob@openssh.com
-   URI:   http://www.openssh.com/
-
-
-   Wesley Griffin
-   SPARTA
-   7075 Samuel Morse Drive
-   Columbia, MD  21046
-   USA
-
-   EMail: wgriffin@sparta.com
-   URI:   http://www.sparta.com/
-
-Appendix A. Acknowledgements
-
-   The authors gratefully acknowledge, in no particular order, the
-   contributions of the following persons:
-
-      Martin Fredriksson
-
-      Olafur Gudmundsson
-
-      Edward Lewis
-
-      Bill Sommerfeld
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 9]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                 [Page 10]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                 [Page 11]
-
diff --git a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
deleted file mode 100644
index 3578d2a15eb8..000000000000
--- a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
+++ /dev/null
@@ -1,519 +0,0 @@
-
-Internet Draft                                          Johan Ihren
-draft-ihren-dnsext-threshold-validation-00.txt          Autonomica
-February 2003
-Expires in six months
-
-
-                        Threshold Validation: 
-
-	 A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other
-   documents at any time. It is inappropriate to use Internet-Drafts
-   as reference material or to cite them other than as "work in
-   progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-   This memo documents a proposal for a different method of validation
-   for DNSSEC aware resolvers. The key change is that by changing from
-   a model of one Key Signing Key, KSK, at a time to multiple KSKs it
-   will be possible to increase the aggregated trust in the signed
-   keys by leveraging from the trust associated with the different
-   signees. 
-
-   By having multiple keys to chose from validating resolvers get the
-   opportunity to use local policy to reflect actual trust in
-   different keys. For instance, it is possible to trust a single,
-   particular key ultimately, while requiring multiple valid
-   signatures by less trusted keys for validation to succeed.
-   Furthermore, with multiple KSKs there are additional redundancy
-   benefits available since it is possible to roll over different KSKs
-   at different times which may make rollover scenarios easier to
-   manage.
-
-Contents
-
-	1. Terminology
-	2. Introduction and Background
-
-	3. Trust in DNSSEC Keys
-	3.1. Key Management, Split Keys and Trust Models
-	3.2. Trust Expansion: Authentication versus Authorization
-
-	4. Proposed Semantics for Signing the KEY Resource Record 
-           Set
-	4.1. Packet Size Considerations
-
-	5. Proposed Use of Multiple "Trusted Keys" in a Validating 
-           Resolver
-	5.1. Not All Possible KSKs Need to Be Trusted
-	5.2. Possible to do Threshold Validation
-	5.3. Not All Trusted Keys Will Be Available
-
-	6. Additional Benefits from Having Multiple KSKs
-	6.1. More Robust Key Rollovers
-	6.2. Evaluation of Multiple Key Distribution Mechanisms
-
-	7. Security Considerations
-	8. IANA Considerations.
-	9. References
-	9.1. Normative.
-	9.2. Informative.
-	10. Acknowledgments.
-	11. Authors' Address
-
-
-1. Terminology
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in
-   RFC 2119. 
-
-   The term "zone" refers to the unit of administrative control in the
-   Domain Name System. "Name server" denotes a DNS name server that is
-   authoritative (i.e. knows all there is to know) for a DNS zone,
-   typically the root zone. A "resolver", is a DNS "client", i.e. an
-   entity that sends DNS queries to authoritative nameservers and
-   interpret the results. A "validating resolver" is a resolver that
-   attempts to perform DNSSEC validation on data it retrieves by doing
-   DNS lookups.
-
-
-2. Introduction and Background
-
-   From a protocol perspective there is no real difference between
-   different keys in DNSSEC. They are all just keys. However, in
-   actual use there is lots of difference. First and foremost, most
-   DNSSEC keys have in-band verification. I.e. the keys are signed by
-   some other key, and this other key is in its turn also signed by
-   yet another key. This way a "chain of trust" is created. Such
-   chains have to end in what is referred to as a "trusted key" for
-   validation of DNS lookups to be possible. 
-
-   A "trusted key" is a the public part of a key that the resolver
-   acquired by some other means than by looking it up in DNS. The
-   trusted key has to be explicitly configured.
-
-   A node in the DNS hierarchy that issues such out-of-band "trusted
-   keys" is called a "security apex" and the trusted key for that apex
-   is the ultimate source of trust for all DNS lookups within that
-   entire subtree.
-
-   DNSSEC is designed to be able to work with more than on security
-   apex. These apexes will all share the problem of how to distribute
-   their "trusted keys" in a way that provides validating resolvers
-   confidence in the distributed keys. 
-
-   Maximizing that confidence is crucial to the usefulness of DNSSEC
-   and this document tries to address this issue.
-
-
-3. Trust in DNSSEC Keys
-
-   In the end the trust that a validating resolver will be able to put
-   in a key that it cannot validate within DNSSEC will have to be a
-   function of
-
-   	    * trust in the key issuer, aka the KSK holder
-
-	    * trust in the distribution method
-
-	    * trust in extra, out-of-band verification
-
-   The KSK holder needs to be trusted not to accidentally lose private
-   keys in public places. Furthermore it needs to be trusted to
-   perform correct identification of the ZSK holders in case they are
-   separate from the KSK holder itself.
-
-   The distribution mechanism can be more or less tamper-proof. If the
-   key holder publishes the public key, or perhaps just a secure
-   fingerprint of the key in a major newspaper it may be rather
-   difficult to tamper with. A key acquired that way may be easier to
-   trust than if it had just been downloaded from a web page.
-
-   Out-of-band verification can for instance be the key being signed
-   by a certificate issued by a known Certificate Authority that the
-   resolver has reason to trust.
-
-3.1. Simplicity vs Trust 
-
-   The fewer keys that are in use the simpler the key management
-   becomes. Therefore increasing the number of keys should only be
-   considered when the complexity is not the major concern. A perfect
-   example of this is the distinction between so called Key Signing
-   Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
-   overall complexity but simplifies real life operations and was an
-   overall gain since operational simplification was considered to be
-   a more crucial issue than the added complexity.
-
-   In the case of a security apex there are additional issues to
-   consider, among them
-
-      * maximizing trust in the KSK received out-of-band
-
-      * authenticating the legitimacy of the ZSKs used
-
-   In some cases this will be easy, since the same entity will manage
-   both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
-   similar to a self-signed certificate). In some environments it will
-   be possible to get the trusted key installed in the resolver end by
-   decree (this would seem to be a likely method within corporate and
-   government environments).
-
-   In other cases, however, this will possibly not be sufficient. In
-   the case of the root zone this is obvious, but there may well be
-   other cases.
-
-3.2. Expanding the "Trust Base"
-
-   For a security apex where the ZSKs and KSK are not held by the same
-   entity the KSK will effectively authenticate the identity of
-   whoever does real operational zone signing. The amount of trust
-   that the data signed by a ZSK will get is directly dependent on
-   whether the end resolver trusts the KSK or not, since the resolver
-   has no OOB access to the public part of the ZSKs (for practical
-   reasons).
-
-   Since the KSK holder is distinct from the ZSK holder the obvious
-   question is whether it would then be possible to further improve
-   the situation by using multiple KSK holders and thereby expanding
-   the trust base to the union of that available to each individual
-   KSK holder. "Trust base" is an invented term intended to signify
-   the aggregate of Internet resolvers that will eventually choose to
-   trust a key issued by a particular KSK holder.
-
-   A crucial issue when considering trust expansion through addition
-   of multiple KSK holders is that the KSK holders are only used to
-   authenticate the ZSKs used for signing the zone. I.e. the function
-   performed by the KSK is basically:
-
-   	     "This is indeed the official ZSK holder for this zone,
-   	     I've verified this fact to the best of my abilitites."
-
-   Which can be thought of as similar to the service of a public
-   notary. I.e. the point with adding more KSK holders is to improve
-   the public trust in data signed by the ZSK holders by improving the
-   strength of available authentication. 
-
-   Therefore adding more KSK holders, each with their own trust base,
-   is by definition a good thing. More authentication is not
-   controversial. On the contrary, when it comes to authentication,
-   the more the merrier.
-
-   
-4. Proposed Semantics for Signing the KEY Resource Record Set
-
-   In DNSSEC according to RFC2535 all KEY Resource Records are used to
-   sign all authoritative data in the zone, including the KEY RRset
-   itself, since RFC2535 makes no distinction between Key Signing
-   Keys, KSK, and Zone Signing Keys, ZSK.  With Delegation Signer [DS]
-   it is possible to change this to the KEY RRset being signed with
-   all KSKs and ZSKs but the rest of the zone only being signed by the
-   ZSKs.
-
-   This proposal changes this one step further, by recommending that
-   the KEY RRset is only signed by the Key Signing Keys, KSK, and
-   explicitly not by the Zone Signing Keys, ZSK. The reason for this
-   is to maximize the amount of space in the DNS response packet that
-   is available for additional KSKs and signatures thereof. The rest
-   of the authoritative zone contents are as previously signed by only
-   the ZSKs.
-
-4.1. Packet Size Considerations
-
-   The reason for the change is to keep down the size of the aggregate
-   of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
-   perform validation of data below a security apex. For DNSSEC data
-   to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
-   set, and therefore the allowed packet size can be assumed to be at
-   least the EDNS0 minimum of 4000 bytes.
-
-   When querying for KEY + SIG(KEY) for "." (the case that is assumed
-   to be most crucial) the size of the response packet after the
-   change to only sign the KEY RR with the KSKs break down into a
-   rather large space of possibilities. Here are a few examples for
-   the possible alternatives for different numbers of KSKs and ZSKs
-   for some different key lengths (all RSA keys, with a public
-   exponent that is < 254). This is all based upon the size of the
-   response for the particular example of querying for
-   
-	". KEY IN"
-
-   with a response of entire KEY + SIG(KEY) with the authority and
-   additional sections empty:
-
-   	      ZSK/768 and KSK/1024   (real small)
-	      Max 12 KSK +  3 ZSK  at 3975
-	          10 KSK +  8 ZSK  at 3934
-		   8 KSK + 13 ZSK  at 3893
-
-	      ZSK/768 + KSK/1280
-	      MAX 10 KSK +  2 ZSK  at 3913
-	           8 KSK +  9 ZSK  at 3970
-                   6 KSK + 15 ZSK  at 3914
-
-	      ZSK/768 + KSK/1536
-	      MAX  8 KSK +  4 ZSK  at 3917
-                   7 KSK +  8 ZSK  at 3938
-                   6 KSK + 12 ZSK  at 3959
-
-              ZSK/768 + KSK/2048
-              MAX  6 KSK +  5 ZSK  at 3936
-                   5 KSK + 10 ZSK  at 3942
-
-              ZSK/1024 + KSK/1024
-              MAX 12 KSK +  2 ZSK  at 3943
-                  11 KSK +  4 ZSK  at 3930
-                  10 KSK +  6 ZSK  at 3917
-                   8 KSK + 10 ZSK  at 3891
-
-              ZSK/1024 + KSK/1536
-              MAX  8 KSK +  3 ZSK  at 3900
-                   7 KSK +  6 ZSK  at 3904
-                   6 KSK +  9 ZSK  at 3908
-
-              ZSK/1024 + KSK/2048
-              MAX  6 KSK +  4 ZSK  at 3951
-                   5 KSK +  8 ZSK  at 3972
-                   4 KSK + 12 ZSK  at 3993
-
-   Note that these are just examples and this document is not making
-   any recommendations on suitable choices of either key lengths nor
-   number of different keys employed at a security apex.
-
-   This document does however, based upon the above figures, make the
-   recommendation that at a security apex that expects to distribute
-   "trusted keys" the KEY RRset should only be signed with the KSKs
-   and not with the ZSKs to keep the size of the response packets
-   down.
-
-
-5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
-
-   In DNSSEC according to RFC2535[RFC2535] validation is the process
-   of tracing a chain of signatures (and keys) upwards through the DNS
-   hierarchy until a "trusted key" is reached. If there is a known
-   trusted key present at a security apex above the starting point
-   validation becomes an exercise with a binary outcome: either the
-   validation succeeds or it fails. No intermediate states are
-   possible.
-
-   With multiple "trusted keys" (i.e. the KEY RRset for the security
-   apex signed by multiple KSKs) this changes into a more complicated
-   space of alternatives. From the perspective of complexity that may
-   be regarded as a change for the worse. However, from a perspective
-   of maximizing available trust the multiple KSKs add value to the
-   system.
-
-5.1. Possible to do Threshold Validation
-
-   With multiple KSKs a new option that opens for the security
-   concious resolver is to not trust a key individually. Instead the
-   resolver may decide to require the validated signatures to exceed a
-   threshold. For instance, given M trusted keys it is possible for
-   the resolver to require N-of-M signatures to treat the data as
-   validated.
-
-   I.e. with the following pseudo-configuration in a validating
-   resolver
-
-   	security-apex "." IN {
-	   keys { ksk-1 .... ;
-      	          ksk-2 .... ;
-	          ksk-3 .... ; 
-		  ksk-4 .... ;
-		  ksk-5 .... ;
-	        };
-	   validation {
-	      # Note that ksk-4 is not present below
-	      keys { ksk-1; ksk-2; ksk-3; ksk-5; }; 
-              # 3 signatures needed with 4 possible keys, aka 75%
-              needed-signatures 3;
-           };
-	};
-
-   we configure five trusted keys for the root zone, but require two
-   valid signatures for the top-most KEY for validation to
-   succeed. I.e.  threshold validation does not force multiple
-   signatures on the entire signature chain, only on the top-most
-   signature, closest to the security apex for which the resolver has
-   trusted keys.		    
-
-5.2. Not All Trusted Keys Will Be Available
-
-   With multiple KSKs held and managed by separate entities the end
-   resolvers will not always manage to get access to all possible
-   trusted keys. In the case of just a single KSK this would be fatal
-   to validation and necessary to avoid at whatever cost. But with
-   several fully trusted keys available the resolver can decide to
-   trust several of them individually. An example based upon more
-   pseudo-configuration:
-
-   	security-apex "." IN {
-	   keys { ksk-1 .... ;
-      	          ksk-2 .... ;
-	          ksk-3 .... ; 
-		  ksk-4 .... ;
-		  ksk-5 .... ;
-	        };
-	   validation {
-	      # Only these two keys are trusted independently
-	      keys { ksk-1; ksk-4; }; 
-              # With these keys a single signature is sufficient
-	      needed-signatures 1;
-           };
-	};
-
-   Here we have the same five keys and instruct the validating
-   resolver to fully trust data that ends up with just one signature
-   from by a fully trusted key.
-
-   The typical case where this will be useful is for the case where
-   there is a risk of the resolver not catching a rollover event by
-   one of the KSKs. By doing rollovers of different KSKs with
-   different schedules it is possible for a resolver to "survive"
-   missing a rollover without validation breaking. This improves
-   overall robustness from a management point of view.
-
-5.3. Not All Possible KSKs Need to Be Trusted
-
-   With just one key available it simply has to be trusted, since that
-   is the only option available. With multiple KSKs the validating
-   resolver immediately get the option of implementing a local policy
-   of only trusting some of the possible keys.
-
-   This local policy can be implemented either by simply not
-   configuring keys that are not trusted or, possibly, configure them
-   but specify to the resolver that certain keys are not to be
-   ultimately trusted alone.
-
-
-6. Additional Benefits from Having Multiple KSKs
-
-6.1. More Robust Key Rollovers
-
-   With only one KSK the rollover operation will be a delicate
-   operation since the new trusted key needs to reach every validating
-   resolver before the old key is retired. For this reason it is
-   expected that long periods of overlap will be needed.
-
-   With multiple KSKs this changes into a system where different
-   "series" of KSKs can have different rollover schedules, thereby
-   changing from one "big" rollover to several "smaller" rollovers.
-
-   If the resolver trusts several of the available keys individually
-   then even a failure to track a certain rollover operation within
-   the overlap period will not be fatal to validation since the other
-   available trusted keys will be sufficient.
-
-6.2. Evaluation of Multiple Key Distribution Mechanisms
-
-   Distribution of the trusted keys for the DNS root zone is
-   recognized to be a difficult problem that ...
-
-   With only one trusted key, from one single "source" to distribute
-   it will be difficult to evaluate what distribution mechanism works
-   best. With multiple KSKs, held by separate entitites it will be
-   possible to measure how large fraction of the resolver population
-   that is trusting what subsets of KSKs.
-
-
-7. Security Considerations
-
-   From a systems perspective the simplest design is arguably the
-   best, i.e. one single holder of both KSK and ZSKs. However, if that
-   is not possible in all cases a more complex scheme is needed where
-   additional trust is injected by using multiple KSK holders, each
-   contributing trust, then there are only two alternatives
-   available. The first is so called "split keys", where a single key
-   is split up among KSK holders, each contributing trust. The second
-   is the multiple KSK design outlined in this proposal.
-
-   Both these alternatives provide for threshold mechanisms. However
-   split keys makes the threshold integral to the key generating
-   mechanism (i.e. it will be a property of the keys how many
-   signatures are needed). In the case of multiple KSKs the threshold
-   validation is not a property of the keys but rather local policy in
-   the validating resolver. A benefit from this is that it is possible
-   for different resolvers to use different trust policies. Some may
-   configure threshold validation requiring multiple signatures and
-   specific keys (optimizing for security) while others may choose to
-   accept a single signature from a larger set of keys (optimizing for
-   redundancy). Since the security requirements are different it would
-   seem to be a good idea to make this choice local policy rather than
-   global policy.
-
-   Furthermore, a clear issue for validating resolvers will be how to
-   ensure that they track all rollover events for keys they
-   trust. Even with operlap during the rollover (which is clearly
-   needed) there is still a need to be exceedingly careful not to miss
-   any rollovers (or fail to acquire a new key) since without this
-   single key validation will fail. With multiple KSKs this operation
-   becomes more robust, since different KSKs may roll at different
-   times according to different rollover schedules and losing one key,
-   for whatever reason, will not be crucial unless the resolver
-   intentionally chooses to be completely dependent on that exact key.
-
-8. IANA Considerations.
-
-   NONE.
-
-
-9. References
-
-9.1. Normative.
-
-   [RFC2535] Domain Name System Security Extensions. D. Eastlake. 
-	     March 1999.
-
-   [RFC3090] DNS Security Extension Clarification on Zone Status. 
-	     E. Lewis.  March 2001.
-
-
-9.2. Informative.
-
-   [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
-	     (DNS). D.  Eastlake 3rd. May 2001.
-
-   [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. 
-	     December 2001.
-
-   [DS]      Delegation Signer Resource Record. 
-	     O. Gudmundsson. October 2002. Work In Progress.
-
-10. Acknowledgments.
-
-   Bill Manning came up with the original idea of moving complexity
-   from the signing side down to the resolver in the form of threshold
-   validation. I've also had much appreciated help from (in no
-   particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
-   Olaf Kolkman.
-
-
-11. Authors' Address
-Johan Ihren
-Autonomica AB
-Bellmansgatan 30
-SE-118 47 Stockholm, Sweden
-johani@autonomica.se
diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
deleted file mode 100644
index f9eaf268194f..000000000000
--- a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
+++ /dev/null
@@ -1,1830 +0,0 @@
-  
-  
-  
-  INTERNET-DRAFT                                       S. Daniel Park
-  Expires: October 2003                              Syam Madanapalli
-  File:                                           SAMSUNG Electronics
-  draft-park-ipv6-extensions-dns-pnp-00.txt                April 2003
-  
-  
-  
-  
-                 IPv6 Extensions for DNS Plug and Play
-  
-  
-  
-  Status of This Memo   
-  
-  This document is an Internet-Draft and is in full conformance with
-  all provisions of Section 10 of RFC2026.
-
-  Internet-Drafts are working documents of the Internet Engineering
-  Task Force (IETF), its areas, and its working groups. Note that
-  other groups may also distribute working documents as
-  Internet-Drafts.
-
-  Internet-Drafts are draft documents valid for a maximum of six
-  months and may be updated, replaced, or obsoleted by other
-  documents at any time. It is inappropriate to use Internet-Drafts
-  as reference material or to cite them other than as "work in
-  progress."
-
-  The list of current Internet-Drafts can be accessed at
-  http://www.ietf.org/ietf/1id-abstracts.txt
-
-  The list of Internet-Draft Shadow Directories can be accessed at
-  http://www.ietf.org/shadow.html.
-  
-  
-  
-  Abstract  
-  
-  This document proposes automatic configuration of domain name (FQDN)
-  for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as
-  a part of IPv6 plug and play feature. 6DNAC allows the automatic
-  registration of domain name and corresponding IPv6 Addresses with
-  the DNS server. In order to provide 6DNAC function, Neighbor Discovery
-  Protocol [2461] will be used. Moreover, 6DNAC does not require any
-  changes to the existing DNS system.
-  
-  
-  Table of Contents 
-  
-  1.       Introduction .............................................  3
-  2.       Terminology ..............................................  3
-  3.       6DNAC Design Principles ..................................  4
-  4.       6DNAC Overview ...........................................  4
-  5.       6DNAC Requirements .......................................  5
-  5.1.     6DANR Client Requirements ................................  5
-  5.2.     6DNAC Server Requirements ................................  6
-    
-Park & Madanapalli             Expires October 2003             [Page 1]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003    
-    
-  6.       6DNAC Messages and Option Formats ........................  6
-  6.1.     Router Advertisement (RA) Message Format .................  6
-  6.2.     Neighbor Solicitation (NS) Message Format ................  7
-  6.3.     Neighbor Advertisement (NA) Message Format ...............  8
-  6.4.     Option Formats ...........................................  8
-  6.4.1.   DNS Zone Suffix Information Option Format ................  8
-  6.4.2.   Domain Name (FQDN) Option Format .........................  9
-  6.4.3.   Router Alert Option for 6DNAC ............................ 10
-  7.       6DNAC Operation .......................................... 10
-  7.1.     6DNAC Network Topology ................................... 11
-  7.2.     6DNAC Operational Scenarios .............................. 12
-  7.2.1.   Domain Name Registration-Success Case .................... 12
-  7.2.2.   Domain Name Registration-with DupAddrDetectTransmits=2.... 14
-  7.2.3.   Domain Name Registration-Defend Case ..................... 16
-  7.2.4.   Domain Name Registration in Retry Mode ................... 19
-  7.2.5.   Domain Name Registration when DAD Fails .................. 20
-  7.3.     DNS Zone Suffix Discovery and FQDN Construction .......... 22
-  7.3.1.   Sending Router Advertisement Messages .................... 22
-  7.3.2.   Processing Router Advertisement Messages ................. 22
-  7.3.3.   FQDN Lifetime expiry ..................................... 23
-  7.3.4.   Host Naming Algorithm .................................... 23
-  7.4.     Duplicate Domain Name Detection .......................... 23
-  7.4.1.   DAD with All Nodes Multicast Address ..................... 24
-  7.4.1.1. Sending Neighbor Solicitation Messages ................... 24
-  7.4.1.2. Processing Neighbor Solicitation Messages ................ 24
-  7.4.1.3. Sending Neighbor Advertisement Messages .................. 25
-  7.4.1.4. Processing Neighbor Advertisement Messages ............... 25
-  7.4.1.5. Pros and Cons ............................................ 25
-  7.4.2.   DAD with Router Alert Option for 6DNAC ................... 25
-  7.4.2.1. Sending Neighbor Solicitation Messages ................... 25
-  7.4.2.2. Processing Neighbor Solicitation Messages ................ 26
-  7.4.2.3. Sending Neighbor Advertisement Messages .................. 26
-  7.4.2.4. Processing Neighbor Advertisement Messages ............... 26
-  7.4.2.5. Pros and Cons ............................................ 26
-  7.4.3.   Explicit Detection of Duplicate Domain Name .............. 26
-  7.4.3.1. Sending Neighbor Solicitation Messages ................... 26
-  7.4.3.2. Processing Neighbor Solicitation Messages ................ 26
-  7.4.3.3. Sending Neighbor Advertisement Messages .................. 27
-  7.4.3.4. Processing Neighbor Advertisement Messages ............... 27
-  7.4.3.5. Pros and Cons ............................................ 27
-  7.4.4.   Retry Mode for Re-registering Domain Name ................ 27
-  7.5.     Domain Name Registration ................................. 27
-  8.       Security Consideration ................................... 27
-  9.       IANA Consideration ....................................... 28
-  10.      Acknowledgement .......................................... 28
-  11.      Intellectual Property .................................... 28
-  12.      Copyright ................................................ 28
-  13.      References ............................................... 29
-  14.      Author's Addresses ....................................... 30
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003             [Page 2]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  1. Introduction 
-  
-  Today, most networks use DNS[1034][1035] for convenience. In case of
-  IPv6, DNS is more important element because of IPv6 long addresses
-  which are difficult to remember. In addition, small networks like home
-  networks using IPv6, should be able to make network easily without
-  manual configuration. Also, these small networks may not have DHCP
-  Server, DNS Server etc. that are used to configure the network. This
-  document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure
-  for generating and registering the Domain Name and IPv6 addresses with
-  the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are
-  required to implement lightweight functions specified in this document.
-  6DNAC can be applied to all defined IPv6 unicast addresses except Link
-  local IPv6 addresses, viz: Site-local and Global addresses.
-  
-  6DNAC uses Neighbor Discovery Protocol [2461] with new additions
-  (defined in section 6) and DAD procedures for generating and 
-  registering the Domain Name with the DNS server automatically.
-  
-  
-  2. Terminology
-
-  6DNAC         - IPv6 Domain Name Auto Configuration. It can provide
-                  IPv6 hosts with Domain Name Generation and 
-                  Registration automatically.
-  
-  6DNAC Client  - An IPv6 node that can generate its own unique Domain
-                  Name. Section 3 identifies the new requirements that
-                  6DNAC places on an IPv6 node to be a 6DNAC node.
-                  
-  6DNAC Server  - An IPv6 node that can collect and registrate Domain
-                  Name and IPv6 addresses automatically. 6DNAC server
-                  uses the information from the DAD operation messages
-                  with newly defined options for the registration of the 
-                  Domain Name and IPv6 Addresses. Section 3 identifies
-                  the new requirements that 6DNAC places on an IPv6 
-                  node to be a 6DNAC server. Also 6DNAC server can have 
-                  various other functions depending on network 
-                  environment and the network operator. For instance 
-                  6DNAC Server can acts as a Gateway as well Home Server
-                  in Home Networks.
- 
-  DAD           - Duplicate Address Detection (is defined [2461]) 
-  
-  DFQDND        - Duplicate Domain Name Detection
-
-  FQDN          - Fully Qualified Domain Name - FQDN and Domain Name are 
-                  used interchangeably in this document.
-  
-  NA            - Neighbor Advertisement message (is defined [2461]) 
-  
-  NS            - Neighbor Solicitation message (is defined [2461])
-
-  RA            - Router Advertisement message (is defined [2461]) 
-
-  SLAAC         - Stateless Address Autoconfiguration [2462].
-
-Park & Madanapalli             Expires October 2003             [Page 3]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  3. 6DNAC Design Principles
-  
-  This section discusses the design principles of 6DNAC mechanism.
-  
-  1. The new procedures for plug and play DNS should not cause changes
-     to existing DNS system. 6DNAC requires lightweight functions to be 
-     implemented only at the client side of the DNS system, and uses the 
-     existing DDNS UPDATE [2136] to communicate with DNS Servers.
-  
-  2. Introducing a new protocol will always introduce new problems. 
-     6DNAC uses the existing protocols NDP [2461] with minor extensions 
-     for generating and registering the domain name automatically 
-     without defining a new protocol
-  
-  3. Reusing proven and well understood design principles/patterns 
-     will always yield a robust system. 6DNAC is based on IPv6 Address 
-     Auotoconfiguration principle, where routers advertise the prefix
-     and host adds the interface ID to the prefix and forms the IPv6 
-     address. Domain Name (FQDN) also contains two parts: host name 
-     and DNS zone suffix. Routers can advertise the DNS zone suffix 
-     on a particular link in Router Advertisements (RA Messages) and 
-     hosts can prefix their preferred host name to the DNS zone suffix
-     and form the fully qualified domain name. Also the detection of
-     duplicate domain name is similar to Duplicate Address Detection
-     (DAD) and can be part of DAD operation itself.
-  
-  
-  4. 6DNAC Overview
-  
-  6DNAC proposes minor extensions to NDP [2461] for automatic generation
-  and registration of domain name with the DNS server. It introduces two
-  new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone
-  Suffix option is carried in Router Advertisement (RA) messages for
-  notifying IPv6 nodes about the valid DNS Zone Suffix on the link and
-  FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement
-  (NA) messages to detect duplicate domain name. 6DNAC consists of two
-  components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the
-  domain name based on DNS Zone Suffix using Host Naming Algorithm (see
-  section 7.3.1) and 6DNAC Server collects and registers the DNS
-  information with the DNS Server on behalf of 6DNAC Clients.
-
-  The automatic configuration of domain name using 6DNAC consists of
-  three parts.
-
-     - DNS Zone Suffix Discovery and FQDN Construction:
-
-       IPv6 Nodes collect DNS Zone Suffix information from Router
-       Advertisements and constructs FQDN by prefixing host name to the
-       DNS Zone Suffix. The IPv6 Nodes are required to implement Host 
-       Naming Algorithm for generating host part of the FQDN in the 
-       absence of administrator.
-
-  Generation of node's FQDN within the node itself has advantages. Nodes
-  can provide forward and reverse name lookups independent of the DNS
-  System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain
-  Name is some thing that is owned by the node.
-
-Park & Madanapalli             Expires October 2003             [Page 4]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-     - Duplicate Domain Name Detection
-
-       All nodes are expected to go for DAD for all new IPv6 unicast
-       addresses, regardless of whether they are obtained through 
-       stateful, stateless or manual configuration. 6DNAC uses the DAD 
-       messages with new option for carrying the Domain Name along with 
-       the new IPv6 Address. 6DNAC Server captures this information and
-       updates DNS Server provided that the IPv6 Address and its domain
-       name are not duplicate. If the domain name is already in use, 
-       the 6DNAC server replies to the sender with FQDN Option in NA 
-       message indicating that the domain name is duplicate. Then the
-       node is expected to generate another domain name using host 
-       naming algorithm and go for DAD. This time the DAD is only for
-       duplicate domain name detection (DFQDND). In order to avoid
-       confusion with the normal NDP processing, the target address 
-       field of the NS message must carry the unspecified address 
-       in retry mode.  This can be repeated depending on number of
-       retries defined by the administrator in the host naming algorithm.
-
-  
-     - Domain Name Registration
-
-       6DNAC Server detects the DNS information (IPv6 Address and 
-       corresponding FQDN) from DAD/DFQDND messages and updates DNS 
-       Server using existing protocol DDNS UPDATE [2136] provided that
-       the IPv6 Address and its domain name are not duplicate.
-  
-  If an IPv6 Address is duplicate, the IPv6 node cannot perform
-  stateless address autoconfiguration repeatedly. Unlike IPv6 stateless 
-  address autoconfiguration, 6DNAC allows the automatic configuration of
-  domain name repeatedly if the domain name is duplicate depending on 
-  number of retries defined by the administrator in the host naming 
-  algorithm.
-  
-  
-  5. 6DNAC Requirements 
-  
-  Depending on the 6DNAC functionality, the IPv6 nodes implement, they
-  are called either 6DNAC Clients or 6DNAC Servers. The following 
-  sections lists the requirements that the 6DNAC Client and 6DNAC server
-  must support.
-   
-   
-  5.1. 6DANC Client Requirements
-  
-        - 6DNAC Client must recognize and process the following NDP 
-          extensions
-
-              - DNS Zone Suffix option in RA messages for generating its
-                domain name (FQDN).
-
-              - Domain Name option in NS and NA messages for detecting 
-                the duplicate domain name
- 
- 
- 
-
-Park & Madanapalli             Expires October 2003             [Page 5]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
-  
-        - It must generate its domain name (FQDN) based on the DNS 
-          suffix that it got from the router advertisement. And it must 
-          have a host naming algorithm for generating the host part of
-          the FQDN.
-
-        - If NA message is received with unspecified target address and
-          FQDN option, then the node must treat that the domain is 
-          duplicate.
-  
-  
-  5.2. 6DNAC Server Requirements
-  
-        - 6DNAC Server must recognize and process the following NDP
-          extensions
-      
-              - If the 6DNAC Server is a router on the link, then it
-                must advertise DNS Zone Suffix option in RA messages
-                for hosts to generate their domain name (FQDN).
-
-              - FQDN option in NS messages for detecting new DNS
-                information for of nodes on the link for which it
-                must update the AAAA RR and PTR RR in DNS Server.
-
-              - FQDN option in NA messages for notifying duplicate
-                domain name with unspecified target address.
-  
-        - 6DNAC server must update the DNS Server (both AAAA RR and
-          PTR RR) dynamically using DDNS UPDATE [2136].
-  
-        - 6DNAC server must cache this (newly detected) FQDN, Link
-          Layer Address, and IPv6 Address information, so that it can
-          decide whether it really needs to update DNS Server or not,
-          to avoid redundant updates. This information will also be
-          used for notifying the duplicate domain name.
-  
-  
-  6. 6DNAC Messages and Option Formats
-  
-  In order to achieve the plug and play DNS, 6DNAC proposes new 
-  extensions to the NDP [2461]. This section specifies the new
-  additions to NDP messages and formats of new options.
-  
-  
-  6.1. Router Advertisement (RA) Message Format
-  
-  Routers send out Router Advertisement (RA) message periodically, or
-  in response to a Router Solicitation. 6DNAC does not modify the format
-  of the RA message, but proposes new option (DNS Zone Suffix Information)
-  to be carried in RA messages.
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003             [Page 6]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |     Code      |          Checksum             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                         Reachable Time                        |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                          Retrans Timer                        |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |   Options ...                                                 |
-     /                                                               /
-     |                  DNS Zone Suffix Information                  |
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                          
-  
-  
-  
-  6.2. Neighbor Solicitation (NS) Message Format 
-  
-  6DNAC does not modify the format of the Neighbor Solicitation (NS)
-  message, but proposes new option (FQDN Option) to be carried in NS
-  messages. When a node is going for DAD, the node must include FQDN
-  option in NS message to participate in plug and play DNS. If the
-  node is going for Explicit Detection of Duplicate Domain Name, the
-  node must use FQDN option in NS message and unspecified address in
-  the target address field.
-  
-  
-      0                   1                   2                   3 
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |     Code      |          Checksum             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                           Reserved                            |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +                       Target Address                          +
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |   Options ...                                                 |
-     /                                                               /
-     |                         Domain Name                           |
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                         
-  
-Park & Madanapalli             Expires October 2003             [Page 7]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  6.3. Neighbor Advertisement (NA) Message Format 
-  
-  6DNAC does not modify the format of the Neighbor Advertisement (NA)
-  message, but proposes new option (FQDN Option) to be carried in NA
-  messages. 6DNAC Server sends NA message with FQDN option to 6DNAC
-  Client that is performing duplicate domain name detection in case
-  the domain name found to be duplicate.
-
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |     Code      |          Checksum             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |R|S|O|                     Reserved                            |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +                       Target Address                          +
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |   Options ...                                                 |
-     /                                                               /
-     |                         FQDN Option                           |
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                           
-  
-  
-  6.4 Option Formats
-  
-  6.4.1. DNS Zone Suffix Information Option Format
-  
-  IPv6 nodes require DNS Zone Suffix for constructing their FQDN.
-  6DNAC introduces new option for routers to advertise the DNS Zone
-  Suffix Information for IPv6 nodes on the link. The suffix information
-  should be configured into routers manually.
-
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |    Length     |          Reserved             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                          Valid Lifetime                       |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     /                       DNS Zone Suffix                         /
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                   
-
-Park & Madanapalli             Expires October 2003             [Page 8]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  Type              [TBD]
-  
-  Length            8-bit unsigned integer. The length of the option
-                    (including the type and length fields) in units of
-                    8 octets.
-  
-  Reserved          This field is unused. It must be initialized to zero
-                    by the sender and must be ignored by the receiver.
-  
-  Valid Life Time   32-bit signed integer.  The maximum time, in 
-                    seconds, over which this suffix is valid. Nodes 
-                    should treat this as the life time for their domain
-                    name. Nodes should contact the source of this
-                    information before expiry of this time interval.
-                    A value of all one bits (0xFFFFFFFF) represents
-                    infinity.
-  
-  DNS Zone Suffix   The suffix part of the FQDN. The data in the DNS 
-                    Zone Suffix field should be encoded according to 
-                    DNS encoding rules specified in [1035].
-  
-  
-  
-  6.4.2. Domain Name (FQDN) Option Format
-  
-  
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |    Length     |          Reserved             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                          Valid Lifetime                       |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +                       FQDN Target Address                     +
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     /                         Domain Name                           /
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                      
-  
-  Type                 [TBD]
-  
-  Length               8-bit unsigned integer. The length of the option
-                       (including the type and length fields) in units 
-                       of 8 octets.  It must be greater than 3.
-                       
-                       
-
-Park & Madanapalli             Expires October 2003             [Page 9]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003                       
-  
-  Reserved             This field is unused. It must be initialized to
-                       zero by the sender and must be ignored by the
-                       receiver.
-  
-  Valid Life Time      32-bit signed integer.  The maximum time, in 
-                       seconds, over which this domain name is valid
-                       6DNAC should deregister this domain name at
-                       the expiry of this interval. 6DNAC clients
-                       should send updates by the expiry of this 
-                       interval. A value of all one bits (0xFFFFFFFF)
-                       represents infinity.
-
-  FQDN Target Address  The Address for which the FQDN maps to.  It 
-                       should be same as Target Address field of the 
-                       NS message in case of DAD & duplicate FQDN are
-                       running in parallel.
-
-  Domain Name          The domain name (FQDN) of the node. The data in
-                       the domain name should be encoded according to
-                       DNS encoding rules specified in [1035].
-  
-  
-  6.4.3. Router Alert Option for 6DNAC
-
-  Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop
-  Header for using in NDP messages.  The presence of this option in NS
-  message informs the router that this NS message is carrying Domain
-  Name information and must be processed by the 6DNAC Server on the router.
-  6DNAC Clients can use this option for sending DAD packets instead
-  of addressing the DAD packets to the all-nodes multicast address
-  when 6DNAC Server is implemented on router.
- 
-  The Router Alert option has the following format:
-
-  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0|        Value (2 octets)       |
-  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                     Length = 2
-
-  Values are registered and maintained by the IANA. For 6DNAC, the 
-  value has to be assigned by IANA.
-
-  Further information about this option can be obtained from 
-  IPv6 Router Alert Option [2711].
-
-
-  7. 6DNAC Operation
-  
-  6DNAC provides mechanisms for automatic generation of domain name
-  and registering it with the DNS Server for IPv6 nodes. 6DNAC consists
-  of two components: 6DNAC Client and 6DNAC Server. All nodes that want
-  to participate in plug and play DNS are required to implement 6DNAC
-  Client functionality, and one of the IPv6 nodes is required to 
-  implement 6DNAC Server functionality. The IPv6 node that implements 
-  the 6DNAC Server functionality must know the location of the DNS 
-  Server and must be a trusted node to send DDNS UPDATE [2136] messages.
-
-Park & Madanapalli             Expires October 2003            [Page 10]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  7.1. 6DNAC Network Topology
-  
-  This section identifies the possible locations for the 6DNAC Server.
-  Note that, all nodes are required to implement 6DNAC Client 
-  functionality for constructing the domain name from the DNS Zone 
-  Suffix Information advertised by the router.  Figure 6 illustrates 
-  IPv6 host (H4) implementing 6DNAC Server functionality. In this case 
-  H4 can serve only one link (that it belongs to) for automatic 
-  registration of domain name. H4 must observe the DAD packets on the 
-  link to detect the DNS information, this requires all nodes on the 
-  link must belong to same solicited node multicast address. In general,
-  this may not be the case. So the node that is going for DAD must use
-  all nodes multicast address for DAD packets, so that the 6DNAC Server
-  (H4) can observe the DAD packets, detects IPv6 address and 
-  corresponding domain name, checks if this domain name is duplicate 
-  and finally registers the domain name with the DNS Server.
- 
-  
-                          6DNAC Server
-      +---+                   +---+                     +----------+
-      | H1|                   | H4|<--- DDNS UPDATE --->|DNS Server|
-      +-+-+                   +-+-+                     +----+-----+
-        |                       |           +----+       +---/
-        |                       |           |    |      /
-     ---+-----+-----------+-----+-----------+ R1 +-----+
-              |           |                 |    |
-              |           |                 +----+
-            +-+-+       +-+-+
-            | H2|       | H3|
-            +---+       +---+
-  
-  
-  H1, H2, H3 - 6DNAC Clients
-  H4         - 6DNAC Server
-  R1         - Router
-  
-  
-                  
-  
-  
-  Figure 7 shows the 6DNAC Server implemented on a router R1. In this
-  case a single 6DNAC server can serve multiple links for automatic
-  configuration of the domain name. This topology also has flexibility
-  of using DAD packets with Router Alert option instead of sending DAD
-  packets to all nodes multicast address. The routers are required to
-  process all the packets with Router Alert option as per [2711].
-
-  In case of Home Networks, R1 is will acts as a Home Gateway (CPE)
-  connected to ISP. R1 delegates the prefix from the ISP edge router.
-  After delegating the prefix the CPE can advertise the DNS Zone suffix
-  along with the prefix information to the nodes on the links to which
-  the router is connected to. Note that the R1 must be configured with
-  the DNS Zone suffix Information manually. 
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 11]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-                         +---+       +---+ 
-                         | H3+       | H4|
-                         +-+-+       +-+-+
-                           |           |
-                           |   LINK2   |
-      +---+             ---+--------+--+--          +----------+
-      | H1|                         |               |DNS Server|
-      +-+-+                         |               +----+-----+
-        |                        +--+-+           -------/
-        |         LINK 1         |    |          /
-     ---+-----+------------------+ R1 +---------+
-              |                  |    |      DDNS UPDATE
-              |                  +----+
-            +-+-+             6DNAC Server
-            | H2|
-            +---+
-  
-  
-  H1, H2 - 6DNAC Clients on Link1
-  H3, H4 - 6DNAC Clients on Link2
-  R1     - Router with 6DNAC Server, serving both Link1 and Link2
-  
-  
-       
-  
-  
-  7.2. 6DNAC Operational Scenarios
-  
-  This section provides message sequence charts for various 6DNAC
-  operational scenarios assuming that the 6DNAC Server is implemented
-  on a router. All the scenarios assume that the normal boot up time
-  stateless address autoconfiguration of Link Local address derived
-  from the Interface Identifier has been completed successfully. And
-  it is also assumed that the router is already configured with the
-  DNS Zone Suffix Information.
-
-  
-  Legend:
-  
-  6DNAC-A, B, C  : 6DNAC Clients
-  6DNAC-S        : 6DNAC Server/Router
-  DAD            : Duplicate Address Detection
-  DFQDND         : Duplicate Domain Name Detection
-  DNS-S          : DNS Server
-  
-  
-  7.2.1. Domain Name Registration-Successful Case 
-
-  This scenario starts when a 6DNAC Client receives RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and wants configure its IPv6 address (Global
-  or Site Local) and domain name. It is Assumed that the 
-  DupAddrDetectTransmits is set to 1.
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 12]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-   +---------+      +---------+      +---------+
-   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+
-        |                |                |
-        |     RA with    |                |
-        | DNS Suffix Opt |                |
-        |<---------------|                |
-        |       #1       |                |
-        |---+            |                |
-  Construct |#2          |                |
-    FQDN    |            |                |
-        |<--+            |                |
-DAD/DFQDND Starts        |                |
-        |                |                |
-        |                |                |
-        |    NS With     |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |       #3       |                |
-        |                |                |
-        |                |------+         |
-        |          Create FQDN  | #4      |
-        |               |         |
-        |                |<-----+         |
-        |                |                |
-        |                |  Register FQDN |
-        |                |--------------->|
-        |                |       #5       |
-        |   #6           |                |
-        |--------+       |                |
-   No Response   |       |                |
-  DFQDND-Success |       |                |
-        |<-------+       |                |
-        |                |                |
-        |                |                |
-        v                V                v  
-
-
-          
-           
-  
-  #1. 6DNAC Server (Router) sends out router advertisement with DNS
-      Suffix information along with other parameters as specified in
-      NDP [2461].
-  
-  #2. 6DNAC Client processes the router advertisement and constructs
-      the FQDN by prefixing hostname to the DNS Zone Suffix. It also
-      constructs IPv6 address from the autoconfiguration prefix
-      information option.
-
-  #3. 6DNAC Client starts duplicate address & FQDN detection for the
-      IPv6 address & FQDN constructed and sends out a Neighbor
-      Solicitation message with FQDN option. 
-
-      Note that the DAD packets must be addressed to all nodes multicast
-      address if Router Alert option is not used. 
-      
-Park & Madanapalli             Expires October 2003            [Page 13]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
-
-  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
-      6DNAC Client as part of duplicate FQDN detection procedure and
-      creates a FQDN entry in its FQDN Cache (assuming that there is no
-      entry ), where C is Link Layer Address of the 6DNAC Client.
-
-  #5.  6DNAC Server then registers FQDN and corresponding IPv6 address
-       through the existing protocol DDNS UPDATE.
-
-  #6.  6DNAC Client times out and observes that there is no response to
-       defend its duplicate FQDN detection procedure and the node is
-       successful in configuring its domain name.
-  
-  Note that, Stateless Address Autoconfiguration DAD procedure is not
-  depicted in the following message sequence chart, which simultaneously
-  happens along with duplicate FQDN detection.
-  
-
-  7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 
-
-  This scenario starts when a 6DNAC Client receives RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and wants configure its IPv6 address (Global
-  or Site Local) and domain name. The node is configured with 
-  DupAddrDetectTransmits = 2 for reliability in delivering DAD messages.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 14]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
-
-   +---------+      +---------+      +---------+
-   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+
-        |                |                |
-        |     RA with    |                |
-        | DNS Suffix Opt |                |
-        |<---------------|                |
-        |       #1       |                |
-        |---+            |                |
-  Construct |#2          |                |
-    FQDN    |            |                |
-        |<--+            |                |
-DAD/DFQDND Starts        |                |
-        |                |                |
-        |                |                |
-        |    NS With     |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |       #3       |                |
-        |                |                |
-        |                |------+         |
-        |          Create FQDN  | #4      |
-        |               |         |
-        |                |<-----+         |
-        |                |                |
-        |                |  Register FQDN |
-        |                |--------------->|
-        |                |       #5       |
-        |    NS With     |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |      #6        |                |
-        |                |                |
-        |          Lookup FQDN            |
-        |          Entry exists           |
-        |                |------+         |
-        |             Ignore    | #7      |
-        |                |<-----+         |
-        |   #8           |                |
-        |--------+       |                |
-   No Response   |       |                |
-  DFQDND-Success |       |                |
-        |<-------+       |                |
-        |                |                |
-        |                |                |
-        v                V                v  
-
-  
-  
-            
-
-
-  Steps from #1 to #5 are same as that of scenario.7.2.1.
-  
-  #6. 6DNAC Client sends out second Neighbor Solicitation message with
-      FQDN option as part of duplicate FQDN detection.
-      
-Park & Madanapalli             Expires October 2003            [Page 15]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
-
-  #7. 6DNAC Server receives and observes that the FQDN Cache exactly
-      matches with that of the NS information and ignores the NS message.
-
-  #8. 6DNAC Client times out and observes that there is no response to
-      defend its duplicate FQDN detection procedure and the node is
-      successful in configuring its domain name..
-
-  
-  7.2.3. Domain Name Registration-Defend Case 
-
-  This scenario starts when two 6DNAC Client receive RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and both the nodes want configure their IPv6
-  address (Global or Site Local) and domain name. In this scenario both
-  the nodes want to have same domain name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 16]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-
-   +---------+      +---------+      +---------+      +---------+
-   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+      +----+----+
-        |                |                |                |
-        |     RA with    |     RA with    |                |
-        | DNS Suffix Opt | DNS Suffix Opt |                |
-        |<---------------|--------------->|                |
-        |       #1       |       #1       |                |
-        |---+            |                |---+            |
-  Construct | #2         |          Construct | #2         |
-      FQDN  |            |              FQDN  |            |
-        |<--+            |                |<--+            |
- DAD/DFQDND Starts       |         DAD/DFQDND Starts       |
-        |                |                        |
-        |                |                |                |
-        |    NS with     |                |                |
-        |    FQDN Opt    |                |                |
-        |--------------->|                |                |
-        |      #3        |                |                |
-        |            No Entry             |                |
-        |                |------+         |                |
-        |          Create FQDN  | #4      |                |
-        |               |         |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |                |         Register FQDN #5        |
-        |                |-------------------------------->|
-        |                |                |                |
-        |                |    NS with     |                |
-        |                |    FQDN Opt    |                |
-        |                |<---------------|                |
-        |                |       #6       |                |
-        |                |------+         |                |
-        |         FQDN is in use|         |                |
-        |          Defend DFQDND| #7      |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |                |    NA with     |                |
-        |                |    D-flag Set  |                |
-        |                |--------------->|                |
-        |                |       #8       |                |
-        |------+         |                |---+            |
- No Response   | #9      |            Enter   | #10        |
- DFQDND Success|         |          Retry Mode|            |
-        |<-----+         |                |<--+            |
-        |                |                |                |
-        v                v                v                v
-
-         
-       
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 17]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
-
-  #1. 6DNAC Server (Router) sends out router advertisement with DNS
-      Suffix information.
-      
-  #2. 6DNAC Clients A&B process the router advertisement and construct
-      their FQDN by prefixing hostname to the DNS Zone Suffix.  They
-      also construct IPv6 address from the autoconfiguration prefix
-      information option.
-      
-      When each host is trying to go for DAD, all hosts must have
-      random delay to avoid the traffic congestion according to [2461].
-      So here it is assumed that 6DNAC Client-A starts DAD first and
-      6DNAC Client-B starts DAD later.
-
-  #3. 6DNAC Client-A starts duplicate address & FQDN detection for the
-      IPv6 address & FQDN constructed and sends out a Neighbor
-      Solicitation message with FQDN option.
-   
-  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
-      6DNAC Client-A as part of duplicate FQDN detection procedure and
-      creates a FQDN entry in its FQDN Cache (assuming that there is no
-      entry ), where A is Link Layer Address of the 6DNAC Client-A.
-
-  #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
-      through the existing protocol DDNS UPDATE.
-
-  #6. 6DNAC Client-B starts duplicate address & FQDN detection for the
-      IPv6 address & FQDN constructed and sends out a Neighbor Solicitation
-      message with FQDN option. 
-
-  #7. 6DNAC Server processes the Neighbor Solicitation message sent by
-      6DNAC Client-B as part of duplicate FQDN detection procedure and 
-      finds that the domain name is already in use by the 6DNAC Client-A.
-      Hence, concludes to defend the duplicate FQDN detection of 6DNAC
-      Client-B.
-
-  #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN
-      option to 6DNAC Client-B to defend its duplicate FQDN detection.
-
-  #9. 6DNAC Client-A times out and observes that there is no response to
-      defend its duplicate FQDN detection procedure and the node is 
-      successful in configuring its domain name.
-
-  #10. 6DNAC Client-B observes that there is a NA with FQDN option
-       indicating that the domain name is duplicate and enters Retry
-       Mode. In retry mode, 6DNAC Client constructs another FQDN based
-       on Host Naming Algorithm. The number of retries is defined by the
-       administrator and must be a configurable value.
-  
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 18]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  7.2.4. Domain Name Registration in Retry Mode
-
-  Pre-Conditions:
-
-  1. Duplicate Address Detection has succeeded 
-  2. Duplicate FQDN Detection FAILED
-  3. FQDN is the first FQDN one constructed and FAILED
-  4. FQDN2 is the second FQDN to be constructed
-  5. The Neighbor Solicitation in the 'Retry Mode'
-    carries unspecified address in its target field (NS*).
-
-   +---------+      +---------+      +---------+
-   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+
-        |                |                |
-        |--------+       |                |
-    Construct    | #1    |                |
-    new FQDN2    |       |                |
-        |<-------+       |                |
-        |                |                |
-  DFQDND Restarts        |                |
-        |                |                |
-        |                |                |
-        |    NS* With    |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |       #2       |                |
-        |                |                |
-        |            No Entry             |
-        |                |------+         |
-        |          Create FQDN  | #3      |
-        |              |         |
-        |                |<-----+         |
-        |                |                |
-        |                | Register FQDN2 |
-        |                |--------------->|
-        |                |       #4       |
-        |                |                |
-        |--------+       |                |
-   No Response   | #5    |                |
-  DFQDND-Success |       |                |
-        |<-------+       |                |
-        |                |                |
-        v                V                v
-
-                
-                
-                
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 19]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
- 
-  #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm,
-      the DNS Zone Suffix, and it is FQDN2.
-  #2. It then starts Duplicate Detection only for Domain Name. 6DNAC
-      Client sends out NS with FQDN option and unspecified target
-      address.
-
-  #3. 6DNAC Server processes the Retry Mode NS message and finds that
-      the FQDN2 is not in use and creates Cache entry as .
-
-  #4. It then starts registration procedures with the DNS Server.
-
-  #5. Meanwhile, 6DNAC Client timesout and observes that there is no
-      defending NA for its DFQDND NS sent out and successfully
-      configures its domain name.
-
-
-  7.2.5. Domain Name Registration when DAD Fails
-
-  Duplicate domain name detection and subsequent registration starts 
-  if and only if the DAD for IPv6 address succeeds. If the DAD for
-  IPv6 address fails then no actions are taken for domain name. When
-  DAD fails for stateless address autoconfiguration, then the domain
-  configuration starts only when the address has been configured using 
-  Stateful Address Configuration methods and the node is going on DAD
-  for this address.
-
-  This scenario starts when a 6DNAC Client receives RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and wants configure its IPv6 address (Global
-  or Site Local) and domain name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 20]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-   +---------+      +---------+      +---------+      +---------+
-   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+      +----+----+
-        |                |                |                |
-        |                |                |                |
-        |     RA with    |                |                |
-        | DNS Suffix Opt |                |                |
-        |<---------------|                |                |
-        |       #1       |                |                |
-        |-----+          |                |                |
-    Construct |          |                |                |
-      FQDN&   | #2       |                |                |
-    IPv6 Addr |          |                |                |
-        |<----+          |                |                |
- DAD/DFQDND Starts       |                |                |
-        |                |                |                |
-        |                |                |                |
-        |    NS with     |                |                |
-        |    FQDN Opt    |                |                |
-        |--------------->+--------------->|                |
-        |       #3       |        #3      |                |
-        |            No Entry             |                |
-        |                |------+         |                |
-        |          Create FQDN  |         |                |
-        |               | #4      |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |                |                |------+         |
-        |                |           My IPv6 Addr| #5      |
-        |                |                |<-----+         |
-        |                |   Defend DAD   |                |
-        |                |    with NA     |                |
-        |<---------------+<---------------|                |
-        |      #6        |       #6       |                |
-        |              Entry              |                |
-        |                |------+         |                |
-        |          Delete FQDN  | #7      |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |----+           |                |                |
-  DAD Failed | #8        |                |                |
- Stop DFQDND |           |                |                |
-        |<---+           |                |                |
-        |                |                |                |
-        v                v                v                v
-
-                     
-
-  #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A.
-
-  #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and
-      FQDN as per Host Naming Algorithm. 
-
-  #3. It then starts Duplicate address & FQDN Detection, for the newly 
-      constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS
-      with FQDN option.  
-
-Park & Madanapalli             Expires October 2003            [Page 21]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
-
-  #4. 6DNAC Server processes the DAD/DFQDND NS message and finds 
-      that there is no entry for the FQDN in its cache. And,
-      creates Cache entry as  and starts a Registration
-      timer with RegistrationWaitTime seconds.
-
-  #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is 
-      in its unicast address list.  
-
-  #6. It then starts defending DAD by sending NA to all-nodes multicast.
-
-  #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A.  
-      And, deletes its FQDN Cache entry .
-      
-  #8. 6DNAC Client gets defending DAD-NA and desists from DAD. 
-      And also, stops Duplicate FQDN Detection as well.
-      At this point the address must be configured using stateful 
-      methods and the domain name registration starts with the DAD
-      for the newly constructed IPv6 address.
-  
-  7.3. DNS Zone Suffix Discovery and FQDN Construction
-  
-  7.3.1. Sending Router Advertisement Messages
-
-  Routers send out Router Advertisement message periodically, 
-  or in response to a Router Solicitation. Router should include 
-  the DNS Zone Suffix Option in their advertisements. If the DNS
-  Zone Suffix changes (similar to Site Renumbering), then it should
-  advertise the Old Zone Suffix with zero Valid Lifetime and New
-  Zone Suffix with proper non-zero Valid Lifetime.  In any other
-  case, a router should not send this option twice in a single
-  router advertisement.
-
-  7.3.2. Processing Router Advertisement Messages  
-
-  For each DNS Zone Suffix Option in Router Advertisement,
-
-  a. 6DNAC node stores the Zone Suffix information in its local
-     database.  Also, constructs FQDN as per Host Naming Algorithm.
-
-  b. If the node has not configured FQDN yet,
-
-     1. If the node is going to perform DAD for either Site local or 
-        Global Address, then it should include FQDN option to perform
-        Duplicate FQDN Detection in parallel with DAD.
-
-     2. If the node has already got either Site local or Global 
-        address, then it should send out NS with FQDN option and 
-        unspecified target address to perform Duplicate FQDN 
-        Detection.
-
-  c. If the node has already configured FQDN, and if the 
-     advertisement carries two DNS Zone Suffix Options,
-     First DNS Zone Suffix should match with the configured FQDN 
-     Suffix and its Valid Lifetime must be zero. Second DNS Zone
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 22]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-     Suffix should have non-zero Valid Lifetime. In this case, the
-     node constructs new FQDN based on the new DNS Zone Suffix (from
-     second DNS Zone Suffix option), and perform Duplicate FQDN 
-     Detection with unspecified target address.  Also, it should
-     overwrite the old FQDN with the newly constructed FQDN.
-     
-
-  7.3.3. FQDN Lifetime expiry
-
-  6DNAC Server:  
-  It should delete the FQDN cache entry and should de-register from
-  the DNS Server.
-
-  6DNAC Client:
-  It should send update to 6DNAC Server by restarting the Duplicate 
-  FQDN Detection. 
-  
-  7.3.4. Host Naming Algorithm
- 
-  A node constructs FQDN by combining DNS Zone Suffix and the hostname
-  as depicted in the following diagram.
-
-     +------------------+----------------------------------+
-     |     Host Name    |          Advertised Suffix       |
-     +------------------+----------------------------------+
-
-          

-
-  A node can choose Host Name using any of the following methods:
- 
-  a. String form of random number generated from the Interface 
-     Identifier.
-     
-  b. List of configured Host Names provided by the administrator.
-
-  
-  The number of retries must be specified in this algorithm in 
-  case of domain name duplication.
-  
-    
-  7.4. Duplicate Domain Name Detection
-  
-  The procedure for detecting duplicated FQDNs uses Neighbor
-  Solicitation and Advertisement messages as described below.
-
-  If a duplicate FQDN is detected during the procedure, the
-  FQDN cannot be assigned to the node.
-
-  An FQDN on which the DFQDND Procedure is applied is said 
-  to be tentative until the procedure has completed successfully.  
-  A tentative FQDN is not considered "assigned to the node" in the 
-  traditional sense.  That is, the node must accept Neighbor 
-  Advertisement message containing the tentative FQDN in the FQDN 
-  Option.
-
-
-Park & Madanapalli             Expires October 2003            [Page 23]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  It should also be noted that DFQDN must be performed prior to 
-  registering with DNS Server to prevent multiple nodes from using 
-  the same FQDN simultaneously. All the Duplicate Address Detection 
-  Neighbor Solicitation messages must carry Source Link Layer Address 
-  Option as specified in NDP [2461]. 
-
-  The detection of duplicate FQDN can be achieved through one of the
-  following three types of procedures.
-  
-  1. DAD with All Nodes Multicast Address
-  2. DAD with Router Alert Option for 6DNAC.
-  3. Explicit Detection of Duplicate Domain Name
-   
-  Even though three solutions are listed, authors prefer only one 
-  procedure to be followed in future based on further analysis and
-  comments received from others. 
-  
-  7.4.1. DAD with All Nodes Multicast Address
-  
-  7.4.1.1. Sending Neighbor Solicitation Messages
-
-  6DNAC Client sends Neighbor Solicitation Messages as part
-  of Duplicate Address Detection SLAAC [2462] with the following 
-  extra information and modifications:
-
-  a. Include FQDN Option in the DAD Neighbor Solicitation Message
-  b. Destination Address is set to All Nodes Multicast Address
-
-  There may be a case where DAD has succeeded but DFQDND is in Retry 
-  Mode. In such case, the Neighbor Solicitation must carry unspecified 
-  address in the ICMP target address field and new domain name in FQDN
-  option to re-try the registration of the domain name.
-
-  7.4.1.2. Processing Neighbor Solicitation Messages
-
-  6DNAC Clients must ignore the FQDN option found in any of the
-  neighbor solicitation messages.
-
-  6DNAC Server processes FQDN Option found in the Duplicate Address 
-  Detection Neighbor Solicitation Messages as described below:
-
-  Lookup FQDN Cache for the domain name in FQDN Option.
-
-  If the entry exists and 
-   i. Link Layer Address matches with SLLA option, this is the case, 
-      where node has changed its IPv6 address or updating the valid 
-      life time. 6DNAC Server updates its cache and also updates DNS
-      Server using DDNS-UPDATE. If there is no change in IPv6 address
-      or life time then no updates are sent to the DNS server. 
-
-  ii. Link Layer Address differs with SLLA option, defend the duplicate 
-      FQDN Detection by sending Neighbor Advertisement Message as 
-      described in $7.4.1.3$.
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 24]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  else,
-    Lookup FQDN Cache for the Link Layer Address in SLLA Option.
-
-    If the entry exists, update the FQDN Cache and update DNS Server 
-    using DDNS-UPDATE. This is the case, where node has changed its
-    domain name (similar to Site Re-numbering).
-
-    If then entry does not exists, then it means that this is the new 
-    registration. It must create a cache entry and start Registration    
-    
-    timer with RegistrationWaitTime. At the expiry of the Registration
-    timer, it should update DNS Server with DDNS-UPDATE.
-
-  7.4.1.3. Sending Neighbor Advertisement Messages
-
-  6DNAC Server sends Neighbor Advertisement Messages as part
-  of Duplicate Address Detection SLAAC [2462] with the FQDN Option 
-  in Neighbor Advertisement message to defend duplicate FQDN 
-  detection.
-
-  There may be the case where defending of duplicate address detection 
-  is not required but defending of FQDN is required.  In such instance, 
-  the defending Neighbor Advertisement must carry FQDN and unspecified
-  address in the ICMP target address field.
-
-  7.4.1.4. Processing Neighbor Advertisement Messages
-
-  6DNAC Server must ignore the any FQDN option found any of 
-  the neighbor advertisement messages.  If the Neighbor Advertisement
-  is a DAD defending, then it must delete its FQDN Cache entry created 
-  on the reception of DAD Neighbor Solicitation message.
-
-  When 6DNAC Clients gets the duplicate address detection neighbor
-  advertisement messages with FQDN option set it means that its
-  duplicate FQDN detection failed and enters Retry Mode.
-
-  7.4.1.5. Pros and Cons
-  
-  The advantage of this procedure is that it does not need any 
-  extension header options to be included. The disadvantage of this 
-  procedure is that, it needs change in the existing DAD procedure.
-  The change is only that the DAD neighbor solicitations are to be 
-  addressed to all nodes multicast address instead of solicited 
-  node multicast address. The another disadvantage is that, it needs 
-  the existence of Duplicate Address Detection Procedure to 
-  perform duplicate FQDN detection. 
-  
-  7.4.2. DAD with Router Alert Option for 6DNAC
-
-  7.4.2.1. Sending Neighbor Solicitation Messages
-
-  6DNAC Client sends Neighbor Solicitation Messages as part
-  of Duplicate Address Detection SLAAC [2462] with the following 
-  extra information:
-
-
-Park & Madanapalli             Expires October 2003            [Page 25]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  a. Include Hop-by-Hop extension Header with Router Alert Option
-     for 6DNAC as described in IPv6 Router Alert Option[2711].
-
-  b. Include FQDN Option in the DAD Neighbor Solicitation Message
-
-  7.4.2.2. Processing Neighbor Solicitation Messages
-
-  This is same as described in $7.4.1.2$. 
-
-  7.4.2.3. Sending Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.3$. 
-
-  7.4.2.4. Processing Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.4$.
-
-  7.4.2.5. Pros and Cons
-
-  The advantage of this procedure is that it does not disturb
-  the existing implementation and their way of processing the 
-  packets.  The disadvantage is that, it needs the existence 
-  of Duplicate Address Detection Procedure to perform duplicate 
-  FQDN detection. Another disadvantage is that this procedure 
-  requires 6DNAC Server functionality to be implemented on Router.
-  However, in this case 6DNAC Server can serve multiple links.
-  
-  7.4.3. Explicit Detection of Duplicate Domain Name
-
-  In this procedure Duplicate FQDN Detection starts after completion
-  of successful Site local or Global Address configuration.
-  
-  7.4.3.1. Sending Neighbor Solicitation Messages
-
-  6DNAC Client sends Neighbor Solicitation Messages as part
-  of Duplicate FQDN Detection with the following information:
-
-  a. Include FQDN Option in the Neighbor Solicitation Message
-
-  b. Destination Address is set to All Nodes Multicast Address
-     or uses Router Alert Option for 6DNAC, when 6DNAC Server is 
-     implemented on router.
-
-  c. Target Address is set to Unspecified Address
-
-  d. Other fields are set as per DAD SLAAC [2462].
-
-  7.4.3.2. Processing Neighbor Solicitation Messages
-
-  This is same as described in $7.4.1.2$.
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 26]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
-
-
-  7.4.3.3. Sending Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.3$.
-
-  7.4.3.4. Processing Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.4$.
-
-  7.4.3.5. Pros and Cons
-
-  The advantage of this procedure is that it does not need the
-  existing duplicate address detection procedure.  This is introduced
-  as the DAD procedure is found to be redundant in when IPv6 addresses
-  are constructed from the interface ID [DIID].
-
-  Note that, if 6DNAC Clients know the address of 6DNAC Server then
-  they can directly send DFQDND-NS to 6DNAC Server. 
-
-  7.4.4. Retry Mode for Re-registering Domain Name
-
-  In retry mode, nodes construct new FQDN as per Host Naming Algorithm.
-  Then they restart Duplicate FQDN Detection as described in $7.4.3$.
-
-
-  7.5. Domain Name Registration
-  
-  6DNAC Server must be an authenticated to update the DNS Server.
-  6DNAC Server must also be configured with the DNS Server 
-  information.
-
-  6DNAC Server detects the DNS information (IPv6 Address and 
-  corresponding FQDN) from DAD/DFQDND messages and caches the
-  information. It also have an associated Registration Timer with 
-  RegistrationWaitTime to wait for the successful completion of 
-  DFQDND and update DNS Server using existing protocol DDNS UPDATE 
-  [2136].
-  
-                 
-  8. Security Consideration
-   
-  If someone wants to hijack correct Domain Name registration, they 
-  could send a NS message with incorrect or same Domain Name to the
-  6DNAC server repeatedly and server would start the Domain Name 
-  registration through above mechanism, which is a security hole. 
-  As described in [2461], a host can check validity of NDP messages.
-  If the NDP message include an IP Authentication Header, the message
-  authenticates correctly. For DNS UPDATE processing, secure DNS
-  Dynamic Update is described in [3007].
-  
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 27]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-  
-  9. IANA Consideration
-  
-  Values in the Router Alert Option are registered and maintained by
-  IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is
-  required to assign the Type values for DNS Zone Suffix Information
-  option and FADN option.
-
-  
-  10. Acknowledgement
-  
-  Special thanks are due to Badrinarayana N.S. and Christian Huitema for
-  many helpful suggestions and revisions. 
-  
-  
-  11. Intellectual Property
-
-  The following notice is copied from RFC 2026 [Bradner, 1996],
-  Section 10.4, and describes the position of the IETF concerning
-  intellectual property claims made against this document.
-
-  The IETF takes no position regarding the validity or scope of any
-  intellectual property or other rights that might be claimed to
-  pertain to the implementation or use other technology described in
-
-  this document or the extent to which any license under such rights
-  might or might not be available; neither does it represent that it
-  
-  has made any effort to identify any such rights.  Information on the
-  IETF's procedures with respect to rights in standards-track and
-  standards-related documentation can be found in BCP-11.  Copies of
-  claims of rights made available for publication and any assurances
-  of licenses to be made available, or the result of an attempt made
-  to obtain a general license or permission for the use of such
-  proprietary rights by implementers or users of this specification
-  can be obtained from the IETF Secretariat.
-
-  The IETF invites any interested party to bring to its attention any
-  copyrights, patents or patent applications, or other proprietary
-  rights which may cover technology that may be required to practice
-  this standard.  Please address the information to the IETF Executive
-  Director.
-  
-  
-  12. Copyright
-
-  The following copyright notice is copied from RFC 2026 [Bradner,
-  1996], Section 10.4, and describes the applicable copyright for this
-  document.
-
-  Copyright (C) The Internet Society July 12, 2001. All Rights
-  Reserved.
-  
-  This document and translations of it may be copied and furnished to
-  others, and derivative works that comment on or otherwise explain it
-  or assist in its implementation may be prepared, copied, published
-
-Park & Madanapalli             Expires October 2003            [Page 28]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  and distributed, in whole or in part, without restriction of any
-  kind, provided that the above copyright notice and this paragraph
-  are included on all such copies and derivative works.  However, this
-  
-  document itself may not be modified in any way, such as by removing
-  the copyright notice or references to the Internet Society or other
-  Internet organizations, except as needed for the purpose of
-  developing Internet standards in which case the procedures for
-  copyrights defined in the Internet Standards process must be
-  followed, or as required to translate it into languages other than
-  English.
-
-  The limited permissions granted above are perpetual and will not be
-  revoked by the Internet Society or its successors or assignees.
-
-  This document and the information contained herein is provided on an
-  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-  
-  
-  13. References
-   
-  [2373]        Hinden, R. and S. Deering, "IP Version 6 Addressing 
-                Architecture", RFC 2373, July 1998. 
-       
-  [2460]        Deering, S. abd R. Hinden, "Internet Protocol, 
-                Version 6 (IPv6) Specification", RFC 2460, 
-                December 1998. 
-               
-  [2461]        Narten, T., Nordmark, E. and W. Simpson, "Neighbor 
-                Discovery for IP version 6(IPv6)", RFC 2461, December 
-                1998. 
-
-  [2462]        S. Thomson and Narten T, "IPv6 Stateless Address Auto- 
-                Configuration", RFC 2462, December 1998. 
-               
-  [2711]        C. Patridge and A.Jackson, "IPv6 Router Alert Option",
-                RFC 2711, October 1999. 
-             
-  [1034]        P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND 
-                FACILITIES", RFC 1034, November 1987. 
-               
-  [1035]        P. Mockapetris, "Domain Names - Implementation and 
-                Specification" RFC 1035, November 1987. 
-
-  [2136]        P. Vixie et al., "Dynamic Updates in the Domain Name
-                System (DNS UPDATE)", RFC2136, April 1997.
-                
-  [3007]        B. Wellington, "Secure Domain Name System (DNS) Dynamic 
-                Update", RFC 3007, November 2000.
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 29]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-                 
-  [DIID]        yokohama-dad-vs-diid.pdf
-                at http://playground.sun.com/ipng/presentations/July2002/
-                
-  [DNSISSUES]   Durand, A., "IPv6 DNS transition issues", draft-ietf-              
-                dnsop-ipv6-dns-issues-00.txt, work in progress.
-                
-  [PREFIX]      S. Miyakawa, R. Droms, "Requirements for IPv6 prefix
-                delegation", draft-ietf-ipv6-prefix-delegation-
-                requirement-01.txt, work in progress.
-   
-  [Autoreg]     H. Kitamura, "Domain Name Auto-Registration for 
-                Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name-
-                auto-reg-00.txt, work in progress.
-
-  [NIQ]         Matt Crawford, "IPv6 Node Information Queries", , work in progress.
-                  
-  
-  14. Author's Addresses 
-  
-  Soohong Daniel Park 
-  Mobile Platform Laboratory, SAMSUNG Electronics, KOREA 
-  Phone: +82-31-200-3728 
-  Email:soohong.park@samsung.com
-  
-  Syam Madanapalli
-  Network Systems Division, SAMSUNG India Software Operations, INDIA
-  Phone: +91-80-5550555
-  Email:syam@samsung.com
-  
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 30]
diff --git a/doc/misc/Makefile.in b/doc/misc/Makefile.in
index c5df0cbd8b2f..b68b94ce6e6d 100644
--- a/doc/misc/Makefile.in
+++ b/doc/misc/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.3.18.4 2007/12/02 22:36:01 marka Exp $
+# $Id: Makefile.in,v 1.3.18.6 2009/07/11 23:46:06 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -38,11 +38,13 @@ docclean manclean maintainer-clean::
 CFG_TEST = ../../bin/tests/cfg_test
 
 options: FORCE
-	if test -x ${CFG_TEST} && \
-	   ${CFG_TEST} --named --grammar | \
-	   ${PERL} ${srcdir}/sort-options.pl | \
-	   ${PERL} ${srcdir}/format-options.pl >$@.new ; then \
+	if test -x ${CFG_TEST} ; \
+	then \
+		${CFG_TEST} --named --grammar > $@.raw ; \
+		${PERL} ${srcdir}/sort-options.pl < $@.raw > $@.sorted ; \
+		${PERL} ${srcdir}/format-options.pl < $@.sorted > $@.new ; \
 		mv -f $@.new $@ ; \
+		rm -f $@.raw $@.sorted ; \
 	else \
-		rm -f $@.new ; \
+		rm -f $@.new $@.raw $@.sorted ; \
 	fi
diff --git a/doc/rfc/index b/doc/rfc/index
index fea5f7181928..5d48ee4e6eef 100644
--- a/doc/rfc/index
+++ b/doc/rfc/index
@@ -20,6 +20,7 @@
 1750:	Randomness Recommendations for Security
 1876:	A Means for Expressing Location Information in the Domain Name System
 1886:	DNS Extensions to support IP version 6
+1912:	Common DNS Operational and Configuration Errors
 1982:	Serial Number Arithmetic
 1995:	Incremental Zone Transfer in DNS
 1996:	A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
@@ -91,6 +92,7 @@
 	 Secret Key Transaction Authentication for DNS (GSS-TSIG)
 3655:	Redefinition of DNS Authenticated Data (AD) bit
 3658:	Delegation Signer (DS) Resource Record (RR)
+3755:	Legacy Resolver Compatibility for Delegation Signer (DS)
 3757:	Domain Name System KEY (DNSKEY) Resource Record (RR)
 	 Secure Entry Point (SEP) Flag
 3833:	Threat Analysis of the Domain Name System (DNS)
@@ -104,6 +106,8 @@
 4159:	Deprecation of "ip6.int"
 4193:	Unique Local IPv6 Unicast Addresses
 4255:	Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
+4294:	IPv6 Node Requirements
+4339:	IPv6 Host Configuration of DNS Server Information Approaches
 4343:	Domain Name System (DNS) Case Insensitivity Clarification
 4367:	What's in a Name: False Assumptions about DNS Names
 4398:	Storing Certificates in the Domain Name System (DNS)
@@ -111,9 +115,26 @@
 4408:	Sender Policy Framework (SPF) for Authorizing Use of Domains
 	 in E-Mail, Version 1
 4470:	Minimally Covering NSEC Records and DNSSEC On-line Signing
+4471:	Derivation of DNS Name Predecessor and Successor
+4472:	Operational Considerations and Issues with IPv6 DNS
+4509:	Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
 4634:	US Secure Hash Algorithms (SHA and HMAC-SHA)
+4635:	HMAC SHA TSIG Algorithm Identifiers
 4641:	DNSSEC Operational Practices
 4648:	The Base16, Base32, and Base64 Data Encodings
+4697:	Observed DNS Resolution Misbehavior
 4701:	A DNS Resource Record (RR) for Encoding
          Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
+4892:	Requirements for a Mechanism Identifying a Name Server Instance
+4955:	DNS Security (DNSSEC) Experiments
+4956:	DNS Security (DNSSEC) Opt-In
+5001:	DNS Name Server Identifier (NSID) Option
+5011:	Automated Updates of DNS Security (DNSSEC) Trust Anchors
 5155:	DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
+5205:	Host Identity Protocol (HIP) Domain Name System (DNS) Extension
+5395:	Domain Name System (DNS) IANA Considerations
+5452:	Measures for Making DNS More Resilient against Forged Answers
+5507:	Design Choices When Expanding the DNS
+5625:	DNS Proxy Implementation Guidelines
+5702:   Use of SHA-2 Algorithms with RSA in
+         DNSKEY and RRSIG Resource Records for DNSSEC
diff --git a/doc/rfc/rfc1912.txt b/doc/rfc/rfc1912.txt
new file mode 100644
index 000000000000..8ace7d267481
--- /dev/null
+++ b/doc/rfc/rfc1912.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                            D. Barr
+Request for Comments: 1912             The Pennsylvania State University
+Obsoletes: 1537                                            February 1996
+Category: Informational
+
+
+            Common DNS Operational and Configuration Errors
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This memo describes errors often found in both the operation of
+   Domain Name System (DNS) servers, and in the data that these DNS
+   servers contain.  This memo tries to summarize current Internet
+   requirements as well as common practice in the operation and
+   configuration of the DNS.  This memo also tries to summarize or
+   expand upon issues raised in [RFC 1537].
+
+1. Introduction
+
+   Running a nameserver is not a trivial task.  There are many things
+   that can go wrong, and many decisions have to be made about what data
+   to put in the DNS and how to set up servers.  This memo attempts to
+   address many of the common mistakes and pitfalls that are made in DNS
+   data as well as in the operation of nameservers.  Discussions are
+   also made regarding some other relevant issues such as server or
+   resolver bugs, and a few political issues with respect to the
+   operation of DNS on the Internet.
+
+2. DNS Data
+
+   This section discusses problems people typically have with the DNS
+   data in their nameserver, as found in the zone data files that the
+   nameserver loads into memory.
+
+2.1 Inconsistent, Missing, or Bad Data
+
+   Every Internet-reachable host should have a name.  The consequences
+   of this are becoming more and more obvious.  Many services available
+   on the Internet will not talk to you if you aren't correctly
+   registered in the DNS.
+
+
+
+
+
+Barr                         Informational                      [Page 1]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   Make sure your PTR and A records match.  For every IP address, there
+   should be a matching PTR record in the in-addr.arpa domain.  If a
+   host is multi-homed, (more than one IP address) make sure that all IP
+   addresses have a corresponding PTR record (not just the first one).
+   Failure to have matching PTR and A records can cause loss of Internet
+   services similar to not being registered in the DNS at all.  Also,
+   PTR records must point back to a valid A record, not a alias defined
+   by a CNAME.  It is highly recommended that you use some software
+   which automates this checking, or generate your DNS data from a
+   database which automatically creates consistent data.
+
+   DNS domain names consist of "labels" separated by single dots.  The
+   DNS is very liberal in its rules for the allowable characters in a
+   domain name.  However, if a domain name is used to name a host, it
+   should follow rules restricting host names.  Further if a name is
+   used for mail, it must follow the naming rules for names in mail
+   addresses.
+
+   Allowable characters in a label for a host name are only ASCII
+   letters, digits, and the `-' character.  Labels may not be all
+   numbers, but may have a leading digit  (e.g., 3com.com).  Labels must
+   end and begin only with a letter or digit.  See [RFC 1035] and [RFC
+   1123].  (Labels were initially restricted in [RFC 1035] to start with
+   a letter, and some older hosts still reportedly have problems with
+   the relaxation in [RFC 1123].)  Note there are some Internet
+   hostnames which violate this rule (411.org, 1776.com).  The presence
+   of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
+   is informational only and was not defining a standard.  There is at
+   least one popular TCP/IP implementation which currently refuses to
+   talk to hosts named with underscores in them.  It must be noted that
+   the language in [1035] is such that these rules are voluntary -- they
+   are there for those who wish to minimize problems.  Note that the
+   rules for Internet host names also apply to hosts and addresses used
+   in SMTP (See RFC 821).
+
+   If a domain name is to be used for mail (not involving SMTP), it must
+   follow the rules for mail in [RFC 822], which is actually more
+   liberal than the above rules.  Labels for mail can be any ASCII
+   character except "specials", control characters, and whitespace
+   characters.  "Specials" are specific symbols used in the parsing of
+   addresses.  They are the characters "()<>@,;:\".[]".  (The "!"
+   character wasn't in [RFC 822], however it also shouldn't be used due
+   to the conflict with UUCP mail as defined in RFC 976)  However, since
+   today almost all names which are used for mail on the Internet are
+   also names used for hostnames, one rarely sees addresses using these
+   relaxed standard, but mail software should be made liberal and robust
+   enough to accept them.
+
+
+
+
+Barr                         Informational                      [Page 2]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   You should also be careful to not have addresses which are valid
+   alternate syntaxes to the inet_ntoa() library call.  For example 0xe
+   is a valid name, but if you were to type "telnet 0xe", it would try
+   to connect to IP address 0.0.0.14.  It is also rumored that there
+   exists some broken inet_ntoa() routines that treat an address like
+   x400 as an IP address.
+
+   Certain operating systems have limitations on the length of their own
+   hostname.  While not strictly of issue to the DNS, you should be
+   aware of your operating system's length limits before choosing the
+   name of a host.
+
+   Remember that many resource records (abbreviated RR) take on more
+   than one argument.  HINFO requires two arguments, as does RP.  If you
+   don't supply enough arguments, servers sometime return garbage for
+   the missing fields.  If you need to include whitespace within any
+   data, you must put the string in quotes.
+
+2.2 SOA records
+
+   In the SOA record of every zone, remember to fill in the e-mail
+   address that will get to the person who maintains the DNS at your
+   site (commonly referred to as "hostmaster").  The `@' in the e-mail
+   must be replaced by a `.' first.  Do not try to put an `@' sign in
+   this address.  If the local part of the address already contains a
+   `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by
+   preceding it with `\' character.  (e.g., to become
+   John\.Smith.widget.xx) Alternately (and preferred), you can just use
+   the generic name `hostmaster', and use a mail alias to redirect it to
+   the appropriate persons.  There exists software which uses this field
+   to automatically generate the e-mail address for the zone contact.
+   This software will break if this field is improperly formatted.  It
+   is imperative that this address get to one or more real persons,
+   because it is often used for everything from reporting bad DNS data
+   to reporting security incidents.
+
+   Even though some BIND versions allow you to use a decimal in a serial
+   number, don't.  A decimal serial number is converted to an unsigned
+   32-bit integer internally anyway.  The formula for a n.m serial
+   number is n*10^(3+int(0.9+log10(m))) + m which translates to
+   something rather unexpected.  For example it's routinely possible
+   with a decimal serial number (perhaps automatically generated by
+   SCCS) to be incremented such that it is numerically larger, but after
+   the above conversion yield a serial number which is LOWER than
+   before.  Decimal serial numbers have been officially deprecated in
+   recent BIND versions.  The recommended syntax is YYYYMMDDnn
+   (YYYY=year, MM=month, DD=day, nn=revision number.  This won't
+   overflow until the year 4294.
+
+
+
+Barr                         Informational                      [Page 3]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   Choose logical values for the timer values in the SOA record (note
+   values below must be expressed as seconds in the zone data):
+
+      Refresh: How often a secondary will poll the primary server to see
+          if the serial number for the zone has increased (so it knows
+          to request a new copy of the data for the zone).  Set this to
+          how long your secondaries can comfortably contain out-of-date
+          data.  You can keep it short (20 mins to 2 hours) if you
+          aren't worried about a small increase in bandwidth used, or
+          longer (2-12 hours) if your Internet connection is slow or is
+          started on demand.  Recent BIND versions (4.9.3) have optional
+          code to automatically notify secondaries that data has
+          changed, allowing you to set this TTL to a long value (one
+          day, or more).
+
+      Retry: If a secondary was unable to contact the primary at the
+          last refresh, wait the retry value before trying again.  This
+          value isn't as important as others, unless the secondary is on
+          a distant network from the primary or the primary is more
+          prone to outages.  It's typically some fraction of the refresh
+          interval.
+
+
+      Expire: How long a secondary will still treat its copy of the zone
+          data as valid if it can't contact the primary.  This value
+          should be greater than how long a major outage would typically
+          last, and must be greater than the minimum and retry
+          intervals, to avoid having a secondary expire the data before
+          it gets a chance to get a new copy.  After a zone is expired a
+          secondary will still continue to try to contact the primary,
+          but it will no longer provide nameservice for the zone.  2-4
+          weeks are suggested values.
+
+      Minimum: The default TTL (time-to-live) for resource records --
+          how long data will remain in other nameservers' cache.  ([RFC
+          1035] defines this to be the minimum value, but servers seem
+          to always implement this as the default value)  This is by far
+          the most important timer.  Set this as large as is comfortable
+          given how often you update your nameserver.  If you plan to
+          make major changes, it's a good idea to turn this value down
+          temporarily beforehand.  Then wait the previous minimum value,
+          make your changes, verify their correctness, and turn this
+          value back up.  1-5 days are typical values.  Remember this
+          value can be overridden on individual resource records.
+
+
+
+
+
+
+
+Barr                         Informational                      [Page 4]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   As you can see, the typical values above for the timers vary widely.
+   Popular documentation like [RFC 1033] recommended a day for the
+   minimum TTL, which is now considered too low except for zones with
+   data that vary regularly.  Once a DNS stabilizes, values on the order
+   of 3 or more days are recommended.  It is also recommended that you
+   individually override the TTL on certain RRs which are often
+   referenced and don't often change to have very large values (1-2
+   weeks).  Good examples of this are the MX, A, and PTR records of your
+   mail host(s), the NS records of your zone, and the A records of your
+   nameservers.
+
+2.3 Glue A Records
+
+   Glue records are A records that are associated with NS records to
+   provide "bootstrapping" information to the nameserver.  For example:
+
+           podunk.xx.      in      ns      ns1.podunk.xx.
+                           in      ns      ns2.podunk.xx.
+           ns1.podunk.xx.  in      a       1.2.3.4
+           ns2.podunk.xx.  in      a       1.2.3.5
+
+   Here, the A records are referred to as "Glue records".
+
+   Glue records are required only in forward zone files for nameservers
+   that are located in the subdomain of the current zone that is being
+   delegated.  You shouldn't have any A records in an in-addr.arpa zone
+   file (unless you're using RFC 1101-style encoding of subnet masks).
+
+   If your nameserver is multi-homed (has more than one IP address), you
+   must list all of its addresses in the glue to avoid cache
+   inconsistency due to differing TTL values, causing some lookups to
+   not find all addresses for your nameserver.
+
+   Some people get in the bad habit of putting in a glue record whenever
+   they add an NS record "just to make sure".  Having duplicate glue
+   records in your zone files just makes it harder when a nameserver
+   moves to a new IP address, or is removed. You'll spend hours trying
+   to figure out why random people still see the old IP address for some
+   host, because someone forgot to change or remove a glue record in
+   some other file.  Newer BIND versions will ignore these extra glue
+   records in local zone files.
+
+   Older BIND versions (4.8.3 and previous) have a problem where it
+   inserts these extra glue records in the zone transfer data to
+   secondaries.  If one of these glues is wrong, the error can be
+   propagated to other nameservers.  If two nameservers are secondaries
+   for other zones of each other, it's possible for one to continually
+   pass old glue records back to the other.  The only way to get rid of
+
+
+
+Barr                         Informational                      [Page 5]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   the old data is to kill both of them, remove the saved backup files,
+   and restart them.  Combined with that those same versions also tend
+   to become infected more easily with bogus data found in other non-
+   secondary nameservers (like the root zone data).
+
+2.4 CNAME records
+
+   A CNAME record is not allowed to coexist with any other data.  In
+   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
+   can't also have an MX record for suzy.podunk.edu, or an A record, or
+   even a TXT record.  Especially do not try to combine CNAMEs and NS
+   records like this!:
+
+
+           podunk.xx.      IN      NS      ns1
+                           IN      NS      ns2
+                           IN      CNAME   mary
+           mary            IN      A       1.2.3.4
+
+
+   This is often attempted by inexperienced administrators as an obvious
+   way to allow your domain name to also be a host.  However, DNS
+   servers like BIND will see the CNAME and refuse to add any other
+   resources for that name.  Since no other records are allowed to
+   coexist with a CNAME, the NS entries are ignored.  Therefore all the
+   hosts in the podunk.xx domain are ignored as well!
+
+   If you want to have your domain also be a host, do the following:
+
+           podunk.xx.      IN      NS      ns1
+                           IN      NS      ns2
+                           IN      A       1.2.3.4
+           mary            IN      A       1.2.3.4
+
+   Don't go overboard with CNAMEs.  Use them when renaming hosts, but
+   plan to get rid of them (and inform your users).  However CNAMEs are
+   useful (and encouraged) for generalized names for servers -- `ftp'
+   for your ftp server, `www' for your Web server, `gopher' for your
+   Gopher server, `news' for your Usenet news server, etc.
+
+   Don't forget to delete the CNAMEs associated with a host if you
+   delete the host it is an alias for.  Such "stale CNAMEs" are a waste
+   of resources.
+
+
+
+
+
+
+
+
+Barr                         Informational                      [Page 6]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   Don't use CNAMEs in combination with RRs which point to other names
+   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
+   implement classless in-addr delegation.)  For example, this is
+   strongly discouraged:
+
+           podunk.xx.      IN      MX      mailhost
+           mailhost        IN      CNAME   mary
+           mary            IN      A       1.2.3.4
+
+
+   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
+   974] explicitly states that MX records shall not point to an alias
+   defined by a CNAME.  This results in unnecessary indirection in
+   accessing the data, and DNS resolvers and servers need to work more
+   to get the answer.  If you really want to do this, you can accomplish
+   the same thing by using a preprocessor such as m4 on your host files.
+
+   Also, having chained records such as CNAMEs pointing to CNAMEs may
+   make administration issues easier, but is known to tickle bugs in
+   some resolvers that fail to check loops correctly.  As a result some
+   hosts may not be able to resolve such names.
+
+   Having NS records pointing to a CNAME is bad and may conflict badly
+   with current BIND servers.  In fact, current BIND implementations
+   will ignore such records, possibly leading to a lame delegation.
+   There is a certain amount of security checking done in BIND to
+   prevent spoofing DNS NS records.  Also, older BIND servers reportedly
+   will get caught in an infinite query loop trying to figure out the
+   address for the aliased nameserver, causing a continuous stream of
+   DNS requests to be sent.
+
+2.5 MX records
+
+   It is a good idea to give every host an MX record, even if it points
+   to itself!  Some mailers will cache MX records, but will always need
+   to check for an MX before sending mail.  If a site does not have an
+   MX, then every piece of mail may result in one more resolver query,
+   since the answer to the MX query often also contains the IP addresses
+   of the MX hosts.  Internet SMTP mailers are required by [RFC 1123] to
+   support the MX mechanism.
+
+   Put MX records even on hosts that aren't intended to send or receive
+   e-mail.  If there is a security problem involving one of these hosts,
+   some people will mistakenly send mail to postmaster or root at the
+   site without checking first to see if it is a "real" host or just a
+   terminal or personal computer that's not set up to accept e-mail.  If
+   you give it an MX record, then the e-mail can be redirected to a real
+   person.  Otherwise mail can just sit in a queue for hours or days
+
+
+
+Barr                         Informational                      [Page 7]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   until the mailer gives up trying to send it.
+
+   Don't forget that whenever you add an MX record, you need to inform
+   the target mailer if it is to treat the first host as "local".  (The
+   "Cw" flag in sendmail, for example)
+
+   If you add an MX record which points to an external host (e.g., for
+   the purposes of backup mail routing) be sure to ask permission from
+   that site first.  Otherwise that site could get rather upset and take
+   action (like throw your mail away, or appeal to higher authorities
+   like your parent DNS administrator or network provider.)
+
+2.6 Other Resource Records
+
+2.6.1 WKS
+
+   WKS records are deprecated in [RFC 1123].  They serve no known useful
+   function, except internally among LISP machines.  Don't use them.
+
+2.6.2 HINFO
+
+   On the issue HINFO records, some will argue that these is a security
+   problem (by broadcasting what vendor hardware and operating system
+   you so people can run systematic attacks on known vendor security
+   holes).  If you do use them, you should keep up to date with known
+   vendor security problems.  However, they serve a useful purpose.
+   Don't forget that HINFO requires two arguments, the hardware type,
+   and the operating system.
+
+   HINFO is sometimes abused to provide other information.  The record
+   is meant to provide specific information about the machine itself.
+   If you need to express other information about the host in the DNS,
+   use TXT.
+
+2.6.3 TXT
+
+   TXT records have no specific definition.  You can put most anything
+   in them.  Some use it for a generic description of the host, some put
+   specific information like its location, primary user, or maybe even a
+   phone number.
+
+2.6.4 RP
+
+   RP records are relatively new.  They are used to specify an e-mail
+   address (see first paragraph of section 2.2)  of the "Responsible
+   Person" of the host, and the name of a TXT record where you can get
+   more information.  See [RFC 1183].
+
+
+
+
+Barr                         Informational                      [Page 8]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+2.7 Wildcard records
+
+   Wildcard MXs are useful mostly for non IP-connected sites.  A common
+   mistake is thinking that a wildcard MX for a zone will apply to all
+   hosts in the zone.  A wildcard MX will apply only to names in the
+   zone which aren't listed in the DNS at all.  e.g.,
+
+           podunk.xx.      IN      NS      ns1
+                           IN      NS      ns2
+           mary            IN      A       1.2.3.4
+           *.podunk.xx.    IN      MX      5 sue
+
+   Mail for mary.podunk.xx will be sent to itself for delivery.  Only
+   mail for jane.podunk.xx or any hosts you don't see above will be sent
+   to the MX.  For most Internet sites, wildcard MX records are not
+   useful.  You need to put explicit MX records on every host.
+
+   Wildcard MXs can be bad, because they make some operations succeed
+   when they should fail instead.  Consider the case where someone in
+   the domain "widget.com" tries to send mail to "joe@larry".  If the
+   host "larry" doesn't actually exist, the mail should in fact bounce
+   immediately.  But because of domain searching the address gets
+   resolved to "larry.widget.com", and because of the wildcard MX this
+   is a valid address according to DNS.  Or perhaps someone simply made
+   a typo in the hostname portion of the address.  The mail message then
+   gets routed to the mail host, which then rejects the mail with
+   strange error messages like "I refuse to talk to myself" or "Local
+   configuration error".
+
+   Wildcard MX records are good for when you have a large number of
+   hosts which are not directly Internet-connected (for example, behind
+   a firewall) and for administrative or political reasons it is too
+   difficult to have individual MX records for every host, or to force
+   all e-mail addresses to be "hidden" behind one or more domain names.
+   In that case, you must divide your DNS into two parts, an internal
+   DNS, and an external DNS.  The external DNS will have only a few
+   hosts and explicit MX records, and one or more wildcard MXs for each
+   internal domain.  Internally the DNS will be complete, with all
+   explicit MX records and no wildcards.
+
+   Wildcard As and CNAMEs are possible too, and are really confusing to
+   users, and a potential nightmare if used without thinking first.  It
+   could result (due again to domain searching) in any telnet/ftp
+   attempts from within the domain to unknown hosts to be directed to
+   one address.  One such wildcard CNAME (in *.edu.com) caused
+   Internet-wide loss of services and potential security nightmares due
+   to unexpected interactions with domain searching.  It resulted in
+   swift fixes, and even an RFC ([RFC 1535]) documenting the problem.
+
+
+
+Barr                         Informational                      [Page 9]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+2.8 Authority and Delegation Errors (NS records)
+
+   You are required to have at least two nameservers for every domain,
+   though more is preferred.  Have secondaries outside your network.  If
+   the secondary isn't under your control, periodically check up on them
+   and make sure they're getting current zone data from you.  Queries to
+   their nameserver about your hosts should always result in an
+   "authoritative" response.  If not, this is called a "lame
+   delegation".  A lame delegations exists when a nameserver is
+   delegated responsibility for providing nameservice for a zone (via NS
+   records) but is not performing nameservice for that zone (usually
+   because it is not set up as a primary or secondary for the zone).
+
+   The "classic" lame delegation can be illustrated in this example:
+
+           podunk.xx.      IN      NS      ns1.podunk.xx.
+                           IN      NS      ns0.widget.com.
+
+   "podunk.xx" is a new domain which has recently been created, and
+   "ns1.podunk.xx" has been set up to perform nameservice for the zone.
+   They haven't quite finished everything yet and haven't made sure that
+   the hostmaster at "ns0.widget.com" has set up to be a proper
+   secondary, and thus has no information about the podunk.xx domain,
+   even though the DNS says it is supposed to.  Various things can
+   happen depending on which nameserver is used.  At best, extra DNS
+   traffic will result from a lame delegation.  At worst, you can get
+   unresolved hosts and bounced e-mail.
+
+   Also, sometimes a nameserver is moved to another host or removed from
+   the list of secondaries.  Unfortunately due to caching of NS records,
+   many sites will still think that a host is a secondary after that
+   host has stopped providing nameservice.  In order to prevent lame
+   delegations while the cache is being aged, continue to provide
+   nameservice on the old nameserver for the length of the maximum of
+   the minimum plus refresh times for the zone and the parent zone.
+   (See section 2.2)
+
+   Whenever a primary or secondary is removed or changed, it takes a
+   fair amount of human coordination among the parties involved.  (The
+   site itself, it's parent, and the site hosting the secondary)  When a
+   primary moves, make sure all secondaries have their named.boot files
+   updated and their servers reloaded.  When a secondary moves, make
+   sure the address records at both the primary and parent level are
+   changed.
+
+   It's also been reported that some distant sites like to pick popular
+   nameservers like "ns.uu.net" and just add it to their list of NS
+   records in hopes that they will magically perform additional
+
+
+
+Barr                         Informational                     [Page 10]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   nameservice for them.  This is an even worse form of lame delegation,
+   since this adds traffic to an already busy nameserver.  Please
+   contact the hostmasters of sites which have lame delegations.
+   Various tools can be used to detect or actively find lame
+   delegations.  See the list of contributed software in the BIND
+   distribution.
+
+   Make sure your parent domain has the same NS records for your zone as
+   you do.  (Don't forget your in-addr.arpa zones too!).  Do not list
+   too many (7 is the recommended maximum), as this just makes things
+   harder to manage and is only really necessary for very popular top-
+   level or root zones.  You also run the risk of overflowing the 512-
+   byte limit of a UDP packet in the response to an NS query.  If this
+   happens, resolvers will "fall back" to using TCP requests, resulting
+   in increased load on your nameserver.
+
+   It's important when picking geographic locations for secondary
+   nameservers to minimize latency as well as increase reliability.
+   Keep in mind network topologies.  For example if your site is on the
+   other end of a slow local or international link, consider a secondary
+   on the other side of the link to decrease average latency.  Contact
+   your Internet service provider or parent domain contact for more
+   information about secondaries which may be available to you.
+
+3. BIND operation
+
+   This section discusses common problems people have in the actual
+   operation of the nameserver (specifically, BIND).  Not only must the
+   data be correct as explained above, but the nameserver must be
+   operated correctly for the data to be made available.
+
+3.1 Serial numbers
+
+   Each zone has a serial number associated with it.  Its use is for
+   keeping track of who has the most current data.  If and only if the
+   primary's serial number of the zone is greater will the secondary ask
+   the primary for a copy of the new zone data (see special case below).
+
+   Don't forget to change the serial number when you change data!  If
+   you don't, your secondaries will not transfer the new zone
+   information.  Automating the incrementing of the serial number with
+   software is also a good idea.
+
+   If you make a mistake and increment the serial number too high, and
+   you want to reset the serial number to a lower value, use the
+   following procedure:
+
+
+
+
+
+Barr                         Informational                     [Page 11]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+      Take the `incorrect' serial number and add 2147483647 to it.  If
+      the number exceeds 4294967296, subtract 4294967296.  Load the
+      resulting number.  Then wait 2 refresh periods to allow the zone
+      to propagate to all servers.
+
+      Repeat above until the resulting serial number is less than the
+      target serial number.
+
+      Up the serial number to the target serial number.
+
+   This procedure won't work if one of your secondaries is running an
+   old version of BIND (4.8.3 or earlier).  In this case you'll have to
+   contact the hostmaster for that secondary and have them kill the
+   secondary servers, remove the saved backup file, and restart the
+   server.  Be careful when editing the serial number -- DNS admins
+   don't like to kill and restart nameservers because you lose all that
+   cached data.
+
+3.2 Zone file style guide
+
+   Here are some useful tips in structuring your zone files.  Following
+   these will help you spot mistakes, and avoid making more.
+
+   Be consistent with the style of entries in your DNS files. If your
+   $ORIGIN is podunk.xx., try not to write entries like:
+
+           mary            IN      A       1.2.3.1
+           sue.podunk.xx.  IN      A       1.2.3.2
+
+   or:
+
+           bobbi           IN      A       1.2.3.2
+                           IN      MX      mary.podunk.xx.
+
+
+   Either use all FQDNs (Fully Qualified Domain Names) everywhere or
+   used unqualified names everywhere.  Or have FQDNs all on the right-
+   hand side but unqualified names on the left.  Above all, be
+   consistent.
+
+   Use tabs between fields, and try to keep columns lined up.  It makes
+   it easier to spot missing fields (note some fields such as "IN" are
+   inherited from the previous record and may be left out in certain
+   circumstances.)
+
+
+
+
+
+
+
+Barr                         Informational                     [Page 12]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   Remember you don't need to repeat the name of the host when you are
+   defining multiple records for one host.  Be sure also to keep all
+   records associated with a host together in the file.  It will make
+   things more straightforward when it comes time to remove or rename a
+   host.
+
+   Always remember your $ORIGIN.  If you don't put a `.' at the end of
+   an FQDN, it's not recognized as an FQDN.  If it is not an FQDN, then
+   the nameserver will append $ORIGIN to the name.  Double check, triple
+   check, those trailing dots, especially in in-addr.arpa zone files,
+   where they are needed the most.
+
+   Be careful with the syntax of the SOA and WKS records (the records
+   which use parentheses).  BIND is not very flexible in how it parses
+   these records.  See the documentation for BIND.
+
+3.3 Verifying data
+
+   Verify the data you just entered or changed by querying the resolver
+   with dig (or your favorite DNS tool, many are included in the BIND
+   distribution) after a change.  A few seconds spent double checking
+   can save hours of trouble, lost mail, and general headaches.  Also be
+   sure to check syslog output when you reload the nameserver.  If you
+   have grievous errors in your DNS data or boot file, named will report
+   it via syslog.
+
+   It is also highly recommended that you automate this checking, either
+   with software which runs sanity checks on the data files before they
+   are loaded into the nameserver, or with software which checks the
+   data already loaded in the nameserver.  Some contributed software to
+   do this is included in the BIND distribution.
+
+4. Miscellaneous Topics
+
+4.1 Boot file setup
+
+   Certain zones should always be present in nameserver configurations:
+
+           primary         localhost               localhost
+           primary         0.0.127.in-addr.arpa    127.0
+           primary         255.in-addr.arpa        255
+           primary         0.in-addr.arpa          0
+
+   These are set up to either provide nameservice for "special"
+   addresses, or to help eliminate accidental queries for broadcast or
+   local address to be sent off to the root nameservers.  All of these
+   files will contain NS and SOA records just like the other zone files
+   you maintain, the exception being that you can probably make the SOA
+
+
+
+Barr                         Informational                     [Page 13]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   timers very long, since this data will never change.
+
+   The "localhost" address is a "special" address which always refers to
+   the local host.  It should contain the following line:
+
+           localhost.      IN      A       127.0.0.1
+
+   The "127.0" file should contain the line:
+
+           1    PTR     localhost.
+
+   There has been some extensive discussion about whether or not to
+   append the local domain to it.  The conclusion is that "localhost."
+   would be the best solution.  The reasons given include:
+
+      "localhost" by itself is used and expected to work in some
+      systems.
+
+      Translating 127.0.0.1 into "localhost.dom.ain" can cause some
+      software to connect back to the loopback interface when it didn't
+      want to because "localhost" is not equal to "localhost.dom.ain".
+
+   The "255" and "0" files should not contain any additional data beyond
+   the NS and SOA records.
+
+   Note that future BIND versions may include all or some of this data
+   automatically without additional configuration.
+
+4.2 Other Resolver and Server bugs
+
+   Very old versions of the DNS resolver have a bug that cause queries
+   for names that look like IP addresses to go out, because the user
+   supplied an IP address and the software didn't realize that it didn't
+   need to be resolved.  This has been fixed but occasionally it still
+   pops up.  It's important because this bug means that these queries
+   will be sent directly to the root nameservers, adding to an already
+   heavy DNS load.
+
+   While running a secondary nameserver off another secondary nameserver
+   is possible, it is not recommended unless necessary due to network
+   topologies.  There are known cases where it has led to problems like
+   bogus TTL values.  While this may be caused by older or flawed DNS
+   implementations, you should not chain secondaries off of one another
+   since this builds up additional reliability dependencies as well as
+   adds additional delays in updates of new zone data.
+
+
+
+
+
+
+Barr                         Informational                     [Page 14]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+4.3 Server issues
+
+   DNS operates primarily via UDP (User Datagram Protocol) messages.
+   Some UNIX operating systems, in an effort to save CPU cycles, run
+   with UDP checksums turned off.  The relative merits of this have long
+   been debated.  However, with the increase in CPU speeds, the
+   performance considerations become less and less important.  It is
+   strongly encouraged that you turn on UDP checksumming to avoid
+   corrupted data not only with DNS but with other services that use UDP
+   (like NFS).  Check with your operating system documentation to verify
+   that UDP checksumming is enabled.
+
+References
+
+   [RFC 974] Partridge, C., "Mail routing and the domain system", STD
+              14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
+
+   [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
+              1033, USC/Information Sciences Institute, November 1987.
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, USC/Information Sciences Institute,
+              November 1987.
+
+   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, USC/Information Sciences
+              Institute, November 1987.
+
+   [RFC 1123] Braden, R., "Requirements for Internet Hosts --
+              Application and Support", STD 3, RFC 1123, IETF, October
+              1989.
+
+   [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
+              1178, Integrated Systems Group/NIST, August 1990.
+
+   [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
+              "New DNS RR Definitions", RFC 1183, October 1990.
+
+   [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction
+              With Widely Deployed DNS Software", RFC 1535, ACES
+              Research Inc., October 1993.
+
+   [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
+              Miller, "Common DNS Implementation Errors and Suggested
+              Fixes", RFC 1536, USC/Information Sciences Institute, USC,
+              October 1993.
+
+
+
+
+
+Barr                         Informational                     [Page 15]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",
+              RFC 1537, CWI, October 1993.
+
+   [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,
+              November 1994.
+
+   [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
+              Vixie Enterprises, July 1994.
+
+5. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+6. Author's Address
+
+   David Barr
+   The Pennsylvania State University
+   Department of Mathematics
+   334 Whitmore Building
+   University Park, PA 16802
+
+   Voice: +1 814 863 7374
+   Fax: +1 814 863-8311
+   EMail: barr@math.psu.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barr                         Informational                     [Page 16]
+
diff --git a/doc/rfc/rfc3755.txt b/doc/rfc/rfc3755.txt
new file mode 100644
index 000000000000..a9a7cf269298
--- /dev/null
+++ b/doc/rfc/rfc3755.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                          S. Weiler
+Request for Comments: 3755                                  SPARTA, Inc.
+Updates: 3658, 2535                                             May 2004
+Category: Standards Track
+
+
+        Legacy Resolver Compatibility for Delegation Signer (DS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   As the DNS Security (DNSSEC) specifications have evolved, the syntax
+   and semantics of the DNSSEC resource records (RRs) have changed.
+   Many deployed nameservers understand variants of these semantics.
+   Dangerous interactions can occur when a resolver that understands an
+   earlier version of these semantics queries an authoritative server
+   that understands the new delegation signer semantics, including at
+   least one failure scenario that will cause an unsecured zone to be
+   unresolvable.  This document changes the type codes and mnemonics of
+   the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
+
+1.  Introduction
+
+   The DNSSEC protocol has been through many iterations whose syntax and
+   semantics are not completely compatible.  This has occurred as part
+   of the ordinary process of proposing a protocol, implementing it,
+   testing it in the increasingly complex and diverse environment of the
+   Internet, and refining the definitions of the initial Proposed
+   Standard.  In the case of DNSSEC, the process has been complicated by
+   DNS's criticality and wide deployment and the need to add security
+   while minimizing daily operational complexity.
+
+   A weak area for previous DNS specifications has been lack of detail
+   in specifying resolver behavior, leaving implementors largely on
+   their own to determine many details of resolver function.  This,
+   combined with the number of iterations the DNSSEC specifications have
+   been through, has resulted in fielded code with a wide variety of
+
+
+
+Weiler                      Standards Track                     [Page 1]
+
+RFC 3755          Legacy Resolver Compatibility for DS          May 2004
+
+
+   behaviors.  This variety makes it difficult to predict how a protocol
+   change will be handled by all deployed resolvers.  The risk that a
+   change will cause unacceptable or even catastrophic failures makes it
+   difficult to design and deploy a protocol change.  One strategy for
+   managing that risk is to structure protocol changes so that existing
+   resolvers can completely ignore input that might confuse them or
+   trigger undesirable failure modes.
+
+   This document addresses a specific problem caused by Delegation
+   Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR
+   that are incompatible with the semantics in [RFC2535].  Answers
+   provided by DS-aware servers can trigger an unacceptable failure mode
+   in some resolvers that implement RFC 2535, which provides a great
+   disincentive to sign zones with DS.  The changes defined in this
+   document allow for the incremental deployment of DS.
+
+1.1.  Terminology
+
+   In this document, the term "unsecure delegation" means any delegation
+   for which no DS record appears at the parent.  An "unsecure referral"
+   is an answer from the parent containing an NS RRset and a proof that
+   no DS record exists for that name.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+1.2.  The Problem
+
+   Delegation Signer (DS) introduces new semantics for the NXT RR that
+   are incompatible with the semantics in RFC 2535.  In RFC 2535, NXT
+   records were only required to be returned as part of a non-existence
+   proof.  With DS, an unsecure referral returns, in addition to the NS,
+   a proof of non-existence of a DS RR in the form of an NXT and
+   SIG(NXT).  RFC 2535 didn't specify how a resolver was to interpret a
+   response with RCODE=0, AA=0, and both an NS and an NXT in the
+   authority section.  Some widely deployed 2535-aware resolvers
+   interpret any answer with an NXT as a proof of non-existence of the
+   requested record.  This results in unsecure delegations being
+   invisible to 2535-aware resolvers and violates the basic
+   architectural principle that DNSSEC must do no harm -- the signing of
+   zones must not prevent the resolution of unsecured delegations.
+
+2.  Possible Solutions
+
+   This section presents several solutions that were considered.
+   Section 3 describes the one selected.
+
+
+
+
+Weiler                      Standards Track                     [Page 2]
+
+RFC 3755          Legacy Resolver Compatibility for DS          May 2004
+
+
+2.1.  Change SIG, KEY, and NXT type codes
+
+   To avoid the problem described above, legacy (RFC2535-aware)
+   resolvers need to be kept from seeing unsecure referrals that include
+   NXT records in the authority section.  The simplest way to do that is
+   to change the type codes for SIG, KEY, and NXT.
+
+   The obvious drawback to this is that new resolvers will not be able
+   to validate zones signed with the old RRs.  This problem already
+   exists, however, because of the changes made by DS, and resolvers
+   that understand the old RRs (and have compatibility issues with DS)
+   are far more prevalent than 2535-signed zones.
+
+2.2.  Change a subset of type codes
+
+   The observed problem with unsecure referrals could be addressed by
+   changing only the NXT type code or another subset of the type codes
+   that includes NXT.  This has the virtue of apparent simplicity, but
+   it risks introducing new problems or not going far enough.  It's
+   quite possible that more incompatibilities exist between DS and
+   earlier semantics.  Legacy resolvers may also be confused by seeing
+   records they recognize (SIG and KEY) while being unable to find NXTs.
+   Although it may seem unnecessary to fix that which is not obviously
+   broken, it's far cleaner to change all of the type codes at once.
+   This will leave legacy resolvers and tools completely blinded to
+   DNSSEC -- they will see only unknown RRs.
+
+2.3.  Replace the DO bit
+
+   Another way to keep legacy resolvers from ever seeing DNSSEC records
+   with DS semantics is to have authoritative servers only send that
+   data to DS-aware resolvers.  It's been proposed that assigning a new
+   EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and
+   having authoritative servers send DNSSEC data only in response to
+   queries with the DA bit set, would accomplish this.  This bit would
+   presumably supplant the DO bit described in [RFC3225].
+
+   This solution is sufficient only if all 2535-aware resolvers zero out
+   EDNS0 flags that they don't understand.  If one passed through the DA
+   bit unchanged, it would still see the new semantics, and it would
+   probably fail to see unsecure delegations.  Since it's impractical to
+   know how every DNS implementation handles unknown EDNS0 flags, this
+   is not a universal solution.  It could, though, be considered in
+   addition to changing the RR type codes.
+
+
+
+
+
+
+
+Weiler                      Standards Track                     [Page 3]
+
+RFC 3755          Legacy Resolver Compatibility for DS          May 2004
+
+
+2.4.  Increment the EDNS version
+
+   Another possible solution is to increment the EDNS version number as
+   defined in [RFC2671], on the assumption that all existing
+   implementations will reject higher versions than they support, and
+   retain the DO bit as the signal for DNSSEC awareness.  This approach
+   has not been tested.
+
+2.5.  Do nothing
+
+   There is a large deployed base of DNS resolvers that understand
+   DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and,
+   due to under specification in those documents, interpret any answer
+   with an NXT as a non-existence proof.  So long as that is the case,
+   zone owners will have a strong incentive to not sign any zones that
+   contain unsecure delegations, lest those delegations be invisible to
+   such a large installed base.  This will dramatically slow DNSSEC
+   adoption.
+
+   Unfortunately, without signed zones there's no clear incentive for
+   operators of resolvers to upgrade their software to support the new
+   version of DNSSEC, as defined in RFC 3658.  Historical data suggests
+   that resolvers are rarely upgraded, and that old nameserver code
+   never dies.
+
+   Rather than wait years for resolvers to be upgraded through natural
+   processes before signing zones with unsecure delegations, addressing
+   this problem with a protocol change will immediately remove the
+   disincentive for signing zones and allow widespread deployment of
+   DNSSEC.
+
+3.  Protocol changes
+
+   This document changes the type codes of SIG, KEY, and NXT.  This
+   approach is the cleanest and safest of those discussed above, largely
+   because the behavior of resolvers that receive unknown type codes is
+   well understood.  This approach has also received the most testing.
+
+   To avoid operational confusion, it's also necessary to change the
+   mnemonics for these RRs.  DNSKEY will be the replacement for KEY,
+   with the mnemonic indicating that these keys are not for application
+   use, per [RFC3445].  RRSIG (Resource Record SIGnature) will replace
+   SIG, and NSEC (Next SECure) will replace NXT.  These new types
+   completely replace the old types, except that SIG(0) [RFC2931] and
+   TKEY [RFC2930] will continue to use SIG and KEY.
+
+
+
+
+
+
+Weiler                      Standards Track                     [Page 4]
+
+RFC 3755          Legacy Resolver Compatibility for DS          May 2004
+
+
+   The new types will have exactly the same syntax and semantics as
+   specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for
+   the following:
+
+   1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC
+      RRs MUST NOT be compressed,
+
+   2) Embedded domain names in RRSIG and NSEC RRs are not downcased for
+      purposes of DNSSEC canonical form and ordering nor for equality
+      comparison, and
+
+   3) An RRSIG with a type-covered field of zero has undefined
+      semantics.  The meaning of such a resource record may only be
+      defined by IETF Standards Action.
+
+   If a resolver receives the old types, it SHOULD treat them as unknown
+   RRs and SHOULD NOT assign any special meaning to them or give them
+   any special treatment.  It MUST NOT use them for DNSSEC validations
+   or other DNS operational decision making.  For example, a resolver
+   MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs.
+   If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive
+   special treatment.  As an example, if a SIG is included in a signed
+   zone, there MUST be an RRSIG for it.  Authoritative servers may wish
+   to give error messages when loading zones containing SIG or NXT
+   records (KEY records may be included for SIG(0) or TKEY).
+
+   As a clarification to previous documents, some positive responses,
+   particularly wildcard proofs and unsecure referrals, will contain
+   NSEC RRs.  Resolvers MUST NOT treat answers with NSEC RRs as negative
+   answers merely because they contain an NSEC.
+
+4.  IANA Considerations
+
+4.1.  DNS Resource Record Types
+
+   This document updates the IANA registry for DNS Resource Record Types
+   by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,
+   respectively.
+
+   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
+   TKEY [RFC2930] use only.
+
+   Type 30 (NXT) should be marked as Obsolete.
+
+
+
+
+
+
+
+
+Weiler                      Standards Track                     [Page 5]
+
+RFC 3755          Legacy Resolver Compatibility for DS          May 2004
+
+
+4.2.  DNS Security Algorithm Numbers
+
+   To allow zone signing (DNSSEC) and transaction security mechanisms
+   (SIG(0) and TKEY) to use different sets of algorithms, the existing
+   "DNS Security Algorithm Numbers" registry is modified to include the
+   applicability of each algorithm.  Specifically, two new columns are
+   added to the registry, showing whether each algorithm may be used for
+   zone signing, transaction security mechanisms, or both.  Only
+   algorithms usable for zone signing may be used in DNSKEY, RRSIG, and
+   DS RRs.  Only algorithms usable for SIG(0) and/or TSIG may be used in
+   SIG and KEY RRs.
+
+   All currently defined algorithms except for Indirect (algorithm 252)
+   remain usable for transaction security mechanisms.  Only RSA/SHA-1
+   [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and
+   254) may be used for zone signing.  Note that the registry does not
+   contain the requirement level of each algorithm, only whether or not
+   an algorithm may be used for the given purposes.  For example,
+   RSA/MD5, while allowed for transaction security mechanisms, is NOT
+   RECOMMENDED, per [RFC3110].
+
+   Additionally, the presentation format algorithm mnemonics from
+   [RFC2535] Section 7 are added to the registry.  This document assigns
+   RSA/SHA-1 the mnemonic RSASHA1.
+
+   As before, assignment of new algorithms in this registry requires
+   IETF Standards Action.  Additionally, modification of algorithm
+   mnemonics or applicability requires IETF Standards Action.  Documents
+   defining a new algorithm must address the applicability of the
+   algorithm and should assign a presentation mnemonic to the algorithm.
+
+4.3.  DNSKEY Flags
+
+   Like the KEY resource record, DNSKEY contains a 16-bit flags field.
+   This document creates a new registry for the DNSKEY flags field.
+
+   Initially, this registry only contains an assignment for bit 7 (the
+   ZONE bit).  Bits 0-6 and 8-15 are available for assignment by IETF
+   Standards Action.
+
+4.4.  DNSKEY Protocol Octet
+
+   Like the KEY resource record, DNSKEY contains an eight bit protocol
+   field.  The only defined value for this field is 3 (DNSSEC).  No
+   other values are allowed, hence no IANA registry is needed for this
+   field.
+
+
+
+
+
+Weiler                      Standards Track                     [Page 6]
+
+RFC 3755          Legacy Resolver Compatibility for DS          May 2004
+
+
+5.  Security Considerations
+
+   The changes introduced here do not materially affect security.  The
+   implications of trying to use both new and legacy types together are
+   not well understood, and attempts to do so would probably lead to
+   unintended and dangerous results.
+
+   Changing type codes will leave code paths in legacy resolvers that
+   are never exercised.  Unexercised code paths are a frequent source of
+   security holes, largely because those code paths do not get frequent
+   scrutiny.
+
+   Doing nothing, as described in section 2.5, will slow DNSSEC
+   deployment.  While this does not decrease security, it also fails to
+   increase it.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
+             (DNS)", RFC 2536, March 1999.
+
+   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
+             RFC 2930, September 2000.
+
+   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+             (SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+             Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
+             (RR)", RFC 3658, December 2003.
+
+
+
+
+
+
+
+
+
+
+
+Weiler                      Standards Track                     [Page 7]
+
+RFC 3755          Legacy Resolver Compatibility for DS          May 2004
+
+
+6.2.  Informative References
+
+   [RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
+             Security Extensions", RFC 2065, January 1997.
+
+   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+             2671, August 1999.
+
+   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+             3225, December 2001.
+
+   [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
+             Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+             (RR) Types", RFC 3597, September 2003.
+
+7.  Acknowledgments
+
+   The changes introduced here and the analysis of alternatives had many
+   contributors.  With apologies to anyone overlooked, those include:
+   Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis,
+   Bill Manning, Paul Vixie, and Suzanne Woolf.
+
+   Thanks to Jakob Schlyter and Mark Andrews for identifying the
+   incompatibility described in section 1.2.
+
+   In addition to the above, the author would like to thank Scott Rose,
+   Olafur Gudmundsson, and Sandra Murphy for their substantive comments.
+
+8.  Author's Address
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7075 Samuel Morse Drive
+   Columbia, MD 21046
+   USA
+
+   EMail: weiler@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                      Standards Track                     [Page 8]
+
+RFC 3755          Legacy Resolver Compatibility for DS          May 2004
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/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.
+
+
+
+
+
+
+
+
+
+Weiler                      Standards Track                     [Page 9]
+
diff --git a/doc/rfc/rfc4294.txt b/doc/rfc/rfc4294.txt
new file mode 100644
index 000000000000..8fea5c311bfd
--- /dev/null
+++ b/doc/rfc/rfc4294.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                   J. Loughney, Ed.
+Request for Comments: 4294                                         Nokia
+Category: Informational                                       April 2006
+
+
+                         IPv6 Node Requirements
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines requirements for IPv6 nodes.  It is expected
+   that IPv6 will be deployed in a wide range of devices and situations.
+   Specifying the requirements for IPv6 nodes allows IPv6 to function
+   well and interoperate in a large number of situations and
+   deployments.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Requirement Language .......................................3
+      1.2. Scope of This Document .....................................3
+      1.3. Description of IPv6 Nodes ..................................3
+   2. Abbreviations Used in This Document .............................3
+   3. Sub-IP Layer ....................................................4
+      3.1. Transmission of IPv6 Packets over Ethernet Networks
+           - RFC 2464 .................................................4
+      3.2. IP version 6 over PPP - RFC 2472 ...........................4
+      3.3. IPv6 over ATM Networks - RFC 2492 ..........................4
+   4. IP Layer ........................................................5
+      4.1. Internet Protocol Version 6 - RFC 2460 .....................5
+      4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5
+      4.3. Path MTU Discovery and Packet Size .........................6
+      4.4. ICMP for the Internet Protocol Version 6 (IPv6) -
+           RFC 2463 ...................................................7
+      4.5. Addressing .................................................7
+      4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8
+   5. DNS and DHCP ....................................................8
+      5.1. DNS ........................................................8
+
+
+
+
+Loughney                     Informational                      [Page 1]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+      5.2. Dynamic Host Configuration Protocol for IPv6
+           (DHCPv6) - RFC 3315 ........................................9
+   6. IPv4 Support and Transition ....................................10
+      6.1. Transition Mechanisms .....................................10
+   7. Mobile IP ......................................................10
+   8. Security .......................................................10
+      8.1. Basic Architecture ........................................10
+      8.2. Security Protocols ........................................11
+      8.3. Transforms and Algorithms .................................11
+      8.4. Key Management Methods ....................................12
+   9. Router-Specific Functionality ..................................12
+      9.1. General ...................................................12
+   10. Network Management ............................................12
+      10.1. Management Information Base Modules (MIBs) ...............12
+   11. Security Considerations .......................................13
+   12. References ....................................................13
+      12.1. Normative References .....................................13
+      12.2. Informative References ...................................16
+   13. Authors and Acknowledgements ..................................18
+
+1.  Introduction
+
+   The goal of this document is to define the common functionality
+   required from both IPv6 hosts and routers.  Many IPv6 nodes will
+   implement optional or additional features, but this document
+   summarizes requirements from other published Standards Track
+   documents in one place.
+
+   This document tries to avoid discussion of protocol details, and
+   references RFCs for this purpose.  This document is informational in
+   nature and does not update Standards Track RFCs.
+
+   Although the document points to different specifications, it should
+   be noted that in most cases, the granularity of requirements are
+   smaller than a single specification, as many specifications define
+   multiple, independent pieces, some of which may not be mandatory.
+
+   As it is not always possible for an implementer to know the exact
+   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
+   that they should adhere to Jon Postel's Robustness Principle:
+
+      Be conservative in what you do, be liberal in what you accept from
+      others [RFC-793].
+
+
+
+
+
+
+
+
+Loughney                     Informational                      [Page 2]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+1.1.  Requirement Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC-2119].
+
+1.2.  Scope of This Document
+
+   IPv6 covers many specifications.  It is intended that IPv6 will be
+   deployed in many different situations and environments.  Therefore,
+   it is important to develop the requirements for IPv6 nodes to ensure
+   interoperability.
+
+   This document assumes that all IPv6 nodes meet the minimum
+   requirements specified here.
+
+1.3.  Description of IPv6 Nodes
+
+   From the Internet Protocol, Version 6 (IPv6) Specification
+   [RFC-2460], we have the following definitions:
+
+      Description of an IPv6 Node
+
+         -  a device that implements IPv6.
+
+      Description of an IPv6 router
+
+         -  a node that forwards IPv6 packets not explicitly addressed
+            to itself.
+
+      Description of an IPv6 Host
+
+      -  any node that is not a router.
+
+2.  Abbreviations Used in This Document
+
+   ATM   Asynchronous Transfer Mode
+
+   AH    Authentication Header
+
+   DAD   Duplicate Address Detection
+
+   ESP   Encapsulating Security Payload
+
+   ICMP  Internet Control Message Protocol
+
+   IKE   Internet Key Exchange
+
+
+
+
+Loughney                     Informational                      [Page 3]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+   MIB   Management Information Base
+
+   MLD   Multicast Listener Discovery
+
+   MTU   Maximum Transfer Unit
+
+   NA    Neighbor Advertisement
+
+   NBMA  Non-Broadcast Multiple Access
+
+   ND    Neighbor Discovery
+
+   NS    Neighbor Solicitation
+
+   NUD   Neighbor Unreachability Detection
+
+   PPP   Point-to-Point Protocol
+
+   PVC   Permanent Virtual Circuit
+
+   SVC   Switched Virtual Circuit
+
+3.  Sub-IP Layer
+
+   An IPv6 node must include support for one or more IPv6 link-layer
+   specifications.  Which link-layer specifications are included will
+   depend upon what link-layers are supported by the hardware available
+   on the system.  It is possible for a conformant IPv6 node to support
+   IPv6 on some of its interfaces and not on others.
+
+   As IPv6 is run over new layer 2 technologies, it is expected that new
+   specifications will be issued.  This section highlights some major
+   layer 2 technologies and is not intended to be complete.
+
+3.1.  Transmission of IPv6 Packets over Ethernet Networks - RFC 2464
+
+   Nodes supporting IPv6 over Ethernet interfaces MUST implement
+   Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
+
+3.2.  IP version 6 over PPP - RFC 2472
+
+   Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP
+   [RFC-2472].
+
+3.3.  IPv6 over ATM Networks - RFC 2492
+
+   Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
+   Networks [RFC-2492].  Additionally, RFC 2492 states:
+
+
+
+Loughney                     Informational                      [Page 4]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+      A minimally conforming IPv6/ATM driver SHALL support the PVC mode
+      of operation.  An IPv6/ATM driver that supports the full SVC mode
+      SHALL also support PVC mode of operation.
+
+4.  IP Layer
+
+4.1.  Internet Protocol Version 6 - RFC 2460
+
+   The Internet Protocol Version 6 is specified in [RFC-2460].  This
+   specification MUST be supported.
+
+   Unrecognized options in Hop-by-Hop Options or Destination Options
+   extensions MUST be processed as described in RFC 2460.
+
+   The node MUST follow the packet transmission rules in RFC 2460.
+
+   Nodes MUST always be able to send, receive, and process fragment
+   headers.  All conformant IPv6 implementations MUST be capable of
+   sending and receiving IPv6 packets; the forwarding functionality MAY
+   be supported.
+
+   RFC 2460 specifies extension headers and the processing for these
+   headers.
+
+      A full implementation of IPv6 includes implementation of the
+      following extension headers: Hop-by-Hop Options, Routing (Type 0),
+      Fragment, Destination Options, Authentication and Encapsulating
+      Security Payload [RFC-2460].
+
+   An IPv6 node MUST be able to process these headers.  It should be
+   noted that there is some discussion about the use of Routing Headers
+   and possible security threats [IPv6-RH] that they cause.
+
+4.2.  Neighbor Discovery for IPv6 - RFC 2461
+
+   Neighbor Discovery SHOULD be supported.  [RFC-2461] states:
+
+      "Unless specified otherwise (in a document that covers operating
+      IP over a particular link type) this document applies to all link
+      types.  However, because ND uses link-layer multicast for some of
+      its services, it is possible that on some link types (e.g., NBMA
+      links) alternative protocols or mechanisms to implement those
+      services will be specified (in the appropriate document covering
+      the operation of IP over a particular link type).  The services
+      described in this document that are not directly dependent on
+      multicast, such as Redirects, Next-hop determination, Neighbor
+      Unreachability Detection, etc., are expected to be provided as
+
+
+
+
+Loughney                     Informational                      [Page 5]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+      specified in this document.  The details of how one uses ND on
+      NBMA links is an area for further study."
+
+   Some detailed analysis of Neighbor Discovery follows:
+
+   Router Discovery is how hosts locate routers that reside on an
+   attached link.  Router Discovery MUST be supported for
+   implementations.
+
+   Prefix Discovery is how hosts discover the set of address prefixes
+   that define which destinations are on-link for an attached link.
+   Prefix discovery MUST be supported for implementations.  Neighbor
+   Unreachability Detection (NUD) MUST be supported for all paths
+   between hosts and neighboring nodes.  It is not required for paths
+   between routers.  However, when a node receives a unicast Neighbor
+   Solicitation (NS) message (that may be a NUD's NS), the node MUST
+   respond to it (i.e., send a unicast Neighbor Advertisement).
+
+   Duplicate Address Detection MUST be supported on all links supporting
+   link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take
+   place on all unicast addresses).
+
+   A host implementation MUST support sending Router Solicitations.
+
+   Receiving and processing Router Advertisements MUST be supported for
+   host implementations.  The ability to understand specific Router
+   Advertisement options is dependent on supporting the specification
+   where the RA is specified.
+
+   Sending and Receiving Neighbor Solicitation (NS) and Neighbor
+   Advertisement (NA) MUST be supported.  NS and NA messages are
+   required for Duplicate Address Detection (DAD).
+
+   Redirect functionality SHOULD be supported.  If the node is a router,
+   Redirect functionality MUST be supported.
+
+4.3.  Path MTU Discovery and Packet Size
+
+4.3.1.  Path MTU Discovery - RFC 1981
+
+   Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
+   implementations MAY choose to not support it and avoid large packets.
+   The rules in RFC 2460 MUST be followed for packet fragmentation and
+   reassembly.
+
+4.3.2.  IPv6 Jumbograms - RFC 2675
+
+   IPv6 Jumbograms [RFC-2675] MAY be supported.
+
+
+
+Loughney                     Informational                      [Page 6]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+4.4.  ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463
+
+   ICMPv6 [RFC-2463] MUST be supported.
+
+4.5.  Addressing
+
+4.5.1.  IP Version 6 Addressing Architecture - RFC 3513
+
+   The IPv6 Addressing Architecture [RFC-3513] MUST be supported as
+   updated by [RFC-3879].
+
+4.5.2.  IPv6 Stateless Address Autoconfiguration - RFC 2462
+
+   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
+   This specification MUST be supported for nodes that are hosts.
+   Static address can be supported as well.
+
+   Nodes that are routers MUST be able to generate link local addresses
+   as described in RFC 2462 [RFC-2462].
+
+   From 2462:
+
+      The autoconfiguration process specified in this document applies
+      only to hosts and not routers.  Since host autoconfiguration uses
+      information advertised by routers, routers will need to be
+      configured by some other means.  However, it is expected that
+      routers will generate link-local addresses using the mechanism
+      described in this document.  In addition, routers are expected to
+      successfully pass the Duplicate Address Detection procedure
+      described in this document on all addresses prior to assigning
+      them to an interface.
+
+   Duplicate Address Detection (DAD) MUST be supported.
+
+4.5.3.  Privacy Extensions for Address Configuration in IPv6 - RFC 3041
+
+   Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
+   SHOULD be supported.  It is recommended that this behavior be
+   configurable on a connection basis within each application when
+   available.  It is noted that a number of applications do not work
+   with addresses generated with this method, while other applications
+   work quite well with them.
+
+4.5.4.  Default Address Selection for IPv6 - RFC 3484
+
+   The rules specified in the Default Address Selection for IPv6
+   [RFC-3484] document MUST be implemented.  It is expected that IPv6
+   nodes will need to deal with multiple addresses.
+
+
+
+Loughney                     Informational                      [Page 7]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+4.5.5.  Stateful Address Autoconfiguration
+
+   Stateful Address Autoconfiguration MAY be supported.  DHCPv6
+   [RFC-3315] is the standard stateful address configuration protocol;
+   see Section 5.3 for DHCPv6 support.
+
+   Nodes which do not support Stateful Address Autoconfiguration may be
+   unable to obtain any IPv6 addresses, aside from link-local addresses,
+   when it receives a router advertisement with the 'M' flag (Managed
+   address configuration) set and that contains no prefixes advertised
+   for Stateless Address Autoconfiguration (see Section 4.5.2).
+   Additionally, such nodes will be unable to obtain other configuration
+   information, such as the addresses of DNS servers when it is
+   connected to a link over which the node receives a router
+   advertisement in which the 'O' flag ("Other stateful configuration")
+   is set.
+
+4.6.  Multicast Listener Discovery (MLD) for IPv6 - RFC 2710
+
+   Nodes that need to join multicast groups SHOULD implement MLDv2
+   [RFC-3810].  However, if the node has applications that only need
+   support for Any-Source Multicast [RFC-3569], the node MAY implement
+   MLDv1 [RFC-2710] instead.  If the node has applications that need
+   support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node
+   MUST support MLDv2 [RFC-3810].
+
+   When MLD is used, the rules in the "Source Address Selection for the
+   Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
+   followed.
+
+5.  DNS and DHCP
+
+5.1.  DNS
+
+   DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363],
+   and [RFC-3596].  Not all nodes will need to resolve names; those that
+   will never need to resolve DNS names do not need to implement
+   resolver functionality.  However, the ability to resolve names is a
+   basic infrastructure capability that applications rely on and
+   generally needs to be supported.  All nodes that need to resolve
+   names SHOULD implement stub-resolver [RFC-1034] functionality, as in
+   RFC 1034, Section 5.3.1, with support for:
+
+      -  AAAA type Resource Records [RFC-3596];
+
+      -  reverse addressing in ip6.arpa using PTR records [RFC-3152];
+
+
+
+
+
+Loughney                     Informational                      [Page 8]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+      -  EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
+         octets.
+
+   Those nodes are RECOMMENDED to support DNS security extensions
+   [RFC-4033], [RFC-4034], and [RFC-4035].
+
+   Those nodes are NOT RECOMMENDED to support the experimental A6 and
+   DNAME Resource Records [RFC-3363].
+
+5.2.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315
+
+5.2.1.  Managed Address Configuration
+
+   The method by which IPv6 nodes that use DHCP for address assignment
+   can obtain IPv6 addresses and other configuration information upon
+   receipt of a Router Advertisement with the 'M' flag set is described
+   in Section 5.5.3 of RFC 2462.
+
+   In addition, in the absence of a router, those IPv6 nodes that use
+   DHCP for address assignment MUST initiate DHCP to obtain IPv6
+   addresses and other configuration information, as described in
+   Section 5.5.2 of RFC 2462.  Those IPv6 nodes that do not use DHCP for
+   address assignment can ignore the 'M' flag in Router Advertisements.
+
+5.2.2.  Other Configuration Information
+
+   The method by which IPv6 nodes that use DHCP to obtain other
+   configuration information can obtain other configuration information
+   upon receipt of a Router Advertisement with the 'O' flag set is
+   described in Section 5.5.3 of RFC 2462.
+
+   Those IPv6 nodes that use DHCP to obtain other configuration
+   information initiate DHCP for other configuration information upon
+   receipt of a Router Advertisement with the 'O' flag set, as described
+   in Section 5.5.3 of RFC 2462.  Those IPv6 nodes that do not use DHCP
+   for other configuration information can ignore the 'O' flag in Router
+   Advertisements.
+
+   An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to
+   obtain other configuration information.
+
+5.3.3.  Use of Router Advertisements in Managed Environments
+
+   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+   are expected to determine their default router information and on-
+   link prefix information from received Router Advertisements.
+
+
+
+
+
+Loughney                     Informational                      [Page 9]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+6.  IPv4 Support and Transition
+
+   IPv6 nodes MAY support IPv4.
+
+6.1.  Transition Mechanisms
+
+6.1.1.  Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893
+
+   If an IPv6 node implements dual stack and tunneling, then [RFC-4213]
+   MUST be supported.
+
+7.  Mobile IP
+
+   The Mobile IPv6 [RFC-3775] specification defines requirements for the
+   following types of nodes:
+
+      -  mobile nodes
+
+      -  correspondent nodes with support for route optimization
+
+      -  home agents
+
+      -  all IPv6 routers
+
+   Hosts MAY support mobile node functionality described in Section 8.5
+   of [RFC-3775], including support of generic packet tunneling [RFC-
+   2473] and secure home agent communications [RFC-3776].
+
+   Hosts SHOULD support route optimization requirements for
+   correspondent nodes described in Section 8.2 of [RFC-3775].
+
+   Routers SHOULD support the generic mobility-related requirements for
+   all IPv6 routers described in Section 8.3 of [RFC-3775].  Routers MAY
+   support the home agent functionality described in Section 8.4 of
+   [RFC-3775], including support of [RFC-2473] and [RFC-3776].
+
+8.  Security
+
+   This section describes the specification of IPsec for the IPv6 node.
+
+8.1.  Basic Architecture
+
+   Security Architecture for the Internet Protocol [RFC-4301] MUST be
+   supported.
+
+
+
+
+
+
+
+Loughney                     Informational                     [Page 10]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+8.2.  Security Protocols
+
+   ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be supported.
+
+8.3.  Transforms and Algorithms
+
+   Current IPsec RFCs specify the support of transforms and algorithms
+   for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and
+   HMAC-MD5-96.  However, "Cryptographic Algorithm Implementation
+   Requirements For ESP And AH" [RFC-4305] contains the current set of
+   mandatory to implement algorithms for ESP and AH.  It also specifies
+   algorithms that should be implemented because they are likely to be
+   promoted to mandatory at some future time.  IPv6 nodes SHOULD conform
+   to the requirements in [RFC-4305], as well as the requirements
+   specified below.
+
+   Since ESP encryption and authentication are both optional, support
+   for the NULL encryption algorithm [RFC-2410] and the NULL
+   authentication algorithm [RFC-4303] MUST be provided to maintain
+   consistency with the way these services are negotiated.  However,
+   while authentication and encryption can each be NULL, they MUST NOT
+   both be NULL.  The NULL encryption algorithm is also useful for
+   debugging.
+
+   The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported
+   within ESP.  Security issues related to the use of DES are discussed
+   in [DESDIFF], [DESINT], and [DESCRACK].  DES-CBC is still listed as
+   required by the existing IPsec RFCs, but updates to these RFCs will
+   be published in the near future.  DES provides 56 bits of protection,
+   which is no longer considered sufficient.
+
+   The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP
+   MUST be supported.  The use of the HMAC-MD5-96 algorithm [RFC-2403]
+   within AH and ESP MAY also be supported.
+
+   The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the
+   same security issues as DES-CBC, and the 3DES-CBC algorithm within
+   ESP MUST be supported to ensure interoperability.
+
+   The AES-128-CBC algorithm [RFC-3602] MUST also be supported within
+   ESP.  AES-128 is expected to be a widely available, secure, and
+   efficient algorithm.  While AES-128-CBC is not required by the
+   current IPsec RFCs, it is expected to become required in the future.
+
+
+
+
+
+
+
+
+Loughney                     Informational                     [Page 11]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+8.4.  Key Management Methods
+
+   An implementation MUST support the manual configuration of the
+   security key and SPI.  The SPI configuration is needed in order to
+   delineate between multiple keys.
+
+   Key management SHOULD be supported.  Examples of key management
+   systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include
+   key management functions.
+
+   Where key refresh, anti-replay features of AH and ESP, or on-demand
+   creation of Security Associations (SAs) is required, automated keying
+   MUST be supported.
+
+   Key management methods for multicast traffic are also being worked on
+   by the MSEC WG.
+
+9.  Router-Specific Functionality
+
+   This section defines general host considerations for IPv6 nodes that
+   act as routers.  Currently, this section does not discuss routing-
+   specific requirements.
+
+9.1.  General
+
+9.1.1.  IPv6 Router Alert Option - RFC 2711
+
+   The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
+   Hop Header that is used in conjunction with some protocols (e.g.,
+   RSVP [RFC-2205] or MLD [RFC-2710]).  The Router Alert option will
+   need to be implemented whenever protocols that mandate its usage are
+   implemented.  See Section 4.6.
+
+9.1.2.  Neighbor Discovery for IPv6 - RFC 2461
+
+   Sending Router Advertisements and processing Router Solicitation MUST
+   be supported.
+
+10.  Network Management
+
+   Network Management MAY be supported by IPv6 nodes.  However, for IPv6
+   nodes that are embedded devices, network management may be the only
+   possible way of controlling these nodes.
+
+10.1.  Management Information Base Modules (MIBs)
+
+   The following two MIBs SHOULD be supported by nodes that support an
+   SNMP agent.
+
+
+
+Loughney                     Informational                     [Page 12]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+10.1.1.  IP Forwarding Table MIB
+
+   IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that
+   support an SNMP agent.
+
+10.1.2.  Management Information Base for the Internet Protocol (IP)
+
+   IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP
+   agent.
+
+11.  Security Considerations
+
+   This document does not affect the security of the Internet, but
+   implementations of IPv6 are expected to support a minimum set of
+   security features to ensure security on the Internet.  "IP Security
+   Document Roadmap" [RFC-2411] is important for everyone to read.
+
+   The security considerations in RFC 2460 state the following:
+
+      The security features of IPv6 are described in the Security
+      Architecture for the Internet Protocol [RFC-2401].
+
+   RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for
+   the security features of IPv6.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC-1035]     Mockapetris, P., "Domain names - implementation and
+                  specification", STD 13, RFC 1035, November 1987.
+
+   [RFC-1981]     McCann, J., Deering, S., and J. Mogul, "Path MTU
+                  Discovery for IP version 6", RFC 1981, August 1996.
+
+   [RFC-2104]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+                  Keyed-Hashing for Message Authentication", RFC 2104,
+                  February 1997.
+
+   [RFC-2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-2403]     Madson, C. and R. Glenn, "The Use of HMAC-MD5-96
+                  within ESP and AH", RFC 2403, November 1998.
+
+   [RFC-2404]     Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
+                  within ESP and AH", RFC 2404, November 1998.
+
+
+
+
+Loughney                     Informational                     [Page 13]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+   [RFC-2405]     Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
+                  Algorithm With Explicit IV", RFC 2405, November 1998.
+
+   [RFC-2410]     Glenn, R. and S. Kent, "The NULL Encryption Algorithm
+                  and Its Use With IPsec", RFC 2410, November 1998.
+
+   [RFC-2411]     Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
+                  Document Roadmap", RFC 2411, November 1998.
+
+   [RFC-2451]     Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
+                  Algorithms", RFC 2451, November 1998.
+
+   [RFC-2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
+                  6 (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC-2461]     Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+                  Discovery for IP Version 6 (IPv6)", RFC 2461, December
+                  1998.
+
+   [RFC-2462]     Thomson, S. and T. Narten, "IPv6 Stateless Address
+                  Autoconfiguration", RFC 2462, December 1998.
+
+   [RFC-2463]     Conta, A. and S. Deering, "Internet Control Message
+                  Protocol (ICMPv6) for the Internet Protocol Version 6
+                  (IPv6) Specification", RFC 2463, December 1998.
+
+   [RFC-2472]     Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
+                  2472, December 1998.
+
+   [RFC-2473]     Conta, A. and S. Deering, "Generic Packet Tunneling in
+                  IPv6 Specification", RFC 2473, December 1998.
+
+   [RFC-2671]     Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                  2671, August 1999.
+
+   [RFC-2710]     Deering, S., Fenner, W., and B. Haberman, "Multicast
+                  Listener Discovery (MLD) for IPv6", RFC 2710, October
+                  1999.
+
+   [RFC-2711]     Partridge, C. and A. Jackson, "IPv6 Router Alert
+                  Option", RFC 2711, October 1999.
+
+   [RFC-3041]     Narten, T. and R. Draves, "Privacy Extensions for
+                  Stateless Address Autoconfiguration in IPv6", RFC
+                  3041, January 2001.
+
+   [RFC-3152]     Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+                  August 2001.
+
+
+
+Loughney                     Informational                     [Page 14]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+   [RFC-3315]     Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
+                  C., and M. Carney, "Dynamic Host Configuration
+                  Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC-3363]     Bush, R., Durand, A., Fink, B., Gudmundsson, O., and
+                  T. Hain, "Representing Internet Protocol version 6
+                  (IPv6) Addresses in the Domain Name System (DNS)", RFC
+                  3363, August 2002.
+
+   [RFC-3484]     Frye, R., Levi, D., Routhier, S., and B. Wijnen,
+                  "Coexistence between Version 1, Version 2, and Version
+                  3 of the Internet-standard Network Management
+                  Framework", BCP 74, RFC 3584, August 2003.
+
+   [RFC-3513]     Hinden, R. and S. Deering, "Internet Protocol Version
+                  6 (IPv6) Addressing Architecture", RFC 3513, April
+                  2003.
+
+   [RFC-3590]     Haberman, B., "Source Address Selection for the
+                  Multicast Listener Discovery (MLD) Protocol", RFC
+                  3590, September 2003.
+
+   [RFC-3596]     Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+                  "DNS Extensions to Support IP Version 6", RFC 3596,
+                  October 2003.
+
+   [RFC-3602]     Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
+                  Cipher Algorithm and Its Use with IPsec", RFC 3602,
+                  September 2003.
+
+   [RFC-3775]     Johnson, D., Perkins, C., and J. Arkko, "Mobility
+                  Support in IPv6", RFC 3775, June 2004.
+
+   [RFC-3776]     Arkko, J., Devarapalli, V., and F. Dupont, "Using
+                  IPsec to Protect Mobile IPv6 Signaling Between Mobile
+                  Nodes and Home Agents", RFC 3776, June 2004.
+
+   [RFC-3810]     Vida, R. and L. Costa, "Multicast Listener Discovery
+                  Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+   [RFC-3879]     Huitema, C. and B. Carpenter, "Deprecating Site Local
+                  Addresses", RFC 3879, September 2004.
+
+   [RFC-4292]     Haberman, B., "IP Forwarding Table MIB", RFC 4292,
+                  April 2006.
+
+   [RFC-4293]     Routhier, S., Ed., "Management Information Base for
+                  the Internet Protocol (IP)", RFC 4293, April 2006.
+
+
+
+Loughney                     Informational                     [Page 15]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+   [RFC-4301]     Kent, S. and R. Atkinson, "Security Architecture for
+                  the Internet Protocol", RFC 4301, December 2005.
+
+   [RFC-4302]     Kent, S., "IP Authentication Header", RFC 4302,
+                  December 2005.
+
+   [RFC-4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
+                  RFC 4303, December 2005.
+
+   [RFC-4305]     Eastlake 3rd, D., "Cryptographic Algorithm
+                  Implementation Requirements for Encapsulating Security
+                  Payload (ESP) and Authentication Header (AH)", RFC
+                  4305, December 2005.
+
+12.2.  Informative References
+
+   [DESDIFF]      Biham, E., Shamir, A., "Differential Cryptanalysis of
+                  DES-like cryptosystems", Journal of Cryptology Vol 4,
+                  Jan 1991.
+
+   [DESCRACK]     Cracking DES, O'Reilly & Associates, Sebastapol, CA
+                  2000.
+
+   [DESINT]       Bellovin, S., "An Issue With DES-CBC When Used Without
+                  Strong Integrity", Proceedings of the 32nd IETF,
+                  Danvers, MA, April 1995.
+
+   [IPv6-RH]      P. Savola, "Security of IPv6 Routing Header and Home
+                  Address Options", Work in Progress.
+
+   [RFC-793]      Postel, J., "Transmission Control Protocol", STD 7,
+                  RFC 793, September 1981.
+
+   [RFC-1034]     Mockapetris, P., "Domain names - concepts and
+                  facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC-2205]     Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
+                  Jamin, "Resource ReSerVation Protocol (RSVP) --
+                  Version 1 Functional Specification", RFC 2205,
+                  September 1997.
+
+   [RFC-2464]     Crawford, M., "Transmission of IPv6 Packets over
+                  Ethernet Networks", RFC 2464, December 1998.
+
+   [RFC-2492]     Armitage, G., Schulter, P., and M. Jork, "IPv6 over
+                  ATM Networks", RFC 2492, January 1999.
+
+
+
+
+
+Loughney                     Informational                     [Page 16]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+   [RFC-2675]     Borman, D., Deering, S., and R. Hinden, "IPv6
+                  Jumbograms", RFC 2675, August 1999.
+
+   [RFC-4213]     Nordmark, E. and R. Gilligan, "Basic Transition
+                  Mechanisms for IPv6 Hosts and Routers", RFC 4213,
+                  October 2005.
+
+   [RFC-3569]     Bhattacharyya, S., "An Overview of Source-Specific
+                  Multicast (SSM)", RFC 3569, July 2003.
+
+   [RFC-3736]     Droms, R., "Stateless Dynamic Host Configuration
+                  Protocol (DHCP) Service for IPv6", RFC 3736, April
+                  2004.
+
+   [RFC-4001]     Daniele, M., Haberman, B., Routhier, S., and J.
+                  Schoenwaelder, "Textual Conventions for Internet
+                  Network Addresses", RFC 4001, February 2005.
+
+   [RFC-4033]     Arends, R., Austein, R., Larson, M., Massey, D., and
+                  S. Rose, "DNS Security Introduction and Requirements",
+                  RFC 4033, March 2005.
+
+   [RFC-4034]     Arends, R., Austein, R., Larson, M., Massey, D., and
+                  S. Rose, "Resource Records for the DNS Security
+                  Extensions", RFC 4034, March 2005.
+
+   [RFC-4035]     Arends, R., Austein, R., Larson, M., Massey, D., and
+                  S. Rose, "Protocol Modifications for the DNS Security
+                  Extensions", RFC 4035, March 2005.
+
+   [RFC-4306]     Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+                  Protocol", RFC 4306, December 2005.
+
+   [SSM-ARCH]     H. Holbrook, B. Cain, "Source-Specific Multicast for
+                  IP", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney                     Informational                     [Page 17]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+13.  Authors and Acknowledgements
+
+   This document was written by the IPv6 Node Requirements design team:
+
+   Jari Arkko
+   [jari.arkko@ericsson.com]
+
+   Marc Blanchet
+   [marc.blanchet@viagenie.qc.ca]
+
+   Samita Chakrabarti
+   [samita.chakrabarti@eng.sun.com]
+
+   Alain Durand
+   [alain.durand@sun.com]
+
+   Gerard Gastaud
+   [gerard.gastaud@alcatel.fr]
+
+   Jun-ichiro itojun Hagino
+   [itojun@iijlab.net]
+
+   Atsushi Inoue
+   [inoue@isl.rdc.toshiba.co.jp]
+
+   Masahiro Ishiyama
+   [masahiro@isl.rdc.toshiba.co.jp]
+
+   John Loughney
+   [john.loughney@nokia.com]
+
+   Rajiv Raghunarayan
+   [raraghun@cisco.com]
+
+   Shoichi Sakane
+   [shouichi.sakane@jp.yokogawa.com]
+
+   Dave Thaler
+   [dthaler@windows.microsoft.com]
+
+   Juha Wiljakka
+   [juha.wiljakka@Nokia.com]
+
+   The authors would like to thank Ran Atkinson, Jim Bound, Brian
+   Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas
+   Narten, Juha Ollila, and Pekka Savola for their comments.
+
+
+
+
+
+Loughney                     Informational                     [Page 18]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+Editor's Contact Information
+
+   Comments or questions regarding this document should be sent to the
+   IPv6 Working Group mailing list (ipv6@ietf.org) or to:
+
+   John Loughney
+   Nokia Research Center
+   Itamerenkatu 11-13
+   00180 Helsinki
+   Finland
+
+   Phone: +358 50 483 6242
+   EMail: John.Loughney@Nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney                     Informational                     [Page 19]
+
+RFC 4294                 IPv6 Node Requirements               April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Loughney                     Informational                     [Page 20]
+
diff --git a/doc/rfc/rfc4339.txt b/doc/rfc/rfc4339.txt
new file mode 100644
index 000000000000..a6f29d9f4309
--- /dev/null
+++ b/doc/rfc/rfc4339.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                      J. Jeong, Ed.
+Request for Comments: 4339                  ETRI/University of Minnesota
+Category: Informational                                    February 2006
+
+
+      IPv6 Host Configuration of DNS Server Information Approaches
+
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+IESG Note
+
+   This document describes three different approaches for the
+   configuration of DNS name resolution server information in IPv6
+   hosts.
+
+   There is not an IETF consensus on which approach is preferred.  The
+   analysis in this document was developed by the proponents for each
+   approach and does not represent an IETF consensus.
+
+   The 'RA option' and 'Well-known anycast' approaches described in this
+   document are not standardized.  Consequently the analysis for these
+   approaches might not be completely applicable to any specific
+   proposal that might be proposed in the future.
+
+Abstract
+
+   This document describes three approaches for IPv6 recursive DNS
+   server address configuration.  It details the operational attributes
+   of three solutions: RA option, DHCPv6 option, and well-known anycast
+   addresses for recursive DNS servers.  Additionally, it suggests the
+   deployment scenarios in four kinds of networks (ISP, enterprise,
+   3GPP, and unmanaged networks) considering multi-solution resolution.
+
+
+
+
+
+
+
+
+
+
+Jeong                        Informational                      [Page 1]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+   3. IPv6 DNS Configuration Approaches ...............................3
+      3.1. RA Option ..................................................3
+           3.1.1. Advantages ..........................................4
+           3.1.2. Disadvantages .......................................5
+           3.1.3. Observations ........................................5
+      3.2. DHCPv6 Option ..............................................6
+           3.2.1. Advantages ..........................................7
+           3.2.2. Disadvantages .......................................8
+           3.2.3. Observations ........................................9
+      3.3. Well-known Anycast Addresses ...............................9
+           3.3.1. Advantages .........................................10
+           3.3.2. Disadvantages ......................................10
+           3.3.3. Observations .......................................10
+   4. Interworking among IPv6 DNS Configuration Approaches ...........11
+   5. Deployment Scenarios ...........................................12
+      5.1. ISP Network ...............................................12
+           5.1.1. RA Option Approach .................................13
+           5.1.2. DHCPv6 Option Approach .............................13
+           5.1.3. Well-known Anycast Addresses Approach ..............14
+      5.2. Enterprise Network ........................................14
+      5.3. 3GPP Network ..............................................15
+           5.3.1. Currently Available Mechanisms and
+                  Recommendations ....................................15
+           5.3.2. RA Extension .......................................16
+           5.3.3. Stateless DHCPv6 ...................................16
+           5.3.4. Well-known Addresses ...............................17
+           5.3.5. Recommendations ....................................18
+      5.4. Unmanaged Network .........................................18
+           5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18
+           5.4.2. Case B: A Dual-stack Gateway Connected to a
+                  Dual-stack ISP .....................................19
+           5.4.3. Case C: A Dual-stack Gateway Connected to
+                  an IPv4-only ISP ...................................19
+           5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19
+   6. Security Considerations ........................................19
+      6.1. RA Option .................................................20
+      6.2. DHCPv6 Option .............................................21
+      6.3. Well-known Anycast Addresses ..............................21
+   7. Contributors ...................................................21
+   8. Acknowledgements ...............................................23
+   9. References .....................................................23
+      9.1. Normative References ......................................23
+      9.2. Informative References ....................................23
+
+
+
+
+Jeong                        Informational                      [Page 2]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+1.  Introduction
+
+   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
+   Autoconfiguration provide ways to configure either fixed or mobile
+   nodes with one or more IPv6 addresses, default routes, and some other
+   parameters [1][2].  To support the access to additional services in
+   the Internet that are identified by a DNS name, such as a web server,
+   the configuration of at least one recursive DNS server is also needed
+   for DNS name resolution.
+
+   This document describes three approaches of recursive DNS server
+   address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6
+   option [3]-[5], and (c) well-known anycast addresses for recursive
+   DNS servers [7].  Also, it suggests the applicable scenarios for four
+   kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP
+   network, and (d) unmanaged network.
+
+   This document is just an analysis of each possible approach, and it
+   does not recommend a particular approach or combination of
+   approaches.  Some approaches may even not be adopted at all as a
+   result of further discussion.
+
+   Therefore, the objective of this document is to help the audience
+   select the approaches suitable for IPv6 host configuration of
+   recursive DNS servers.
+
+2.  Terminology
+
+   This document uses the terminology described in [1]-[7].  In
+   addition, a new term is defined below:
+
+   o  Recursive DNS Server (RDNSS): Server which provides a recursive
+      DNS resolution service.
+
+3.  IPv6 DNS Configuration Approaches
+
+   In this section, the operational attributes of the three solutions
+   are described in detail.
+
+3.1.  RA Option
+
+   The RA approach defines a new ND option, called the RDNSS option,
+   that contains a recursive DNS server address [6].  Existing ND
+   transport mechanisms (i.e., advertisements and solicitations) are
+   used.  This works in the same way that nodes learn about routers and
+   prefixes.  An IPv6 host can configure the IPv6 addresses of one or
+   more RDNSSes via RA message periodically sent by a router or
+   solicited by a Router Solicitation (RS).
+
+
+
+Jeong                        Informational                      [Page 3]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   This approach needs RDNSS information to be configured in the routers
+   doing the advertisements.  The configuration of RDNSS addresses can
+   be performed manually by an operator or in other ways, such as
+   automatic configuration through a DHCPv6 client running on the
+   router.  An RA message with one RDNSS option can include as many
+   RDNSS addresses as needed [6].
+
+   Through the ND protocol and RDNSS option, along with a prefix
+   information option, an IPv6 host can perform network configuration of
+   its IPv6 address and RDNSS simultaneously [1][2].  The RA option for
+   RDNSS can be used on any network that supports the use of ND.
+
+   The RA approach is useful in some mobile environments where the
+   addresses of the RDNSSes are changing because the RA option includes
+   a lifetime field that allows client to use RDNSSes nearer to the
+   client.  This can be configured to a value that will require the
+   client to time out the entry and switch over to another RDNSS address
+   [6].  However, from the viewpoint of implementation, the lifetime
+   field would seem to make matters a bit more complex.  Instead of just
+   writing to a DNS configuration file, such as resolv.conf for the list
+   of RDNSS addresses, we have to have a daemon around (or a program
+   that is called at the defined intervals) that keeps monitoring the
+   lifetime of RDNSSes all the time.
+
+   The preference value of RDNSS, included in the RDNSS option, allows
+   IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this
+   can be used for the load balancing of RDNSSes.
+
+3.1.1.  Advantages
+
+   The RA option for RDNSS has a number of advantages.  These include:
+
+   1.  The RA option is an extension of existing ND/Autoconfig
+       mechanisms [1][2] and does not require a change in the base ND
+       protocol.
+
+   2.  This approach, like ND, works well on a variety of link types,
+       including point-to-point links, point-to-multipoint, and
+       multipoint-to-multipoint (i.e., Ethernet LANs).  RFC 2461 [1]
+       states, however, that there may be some link types on which ND is
+       not feasible; on such links, some other mechanisms will be needed
+       for DNS configuration.
+
+   3.  All the information a host needs to run the basic Internet
+       applications (such as the email, web, ftp, etc.) can be obtained
+       with the addition of this option to ND and address
+       autoconfiguration.  The use of a single mechanism is more
+       reliable and easier to provide than when the RDNSS information is
+
+
+
+Jeong                        Informational                      [Page 4]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+       learned via another protocol mechanism.  Debugging problems when
+       multiple protocol mechanisms are being used is harder and much
+       more complex.
+
+   4.  This mechanism works over a broad range of scenarios and
+       leverages IPv6 ND.  This works well on links that are high
+       performance (e.g., Ethernet LANs) and low performance (e.g.,
+       cellular networks).  In the latter case, by combining the RDNSS
+       information with the other information in the RA, the host can
+       learn all the information needed to use most Internet
+       applications, such as the web, in a single packet.  This not only
+       saves bandwidth, but also minimizes the delay needed to learn the
+       RDNSS information.
+
+   5.  The RA approach could be used as a model for similar types of
+       configuration information.  New RA options for other server
+       addresses, such as NTP server address, that are common to all
+       clients on a subnet would be easy to define.
+
+3.1.2.  Disadvantages
+
+   1.  ND is mostly implemented in the kernel of the operating system.
+       Therefore, if ND supports the configuration of some additional
+       services, such as DNS servers, ND should be extended in the
+       kernel and complemented by a user-land process.  DHCPv6, however,
+       has more flexibility for the extension of service discovery
+       because it is an application layer protocol.
+
+   2.  The current ND framework should be modified to facilitate the
+       synchronization between another ND cache for RDNSSes in the
+       kernel space and the DNS configuration file in the user space.
+       Because it is unacceptable to write and rewrite to the DNS
+       configuration file (e.g., resolv.conf) from the kernel, another
+       approach is needed.  One simple approach to solve this is to have
+       a daemon listening to what the kernel conveys, and to have the
+       daemon do these steps, but such a daemon is not needed with the
+       current ND framework.
+
+   3.  It is necessary to configure RDNSS addresses at least at one
+       router on every link where this information needs to be
+       configured via the RA option.
+
+3.1.3.  Observations
+
+   The proposed RDNSS RA option, along with the IPv6 ND and
+   Autoconfiguration, allows a host to obtain all of the information it
+   needs to access basic Internet services like the web, email, ftp,
+   etc.  This is preferable in the environments where hosts use RAs to
+
+
+
+Jeong                        Informational                      [Page 5]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   autoconfigure their addresses and all the hosts on the subnet share
+   the same router and server addresses.  If the configuration
+   information can be obtained from a single mechanism, it is preferable
+   because it does not add additional delay, and because it uses a
+   minimum of bandwidth.  Environments like this include homes, public
+   cellular networks, and enterprise environments where no per host
+   configuration is needed.
+
+   DHCPv6 is preferable where it is being used for address configuration
+   and if there is a need for host specific configuration [3]-[5].
+   Environments like this are most likely to be the enterprise
+   environments where the local administration chooses to have per host
+   configuration control.
+
+3.2.  DHCPv6 Option
+
+   DHCPv6 [3] includes the "DNS Recursive Name Server" option, through
+   which a host can obtain a list of IP addresses of recursive DNS
+   servers [5].  The DNS Recursive Name Server option carries a list of
+   IPv6 addresses of RDNSSes to which the host may send DNS queries.
+   The DNS servers are listed in the order of preference for use by the
+   DNS resolver on the host.
+
+   The DNS Recursive Name Server option can be carried in any DHCPv6
+   Reply message, in response to either a Request or an Information
+   request message.  Thus, the DNS Recursive Name Server option can be
+   used either when DHCPv6 is used for address assignment, or when
+   DHCPv6 is used only for other configuration information as stateless
+   DHCPv6 [4].
+
+   Stateless DHCPv6 can be deployed either by using DHCPv6 servers
+   running on general-purpose computers, or on router hardware.  Several
+   router vendors currently implement stateless DHCPv6 servers.
+   Deploying stateless DHCPv6 in routers has the advantage that no
+   special hardware is required, and it should work well for networks
+   where DHCPv6 is needed for very straightforward configuration of
+   network devices.
+
+   However, routers can also act as DHCPv6 relay agents.  In this case,
+   the DHCPv6 server need not be on the router; it can be on a general
+   purpose computer.  This has the potential to give the operator of the
+   DHCPv6 server more flexibility in how the DHCPv6 server responds to
+   individual clients that can easily be given different configuration
+   information based on their identity, or for any other reason.
+   Nothing precludes adding this flexibility to a router, but generally,
+   in current practice, DHCP servers running on general-purpose hosts
+   tend to have more configuration options than those that are embedded
+   in routers.
+
+
+
+Jeong                        Informational                      [Page 6]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
+   clients that use a stateful configuration assignment.  To do this,
+   the DHCPv6 server sends a Reconfigure message to the client.  The
+   client validates the Reconfigure message, and then contacts the
+   DHCPv6 server to obtain updated configuration information.  By using
+   this mechanism, it is currently possible to propagate new
+   configuration information to DHCPv6 clients as this information
+   changes.
+
+   The DHC Working Group has standardized an additional mechanism
+   through which configuration information, including the list of
+   RDNSSes, can be updated.  The lifetime option for DHCPv6 [8] assigns
+   a lifetime to configuration information obtained through DHCPv6.  At
+   the expiration of the lifetime, the host contacts the DHCPv6 server
+   to obtain updated configuration information, including the list of
+   RDNSSes.  This lifetime gives the network administrator another
+   mechanism to configure hosts with new RDNSSes by controlling the time
+   at which the host refreshes the list.
+
+   The DHC Working Group has also discussed the possibility of defining
+   an extension to DHCPv6 that would allow the use of multicast to
+   provide configuration information to multiple hosts with a single
+   DHCPv6 message.  Because of the lack of deployment experience, the WG
+   has deferred consideration of multicast DHCPv6 configuration at this
+   time.  Experience with DHCPv4 has not identified a requirement for
+   multicast message delivery, even in large service provider networks
+   with tens of thousands of hosts that may initiate a DHCPv4 message
+   exchange simultaneously.
+
+3.2.1.  Advantages
+
+   The DHCPv6 option for RDNSS has a number of advantages.  These
+   include:
+
+   1.  DHCPv6 currently provides a general mechanism for conveying
+       network configuration information to clients.  Configuring DHCPv6
+       servers in this way allows the network administrator to configure
+       RDNSSes, the addresses of other network services, and location-
+       specific information, such as time zones.
+
+   2.  As a consequence, when the network administrator goes to
+       configure DHCPv6, all the configuration information can be
+       managed through a single service, typically with a single user
+       interface and a single configuration database.
+
+
+
+
+
+
+
+Jeong                        Informational                      [Page 7]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   3.  DHCPv6 allows for the configuration of a host with information
+       specific to that host, so that hosts on the same link can be
+       configured with different RDNSSes and with other configuration
+       information.
+
+   4.  A mechanism exists for extending DHCPv6 to support the
+       transmission of additional configuration that has not yet been
+       anticipated.
+
+   5.  Hosts that require other configuration information, such as the
+       addresses of SIP servers and NTP servers, are likely to need
+       DHCPv6 for other configuration information.
+
+   6.  The specification for configuration of RDNSSes through DHCPv6 is
+       available as an RFC.  No new protocol extensions (such as new
+       options) are necessary.
+
+   7.  Interoperability among independent implementations has been
+       demonstrated.
+
+3.2.2.  Disadvantages
+
+   The DHCPv6 option for RDNSS has a few disadvantages.  These include:
+
+   1.  Update currently requires a message from server (however, see
+       [8]).
+
+   2.  Because DNS information is not contained in RA messages, the host
+       must receive two messages from the router and must transmit at
+       least one message to the router.  On networks where bandwidth is
+       at a premium, this is a disadvantage, although on most networks
+       it is not a practical concern.
+
+   3.  There is an increased latency for initial configuration.  In
+       addition to waiting for an RA message, the client must now
+       exchange packets with a DHCPv6 server.  Even if it is locally
+       installed on a router, this will slightly extend the time
+       required to configure the client.  For clients that are moving
+       rapidly from one network to another, this will be a disadvantage.
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                        Informational                      [Page 8]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+3.2.3.  Observations
+
+   In the general case, on general-purpose networks, stateless DHCPv6
+   provides significant advantages and no significant disadvantages.
+   Even in the case where bandwidth is at a premium and low latency is
+   desired, if hosts require other configuration information in addition
+   to a list of RDNSSes or if hosts must be configured selectively,
+   those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
+   name server option will be advantageous.
+
+   However, we are aware of some applications where it would be
+   preferable to put the RDNSS information into an RA packet; for
+   example, in a mobile phone network, where bandwidth is at a premium
+   and extremely low latency is desired.  The DNS configuration based on
+   RA should be standardized so as to allow these special applications
+   to be handled using DNS information in the RA packet.
+
+3.3.  Well-known Anycast Addresses
+
+   Anycast uses the same routing system as unicast [9].  However,
+   administrative entities are local ones.  The local entities may
+   accept unicast routes (including default routes) to anycast servers
+   from adjacent entities.  The administrative entities should not
+   advertise their peer routes to their internal anycast servers, if
+   they want to prohibit external access from some peers to the servers.
+   If some advertisement is inevitable (such as the case with default
+   routes), the packets to the servers should be blocked at the boundary
+   of the entities.  Thus, for this anycast, not only unicast routing
+   but also unicast ND protocols can be used as is.
+
+   First of all, the well-known anycast addresses approach is much
+   different from that discussed by the IPv6 Working Group in the past
+   [7].  Note that "anycast" in this memo is simpler than that of RFC
+   1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to
+   have multiple servers on a single link sharing an anycast address.
+   That is, on a link, an anycast address is assumed to be unique.  DNS
+   clients today already have redundancy by having multiple well-known
+   anycast addresses configured as RDNSS addresses.  There is no point
+   in having multiple RDNSSes sharing an anycast address on a single
+   link.
+
+   The approach with well-known anycast addresses is to set multiple
+   well-known anycast addresses in clients' resolver configuration files
+   from the beginning as, say, factory default.  Thus, there is no
+   transport mechanism and no packet format [7].
+
+   An anycast address is an address shared by multiple servers (in this
+   case, the servers are RDNSSes).  A request from a client to the
+
+
+
+Jeong                        Informational                      [Page 9]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   anycast address is routed to a server selected by the routing system.
+   However, it is a bad idea to mandate "site" boundary on anycast
+   addresses, because most users do not have their own servers and want
+   to access their ISPs across their site boundaries.  Larger sites may
+   also depend on their ISPs or may have their own RDNSSes within "site"
+   boundaries.
+
+3.3.1.  Advantages
+
+   The basic advantage of the well-known addresses approach is that it
+   uses no transport mechanism.  Thus, the following apply:
+
+   1.  There is no delay to get the response and no further delay by
+       packet losses.
+
+   2.  The approach can be combined with any other configuration
+       mechanisms, such as the RA-based approach and DHCP-based
+       approach, as well as the factory default configuration.
+
+   3.  The approach works over any environment where DNS works.
+
+   Another advantage is that this approach only needs configuration of
+   the DNS servers as a router (or configuration of a proxy router).
+   Considering that DNS servers do need configuration, the amount of
+   overall configuration effort is proportional to the number of DNS
+   servers and it scales linearly.  Note that, in the simplest case,
+   where a subscriber to an ISP does not have a DNS server, the
+   subscriber naturally accesses DNS servers of the ISP, even though the
+   subscriber and the ISP do nothing and there is no protocol to
+   exchange DNS server information between the subscriber and the ISP.
+
+3.3.2.  Disadvantages
+
+   The well-known anycast addresses approach requires that DNS servers
+   (or routers near to them as a proxy) act as routers to advertise
+   their anycast addresses to the routing system, which requires some
+   configuration (see the last paragraph of the previous section on the
+   scalability of the effort).  In addition, routers at the boundary of
+   the "site" might need the configuration of route filters to prevent
+   providing DNS services for parties outside the "site" and the
+   possibility of denial of service attacks on the internal DNS
+   infrastructure.
+
+3.3.3.  Observations
+
+   If other approaches are used in addition, the well-known anycast
+   addresses should also be set in RA or DHCP configuration files to
+   reduce the configuration effort of users.
+
+
+
+Jeong                        Informational                     [Page 10]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   The redundancy by multiple RDNSSes is better provided by multiple
+   servers with different anycast addresses than by multiple servers
+   sharing the same anycast address, because the former approach allows
+   stale servers to generate routes to their anycast addresses.  Thus,
+   in a routing domain (or domains sharing DNS servers), there will be
+   only one server with an anycast address unless the domain is so large
+   that load distribution is necessary.
+
+   Small ISPs will operate one RDNSS at each anycast address that is
+   shared by all the subscribers.  Large ISPs may operate multiple
+   RDNSSes at each anycast address to distribute and reduce load, where
+   the boundary between RDNSSes may be fixed (redundancy is still
+   provided by multiple addresses) or change dynamically.  DNS packets
+   with the well-known anycast addresses are not expected (though not
+   prohibited) to cross ISP boundaries, as ISPs are expected to be able
+   to take care of themselves.
+
+   Because "anycast" in this memo is simpler than that of RFC 1546 [9]
+   and RFC 3513 [10], where it is assumed to be administratively
+   prohibited to have multiple servers on a single link sharing an
+   anycast address, anycast in this memo should be implemented as
+   UNICAST of RFC 2461 [1] and RFC 3513 [10].  As a result, ND-related
+   instability disappears.  Thus, in the well-known anycast addresses
+   approach, anycast can and should use the anycast address as a source
+   unicast (according to RFC 3513 [10]) address of packets of UDP and
+   TCP responses.  With TCP, if a route flips and packets to an anycast
+   address are routed to a new server, it is expected that the flip is
+   detected by ICMP or sequence number inconsistency, and that the TCP
+   connection is reset and retried.
+
+4.  Interworking among IPv6 DNS Configuration Approaches
+
+   Three approaches can work together for IPv6 host configuration of
+   RDNSS.  This section shows a consideration on how these approaches
+   can interwork.
+
+   For ordering between RA and DHCP approaches, the O (Other stateful
+   configuration) flag in the RA message can be used [6][28].  If no
+   RDNSS option is included, an IPv6 host may perform DNS configuration
+   through DHCPv6 [3]-[5] regardless of whether the O flag is set or
+   not.
+
+   The well-known anycast addresses approach fully interworks with the
+   other approaches.  That is, the other approaches can remove the
+   configuration effort on servers by using the well-known addresses as
+   the default configuration.  Moreover, the clients preconfigured with
+   the well-known anycast addresses can be further configured to use
+   other approaches to override the well-known addresses, if the
+
+
+
+Jeong                        Informational                     [Page 11]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   configuration information from other approaches is available.
+   Otherwise, all the clients need to have the well-known anycast
+   addresses preconfigured.  In order to use the anycast approach along
+   with two other approaches, there are three choices as follows:
+
+   1.  The first choice is that well-known addresses are used as last
+       resort, when an IPv6 host cannot get RDNSS information through RA
+       and DHCP.  The well-known anycast addresses have to be
+       preconfigured in all of IPv6 hosts' resolver configuration files.
+
+   2.  The second is that an IPv6 host can configure well-known
+       addresses as the most preferable in its configuration file even
+       though either an RA option or DHCP option is available.
+
+   3.  The last is that the well-known anycast addresses can be set in
+       RA or DHCP configuration to reduce the configuration effort of
+       users.  According to either the RA or DHCP mechanism, the well-
+       known addresses can be obtained by an IPv6 host.  Because this
+       approach is the most convenient for users, the last option is
+       recommended.
+
+   Note: This section does not necessarily mean that this document
+   suggests adopting all of these three approaches and making them
+   interwork in the way described here.  In fact, as a result of further
+   discussion some approaches may not even be adopted at all.
+
+5.  Deployment Scenarios
+
+   Regarding the DNS configuration on the IPv6 host, several mechanisms
+   are being considered by the DNSOP Working Group, such as RA option,
+   DHCPv6 option, and well-known preconfigured anycast addresses as of
+   today, and this document is a final result from the long thread.  In
+   this section, we suggest four applicable scenarios of three
+   approaches for IPv6 DNS configuration.
+
+   Note: In the applicable scenarios, authors do not implicitly push any
+   specific approaches into the restricted environments.  No enforcement
+   is in each scenario, and all mentioned scenarios are probable.  The
+   main objective of this work is to provide a useful guideline for IPv6
+   DNS configuration.
+
+5.1.  ISP Network
+
+   A characteristic of an ISP network is that multiple Customer Premises
+   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
+   routers and that each PE connects multiple CPE devices to the
+   backbone network infrastructure [11].  The CPEs may be hosts or
+   routers.
+
+
+
+Jeong                        Informational                     [Page 12]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   If the CPE is a router, there is a customer network that is connected
+   to the ISP backbone through the CPE.  Typically, each customer
+   network gets a different IPv6 prefix from an IPv6 PE router, but the
+   same RDNSS configuration will be distributed.
+
+   This section discusses how the different approaches to distributing
+   DNS information are compared in an ISP network.
+
+5.1.1.  RA Option Approach
+
+   When the CPE is a host, the RA option for RDNSS can be used to allow
+   the CPE to get RDNSS information and /64 prefix information for
+   stateless address autoconfiguration at the same time when the host is
+   attached to a new subnet [6].  Because an IPv6 host must receive at
+   least one RA message for stateless address autoconfiguration and
+   router configuration, the host could receive RDNSS configuration
+   information in the RA without the overhead of an additional message
+   exchange.
+
+   When the CPE is a router, the CPE may accept the RDNSS information
+   from the RA on the interface connected to the ISP and copy that
+   information into the RAs advertised in the customer network.
+
+   This approach is more valuable in the mobile host scenario, in which
+   the host must receive at least an RA message for detecting a new
+   network, than in other scenarios generally, although the
+   administrator should configure RDNSS information on the routers.
+   Secure ND [12] can provide extended security when RA messages are
+   used.
+
+5.1.2.  DHCPv6 Option Approach
+
+   DHCPv6 can be used for RDNSS configuration through the use of the DNS
+   option, and can provide other configuration information in the same
+   message with RDNSS configuration [3]-[5].  The DHCPv6 DNS option is
+   already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or
+   stateless DHCP [4] is not nearly as complex as a full DHCPv6
+   implementation.  DHCP is a client-server model protocol, so ISPs can
+   handle user identification on its network intentionally; also,
+   authenticated DHCP [13] can be used for secure message exchange.
+
+   The expected model for deployment of IPv6 service by ISPs is to
+   assign a prefix to each customer, which will be used by the customer
+   gateway to assign a /64 prefix to each network in the customer's
+   network.  Prefix delegation with DHCP (DHCPv6 PD) has already been
+   adopted by ISPs for automating the assignment of the customer prefix
+   to the customer gateway [15].  DNS configuration can be carried in
+   the same DHCPv6 message exchange used for DHCPv6 to provide that
+
+
+
+Jeong                        Informational                     [Page 13]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   information efficiently, along with any other configuration
+   information needed by the customer gateway or customer network.  This
+   service model can be useful to Home or SOHO subscribers.  The Home or
+   SOHO gateway, which is a customer gateway for ISP, can then pass that
+   RDNSS configuration information to the hosts in the customer network
+   through DHCP.
+
+5.1.3.  Well-known Anycast Addresses Approach
+
+   The well-known anycast addresses approach is also a feasible and
+   simple mechanism for ISP [7].  The use of well-known anycast
+   addresses avoids some of the security risks in rogue messages sent
+   through an external protocol such as RA or DHCPv6.  The configuration
+   of hosts for the use of well-known anycast addresses requires no
+   protocol or manual configuration, but the configuration of routing
+   for the anycast addresses requires intervention on the part of the
+   network administrator.  Also, the number of special addresses would
+   be equal to the number of RDNSSes that could be made available to
+   subscribers.
+
+5.2.  Enterprise Network
+
+   An enterprise network is defined as a network that has multiple
+   internal links, one or more router connections to one or more
+   providers, and is actively managed by a network operations entity
+   [14].  An enterprise network can get network prefixes from an ISP by
+   either manual configuration or prefix delegation [15].  In most
+   cases, because an enterprise network manages its own DNS domains, it
+   operates its own DNS servers for the domains.  These DNS servers
+   within enterprise networks process recursive DNS name resolution
+   requests from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
+   enterprise network can be performed as it is in Section 4, in which
+   three approaches can be used together as follows:
+
+   1.  An IPv6 host can decide which approach is or may be used in its
+       subnet with the O flag in RA message [6][28].  As the first
+       choice in Section 4, well-known anycast addresses can be used as
+       a last resort when RDNSS information cannot be obtained through
+       either an RA option or a DHCP option.  This case needs IPv6 hosts
+       to preconfigure the well-known anycast addresses in their DNS
+       configuration files.
+
+   2.  When the enterprise prefers the well-known anycast approach to
+       others, IPv6 hosts should preconfigure the well-known anycast
+       addresses as it is in the first choice.
+
+   3.  The last choice, a more convenient and transparent way, does not
+       need IPv6 hosts to preconfigure the well-known anycast addresses
+
+
+
+Jeong                        Informational                     [Page 14]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+       because the addresses are delivered to IPv6 hosts via either the
+       RA option or DHCPv6 option as if they were unicast addresses.
+       This way is most recommended for the sake of the user's
+       convenience.
+
+5.3.  3GPP Network
+
+   The IPv6 DNS configuration is a missing part of IPv6
+   autoconfiguration and an important part of the basic IPv6
+   functionality in the 3GPP User Equipment (UE).  The higher-level
+   description of the 3GPP architecture can be found in [16], and
+   transition to IPv6 in 3GPP networks is analyzed in [17] and [18].
+
+   In the 3GPP architecture, there is a dedicated link between the UE
+   and the GGSN called the Packet Data Protocol (PDP) Context.  This
+   link is created through the PDP Context activation procedure [19].
+   There is a separate PDP context type for IPv4 and IPv6 traffic.  If a
+   3GPP UE user is communicating by using IPv6 (i.e., by having an
+   active IPv6 PDP context), it cannot be assumed that the user
+   simultaneously has an active IPv4 PDP context, and DNS queries could
+   be done using IPv4.  A 3GPP UE can thus be an IPv6 node, and somehow
+   it needs to discover the address of the RDNSS.  Before IP-based
+   services (e.g., web browsing or e-mail) can be used, the IPv6 (and
+   IPv4) RDNSS addresses need to be discovered in the 3GPP UE.
+
+   Section 5.3.1 briefly summarizes currently available mechanisms in
+   3GPP networks and recommendations. 5.3.2 analyzes the Router
+   Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6
+   mechanism, and 5.3.4 analyzes the well-known addresses approach.
+   Section 5.3.5 summarizes the recommendations.
+
+5.3.1.  Currently Available Mechanisms and Recommendations
+
+   3GPP has defined a mechanism in which RDNSS addresses can be received
+   in the PDP context activation (a control plane mechanism).  That is
+   called the Protocol Configuration Options Information Element (PCO-
+   IE) mechanism [20].  The RDNSS addresses can also be received over
+   the air (using text messages) or typed in manually in the UE.  Note
+   that the two last mechanisms are not very well scalable.  The UE user
+   most probably does not want to type IPv6 RDNSS addresses manually in
+   the user's UE.  The use of well-known addresses is briefly discussed
+   in section 5.3.4.
+
+   It is seen that the mechanisms above most probably are not sufficient
+   for the 3GPP environment.  IPv6 is intended to operate in a zero-
+   configuration manner, no matter what the underlying network
+   infrastructure is.  Typically, the RDNSS address is needed to make an
+   IPv6 node operational, and the DNS configuration should be as simple
+
+
+
+Jeong                        Informational                     [Page 15]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   as the address autoconfiguration mechanism.  Note that there will be
+   additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP-
+   specific DNS configuration mechanisms (such as PCO-IE [20]) do not
+   work for those IP interfaces.  In other words, a good IPv6 DNS
+   configuration mechanism should also work in a multi-access network
+   environment.
+
+   From a 3GPP point of view, the best IPv6 DNS configuration solution
+   is feasible for a very large number of IPv6-capable UEs (even
+   hundreds of millions in one operator's network), is automatic, and
+   thus requires no user action.  It is suggested that a lightweight,
+   stateless mechanism be standardized for use in all network
+   environments.  The solution could then be used for 3GPP, 3GPP2, and
+   other access network technologies.  Thus, not only is a light,
+   stateless IPv6 DNS configuration mechanism needed in 3GPP networks,
+   but also 3GPP networks and UEs would certainly benefit from the new
+   mechanism.
+
+5.3.2.  RA Extension
+
+   Router Advertisement extension [6] is a lightweight IPv6 DNS
+   configuration mechanism that requires minor changes in the 3GPP UE
+   IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
+   the 3GPP architecture) IPv6 stack.  This solution can be specified in
+   the IETF (no action is needed in the 3GPP) and taken in use in 3GPP
+   UEs and GGSNs.
+
+   In this solution, an IPv6-capable UE configures DNS information via
+   an RA message sent by its default router (GGSN); i.e., the RDNSS
+   option for a recursive DNS server is included in the RA message.
+   This solution is easily scalable for a very large number of UEs.  The
+   operator can configure the RDNSS addresses in the GGSN as a part of
+   normal GGSN configuration.  The IPv6 RDNSS address is received in the
+   Router Advertisement, and an extra Round Trip Time (RTT) for asking
+   RDNSS addresses can be avoided.
+
+   When one considers the cons, this mechanism still requires
+   standardization effort in the IETF, and the end nodes and routers
+   need to support this mechanism.  The equipment software update
+   should, however, be pretty straightforward, and new IPv6 equipment
+   could support RA extension already from the beginning.
+
+5.3.3.  Stateless DHCPv6
+
+   A DHCPv6-based solution needs the implementation of Stateless DHCP
+   [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the
+   operator's network.  A possible configuration is such that the GGSN
+   works as a DHCP relay.
+
+
+
+Jeong                        Informational                     [Page 16]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   The pros of a stateless DHCPv6-based solution are:
+
+   1.  Stateless DHCPv6 is a standardized mechanism.
+
+   2.  DHCPv6 can be used for receiving configuration information other
+       than RDNSS addresses; e.g., SIP server addresses.
+
+   3.  DHCPv6 works in different network environments.
+
+   4.  When DHCPv6 service is deployed through a single, centralized
+       server, the RDNSS configuration information can be updated by the
+       network administrator at a single source.
+
+   Some issues with DHCPv6 in 3GPP networks are listed below:
+
+   1.  DHCPv6 requires an additional server in the network unless the
+       (Stateless) DHCPv6 functionality is integrated into an existing
+       router.  This means that there might be one additional server to
+       be maintained.
+
+   2.  DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
+       (3GPP Stateless Address Autoconfiguration is typically used) and
+       is not automatically implemented in 3GPP IPv6 UEs.
+
+   3.  Scalability and reliability of DHCPv6 in very large 3GPP networks
+       (with tens or hundreds of millions of UEs) may be an issue; at
+       least the redundancy needs to be taken care of.  However, if the
+       DHCPv6 service is integrated into the network elements, such as a
+       router operating system, scalability and reliability is
+       comparable with other DNS configuration approaches.
+
+   4.  It is sub-optimal to utilize the radio resources in 3GPP networks
+       for DHCPv6 messages if there is a simpler alternative is
+       available.
+
+       *  The use of stateless DHCPv6 adds one round-trip delay to the
+          case in which the UE can start transmitting data right after
+          the Router Advertisement.
+
+   5.  If the DNS information (suddenly) changes, Stateless DHCPv6
+       cannot automatically update the UE; see [21].
+
+5.3.4.  Well-known Addresses
+
+   Using well-known addresses is also a feasible and light mechanism for
+   3GPP UEs.  Those well-known addresses can be preconfigured in the UE
+   software and the operator can make the corresponding configuration on
+   the network side.  Thus, this is a very easy mechanism for the UE,
+
+
+
+Jeong                        Informational                     [Page 17]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   but it requires some configuration work in the network.  When using
+   well-known addresses, UE forwards queries to any of the preconfigured
+   addresses.  In the current proposal [7], IPv6 anycast addresses are
+   suggested.
+
+   Note: An IPv6 DNS configuration proposal, based on the use of well-
+   known site-local addresses, was developed by the IPv6 Working Group;
+   it was seen as a feasible mechanism for 3GPP UEs, although no IETF
+   consensus was reached on this proposal.  In the end, the deprecation
+   of IPv6 site-local addresses made it impossible to standardize a
+   mechanism that uses site-local addresses as well-known addresses.
+   However, as of this writing, this mechanism is implemented in some
+   operating systems and 3GPP UEs as a last resort of IPv6 DNS
+   configuration.
+
+5.3.5.  Recommendations
+
+   It is suggested that a lightweight, stateless DNS configuration
+   mechanism be specified as soon as possible.  From a 3GPP UE and
+   network point of view, the Router Advertisement-based mechanism looks
+   most promising.  The sooner a light, stateless mechanism is
+   specified, the sooner we can stop using well-known site-local
+   addresses for IPv6 DNS configuration.
+
+5.4.  Unmanaged Network
+
+   There are four deployment scenarios of interest in unmanaged networks
+   [22]:
+
+   1.  A gateway that does not provide IPv6 at all,
+
+   2.  A dual-stack gateway connected to a dual-stack ISP,
+
+   3.  A dual-stack gateway connected to an IPv4-only ISP, and
+
+   4.  A gateway connected to an IPv6-only ISP.
+
+5.4.1.  Case A: Gateway Does Not Provide IPv6 at All
+
+   In this case, the gateway does not provide IPv6; the ISP may or may
+   not provide IPv6.  Automatic or Configured tunnels are the
+   recommended transition mechanisms for this scenario.
+
+   The case where dual-stack hosts behind an NAT need access to an IPv6
+   RDNSS cannot be entirely ruled out.  The DNS configuration mechanism
+   has to work over the tunnel, and the underlying tunneling mechanism
+   could implement NAT traversal.  The tunnel server assumes the role of
+   a relay (for both DHCP and well-known anycast addresses approaches).
+
+
+
+Jeong                        Informational                     [Page 18]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   The RA-based mechanism is relatively straightforward in its
+   operation, assuming the tunnel server is also the IPv6 router
+   emitting RAs.  The well-known anycast addresses approach also seems
+   simple in operation across the tunnel, but the deployment model using
+   well-known anycast addresses in a tunneled environment is unclear or
+   not well understood.
+
+5.4.2.  Case B: A Dual-stack Gateway Connected to a Dual-stack ISP
+
+   This is similar to a typical IPv4 home user scenario, where DNS
+   configuration parameters are obtained using DHCP.  The exception is
+   that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where
+   the DHCP server is stateful (it maintains the state for clients).
+
+5.4.3.  Case C: A Dual-stack Gateway Connected to an IPv4-only ISP
+
+   This is similar to Case B.  If a gateway provides IPv6 connectivity
+   by managing tunnels, then it is also supposed to provide access to an
+   RDNSS.  Like this, the tunnel for IPv6 connectivity originates from
+   the dual-stack gateway instead of from the host.
+
+5.4.4.  Case D: A Gateway Connected to an IPv6-only ISP
+
+   This is similar to Case B.
+
+6.  Security Considerations
+
+   As security requirements depend solely on applications and differ
+   from application to application, there can be no generic requirement
+   defined at the IP or application layer for DNS.
+
+   However, note that cryptographic security requires configured secret
+   information and that full autoconfiguration and cryptographic
+   security are mutually exclusive.  People insisting on secure, full
+   autoconfiguration will get false security, false autoconfiguration,
+   or both.
+
+   In some deployment scenarios [17], where cryptographic security is
+   required for applications, the secret information for the
+   cryptographic security is preconfigured, through which application-
+   specific configuration data, including those for DNS, can be securely
+   configured.  Note that if applications requiring cryptographic
+   security depend on DNS, the applications also require cryptographic
+   security to DNS.  Therefore, the full autoconfiguration of DNS is not
+   acceptable.
+
+   However, with full autoconfiguration, weaker but still reasonable
+   security is being widely accepted and will continue to be acceptable.
+
+
+
+Jeong                        Informational                     [Page 19]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   That is, with full autoconfiguration, which means there is no
+   cryptographic security for the autoconfiguration, it is already
+   assumed that the local environment is secure enough that the
+   information from the local autoconfiguration server has acceptable
+   security even without cryptographic security.  Thus, the
+   communication between the local DNS client and local DNS server has
+   acceptable security.
+
+   In autoconfiguring recursive servers, DNSSEC may be overkill, because
+   DNSSEC [23]-[25] needs the configuration and reconfiguration of
+   clients at root key roll-over [26][27].  Even if additional keys for
+   secure key roll-over are added at the initial configuration, they are
+   as vulnerable as the original keys to some forms of attack, such as
+   social hacking.  Another problem of using DNSSEC and
+   autoconfiguration together is that DNSSEC requires secure time, which
+   means secure communication with autoconfigured time servers, which
+   requires configured secret information.  Therefore, in order that the
+   autoconfiguration may be secure, configured secret information is
+   required.
+
+   If DNSSEC [23]-[25] is used and the signatures are verified on the
+   client host, the misconfiguration of a DNS server may simply be
+   denial of service.  Also, if local routing environment is not
+   reliable, clients may be directed to a false resolver with the same
+   IP address as the true one.
+
+6.1.  RA Option
+
+   The security of RA option for RDNSS is the same as the ND protocol
+   security [1][6].  The RA option does not add any new vulnerability.
+
+   Note that the vulnerability of ND is not worse and is a subset of the
+   attacks that any node attached to a LAN can do independently of ND.
+   A malicious node on a LAN can promiscuously receive packets for any
+   router's MAC address and send packets with the router's MAC address
+   as the source MAC address in the L2 header.  As a result, the L2
+   switches send packets addressed to the router to the malicious node.
+   Also, this attack can send redirects that tell the hosts to send
+   their traffic somewhere else.  The malicious node can send
+   unsolicited RA or NA replies, answer RS or NS requests, etc.  All of
+   this can be done independently of implementing ND.  Therefore, the RA
+   option for RDNSS does not add to the vulnerability.
+
+   Security issues regarding the ND protocol were discussed by the IETF
+   SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for
+   the ND security has been published [12].
+
+
+
+
+
+Jeong                        Informational                     [Page 20]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+6.2.  DHCPv6 Option
+
+   The DNS Recursive Name Server option may be used by an intruder DHCP
+   server to cause DHCP clients to send DNS queries to an intruder DNS
+   recursive name server [5].  The results of these misdirected DNS
+   queries may be used to spoof DNS names.
+
+   To avoid attacks through the DNS Recursive Name Server option, the
+   DHCP client SHOULD require DHCP authentication (see "Authentication
+   of DHCP messages" in RFC 3315 [3][13]) before installing a list of
+   DNS recursive name servers obtained through authenticated DHCP.
+
+6.3.  Well-known Anycast Addresses
+
+   The well-known anycast addresses approach is not a protocol, thus
+   there is no need to secure the protocol itself.
+
+   However, denial of service attacks on the DNS resolver system might
+   be easier to achieve as the anycast addresses used are by definition
+   well known.
+
+7.  Contributors
+
+   Ralph Droms
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxboro, MA  01719
+   US
+
+   Phone: +1 978 936 1674
+   EMail: rdroms@cisco.com
+
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA  94043
+   US
+
+   Phone: +1 650 625 2004
+   EMail: bob.hinden@nokia.com
+
+
+
+
+
+
+
+
+
+
+Jeong                        Informational                     [Page 21]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   Ted Lemon
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA  94043
+   US
+
+   EMail: Ted.Lemon@nominum.com
+
+   Masataka Ohta
+   Tokyo Institute of Technology
+   2-12-1, O-okayama, Meguro-ku
+   Tokyo  152-8552
+   Japan
+
+   Phone: +81 3 5734 3299
+   Fax:   +81 3 5734 3299
+   EMail: mohta@necom830.hpcl.titech.ac.jp
+
+
+   Soohong Daniel Park
+   Mobile Platform Laboratory, SAMSUNG Electronics
+   416 Maetan-3dong, Yeongtong-Gu
+   Suwon, Gyeonggi-Do  443-742
+   Korea
+
+   Phone: +82 31 200 4508
+   EMail: soohong.park@samsung.com
+
+
+   Suresh Satapati
+   Cisco Systems, Inc.
+   San Jose, CA  95134
+   US
+
+   EMail: satapati@cisco.com
+
+
+   Juha Wiljakka
+   Nokia
+   Visiokatu 3
+   FIN-33720, TAMPERE
+   Finland
+
+   Phone: +358 7180 48372
+   EMail: juha.wiljakka@nokia.com
+
+
+
+
+
+
+Jeong                        Informational                     [Page 22]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+8.  Acknowledgements
+
+   This document has greatly benefited from inputs by David Meyer, Rob
+   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
+   Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
+   Also, Tony Bonanno proofread this document.  The authors appreciate
+   their contribution.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+        for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+   [2]  Thomson, S. and T. Narten, "IPv6 Stateless Address
+        Autoconfiguration", RFC 2462, December 1998.
+
+   [3]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+        RFC 3315, July 2003.
+
+   [4]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
+        Service for IPv6", RFC 3736, April 2004.
+
+   [5]  Droms, R., "DNS Configuration options for Dynamic Host
+        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
+        2003.
+
+9.2.  Informative References
+
+   [6]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6
+        Router Advertisement Option for DNS Configuration", Work in
+        Progress, September 2005.
+
+   [7]  Ohta, M., "Preconfigured DNS Server Addresses", Work in
+        Progress, February 2004.
+
+   [8]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
+        Option for Dynamic Host Configuration Protocol for IPv6
+        (DHCPv6)", RFC 4242, November 2005.
+
+   [9]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
+        Service", RFC 1546, November 1993.
+
+   [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+        Addressing Architecture", RFC 3513, April 2003.
+
+
+
+
+Jeong                        Informational                     [Page 23]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   [11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola,
+        "Scenarios and Analysis for Introducing IPv6 into ISP Networks",
+        RFC 4029, March 2005.
+
+   [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
+        Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+   [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
+        RFC 3118, June 2001.
+
+   [14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June
+        2005.
+
+   [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
+        Configuration Protocol (DHCP) version 6", RFC 3633, December
+        2003.
+
+   [16] Wasserman, M., "Recommendations for IPv6 in Third Generation
+        Partnership Project (3GPP) Standards", RFC 3314, September 2002.
+
+   [17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC
+        3574, August 2003.
+
+   [18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation
+        Partnership Project (3GPP) Networks", RFC 4215, October 2005.
+
+   [19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
+        Service description; Stage 2 (Release 5)", December 2002.
+
+   [20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
+        specification; Core network protocols; Stage 3 (Release 5)",
+        June 2003.
+
+   [21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
+        Requirements for Stateless Dynamic Host Configuration Protocol
+        for IPv6 (DHCPv6)", RFC 4076, May 2005.
+
+   [22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
+        "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April
+        2004.
+
+   [23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033, March
+        2005.
+
+   [24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+
+
+Jeong                        Informational                     [Page 24]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   [25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions", RFC
+        4035, March 2005.
+
+   [26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work
+        in Progress, October 2005.
+
+   [27] Guette, G. and O. Courtay, "Requirements for Automated Key
+        Rollover in DNSSEC", Work in Progress, January 2005.
+
+   [28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
+        and O Flags of IPv6 Router Advertisement", Work in Progress,
+        March 2005.
+
+Author's Address
+
+   Jaehoon Paul Jeong (editor)
+   ETRI/Department of Computer Science and Engineering
+   University of Minnesota
+   117 Pleasant Street SE
+   Minneapolis, MN  55455
+   US
+
+   Phone: +1 651 587 7774
+   Fax:   +1 612 625 2002
+   EMail: jjeong@cs.umn.edu
+   URI:   http://www.cs.umn.edu/~jjeong/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                        Informational                     [Page 25]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Jeong                        Informational                     [Page 26]
+
diff --git a/doc/rfc/rfc4471.txt b/doc/rfc/rfc4471.txt
new file mode 100644
index 000000000000..eb338e6b5edf
--- /dev/null
+++ b/doc/rfc/rfc4471.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                          G. Sisson
+Request for Comments: 4471                                     B. Laurie
+Category: Experimental                                           Nominet
+                                                          September 2006
+
+
+            Derivation of DNS Name Predecessor and Successor
+
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes two methods for deriving the canonically-
+   ordered predecessor and successor of a DNS name.  These methods may
+   be used for dynamic NSEC resource record synthesis, enabling
+   security-aware name servers to provide authenticated denial of
+   existence without disclosing other owner names in a DNSSEC secured
+   zone.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Notational Conventions ..........................................3
+   3. Derivations .....................................................3
+      3.1. Absolute Method ............................................3
+           3.1.1. Derivation of DNS Name Predecessor ..................3
+           3.1.2. Derivation of DNS Name Successor ....................4
+      3.2. Modified Method ............................................4
+           3.2.1. Derivation of DNS Name Predecessor ..................5
+           3.2.2. Derivation of DNS Name Successor ....................6
+   4. Notes ...........................................................6
+      4.1. Test for Existence .........................................6
+      4.2. Case Considerations ........................................7
+      4.3. Choice of Range ............................................7
+      4.4. Wild Card Considerations ...................................8
+      4.5. Possible Modifications .....................................8
+           4.5.1. Restriction of Effective Maximum DNS Name Length ....8
+           4.5.2. Use of Modified Method with Zones Containing
+
+
+
+Sisson & Laurie               Experimental                      [Page 1]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+                  SRV RRs .............................................8
+   5. Examples ........................................................9
+      5.1. Examples of Immediate Predecessors Using Absolute Method ..10
+      5.2. Examples of Immediate Successors Using Absolute Method ....14
+      5.3. Examples of Predecessors Using Modified Method ............19
+      5.4. Examples of Successors Using Modified Method ..............20
+   6. Security Considerations ........................................21
+   7. Acknowledgements ...............................................21
+   8. References .....................................................21
+      8.1. Normative References ......................................21
+      8.2. Informative References ....................................22
+
+1.  Introduction
+
+   One of the proposals for avoiding the exposure of zone information
+   during the deployment DNSSEC is dynamic NSEC resource record (RR)
+   synthesis.  This technique is described in [DNSSEC-TRANS] and
+   [RFC4470], and involves the generation of NSEC RRs that just span the
+   query name for non-existent owner names.  In order to do this, the
+   DNS names that would occur just prior to and just following a given
+   query name must be calculated in real time, as maintaining a list of
+   all possible owner names that might occur in a zone would be
+   impracticable.
+
+   Section 6.1 of [RFC4034] defines canonical DNS name order.  This
+   document does not amend or modify this definition.  However, the
+   derivation of immediate predecessor and successor, although trivial,
+   is non-obvious.  Accordingly, several methods are described here as
+   an aid to implementors and a reference to other interested parties.
+
+   This document describes two methods:
+
+   1.  An "absolute method", which returns the immediate predecessor or
+       successor of a domain name such that no valid DNS name could
+       exist between that DNS name and the predecessor or successor.
+
+   2.  A "modified method", which returns a predecessor and successor
+       that are more economical in size and computation.  This method is
+       restricted to use with zones consisting exclusively of owner
+       names that contain no more than one label more than the owner
+       name of the apex, where the longest possible owner name (i.e.,
+       one with a maximum length left-most label) would not exceed the
+       maximum DNS name length.  This is, however, the type of zone for
+       which the technique of online signing is most likely to be used.
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                      [Page 2]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+2.  Notational Conventions
+
+   The following notational conventions are used in this document for
+   economy of expression:
+
+   N: An unspecified DNS name.
+
+   P(N): Immediate predecessor to N (absolute method).
+
+   S(N): Immediate successor to N (absolute method).
+
+   P'(N): Predecessor to N (modified method).
+
+   S'(N): Successor to N (modified method).
+
+3.  Derivations
+
+   These derivations assume that all uppercase US-ASCII letters in N
+   have already been replaced by their corresponding lowercase
+   equivalents.  Unless otherwise specified, processing stops after the
+   first step in which a condition is met.
+
+   The derivations make reference to maximum label length and maximum
+   DNS name length; these are defined in Section 3.1 of [RFC1034] to be
+   63 and 255 octets, respectively.
+
+3.1.  Absolute Method
+
+3.1.1.  Derivation of DNS Name Predecessor
+
+   To derive P(N):
+
+   1.  If N is the same as the owner name of the zone apex, prepend N
+       repeatedly with labels of the maximum length possible consisting
+       of octets of the maximum sort value (e.g., 0xff) until N is the
+       maximum length possible; otherwise proceed to the next step.
+
+   2.  If the least significant (left-most) label of N consists of a
+       single octet of the minimum sort value (e.g., 0x00), remove that
+       label; otherwise proceed to the next step.
+
+   3.  If the least significant (right-most) octet in the least
+       significant (left-most) label of N is the minimum sort value,
+       remove the least significant octet and proceed to step 5.
+
+   4.  Decrement the value of the least significant (right-most) octet
+       of the least significant (left-most) label, skipping any values
+       that correspond to uppercase US-ASCII letters, and then append
+
+
+
+Sisson & Laurie               Experimental                      [Page 3]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+       the least significant (left-most) label with as many octets as
+       possible of the maximum sort value.  Proceed to the next step.
+
+   5.  Prepend N repeatedly with labels of as long a length as possible
+       consisting of octets of the maximum sort value until N is the
+       maximum length possible.
+
+3.1.2.  Derivation of DNS Name Successor
+
+   To derive S(N):
+
+   1.  If N is two or more octets shorter than the maximum DNS name
+       length, prepend N with a label containing a single octet of the
+       minimum sort value (e.g., 0x00); otherwise proceed to the next
+       step.
+
+   2.  If N is one octet shorter than the maximum DNS name length and
+       the least significant (left-most) label is one or more octets
+       shorter than the maximum label length, append an octet of the
+       minimum sort value to the least significant label; otherwise
+       proceed to the next step.
+
+   3.  Increment the value of the least significant (right-most) octet
+       in the least significant (left-most) label that is less than the
+       maximum sort value (e.g., 0xff), skipping any values that
+       correspond to uppercase US-ASCII letters, and then remove any
+       octets to the right of that one.  If all octets in the label are
+       the maximum sort value, then proceed to the next step.
+
+   4.  Remove the least significant (left-most) label.  Unless N is now
+       the same as the owner name of the zone apex (this will occur only
+       if N was the maximum possible name in canonical DNS name order,
+       and thus has wrapped to the owner name of zone apex), repeat
+       starting at step 2.
+
+3.2.  Modified Method
+
+   This method is for use with zones consisting only of single-label
+   owner names where an owner name consisting of label of maximum length
+   would not result in a DNS name that exceeded the maximum DNS name
+   length.  This method is computationally simpler and returns values
+   that are more economical in size than the absolute method.  It
+   differs from the absolute method detailed above in the following
+   ways:
+
+   1.  Step 1 of the derivation P(N) has been omitted as the existence
+       of the owner name of the zone apex never requires denial.
+
+
+
+
+Sisson & Laurie               Experimental                      [Page 4]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   2.  A new step 1 has been introduced that removes unnecessary labels.
+
+   3.  Step 4 of the derivation P(N) has been omitted as it is only
+       necessary for zones containing owner names consisting of more
+       than one label.  This omission generally results in a significant
+       reduction of the length of derived predecessors.
+
+   4.  Step 1 of the derivation S(N) had been omitted as it is only
+       necessary for zones containing owner names consisting of more
+       than one label.  This omission results in a tiny reduction of the
+       length of derived successors, and maintains consistency with the
+       modification of step 4 of the derivation P(N) described above.
+
+   5.  Steps 2 and 4 of the derivation S(N) have been modified to
+       eliminate checks for maximum DNS name length, as it is an
+       assumption of this method that no DNS name in the zone can exceed
+       the maximum DNS name length.
+
+3.2.1.  Derivation of DNS Name Predecessor
+
+   To derive P'(N):
+
+   1.  If N is two or more labels longer than the owner name of the
+       apex, repeatedly remove the least significant (left-most) label
+       until N is only one label longer than the owner name of the apex;
+       otherwise proceed to the next step.
+
+   2.  If the least significant (left-most) label of N consists of a
+       single octet of the minimum sort value (e.g., 0x00), remove that
+       label; otherwise proceed to the next step.  (If this condition is
+       met, P'(N) is the owner name of the apex.)
+
+   3.  If the least significant (right-most) octet in the least
+       significant (left-most) label of N is the minimum sort value,
+       remove the least significant octet.
+
+   4.  Decrement the value of the least significant (right-most) octet,
+       skipping any values that correspond to uppercase US-ASCII
+       letters, and then append the label with as many octets as
+       possible of the maximum sort value.
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                      [Page 5]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+3.2.2.  Derivation of DNS Name Successor
+
+   To derive S'(N):
+
+   1.  If N is two or more labels longer than the owner name of the
+       apex, repeatedly remove the least significant (left-most) label
+       until N is only one label longer than the owner name of the apex.
+       Proceed to the next step.
+
+   2.  If the least significant (left-most) label of N is one or more
+       octets shorter than the maximum label length, append an octet of
+       the minimum sort value to the least significant label; otherwise
+       proceed to the next step.
+
+   3.  Increment the value of the least significant (right-most) octet
+       in the least significant (left-most) label that is less than the
+       maximum sort value (e.g., 0xff), skipping any values that
+       correspond to uppercase US-ASCII letters, and then remove any
+       octets to the right of that one.  If all octets in the label are
+       the maximum sort value, then proceed to the next step.
+
+   4.  Remove the least significant (left-most) label.  (This will occur
+       only if the least significant label is the maximum label length
+       and consists entirely of octets of the maximum sort value, and
+       thus has wrapped to the owner name of the zone apex.)
+
+4.  Notes
+
+4.1.  Test for Existence
+
+   Before using the result of P(N) or P'(N) as the owner name of an NSEC
+   RR in a DNS response, a name server should test to see whether the
+   name exists.  If it does, either a standard non-synthesised NSEC RR
+   should be used, or the synthesised NSEC RR should reflect the RRset
+   types that exist at the NSEC RR's owner name in the Type Bit Map
+   field as specified by Section 4.1.2 of [RFC4034].  Implementors will
+   likely find it simpler to use a non-synthesised NSEC RR.  For further
+   details, see Section 2 of [RFC4470].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                      [Page 6]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+4.2.  Case Considerations
+
+   Section 3.5 of [RFC1034] specifies that "while upper and lower case
+   letters are allowed in names, no significance is attached to the
+   case".  Additionally, Section 6.1 of [RFC4034] states that when
+   determining canonical DNS name order, "uppercase US-ASCII letters are
+   treated as if they were lowercase US-ASCII letters".  Consequently,
+   values corresponding to US-ASCII uppercase letters must be skipped
+   when decrementing and incrementing octets in the derivations
+   described in Section 3.
+
+   The following pseudo-code is illustrative:
+
+   Decrement the value of an octet:
+
+      if (octet == '[')       // '[' is just after uppercase 'Z'
+              octet = '@';    // '@' is just prior to uppercase 'A'
+      else
+              octet--;
+
+   Increment the value of an octet:
+
+      if (octet == '@')       // '@' is just prior to uppercase 'A'
+              octet = '[';    // '[' is just after uppercase 'Z'
+      else
+              octet++;
+
+4.3.  Choice of Range
+
+   [RFC2181] makes the clarification that "any binary string whatever
+   can be used as the label of any resource record".  Consequently, the
+   minimum sort value may be set as 0x00 and the maximum sort value as
+   0xff, and the range of possible values will be any DNS name that
+   contains octets of any value other than those corresponding to
+   uppercase US-ASCII letters.
+
+   However, if all owner names in a zone are in the letter-digit-hyphen,
+   or LDH, format specified in [RFC1034], it may be desirable to
+   restrict the range of possible values to DNS names containing only
+   LDH values.  This has the effect of
+
+   1.  making the output of tools such as `dig' and `nslookup' less
+       subject to confusion,
+
+   2.  minimising the impact that NSEC RRs containing DNS names with
+       non-LDH values (or non-printable values) might have on faulty DNS
+       resolver implementations, and
+
+
+
+
+Sisson & Laurie               Experimental                      [Page 7]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   3.  preventing the possibility of results that are wildcard DNS names
+       (see Section 4.4).
+
+   This may be accomplished by using a minimum sort value of 0x1f (US-
+   ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
+   character lowercase `z'), and then skipping non-LDH, non-lowercase
+   values when incrementing or decrementing octets.
+
+4.4.  Wild Card Considerations
+
+   Neither derivation avoids the possibility that the result may be a
+   DNS name containing a wildcard label, i.e., a label containing a
+   single octet with the value 0x2a (US-ASCII character `*').  With
+   additional tests, wildcard DNS names may be explicitly avoided;
+   alternatively, if the range of octet values can be restricted to
+   those corresponding to letter-digit-hyphen, or LDH, characters (see
+   Section 4.3), such DNS names will not occur.
+
+   Note that it is improbable that a result that is a wildcard DNS name
+   will occur unintentionally; even if one does occur either as the
+   owner name of, or in the RDATA of an NSEC RR, it is treated as a
+   literal DNS name with no special meaning.
+
+4.5.  Possible Modifications
+
+4.5.1.  Restriction of Effective Maximum DNS Name Length
+
+   [RFC1034] specifies that "the total number of octets that represent a
+   name (i.e., the sum of all label octets and label lengths) is limited
+   to 255", including the null (zero-length) label that represents the
+   root.  For the purpose of deriving predecessors and successors during
+   NSEC RR synthesis, the maximum DNS name length may be effectively
+   restricted to the length of the longest DNS name in the zone.  This
+   will minimise the size of responses containing synthesised NSEC RRs
+   but, especially in the case of the modified method, may result in
+   some additional computational complexity.
+
+   Note that this modification will have the effect of revealing
+   information about the longest name in the zone.  Moreover, when the
+   contents of the zone changes, e.g., during dynamic updates and zone
+   transfers, care must be taken to ensure that the effective maximum
+   DNS name length agrees with the new contents.
+
+4.5.2.  Use of Modified Method with Zones Containing SRV RRs
+
+   Normally, the modified method cannot be used in zones that contain
+   Service Record (SRV) RRs [RFC2782], as SRV RRs have owner names that
+   contain multiple labels.  However, the use of SRV RRs can be
+
+
+
+Sisson & Laurie               Experimental                      [Page 8]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   accommodated by various techniques.  There are at least four possible
+   ways to do this:
+
+   1.  Use conventional NSEC RRs for the region of the zone that
+       contains first-level labels beginning with the underscore (`_')
+       character.  For the purposes of generating these NSEC RRs, the
+       existence of (possibly fictional) ownernames `9{63}' and `a'
+       could be assumed, providing a lower and upper bound for this
+       region.  Then all queries where the QNAME does not exist but
+       contains a first-level label beginning with an underscore could
+       be handled using the normal DNSSEC protocol.
+
+       This approach would make it possible to enumerate all DNS names
+       in the zone containing a first-level label beginning with
+       underscore, including all SRV RRs, but this may be of less a
+       concern to the zone administrator than incurring the overhead of
+       the absolute method or of the following variants of the modified
+       method.
+
+   2.  The absolute method could be used for synthesising NSEC RRs for
+       all queries where the QNAME contains a leading underscore.
+       However, this re-introduces the susceptibility of the absolute
+       method to denial of service activity, as an attacker could send
+       queries for an effectively inexhaustible supply of domain names
+       beginning with a leading underscore.
+
+   3.  A variant of the modified method could be used for synthesising
+       NSEC RRs for all queries where the QNAME contains a leading
+       underscore.  This variant would assume that all predecessors and
+       successors to queries where the QNAME contains a leading
+       underscore may consist of two labels rather than only one.  This
+       introduces a little additional complexity without incurring the
+       full increase in response size and computational complexity as
+       the absolute method.
+
+   4.  Finally, a variant of the modified method that assumes that all
+       owner names in the zone consist of one or two labels could be
+       used.  However, this negates much of the reduction in response
+       size of the modified method and may be nearly as computationally
+       complex as the absolute method.
+
+5.  Examples
+
+   In the following examples,
+
+      the owner name of the zone apex is "example.com.",
+
+
+
+
+
+Sisson & Laurie               Experimental                      [Page 9]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+      the range of octet values is 0x00 - 0xff excluding values
+      corresponding to uppercase US-ASCII letters, and
+
+      non-printable octet values are expressed as three-digit decimal
+      numbers preceded by a backslash (as specified in Section 5.1 of
+      [RFC1035]).
+
+5.1.  Examples of Immediate Predecessors Using Absolute Method
+
+   Example of a typical case:
+
+      P(foo.example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.fon\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
+
+      where {n} represents the number of repetitions of an octet.
+
+   Example where least significant (left-most) label of DNS name
+   consists of a single octet of the minimum sort value:
+
+      P(\000.foo.example.com.) = foo.example.com.
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 10]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   Example where least significant (right-most) octet of least
+   significant (left-most) label has the minimum sort value:
+
+      P(foo\000.example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.foo.example.com.
+
+      or, in alternate notation:
+
+           \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 11]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   Example where DNS name contains an octet that must be decremented by
+   skipping values corresponding to US-ASCII uppercase letters:
+
+      P(fo\[.example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.fo\@\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
+
+      where {n} represents the number of repetitions of an octet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 12]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   Example where DNS name is the owner name of the zone apex, and
+   consequently wraps to the DNS name with the maximum possible sort
+   order in the zone:
+
+      P(example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 13]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+5.2.  Examples of Immediate Successors Using Absolute Method
+
+   Example of typical case:
+
+      S(foo.example.com.) = \000.foo.example.com.
+
+   Example where DNS name is one octet short of the maximum DNS name
+   length:
+
+      N =  fooooooooooooooooooooooooooooooooooooooooooooooo
+           .ooooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooo.ooooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooo.ooooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooooooooooo
+           \000.ooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooooo.ooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooooo.ooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}\000.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 14]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   Example where DNS name is the maximum DNS name length:
+
+      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
+           o.oooooooooooooooooooooooooooooooooooooooooooooo
+           ooooooooooooooooo.oooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooooo.oooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           o.example.com.
+
+      or, in alternate notation:
+
+           fo{48}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooooooooooo
+           p.oooooooooooooooooooooooooooooooooooooooooooooo
+           ooooooooooooooooo.oooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooooo.oooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           o.example.com.
+
+      or, in alternate notation:
+
+           fo{47}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 15]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   Example where DNS name is the maximum DNS name length and the least
+   significant (left-most) label has the maximum sort value:
+
+      N =  \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.ooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooooo.ooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooooo.ooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooo.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooop.oooooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooo.oooooooooooooooo
+           ooooooooooooooooooooooooooooooooooooooooooooooo.
+           example.com.
+
+      or, in alternate notation:
+
+           o{62}p.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 16]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   Example where DNS name is the maximum DNS name length and the eight
+   least significant (right-most) octets of the least significant
+   (left-most) label have the maximum sort value:
+
+      N  = foooooooooooooooooooooooooooooooooooooooo\255
+           \255\255\255\255\255\255\255.ooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooo.ooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooo.ooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooo.example.com.
+
+      or, in alternate notation:
+
+           fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooop.oooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           ooooooooo.oooooooooooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooo.oooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+      or, in alternate notation:
+
+           fo{39}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 17]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   Example where DNS name is the maximum DNS name length and contains an
+   octet that must be incremented by skipping values corresponding to
+   US-ASCII uppercase letters:
+
+      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
+           \@.ooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooo.ooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooo.ooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}\@.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooooooooooo
+           \[.ooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooo.ooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooo.ooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}\[.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 18]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   Example where DNS name has the maximum possible sort order in the
+   zone, and consequently wraps to the owner name of the zone apex:
+
+      N  = \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+      S(N) = example.com.
+
+5.3.  Examples of Predecessors Using Modified Method
+
+   Example of a typical case:
+
+      P'(foo.example.com.) =
+
+           fon\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.example.com.
+
+      or, in alternate notation:
+
+           fon\255{60}.example.com.
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 19]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+   Example where DNS name contains more labels than DNS names in the
+   zone:
+
+      P'(bar.foo.example.com.) = foo.example.com.
+
+   Example where least significant (right-most) octet of least
+   significant (left-most) label has the minimum sort value:
+
+      P'(foo\000.example.com.) = foo.example.com.
+
+   Example where least significant (left-most) label has the minimum
+   sort value:
+
+      P'(\000.example.com.) = example.com.
+
+   Example where DNS name is the owner name of the zone apex, and
+   consequently wraps to the DNS name with the maximum possible sort
+   order in the zone:
+
+      P'(example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{63}.example.com.
+
+5.4.  Examples of Successors Using Modified Method
+
+   Example of a typical case:
+
+      S'(foo.example.com.) = foo\000.example.com.
+
+   Example where DNS name contains more labels than DNS names in the
+   zone:
+
+      S'(bar.foo.example.com.) = foo\000.example.com.
+
+
+   Example where least significant (left-most) label has the maximum
+   sort value, and consequently wraps to the owner name of the zone
+   apex:
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 20]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+      N  = \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{63}.example.com.
+
+      S'(N) = example.com.
+
+6.  Security Considerations
+
+   The derivation of some predecessors/successors requires the testing
+   of more conditions than others.  Consequently, the effectiveness of a
+   denial-of-service attack may be enhanced by sending queries that
+   require more conditions to be tested.  The modified method involves
+   the testing of fewer conditions than the absolute method and
+   consequently is somewhat less susceptible to this exposure.
+
+7.  Acknowledgements
+
+   The authors would like to thank Sam Weiler, Olaf Kolkman, Olafur
+   Gudmundsson, and Niall O'Reilly for their review and input.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1034]      Mockapetris, P., "Domain names - concepts and
+                  facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]      Mockapetris, P., "Domain names - implementation and
+                  specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2181]      Elz, R. and R. Bush, "Clarifications to the DNS
+                  Specification", RFC 2181, July 1997.
+
+   [RFC2782]      Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
+                  for specifying the location of services (DNS SRV)",
+                  RFC 2782, February 2000.
+
+   [RFC4034]      Arends, R., Austein, R., Larson, M., Massey, D., and
+                  S. Rose, "Resource Records for the DNS Security
+                  Extensions", RFC 4034, March 2005.
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 21]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+8.2.  Informative References
+
+   [RFC4470]      Weiler, S. and J. Ihren, "Minimally Covering NSEC
+                  Records and DNSSEC On-line Signing", RFC 4470, April
+                  2006.
+
+   [DNSSEC-TRANS] Arends, R., Koch, P., and J. Schlyter, "Evaluating
+                  DNSSEC Transition Mechanisms", Work in Progress,
+                  February 2005.
+
+Authors' Addresses
+
+   Geoffrey Sisson
+   Nominet
+   Sandford Gate
+   Sandy Lane West
+   Oxford
+   OX4 6LB
+   GB
+
+   Phone: +44 1865 332211
+   EMail: geoff@nominet.org.uk
+
+
+   Ben Laurie
+   Nominet
+   17 Perryn Road
+   London
+   W3 7LR
+   GB
+
+   Phone: +44 20 8735 0686
+   EMail: ben@algroup.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 22]
+
+RFC 4471           DNS Name Predecessor and Successor     September 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sisson & Laurie               Experimental                     [Page 23]
+
diff --git a/doc/rfc/rfc4472.txt b/doc/rfc/rfc4472.txt
new file mode 100644
index 000000000000..b396e9a11a55
--- /dev/null
+++ b/doc/rfc/rfc4472.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                          A. Durand
+Request for Comments: 4472                                       Comcast
+Category: Informational                                         J. Ihren
+                                                              Autonomica
+                                                               P. Savola
+                                                               CSC/FUNET
+                                                              April 2006
+
+
+          Operational Considerations and Issues with IPv6 DNS
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This memo presents operational considerations and issues with IPv6
+   Domain Name System (DNS), including a summary of special IPv6
+   addresses, documentation of known DNS implementation misbehavior,
+   recommendations and considerations on how to perform DNS naming for
+   service provisioning and for DNS resolver IPv6 support,
+   considerations for DNS updates for both the forward and reverse
+   trees, and miscellaneous issues.  This memo is aimed to include a
+   summary of information about IPv6 DNS considerations for those who
+   have experience with IPv4 DNS.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Representing IPv6 Addresses in DNS Records .................3
+      1.2. Independence of DNS Transport and DNS Records ..............4
+      1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
+      1.4. Query Type '*' and A/AAAA Records ..........................4
+   2. DNS Considerations about Special IPv6 Addresses .................5
+      2.1. Limited-Scope Addresses ....................................5
+      2.2. Temporary Addresses ........................................5
+      2.3. 6to4 Addresses .............................................5
+      2.4. Other Transition Mechanisms ................................5
+   3. Observed DNS Implementation Misbehavior .........................6
+      3.1. Misbehavior of DNS Servers and Load-balancers ..............6
+      3.2. Misbehavior of DNS Resolvers ...............................6
+
+
+
+Durand, et al.               Informational                      [Page 1]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   4. Recommendations for Service Provisioning Using DNS ..............7
+      4.1. Use of Service Names instead of Node Names .................7
+      4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
+      4.3. Adding the Records Only When Fully IPv6-enabled ............8
+      4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
+           4.4.1. TTL with Courtesy Additional Data ...................9
+           4.4.2. TTL with Critical Additional Data ..................10
+      4.5. IPv6 Transport Guidelines for DNS Servers .................10
+   5. Recommendations for DNS Resolver IPv6 Support ..................10
+      5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
+      5.2. Obtaining a List of DNS Recursive Resolvers ...............12
+      5.3. IPv6 Transport Guidelines for Resolvers ...................12
+   6. Considerations about Forward DNS Updating ......................13
+      6.1. Manual or Custom DNS Updates ..............................13
+      6.2. Dynamic DNS ...............................................13
+   7. Considerations about Reverse DNS Updating ......................14
+      7.1. Applicability of Reverse DNS ..............................14
+      7.2. Manual or Custom DNS Updates ..............................15
+      7.3. DDNS with Stateless Address Autoconfiguration .............16
+      7.4. DDNS with DHCP ............................................17
+      7.5. DDNS with Dynamic Prefix Delegation .......................17
+   8. Miscellaneous DNS Considerations ...............................18
+      8.1. NAT-PT with DNS-ALG .......................................18
+      8.2. Renumbering Procedures and Applications' Use of DNS .......18
+   9. Acknowledgements ...............................................19
+   10. Security Considerations .......................................19
+   11. References ....................................................20
+      11.1. Normative References .....................................20
+      11.2. Informative References ...................................22
+   Appendix A. Unique Local Addressing Considerations for DNS ........24
+   Appendix B. Behavior of Additional Data in IPv4/IPv6
+               Environments ..........................................24
+      B.1. Description of Additional Data Scenarios ..................24
+      B.2. Which Additional Data to Keep, If Any? ....................26
+      B.3. Discussion of the Potential Problems ......................27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.               Informational                      [Page 2]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+1.  Introduction
+
+   This memo presents operational considerations and issues with IPv6
+   DNS; it is meant to be an extensive summary and a list of pointers
+   for more information about IPv6 DNS considerations for those with
+   experience with IPv4 DNS.
+
+   The purpose of this document is to give information about various
+   issues and considerations related to DNS operations with IPv6; it is
+   not meant to be a normative specification or standard for IPv6 DNS.
+
+   The first section gives a brief overview of how IPv6 addresses and
+   names are represented in the DNS, how transport protocols and
+   resource records (don't) relate, and what IPv4/IPv6 name space
+   fragmentation means and how to avoid it; all of these are described
+   at more length in other documents.
+
+   The second section summarizes the special IPv6 address types and how
+   they relate to DNS.  The third section describes observed DNS
+   implementation misbehaviors that have a varying effect on the use of
+   IPv6 records with DNS.  The fourth section lists recommendations and
+   considerations for provisioning services with DNS.  The fifth section
+   in turn looks at recommendations and considerations about providing
+   IPv6 support in the resolvers.  The sixth and seventh sections
+   describe considerations with forward and reverse DNS updates,
+   respectively.  The eighth section introduces several miscellaneous
+   IPv6 issues relating to DNS for which no better place has been found
+   in this memo.  Appendix A looks briefly at the requirements for
+   unique local addressing.  Appendix B discusses additional data.
+
+1.1.  Representing IPv6 Addresses in DNS Records
+
+   In the forward zones, IPv6 addresses are represented using AAAA
+   records.  In the reverse zones, IPv6 address are represented using
+   PTR records in the nibble format under the ip6.arpa. tree.  See
+   [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
+   for background information.
+
+   In particular, one should note that the use of A6 records in the
+   forward tree or Bitlabels in the reverse tree is not recommended
+   [RFC3363].  Using DNAME records is not recommended in the reverse
+   tree in conjunction with A6 records; the document did not mean to
+   take a stance on any other use of DNAME records [RFC3364].
+
+
+
+
+
+
+
+
+Durand, et al.               Informational                      [Page 3]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+1.2.  Independence of DNS Transport and DNS Records
+
+   DNS has been designed to present a single, globally unique name space
+   [RFC2826].  This property should be maintained, as described here and
+   in Section 1.3.
+
+   The IP version used to transport the DNS queries and responses is
+   independent of the records being queried: AAAA records can be queried
+   over IPv4, and A records over IPv6.  The DNS servers must not make
+   any assumptions about what data to return for Answer and Authority
+   sections based on the underlying transport used in a query.
+
+   However, there is some debate whether the addresses in Additional
+   section could be selected or filtered using hints obtained from which
+   transport was being used; this has some obvious problems because in
+   many cases the transport protocol does not correlate with the
+   requests, and because a "bad" answer is in a way worse than no answer
+   at all (consider the case where the client is led to believe that a
+   name received in the additional record does not have any AAAA records
+   at all).
+
+   As stated in [RFC3596]:
+
+      The IP protocol version used for querying resource records is
+      independent of the protocol version of the resource records; e.g.,
+      IPv4 transport can be used to query IPv6 records and vice versa.
+
+1.3.  Avoiding IPv4/IPv6 Name Space Fragmentation
+
+   To avoid the DNS name space from fragmenting into parts where some
+   parts of DNS are only visible using IPv4 (or IPv6) transport, the
+   recommendation is to always keep at least one authoritative server
+   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
+   See DNS IPv6 transport guidelines [RFC3901] for more information.
+
+1.4.  Query Type '*' and A/AAAA Records
+
+   QTYPE=* is typically only used for debugging or management purposes;
+   it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
+   any available RRsets, not *all* the RRsets, because the caches do not
+   necessarily have all the RRsets and have no way of guaranteeing that
+   they have all the RRsets.  Therefore, to get both A and AAAA records
+   reliably, two separate queries must be made.
+
+
+
+
+
+
+
+
+Durand, et al.               Informational                      [Page 4]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+2.  DNS Considerations about Special IPv6 Addresses
+
+   There are a couple of IPv6 address types that are somewhat special;
+   these are considered here.
+
+2.1.  Limited-Scope Addresses
+
+   The IPv6 addressing architecture [RFC4291] includes two kinds of
+   local-use addresses: link-local (fe80::/10) and site-local
+   (fec0::/10).  The site-local addresses have been deprecated [RFC3879]
+   but are discussed with unique local addresses in Appendix A.
+
+   Link-local addresses should never be published in DNS (whether in
+   forward or reverse tree), because they have only local (to the
+   connected link) significance [WIP-DC2005].
+
+2.2.  Temporary Addresses
+
+   Temporary addresses defined in RFC 3041 [RFC3041] (sometimes called
+   "privacy addresses") use a random number as the interface identifier.
+   Having DNS AAAA records that are updated to always contain the
+   current value of a node's temporary address would defeat the purpose
+   of the mechanism and is not recommended.  However, it would still be
+   possible to return a non-identifiable name (e.g., the IPv6 address in
+   hexadecimal format), as described in [RFC3041].
+
+2.3.  6to4 Addresses
+
+   6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a
+   public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
+
+   If the reverse DNS population would be desirable (see Section 7.1 for
+   applicability), there are a number of possible ways to do so.
+
+   [WIP-H2005] aims to design an autonomous reverse-delegation system
+   that anyone being capable of communicating using a specific 6to4
+   address would be able to set up a reverse delegation to the
+   corresponding 6to4 prefix.  This could be deployed by, e.g., Regional
+   Internet Registries (RIRs).  This is a practical solution, but may
+   have some scalability concerns.
+
+2.4.  Other Transition Mechanisms
+
+   6to4 is mentioned as a case of an IPv6 transition mechanism requiring
+   special considerations.  In general, mechanisms that include a
+   special prefix may need a custom solution; otherwise, for example,
+   when IPv4 address is embedded as the suffix or not embedded at all,
+   special solutions are likely not needed.
+
+
+
+Durand, et al.               Informational                      [Page 5]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   Note that it does not seem feasible to provide reverse DNS with
+   another automatic tunneling mechanism, Teredo [RFC4380]; this is
+   because the IPv6 address is based on the IPv4 address and UDP port of
+   the current Network Address Translation (NAT) mapping, which is
+   likely to be relatively short-lived.
+
+3.  Observed DNS Implementation Misbehavior
+
+   Several classes of misbehavior in DNS servers, load-balancers, and
+   resolvers have been observed.  Most of these are rather generic, not
+   only applicable to IPv6 -- but in some cases, the consequences of
+   this misbehavior are extremely severe in IPv6 environments and
+   deserve to be mentioned.
+
+3.1.  Misbehavior of DNS Servers and Load-balancers
+
+   There are several classes of misbehavior in certain DNS servers and
+   load-balancers that have been noticed and documented [RFC4074]: some
+   implementations silently drop queries for unimplemented DNS records
+   types, or provide wrong answers to such queries (instead of a proper
+   negative reply).  While typically these issues are not limited to
+   AAAA records, the problems are aggravated by the fact that AAAA
+   records are being queried instead of (mainly) A records.
+
+   The problems are serious because when looking up a DNS name, typical
+   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
+   to query the AAAA records of the name, and after receiving a
+   response, query the A records.  This is done in a serial fashion --
+   if the first query is never responded to (instead of properly
+   returning a negative answer), significant time-outs will occur.
+
+   In consequence, this is an enormous problem for IPv6 deployments, and
+   in some cases, IPv6 support in the software has even been disabled
+   due to these problems.
+
+   The solution is to fix or retire those misbehaving implementations,
+   but that is likely not going to be effective.  There are some
+   possible ways to mitigate the problem, e.g., by performing the
+   lookups somewhat in parallel and reducing the time-out as long as at
+   least one answer has been received, but such methods remain to be
+   investigated; slightly more on this is included in Section 5.
+
+3.2.  Misbehavior of DNS Resolvers
+
+   Several classes of misbehavior have also been noticed in DNS
+   resolvers [WIP-LB2005].  However, these do not seem to directly
+   impair IPv6 use, and are only referred to for completeness.
+
+
+
+
+Durand, et al.               Informational                      [Page 6]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+4.  Recommendations for Service Provisioning Using DNS
+
+   When names are added in the DNS to facilitate a service, there are
+   several general guidelines to consider to be able to do it as
+   smoothly as possible.
+
+4.1.  Use of Service Names instead of Node Names
+
+   It makes sense to keep information about separate services logically
+   separate in the DNS by using a different DNS hostname for each
+   service.  There are several reasons for doing this, for example:
+
+   o  It allows more flexibility and ease for migration of (only a part
+      of) services from one node to another,
+
+   o  It allows configuring different properties (e.g., Time to Live
+      (TTL)) for each service, and
+
+   o  It allows deciding separately for each service whether or not to
+      publish the IPv6 addresses (in cases where some services are more
+      IPv6-ready than others).
+
+   Using SRV records [RFC2782] would avoid these problems.
+   Unfortunately, those are not sufficiently widely used to be
+   applicable in most cases.  Hence an operation technique is to use
+   service names instead of node names (or "hostnames").  This
+   operational technique is not specific to IPv6, but required to
+   understand the considerations described in Section 4.2 and
+   Section 4.3.
+
+   For example, assume a node named "pobox.example.com" provides both
+   SMTP and IMAP service.  Instead of configuring the MX records to
+   point at "pobox.example.com", and configuring the mail clients to
+   look up the mail via IMAP from "pobox.example.com", one could use,
+   e.g., "smtp.example.com" for SMTP (for both message submission and
+   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
+   Note that in the specific case of SMTP relaying, the server itself
+   must typically also be configured to know all its names to ensure
+   that loops do not occur.  DNS can provide a layer of indirection
+   between service names and where the service actually is, and using
+   which addresses.  (Obviously, when wanting to reach a specific node,
+   one should use the hostname rather than a service name.)
+
+
+
+
+
+
+
+
+
+Durand, et al.               Informational                      [Page 7]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+4.2.  Separate vs. the Same Service Names for IPv4 and IPv6
+
+   The service naming can be achieved in basically two ways: when a
+   service is named "service.example.com" for IPv4, the IPv6-enabled
+   service could either be added to "service.example.com" or added
+   separately under a different name, e.g., in a sub-domain like
+   "service.ipv6.example.com".
+
+   These two methods have different characteristics.  Using a different
+   name allows for easier service piloting, minimizing the disturbance
+   to the "regular" users of IPv4 service; however, the service would
+   not be used transparently, without the user/application explicitly
+   finding it and asking for it -- which would be a disadvantage in most
+   cases.  When the different name is under a sub-domain, if the
+   services are deployed within a restricted network (e.g., inside an
+   enterprise), it's possible to prefer them transparently, at least to
+   a degree, by modifying the DNS search path; however, this is a
+   suboptimal solution.  Using the same service name is the "long-term"
+   solution, but may degrade performance for those clients whose IPv6
+   performance is lower than IPv4, or does not work as well (see
+   Section 4.3 for more).
+
+   In most cases, it makes sense to pilot or test a service using
+   separate service names, and move to the use of the same name when
+   confident enough that the service level will not degrade for the
+   users unaware of IPv6.
+
+4.3.  Adding the Records Only When Fully IPv6-enabled
+
+   The recommendation is that AAAA records for a service should not be
+   added to the DNS until all of following are true:
+
+   1.  The address is assigned to the interface on the node.
+
+   2.  The address is configured on the interface.
+
+   3.  The interface is on a link that is connected to the IPv6
+       infrastructure.
+
+   In addition, if the AAAA record is added for the node, instead of
+   service as recommended, all the services of the node should be IPv6-
+   enabled prior to adding the resource record.
+
+   For example, if an IPv6 node is isolated from an IPv6 perspective
+   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
+   that it should not have an address in the DNS.
+
+
+
+
+
+Durand, et al.               Informational                      [Page 8]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   Consider the case of two dual-stack nodes, which both are IPv6-
+   enabled, but the server does not have (global) IPv6 connectivity.  As
+   the client looks up the server's name, only A records are returned
+   (if the recommendations above are followed), and no IPv6
+   communication, which would have been unsuccessful, is even attempted.
+
+   The issues are not always so black-and-white.  Usually, it's
+   important that the service offered using both protocols is of roughly
+   equal quality, using the appropriate metrics for the service (e.g.,
+   latency, throughput, low packet loss, general reliability, etc.).
+   This is typically very important especially for interactive or real-
+   time services.  In many cases, the quality of IPv6 connectivity may
+   not yet be equal to that of IPv4, at least globally; this has to be
+   taken into consideration when enabling services.
+
+4.4.  The Use of TTL for IPv4 and IPv6 RRs
+
+   The behavior of DNS caching when different TTL values are used for
+   different RRsets of the same name calls for explicit discussion.  For
+   example, let's consider two unrelated zone fragments:
+
+      example.com.        300    IN    MX     foo.example.com.
+      foo.example.com.    300    IN    A      192.0.2.1
+      foo.example.com.    100    IN    AAAA   2001:db8::1
+
+   ...
+
+      child.example.com.    300  IN    NS     ns.child.example.com.
+      ns.child.example.com. 300  IN    A      192.0.2.1
+      ns.child.example.com. 100  IN    AAAA   2001:db8::1
+
+   In the former case, we have "courtesy" additional data; in the
+   latter, we have "critical" additional data.  See more extensive
+   background discussion of additional data handling in Appendix B.
+
+4.4.1.  TTL with Courtesy Additional Data
+
+   When a caching resolver asks for the MX record of example.com, it
+   gets back "foo.example.com".  It may also get back either one or both
+   of the A and AAAA records in the additional section.  The resolver
+   must explicitly query for both A and AAAA records [RFC2821].
+
+   After 100 seconds, the AAAA record is removed from the cache(s)
+   because its TTL expired.  It could be argued to be useful for the
+   caching resolvers to discard the A record when the shorter TTL (in
+   this case, for the AAAA record) expires; this would avoid the
+   situation where there would be a window of 200 seconds when
+   incomplete information is returned from the cache.  Further argument
+
+
+
+Durand, et al.               Informational                      [Page 9]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   for discarding is that in the normal operation, the TTL values are so
+   high that very likely the incurred additional queries would not be
+   noticeable, compared to the obtained performance optimization.  The
+   behavior in this scenario is unspecified.
+
+4.4.2.  TTL with Critical Additional Data
+
+   The difference to courtesy additional data is that the A/AAAA records
+   served by the parent zone cannot be queried explicitly.  Therefore,
+   after 100 seconds the AAAA record is removed from the cache(s), but
+   the A record remains.  Queries for the remaining 200 seconds
+   (provided that there are no further queries from the parent that
+   could refresh the caches) only return the A record, leading to a
+   potential operational situation with unreachable servers.
+
+   Similar cache flushing strategies apply in this scenario; the
+   behavior is likewise unspecified.
+
+4.5.  IPv6 Transport Guidelines for DNS Servers
+
+   As described in Section 1.3 and [RFC3901], there should continue to
+   be at least one authoritative IPv4 DNS server for every zone, even if
+   the zone has only IPv6 records.  (Note that obviously, having more
+   servers with robust connectivity would be preferable, but this is the
+   minimum recommendation; also see [RFC2182].)
+
+5.  Recommendations for DNS Resolver IPv6 Support
+
+   When IPv6 is enabled on a node, there are several things to consider
+   to ensure that the process is as smooth as possible.
+
+5.1.  DNS Lookups May Query IPv6 Records Prematurely
+
+   The system library that implements the getaddrinfo() function for
+   looking up names is a critical piece when considering the robustness
+   of enabling IPv6; it may come in basically three flavors:
+
+   1.  The system library does not know whether IPv6 has been enabled in
+       the kernel of the operating system: it may start looking up AAAA
+       records with getaddrinfo() and AF_UNSPEC hint when the system is
+       upgraded to a system library version that supports IPv6.
+
+   2.  The system library might start to perform IPv6 queries with
+       getaddrinfo() only when IPv6 has been enabled in the kernel.
+       However, this does not guarantee that there exists any useful
+       IPv6 connectivity (e.g., the node could be isolated from the
+       other IPv6 networks, only having link-local addresses).
+
+
+
+
+Durand, et al.               Informational                     [Page 10]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   3.  The system library might implement a toggle that would apply some
+       heuristics to the "IPv6-readiness" of the node before starting to
+       perform queries; for example, it could check whether only link-
+       local IPv6 address(es) exists, or if at least one global IPv6
+       address exists.
+
+   First, let us consider generic implications of unnecessary queries
+   for AAAA records: when looking up all the records in the DNS, AAAA
+   records are typically tried first, and then A records.  These are
+   done in serial, and the A query is not performed until a response is
+   received to the AAAA query.  Considering the misbehavior of DNS
+   servers and load-balancers, as described in Section 3.1, the lookup
+   delay for AAAA may incur additional unnecessary latency, and
+   introduce a component of unreliability.
+
+   One option here could be to do the queries partially in parallel; for
+   example, if the final response to the AAAA query is not received in
+   0.5 seconds, start performing the A query while waiting for the
+   result.  (Immediate parallelism might not be optimal, at least
+   without information-sharing between the lookup threads, as that would
+   probably lead to duplicate non-cached delegation chain lookups.)
+
+   An additional concern is the address selection, which may, in some
+   circumstances, prefer AAAA records over A records even when the node
+   does not have any IPv6 connectivity [WIP-RDP2004].  In some cases,
+   the implementation may attempt to connect or send a datagram on a
+   physical link [WIP-R2006], incurring very long protocol time-outs,
+   instead of quickly falling back to IPv4.
+
+   Now, we can consider the issues specific to each of the three
+   possibilities:
+
+   In the first case, the node performs a number of completely useless
+   DNS lookups as it will not be able to use the returned AAAA records
+   anyway.  (The only exception is where the application desires to know
+   what's in the DNS, but not use the result for communication.)  One
+   should be able to disable these unnecessary queries, for both latency
+   and reliability reasons.  However, as IPv6 has not been enabled, the
+   connections to IPv6 addresses fail immediately, and if the
+   application is programmed properly, the application can fall
+   gracefully back to IPv4 [RFC4038].
+
+   The second case is similar to the first, except it happens to a
+   smaller set of nodes when IPv6 has been enabled but connectivity has
+   not been provided yet.  Similar considerations apply, with the
+   exception that IPv6 records, when returned, will be actually tried
+   first, which may typically lead to long time-outs.
+
+
+
+
+Durand, et al.               Informational                     [Page 11]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   The third case is a bit more complex: optimizing away the DNS lookups
+   with only link-locals is probably safe (but may be desirable with
+   different lookup services that getaddrinfo() may support), as the
+   link-locals are typically automatically generated when IPv6 is
+   enabled, and do not indicate any form of IPv6 connectivity.  That is,
+   performing DNS lookups only when a non-link-local address has been
+   configured on any interface could be beneficial -- this would be an
+   indication that the address has been configured either from a router
+   advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+   [RFC3315], or manually.  Each would indicate at least some form of
+   IPv6 connectivity, even though there would not be guarantees of it.
+
+   These issues should be analyzed at more depth, and the fixes found
+   consensus on, perhaps in a separate document.
+
+5.2.  Obtaining a List of DNS Recursive Resolvers
+
+   In scenarios where DHCPv6 is available, a host can discover a list of
+   DNS recursive resolvers through the DHCPv6 "DNS Recursive Name
+   Server" option [RFC3646].  This option can be passed to a host
+   through a subset of DHCPv6 [RFC3736].
+
+   The IETF is considering the development of alternative mechanisms for
+   obtaining the list of DNS recursive name servers when DHCPv6 is
+   unavailable or inappropriate.  No decision about taking on this
+   development work has been reached as of this writing [RFC4339].
+
+   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
+   under consideration for development include the use of [WIP-O2004]
+   and the use of Router Advertisements to convey the information
+   [WIP-J2006].
+
+   Note that even though IPv6 DNS resolver discovery is a recommended
+   procedure, it is not required for dual-stack nodes in dual-stack
+   networks as IPv6 DNS records can be queried over IPv4 as well as
+   IPv6.  Obviously, nodes that are meant to function without manual
+   configuration in IPv6-only networks must implement the DNS resolver
+   discovery function.
+
+5.3.  IPv6 Transport Guidelines for Resolvers
+
+   As described in Section 1.3 and [RFC3901], the recursive resolvers
+   should be IPv4-only or dual-stack to be able to reach any IPv4-only
+   DNS server.  Note that this requirement is also fulfilled by an IPv6-
+   only stub resolver pointing to a dual-stack recursive DNS resolver.
+
+
+
+
+
+
+Durand, et al.               Informational                     [Page 12]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+6.  Considerations about Forward DNS Updating
+
+   While the topic of how to enable updating the forward DNS, i.e., the
+   mapping from names to the correct new addresses, is not specific to
+   IPv6, it should be considered especially due to the advent of
+   Stateless Address Autoconfiguration [RFC2462].
+
+   Typically, forward DNS updates are more manageable than doing them in
+   the reverse DNS, because the updater can often be assumed to "own" a
+   certain DNS name -- and we can create a form of security relationship
+   with the DNS name and the node that is allowed to update it to point
+   to a new address.
+
+   A more complex form of DNS updates -- adding a whole new name into a
+   DNS zone, instead of updating an existing name -- is considered out
+   of scope for this memo as it could require zone-wide authentication.
+   Adding a new name in the forward zone is a problem that is still
+   being explored with IPv4, and IPv6 does not seem to add much new in
+   that area.
+
+6.1.  Manual or Custom DNS Updates
+
+   The DNS mappings can also be maintained by hand, in a semi-automatic
+   fashion or by running non-standardized protocols.  These are not
+   considered at more length in this memo.
+
+6.2.  Dynamic DNS
+
+   Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
+   mechanism for dynamically updating the DNS.  It works equally well
+   with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual
+   address configuration.  It is important to consider how each of these
+   behave if IP address-based authentication, instead of stronger
+   mechanisms [RFC3007], was used in the updates.
+
+   1.  Manual addresses are static and can be configured.
+
+   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
+       on the deployment, and could or could not be configured on the
+       DNS server for the long term.
+
+   3.  SLAAC addresses are typically stable for a long time, but could
+       require work to be configured and maintained.
+
+   As relying on IP addresses for Dynamic DNS is rather insecure at
+   best, stronger authentication should always be used; however, this
+   requires that the authorization keying will be explicitly configured
+   using unspecified operational methods.
+
+
+
+Durand, et al.               Informational                     [Page 13]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   Note that with DHCP it is also possible that the DHCP server updates
+   the DNS, not the host.  The host might only indicate in the DHCP
+   exchange which hostname it would prefer, and the DHCP server would
+   make the appropriate updates.  Nonetheless, while this makes setting
+   up a secure channel between the updater and the DNS server easier, it
+   does not help much with "content" security, i.e., whether the
+   hostname was acceptable -- if the DNS server does not include
+   policies, they must be included in the DHCP server (e.g., a regular
+   host should not be able to state that its name is "www.example.com").
+   DHCP-initiated DDNS updates have been extensively described in
+   [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b].
+
+   The nodes must somehow be configured with the information about the
+   servers where they will attempt to update their addresses, sufficient
+   security material for authenticating themselves to the server, and
+   the hostname they will be updating.  Unless otherwise configured, the
+   first could be obtained by looking up the authoritative name servers
+   for the hostname; the second must be configured explicitly unless one
+   chooses to trust the IP address-based authentication (not a good
+   idea); and lastly, the nodename is typically pre-configured somehow
+   on the node, e.g., at install time.
+
+   Care should be observed when updating the addresses not to use longer
+   TTLs for addresses than are preferred lifetimes for the addresses, so
+   that if the node is renumbered in a managed fashion, the amount of
+   stale DNS information is kept to the minimum.  That is, if the
+   preferred lifetime of an address expires, the TTL of the record needs
+   to be modified unless it was already done before the expiration.  For
+   better flexibility, the DNS TTL should be much shorter (e.g., a half
+   or a third) than the lifetime of an address; that way, the node can
+   start lowering the DNS TTL if it seems like the address has not been
+   renewed/refreshed in a while.  Some discussion on how an
+   administrator could manage the DNS TTL is included in [RFC4192]; this
+   could be applied to (smart) hosts as well.
+
+7.  Considerations about Reverse DNS Updating
+
+   Updating the reverse DNS zone may be difficult because of the split
+   authority over an address.  However, first we have to consider the
+   applicability of reverse DNS in the first place.
+
+7.1.  Applicability of Reverse DNS
+
+   Today, some applications use reverse DNS either to look up some hints
+   about the topological information associated with an address (e.g.,
+   resolving web server access logs) or (as a weak form of a security
+   check) to get a feel whether the user's network administrator has
+
+
+
+
+Durand, et al.               Informational                     [Page 14]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   "authorized" the use of the address (on the premise that adding a
+   reverse record for an address would signal some form of
+   authorization).
+
+   One additional, maybe slightly more useful usage is ensuring that the
+   reverse and forward DNS contents match (by looking up the pointer to
+   the name by the IP address from the reverse tree, and ensuring that a
+   record under the name in the forward tree points to the IP address)
+   and correspond to a configured name or domain.  As a security check,
+   it is typically accompanied by other mechanisms, such as a user/
+   password login; the main purpose of the reverse+forward DNS check is
+   to weed out the majority of unauthorized users, and if someone
+   managed to bypass the checks, he would still need to authenticate
+   "properly".
+
+   It may also be desirable to store IPsec keying material corresponding
+   to an IP address in the reverse DNS, as justified and described in
+   [RFC4025].
+
+   It is not clear whether it makes sense to require or recommend that
+   reverse DNS records be updated.  In many cases, it would just make
+   more sense to use proper mechanisms for security (or topological
+   information lookup) in the first place.  At minimum, the applications
+   that use it as a generic authorization (in the sense that a record
+   exists at all) should be modified as soon as possible to avoid such
+   lookups completely.
+
+   The applicability is discussed at more length in [WIP-S2005c].
+
+7.2.  Manual or Custom DNS Updates
+
+   Reverse DNS can of course be updated using manual or custom methods.
+   These are not further described here, except for one special case.
+
+   One way to deploy reverse DNS would be to use wildcard records, for
+   example, by configuring one name for a subnet (/64) or a site (/48).
+   As a concrete example, a site (or the site's ISP) could configure the
+   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
+   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
+   site.example.com.".  Naturally, such a name could not be verified
+   from the forward DNS, but would at least provide some form of
+   "topological information" or "weak authorization" if that is really
+   considered to be useful.  Note that this is not actually updating the
+   DNS as such, as the whole point is to avoid DNS updates completely by
+   manually configuring a generic name.
+
+
+
+
+
+
+Durand, et al.               Informational                     [Page 15]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+7.3.  DDNS with Stateless Address Autoconfiguration
+
+   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
+   some regard, while being more difficult in another, as described
+   below.
+
+   The address space administrator decides whether or not the hosts are
+   trusted to update their reverse DNS records.  If they are trusted and
+   deployed at the same site (e.g., not across the Internet), a simple
+   address-based authorization is typically sufficient (i.e., check that
+   the DNS update is done from the same IP address as the record being
+   updated); stronger security can also be used [RFC3007].  If they
+   aren't allowed to update the reverses, no update can occur.  However,
+   such address-based update authorization operationally requires that
+   ingress filtering [RFC3704] has been set up at the border of the site
+   where the updates occur, and as close to the updater as possible.
+
+   Address-based authorization is simpler with reverse DNS (as there is
+   a connection between the record and the address) than with forward
+   DNS.  However, when a stronger form of security is used, forward DNS
+   updates are simpler to manage because the host can be assumed to have
+   an association with the domain.  Note that the user may roam to
+   different networks and does not necessarily have any association with
+   the owner of that address space.  So, assuming a stronger form of
+   authorization for reverse DNS updates than an address association is
+   generally infeasible.
+
+   Moreover, the reverse zones must be cleaned up by an unspecified
+   janitorial process: the node does not typically know a priori that it
+   will be disconnected, and it cannot send a DNS update using the
+   correct source address to remove a record.
+
+   A problem with defining the clean-up process is that it is difficult
+   to ensure that a specific IP address and the corresponding record are
+   no longer being used.  Considering the huge address space, and the
+   unlikelihood of collision within 64 bits of the interface
+   identifiers, a process that would remove the record after no traffic
+   has been seen from a node in a long period of time (e.g., a month or
+   year) might be one possible approach.
+
+   To insert or update the record, the node must discover the DNS server
+   to send the update to somehow, similar to as discussed in
+   Section 6.2.  One way to automate this is looking up the DNS server
+   authoritative (e.g., through SOA record) for the IP address being
+   updated, but the security material (unless the IP address-based
+   authorization is trusted) must also be established by some other
+   means.
+
+
+
+
+Durand, et al.               Informational                     [Page 16]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   One should note that Cryptographically Generated Addresses (CGAs)
+   [RFC3972] may require a slightly different kind of treatment.  CGAs
+   are addresses where the interface identifier is calculated from a
+   public key, a modifier (used as a nonce), the subnet prefix, and
+   other data.  Depending on the usage profile, CGAs might or might not
+   be changed periodically due to, e.g., privacy reasons.  As the CGA
+   address is not predictable, a reverse record can only reasonably be
+   inserted in the DNS by the node that generates the address.
+
+7.4.  DDNS with DHCP
+
+   With DHCPv4, the reverse DNS name is typically already inserted to
+   the DNS that reflects the name (e.g., "dhcp-67.example.com").  One
+   can assume similar practice may become commonplace with DHCPv6 as
+   well; all such mappings would be pre-configured and would require no
+   updating.
+
+   If a more explicit control is required, similar considerations as
+   with SLAAC apply, except for the fact that typically one must update
+   a reverse DNS record instead of inserting one (if an address
+   assignment policy that reassigns disused addresses is adopted) and
+   updating a record seems like a slightly more difficult thing to
+   secure.  However, it is yet uncertain how DHCPv6 is going to be used
+   for address assignment.
+
+   Note that when using DHCP, either the host or the DHCP server could
+   perform the DNS updates; see the implications in Section 6.2.
+
+   If disused addresses were to be reassigned, host-based DDNS reverse
+   updates would need policy considerations for DNS record modification,
+   as noted above.  On the other hand, if disused address were not to be
+   assigned, host-based DNS reverse updates would have similar
+   considerations as SLAAC in Section 7.3.  Server-based updates have
+   similar properties except that the janitorial process could be
+   integrated with DHCP address assignment.
+
+7.5.  DDNS with Dynamic Prefix Delegation
+
+   In cases where a prefix, instead of an address, is being used and
+   updated, one should consider what is the location of the server where
+   DDNS updates are made.  That is, where the DNS server is located:
+
+   1.  At the same organization as the prefix delegator.
+
+   2.  At the site where the prefixes are delegated to.  In this case,
+       the authority of the DNS reverse zone corresponding to the
+       delegated prefix is also delegated to the site.
+
+
+
+
+Durand, et al.               Informational                     [Page 17]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   3.  Elsewhere; this implies a relationship between the site and where
+       the DNS server is located, and such a relationship should be
+       rather straightforward to secure as well.  Like in the previous
+       case, the authority of the DNS reverse zone is also delegated.
+
+   In the first case, managing the reverse DNS (delegation) is simpler
+   as the DNS server and the prefix delegator are in the same
+   administrative domain (as there is no need to delegate anything at
+   all); alternatively, the prefix delegator might forgo DDNS reverse
+   capability altogether, and use, e.g., wildcard records (as described
+   in Section 7.2).  In the other cases, it can be slightly more
+   difficult, particularly as the site will have to configure the DNS
+   server to be authoritative for the delegated reverse zone, implying
+   automatic configuration of the DNS server -- as the prefix may be
+   dynamic.
+
+   Managing the DDNS reverse updates is typically simple in the second
+   case, as the updated server is located at the local site, and
+   arguably IP address-based authentication could be sufficient (or if
+   not, setting up security relationships would be simpler).  As there
+   is an explicit (security) relationship between the parties in the
+   third case, setting up the security relationships to allow reverse
+   DDNS updates should be rather straightforward as well (but IP
+   address-based authentication might not be acceptable).  In the first
+   case, however, setting up and managing such relationships might be a
+   lot more difficult.
+
+8.  Miscellaneous DNS Considerations
+
+   This section describes miscellaneous considerations about DNS that
+   seem related to IPv6, for which no better place has been found in
+   this document.
+
+8.1.  NAT-PT with DNS-ALG
+
+   The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look
+   like AAAA records to the IPv6-only nodes.  Numerous problems have
+   been identified with [WIP-AD2005].  This is a strong reason not to
+   use NAT-PT in the first place.
+
+8.2.  Renumbering Procedures and Applications' Use of DNS
+
+   One of the most difficult problems of systematic IP address
+   renumbering procedures [RFC4192] is that an application that looks up
+   a DNS name disregards information such as TTL, and uses the result
+   obtained from DNS as long as it happens to be stored in the memory of
+   the application.  For applications that run for a long time, this
+
+
+
+
+Durand, et al.               Informational                     [Page 18]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   could be days, weeks, or even months.  Some applications may be
+   clever enough to organize the data structures and functions in such a
+   manner that lookups get refreshed now and then.
+
+   While the issue appears to have a clear solution, "fix the
+   applications", practically, this is not reasonable immediate advice.
+   The TTL information is not typically available in the APIs and
+   libraries (so, the advice becomes "fix the applications, APIs, and
+   libraries"), and a lot more analysis is needed on how to practically
+   go about to achieve the ultimate goal of avoiding using the names
+   longer than expected.
+
+9.  Acknowledgements
+
+   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
+   provisioning were moved here from [RFC4213] by Erik Nordmark and Bob
+   Gilligan.  Havard Eidnes and Michael Patton provided useful feedback
+   and improvements.  Scott Rose, Rob Austein, Masataka Ohta, and Mark
+   Andrews helped in clarifying the issues regarding additional data and
+   the use of TTL.  Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei
+   Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided
+   useful feedback during the WG last call.  Thomas Narten provided
+   extensive feedback during the IESG evaluation.
+
+10.  Security Considerations
+
+   This document reviews the operational procedures for IPv6 DNS
+   operations and does not have security considerations in itself.
+
+   However, it is worth noting that in particular with Dynamic DNS
+   updates, security models based on the source address validation are
+   very weak and cannot be recommended -- they could only be considered
+   in the environments where ingress filtering [RFC3704] has been
+   deployed.  On the other hand, it should be noted that setting up an
+   authorization mechanism (e.g., a shared secret, or public-private
+   keys) between a node and the DNS server has to be done manually, and
+   may require quite a bit of time and expertise.
+
+   To re-emphasize what was already stated, the reverse+forward DNS
+   check provides very weak security at best, and the only
+   (questionable) security-related use for them may be in conjunction
+   with other mechanisms when authenticating a user.
+
+
+
+
+
+
+
+
+
+Durand, et al.               Informational                     [Page 19]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC1034]     Mockapetris, P., "Domain names - concepts and
+                 facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC2136]     Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+                 "Dynamic Updates in the Domain Name System (DNS
+                 UPDATE)", RFC 2136, April 1997.
+
+   [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
+                 Specification", RFC 2181, July 1997.
+
+   [RFC2182]     Elz, R., Bush, R., Bradner, S., and M. Patton,
+                 "Selection and Operation of Secondary DNS Servers",
+                 BCP 16, RFC 2182, July 1997.
+
+   [RFC2462]     Thomson, S. and T. Narten, "IPv6 Stateless Address
+                 Autoconfiguration", RFC 2462, December 1998.
+
+   [RFC2671]     Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+                 RFC 2671, August 1999.
+
+   [RFC2821]     Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+                 April 2001.
+
+   [RFC3007]     Wellington, B., "Secure Domain Name System (DNS)
+                 Dynamic Update", RFC 3007, November 2000.
+
+   [RFC3041]     Narten, T. and R. Draves, "Privacy Extensions for
+                 Stateless Address Autoconfiguration in IPv6", RFC 3041,
+                 January 2001.
+
+   [RFC3056]     Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+                 via IPv4 Clouds", RFC 3056, February 2001.
+
+   [RFC3152]     Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+                 August 2001.
+
+   [RFC3315]     Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+                 and M. Carney, "Dynamic Host Configuration Protocol for
+                 IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3363]     Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+                 Hain, "Representing Internet Protocol version 6 (IPv6)
+                 Addresses in the Domain Name System (DNS)", RFC 3363,
+                 August 2002.
+
+
+
+Durand, et al.               Informational                     [Page 20]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   [RFC3364]     Austein, R., "Tradeoffs in Domain Name System (DNS)
+                 Support for Internet Protocol version 6 (IPv6)",
+                 RFC 3364, August 2002.
+
+   [RFC3596]     Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+                 "DNS Extensions to Support IP Version 6", RFC 3596,
+                 October 2003.
+
+   [RFC3646]     Droms, R., "DNS Configuration options for Dynamic Host
+                 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+                 December 2003.
+
+   [RFC3736]     Droms, R., "Stateless Dynamic Host Configuration
+                 Protocol (DHCP) Service for IPv6", RFC 3736,
+                 April 2004.
+
+   [RFC3879]     Huitema, C. and B. Carpenter, "Deprecating Site Local
+                 Addresses", RFC 3879, September 2004.
+
+   [RFC3901]     Durand, A. and J. Ihren, "DNS IPv6 Transport
+                 Operational Guidelines", BCP 91, RFC 3901,
+                 September 2004.
+
+   [RFC4038]     Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+                 Castro, "Application Aspects of IPv6 Transition",
+                 RFC 4038, March 2005.
+
+   [RFC4074]     Morishita, Y. and T. Jinmei, "Common Misbehavior
+                 Against DNS Queries for IPv6 Addresses", RFC 4074,
+                 May 2005.
+
+   [RFC4192]     Baker, F., Lear, E., and R. Droms, "Procedures for
+                 Renumbering an IPv6 Network without a Flag Day",
+                 RFC 4192, September 2005.
+
+   [RFC4193]     Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+                 Addresses", RFC 4193, October 2005.
+
+   [RFC4291]     Hinden, R. and S. Deering, "IP Version 6 Addressing
+                 Architecture", RFC 4291, February 2006.
+
+   [RFC4339]     Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
+                 Information Approaches", RFC 4339, February 2006.
+
+
+
+
+
+
+
+
+Durand, et al.               Informational                     [Page 21]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+11.2.  Informative References
+
+   [RFC2766]     Tsirtsis, G. and P. Srisuresh, "Network Address
+                 Translation - Protocol Translation (NAT-PT)", RFC 2766,
+                 February 2000.
+
+   [RFC2782]     Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
+                 for specifying the location of services (DNS SRV)",
+                 RFC 2782, February 2000.
+
+   [RFC2826]     Internet Architecture Board, "IAB Technical Comment on
+                 the Unique DNS Root", RFC 2826, May 2000.
+
+   [RFC3704]     Baker, F. and P. Savola, "Ingress Filtering for
+                 Multihomed Networks", BCP 84, RFC 3704, March 2004.
+
+   [RFC3972]     Aura, T., "Cryptographically Generated Addresses
+                 (CGA)", RFC 3972, March 2005.
+
+   [RFC4025]     Richardson, M., "A Method for Storing IPsec Keying
+                 Material in DNS", RFC 4025, March 2005.
+
+   [RFC4213]     Nordmark, E. and R. Gilligan, "Basic Transition
+                 Mechanisms for IPv6 Hosts and Routers", RFC 4213,
+                 October 2005.
+
+   [RFC4215]     Wiljakka, J., "Analysis on IPv6 Transition in Third
+                 Generation Partnership Project (3GPP) Networks",
+                 RFC 4215, October 2005.
+
+   [RFC4380]     Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+                 Network Address Translations (NATs)", RFC 4380,
+                 February 2006.
+
+   [TC-TEST]     Jinmei, T., "Thread "RFC2181 section 9.1: TC bit
+                 handling and additional data" on DNSEXT mailing list,
+                 Message-
+                 Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August
+                 1, 2005, .
+
+   [WIP-AD2005]  Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
+                 Experimental", Work in Progress, October 2005.
+
+   [WIP-DC2005]  Durand, A. and T. Chown, "To publish, or not to
+                 publish, that is the question", Work in Progress,
+                 October 2005.
+
+
+
+
+Durand, et al.               Informational                     [Page 22]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   [WIP-H2005]   Huston, G., "6to4 Reverse DNS Delegation
+                 Specification", Work in Progress, November 2005.
+
+   [WIP-J2006]   Jeong, J., "IPv6 Router Advertisement Option for DNS
+                 Configuration", Work in Progress, January 2006.
+
+   [WIP-LB2005]  Larson, M. and P. Barber, "Observed DNS Resolution
+                 Misbehavior", Work in Progress, February 2006.
+
+   [WIP-O2004]   Ohta, M., "Preconfigured DNS Server Addresses", Work in
+                 Progress, February 2004.
+
+   [WIP-R2006]   Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
+                 Considered Harmful", Work in Progress, January 2006.
+
+   [WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual
+                 Stack IPv6 on by Default", Work in Progress, July 2004.
+
+   [WIP-S2005a]  Stapp, M., "The DHCP Client FQDN Option", Work in
+                 Progress, March 2006.
+
+   [WIP-S2005b]  Stapp, M., "A DNS RR for Encoding DHCP Information
+                 (DHCID RR)", Work in Progress, March 2006.
+
+   [WIP-S2005c]  Senie, D., "Encouraging the use of DNS IN-ADDR
+                 Mapping", Work in Progress, August 2005.
+
+   [WIP-SV2005]  Stapp, M. and B. Volz, "Resolution of FQDN Conflicts
+                 among DHCP Clients", Work in Progress, March 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.               Informational                     [Page 23]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+Appendix A.  Unique Local Addressing Considerations for DNS
+
+   Unique local addresses [RFC4193] have replaced the now-deprecated
+   site-local addresses [RFC3879].  From the perspective of the DNS, the
+   locally generated unique local addresses (LUL) and site-local
+   addresses have similar properties.
+
+   The interactions with DNS come in two flavors: forward and reverse
+   DNS.
+
+   To actually use local addresses within a site, this implies the
+   deployment of a "split-faced" or a fragmented DNS name space, for the
+   zones internal to the site, and the outsiders' view to it.  The
+   procedures to achieve this are not elaborated here.  The implication
+   is that local addresses must not be published in the public DNS.
+
+   To facilitate reverse DNS (if desired) with local addresses, the stub
+   resolvers must look for DNS information from the local DNS servers,
+   not, e.g., starting from the root servers, so that the local
+   information may be provided locally.  Note that the experience of
+   private addresses in IPv4 has shown that the root servers get loaded
+   for requests for private address lookups in any case.  This
+   requirement is discussed in [RFC4193].
+
+Appendix B.  Behavior of Additional Data in IPv4/IPv6 Environments
+
+   DNS responses do not always fit in a single UDP packet.  We'll
+   examine the cases that happen when this is due to too much data in
+   the Additional section.
+
+B.1.  Description of Additional Data Scenarios
+
+   There are two kinds of additional data:
+
+   1.  "critical" additional data; this must be included in all
+       scenarios, with all the RRsets, and
+
+   2.  "courtesy" additional data; this could be sent in full, with only
+       a few RRsets, or with no RRsets, and can be fetched separately as
+       well, but at the cost of additional queries.
+
+   The responding server can algorithmically determine which type the
+   additional data is by checking whether it's at or below a zone cut.
+
+   Only those additional data records (even if sometimes carelessly
+   termed "glue") are considered "critical" or real "glue" if and only
+   if they meet the above-mentioned condition, as specified in Section
+   4.2.1 of [RFC1034].
+
+
+
+Durand, et al.               Informational                     [Page 24]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+   Remember that resource record sets (RRsets) are never "broken up", so
+   if a name has 4 A records and 5 AAAA records, you can either return
+   all 9, all 4 A records, all 5 AAAA records, or nothing.  In
+   particular, notice that for the "critical" additional data getting
+   all the RRsets can be critical.
+
+   In particular, [RFC2181] specifies (in Section 9) that:
+
+   a.  if all the "critical" RRsets do not fit, the sender should set
+       the TC bit, and the recipient should discard the whole response
+       and retry using mechanism allowing larger responses such as TCP.
+
+   b.  "courtesy" additional data should not cause the setting of the TC
+       bit, but instead all the non-fitting additional data RRsets
+       should be removed.
+
+   An example of the "courtesy" additional data is A/AAAA records in
+   conjunction with MX records as shown in Section 4.4; an example of
+   the "critical" additional data is shown below (where getting both the
+   A and AAAA RRsets is critical with respect to the NS RR):
+
+      child.example.com.    IN   NS ns.child.example.com.
+      ns.child.example.com. IN    A 192.0.2.1
+      ns.child.example.com. IN AAAA 2001:db8::1
+
+   When there is too much "courtesy" additional data, at least the non-
+   fitting RRsets should be removed [RFC2181]; however, as the
+   additional data is not critical, even all of it could be safely
+   removed.
+
+   When there is too much "critical" additional data, TC bit will have
+   to be set, and the recipient should ignore the response and retry
+   using TCP; if some data were to be left in the UDP response, the
+   issue is which data could be retained.
+
+   However, the practice may differ from the specification.  Testing and
+   code analysis of three recent implementations [TC-TEST] confirm this.
+   None of the tested implementations have a strict separation of
+   critical and courtesy additional data, while some forms of additional
+   data may be treated preferably.  All the implementations remove some
+   (critical or courtesy) additional data RRsets without setting the TC
+   bit if the response would not otherwise fit.
+
+   Failing to discard the response with the TC bit or omitting critical
+   information but not setting the TC bit lead to an unrecoverable
+   problem.  Omitting only some of the RRsets if all would not fit (but
+   not setting the TC bit) leads to a performance problem.  These are
+   discussed in the next two subsections.
+
+
+
+Durand, et al.               Informational                     [Page 25]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+B.2.  Which Additional Data to Keep, If Any?
+
+   NOTE: omitting some critical additional data instead of setting the
+   TC bit violates a 'should' in Section 9 of RFC2181.  However, as many
+   implementations still do that [TC-TEST], operators need to understand
+   its implications, and we describe that behavior as well.
+
+   If the implementation decides to keep as much data (whether
+   "critical" or "courtesy") as possible in the UDP responses, it might
+   be tempting to use the transport of the DNS query as a hint in either
+   of these cases: return the AAAA records if the query was done over
+   IPv6, or return the A records if the query was done over IPv4.
+   However, this breaks the model of independence of DNS transport and
+   resource records, as noted in Section 1.2.
+
+   With courtesy additional data, as long as enough RRsets will be
+   removed so that TC will not be set, it is allowed to send as many
+   complete RRsets as the implementations prefers.  However, the
+   implementations are also free to omit all such RRsets, even if
+   complete.  Omitting all the RRsets (when removing only some would
+   suffice) may create a performance penalty, whereby the client may
+   need to issue one or more additional queries to obtain necessary
+   and/or consistent information.
+
+   With critical additional data, the alternatives are either returning
+   nothing (and absolutely requiring a retry with TCP) or returning
+   something (working also in the case if the recipient does not discard
+   the response and retry using TCP) in addition to setting the TC bit.
+   If the process for selecting "something" from the critical data would
+   otherwise be practically "flipping the coin" between A and AAAA
+   records, it could be argued that if one looked at the transport of
+   the query, it would have a larger possibility of being right than
+   just 50/50.  In other words, if the returned critical additional data
+   would have to be selected somehow, using something more sophisticated
+   than a random process would seem justifiable.
+
+   That is, leaving in some intelligently selected critical additional
+   data is a trade-off between creating an optimization for those
+   resolvers that ignore the "should discard" recommendation and causing
+   a protocol problem by propagating inconsistent information about
+   "critical" records in the caches.
+
+   Similarly, leaving in the complete courtesy additional data RRsets
+   instead of removing all the RRsets is a performance trade-off as
+   described in the next section.
+
+
+
+
+
+
+Durand, et al.               Informational                     [Page 26]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+B.3.  Discussion of the Potential Problems
+
+   As noted above, the temptation for omitting only some of the
+   additional data could be problematic.  This is discussed more below.
+
+   For courtesy additional data, this causes a potential performance
+   problem as this requires that the clients issue re-queries for the
+   potentially omitted RRsets.  For critical additional data, this
+   causes a potential unrecoverable problem if the response is not
+   discarded and the query not re-tried with TCP, as the nameservers
+   might be reachable only through the omitted RRsets.
+
+   If an implementation would look at the transport used for the query,
+   it is worth remembering that often the host using the records is
+   different from the node requesting them from the authoritative DNS
+   server (or even a caching resolver).  So, whichever version the
+   requestor (e.g., a recursive server in the middle) uses makes no
+   difference to the ultimate user of the records, whose transport
+   capabilities might differ from those of the requestor.  This might
+   result in, e.g., inappropriately returning A records to an IPv6-only
+   node, going through a translation, or opening up another IP-level
+   session (e.g., a Packet Data Protocol (PDP) context [RFC4215]).
+   Therefore, at least in many scenarios, it would be very useful if the
+   information returned would be consistent and complete -- or if that
+   is not feasible, leave it to the client to query again.
+
+   The problem of too much additional data seems to be an operational
+   one: the zone administrator entering too many records that will be
+   returned truncated (or missing some RRsets, depending on
+   implementations) to the users.  A protocol fix for this is using
+   Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity
+   for larger UDP packet sizes, pushing up the relevant threshold.
+   Further, DNS server implementations should omit courtesy additional
+   data completely rather than including only some RRsets [RFC2181].  An
+   operational fix for this is having the DNS server implementations
+   return a warning when the administrators create zones that would
+   result in too much additional data being returned.  Further, DNS
+   server implementations should warn of or disallow such zone
+   configurations that are recursive or otherwise difficult to manage by
+   the protocol.
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.               Informational                     [Page 27]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+Authors' Addresses
+
+   Alain Durand
+   Comcast
+   1500 Market St.
+   Philadelphia, PA  19102
+   USA
+
+   EMail: Alain_Durand@cable.comcast.com
+
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm
+   Sweden
+
+   EMail: johani@autonomica.se
+
+
+   Pekka Savola
+   CSC/FUNET
+   Espoo
+   Finland
+
+   EMail: psavola@funet.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.               Informational                     [Page 28]
+
+RFC 4472              Considerations with IPv6 DNS            April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Durand, et al.               Informational                     [Page 29]
+
diff --git a/doc/rfc/rfc4509.txt b/doc/rfc/rfc4509.txt
new file mode 100644
index 000000000000..4eaf296c7baf
--- /dev/null
+++ b/doc/rfc/rfc4509.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        W. Hardaker
+Request for Comments: 4509                                        Sparta
+Category: Standards Track                                       May 2006
+
+
+ Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
+
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document 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 DNSKEYs in a child zone.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Implementing the SHA-256 Algorithm for DS Record Support ........2
+      2.1. DS Record Field Values .....................................2
+      2.2. DS Record with SHA-256 Wire Format .........................3
+      2.3. Example DS Record Using SHA-256 ............................3
+   3. Implementation Requirements .....................................3
+   4. Deployment Considerations .......................................4
+   5. IANA Considerations .............................................4
+   6. Security Considerations .........................................4
+      6.1. Potential Digest Type Downgrade Attacks ....................4
+      6.2. SHA-1 vs SHA-256 Considerations for DS Records .............5
+   7. Acknowledgements ................................................5
+   8. References ......................................................6
+      8.1. Normative References .......................................6
+      8.2. Informative References .....................................6
+
+
+
+
+
+
+
+
+Hardaker                    Standards Track                     [Page 1]
+
+RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
+
+
+1.  Introduction
+
+   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
+   zones to distribute a cryptographic digest of one key in a child's
+   DNSKEY RRset.  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, with a type covered of DS.
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in [RFC2119].
+
+2.  Implementing the SHA-256 Algorithm for DS Record Support
+
+   This document specifies that the digest type code 2 has been 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: 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 be 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.
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                    Standards Track                     [Page 2]
+
+RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
+
+
+2.2.  DS Record with SHA-256 Wire Format
+
+   The resulting on-the-wire format for the resulting DS record will be
+   as follows:
+
+                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |           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:
+
+   dskey.example.com. 86400 IN DS 60485 5 2   ( 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.
+
+
+
+
+
+
+Hardaker                    Standards Track                     [Page 3]
+
+RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
+
+
+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
+   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 cannot 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
+   has been assigned by IANA.
+
+   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 uses a different digest type.
+
+   o  A validator accepts a weaker digest even if a stronger one is
+      present but invalid.
+
+
+
+
+
+
+Hardaker                    Standards Track                     [Page 4]
+
+RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
+
+
+   For example, if the following conditions are all true:
+
+   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
+   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.  Acknowledgements
+
+   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                    Standards Track                     [Page 5]
+
+RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 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)", Work in
+                Progress.
+
+Author's Address
+
+   Wes Hardaker
+   Sparta
+   P.O. Box 382
+   Davis, CA  95617
+   USA
+
+   EMail: hardaker@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                    Standards Track                     [Page 6]
+
+RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Hardaker                    Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc4635.txt b/doc/rfc/rfc4635.txt
new file mode 100644
index 000000000000..554502dc91e6
--- /dev/null
+++ b/doc/rfc/rfc4635.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 4635                         Motorola Laboratories
+Category: Standards Track                                    August 2006
+
+
+                  HMAC SHA TSIG Algorithm Identifiers
+
+                          Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Use of the Domain Name System TSIG resource record requires
+   specification of a cryptographic message authentication code.
+   Currently, identifiers have been specified only for HMAC MD5 (Hashed
+   Message Authentication Code, Message Digest 5) and GSS (Generic
+   Security Service) TSIG algorithms.  This document standardizes
+   identifiers and implementation requirements for additional HMAC SHA
+   (Secure Hash Algorithm) TSIG algorithms and standardizes how to
+   specify and handle the truncation of HMAC values in TSIG.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Algorithms and Identifiers ......................................2
+   3. Specifying Truncation ...........................................3
+      3.1. Truncation Specification ...................................4
+   4. TSIG Truncation Policy and Error Provisions .....................4
+   5. IANA Considerations .............................................5
+   6. Security Considerations .........................................5
+   7. Normative References ............................................6
+   8. Informative References. .........................................7
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 1]
+
+RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
+
+
+1.  Introduction
+
+   [RFC2845] specifies a TSIG Resource Record (RR) that can be used to
+   authenticate DNS (Domain Name System [STD13]) queries and responses.
+   This RR contains a domain name syntax data item that names the
+   authentication algorithm used.  [RFC2845] defines the
+   HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC
+   (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5
+   (Message Digest 5) [RFC1321] hash algorithm.  IANA has also
+   registered "gss-tsig" as an identifier for TSIG authentication where
+   the cryptographic operations are delegated to the Generic Security
+   Service (GSS) [RFC3645].
+
+   Note that use of TSIG presumes prior agreement, between the resolver
+   and server involved, as to the algorithm and key to be used.
+
+   In Section 2, this document specifies additional names for TSIG
+   authentication algorithms based on US NIST SHA (United States,
+   National Institute of Science and Technology, Secure Hash Algorithm)
+   algorithms and HMAC and specifies the implementation requirements for
+   those algorithms.
+
+   In Section 3, this document specifies the effect of inequality
+   between the normal output size of the specified hash function and the
+   length of MAC (Message Authentication Code) data given in the TSIG
+   RR.  In particular, it specifies that a shorter-length field value
+   specifies truncation and that a longer-length field is an error.
+
+   In Section 4, policy restrictions and implications related to
+   truncation are described and specified, as is a new error code to
+   indicate truncation shorter than that permitted by policy.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in
+   this document are to be interpreted as described in [RFC2119].
+
+2.  Algorithms and Identifiers
+
+   TSIG Resource Records (RRs) [RFC2845] are used to authenticate DNS
+   queries and responses.  They are intended to be efficient symmetric
+   authentication codes based on a shared secret.  (Asymmetric
+   signatures can be provided using the SIG RR [RFC2931].  In
+   particular, SIG(0) can be used for transaction signatures.)  Used
+   with a strong hash function, HMAC [RFC2104] provides a way to
+   calculate such symmetric authentication codes.  The only specified
+   HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG-
+   ALG.REG.INT, based on MD5 [RFC1321].
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 2]
+
+RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
+
+
+   The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as
+   compared with the 128 bits for MD5, and additional hash algorithms in
+   the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and
+   512 bits may be preferred in some cases.  This is because
+   increasingly successful cryptanalytic attacks are being made on the
+   shorter hashes.
+
+   Use of TSIG between a DNS resolver and server is by mutual agreement.
+   That agreement can include the support of additional algorithms and
+   criteria as to which algorithms and truncations are acceptable,
+   subject to the restriction and guidelines in Sections 3 and 4 below.
+   Key agreement can be by the TKEY mechanism [RFC2930] or some other
+   mutually agreeable method.
+
+   The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
+   included in the table below for convenience.  Implementations that
+   support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
+   implement gss-tsig and the other algorithms listed below.
+
+      Mandatory      HMAC-MD5.SIG-ALG.REG.INT
+      Optional       gss-tsig
+      Mandatory      hmac-sha1
+      Optional       hmac-sha224
+      Mandatory      hmac-sha256
+      Optional       hamc-sha384
+      Optional       hmac-sha512
+
+   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
+
+3.  Specifying Truncation
+
+   When space is at a premium and the strength of the full length of an
+   HMAC is not needed, it is reasonable to truncate the HMAC output and
+   use the truncated value for authentication.  HMAC SHA-1 truncated to
+   96 bits is an option available in several IETF protocols, including
+   IPsec and TLS.
+
+   The TSIG RR [RFC2845] includes a "MAC size" field, which gives the
+   size of the MAC field in octets.  However, [RFC2845] does not specify
+   what to do if this MAC size differs from the length of the output of
+   HMAC for a particular hash function.  Truncation is indicated by a
+   MAC size less than the HMAC size, as specified below.
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 3]
+
+RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
+
+
+3.1.  Truncation Specification
+
+   The specification for TSIG handling is changed as follows:
+
+   1. If "MAC size" field is greater than HMAC output length:
+
+         This case MUST NOT be generated and, if received, MUST cause
+      the packet to be dropped and RCODE 1 (FORMERR) to be returned.
+
+   2. If "MAC size" field equals HMAC output length:
+
+         Operation is as described in [RFC2845], and the entire output
+      HMAC output is present.
+
+   3. "MAC size" field is less than HMAC output length but greater than
+      that specified in case 4, below:
+
+         This is sent when the signer has truncated the HMAC output to
+      an allowable length, as described in RFC 2104, taking initial
+      octets and discarding trailing octets.  TSIG truncation can only
+      be to an integral number of octets.  On receipt of a packet with
+      truncation thus indicated, the locally calculated MAC is similarly
+      truncated and only the truncated values are compared for
+      authentication.  The request MAC used when calculating the TSIG
+      MAC for a reply is the truncated request MAC.
+
+   4. "MAC size" field is less than the larger of 10 (octets) and half
+      the length of the hash function in use:
+
+         With the exception of certain TSIG error messages described in
+      RFC 2845, Section 3.2, where it is permitted that the MAC size be
+      zero, this case MUST NOT be generated and, if received, MUST cause
+      the packet to be dropped and RCODE 1 (FORMERR) to be returned.
+      The size limit for this case can also, for the hash functions
+      mentioned in this document, be stated as less than half the hash
+      function length for hash functions other than MD5 and less than 10
+      octets for MD5.
+
+4.  TSIG Truncation Policy and Error Provisions
+
+   Use of TSIG is by mutual agreement between a resolver and server.
+   Implicit in such "agreement" are criterion as to acceptable keys and
+   algorithms and, with the extensions in this document, truncations.
+   Note that it is common for implementations to bind the TSIG secret
+   key or keys that may be in place at a resolver and server to
+   particular algorithms.  Thus, such implementations only permit the
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 4]
+
+RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
+
+
+   use of an algorithm if there is an associated key in place.  Receipt
+   of an unknown, unimplemented, or disabled algorithm typically results
+   in a BADKEY error.
+
+      Local policies MAY require the rejection of TSIGs, even though
+   they use an algorithm for which implementation is mandatory.
+
+      When a local policy permits acceptance of a TSIG with a particular
+   algorithm and a particular non-zero amount of truncation, it SHOULD
+   also permit the use of that algorithm with lesser truncation (a
+   longer MAC) up to the full HMAC output.
+
+      Regardless of a lower acceptable truncated MAC length specified by
+   local policy, a reply SHOULD be sent with a MAC at least as long as
+   that in the corresponding request, unless the request specified a MAC
+   length longer than the HMAC output.
+
+      Implementations permitting multiple acceptable algorithms and/or
+   truncations SHOULD permit this list to be ordered by presumed
+   strength and SHOULD allow different truncations for the same
+   algorithm to be treated as separate entities in this list.  When so
+   implemented, policies SHOULD accept a presumed stronger algorithm and
+   truncation than the minimum strength required by the policy.
+
+      If a TSIG is received with truncation that is permitted under
+   Section 3 above but the MAC is too short for the local policy in
+   force, an RCODE of 22 (BADTRUNC) MUST be returned.
+
+5.  IANA Considerations
+
+   This document (1) registers the new TSIG algorithm identifiers listed
+   in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in
+   Section 4 [RFC2845].
+
+6.  Security Considerations
+
+   For all of the message authentication code algorithms listed herein,
+   those producing longer values are believed to be stronger; however,
+   while there have been some arguments that mild truncation can
+   strengthen a MAC by reducing the information available to an
+   attacker, excessive truncation clearly weakens authentication by
+   reducing the number of bits an attacker has to try to break the
+   authentication by brute force [RFC2104].
+
+   Significant progress has been made recently in cryptanalysis of hash
+   function of the types used herein, all of which ultimately derive
+   from the design of MD4.  While the results so far should not effect
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 5]
+
+RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
+
+
+   HMAC, the stronger SHA-1 and SHA-256 algorithms are being made
+   mandatory due to caution.
+
+   See the Security Considerations section of [RFC2845].  See also the
+   Security Considerations section of [RFC2104] from which the limits on
+   truncation in this RFC were taken.
+
+7.  Normative References
+
+   [FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US
+               Federal Information Processing Standard, with Change
+               Notice 1, February 2004.
+
+   [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
+               1321, April 1992.
+
+   [RFC2104]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+               Keyed-Hashing for Message Authentication", RFC 2104,
+               February 1997.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2845]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+               Wellington, "Secret Key Transaction Authentication for
+               DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC3174]   Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
+               1 (SHA1)", RFC 3174, September 2001.
+
+   [RFC3874]   Housley, R., "A 224-bit One-way Hash Function: SHA-224",
+               RFC 3874, September 2004.
+
+   [RFC4634]   Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
+               (SHA)", RFC 4634, July 2006.
+
+   [STD13]     Mockapetris, P., "Domain names - concepts and
+               facilities", STD 13, RFC 1034, November 1987.
+
+               Mockapetris, P., "Domain names - implementation and
+               specification", STD 13, RFC 1035, November 1987.
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 6]
+
+RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
+
+
+8.  Informative References.
+
+   [RFC2930]   Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+               RR)", RFC 2930, September 2000.
+
+   [RFC2931]   Eastlake 3rd, D., "DNS Request and Transaction Signatures
+               ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3645]   Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
+               and R. Hall, "Generic Security Service Algorithm for
+               Secret Key Transaction Authentication for DNS (GSS-
+               TSIG)", RFC 3645, October 2003.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Phone: +1-508-786-7554 (w)
+   EMail: Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 7]
+
+RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc4697.txt b/doc/rfc/rfc4697.txt
new file mode 100644
index 000000000000..773507ca6904
--- /dev/null
+++ b/doc/rfc/rfc4697.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                          M. Larson
+Request for Comments: 4697                                     P. Barber
+BCP: 123                                                  VeriSign, Inc.
+Category: Best Current Practice                             October 2006
+
+
+                  Observed DNS Resolution Misbehavior
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (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.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. A Note about Terminology in this Memo ......................3
+      1.2. Key Words ..................................................3
+   2. Observed Iterative Resolver Misbehavior .........................3
+      2.1. Aggressive Requerying for Delegation Information ...........3
+           2.1.1. Recommendation ......................................5
+      2.2. Repeated Queries to Lame Servers ...........................6
+           2.2.1. Recommendation ......................................6
+      2.3. Inability to Follow Multiple Levels of Indirection .........7
+           2.3.1. Recommendation ......................................7
+      2.4. Aggressive Retransmission when Fetching Glue ...............8
+           2.4.1. Recommendation ......................................9
+      2.5. Aggressive Retransmission behind Firewalls .................9
+           2.5.1. Recommendation .....................................10
+      2.6. Misconfigured NS Records ..................................10
+           2.6.1. Recommendation .....................................11
+
+
+
+
+Larson & Barber          Best Current Practice                  [Page 1]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+      2.7. Name Server Records with Zero TTL .........................11
+           2.7.1. Recommendation .....................................12
+      2.8. Unnecessary Dynamic Update Messages .......................12
+           2.8.1. Recommendation .....................................13
+      2.9. Queries for Domain Names Resembling IPv4 Addresses ........13
+           2.9.1. Recommendation .....................................14
+      2.10. Misdirected Recursive Queries ............................14
+           2.10.1. Recommendation ....................................14
+      2.11. Suboptimal Name Server Selection Algorithm ...............15
+           2.11.1. Recommendation ....................................15
+   3. Security Considerations ........................................16
+   4. Acknowledgements ...............................................16
+   5. Internationalization Considerations ............................16
+   6. References .....................................................16
+      6.1. Normative References ......................................16
+      6.2. Informative References ....................................16
+
+1.  Introduction
+
+   Observation of query traffic received by two root name servers and
+   the thirteen com/net Top-Level Domain (TLD) name servers has revealed
+   that a large proportion of the total traffic often consists of
+   "requeries".  A requery is the same question ()
+   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 (Denial of Service (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.
+
+
+
+
+
+Larson & Barber          Best Current Practice                  [Page 2]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+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 can 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",
+   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.
+
+1.2.  Key Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+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
+
+
+
+Larson & Barber          Best Current Practice                  [Page 3]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+   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 that
+   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
+   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
+
+
+
+Larson & Barber          Best Current Practice                  [Page 4]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+   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 Time to Live (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
+   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].
+
+
+
+
+Larson & Barber          Best Current Practice                  [Page 5]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+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 is
+   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 do not 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 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.
+
+   Implementations that perform lame server caching MUST refrain from
+   sending queries to known lame servers for a configurable time
+   interval after the server is discovered to be lame.  A minimum
+   interval of thirty minutes is RECOMMENDED.
+
+
+
+
+
+
+
+
+Larson & Barber          Best Current Practice                  [Page 6]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+   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 that 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".  Although 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.
+
+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
+
+
+
+Larson & Barber          Best Current Practice                  [Page 7]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+   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
+   prevents it from receiving responses.  If this is the case, all
+   glue-fetching queries will go unanswered.
+
+   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
+
+
+
+Larson & Barber          Best Current Practice                  [Page 8]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+   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 cannot 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
+   servers, which could explain how such a situation could persist
+   without being detected.
+
+
+
+
+
+
+
+
+Larson & Barber          Best Current Practice                  [Page 9]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+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, but not the resulting replies, to pass through.
+
+   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.1 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"
+   authoritative server.
+
+
+
+
+
+Larson & Barber          Best Current Practice                 [Page 10]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+   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
+   that 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
+   zone parent/child relationships that we are aware of, there is
+
+
+
+Larson & Barber          Best Current Practice                 [Page 11]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+   typically some delay involved in effecting changes.  Furthermore,
+   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 Start of Authority (SOA)
+   record's 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 successful.  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
+
+
+
+Larson & Barber          Best Current Practice                 [Page 12]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+   "internal root" design, there could conceivably be private, non-
+   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 the 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 that 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 that 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".
+
+
+
+
+
+
+
+Larson & Barber          Best Current Practice                 [Page 13]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+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
+   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
+   (http://www.as112.net), 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 Recursion Desired (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 notified immediately 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.
+
+
+
+
+
+
+
+
+Larson & Barber          Best Current Practice                 [Page 14]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+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.
+
+   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.  That is, 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 twelve 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          Best Current Practice                 [Page 15]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+3.  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.
+
+4.  Acknowledgements
+
+   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.
+
+5.  Internationalization Considerations
+
+   There are no new internationalization considerations introduced by
+   this memo.
+
+6.  References
+
+6.1.  Normative 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.
+
+6.2.  Informative References
+
+   [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.
+
+
+
+Larson & Barber          Best Current Practice                 [Page 16]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+   [7]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E.
+        Lear, "Address Allocation for Private Internets", BCP 5, RFC
+        1918, February 1996.
+
+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          Best Current Practice                 [Page 17]
+
+RFC 4697          Observed DNS Resolution Misbehavior       October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Larson & Barber          Best Current Practice                 [Page 18]
+
diff --git a/doc/rfc/rfc4892.txt b/doc/rfc/rfc4892.txt
new file mode 100644
index 000000000000..a89d3fb0892f
--- /dev/null
+++ b/doc/rfc/rfc4892.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                           S. Woolf
+Request for Comments: 4892             Internet Systems Consortium, Inc.
+Category: Informational                                        D. Conrad
+                                                                   ICANN
+                                                               June 2007
+
+
+    Requirements for a Mechanism Identifying a Name Server Instance
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+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
+   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.
+
+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.
+
+
+
+
+
+Woolf & Conrad               Informational                      [Page 1]
+
+RFC 4892                        Serverid                       June 2007
+
+
+   The conventional 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 associated with DNS (or any other) service somewhat
+   problematic.  Specifically, multiple dedicated DNS queries may not go
+   to the same server 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 A.B.C.D".
+   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.
+
+2.  Existing Conventions
+
+   For some time, the commonly deployed Berkeley Internet Name Domain
+   (BIND) 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 label, replaces "BIND." with "SERVER.".  Thus
+   the query label to learn the unique name of a server may appear 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
+
+
+
+Woolf & Conrad               Informational                      [Page 2]
+
+RFC 4892                        Serverid                       June 2007
+
+
+   administratively defined string which defaults to the software
+   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.
+
+   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.
+
+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.
+
+
+
+
+Woolf & Conrad               Informational                      [Page 3]
+
+RFC 4892                        Serverid                       June 2007
+
+
+   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 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 aforementioned refinement changes
+       the query label 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 contain, including a possible encoding or
+       authentication mechanism.
+
+   5.  Hypothetically, since DNSSEC has been defined to cover all DNS
+       classes, the TXT RRs returned in response to the "ID.SERVER."
+       query could be signed, which has the advantages described in
+       [RFC4033].  However, since DNSSEC deployment for the CHAOS class
+       is neither existent nor foreseeable, and since the "ID.SERVER."
+       TXT RR is expected to be unique per server, this would be
+       impossible in practice.
+
+   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, "I need to know what nameserver is answering my queries",
+   not simply a convenient one.
+
+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
+
+
+
+
+Woolf & Conrad               Informational                      [Page 4]
+
+RFC 4892                        Serverid                       June 2007
+
+
+       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.
+
+4.  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.
+
+5.  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 server identification 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 the 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.
+
+
+
+
+
+Woolf & Conrad               Informational                      [Page 5]
+
+RFC 4892                        Serverid                       June 2007
+
+
+   Both authentication and confidentiality of server identification data
+   are potentially of interest to administrators -- that is, operators
+   may wish to make such data available and reliable to themselves and
+   their chosen associates only.  This constraint would imply both an
+   ability to authenticate it to themselves and to keep it private from
+   arbitrary other parties, which leads to characteristics 4 and 5 of an
+   improved solution.
+
+6.  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 versions 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.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC3258]  Hardie, T., "Distributing Authoritative Name Servers via
+              Shared Unicast Addresses", RFC 3258, April 2002.
+
+7.2.  Informative References
+
+   [BIND]     ISC, "BIND 9 Configuration Reference".
+
+   [NSID]     Austein, R., "DNS Name Server Identifier Option (NSID)",
+              Work in Progress, June 2006.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, March 2005.
+
+
+
+
+
+
+
+Woolf & Conrad               Informational                      [Page 6]
+
+RFC 4892                        Serverid                       June 2007
+
+
+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
+   ICANN
+   4676 Admiralty Way
+   Marina del Rey, CA  90292
+   US
+
+   Phone: +1 310 823 9358
+   EMail: david.conrad@icann.org
+   URI:   http://www.iana.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad               Informational                      [Page 7]
+
+RFC 4892                        Serverid                       June 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+Woolf & Conrad               Informational                      [Page 8]
+
diff --git a/doc/rfc/rfc4955.txt b/doc/rfc/rfc4955.txt
new file mode 100644
index 000000000000..2d2eb84e0fb8
--- /dev/null
+++ b/doc/rfc/rfc4955.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          D. Blacka
+Request for Comments: 4955                                VeriSign, Inc.
+Category: Standards Track                                      July 2007
+
+
+                   DNS Security (DNSSEC) Experiments
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document describes a methodology for deploying alternate, non-
+   backwards-compatible, DNS Security (DNSSEC) methodologies in an
+   experimental fashion without disrupting the deployment of standard
+   DNSSEC.
+
+Table of Contents
+
+   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
+   3.  Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   4.  Method  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   5.  Defining an Experiment  . . . . . . . . . . . . . . . . . . . . 4
+   6.  Considerations  . . . . . . . . . . . . . . . . . . . . . . . . 5
+   7.  Use in Non-Experiments  . . . . . . . . . . . . . . . . . . . . 5
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
+     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                      Standards Track                     [Page 1]
+
+RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
+
+
+1.  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 coexistence
+   with standard DNSSEC and DNS by using unknown algorithm identifiers
+   to hide the experimental DNSSEC protocol modifications from standard
+   security-aware resolvers.
+
+2.  Definitions and Terminology
+
+   Throughout this document, familiarity with the DNS system (RFC 1035
+   [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and
+   RFC 4035 [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].
+
+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                      Standards Track                     [Page 2]
+
+RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
+
+
+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 RFC 4035 [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.
+
+   Although this behavior isn't strictly mandatory (as marked by MUST),
+   it is unlikely for a validator to implement a substantially different
+   behavior.  Essentially, if the validator does not have a usable chain
+   of trust to a child zone, then it can only do one of two things:
+   treat responses from the zone as insecure (the recommended behavior),
+   or treat the responses as bogus.  If the validator chooses the
+   latter, this will both violate the expectation of the zone owner and
+   defeat the purpose of the above rule.  However, with local policy, it
+   is within the right of a validator to refuse to trust certain zones
+   based on any criteria, including the use of unknown signing
+   algorithms.
+
+   Because we are talking about experiments, it is RECOMMENDED that
+   private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1.
+   Note that secure handling of private algorithms requires special
+   handing by the validator logic.  See "Clarifications and
+   Implementation Notes for DNSSECbis" [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.
+
+
+
+Blacka                      Standards Track                     [Page 3]
+
+RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
+
+
+   It is RECOMMENDED that for a particular DNSSEC experiment, a
+   particular domain name base is chosen for all new algorithms, then
+   the algorithm number (or name) is prepended to it.  For example, for
+   experiment A, the base name of "dnssec-experiment-a.example.com" is
+   chosen.  Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
+   defined to be "3.dnssec-experiment-a.example.com" and
+   "5.dnssec-experiment-a.example.com".  However, any unique identifier
+   will 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 possible to validate experimentally,
+   or it is not.
+
+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
+   Object Identifier (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).
+
+
+
+Blacka                      Standards Track                     [Page 4]
+
+RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
+
+
+   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.
+
+6.  Considerations
+
+   There are a number of considerations with using this methodology.
+
+   1.  If an unaware validator does not correctly follow the rules laid
+       out in RFC 4035 (e.g., the validator interprets a DNSSEC record
+       prior to validating it), or if the experiment is broader in scope
+       that just modifying the DNSSEC semantics, the experiment may not
+       be sufficiently masked by this technique.  This may cause
+       unintended resolution failures.
+
+   2.  It will not be possible for security-aware resolvers unaware of
+       the experiment to build a chain of trust through an experimental
+       zone.
+
+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.
+
+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.
+
+   Implementers should take into account any security issues that may
+   result from environments being configured to trust both experimental
+   and non-experimental zones.  If the experimental zone is more
+
+
+
+Blacka                      Standards Track                     [Page 5]
+
+RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
+
+
+   vulnerable to attacks, it could, for example, be used to promote
+   trust in zones not part of the experiment, possibly under the control
+   of an attacker.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  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.
+
+9.2.  Informative References
+
+   [5]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [6]  Weiler, S. and R. Austein, "Clarifications and Implementation
+        Notes for DNSSECbis", Work in Progress, March 2007.
+
+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                      Standards Track                     [Page 6]
+
+RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+Blacka                      Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc4956.txt b/doc/rfc/rfc4956.txt
new file mode 100644
index 000000000000..536c680cbafc
--- /dev/null
+++ b/doc/rfc/rfc4956.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4956                                       Nominet
+Category: Experimental                                        M. Kosters
+                                                               D. Blacka
+                                                          VeriSign, Inc.
+                                                               July 2007
+
+
+                      DNS Security (DNSSEC) Opt-In
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   In the DNS security (DNSSEC) extensions, delegations to unsigned
+   subzones are cryptographically secured.  Maintaining this
+   cryptography is not always practical or necessary.  This document
+   describes an experimental "Opt-In" model that allows administrators
+   to omit this cryptography and manage the cost of adopting DNSSEC with
+   large zones.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 1]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+Table of Contents
+
+   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
+   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Server Considerations  . . . . . . . . . . . . . . . . . .  6
+       4.1.1.  Delegations Only . . . . . . . . . . . . . . . . . . .  6
+       4.1.2.  Insecure Delegation Responses  . . . . . . . . . . . .  6
+       4.1.3.  Dynamic Update . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  Client Considerations  . . . . . . . . . . . . . . . . . .  7
+       4.2.1.  Delegations Only . . . . . . . . . . . . . . . . . . .  7
+       4.2.2.  Validation Process Changes . . . . . . . . . . . . . .  7
+       4.2.3.  NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
+       4.2.4.  Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
+   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  Implementing Opt-In Using "Views" . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 2]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+1.  Overview
+
+   The cost to cryptographically secure delegations to unsigned zones is
+   high for large delegation-centric zones and zones where insecure
+   delegations will be updated rapidly.  For these zones, the costs of
+   maintaining the NextSECure (NSEC) record chain may be extremely high
+   relative to the gain of cryptographically authenticating existence of
+   unsecured zones.
+
+   This document describes an experimental method of eliminating the
+   superfluous cryptography present in secure delegations to unsigned
+   zones.  Using "Opt-In", a zone administrator can choose to remove
+   insecure delegations from the NSEC chain.  This is accomplished by
+   extending the semantics of the NSEC record by using a redundant bit
+   in the type map.
+
+2.  Definitions and Terminology
+
+   Throughout this document, familiarity with the DNS system (RFC 1035
+   [1]), DNS security extensions ([4], [5], and [6], referred to in this
+   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
+   [10]) is assumed.
+
+   The following abbreviations and terms are used in this document:
+
+   RR:  is used to refer to a DNS resource record.
+
+   RRset:  refers to a Resource Record Set, as defined by [8].  In this
+      document, the RRset is also defined to include the covering RRSIG
+      records, if any exist.
+
+   signed name:  refers to a DNS name that has, at minimum, a (signed)
+      NSEC record.
+
+   unsigned name:  refers to a DNS name that does not (at least) have an
+      NSEC record.
+
+   covering NSEC record/RRset:  is the NSEC record used to prove
+      (non)existence of a particular name or RRset.  This means that for
+      a RRset or name 'N', the covering NSEC record has the name 'N', or
+      has an owner name less than 'N' and "next" name greater than 'N'.
+
+   delegation:  refers to an NS RRset with a name different from the
+      current zone apex (non-zone-apex), signifying a delegation to a
+      subzone.
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 3]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   secure delegation:  refers to a signed name containing a delegation
+      (NS RRset), and a signed DS RRset, signifying a delegation to a
+      signed subzone.
+
+   insecure delegation:  refers to a signed name containing a delegation
+      (NS RRset), but lacking a DS RRset, signifying a delegation to an
+      unsigned subzone.
+
+   Opt-In insecure delegation:  refers to an unsigned name containing
+      only a delegation NS RRset.  The covering NSEC record uses the
+      Opt-In methodology described in this document.
+
+   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+3.  Experimental Status
+
+   This document describes an EXPERIMENTAL extension to DNSSEC.  It
+   interoperates with non-experimental DNSSEC using the technique
+   described in [7].  This experiment is identified with the following
+   private algorithms (using algorithm 253):
+
+   "3.optin.verisignlabs.com":  is an alias for DNSSEC algorithm 3, DSA,
+      and
+
+   "5.optin.verisignlabs.com":  is an alias for DNSSEC algorithm 5,
+      RSASHA1.
+
+   Servers wishing to sign and serve zones that utilize Opt-In MUST sign
+   the zone with only one or more of these private algorithms and MUST
+   NOT use any other algorithms.
+
+   Resolvers MUST NOT apply the Opt-In validation rules described in
+   this document unless a zone is signed using one or more of these
+   private algorithms.
+
+   This experimental protocol relaxes the restriction that validators
+   MUST ignore the setting of the NSEC bit in the type map as specified
+   in RFC 4035 [6] Section 5.4.
+
+   The remainder of this document assumes that the servers and resolvers
+   involved are aware of and are involved in this experiment.
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 4]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+4.  Protocol Additions
+
+   In DNSSEC, delegation NS RRsets are not signed, but are instead
+   accompanied by an NSEC RRset of the same name and (possibly) a DS
+   record.  The security status of the subzone is determined by the
+   presence or absence of the DS RRset, cryptographically proven by the
+   NSEC record.  Opt-In expands this definition by allowing insecure
+   delegations to exist within an otherwise signed zone without the
+   corresponding NSEC record at the delegation's owner name.  These
+   insecure delegations are proven insecure by using a covering NSEC
+   record.
+
+   Since this represents a change of the interpretation of NSEC records,
+   resolvers must be able to distinguish between RFC standard DNSSEC
+   NSEC records and Opt-In NSEC records.  This is accomplished by
+   "tagging" the NSEC records that cover (or potentially cover) insecure
+   delegation nodes.  This tag is indicated by the absence of the NSEC
+   bit in the type map.  Since the NSEC bit in the type map merely
+   indicates the existence of the record itself, this bit is redundant
+   and safe for use as a tag.
+
+   An Opt-In tagged NSEC record does not assert the (non)existence of
+   the delegations that it covers (except for a delegation with the same
+   name).  This allows for the addition or removal of these delegations
+   without recalculating or resigning records in the NSEC chain.
+   However, Opt-In tagged NSEC records do assert the (non)existence of
+   other RRsets.
+
+   An Opt-In NSEC record MAY have the same name as an insecure
+   delegation.  In this case, the delegation is proven insecure by the
+   lack of a DS bit in the type map, and the signed NSEC record does
+   assert the existence of the delegation.
+
+   Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
+   records and standard DNSSEC NSEC records.  If an NSEC record is not
+   Opt-In, there MUST NOT be any insecure delegations (or any other
+   records) between it and the RRsets indicated by the 'next domain
+   name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
+   insecure delegations between it and the next node indicated by the
+   'next domain name' in the NSEC RDATA.
+
+   In summary,
+
+   o  An Opt-In NSEC type is identified by a zero-valued (or not-
+      specified) NSEC bit in the type bit map of the NSEC record.
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 5]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   o  A standard DNSSEC NSEC type is identified by a one-valued NSEC bit
+      in the type bit map of the NSEC record.
+
+   and
+
+   o  An Opt-In NSEC record does not assert the non-existence of a name
+      between its owner name and "next" name, although it does assert
+      that any name in this span MUST be an insecure delegation.
+
+   o  An Opt-In NSEC record does assert the (non)existence of RRsets
+      with the same owner name.
+
+4.1.  Server Considerations
+
+   Opt-In imposes some new requirements on authoritative DNS servers.
+
+4.1.1.  Delegations Only
+
+   This specification dictates that only insecure delegations may exist
+   between the owner and "next" names of an Opt-In tagged NSEC record.
+   Signing tools MUST NOT generate signed zones that violate this
+   restriction.  Servers MUST refuse to load and/or serve zones that
+   violate this restriction.  Servers also MUST reject AXFR or IXFR
+   responses that violate this restriction.
+
+4.1.2.  Insecure Delegation Responses
+
+   When returning an Opt-In insecure delegation, the server MUST return
+   the covering NSEC RRset in the Authority section.
+
+   In standard DNSSEC, NSEC records already must be returned along with
+   the insecure delegation.  The primary difference that this proposal
+   introduces is that the Opt-In tagged NSEC record will have a
+   different owner name from the delegation RRset.  This may require
+   implementations to search for the covering NSEC RRset.
+
+4.1.3.  Dynamic Update
+
+   Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
+   particular, it introduces the need for rules that describe when to
+   add or remove a delegation name from the NSEC chain.  This document
+   does not attempt to define these rules.  Until these rules are
+   defined, servers MUST NOT process DNS Dynamic Update requests against
+   zones that use Opt-In NSEC records.  Servers SHOULD return responses
+   to update requests with RCODE=REFUSED.
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 6]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+4.2.  Client Considerations
+
+   Opt-In imposes some new requirements on security-aware resolvers
+   (caching or otherwise).
+
+4.2.1.  Delegations Only
+
+   As stated in Section 4.1 above, this specification restricts the
+   namespace covered by Opt-In tagged NSEC records to insecure
+   delegations only.  Clients are not expected to take any special
+   measures to enforce this restriction; instead, it forms an underlying
+   assumption that clients may rely on.
+
+4.2.2.  Validation Process Changes
+
+   This specification does not change the resolver's resolution
+   algorithm.  However, it does change the DNSSEC validation process.
+
+4.2.2.1.  Referrals
+
+   Resolvers MUST be able to use Opt-In tagged NSEC records to
+   cryptographically prove the validity and security status (as
+   insecure) of a referral.  Resolvers determine the security status of
+   the referred-to zone as follows:
+
+   o  In standard DNSSEC, the security status is proven by the existence
+      or absence of a DS RRset at the same name as the delegation.  The
+      existence of the DS RRset indicates that the referred-to zone is
+      signed.  The absence of the DS RRset is proven using a verified
+      NSEC record of the same name that does not have the DS bit set in
+      the type map.  This NSEC record MAY also be tagged as Opt-In.
+
+   o  Using Opt-In, the security status is proven by the existence of a
+      DS record (for signed) or the presence of a verified Opt-In tagged
+      NSEC record that covers the delegation name.  That is, the NSEC
+      record does not have the NSEC bit set in the type map, and the
+      delegation name falls between the NSEC's owner and "next" name.
+
+   Using Opt-In does not substantially change the nature of following
+   referrals within DNSSEC.  At every delegation point, the resolver
+   will have cryptographic proof that the referred-to subzone is signed
+   or unsigned.
+
+4.2.2.2.  Queries for DS Resource Records
+
+   Since queries for DS records are directed to the parent side of a
+   zone cut (see [5], Section 5), negative responses to these queries
+   may be covered by an Opt-In flagged NSEC record.
+
+
+
+Arends, et al.                Experimental                      [Page 7]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   Resolvers MUST be able to use Opt-In tagged NSEC records to
+   cryptographically prove the validity and security status of negative
+   responses to queries for DS records.  In particular, a NOERROR/NODATA
+   (i.e., RCODE=3, but the answer section is empty) response to a DS
+   query may be proven by an Opt-In flagged covering NSEC record, rather
+   than an NSEC record matching the query name.
+
+4.2.3.  NSEC Record Caching
+
+   Caching resolvers MUST be able to retrieve the appropriate covering
+   Opt-In NSEC record when returning referrals that need them.  This
+   requirement differs from standard DNSSEC in that the covering NSEC
+   will not have the same owner name as the delegation.  Some
+   implementations may have to use new methods for finding these NSEC
+   records.
+
+4.2.4.  Use of the AD bit
+
+   The AD bit, as defined by [3] and [6], MUST NOT be set when:
+
+   o  sending a Name Error (RCODE=3) response where the covering NSEC is
+      tagged as Opt-In.
+
+   o  sending an Opt-In insecure delegation response, unless the
+      covering (Opt-In) NSEC record's owner name equals the delegation
+      name.
+
+   o  sending a NOERROR/NODATA response when query type is DS and the
+      covering NSEC is tagged as Opt-In, unless NSEC record's owner name
+      matches the query name.
+
+   This rule is based on what the Opt-In NSEC record actually proves:
+   for names that exist between the Opt-In NSEC record's owner and
+   "next" names, the Opt-In NSEC record cannot prove the non-existence
+   or existence of the name.  As such, not all data in the response has
+   been cryptographically verified, so the AD bit cannot be set.
+
+5.  Benefits
+
+   Using Opt-In allows administrators of large and/or changing
+   delegation-centric zones to minimize the overhead involved in
+   maintaining the security of the zone.
+
+   Opt-In accomplishes this by eliminating the need for NSEC records for
+   insecure delegations.  This, in a zone with a large number of
+   delegations to unsigned subzones, can lead to substantial space
+   savings (both in memory and on disk).  Additionally, Opt-In allows
+   for the addition or removal of insecure delegations without modifying
+
+
+
+Arends, et al.                Experimental                      [Page 8]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   the NSEC record chain.  Zones that are frequently updating insecure
+   delegations (e.g., Top-Level Domains (TLDs)) can avoid the
+   substantial overhead of modifying and resigning the affected NSEC
+   records.
+
+6.  Example
+
+   Consider the zone EXAMPLE shown below.  This is a zone where all of
+   the NSEC records are tagged as Opt-In.
+
+   Example A: Fully Opt-In Zone.
+
+         EXAMPLE.               SOA    ...
+         EXAMPLE.               RRSIG  SOA ...
+         EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
+         EXAMPLE.               RRSIG  NS ...
+         EXAMPLE.               DNSKEY ...
+         EXAMPLE.               RRSIG  DNSKEY ...
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
+                                       SOA NS RRSIG DNSKEY )
+         EXAMPLE.               RRSIG  NSEC ...
+
+         FIRST-SECURE.EXAMPLE.  A      ...
+         FIRST-SECURE.EXAMPLE.  RRSIG  A ...
+         FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
+         FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
+
+         NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
+         NS.NOT-SECURE.EXAMPLE. A      ...
+
+         NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
+         NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
+         NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
+
+         SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
+         SECOND-SECURE.EXAMPLE. DS     ...
+         SECOND-SECURE.EXAMPLE. RRSIG  DS ...
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+
+                                Example A.
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 9]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   In this example, a query for a signed RRset (e.g., "FIRST-
+   SECURE.EXAMPLE A") or a secure delegation ("WWW.SECOND-SECURE.EXAMPLE
+   A") will result in a standard DNSSEC response.
+
+   A query for a nonexistent RRset will result in a response that
+   differs from standard DNSSEC by the following: the NSEC record will
+   be tagged as Opt-In, there may be no NSEC record proving the non-
+   existence of a matching wildcard record, and the AD bit will not be
+   set.
+
+   A query for an insecure delegation RRset (or a referral) will return
+   both the answer (in the Authority section) and the corresponding
+   Opt-In NSEC record to prove that it is not secure.
+
+   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
+
+
+         RCODE=NOERROR, AD=0
+
+         Answer Section:
+
+         Authority Section:
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         Additional Section:
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+                                Example A.1
+
+   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
+   NSEC record, because there are no insecure delegations that occur
+   between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
+   Example A would still be a valid zone if the NSEC record for EXAMPLE.
+   was changed to the following RR:
+
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
+                                       RRSIG DNSKEY NSEC )
+
+   However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
+   SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
+   delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
+   UNSIGNED.EXAMPLE., respectively).
+
+   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
+   part of the NSEC chain and also covered by an Opt-In tagged NSEC
+   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
+
+
+
+Arends, et al.                Experimental                     [Page 10]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   removed from the zone without modifying and resigning the prior NSEC
+   record.  Delegations with names that fall between NOT-SECURE-
+   2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
+   resigning any NSEC records.
+
+7.  Transition Issues
+
+   Opt-In is not backwards compatible with standard DNSSEC and is
+   considered experimental.  Standard DNSSEC-compliant implementations
+   would not recognize Opt-In tagged NSEC records as different from
+   standard NSEC records.  Because of this, standard DNSSEC
+   implementations, if they were to validate Opt-In style responses,
+   would reject all Opt-In insecure delegations within a zone as
+   invalid.  However, by only signing with private algorithms, standard
+   DNSSEC implementations will treat Opt-In responses as unsigned.
+
+   It should be noted that all elements in the resolution path between
+   (and including) the validator and the authoritative name server must
+   be aware of the Opt-In experiment and implement the Opt-In semantics
+   for successful validation to be possible.  In particular, this
+   includes any caching middleboxes between the validator and
+   authoritative name server.
+
+8.  Security Considerations
+
+   Opt-In allows for unsigned names, in the form of delegations to
+   unsigned subzones, to exist within an otherwise signed zone.  All
+   unsigned names are, by definition, insecure, and their validity or
+   existence cannot be cryptographically proven.
+
+   In general:
+
+   o  Records with unsigned names (whether or not existing) suffer from
+      the same vulnerabilities as records in an unsigned zone.  These
+      vulnerabilities are described in more detail in [12] (note in
+      particular Sections 2.3, "Name Games" and 2.6, "Authenticated
+      Denial").
+
+   o  Records with signed names have the same security whether or not
+      Opt-In is used.
+
+   Note that with or without Opt-In, an insecure delegation may have its
+   contents undetectably altered by an attacker.  Because of this, the
+   primary difference in security that Opt-In introduces is the loss of
+   the ability to prove the existence or nonexistence of an insecure
+   delegation within the span of an Opt-In NSEC record.
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 11]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   In particular, this means that a malicious entity may be able to
+   insert or delete records with unsigned names.  These records are
+   normally NS records, but this also includes signed wildcard
+   expansions (while the wildcard record itself is signed, its expanded
+   name is an unsigned name), which can be undetectably removed or used
+   to replace an existing unsigned delegation.
+
+   For example, if a resolver received the following response from the
+   example zone above:
+
+   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
+
+         RCODE=NOERROR
+
+         Answer Section:
+
+         Authority Section:
+         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
+         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
+                                        RRSIG DNSKEY
+         EXAMPLE.                RRSIG  NSEC ...
+
+         Additional Section:
+
+
+                        Attacker has forged a name
+
+   The resolver would have no choice but to believe that the referral to
+   NS.FORGED. is valid.  If a wildcard existed that would have been
+   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+   have undetectably removed it and replaced it with the forged
+   delegation.
+
+   Note that being able to add a delegation is functionally equivalent
+   to being able to add any record type: an attacker merely has to forge
+   a delegation to the nameserver under his/her control and place
+   whatever records are needed at the subzone apex.
+
+   While in particular cases, this issue may not present a significant
+   security problem, in general it should not be lightly dismissed.
+   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+   In particular, zone signing tools SHOULD NOT default to Opt-In, and
+   MAY choose not to support Opt-In at all.
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 12]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+9.  Acknowledgments
+
+   The contributions, suggestions, and remarks of the following persons
+   (in alphabetic order) to this document are acknowledged:
+
+      Mats Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill
+      Manning, Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter,
+      Brian Wellington.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]   Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+         Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033,
+         March 2005.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions",
+         RFC 4035, March 2005.
+
+   [7]   Blacka, D., "DNSSEC Experiments", RFC 4955, July 2007.
+
+10.2.  Informative References
+
+   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+         RFC 2181, July 1997.
+
+   [9]   Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
+         Status", RFC 3090, March 2001.
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 13]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
+         December 2001.
+
+   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+         System (DNS)", RFC 3833, August 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 14]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+Appendix A.  Implementing Opt-In Using "Views"
+
+   In many cases, it may be convenient to implement an Opt-In zone by
+   combining two separately maintained "views" of a zone at request
+   time.  In this context, "view" refers to a particular version of a
+   zone, not to any specific DNS implementation feature.
+
+   In this scenario, one view is the secure view, the other is the
+   insecure (or legacy) view.  The secure view consists of an entirely
+   signed zone using Opt-In tagged NSEC records.  The insecure view
+   contains no DNSSEC information.  It is helpful, although not
+   necessary, for the secure view to be a subset (minus DNSSEC records)
+   of the insecure view.
+
+   In addition, the only RRsets that may solely exist in the insecure
+   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
+   the zone apex NS RRset) MUST be signed and in the secure view.
+
+   These two views may be combined at request time to provide a virtual,
+   single Opt-In zone.  The following algorithm is used when responding
+   to each query:
+
+      V_A is the secure view as described above.
+
+      V_B is the insecure view as described above.
+
+      R_A is a response generated from V_A, following standard DNSSEC.
+
+      R_B is a response generated from V_B, following DNS resolution as
+      per RFC 1035 [1].
+
+      R_C is the response generated by combining R_A with R_B, as
+      described below.
+
+      A query is DNSSEC-aware if it either has the DO bit [11] turned on
+      or is for a DNSSEC-specific record type.
+
+   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
+       generate and return R_B, otherwise
+
+   2.  Generate R_A.
+
+   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 15]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   4.  Generate R_B and combine it with R_A to form R_C:
+
+          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
+          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
+          record, if R_B's RCODE = NOERROR.
+
+   5.  Return R_C.
+
+Authors' Addresses
+
+   Roy Arends
+   Nominet
+   Sandford Gate
+   Sandy Lane West
+   Oxford  OX4 6LB
+   UNITED KINGDOM
+
+   Phone: +44 1865 332211
+   EMail: roy@nominet.org.uk
+
+
+   Mark Kosters
+   VeriSign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   EMail: mkosters@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+   David Blacka
+   VeriSign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   EMail: davidb@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 16]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 17]
+
diff --git a/doc/rfc/rfc5001.txt b/doc/rfc/rfc5001.txt
new file mode 100644
index 000000000000..fe153393694b
--- /dev/null
+++ b/doc/rfc/rfc5001.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 5001                                           ISC
+Category: Standards Track                                    August 2007
+
+
+                DNS Name Server Identifier (NSID) Option
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+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
+   mechanisms 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 that 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                     Standards Track                     [Page 1]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  3
+     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  3
+     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
+     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  4
+   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  7
+     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  7
+     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  8
+   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+
+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 that 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.
+
+
+
+
+
+
+
+
+Austein                     Standards Track                     [Page 2]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+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].
+
+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 that 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.
+
+
+
+
+
+Austein                     Standards Track                     [Page 3]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   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 3.
+
+   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 contents 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.
+
+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 are
+   deliberately left outside the scope of this specification.
+
+   Choosing the NSID content is a prerogative of the server
+   administrator.  The server administrator might choose to encode the
+   NSID content in such a way that the server operator (or clients
+   authorized by the server operator) can decode the NSID content to
+   obtain more information than other clients can.  Alternatively, the
+   server operator might choose unencoded NSID content that is equally
+   meaningful to any client.
+
+   This section describes 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 specifying a simple opaque
+   byte string in Section 2.3.
+
+
+
+Austein                     Standards Track                     [Page 4]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   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 probabilistically 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 dynamically 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.
+
+   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
+
+
+
+Austein                     Standards Track                     [Page 5]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+      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  Probabilistically unique identifiers have properties similar 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 probabilistically unique
+      identifier across reboots, but this does not appear to be a
+      serious restriction, since authoritative nameservers almost always
+      have some form of non-volatile storage.  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
+      generates a new identifier every time it reboots.
+
+   o  Using an arbitrary octet string gives name server operators yet
+      another setting 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.
+
+   o  A signed blob is not particularly useful as an NSID payload unless
+      the signed data is dynamic and includes some kind of replay
+      protection, such as a timestamp or some kind of data identifying
+      the requestor.  Signed blobs that meet these criteria could
+      conceivably be useful in some situations but would require
+      detailed security analysis beyond the scope of this document.
+
+   o  A static encrypted blob would not be particularly useful, as it
+      would be subject to replay attacks and would, in effect, just be a
+      random number to any party that does not possess the decryption
+      key.  Dynamic encrypted blobs could conceivably be useful in some
+      situations but, as with signed blobs, dynamic encrypted blobs
+      would require detailed security analysis beyond the scope of this
+      document.
+
+   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 of payload up to the implementor and name server operator.
+
+
+
+Austein                     Standards Track                     [Page 6]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   The following guidelines may be useful to implementors and server
+   operators:
+
+   o  Operators for whom divulging the unicast address is an issue could
+      use the raw binary representation of a probabilistically 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,
+
+
+
+Austein                     Standards Track                     [Page 7]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   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
+   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 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.
+
+4.  IANA Considerations
+
+   IANA has allocated EDNS option code 3 for the NSID option
+   (Section 2.3).
+
+
+
+Austein                     Standards Track                     [Page 8]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+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.
+
+   Two of the possible kinds of payload data discussed in Section 3.1
+   involve a digital signature and encryption, respectively.  While this
+   specification discusses some of the pitfalls that might lurk for
+   careless users of these kinds of payload data, full analysis of the
+   issues that would be involved in these kinds of payload data would
+   require knowledge of the content to be signed or encrypted,
+   algorithms to be used, and so forth, which is beyond the scope of
+   this document.  Implementors should seek competent advice before
+   attempting to use these kinds of NSID payloads.
+
+6.  Acknowledgements
+
+   Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews,
+   Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad,
+   John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter
+   Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey
+   Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam
+   Weiler, and Suzanne Woolf, none of whom are responsible for what the
+   author did with their comments and suggestions.  Apologies to anyone
+   inadvertently omitted from the above list.
+
+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.
+
+
+
+
+
+
+Austein                     Standards Track                     [Page 9]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   [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.
+
+Author's Address
+
+   Rob Austein
+   ISC
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                     Standards Track                    [Page 10]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+Austein                     Standards Track                    [Page 11]
+
diff --git a/doc/rfc/rfc5011.txt b/doc/rfc/rfc5011.txt
new file mode 100644
index 000000000000..42235e977f89
--- /dev/null
+++ b/doc/rfc/rfc5011.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                         M. StJohns
+Request for Comments: 5011                                   Independent
+Category: Standards Track                                 September 2007
+
+
+        Automated Updates of DNS Security (DNSSEC) Trust Anchors
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document 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
+   (but not resolver resolution behavior), and the addition of a single
+   flag bit to the DNSKEY record.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                     Standards Track                     [Page 1]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Compliance Nomenclature ....................................3
+   2. Theory of Operation .............................................3
+      2.1. Revocation .................................................4
+      2.2. Add Hold-Down ..............................................4
+      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 .....................................................7
+   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 ...................................12
+      8.3. Dynamic Updates ...........................................12
+   9. Normative References ...........................................12
+   10. Informative References ........................................12
+
+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 spaces 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
+
+
+
+StJohns                     Standards Track                     [Page 2]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+   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 these 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].
+
+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 set of valid trust anchors for that trust point.
+
+   There are some issues with this approach that 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.
+
+
+
+
+
+StJohns                     Standards Track                     [Page 3]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+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 that didn't
+   contain A.  To fix this, we add a mechanism that 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 purpose except to
+   validate 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 that 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 [RFC3755], 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.
+
+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 that were
+
+
+
+
+
+StJohns                     Standards Track                     [Page 4]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+   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 that 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
+   explicitly 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 the 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 that has been configured for an 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, half the original TTL for the DNSKEY
+   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.  That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
+   1/2*RRSigExpirationInterval))
+
+   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, 10% of the original TTL, or 10% of the original
+   expiration interval.  That is, retryTime = MAX (1 hour, MIN (1 day,
+   .1 * origTTL, .1 * expireInterval)).
+
+
+
+
+
+
+
+
+StJohns                     Standards Track                     [Page 5]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+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 that contained the
+   new key, whichever is greater.  This ensures that at least two
+   validated DNSKEY RRSets that 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 8 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 this view
+   at various points in the key's lifetime.  The table is a normative
+   part of this specification.  The initial state of the key is 'Start'.
+   The resolver's view of the state of the key changes as various events
+   occur.
+
+   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.
+
+
+
+
+
+
+StJohns                     Standards Track                     [Page 6]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+                             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.
+
+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).
+
+
+
+
+StJohns                     Standards Track                     [Page 7]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+   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 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 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 that 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 that is subordinate to another configured
+   trust point MAY be deleted by a resolver after 180 days, where such a
+
+
+
+StJohns                     Standards Track                     [Page 8]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+   subordinate trust point validly chains to a superior trust point.
+   The decision to delete the subordinate trust anchor is a local
+   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 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
+       Sections 2 and 4 above.
+
+6.2.  Deleting a Trust Anchor
+
+   Assume existing trust anchors 'A' and 'B' and that you want to revoke
+   and delete 'A'.
+
+
+
+
+StJohns                     Standards Track                     [Page 9]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+   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.
+
+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 that is subordinate to another configured
+   trust point (e.g., example.com to .com) requires some juggling of the
+   data.  The specific process is:
+
+
+
+StJohns                     Standards Track                    [Page 10]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+   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
+   (because the trust point was deleted) or becomes bogus (because it
+   didn't chain to the superior zone).
+
+7.  IANA Considerations
+
+   The IANA has assigned a bit in the DNSKEY flags field (see Section 7
+   of [RFC4034]) for the REVOKE bit (8).
+
+8.  Security Considerations
+
+   In addition to the following sections, see also Theory of Operation
+   above (Section 2) and especially Section 2.2 for related discussions.
+
+   Security considerations for trust anchor rollover not specific to
+   this protocol are discussed in [RFC4986].
+
+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 trusting 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, which are outside the scope of this document.
+
+
+
+
+
+
+
+StJohns                     Standards Track                    [Page 11]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+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
+   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.
+
+10.  Informative References
+
+   [RFC4986]  Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
+              "Requirements Related to DNS Security (DNSSEC) Trust
+              Anchor Rollover", RFC 4986, August 2007.
+
+
+
+
+
+
+StJohns                     Standards Track                    [Page 12]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+Author's Address
+
+   Michael StJohns
+   Independent
+
+   EMail: mstjohns@comcast.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                     Standards Track                    [Page 13]
+
+RFC 5011                  Trust Anchor Update             September 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                     Standards Track                    [Page 14]
+
diff --git a/doc/rfc/rfc5205.txt b/doc/rfc/rfc5205.txt
new file mode 100644
index 000000000000..4e17b1d960e8
--- /dev/null
+++ b/doc/rfc/rfc5205.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                        P. Nikander
+Request for Comments: 5205                  Ericsson Research NomadicLab
+Category: Experimental                                       J. Laganier
+                                                        DoCoMo Euro-Labs
+                                                              April 2008
+
+
+    Host Identity Protocol (HIP) Domain Name System (DNS) Extension
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies a new resource record (RR) for the Domain
+   Name System (DNS), and how to use it with the Host Identity Protocol
+   (HIP).  This RR allows a HIP node to store in the DNS its Host
+   Identity (HI, the public component of the node public-private key
+   pair), Host Identity Tag (HIT, a truncated hash of its public key),
+   and the Domain Names of its rendezvous servers (RVSs).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nikander & Laganier           Experimental                      [Page 1]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Simple Static Singly Homed End-Host  . . . . . . . . . . .  5
+     3.2.  Mobile end-host  . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Overview of Using the DNS with HIP . . . . . . . . . . . . . .  8
+     4.1.  Storing HI, HIT, and RVS in the DNS  . . . . . . . . . . .  8
+     4.2.  Initiating Connections Based on DNS Names  . . . . . . . .  8
+   5.  HIP RR Storage Format  . . . . . . . . . . . . . . . . . . . .  9
+     5.1.  HIT Length Format  . . . . . . . . . . . . . . . . . . . .  9
+     5.2.  PK Algorithm Format  . . . . . . . . . . . . . . . . . . .  9
+     5.3.  PK Length Format . . . . . . . . . . . . . . . . . . . . . 10
+     5.4.  HIT Format . . . . . . . . . . . . . . . . . . . . . . . . 10
+     5.5.  Public Key Format  . . . . . . . . . . . . . . . . . . . . 10
+     5.6.  Rendezvous Servers Format  . . . . . . . . . . . . . . . . 10
+   6.  HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 10
+   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+     8.1.  Attacker Tampering with an Insecure HIP RR . . . . . . . . 12
+     8.2.  Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13
+     8.3.  DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     11.1. Normative references . . . . . . . . . . . . . . . . . . . 14
+     11.2. Informative references . . . . . . . . . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nikander & Laganier           Experimental                      [Page 2]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+1.  Introduction
+
+   This document specifies a new resource record (RR) for the Domain
+   Name System (DNS) [RFC1034], and how to use it with the Host Identity
+   Protocol (HIP) [RFC5201].  This RR allows a HIP node to store in the
+   DNS its Host Identity (HI, the public component of the node public-
+   private key pair), Host Identity Tag (HIT, a truncated hash of its
+   HI), and the Domain Names of its rendezvous servers (RVSs) [RFC5204].
+
+   Currently, most of the Internet applications that need to communicate
+   with a remote host first translate a domain name (often obtained via
+   user input) into one or more IP address(es).  This step occurs prior
+   to communication with the remote host, and relies on a DNS lookup.
+
+   With HIP, IP addresses are intended to be used mostly for on-the-wire
+   communication between end hosts, while most Upper Layer Protocols
+   (ULP) and applications use HIs or HITs instead (ICMP might be an
+   example of an ULP not using them).  Consequently, we need a means to
+   translate a domain name into an HI.  Using the DNS for this
+   translation is pretty straightforward: We define a new HIP resource
+   record.  Upon query by an application or ULP for a name to IP address
+   lookup, the resolver would then additionally perform a name to HI
+   lookup, and use it to construct the resulting HI to IP address
+   mapping (which is internal to the HIP layer).  The HIP layer uses the
+   HI to IP address mapping to translate HIs and HITs into IP addresses
+   and vice versa.
+
+   The HIP Rendezvous Extension [RFC5204] allows a HIP node to be
+   reached via the IP address(es) of a third party, the node's
+   rendezvous server (RVS).  An Initiator willing to establish a HIP
+   association with a Responder served by an RVS would typically
+   initiate a HIP exchange by sending an I1 towards the RVS IP address
+   rather than towards the Responder IP address.  Consequently, we need
+   a means to find the name of a rendezvous server for a given host
+   name.
+
+   This document introduces the new HIP DNS resource record to store the
+   Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag
+   (HIT) information.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+Nikander & Laganier           Experimental                      [Page 3]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+3.  Usage Scenarios
+
+   In this section, we briefly introduce a number of usage scenarios
+   where the DNS is useful with the Host Identity Protocol.
+
+   With HIP, most applications and ULPs are unaware of the IP addresses
+   used to carry packets on the wire.  Consequently, a HIP node could
+   take advantage of having multiple IP addresses for fail-over,
+   redundancy, mobility, or renumbering, in a manner that is transparent
+   to most ULPs and applications (because they are bound to HIs; hence,
+   they are agnostic to these IP address changes).
+
+   In these situations, for a node to be reachable by reference to its
+   Fully Qualified Domain Name (FQDN), the following information should
+   be stored in the DNS:
+
+   o  A set of IP address(es) via A [RFC1035] and AAAA [RFC3596] RR sets
+      (RRSets [RFC2181]).
+
+   o  A Host Identity (HI), Host Identity Tag (HIT), and possibly a set
+      of rendezvous servers (RVS) through HIP RRs.
+
+   When a HIP node wants to initiate communication with another HIP
+   node, it first needs to perform a HIP base exchange to set up a HIP
+   association towards its peer.  Although such an exchange can be
+   initiated opportunistically, i.e., without prior knowledge of the
+   Responder's HI, by doing so both nodes knowingly risk man-in-the-
+   middle attacks on the HIP exchange.  To prevent these attacks, it is
+   recommended that the Initiator first obtain the HI of the Responder,
+   and then initiate the exchange.  This can be done, for example,
+   through manual configuration or DNS lookups.  Hence, a new HIP RR is
+   introduced.
+
+   When a HIP node is frequently changing its IP address(es), the
+   natural DNS latency for propagating changes may prevent it from
+   publishing its new IP address(es) in the DNS.  For solving this
+   problem, the HIP Architecture [RFC4423] introduces rendezvous servers
+   (RVSs) [RFC5204].  A HIP host uses a rendezvous server as a
+   rendezvous point to maintain reachability with possible HIP
+   initiators while moving [RFC5206].  Such a HIP node would publish in
+   the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-
+   to-date with its current set of IP addresses.
+
+   When a HIP node wants to initiate a HIP exchange with a Responder, it
+   will perform a number of DNS lookups.  Depending on the type of
+   implementation, the order in which those lookups will be issued may
+   vary.  For instance, implementations using HIT in APIs may typically
+   first query for HIP resource records at the Responder FQDN, while
+
+
+
+Nikander & Laganier           Experimental                      [Page 4]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+   those using an IP address in APIs may typically first query for A
+   and/or AAAA resource records.
+
+   In the following, we assume that the Initiator first queries for HIP
+   resource records at the Responder FQDN.
+
+   If the query for the HIP type was responded to with a DNS answer with
+   RCODE=3 (Name Error), then the Responder's information is not present
+   in the DNS and further queries for the same owner name SHOULD NOT be
+   made.
+
+   In case the query for the HIP records returned a DNS answer with
+   RCODE=0 (No Error) and an empty answer section, it means that no HIP
+   information is available at the responder name.  In such a case, if
+   the Initiator has been configured with a policy to fallback to
+   opportunistic HIP (initiating without knowing the Responder's HI) or
+   plain IP, it would send out more queries for A and AAAA types at the
+   Responder's FQDN.
+
+   Depending on the combinations of answers, the situations described in
+   Section 3.1 and Section 3.2 can occur.
+
+   Note that storing HIP RR information in the DNS at an FQDN that is
+   assigned to a non-HIP node might have ill effects on its reachability
+   by HIP nodes.
+
+3.1.  Simple Static Singly Homed End-Host
+
+   A HIP node (R) with a single static network attachment, wishing to be
+   reachable by reference to its FQDN (www.example.com), would store in
+   the DNS, in addition to its IP address(es) (IP-R), its Host Identity
+   (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record.
+
+   An Initiator willing to associate with a node would typically issue
+   the following queries:
+
+   o  QNAME=www.example.com, QTYPE=HIP
+
+   o  (QCLASS=IN is assumed and omitted from the examples)
+
+   Which returns a DNS packet with RCODE=0 and one or more HIP RRs with
+   the HIT and HI (e.g., HIT-R and HI-R) of the Responder in the answer
+   section, but no RVS.
+
+
+
+
+
+
+
+
+Nikander & Laganier           Experimental                      [Page 5]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+   o  QNAME=www.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
+
+   Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs
+   containing IP address(es) of the Responder (e.g., IP-R) in the answer
+   section.
+
+   Caption: In the remainder of this document, for the sake of keeping
+            diagrams simple and concise, several DNS queries and answers
+            are represented as one single transaction, while in fact
+            there are several queries and answers flowing back and
+            forth, as described in the textual examples.
+
+               [HIP? A?        ]
+               [www.example.com]            +-----+
+          +-------------------------------->|     |
+          |                                 | DNS |
+          | +-------------------------------|     |
+          | |  [HIP? A?        ]            +-----+
+          | |  [www.example.com]
+          | |  [HIP HIT-R HI-R ]
+          | |  [A IP-R         ]
+          | v
+        +-----+                              +-----+
+        |     |--------------I1------------->|     |
+        |  I  |<-------------R1--------------|  R  |
+        |     |--------------I2------------->|     |
+        |     |<-------------R2--------------|     |
+        +-----+                              +-----+
+
+                         Static Singly Homed Host
+
+   The Initiator would then send an I1 to the Responder's IP addresses
+   (IP-R).
+
+3.2.  Mobile end-host
+
+   A mobile HIP node (R) wishing to be reachable by reference to its
+   FQDN (www.example.com) would store in the DNS, possibly in addition
+   to its IP address(es) (IP-R), its HI (HI-R), HIT (HIT-R), and the
+   domain name(s) of its rendezvous server(s) (e.g., rvs.example.com) in
+   HIP resource record(s).  The mobile HIP node also needs to notify its
+   rendezvous servers of any change in its set of IP address(es).
+
+   An Initiator willing to associate with such a mobile node would
+   typically issue the following queries:
+
+   o  QNAME=www.example.com, QTYPE=HIP
+
+
+
+
+Nikander & Laganier           Experimental                      [Page 6]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+   Which returns a DNS packet with RCODE=0 and one or more HIP RRs with
+   the HIT, HI, and RVS domain name(s) (e.g., HIT-R, HI-R, and
+   rvs.example.com) of the Responder in the answer section.
+
+   o  QNAME=rvs.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
+
+   Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs
+   containing IP address(es) of the Responder's RVS (e.g., IP-RVS) in
+   the answer section.
+
+              [HIP?           ]
+              [www.example.com]
+
+              [A?             ]
+              [rvs.example.com]                     +-----+
+         +----------------------------------------->|     |
+         |                                          | DNS |
+         | +----------------------------------------|     |
+         | |  [HIP?                          ]      +-----+
+         | |  [www.example.com               ]
+         | |  [HIP HIT-R HI-R rvs.example.com]
+         | |
+         | |  [A?             ]
+         | |  [rvs.example.com]
+         | |  [A IP-RVS       ]
+         | |
+         | |                +-----+
+         | | +------I1----->| RVS |-----I1------+
+         | | |              +-----+             |
+         | | |                                  |
+         | | |                                  |
+         | v |                                  v
+        +-----+                              +-----+
+        |     |<---------------R1------------|     |
+        |  I  |----------------I2----------->|  R  |
+        |     |<---------------R2------------|     |
+        +-----+                              +-----+
+
+                              Mobile End-Host
+
+   The Initiator would then send an I1 to the RVS IP address (IP-RVS).
+   Following, the RVS will relay the I1 up to the mobile node's IP
+   address (IP-R), which will complete the HIP exchange.
+
+
+
+
+
+
+
+
+Nikander & Laganier           Experimental                      [Page 7]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+4.  Overview of Using the DNS with HIP
+
+4.1.  Storing HI, HIT, and RVS in the DNS
+
+   For any HIP node, its Host Identity (HI), the associated Host
+   Identity Tag (HIT), and the FQDN of its possible RVSs can be stored
+   in a DNS HIP RR.  Any conforming implementation may store a Host
+   Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP
+   RDATA format.  HI and HIT are defined in Section 3 of the HIP
+   specification [RFC5201].
+
+   Upon return of a HIP RR, a host MUST always calculate the HI-
+   derivative HIT to be used in the HIP exchange, as specified in
+   Section 3 of the HIP specification [RFC5201], while the HIT possibly
+   embedded along SHOULD only be used as an optimization (e.g., table
+   lookup).
+
+   The HIP resource record may also contain one or more domain name(s)
+   of rendezvous server(s) towards which HIP I1 packets might be sent to
+   trigger the establishment of an association with the entity named by
+   this resource record [RFC5204].
+
+   The rendezvous server field of the HIP resource record stored at a
+   given owner name MAY include the owner name itself.  A semantically
+   equivalent situation occurs if no rendezvous server is present in the
+   HIP resource record stored at that owner name.  Such situations occur
+   in two cases:
+
+   o  The host is mobile, and the A and/or AAAA resource record(s)
+      stored at its host name contain the IP address(es) of its
+      rendezvous server rather than its own one.
+
+   o  The host is stationary, and can be reached directly at the IP
+      address(es) contained in the A and/or AAAA resource record(s)
+      stored at its host name.  This is a degenerated case of rendezvous
+      service where the host somewhat acts as a rendezvous server for
+      itself.
+
+   An RVS receiving such an I1 would then relay it to the appropriate
+   Responder (the owner of the I1 receiver HIT).  The Responder will
+   then complete the exchange with the Initiator, typically without
+   ongoing help from the RVS.
+
+4.2.  Initiating Connections Based on DNS Names
+
+   On a HIP node, a Host Identity Protocol exchange SHOULD be initiated
+   whenever a ULP attempts to communicate with an entity and the DNS
+   lookup returns HIP resource records.
+
+
+
+Nikander & Laganier           Experimental                      [Page 8]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+5.  HIP RR Storage Format
+
+   The RDATA for a HIP RR consists of a public key algorithm type, the
+   HIT length, a HIT, a public key, and optionally one or more
+   rendezvous server(s).
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  HIT length   | PK algorithm  |          PK length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                           HIT                                 ~
+   |                                                               |
+   +                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     |                                         |
+   +-+-+-+-+-+-+-+-+-+-+-+                                         +
+   |                           Public Key                          |
+   ~                                                               ~
+   |                                                               |
+   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+   |                                                               |
+   ~                       Rendezvous Servers                      ~
+   |                                                               |
+   +             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             |
+   +-+-+-+-+-+-+-+
+
+   The HIT length, PK algorithm, PK length, HIT, and Public Key fields
+   are REQUIRED.  The Rendezvous Servers field is OPTIONAL.
+
+5.1.  HIT Length Format
+
+   The HIT length indicates the length in bytes of the HIT field.  This
+   is an 8-bit unsigned integer.
+
+5.2.  PK Algorithm Format
+
+   The PK algorithm field indicates the public key cryptographic
+   algorithm and the implied public key field format.  This is an 8-bit
+   unsigned integer.  This document reuses the values defined for the
+   'algorithm type' of the IPSECKEY RR [RFC4025].
+
+   Presently defined values are listed in Section 9 for reference.
+
+
+
+
+
+Nikander & Laganier           Experimental                      [Page 9]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+5.3.  PK Length Format
+
+   The PK length indicates the length in bytes of the Public key field.
+   This is a 16-bit unsigned integer in network byte order.
+
+5.4.  HIT Format
+
+   The HIT is stored as a binary value in network byte order.
+
+5.5.  Public Key Format
+
+   Both of the public key types defined in this document (RSA and DSA)
+   reuse the public key formats defined for the IPSECKEY RR [RFC4025].
+
+   The DSA key format is defined in RFC 2536 [RFC2536].
+
+   The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key
+   size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025]
+   specification.
+
+5.6.  Rendezvous Servers Format
+
+   The Rendezvous Servers field indicates one or more variable length
+   wire-encoded domain names of rendezvous server(s), as described in
+   Section 3.3 of RFC 1035 [RFC1035].  The wire-encoded format is self-
+   describing, so the length is implicit.  The domain names MUST NOT be
+   compressed.  The rendezvous server(s) are listed in order of
+   preference (i.e., first rendezvous server(s) are preferred), defining
+   an implicit order amongst rendezvous servers of a single RR.  When
+   multiple HIP RRs are present at the same owner name, this implicit
+   order of rendezvous servers within an RR MUST NOT be used to infer a
+   preference order between rendezvous servers stored in different RRs.
+
+6.  HIP RR Presentation Format
+
+   This section specifies the representation of the HIP RR in a zone
+   master file.
+
+   The HIT length field is not represented, as it is implicitly known
+   thanks to the HIT field representation.
+
+   The PK algorithm field is represented as unsigned integers.
+
+   The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a.
+   hex or hexadecimal) of the HIT.  The encoding MUST NOT contain
+   whitespaces to distinguish it from the public key field.
+
+
+
+
+
+Nikander & Laganier           Experimental                     [Page 10]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+   The Public Key field is represented as the Base64 encoding [RFC4648]
+   of the public key.  The encoding MUST NOT contain whitespace(s) to
+   distinguish it from the Rendezvous Servers field.
+
+   The PK length field is not represented, as it is implicitly known
+   thanks to the Public key field representation containing no
+   whitespaces.
+
+   The Rendezvous Servers field is represented by one or more domain
+   name(s) separated by whitespace(s).
+
+   The complete representation of the HPIHI record is:
+
+   IN  HIP   ( pk-algorithm
+               base16-encoded-hit
+               base64-encoded-public-key
+               rendezvous-server[1]
+                       ...
+               rendezvous-server[n] )
+
+   When no RVSs are present, the representation of the HPIHI record is:
+
+   IN  HIP   ( pk-algorithm
+               base16-encoded-hit
+               base64-encoded-public-key )
+
+7.  Examples
+
+   In the examples below, the public key field containing no whitespace
+   is wrapped since it does not fit in a single line of this document.
+
+   Example of a node with HI and HIT but no RVS:
+
+www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
+                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
+9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
+b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D )
+
+   Example of a node with a HI, HIT, and one RVS:
+
+www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
+                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
+9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
+b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
+                                rvs.example.com. )
+
+
+
+
+
+
+Nikander & Laganier           Experimental                     [Page 11]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+   Example of a node with a HI, HIT, and two RVSs:
+
+www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
+                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
+9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
+b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
+                                rvs1.example.com.
+                                rvs2.example.com. )
+
+8.  Security Considerations
+
+   This section contains a description of the known threats involved
+   with the usage of the HIP DNS Extension.
+
+   In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS
+   Extension allows for the provision of two HIP nodes with the public
+   keying material (HI) of their peer.  These HIs will be subsequently
+   used in a key exchange between the peers.  Hence, the HIP DNS
+   Extension introduces the same kind of threats that IPSECKEY does,
+   plus threats caused by the possibility given to a HIP node to
+   initiate or accept a HIP exchange using "opportunistic" or
+   "unpublished Initiator HI" modes.
+
+   A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure
+   channel ensuring data integrity and authenticity of the RRs.  DNSSEC
+   [RFC4033] [RFC4034] [RFC4035] provides such a secure channel.
+   However, it should be emphasized that DNSSEC only offers data
+   integrity and authenticity guarantees to the channel between the DNS
+   server publishing a zone and the HIP node.  DNSSEC does not ensure
+   that the entity publishing the zone is trusted.  Therefore, the RRSIG
+   signature of the HIP RRSet MUST NOT be misinterpreted as a
+   certificate binding the HI and/or the HIT to the owner name.
+
+   In the absence of a proper secure channel, both parties are
+   vulnerable to MitM and DoS attacks, and unrelated parties might be
+   subject to DoS attacks as well.  These threats are described in the
+   following sections.
+
+8.1.  Attacker Tampering with an Insecure HIP RR
+
+   The HIP RR contains public keying material in the form of the named
+   peer's public key (the HI) and its secure hash (the HIT).  Both of
+   these are not sensitive to attacks where an adversary gains knowledge
+   of them.  However, an attacker that is able to mount an active attack
+   on the DNS, i.e., tampers with this HIP RR (e.g., using DNS
+   spoofing), is able to mount Man-in-the-Middle attacks on the
+   cryptographic core of the eventual HIP exchange (Responder's HIP RR
+   rewritten by the attacker).
+
+
+
+Nikander & Laganier           Experimental                     [Page 12]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+   The HIP RR may contain a rendezvous server domain name resolved into
+   a destination IP address where the named peer is reachable by an I1,
+   as per the HIP Rendezvous Extension [RFC5204].  Thus, an attacker
+   able to tamper with this RR is able to redirect I1 packets sent to
+   the named peer to a chosen IP address for DoS or MitM attacks.  Note
+   that this kind of attack is not specific to HIP and exists
+   independently of whether or not HIP and the HIP RR are used.  Such an
+   attacker might tamper with A and AAAA RRs as well.
+
+   An attacker might obviously use these two attacks in conjunction: It
+   will replace the Responder's HI and RVS IP address by its own in a
+   spoofed DNS packet sent to the Initiator HI, then redirect all
+   exchanged packets to him and mount a MitM on HIP.  In this case, HIP
+   won't provide confidentiality nor Initiator HI protection from
+   eavesdroppers.
+
+8.2.  Hash and HITs Collisions
+
+   As with many cryptographic algorithms, some secure hashes (e.g.,
+   SHA1, used by HIP to generate a HIT from an HI) eventually become
+   insecure, because an exploit has been found in which an attacker with
+   reasonable computation power breaks one of the security features of
+   the hash (e.g., its supposed collision resistance).  This is why a
+   HIP end-node implementation SHOULD NOT authenticate its HIP peers
+   based solely on a HIT retrieved from the DNS, but SHOULD rather use
+   HI-based authentication.
+
+8.3.  DNSSEC
+
+   In the absence of DNSSEC, the HIP RR is subject to the threats
+   described in RFC 3833 [RFC3833].
+
+9.  IANA Considerations
+
+   IANA has allocated one new RR type code (55) for the HIP RR from the
+   standard RR type space.
+
+   IANA does not need to open a new registry for public key algorithms
+   of the HIP RR because the HIP RR reuses "algorithms types" defined
+   for the IPSECKEY RR [RFC4025].  Presently defined values are shown
+   here for reference only:
+
+      0 is reserved
+
+      1 is DSA
+
+      2 is RSA
+
+
+
+
+Nikander & Laganier           Experimental                     [Page 13]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+   In the future, if a new algorithm is to be used for the HIP RR, a new
+   algorithm type and corresponding public key encoding should be
+   defined for the IPSECKEY RR.  The HIP RR should reuse both the same
+   algorithm type and the same corresponding public key format as the
+   IPSECKEY RR.
+
+10.  Acknowledgments
+
+   As usual in the IETF, this document is the result of a collaboration
+   between many people.  The authors would like to thank the author
+   (Michael Richardson), contributors, and reviewers of the IPSECKEY RR
+   [RFC4025] specification, after which this document was framed.  The
+   authors would also like to thank the following people, who have
+   provided thoughtful and helpful discussions and/or suggestions, that
+   have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu
+   Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman,
+   Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro.
+   Some parts of this document stem from the HIP specification
+   [RFC5201].
+
+11.  References
+
+11.1.  Normative references
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [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.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IP Version 6", RFC 3596,
+              October 2003.
+
+   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
+              Material in DNS", RFC 4025, March 2005.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+
+
+
+
+Nikander & Laganier           Experimental                     [Page 14]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+   [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.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
+
+   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
+              Henderson, "Host Identity Protocol", RFC 5201, April 2008.
+
+   [RFC5204]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
+              Rendezvous Extension", RFC 5204, April 2008.
+
+11.2.  Informative references
+
+   [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
+              (DNS)", RFC 2536, March 1999.
+
+   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+              Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
+              Name System (DNS)", RFC 3833, August 2004.
+
+   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
+              (HIP) Architecture", RFC 4423, May 2006.
+
+   [RFC5206]  Henderson, T., Ed., "End-Host Mobility and Multihoming
+              with the Host Identity Protocol", RFC 5206, April 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nikander & Laganier           Experimental                     [Page 15]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+Authors' Addresses
+
+   Pekka Nikander
+   Ericsson Research NomadicLab
+   JORVAS  FIN-02420
+   FINLAND
+
+   Phone: +358 9 299 1
+   EMail: pekka.nikander@nomadiclab.com
+
+
+   Julien Laganier
+   DoCoMo Communications Laboratories Europe GmbH
+   Landsberger Strasse 312
+   Munich  80687
+   Germany
+
+   Phone: +49 89 56824 231
+   EMail: julien.ietf@laposte.net
+   URI:   http://www.docomolab-euro.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nikander & Laganier           Experimental                     [Page 16]
+
+RFC 5205                   HIP DNS Extension                  April 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Nikander & Laganier           Experimental                     [Page 17]
+
diff --git a/doc/rfc/rfc5452.txt b/doc/rfc/rfc5452.txt
new file mode 100644
index 000000000000..6f59bf57acfb
--- /dev/null
+++ b/doc/rfc/rfc5452.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                          A. Hubert
+Request for Comments: 5452            Netherlabs Computer Consulting BV.
+Updates: 2181                                                R. van Mook
+Category: Standards Track                                        Equinix
+                                                            January 2009
+
+
+     Measures for Making DNS More Resilient against Forged Answers
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (http://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   The current Internet climate poses serious threats to the Domain Name
+   System.  In the interim period before the DNS protocol can be secured
+   more fully, measures can already be taken to harden the DNS to make
+   'spoofing' a recursing nameserver many orders of magnitude harder.
+
+   Even a cryptographically secured DNS benefits from having the ability
+   to discard bogus responses quickly, as this potentially saves large
+   amounts of computation.
+
+   By describing certain behavior that has previously not been
+   standardized, this document sets out how to make the DNS more
+   resilient against accepting incorrect responses.  This document
+   updates RFC 2181.
+
+
+
+
+
+
+
+
+Hubert & van Mook           Standards Track                     [Page 1]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Requirements and Definitions . . . . . . . . . . . . . . . . .  4
+     2.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Description of DNS Spoofing  . . . . . . . . . . . . . . . . .  5
+   4.  Detailed Description of Spoofing Scenarios . . . . . . . . . .  6
+     4.1.  Forcing a Query  . . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  Matching the Question Section  . . . . . . . . . . . . . .  7
+     4.3.  Matching the ID Field  . . . . . . . . . . . . . . . . . .  7
+     4.4.  Matching the Source Address of the Authentic Response  . .  7
+     4.5.  Matching the Destination Address and Port of the
+           Authentic Response . . . . . . . . . . . . . . . . . . . .  8
+     4.6.  Have the Response Arrive before the Authentic Response . .  8
+   5.  Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . .  9
+   6.  Accepting Only In-Domain Records . . . . . . . . . . . . . . .  9
+   7.  Combined Difficulty  . . . . . . . . . . . . . . . . . . . . . 10
+     7.1.  Symbols Used in Calculation  . . . . . . . . . . . . . . . 10
+     7.2.  Calculation  . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     8.1.  Repetitive Spoofing Attempts for a Single Domain Name  . . 13
+   9.  Forgery Countermeasures  . . . . . . . . . . . . . . . . . . . 13
+     9.1.  Query Matching Rules . . . . . . . . . . . . . . . . . . . 13
+     9.2.  Extending the Q-ID Space by Using Ports and Addresses  . . 14
+       9.2.1.  Justification and Discussion . . . . . . . . . . . . . 14
+     9.3.  Spoof Detection and Countermeasure . . . . . . . . . . . . 15
+   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
+     12.2. Informative References . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hubert & van Mook           Standards Track                     [Page 2]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+1.  Introduction
+
+   This document describes several common problems in DNS
+   implementations, which, although previously recognized, remain
+   largely unsolved.  Besides briefly recapping these problems, this
+   document contains rules that, if implemented, make complying
+   resolvers vastly more resistant to the attacks described.  The goal
+   is to make the existing DNS as secure as possible within the current
+   protocol boundaries.
+
+   The words below are aimed at authors of resolvers: it is up to
+   operators to decide which nameserver implementation to use, or which
+   options to enable.  Operational constraints may override the security
+   concerns described below.  However, implementations are expected to
+   allow an operator to enable functionality described in this document.
+
+   Almost every transaction on the Internet involves the Domain Name
+   System, which is described in [RFC1034], [RFC1035], and beyond.
+
+   Additionally, it has recently become possible to acquire Secure
+   Socket Layer/Transport Layer Security (SSL/TLS) certificates with no
+   other confirmation of identity than the ability to respond to a
+   verification email sent via SMTP ([RFC5321]) -- which generally uses
+   DNS for its routing.
+
+   In other words, any party that (temporarily) controls the Domain Name
+   System is in a position to reroute most kinds of Internet
+   transactions, including the verification steps in acquiring an SSL/
+   TLS certificate for a domain.  This in turn means that even
+   transactions protected by SSL/TLS could be diverted.
+
+   It is entirely conceivable that such rerouted traffic could be used
+   to the disadvantage of Internet users.
+
+   These and other developments have made the security and
+   trustworthiness of DNS of renewed importance.  Although the DNS
+   community is working hard on finalizing and implementing a
+   cryptographically enhanced DNS protocol, steps should be taken to
+   make sure that the existing use of DNS is as secure as possible
+   within the bounds of the relevant standards.
+
+   It should be noted that the most commonly used resolvers currently do
+   not perform as well as possible in this respect, making this document
+   of urgent importance.
+
+   A thorough analysis of risks facing DNS can be found in [RFC3833].
+
+
+
+
+
+Hubert & van Mook           Standards Track                     [Page 3]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   This document expands on some of the risks mentioned in RFC 3833,
+   especially those outlined in the sections on "ID Guessing and Query
+   Prediction" and "Name Chaining".  Furthermore, it emphasizes a number
+   of existing rules and guidelines embodied in the relevant DNS
+   protocol specifications.  The following also specifies new
+   requirements to make sure the Domain Name System can be relied upon
+   until a more secure protocol has been standardized and deployed.
+
+   It should be noted that even when all measures suggested below are
+   implemented, protocol users are not protected against third parties
+   with the ability to observe, modify, or inject packets in the traffic
+   of a resolver.
+
+   For protocol extensions that offer protection against these
+   scenarios, see [RFC4033] and beyond.
+
+2.  Requirements and Definitions
+
+2.1.  Definitions
+
+   This document uses the following definitions:
+
+      Client: typically a 'stub-resolver' on an end-user's computer.
+
+      Resolver: a nameserver performing recursive service for clients,
+      also known as a caching server, or a full service resolver
+      ([RFC1123], Section 6.1.3.1).
+
+      Stub resolver: a very limited resolver on a client computer, that
+      leaves the recursing work to a full resolver.
+
+      Query: a question sent out by a resolver, typically in a UDP
+      packet
+
+      Response: the answer sent back by an authoritative nameserver,
+      typically in a UDP packet.
+
+      Third party: any entity other than the resolver or the intended
+      recipient of a question.  The third party may have access to an
+      arbitrary authoritative nameserver, but has no access to packets
+      transmitted by the resolver or authoritative server.
+
+      Attacker: malicious third party.
+
+      Spoof: the activity of attempting to subvert the DNS process by
+      getting a chosen answer accepted.
+
+
+
+
+
+Hubert & van Mook           Standards Track                     [Page 4]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+      Authentic response: the correct answer that comes from the right
+      authoritative server.
+
+      Target domain name: domain for which the attacker wishes to spoof
+      in an answer
+
+      Fake data: response chosen by the attacker.
+
+2.2.  Key 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].
+
+3.  Description of DNS Spoofing
+
+   When certain steps are taken, it is feasible to "spoof" the current
+   deployed majority of resolvers with carefully crafted and timed DNS
+   packets.  Once spoofed, a caching server will repeat the data it
+   wrongfully accepted, and make its clients contact the wrong, and
+   possibly malicious, servers.
+
+   To understand how this process works it is important to know what
+   makes a resolver accept a response.
+
+   The following sentence in Section 5.3.3 of [RFC1034] presaged the
+   present problem:
+
+     The resolver should be highly paranoid in its parsing of responses.
+     It should also check that the response matches the query it sent
+     using the ID field in the response.
+
+   DNS data is to be accepted by a resolver if and only if:
+
+   1.  The question section of the reply packet is equivalent to that of
+       a question packet currently waiting for a response.
+
+   2.  The ID field of the reply packet matches that of the question
+       packet.
+
+   3.  The response comes from the same network address to which the
+       question was sent.
+
+   4.  The response comes in on the same network address, including port
+       number, from which the question was sent.
+
+   In general, the first response matching these four conditions is
+   accepted.
+
+
+
+Hubert & van Mook           Standards Track                     [Page 5]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   If a third party succeeds in meeting the four conditions before the
+   response from the authentic nameserver does so, it is in a position
+   to feed a resolver fabricated data.  When it does so, we dub it an
+   "attacker", attempting to spoof in fake data.
+
+   All conditions mentioned above can theoretically be met by a third
+   party, with the difficulty being a function of the resolver
+   implementation and zone configuration.
+
+4.  Detailed Description of Spoofing Scenarios
+
+   The previous paragraph discussed a number of requirements an attacker
+   must match in order to spoof in manipulated (or fake) data.  This
+   section discusses the relative difficulties and how implementation-
+   defined choices impact the amount of work an attacker has to perform
+   to meet said difficulties.
+
+   Some more details can be found in Section 2.2 of [RFC3833].
+
+4.1.  Forcing a Query
+
+   Formally, there is no need for a nameserver to perform service except
+   for its operator, its customers, or more generally its users.
+   Recently, open recursing nameservers have been used to amplify
+   denial-of-service attacks.
+
+   Providing full service enables the third party to send the target
+   resolver a query for the domain name it intends to spoof.  On
+   receiving this query, and not finding the answer in its cache, the
+   resolver will transmit queries to relevant authoritative nameservers.
+   This opens up a window of opportunity for getting fake answer data
+   accepted.
+
+   Queries may however be forced indirectly, for example, by inducing a
+   mail server to perform DNS lookups.
+
+   Some operators restrict access by not recursing for unauthorized IP
+   addresses, but only respond with data from the cache.  This makes
+   spoofing harder for a third party as it cannot then force the exact
+   moment a question will be asked.  It is still possible however to
+   determine a time range when this will happen, because nameservers
+   helpfully publish the decreasing time to live (TTL) of entries in the
+   cache, which indicate from which absolute time onwards a new query
+   could be sent to refresh the expired entry.
+
+   The time to live of the target domain name's RRSets determines how
+   often a window of opportunity is available, which implies that a
+   short TTL makes spoofing far more viable.
+
+
+
+Hubert & van Mook           Standards Track                     [Page 6]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   Note that the attacker might very well have authorized access to the
+   target resolver by virtue of being a customer or employee of its
+   operator.  In addition, access may be enabled through the use of
+   reflectors as outlined in [RFC5358].
+
+4.2.  Matching the Question Section
+
+   DNS packets, both queries and responses, contain a question section.
+   Incoming responses should be verified to have a question section that
+   is equivalent to that of the outgoing query.
+
+4.3.  Matching the ID Field
+
+   The DNS ID field is 16 bits wide, meaning that if full use is made of
+   all these bits, and if their contents are truly random, it will
+   require on average 32768 attempts to guess.  Anecdotal evidence
+   suggests there are implementations utilizing only 14 bits, meaning on
+   average 8192 attempts will suffice.
+
+   Additionally, if the target nameserver can be forced into having
+   multiple identical queries outstanding, the "Birthday Attack"
+   phenomenon means that any fake data sent by the attacker is matched
+   against multiple outstanding queries, significantly raising the
+   chance of success.  Further details in Section 5.
+
+4.4.  Matching the Source Address of the Authentic Response
+
+   It should be noted that meeting this condition entails being able to
+   transmit packets on behalf of the address of the authoritative
+   nameserver.  While two Best Current Practice documents ([RFC2827] and
+   [RFC3013] specifically) direct Internet access providers to prevent
+   their customers from assuming IP addresses that are not assigned to
+   them, these recommendations are not universally (nor even widely)
+   implemented.
+
+   Many zones have two or three authoritative nameservers, which make
+   matching the source address of the authentic response very likely
+   with even a naive choice having a double digit success rate.
+
+   Most recursing nameservers store relative performance indications of
+   authoritative nameservers, which may make it easier to predict which
+   nameserver would originally be queried -- the one most likely to
+   respond the quickest.
+
+   Generally, this condition requires at most two or three attempts
+   before it is matched.
+
+
+
+
+
+Hubert & van Mook           Standards Track                     [Page 7]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+4.5.  Matching the Destination Address and Port of the Authentic
+      Response
+
+   Note that the destination address of the authentic response is the
+   source address of the original query.
+
+   The actual address of a recursing nameserver is generally known; the
+   port used for asking questions is harder to determine.  Most current
+   resolvers pick an arbitrary port at startup (possibly at random) and
+   use this for all outgoing queries.  In quite a number of cases, the
+   source port of outgoing questions is fixed at the traditional DNS
+   assigned server port number of 53.
+
+   If the source port of the original query is random, but static, any
+   authoritative nameserver under observation by the attacker can be
+   used to determine this port.  This means that matching this
+   conditions often requires no guess work.
+
+   If multiple ports are used for sending queries, this enlarges the
+   effective ID space by a factor equal to the number of ports used.
+
+   Less common resolving servers choose a random port per outgoing
+   query.  If this strategy is followed, this port number can be
+   regarded as an additional ID field, again containing up to 16 bits.
+
+   If the maximum ports range is utilized, on average, around 32256
+   source ports would have to be tried before matching the source port
+   of the original query, as ports below 1024 may be unavailable for
+   use, leaving 64512 options.
+
+   It is in general safe for DNS to use ports in the range 1024-49152
+   even though some of these ports are allocated to other protocols.
+   DNS resolvers will not be able to use any ports that are already in
+   use.  If a DNS resolver uses a port, it will release that port after
+   a short time and migrate to a different port.  Only in the case of a
+   high-volume resolver is it possible that an application wanting a
+   particular UDP port suffers a long term block-out.
+
+   It should be noted that a firewall will not prevent the matching of
+   this address, as it will accept answers that (appear to) come from
+   the correct address, offering no additional security.
+
+4.6.  Have the Response Arrive before the Authentic Response
+
+   Once any packet has matched the previous four conditions (plus
+   possible additional conditions), no further responses are generally
+   accepted.
+
+
+
+
+Hubert & van Mook           Standards Track                     [Page 8]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   This means that the third party has a limited time in which to inject
+   its spoofed response.  For calculations, we will assume a window in
+   order of at most 100 ms (depending on the network distance to the
+   authentic authoritative nameserver).
+
+   This time period can be far longer if the authentic authoritative
+   nameservers are (briefly) overloaded by queries, perhaps by the
+   attacker.
+
+5.  Birthday Attacks
+
+   The so-called "birthday paradox" implies that a group of 23 people
+   suffices to have a more than even chance of having two or more
+   members of the group share a birthday.
+
+   An attacker can benefit from this exact phenomenon if it can force
+   the target resolver to have multiple equivalent (identical QNAME,
+   QTYPE, and QCLASS) outstanding queries at any one time to the same
+   authoritative server.
+
+   Any packet the attacker sends then has a much higher chance of being
+   accepted because it only has to match any of the outstanding queries
+   for that single domain.  Compared to the birthday analogy above, of
+   the group composed of queries and responses, the chance of having any
+   of these share an ID rises quickly.
+
+   As long as small numbers of queries are sent out, the chance of
+   successfully spoofing a response rises linearly with the number of
+   outstanding queries for the exact domain and nameserver.
+
+   For larger numbers, this effect is less pronounced.
+
+   More details are available in US-CERT [vu-457875].
+
+6.  Accepting Only In-Domain Records
+
+   Responses from authoritative nameservers often contain information
+   that is not part of the zone for which we deem it authoritative.  As
+   an example, a query for the MX record of a domain might get as its
+   responses a mail exchanger in another domain, and additionally the IP
+   address of this mail exchanger.
+
+   If accepted uncritically, the resolver stands the chance of accepting
+   data from an untrusted source.  Care must be taken to only accept
+   data if it is known that the originator is authoritative for the
+   QNAME or a parent of the QNAME.
+
+
+
+
+
+Hubert & van Mook           Standards Track                     [Page 9]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   One very simple way to achieve this is to only accept data if it is
+   part of the domain for which the query was intended.
+
+7.  Combined Difficulty
+
+   Given a known or static destination port, matching ID field, the
+   source and destination address requires on average in the order of 2
+   * 2^15 = 65000 packets, assuming a zone has 2 authoritative
+   nameservers.
+
+   If the window of opportunity available is around 100 ms, as assumed
+   above, an attacker would need to be able to briefly transmit 650000
+   packets/s to have a 50% chance to get spoofed data accepted on the
+   first attempt.
+
+   A realistic minimal DNS response consists of around 80 bytes,
+   including IP headers, making the packet rate above correspond to a
+   respectable burst of 416 Mbit/s.
+
+   As of mid-2006, this kind of bandwidth was not common but not scarce
+   either, especially among those in a position to control many servers.
+
+   These numbers change when a window of a full second is assumed,
+   possibly because the arrival of the authentic response can be
+   prevented by overloading the bona fide authoritative hosts with decoy
+   queries.  This reduces the needed bandwidth to 42 Mbit/s.
+
+   If, in addition, the attacker is granted more than a single chance
+   and allowed up to 60 minutes of work on a domain with a time to live
+   of 300 seconds, a meager 4 Mbit/s suffices for a 50% chance at
+   getting fake data accepted.  Once equipped with a longer time,
+   matching condition 1 mentioned above is straightforward -- any
+   popular domain will have been queried a number of times within this
+   hour, and given the short TTL, this would lead to queries to
+   authoritative nameservers, opening windows of opportunity.
+
+7.1.  Symbols Used in Calculation
+
+   Assume the following symbols are used:
+
+   I: Number distinct IDs available (maximum 65536)
+
+   P: Number of ports used (maximum around 64000 as ports under 1024 are
+      not always available, but often 1)
+
+   N: Number of authoritative nameservers for a domain (averages around
+      2.5)
+
+
+
+
+Hubert & van Mook           Standards Track                    [Page 10]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   F: Number of "fake" packets sent by the attacker
+
+   R: Number of packets sent per second by the attacker
+
+   W: Window of opportunity, in seconds.  Bounded by the response time
+      of the authoritative servers (often 0.1s)
+
+   D: Average number of identical outstanding queries of a resolver
+      (typically 1, see Section 5)
+
+   A: Number of attempts, one for each window of opportunity
+
+7.2.  Calculation
+
+   The probability of spoofing a resolver is equal to the amount of fake
+   packets that arrive within the window of opportunity, divided by the
+   size of the problem space.
+
+   When the resolver has 'D' multiple identical outstanding queries,
+   each fake packet has a proportionally higher chance of matching any
+   of these queries.  This assumption only holds for small values of
+   'D'.
+
+   In symbols, if the probability of being spoofed is denoted as P_s:
+
+              D * F
+   P_s =    ---------
+            N * P * I
+
+   It is more useful to reason not in terms of aggregate packets but to
+   convert to packet rate, which can easily be converted to bandwidth if
+   needed.
+
+   If the window of opportunity length is 'W' and the attacker can send
+   'R' packets per second, the number of fake packets 'F' that are
+   candidates to be accepted is:
+
+                          D * R * W
+   F = R * W  ->   P_s  = ---------
+                          N * P * I
+
+   Finally, to calculate the combined chance 'P_cs' of spoofing over a
+   chosen time period 'T', it should be realized that the attacker has a
+   new window of opportunity each time the TTL 'TTL' of the target
+   domain expires.  This means that the number of attempts 'A' is equal
+   to 'T / TTL'.
+
+
+
+
+
+Hubert & van Mook           Standards Track                    [Page 11]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   To calculate the combined chance of at least one success, the
+   following formula holds:
+
+                                                        (T / TTL)
+                         A          (       D * R * W )
+   P_cs = 1 - ( 1 - P_s )    =  1 - ( 1  -  --------- )
+                                    (       N * P * I )
+
+   When common numbers (as listed above) for D, W, N, P, and I are
+   inserted, this formula reduces to:
+
+                               (T / TTL)
+              (         R    )
+   P_cs = 1 - ( 1 -  ------- )
+              (      1638400 )
+
+   From this formula, it can be seen that, if the nameserver
+   implementation is unchanged, only raising the TTL offers protection.
+   Raising N, the number of authoritative nameservers, is not feasible
+   beyond a small number.
+
+   For the degenerate case of a zero-second TTL, a window of opportunity
+   opens for each query sent, making the effective TTL equal to 'W'
+   above, the response time of the authoritative server.
+
+   This last case also holds for spoofing techniques that do not rely on
+   TTL expiry, but use repeated and changing queries.
+
+8.  Discussion
+
+   The calculations above indicate the relative ease with which DNS data
+   can be spoofed.  For example, using the formula derived earlier on an
+   RRSet with a 3600 second TTL, an attacker sending 7000 fake response
+   packets/s (a rate of 4.5 Mbit/s), stands a 10% chance of spoofing a
+   record in the first 24 hours, which rises to 50% after a week.
+
+   For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24
+   minutes, 50% after less than 3 hours, 90% after around 9 hours.
+
+   For some classes of attacks, the effective TTL is near zero, as noted
+   above.
+
+   Note that the attacks mentioned above can be detected by watchful
+   server operators - an unexpected incoming stream of 4.5 Mbit/s of
+   packets might be noticed.
+
+   An important assumption however in these calculations is a known or
+   static destination port of the authentic response.
+
+
+
+Hubert & van Mook           Standards Track                    [Page 12]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   If that port number is unknown and needs to be guessed as well, the
+   problem space expands by a factor of 64000, leading the attacker to
+   need in excess of 285Gb/s to achieve similar success rates.
+
+   Such bandwidth is not generally available, nor is it expected to be
+   so in the foreseeable future.
+
+   Note that some firewalls may need reconfiguring if they are currently
+   set up to only allow outgoing queries from a single DNS source port.
+
+8.1.  Repetitive Spoofing Attempts for a Single Domain Name
+
+   Techniques are available to use an effectively infinite number of
+   queries to achieve a desired spoofing goal.  In the math above, this
+   reduces the effective TTL to 0.
+
+   If such techniques are employed, using the same 7000 packets/s rate
+   mentioned above, and using 1 source port, the spoofing chance rises
+   to 50% within 7 seconds.
+
+   If 64000 ports are used, as recommended in this document, using the
+   same query rate, the 50% level is reached after around 116 hours.
+
+9.  Forgery Countermeasures
+
+9.1.  Query Matching Rules
+
+   A resolver implementation MUST match responses to all of the
+   following attributes of the query:
+
+   o  Source address against query destination address
+
+   o  Destination address against query source address
+
+   o  Destination port against query source port
+
+   o  Query ID
+
+   o  Query name
+
+   o  Query class and type
+
+   before applying DNS trustworthiness rules (see Section 5.4.1 of
+   [RFC2181]).
+
+   A mismatch and the response MUST be considered invalid.
+
+
+
+
+
+Hubert & van Mook           Standards Track                    [Page 13]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+9.2.  Extending the Q-ID Space by Using Ports and Addresses
+
+   Resolver implementations MUST:
+
+   o  Use an unpredictable source port for outgoing queries from the
+      range of available ports (53, or 1024 and above) that is as large
+      as possible and practicable;
+
+   o  Use multiple different source ports simultaneously in case of
+      multiple outstanding queries;
+
+   o  Use an unpredictable query ID for outgoing queries, utilizing the
+      full range available (0-65535).
+
+   Resolvers that have multiple IP addresses SHOULD use them in an
+   unpredictable manner for outgoing queries.
+
+   Resolver implementations SHOULD provide means to avoid usage of
+   certain ports.
+
+   Resolvers SHOULD favor authoritative nameservers with which a trust
+   relation has been established; stub-resolvers SHOULD be able to use
+   Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when
+   communicating with their recursive resolver.
+
+   In case a cryptographic verification of response validity is
+   available (TSIG, SIG(0)), resolver implementations MAY waive above
+   rules, and rely on this guarantee instead.
+
+   Proper unpredictability can be achieved by employing a high quality
+   (pseudo-)random generator, as described in [RFC4086].
+
+9.2.1.  Justification and Discussion
+
+   Since an attacker can force a full DNS resolver to send queries to
+   the attacker's own nameservers, any constant or sequential state held
+   by such a resolver can be measured, and it must not be trivially easy
+   to reverse engineer the resolver's internal state in a way that
+   allows low-cost, high-accuracy prediction of future state.
+
+   A full DNS resolver with only one or a small number of upstream-
+   facing endpoints is effectively using constants for IP source address
+   and UDP port number, and these are very predictable by potential
+   attackers, and must therefore be avoided.
+
+   A full DNS resolver that uses a simple increment to get its next DNS
+   query ID is likewise very predictable and so very spoofable.
+
+
+
+
+Hubert & van Mook           Standards Track                    [Page 14]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   Finally, weak random number generators have been shown to expose
+   their internal state, such that an attacker who witnesses several
+   sequential "random" values can easily predict the next ones.  A
+   crypto-strength random number generator is one whose output cannot be
+   predicted no matter how many successive values are witnessed.
+
+9.3.  Spoof Detection and Countermeasure
+
+   If a resolver detects that an attempt is being made to spoof it,
+   perhaps by discovering that many packets fail the criteria as
+   outlined above, it MAY abandon the UDP query and re-issue it over
+   TCP.  TCP, by the nature of its use of sequence numbers, is far more
+   resilient against forgery by third parties.
+
+10.  Security Considerations
+
+   This document provides clarification of the DNS specification to
+   decrease the probability that DNS responses can be successfully
+   forged.  Recommendations found above should be considered
+   complementary to possible cryptographical enhancements of the domain
+   name system, which protect against a larger class of attacks.
+
+   This document recommends the use of UDP source port number
+   randomization to extend the effective DNS transaction ID beyond the
+   available 16 bits.
+
+   A resolver that does not implement the recommendations outlined above
+   can easily be forced to accept spoofed responses, which in turn are
+   passed on to client computers -- misdirecting (user) traffic to
+   possibly malicious entities.
+
+   This document directly impacts the security of the Domain Name
+   System, implementers are urged to follow its recommendations.
+
+   Most security considerations can be found in Sections 4 and 5, while
+   proposed countermeasures are described in Section 9.
+
+   For brevity's sake, in lieu of repeating the security considerations
+   references, the reader is referred to these sections.
+
+   Nothing in this document specifies specific algorithms for operators
+   to use; it does specify algorithms implementations SHOULD or MUST
+   support.
+
+   It should be noted that the effects of source port randomization may
+   be dramatically reduced by NAT devices that either serialize or limit
+   in volume the UDP source ports used by the querying resolver.
+
+
+
+
+Hubert & van Mook           Standards Track                    [Page 15]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   DNS recursive servers sitting behind at NAT or a statefull firewall
+   may consume all available NAT translation entries/ports when
+   operating under high query load.  Port randomization will cause
+   translation entries to be consumed faster than with fixed query port.
+
+   To avoid this, NAT boxes and statefull firewalls can/should purge
+   outgoing DNS query translation entries 10-17 seconds after the last
+   outgoing query on that mapping was sent.  [RFC4787]-compliant devices
+   need to treat UDP messages with port 53 differently than most other
+   UDP protocols.
+
+   To minimize the potential that port/state exhaustion attacks can be
+   staged from the outside, it is recommended that services that
+   generate a number of DNS queries for each connection should be rate
+   limited.  This applies in particular to email servers.
+
+11.  Acknowledgments
+
+   Source port randomization in DNS was first implemented and possibly
+   invented by Dan J. Bernstein.
+
+   Although any mistakes remain our own, the authors gratefully
+   acknowledge the help and contributions of:
+      Stephane Bortzmeyer
+      Alfred Hoenes
+      Peter Koch
+      Sean Leach
+      Norbert Sendetzky
+      Paul Vixie
+      Florian Weimer
+      Wouter Wijngaards
+      Dan Wing
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC1034]    Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]    Mockapetris, P., "Domain names - implementation and
+                specification", STD 13, RFC 1035, November 1987.
+
+   [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.
+
+
+
+Hubert & van Mook           Standards Track                    [Page 16]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+   [RFC2827]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
+                Defeating Denial of Service Attacks which employ IP
+                Source Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+                Wellington, "Secret Key Transaction Authentication for
+                DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC3013]    Killalea, T., "Recommended Internet Service Provider
+                Security Services and Procedures", BCP 46, RFC 3013,
+                November 2000.
+
+   [RFC4033]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                Rose, "DNS Security Introduction and Requirements",
+                RFC 4033, March 2005.
+
+   [RFC4086]    Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+                Requirements for Security", BCP 106, RFC 4086,
+                June 2005.
+
+   [RFC5321]    Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+                October 2008.
+
+12.2.  Informative References
+
+   [RFC1123]    Braden, R., "Requirements for Internet Hosts -
+                Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC3833]    Atkins, D. and R. Austein, "Threat Analysis of the
+                Domain Name System (DNS)", RFC 3833, August 2004.
+
+   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
+                Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4787]    Audet, F. and C. Jennings, "Network Address Translation
+                (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+                RFC 4787, January 2007.
+
+   [RFC5358]    Damas, J. and F. Neves, "Preventing Use of Recursive
+                Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+                October 2008.
+
+   [vu-457875]  United States CERT, "Various DNS service implementations
+                generate multiple simultaneous queries for the same
+                resource record", VU 457875, November 2002.
+
+
+
+
+
+
+Hubert & van Mook           Standards Track                    [Page 17]
+
+RFC 5452         DNS Resilience against Forged Answers      January 2009
+
+
+Authors' Addresses
+
+   Bert Hubert
+   Netherlabs Computer Consulting BV.
+   Braillelaan 10
+   Rijswijk (ZH)  2289 CM
+   The Netherlands
+
+   EMail: bert.hubert@netherlabs.nl
+
+
+   Remco van Mook
+   Equinix
+   Auke Vleerstraat 1
+   Enschede  7521 PE
+   The Netherlands
+
+   EMail: remco@eu.equinix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hubert & van Mook           Standards Track                    [Page 18]
+
diff --git a/doc/rfc/rfc5507.txt b/doc/rfc/rfc5507.txt
new file mode 100644
index 000000000000..a286d90854d5
--- /dev/null
+++ b/doc/rfc/rfc5507.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                                IAB
+Request for Comments: 5507                             P. Faltstrom, Ed.
+Category: Informational                                  R. Austein, Ed.
+                                                            P. Koch, Ed.
+                                                              April 2009
+
+
+                 Design Choices When Expanding the DNS
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+Abstract
+
+   This note discusses how to extend the DNS with new data for a new
+   application.  DNS extension discussions too often focus on reuse of
+   the TXT Resource Record Type.  This document lists different
+   mechanisms to extend the DNS, and concludes that the use of a new DNS
+   Resource Record Type is the best solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 1]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Background ......................................................4
+   3. Extension Mechanisms ............................................5
+      3.1. Place Selectors inside the RDATA of Existing
+           Resource Record Types ......................................5
+      3.2. Add a Prefix to the Owner Name .............................6
+      3.3. Add a Suffix to the Owner Name .............................7
+      3.4. Add a New Class ............................................8
+      3.5. Add a New Resource Record Type .............................8
+   4. Zone Boundaries are Invisible to Applications ...................9
+   5. Why Adding a New Resource Record Type Is the Preferred
+      Solution .......................................................10
+   6. Conclusion and Recommendation ..................................14
+   7. Creating a New Resource Record Type ............................14
+   8. Security Considerations ........................................15
+   9. Acknowledgements ...............................................15
+   10. IAB Members at the Time of This Writing .......................16
+   11. References ....................................................16
+      11.1. Normative References .....................................16
+      11.2. Informative References ...................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 2]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+1.  Introduction
+
+   The DNS stores multiple categories of data.  The two most commonly
+   used categories are infrastructure data for the DNS system itself (NS
+   and SOA Resource Records) and data that have to do with mappings
+   between domain names and IP addresses (A, AAAA, and PTR Resource
+   Records).  There are other categories as well, some of which are tied
+   to specific applications like email (MX Resource Records), while
+   others are generic Resource Record Types used to convey information
+   for multiple protocols (SRV and NAPTR Resource Records).
+
+   When storing data in the DNS for a new application, the goal must be
+   to store data in such a way that the application can query for the
+   data it wants, while minimizing both the impact on existing
+   applications and the amount of extra data transferred to the client.
+   This implies that a number of design choices have to be made, where
+   the most important is to ensure that a precise selection of what data
+   to return must be made already in the query.  A query consists of a
+   triple: {Owner (or name), Resource Record Class, Resource Record
+   Type}.
+
+   Historically, extending the DNS to store application data tied to a
+   domain name has been done in different ways at different times.  MX
+   Resource Records were created as a new Resource Record Type
+   specifically designed to support electronic mail.  SRV records are a
+   generic type that use a prefixing scheme in combination with a base
+   domain name.  NAPTR records add selection data inside the RDATA.  It
+   is clear that the methods used to add new data types to the DNS have
+   been inconsistent, and the purpose of this document is to attempt to
+   clarify the implications of each of these methods, both for the
+   applications that use them and for the rest of the DNS.
+
+   This document talks extensively about use of DNS wildcards.  Many
+   people might think use of wildcards is not something that happens
+   today.  In reality though, wildcards are in use, especially for
+   certain application-specific data such as MX Resource Records.
+   Because of this, the choice has to be made with the existence of
+   wildcards in mind.
+
+   Another overall issue that must be taken into account is what the new
+   data in the DNS are to describe.  In some cases, they might be
+   completely new data.  In other cases, they might be metadata tied to
+   data that already exist in the DNS.  Examples of new data are key
+   information for the Secure SHell (SSH) Protocol and data used for
+   authenticating the sender of email messages (metadata tied to MX
+   Resource Records).  If the new data are tied to data that already
+   exist in the DNS, an analysis should be made as to whether having
+   (for example) address records and SSH key information in different
+
+
+
+IAB, et al.                  Informational                      [Page 3]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   DNS zones is a problem or if it is a bonus, and if it is a problem,
+   whether the specification must require all of the related data to be
+   in the same zone.  One specific difference between having the records
+   in the same zone or not has to do with maintenance of the records.
+   If they are in the same zone, the same maintainer (from a DNS
+   perspective) manages the two records.  Specifically, they must be
+   signed with the same DNSSEC keys if DNSSEC is in use.
+
+   This document does not talk about what one should store in the DNS.
+   It also doesn't discuss whether the DNS should be used for service
+   discovery, or whether the DNS should be used for storage of data
+   specific to the service.  In general, the DNS is a protocol that,
+   apart from holding metadata that makes the DNS itself function (NS,
+   SOA, DNSSEC Resource Record Types, etc.), only holds references to
+   service locations (SRV, NAPTR, A, AAAA Resource Record Types) --
+   though there are exceptions, such as MX Resource Records.
+
+2.  Background
+
+   See RFC 5395 [RFC5395] for a brief summary of the DNS query
+   structure.  Readers interested in the full story should start with
+   the base DNS specification in RFC 1035 [RFC1035] and continue with
+   the various documents that update, clarify, and extend the base
+   specification.
+
+   When composing a DNS query, the parameters used by the protocol are a
+   {owner, class, type} triple.  Every Resource Record matching such a
+   triple is said to belong to the same Resource Record Set (RRSet), and
+   the whole RRSet is always returned to the client that queries for it.
+   Splitting an RRSet is a protocol violation (sending a partial RRSet,
+   not truncating the DNS response), because it can result in coherency
+   problems with the DNS caching mechanism.  See Section 5 of [RFC2181]
+   for more information.
+
+   Some discussions around extensions to the DNS include arguments
+   around MTU size.  Note that most discussions about DNS and MTU size
+   are about the size of the whole DNS packet, not about the size of a
+   single RRSet.
+
+   Almost all DNS query traffic is carried over UDP, where a DNS message
+   must fit within a single UDP packet.  DNS response messages are
+   almost always larger than DNS query messages, so message size issues
+   are almost always about responses, not queries.  The base DNS
+   specification limits DNS messages over UDP to 512 octets; EDNS0
+   [RFC2671] specifies a mechanism by which a client can signal its
+   willingness to receive larger responses, but deployment of EDNS0 is
+   not universal, in part because of firewalls that block fragmented UDP
+   packets or EDNS0.  If a response message won't fit in a single
+
+
+
+IAB, et al.                  Informational                      [Page 4]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   packet, the name server returns a truncated response, at which point
+   the client may retry using TCP.  DNS queries over TCP are not subject
+   to this length limitation, but TCP imposes significantly higher per-
+   query overhead on name servers than UDP.  It is also the case that
+   the policies in deployed firewalls far too often are such that they
+   block DNS over TCP, so using TCP might not in reality be an option.
+   There are also risks (although possibly small) that a change of
+   routing while a TCP flow is open creates problems when the DNS
+   servers are deployed in an anycast environment.
+
+3.  Extension Mechanisms
+
+   The DNS protocol is intended to be extensible to support new kinds of
+   data.  This section examines the various ways in which this sort of
+   extension can be accomplished.
+
+3.1.  Place Selectors inside the RDATA of Existing Resource Record Types
+
+   For a given query name, one might choose to have a single RRSet (all
+   Resource Records sharing the same {owner, class, type} triple) shared
+   by multiple applications, and have the different applications use
+   selectors within the Resource Record data (RDATA) to determine which
+   records are intended for which applications.  This sort of selector
+   mechanism is usually referred to "subtyping", because it is in effect
+   creating an additional type subsystem within a single DNS Resource
+   Record Type.
+
+   Examples of subtyping include NAPTR Resource Records [RFC3761] and
+   the original DNSSEC KEY Resource Record Type [RFC2535] (which was
+   later updated by RFC 3445 [RFC3445], and obsoleted by RFC 4033
+   [RFC4033], RFC 4034 [RFC4034] and RFC 4035 [RFC4035]).
+
+   All DNS subtyping schemes share a common weakness: with subtyping
+   schemes, it is impossible for a client to query for just the data it
+   wants.  Instead, the client must fetch the entire RRSet, then select
+   the Resource Records in which it is interested.  Furthermore, since
+   DNSSEC signatures operate on complete RRSets, the entire RRSet must
+   be re-signed if any Resource Record in it changes.  As a result, each
+   application that uses a subtyped Resource Record incurs higher
+   overhead than any of the applications would have incurred had they
+   not been using a subtyping scheme.  The fact the RRSet is always
+   passed around as an indivisible unit increases the risk the RRSet
+   will not fit in a UDP packet, which in turn increases the risk that
+   the client will have to retry the query with TCP, which substantially
+   increases the load on the name server.  More precisely: having one
+   query fail over to TCP is not a big deal, but since the typical ratio
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 5]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   of clients to servers in today's deployed DNS is very high, having a
+   substantial number of DNS messages fail over to TCP may cause the
+   queried name servers to be overloaded by TCP overhead.
+
+   Because of the size limitations, using a subtyping scheme to list a
+   large number of services for a single domain name risks triggering
+   truncation and fallback to TCP, which may in turn force the zone
+   administrator to announce only a subset of available services.
+
+3.2.  Add a Prefix to the Owner Name
+
+   By adding an application-specific prefix to a domain name, we get a
+   different {owner, class, type} triple, and therefore a different
+   RRSet.  One problem with adding prefixes has to do with wildcards,
+   especially if one has records like:
+
+   *.example.com. IN MX 1 mail.example.com.
+
+   and one wants records tied to those names.  Suppose one creates the
+   prefix "_mail".  One would then have to say something like:
+
+   _mail.*.example.com. IN X-FOO A B C D
+
+   but DNS wildcards only work with the "*" as the leftmost token in the
+   domain name (see also RFC 4592 [RFC4592]).
+
+   There have been proposals to deal with the problem that DNS wildcards
+   are always terminal records.  These proposals introduce an additional
+   set of trade-offs that would need to be taken into account when
+   assessing which extension mechanism to choose.  Aspects of extra
+   response time needed to perform the extra queries, costs of pre-
+   calculation of possible answers, or the costs induced to the system
+   as a whole come to mind.  At the time of writing, none of these
+   proposals has been published as Standards Track RFCs.
+
+   Even when a specific prefix is chosen, the data will still have to be
+   stored in some Resource Record Type.  This Resource Record Type can
+   be either a new Resource Record Type or an existing Resource Record
+   Type that has an appropriate format to store the data.  One also
+   might need some other selection mechanism, such as the ability to
+   distinguish between the records in an RRSet, given they have the same
+   Resource Record Type.  Because of this, one needs to both register a
+   unique prefix and define what Resource Record Type is to be used for
+   this specific service.
+
+
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 6]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   If the record has some relationship with another record in the zone,
+   the fact that the two records can be in different zones might have
+   implications on the trust the application has in the records.  For
+   example:
+
+   example.com.      IN MX    10 mail.example.com.
+   _foo.example.com. IN X-BAR "metadata for the mail service"
+
+   In this example, the two records might be in two different zones, and
+   as a result might be administered by two different organizations, and
+   signed by two different entities when using DNSSEC.  For these two
+   reasons, using a prefix has recently become a very interesting
+   solution for many protocol designers.  In some cases, e.g.,
+   DomainKeys Identified Mail Signatures [RFC4871], TXT records have
+   been used.  In others, such as SRV, entirely new Resource Record
+   Types have been added.
+
+3.3.  Add a Suffix to the Owner Name
+
+   Adding a suffix to a domain name changes the {owner, class, type}
+   triple, and therefore the RRSet.  In this case, since the query name
+   can be set to exactly the data one wants, the size of the RRSet is
+   minimized.  The problem with adding a suffix is that it creates a
+   parallel tree within the IN class.  Further, there is no technical
+   mechanism to ensure that the delegation for "example.com" and
+   "example.com._bar" are made to the same organization.  Furthermore,
+   data associated with a single entity will now be stored in two
+   different zones, such as "example.com" and "example.com._bar", which,
+   depending on who controls "_bar", can create new synchronization and
+   update authorization issues.
+
+   One way of solving the administrative issues is by using the DNAME
+   Resource Record Type specified in RFC 2672 [RFC2672].
+
+   Even when using a different name, the data will still have to be
+   stored in some Resource Record Type that has an appropriate format to
+   store the data.  This implies that one might have to mix the prefix
+   based selection mechanism with some other mechanism so that the right
+   Resource Record can be found out of many in a potential larger RRSet.
+
+   In RFC 2163 [RFC2163] an infix token is inserted directly below the
+   Top-Level Domain (TLD), but the result is equivalent to adding a
+   suffix to the owner name (instead of creating a TLD, one is creating
+   a second level domain).
+
+
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 7]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+3.4.  Add a New Class
+
+   DNS zones are class-specific in the sense that all the records in
+   that zone share the same class as the zone's SOA record and the
+   existence of a zone in one class does not guarantee the existence of
+   the zone in any other class.  In practice, only the IN class has ever
+   seen widespread deployment, and the administrative overhead of
+   deploying an additional class would almost certainly be prohibitive.
+
+   Nevertheless, one could, in theory, use the DNS class mechanism to
+   distinguish between different kinds of data.  However, since the DNS
+   delegation tree (represented by NS Resource Records) is itself tied
+   to a specific class, attempting to resolve a query by crossing a
+   class boundary may produce unexpected results because there is no
+   guarantee that the name servers for the zone in the new class will be
+   the same as the name servers in the IN class.  The MIT Hesiod system
+   [Dyer87] used a scheme like this for storing data in the HS class,
+   but only on a very small scale (within a single institution), and
+   with an administrative fiat requiring that the delegation trees for
+   the IN and HS trees be identical.  The use of the HS class for such
+   storage of non-sensitive data was, over time, replaced by use of the
+   Lightweight Directory Access Protocol (LDAP) [RFC4511].
+
+   Even when using a different class, the data will still have to be
+   stored in some Resource Record Type that has an appropriate format.
+
+3.5.  Add a New Resource Record Type
+
+   When adding a new Resource Record Type to the system, entities in
+   four different roles have to be able to handle the new Type:
+
+   1.  There must be a way to insert the new Resource Records into the
+       zone at the Primary Master name server.  For some server
+       implementations, the user interface only accepts Resource Record
+       Types that it understands (perhaps so that the implementation can
+       attempt to validate the data).  Other implementations allow the
+       zone administrator to enter an integer for the Resource Record
+       Type code and the RDATA in Base64 or hexadecimal encoding (or
+       even as raw data).  RFC 3597 [RFC3597] specifies a standard
+       generic encoding for this purpose.
+
+   2.  A slave authoritative name server must be able to do a zone
+       transfer, receive the data from some other authoritative name
+       server, and serve data from the zone even though the zone
+       includes records of unknown Resource Record Types.  Historically,
+       some implementations have had problems parsing stored copies of
+       the zone file after restarting, but those problems have not been
+       seen for a few years.  Some implementations use an alternate
+
+
+
+IAB, et al.                  Informational                      [Page 8]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+       mechanism (e.g., LDAP) to transfer Resource Records in a zone,
+       and are primarily used within corporate environments; in this
+       case, name servers must be able to transfer new Resource Record
+       Types using whatever mechanism is used.  However, today this
+       alternative mechanism may not support unknown Resource Record
+       Types.  Hence, in Internet environments, unknown Resource Record
+       Types are supported, but in corporate environments they are
+       problematic.
+
+   3.  A caching resolver (most commonly a recursive name server) will
+       cache the records that are responses to queries.  As mentioned in
+       RFC 3597 [RFC3597], there are various pitfalls where a recursive
+       name server might end up having problems.
+
+   4.  The application must be able to get the RRSet with a new Resource
+       Record Type.  The application itself may understand the RDATA,
+       but the resolver library might not.  Support for a generic
+       interface for retrieving arbitrary DNS Resource Record Types has
+       been a requirement since 1989 (see Section 6.1.4.2 of [RFC1123]).
+       Some stub resolver library implementations neglect to provide
+       this functionality and cannot handle unknown Resource Record
+       Types, but implementation of a new stub resolver library is not
+       particularly difficult, and open source libraries that already
+       provide this functionality are available.
+
+   Historically, adding a new Resource Record Type has been very
+   problematic.  The review process has been cumbersome, DNS servers
+   have not been able to handle new Resource Record Types, and firewalls
+   have dropped queries or responses with Resource Record Types that are
+   unknown to the firewall.  This is, for example, one of the reasons
+   the ENUM standard reuses the NAPTR Resource Record, a decision that
+   today might have gone to creating a new Resource Record Type instead.
+
+   Today, there is a requirement that DNS software handle unknown
+   Resource Record Types, and investigations have shown that software
+   that is deployed, in general, does support it, except in some
+   alternate mechanisms for transferring Resource Records such as LDAP,
+   as noted above.  Also, the approval process for new Resource Record
+   Types has been updated [RFC5395] so the effort that is needed for
+   various Resource Record Types is more predictable.
+
+4.  Zone Boundaries are Invisible to Applications
+
+   Regardless of the possible choices above, we have seen a number of
+   cases where the application made assumptions about the structure of
+   the namespace and the location where specific information resides.
+   We take a small sidestep to argue against such approaches.
+
+
+
+
+IAB, et al.                  Informational                      [Page 9]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   The DNS namespace is a hierarchy, technically speaking.  However,
+   this only refers to the way names are built from multiple labels.
+   DNS hierarchy neither follows nor implies administrative hierarchy.
+   Because of that, it cannot be assumed that data attached to a node in
+   the DNS tree is valid for the whole subtree.  Technically, there are
+   zone boundaries partitioning the namespace, and administrative
+   boundaries (or policy boundaries) may even exist elsewhere.
+
+   The false assumption has lead to an approach called "tree climbing",
+   where a query that does not receive a positive response (either the
+   requested RRSet was missing or the name did not exist) is retried by
+   repeatedly stripping off the leftmost label (climbing towards the
+   root) until the root domain is reached.  Sometimes these proposals
+   try to avoid the query for the root or the TLD level, but still this
+   approach has severe drawbacks:
+
+   o  Technically, the DNS was built as a query-response tool without
+      any search capability [RFC3467].  Adding the search mechanism
+      imposes additional burden on the technical infrastructure, in the
+      worst case on TLD and root name servers.
+
+   o  For reasons similar to those outlined in RFC 1535 [RFC1535],
+      querying for information in a domain outside the control of the
+      intended entity may lead to incorrect results and may also put
+      security at risk.  Finding the exact policy boundary is impossible
+      without an explicit marker, which does not exist at present.  At
+      best, software can detect zone boundaries (e.g., by looking for
+      SOA Resource Records), but some TLD registries register names
+      starting at the second level (e.g., CO.UK), and there are various
+      other "registry" types at second, third, or other level domains
+      that cannot be identified as such without policy knowledge
+      external to the DNS.
+
+   To restate, the zone boundary is purely a boundary that exists in the
+   DNS for administrative purposes, and applications should be careful
+   not to draw unwarranted conclusions from zone boundaries.  A
+   different way of stating this is that the DNS does not support
+   inheritance, e.g., an MX RRSet for a TLD will not be valid for any
+   subdomain of that particular TLD.
+
+5.  Why Adding a New Resource Record Type Is the Preferred Solution
+
+   By now, the astute reader might be wondering what conclusions to draw
+   from the issues presented so far.  We will now attempt to clear up
+   the reader's confusion by following the thought processes of a
+   typical application designer who wishes to store data in the DNS.
+   We'll show how such a designer almost inevitably hits upon the idea
+   of just using a TXT Resource Record, why this is a bad thing, and why
+
+
+
+IAB, et al.                  Informational                     [Page 10]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   a new Resource Record Type should be allocated instead.  We'll also
+   explain how the reuse of an existing Resource Record, including TXT,
+   can be made less harmful.
+
+   The overall problem with most solutions has to do with two main
+   issues:
+
+   o  No semantics to prevent collision with other use
+
+   o  Space considerations in the DNS message
+
+   A typical application designer is not interested in the DNS for its
+   own sake, but rather regards it as a distributed database in which
+   application data can be stored.  As a result, the designer of a new
+   application is usually looking for the easiest way to add whatever
+   new data the application needs to the DNS in a way that naturally
+   associates the data with a DNS name and does not require major
+   changes to DNS servers.
+
+   As explained in Section 3.4, using the DNS class system as an
+   extension mechanism is not really an option, and in fact, most users
+   of the system don't even realize that the mechanism exists.  As a
+   practical matter, therefore any extension is likely to be within the
+   IN class.
+
+   Adding a new Resource Record Type is the technically correct answer
+   from the DNS protocol standpoint (more on this below), but doing so
+   requires some DNS expertise, due to the issues listed in Section 3.5.
+   Consequently, this option is often rejected.  Note that according to
+   RFC 5395 [RFC5395], some Types require IETF Consensus, while others
+   only require a specification.
+
+   There is a drawback to defining new RR types that is worth
+   mentioning.  The Resource Record Type (RRTYPE) is a 16-bit value and
+   hence is a limited resource.  In order to prevent hoarding the
+   registry has a review-based allocation policy [RFC5395]; however,
+   this may not be sufficient if extension of the DNS by addition of new
+   RR types takes up significantly and the registry starts nearing
+   completion.  In that case, the trade-offs with respect to choosing an
+   extension mechanism may need to change.
+
+   The application designer is thus left with the prospect of reusing
+   some existing DNS Types within the IN class, but when the designer
+   looks at the existing Types, almost all of them have well-defined
+   semantics, none of which quite match the needs of the new
+   application.  This has not completely prevented proposals from
+
+
+
+
+
+IAB, et al.                  Informational                     [Page 11]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   reusing existing Resource Record Types in ways incompatible with
+   their defined semantics, but it does tend to steer application
+   designers away from this approach.
+
+   For example, Resource Record Type 40 was registered for the SINK
+   Resource Record Type.  This Resource Record Type was discussed in the
+   DNSIND working group of the IETF, and it was decided at the 46th IETF
+   to not move the I-D forward to become an RFC because of the risk of
+   encouraging application designers to use the SINK Resource Record
+   Type instead of registering a new Resource Record Type, which would
+   result in infeasibly large SINK RRsets.
+
+   Eliminating all of the above leaves the TXT Resource Record Type in
+   the IN class.  The TXT RDATA format is free form text, and there are
+   no existing semantics to get in the way.  Some attempts have been
+   made, for example, in [DNSEXT-DNS-SD], to specify a structured format
+   for TXT Resource Record Types, but no such attempt has reached RFC
+   status.  Furthermore, the TXT Resource Record can obviously just be
+   used as a bucket in which to carry around data to be used by some
+   higher-level parser, perhaps in some human-readable programming or
+   markup language.  Thus, for many applications, TXT Resource Records
+   are the "obvious" choice.  Unfortunately, this conclusion, while
+   understandable, is also problematic, for several reasons.
+
+   The first reason why TXT Resource Records are not well suited to such
+   use is precisely what makes them so attractive: the lack of pre-
+   defined common syntax or structure.  As a result, each application
+   that uses them creates its own syntax/structure, and that makes it
+   difficult to reliably distinguish one application's record from
+   others, and for its parser to avoid problems when it encounters other
+   TXT records.
+
+   Arguably, the TXT Resource Record is misnamed, and should have been
+   called the Local Container record, because a TXT Resource Record
+   means only what the data producer says it means.  This is fine, so
+   long as TXT Resource Records are being used by human beings or by
+   private agreement between data producer and data consumer.  However,
+   it becomes a problem once one starts using them for standardized
+   protocols in which there is no prior relationship between data
+   producer and data consumer.  If TXT records are used without one of
+   the naming modifications discussed earlier (and in some cases even if
+   one uses such naming mechanisms), there is nothing to prevent
+   collisions with some other incompatible use of TXT Resource Records.
+
+   This is even worse than the general subtyping problem described in
+   Section 3.1 because TXT Resource Records don't even have a
+   standardized selector field in which to store the subtype.  RFC 1464
+   [RFC1464] tried, but it was not a success.  At best, a definition of
+
+
+
+IAB, et al.                  Informational                     [Page 12]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   a subtype is reduced to hoping that whatever scheme one has come up
+   with will not accidently conflict with somebody else's subtyping
+   scheme, and that it will not be possible to mis-parse one
+   application's use of TXT Resource Records as data intended for a
+   different application.  Any attempt to impose a standardized format
+   within the TXT Resource Record format would be at least fifteen years
+   too late, even if it were put into effect immediately; at best, one
+   can restrict the syntax that a particular application uses within a
+   TXT Resource Record and accept the risk that unrelated TXT Resource
+   Record uses will collide with it.
+
+   Using one of the naming modifications discussed in Section 3.2 and
+   Section 3.3 would address the subtyping problem, (and have been used
+   in combinations with reuse of TXT record, such as for the dns/txt
+   lookup mechanism in Domain Keys Identified Mail (DKIM)) but each of
+   these approaches brings in new problems of its own.  The prefix
+   approach (that for example SRV Resource Records use) does not work
+   well with wildcards, which is a particular problem for mail-related
+   applications, since MX Resource Records are probably the most common
+   use of DNS wildcards.  The suffix approach doesn't have wildcard
+   issues, but, as noted previously, it does have synchronization and
+   update authorization issues, since it works by creating a second
+   subtree in a different part of the global DNS namespace.
+
+   The next reason why TXT Resource Records are not well suited to
+   protocol use has to do with the limited data space available in a DNS
+   message.  As alluded to briefly in Section 3.1, typical DNS query
+   traffic patterns involve a very large number of DNS clients sending
+   queries to a relatively small number of DNS servers.  Normal path MTU
+   discovery schemes do little good here because, from the server's
+   perspective, there isn't enough repeat traffic from any one client
+   for it to be worth retaining state.  UDP-based DNS is an idempotent
+   query, whereas TCP-based DNS requires the server to keep state (in
+   the form of TCP connection state, usually in the server's kernel) and
+   roughly triples the traffic load.  Thus, there's a strong incentive
+   to keep DNS messages short enough to fit in a UDP datagram,
+   preferably a UDP datagram short enough not to require IP
+   fragmentation.
+
+   Subtyping schemes are therefore again problematic because they
+   produce larger Resource RRSets than necessary, but verbose text
+   encodings of data are also wasteful since the data they hold can
+   usually be represented more compactly in a Resource Record designed
+   specifically to support the application's particular data needs.  If
+   the data that need to be carried are so large that there is no way to
+   make them fit comfortably into the DNS regardless of encoding, it is
+   probably better to move the data somewhere else, and just use the DNS
+   as a pointer to the data, as with NAPTR.
+
+
+
+IAB, et al.                  Informational                     [Page 13]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+6.  Conclusion and Recommendation
+
+   Given the problems detailed in Section 5, it is worth reexamining the
+   oft-jumped-to conclusion that specifying a new Resource Record Type
+   is hard.  Historically, this was indeed the case, but recent surveys
+   suggest that support for unknown Resource Record Types [RFC3597] is
+   now widespread in the public Internet, and because of that, the DNS
+   infrastructure can handle new Resource Record Types.  The lack of
+   support for unknown Types remains an issue for relatively old
+   provisioning software and in corporate environments.
+
+   Of all the issues detailed in Section 3.5, provisioning the data is
+   in some respects the most difficult.  Investigations with zone
+   transfers show that the problem is less difficult for the
+   authoritative name servers themselves than the front-end systems used
+   to enter (and perhaps validate) the data.  Hand editing does not work
+   well for maintenance of large zones, so some sort of tool is
+   necessary, and the tool may not be tightly coupled to the name server
+   implementation itself.  Note, however, that this provisioning problem
+   exists to some degree with any new form of data to be stored in the
+   DNS, regardless of data format, Resource Record type (even if TXT
+   Resource Record Types are in use), or naming scheme.  Adapting front-
+   end systems to support a new Resource Record Type may be a bit more
+   difficult than reusing an existing type, but this appears to be a
+   minor difference in degree rather than a difference in kind.
+
+   Given the various issues described in this note, we believe that:
+
+   o  there is no magic solution that allows a completely painless
+      addition of new data to the DNS, but
+
+   o  on the whole, the best solution is still to use the DNS Resource
+      Record Type mechanism designed for precisely this purpose,
+      whenever possible, and
+
+   o  of all the alternate solutions, the "obvious" approach of using
+      TXT Resource Records for arbitrary names is almost certainly the
+      worst, especially for the two reasons outlined above (lack of
+      semantics and its implementations, and size leading to the need to
+      use TCP).
+
+7.  Creating a New Resource Record Type
+
+   The process for creating a new Resource Record Type is specified in
+   RFC 5395 [RFC5395].
+
+
+
+
+
+
+IAB, et al.                  Informational                     [Page 14]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+8.  Security Considerations
+
+   DNS RRSets can be signed using DNSSEC.  DNSSEC is almost certainly
+   necessary for any application mechanism that stores authorization
+   data in the DNS.  DNSSEC signatures significantly increase the size
+   of the messages transported, and because of this, the DNS message
+   size issues discussed in Sections 3.1 and 5 are more serious than
+   they might at first appear.
+
+   Adding new Resource Record Types (as discussed in Section 3.5) can
+   create two different kinds of problems: in the DNS software and in
+   applications.  In the DNS software, it might conceivably trigger bugs
+   and other bad behavior in software that is not compliant with RFC
+   3597 [RFC3597], but most such DNS software is old enough and insecure
+   enough that it should be updated for other reasons in any case.  In
+   applications and provisioning software, the changes for the new
+   features that need the new data in the DNS can be updated to
+   understand the structure of the new data format (regardless of
+   whether a new Resource Record Type is used or some other mechanism is
+   chosen).  Basic API support for retrieving arbitrary Resource Record
+   Types has been a requirement since 1989 [RFC1123].
+
+   Any new protocol that proposes to use the DNS to store data used to
+   make authorization decisions would be well advised not only to use
+   DNSSEC but also to encourage upgrades to DNS server software recent
+   enough not to be riddled with well-known exploitable bugs.
+
+9.  Acknowledgements
+
+   This document has been created over a number of years, with input
+   from many people.  The question on how to expand and use the DNS is
+   sensitive, and a document like this can not please everyone.  The
+   goal is instead to describe the architecture and tradeoffs, and make
+   some recommendations about best practices.
+
+   People that have helped include: Dean Anderson, Mark Andrews, John
+   Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein,
+   Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies,
+   Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert
+   Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric
+   Hall, Phillip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman,
+   Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Ben
+   Laurie, William Leibzon, John Levine, Edward Lewis, David MacQuigg,
+   Allison Mankin, Bill Manning, David Meyer, Pekka Nikander, Mans
+   Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan
+   Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten Strotmann, Pekka
+   Savola, Chip Sharp, James Snell, Michael Thomas, Paul Vixie, Sam
+   Weiler, Florian Weimer, Bert Wijnen, and Dan Wing.
+
+
+
+IAB, et al.                  Informational                     [Page 15]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+10.  IAB Members at the Time of This Writing
+
+   Loa Andersson
+   Gonzalo Camarillo
+   Stuart Cheshire
+   Russ Housley
+   Olaf Kolkman
+   Gregory Lebovitz
+   Barry Leiba
+   Kurtis Lindqvist
+   Andrew Malis
+   Danny McPherson
+   David Oran
+   Dave Thaler
+   Lixia Zhang
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC1035]        Mockapetris, P., "Domain names - implementation and
+                    specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1464]        Rosenbaum, R., "Using the Domain Name System To
+                    Store Arbitrary String Attributes", RFC 1464,
+                    May 1993.
+
+   [RFC2535]        Eastlake, D., "Domain Name System Security
+                    Extensions", RFC 2535, March 1999.
+
+   [RFC2671]        Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+                    RFC 2671, August 1999.
+
+   [RFC3597]        Gustafsson, A., "Handling of Unknown DNS Resource
+                    Record (RR) Types", RFC 3597, September 2003.
+
+   [RFC5395]        Eastlake, D., "Domain Name System (DNS) IANA
+                    Considerations", BCP 42, RFC 5395, November 2008.
+
+11.2.  Informative References
+
+   [DNSEXT-DNS-SD]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+                    Discovery", Work in Progress, September 2008.
+
+   [Dyer87]         Dyer, S. and F. Hsu, "Hesiod, Project Athena
+                    Technical Plan - Name Service", Version 1.9,
+                    April 1987.
+
+
+
+
+IAB, et al.                  Informational                     [Page 16]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   [RFC1123]        Braden, R., "Requirements for Internet Hosts -
+                    Application and Support", STD 3, RFC 1123,
+                    October 1989.
+
+   [RFC1535]        Gavron, E., "A Security Problem and Proposed
+                    Correction With Widely Deployed DNS Software",
+                    RFC 1535, October 1993.
+
+   [RFC2163]        Allocchio, C., "Using the Internet DNS to Distribute
+                    MIXER Conformant Global Address Mapping (MCGAM)",
+                    RFC 2163, January 1998.
+
+   [RFC2181]        Elz, R. and R. Bush, "Clarifications to the DNS
+                    Specification", RFC 2181, July 1997.
+
+   [RFC2672]        Crawford, M., "Non-Terminal DNS Name Redirection",
+                    RFC 2672, August 1999.
+
+   [RFC3445]        Massey, D. and S. Rose, "Limiting the Scope of the
+                    KEY Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3467]        Klensin, J., "Role of the Domain Name System (DNS)",
+                    RFC 3467, February 2003.
+
+   [RFC3761]        Faltstrom, P. and M. Mealling, "The E.164 to Uniform
+                    Resource Identifiers (URI) Dynamic Delegation
+                    Discovery System (DDDS) Application (ENUM)",
+                    RFC 3761, April 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.
+
+   [RFC4511]        Sermersheim, J., "Lightweight Directory Access
+                    Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4592]        Lewis, E., "The Role of Wildcards in the Domain Name
+                    System", RFC 4592, July 2006.
+
+
+
+
+
+IAB, et al.                  Informational                     [Page 17]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   [RFC4871]        Allman, E., Callas, J., Delany, M., Libbey, M.,
+                    Fenton, J., and M. Thomas, "DomainKeys Identified
+                    Mail (DKIM) Signatures", RFC 4871, May 2007.
+
+Authors' Addresses
+
+   Internet Architecture Board
+
+   EMail: iab@iab.org
+
+
+   Patrik Faltstrom (editor)
+
+   EMail: paf@cisco.com
+
+
+   Rob Austein (editor)
+
+   EMail: sra@isc.org
+
+
+   Peter Koch (editor)
+
+   EMail: pk@denic.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB, et al.                  Informational                     [Page 18]
+
diff --git a/doc/rfc/rfc5625.txt b/doc/rfc/rfc5625.txt
new file mode 100644
index 000000000000..102d7e8770ee
--- /dev/null
+++ b/doc/rfc/rfc5625.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                          R. Bellis
+Request for Comments: 5625                                    Nominet UK
+BCP: 152                                                     August 2009
+Category: Best Current Practice
+
+
+                  DNS Proxy Implementation Guidelines
+
+Abstract
+
+   This document provides guidelines for the implementation of DNS
+   proxies, as found in broadband gateways and other similar network
+   devices.
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                   Best Current Practice                  [Page 1]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................3
+   3. The Transparency Principle ......................................3
+   4. Protocol Conformance ............................................4
+      4.1. Unexpected Flags and Data ..................................4
+      4.2. Label Compression ..........................................4
+      4.3. Unknown Resource Record Types ..............................4
+      4.4. Packet Size Limits .........................................4
+           4.4.1. TCP Transport .......................................5
+           4.4.2. Extension Mechanisms for DNS (EDNS0) ................6
+           4.4.3. IP Fragmentation ....................................6
+      4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7
+   5. DHCP's Interaction with DNS .....................................7
+      5.1. Domain Name Server (DHCP Option 6) .........................7
+      5.2. Domain Name (DHCP Option 15) ...............................8
+      5.3. DHCP Leases ................................................8
+   6. Security Considerations .........................................9
+      6.1. Forgery Resilience .........................................9
+      6.2. Interface Binding .........................................10
+      6.3. Packet Filtering ..........................................10
+   7. Acknowledgements ...............................................10
+   8. References .....................................................11
+      8.1. Normative References ......................................11
+      8.2. Informative References ....................................12
+
+1.  Introduction
+
+   Research has found ([SAC035], [DOTSE]) that many commonly used
+   broadband gateways (and similar devices) contain DNS proxies that are
+   incompatible in various ways with current DNS standards.
+
+   These proxies are usually simple DNS forwarders, but typically do not
+   have any caching capabilities.  The proxy serves as a convenient
+   default DNS resolver for clients on the LAN, but relies on an
+   upstream resolver (e.g., at an ISP) to perform recursive DNS lookups.
+
+   Note that to ensure full DNS protocol interoperability it is
+   preferred that client stub resolvers should communicate directly with
+   full-feature, upstream recursive resolvers wherever possible.
+
+   That notwithstanding, this document describes the incompatibilities
+   that have been discovered and offers guidelines to implementors on
+   how to provide better interoperability in those cases where the
+   client must use the broadband gateway's DNS proxy.
+
+
+
+
+
+Bellis                   Best Current Practice                  [Page 2]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  The Transparency Principle
+
+   It is not considered practical for a simple DNS proxy to implement
+   all current and future DNS features.
+
+   There are several reasons why this is the case:
+
+   o  Broadband gateways usually have limited hardware resources.
+
+   o  Firmware upgrade cycles are long, and many users do not routinely
+      apply upgrades when they become available.
+
+   o  No one knows what those future DNS features will be or how they
+      might be implemented.
+
+   o  Doing so would substantially complicate the configuration user
+      interface (UI) of the device.
+
+   Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0
+   below) are intended to be used as "hop-by-hop" mechanisms.  If the
+   DNS proxy is considered to be such a "hop" in the resolution chain,
+   then for it to function correctly, it would need to be fully
+   compliant with all such mechanisms.
+
+   [SAC035] shows that the more actively a proxy participates in the DNS
+   protocol, the more likely it is that it will somehow interfere with
+   the flow of messages between the DNS client and the upstream
+   recursive resolvers.
+
+   The role of the proxy should therefore be no more and no less than to
+   receive DNS requests from clients on the LAN side, forward those
+   verbatim to one of the known upstream recursive resolvers on the WAN
+   side, and ensure that the whole response is returned verbatim to the
+   original client.
+
+   It is RECOMMENDED that proxies should be as transparent as possible,
+   such that any "hop-by-hop" mechanisms or newly introduced protocol
+   extensions operate as if the proxy were not there.
+
+   Except when required to enforce an active security or network policy
+   (such as maintaining a pre-authentication "walled garden"), end-users
+   SHOULD be able to send their DNS queries to specified upstream
+
+
+
+Bellis                   Best Current Practice                  [Page 3]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+   resolvers, thereby bypassing the proxy altogether.  In this case, the
+   gateway SHOULD NOT modify the DNS request or response packets in any
+   way.
+
+4.  Protocol Conformance
+
+4.1.  Unexpected Flags and Data
+
+   The Transparency Principle above, when combined with Postel's
+   Robustness Principle [RFC0793], suggests that DNS proxies should not
+   arbitrarily reject or otherwise drop requests or responses based on
+   perceived non-compliance with standards.
+
+   For example, some proxies have been observed to drop any packet
+   containing either the "Authentic Data" (AD) or "Checking Disabled"
+   (CD) bits from DNSSEC [RFC4035].  This may be because [RFC1035]
+   originally specified that these unused "Z" flag bits "MUST" be zero.
+   However, these flag bits were always intended to be reserved for
+   future use, so refusing to proxy any packet containing these flags
+   (now that uses for those flags have indeed been defined) is not
+   appropriate.
+
+   Therefore, proxies MUST ignore any unknown DNS flags and proxy those
+   packets as usual.
+
+4.2.  Label Compression
+
+   Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
+
+   Proxies MUST forward packets regardless of the presence or absence of
+   compressed labels therein.
+
+4.3.  Unknown Resource Record Types
+
+   [RFC3597] requires that resolvers MUST handle Resource Records (RRs)
+   of unknown type transparently.
+
+   All requests and responses MUST be proxied regardless of the values
+   of the QTYPE and QCLASS fields.
+
+   Similarly, all responses MUST be proxied regardless of the values of
+   the TYPE and CLASS fields of any Resource Record therein.
+
+4.4.  Packet Size Limits
+
+   [RFC1035] specifies that the maximum size of the DNS payload in a UDP
+   packet is 512 octets.  Where the required portions of a response
+   would not fit inside that limit, the DNS server MUST set the
+
+
+
+Bellis                   Best Current Practice                  [Page 4]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+   "TrunCation" (TC) bit in the DNS response header to indicate that
+   truncation has occurred.  There are however two standard mechanisms
+   (described in Sections 4.4.1 and 4.4.2) for transporting responses
+   larger than 512 octets.
+
+   Many proxies have been observed to truncate all responses at 512
+   octets, and others at a packet size related to the WAN MTU, in either
+   case doing so without correctly setting the TC bit.
+
+   Other proxies have been observed to remove the TC bit in server
+   responses that correctly had the TC bit set by the server.
+
+   If a DNS response is truncated but the TC bit is not set, then client
+   failures may result.  In particular, a naive DNS client library might
+   suffer crashes due to reading beyond the end of the data actually
+   received.
+
+   Since UDP packets larger than 512 octets are now expected in normal
+   operation, proxies SHOULD NOT truncate UDP packets that exceed that
+   size.  See Section 4.4.3 for recommendations for packet sizes
+   exceeding the WAN MTU.
+
+   If a proxy must unilaterally truncate a response, then the proxy MUST
+   set the TC bit.  Similarly, proxies MUST NOT remove the TC bit from
+   responses.
+
+4.4.1.  TCP Transport
+
+   Should a UDP query fail because of truncation, the standard fail-over
+   mechanism is to retry the query using TCP, as described in Section
+   6.1.3.2 of [RFC1123].
+
+   Whilst TCP transport is not strictly mandatory, it is supported by
+   the vast majority of stub resolvers and recursive servers.  Lack of
+   support in the proxy prevents this fail-over mechanism from working.
+
+   DNS proxies MUST therefore be prepared to receive and forward queries
+   over TCP.
+
+   Note that it is unlikely that a client would send a request over TCP
+   unless it had already received a truncated UDP response.  Some
+   "smart" proxies have been observed to first forward any request
+   received over TCP to an upstream resolver over UDP, only for the
+   response to be truncated, causing the proxy to retry over TCP.  Such
+   behaviour increases network traffic and causes delay in DNS
+   resolution since the initial UDP request is doomed to fail.
+
+
+
+
+
+Bellis                   Best Current Practice                  [Page 5]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+   Therefore, whenever a proxy receives a request over TCP, the proxy
+   SHOULD forward the query over TCP and SHOULD NOT attempt the same
+   query over UDP first.
+
+4.4.2.  Extension Mechanisms for DNS (EDNS0)
+
+   The "Extension Mechanism for DNS" [RFC2671] was introduced to allow
+   the transport of larger DNS packets over UDP and also to allow for
+   additional request and response flags.
+
+   A client may send an OPT Resource Record (OPT RR) in the Additional
+   Section of a request to indicate that it supports a specific receive
+   buffer size.  The OPT RR also includes the "DNSSEC OK" (DO) flag used
+   by DNSSEC to indicate that DNSSEC-related RRs should be returned to
+   the client.
+
+   However, some proxies have been observed to either reject (with a
+   FORMERR response code) or black-hole any packet containing an OPT RR.
+   As per Section 4.1, proxies MUST NOT refuse to proxy such packets.
+
+4.4.3.  IP Fragmentation
+
+   Support for UDP packet sizes exceeding the WAN MTU depends on the
+   gateway's algorithm for handling fragmented IP packets.  Several
+   methods are possible:
+
+   1.  Fragments are dropped.
+
+   2.  Fragments are forwarded individually as they're received.
+
+   3.  Complete packets are reassembled on the gateway and then re-
+       fragmented (if necessary) as they're forwarded to the client.
+
+   Method 1 above will cause compatibility problems with EDNS0 unless
+   the DNS client is configured to advertise an EDNS0 buffer size
+   limited to the WAN MTU less the size of the IP header.  Note that RFC
+   2671 does recommend that the path MTU should be taken into account
+   when using EDNS0.
+
+   Also, whilst the EDNS0 specification allows for a buffer size of up
+   to 65535 octets, most common DNS server implementations do not
+   support a buffer size above 4096 octets.
+
+   Therefore (irrespective of which of the above methods is in use),
+   proxies SHOULD be capable of forwarding UDP packets up to a payload
+   size of at least 4096 octets.
+
+
+
+
+
+Bellis                   Best Current Practice                  [Page 6]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+   NB: in theory, IP fragmentation may also occur if the LAN MTU is
+   smaller than the WAN MTU, although the author has not observed such a
+   configuration in use on any residential broadband service.
+
+4.5.  Secret Key Transaction Authentication for DNS (TSIG)
+
+   [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
+   requests and responses at the packet level.
+
+   Any modifications made to the DNS portions of a TSIG-signed query or
+   response packet (with the exception of the Query ID) will cause a
+   TSIG authentication failure.
+
+   DNS proxies MUST implement Section 4.7 of [RFC2845] and either
+   forward packets unchanged (as recommended above) or fully implement
+   TSIG.
+
+   As per Section 4.3, DNS proxies MUST be capable of proxying packets
+   containing TKEY [RFC2930] Resource Records.
+
+   NB: any DNS proxy (such as those commonly found in WiFi hotspot
+   "walled gardens") that transparently intercepts all DNS queries and
+   that returns unsigned responses to signed queries, will also cause
+   TSIG authentication failures.
+
+5.  DHCP's Interaction with DNS
+
+   Whilst this document is primarily about DNS proxies, most consumers
+   rely on DHCP [RFC2131] to obtain network configuration settings.
+   Such settings include the client machine's IP address, subnet mask,
+   and default gateway, but also include DNS-related settings.
+
+   It is therefore appropriate to examine how DHCP affects client DNS
+   configuration.
+
+5.1.  Domain Name Server (DHCP Option 6)
+
+   Most gateways default to supplying their own IP address in the DHCP
+   "Domain Name Server" option [RFC2132].  The net result is that
+   without explicit re-configuration many DNS clients will, by default,
+   send queries to the gateway's DNS proxy.  This is understandable
+   behaviour given that the correct upstream settings are not usually
+   known at boot time.
+
+
+
+
+
+
+
+
+Bellis                   Best Current Practice                  [Page 7]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+   Most gateways learn their own DNS settings via values supplied by an
+   ISP via DHCP or PPP over the WAN interface.  However, whilst many
+   gateways do allow the device administrator to override those values,
+   some gateways only use those supplied values to affect the proxy's
+   own forwarding function, and do not offer these values via DHCP.
+
+   When using such a device, the only way to avoid using the DNS proxy
+   is to hard-code the required values in the client operating system.
+   This may be acceptable for a desktop system but it is inappropriate
+   for mobile devices that are regularly used on many different
+   networks.
+
+   As per Section 3, end-users SHOULD be able to send their DNS queries
+   directly to specified upstream resolvers, ideally without hard-coding
+   those settings in their stub resolver.
+
+   It is therefore RECOMMENDED that gateways SHOULD support device-
+   administrator configuration of values for the "Domain Name Server"
+   DHCP option.
+
+5.2.  Domain Name (DHCP Option 15)
+
+   A significant amount of traffic to the DNS Root Name Servers is for
+   invalid top-level domain names, and some of that traffic can be
+   attributed to particular equipment vendors whose firmware defaults
+   this DHCP option to specific values.
+
+   Since no standard exists for a "local" scoped domain name suffix, it
+   is RECOMMENDED that the default value for this option SHOULD be
+   empty, and that this option MUST NOT be sent to clients when no value
+   is configured.
+
+5.3.  DHCP Leases
+
+   It is noted that some DHCP servers in broadband gateways offer, by
+   default, their own IP address for the "Domain Name Server" option (as
+   described above) but then automatically start offering the upstream
+   servers' addresses once they've been learnt over the WAN interface.
+
+   In general, this behaviour is highly desirable, but the effect for
+   the end-user is that the settings used depend on whether the DHCP
+   lease was obtained before or after the WAN link was established.
+
+   If the DHCP lease is obtained whilst the WAN link is down, then the
+   DHCP client (and hence the DNS client) will not receive the correct
+   values until the DHCP lease is renewed.
+
+
+
+
+
+Bellis                   Best Current Practice                  [Page 8]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+   Whilst no specific recommendations are given here, vendors may wish
+   to give consideration to the length of DHCP leases and to whether
+   some mechanism for forcing a DHCP lease renewal might be appropriate.
+
+   Another possibility is that the learnt upstream values might be
+   persisted in non-volatile memory such that on reboot the same values
+   can be automatically offered via DHCP.  However, this does run the
+   risk that incorrect values are initially offered if the device is
+   moved or connected to another ISP.
+
+   Alternatively, the DHCP server might only issue very short (i.e., 60
+   second) leases while the WAN link is down, only reverting to more
+   typical lease lengths once the WAN link is up and the upstream DNS
+   servers are known.  Indeed, with such a configuration it may be
+   possible to avoid the need to implement a DNS proxy function in the
+   broadband gateway at all.
+
+6.  Security Considerations
+
+   This document introduces no new protocols.  However, there are some
+   security-related recommendations for vendors that are listed here.
+
+6.1.  Forgery Resilience
+
+   Whilst DNS proxies are not usually full-feature resolvers, they
+   nevertheless share some characteristics with them.
+
+   Notwithstanding the recommendations above about transparency, many
+   DNS proxies are observed to pick a new Query ID for outbound requests
+   to ensure that responses are directed to the correct client.
+
+   NB: changing the Query ID is acceptable and compatible with proxying
+   TSIG-signed packets since the TSIG signature calculation is based on
+   the original message ID, which is carried in the TSIG RR.
+
+   It has been standard guidance for many years that each DNS query
+   should use a randomly generated Query ID.  However, many proxies have
+   been observed picking sequential Query IDs for successive requests.
+
+   It is strongly RECOMMENDED that DNS proxies follow the relevant
+   recommendations in [RFC5452], particularly those in Section 9.2
+   relating to randomisation of Query IDs and source ports.  This also
+   applies to source port selection within any NAT function.
+
+   If a DNS proxy is running on a broadband gateway with NAT that is
+   compliant with [RFC4787], then it SHOULD also follow the
+   recommendations in Section 10 of [RFC5452] concerning how long DNS
+   state is kept.
+
+
+
+Bellis                   Best Current Practice                  [Page 9]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+6.2.  Interface Binding
+
+   Some gateways have been observed to have their DNS proxy listening on
+   both internal (LAN) and external (WAN) interfaces.  In this
+   configuration, it is possible for the proxy to be used to mount
+   reflector attacks as described in [RFC5358].
+
+   The DNS proxy in a gateway SHOULD NOT, by default, be accessible from
+   the WAN interfaces of the device.
+
+6.3.  Packet Filtering
+
+   The Transparency and Robustness Principles are not entirely
+   compatible with the deep packet-inspection features of security
+   appliances such as firewalls, which are intended to protect systems
+   on the inside of a network from rogue traffic.
+
+   However, a clear distinction may be made between traffic that is
+   intrinsically malformed and that which merely contains unexpected
+   data.
+
+   Examples of malformed packets that MAY be dropped include:
+
+   o  invalid compression pointers (i.e., those that point outside of
+      the current packet or that might cause a parsing loop)
+
+   o  incorrect counts for the Question, Answer, Authority, and
+      Additional Sections (although care should be taken where
+      truncation is a possibility)
+
+   Dropped packets will cause the client to repeatedly retransmit the
+   original request, with the client only detecting the error after
+   several retransmit intervals.
+
+   In these circumstances, proxies SHOULD synthesise a suitable DNS
+   error response to the client (i.e., SERVFAIL) instead of dropping the
+   packet completely.  This will allow the client to detect the error
+   immediately.
+
+7.  Acknowledgements
+
+   The author would particularly like to acknowledge the assistance of
+   Lisa Phifer of Core Competence.  In addition, the author is grateful
+   for the feedback from the members of the DNSEXT Working Group.
+
+
+
+
+
+
+
+Bellis                   Best Current Practice                 [Page 10]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, March 1997.
+
+   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+              Extensions", RFC 2132, March 1997.
+
+   [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.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
+              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+              RFC 4787, January 2007.
+
+   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
+              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+              October 2008.
+
+
+
+
+
+Bellis                   Best Current Practice                 [Page 11]
+
+RFC 5625          DNS Proxy Implementation Guidelines        August 2009
+
+
+   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
+              Resilient against Forged Answers", RFC 5452, January 2009.
+
+8.2.  Informative References
+
+   [DOTSE]    Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
+              Routers", February 2008,
+              .
+
+   [SAC035]   Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
+              Broadband Routers and Firewalls", September 2008,
+              .
+
+Author's Address
+
+   Ray Bellis
+   Nominet UK
+   Edmund Halley Road
+   Oxford  OX4 4DQ
+   United Kingdom
+
+   Phone: +44 1865 332211
+   EMail: ray.bellis@nominet.org.uk
+   URI:   http://www.nominet.org.uk/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                   Best Current Practice                 [Page 12]
+
diff --git a/doc/rfc/rfc5702.txt b/doc/rfc/rfc5702.txt
new file mode 100644
index 000000000000..5155cc6440c8
--- /dev/null
+++ b/doc/rfc/rfc5702.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                          J. Jansen
+Request for Comments: 5702                                    NLnet Labs
+Category: Standards Track                                   October 2009
+
+
+                  Use of SHA-2 Algorithms with RSA in
+              DNSKEY and RRSIG Resource Records for DNSSEC
+
+Abstract
+
+   This document describes how to produce RSA/SHA-256 and RSA/SHA-512
+   DNSKEY and RRSIG resource records for use in the Domain Name System
+   Security Extensions (RFC 4033, RFC 4034, and RFC 4035).
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen                      Standards Track                     [Page 1]
+
+RFC 5702                    DNSSEC RSA/SHA-2                October 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. DNSKEY Resource Records .........................................3
+      2.1. RSA/SHA-256 DNSKEY Resource Records ........................3
+      2.2. RSA/SHA-512 DNSKEY Resource Records ........................3
+   3. RRSIG Resource Records ..........................................3
+      3.1. RSA/SHA-256 RRSIG Resource Records .........................4
+      3.2. RSA/SHA-512 RRSIG Resource Records .........................4
+   4. Deployment Considerations .......................................5
+      4.1. Key Sizes ..................................................5
+      4.2. Signature Sizes ............................................5
+   5. Implementation Considerations ...................................5
+      5.1. Support for SHA-2 Signatures ...............................5
+      5.2. Support for NSEC3 Denial of Existence ......................5
+   6. Examples ........................................................6
+      6.1. RSA/SHA-256 Key and Signature ..............................6
+      6.2. RSA/SHA-512 Key and Signature ..............................7
+   7. IANA Considerations .............................................8
+   8. Security Considerations .........................................8
+      8.1. SHA-1 versus SHA-2 Considerations for RRSIG
+           Resource Records ...........................................8
+      8.2. Signature Type Downgrade Attacks ...........................8
+   9. Acknowledgments .................................................9
+   10. References .....................................................9
+      10.1. Normative References ......................................9
+      10.2. Informative References ....................................9
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global, hierarchical distributed
+   database for Internet Naming.  The DNS has been extended to use
+   cryptographic keys and digital signatures for the verification of the
+   authenticity and integrity of its data.  [RFC4033], [RFC4034], and
+   [RFC4035] describe these DNS Security Extensions, called DNSSEC.
+
+   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
+   and specifies a list of cryptographic algorithms to use.  This
+   document extends that list with the algorithms RSA/SHA-256 and RSA/
+   SHA-512, and specifies how to store DNSKEY data and how to produce
+   RRSIG resource records with these hash algorithms.
+
+   Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family
+   of algorithms is assumed in this document.
+
+
+
+
+
+
+
+Jansen                      Standards Track                     [Page 2]
+
+RFC 5702                    DNSSEC RSA/SHA-2                October 2009
+
+
+   To refer to both SHA-256 and SHA-512, this document will use the name
+   SHA-2.  This is done to improve readability.  When a part of text is
+   specific for either SHA-256 or SHA-512, their specific names are
+   used.  The same goes for RSA/SHA-256 and RSA/SHA-512, which will be
+   grouped using the name RSA/SHA-2.
+
+   The term "SHA-2" is not officially defined but is usually used to
+   refer to the collection of the algorithms SHA-224, SHA-256, SHA-384,
+   and SHA-512.  Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2
+   will only refer to SHA-256 and SHA-512 in this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  DNSKEY Resource Records
+
+   The format of the DNSKEY RR can be found in [RFC4034].  [RFC3110]
+   describes the use of RSA/SHA-1 for DNSSEC signatures.
+
+2.1.  RSA/SHA-256 DNSKEY Resource Records
+
+   RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
+   resource records (RRs) with the algorithm number 8.
+
+   For interoperability, as in [RFC3110], the key size of RSA/SHA-256
+   keys MUST NOT be less than 512 bits and MUST NOT be more than 4096
+   bits.
+
+2.2.  RSA/SHA-512 DNSKEY Resource Records
+
+   RSA public keys for use with RSA/SHA-512 are stored in DNSKEY
+   resource records (RRs) with the algorithm number 10.
+
+   The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and
+   MUST NOT be more than 4096 bits.
+
+3.  RRSIG Resource Records
+
+   The value of the signature field in the RRSIG RR follows the RSASSA-
+   PKCS1-v1_5 signature scheme and is calculated as follows.  The values
+   for the RDATA fields that precede the signature data are specified in
+   [RFC4034].
+
+
+
+
+
+
+
+
+Jansen                      Standards Track                     [Page 3]
+
+RFC 5702                    DNSSEC RSA/SHA-2                October 2009
+
+
+   hash = SHA-XXX(data)
+
+   Here XXX is either 256 or 512, depending on the algorithm used, as
+   specified in FIPS PUB 180-3; "data" is the wire format data of the
+   resource record set that is signed, as specified in [RFC4034].
+
+   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
+
+   Here "|" is concatenation; "00", "01", "FF", and "00" are fixed
+   octets of corresponding hexadecimal value; "e" is the private
+   exponent of the signing RSA key; and "n" is the public modulus of the
+   signing key.  The FF octet MUST be repeated the exact number of times
+   so that the total length of the concatenated term in parentheses
+   equals the length of the modulus of the signer's public key ("n").
+
+   The "prefix" is intended to make the use of standard cryptographic
+   libraries easier.  These specifications are taken directly from the
+   specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of
+   [RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2
+   of [RFC3447]).  The prefixes for the different algorithms are
+   specified below.
+
+3.1.  RSA/SHA-256 RRSIG Resource Records
+
+   RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
+   records (RRs) with algorithm number 8.
+
+   The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as
+   specified in PKCS #1 v2.1 [RFC3447]:
+
+   hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
+
+3.2.  RSA/SHA-512 RRSIG Resource Records
+
+   RSA/SHA-512 signatures are stored in the DNS using RRSIG resource
+   records (RRs) with algorithm number 10.
+
+   The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as
+   specified in PKCS #1 v2.1 [RFC3447]:
+
+   hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
+
+
+
+
+
+
+
+
+
+
+Jansen                      Standards Track                     [Page 4]
+
+RFC 5702                    DNSSEC RSA/SHA-2                October 2009
+
+
+4.  Deployment Considerations
+
+4.1.  Key Sizes
+
+   Apart from the restrictions in Section 2, this document will not
+   specify what size of keys to use.  That is an operational issue and
+   depends largely on the environment and intended use.  A good starting
+   point for more information would be NIST SP 800-57 [NIST800-57].
+
+4.2.  Signature Sizes
+
+   In this family of signing algorithms, the size of signatures is
+   related to the size of the key and not to the hashing algorithm used
+   in the signing process.  Therefore, RRSIG resource records produced
+   with RSA/SHA-256 or RSA/SHA-512 will have the same size as those
+   produced with RSA/SHA-1, if the keys have the same length.
+
+5.  Implementation Considerations
+
+5.1.  Support for SHA-2 Signatures
+
+   DNSSEC-aware implementations SHOULD be able to support RRSIG and
+   DNSKEY resource records created with the RSA/SHA-2 algorithms as
+   defined in this document.
+
+5.2.  Support for NSEC3 Denial of Existence
+
+   [RFC5155] defines new algorithm identifiers for existing signing
+   algorithms, to indicate that zones signed with these algorithm
+   identifiers can use NSEC3 as well as NSEC records to provide denial
+   of existence.  That mechanism was chosen to protect implementations
+   predating RFC 5155 from encountering resource records about which
+   they could not know.  This document does not define such algorithm
+   aliases.
+
+   A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate
+   negative answers in the form of both NSEC and NSEC3 with hash
+   algorithm 1, as defined in [RFC5155].  An authoritative server that
+   does not implement NSEC3 MAY still serve zones that use RSA/SHA-2
+   with NSEC denial of existence.
+
+
+
+
+
+
+
+
+
+
+
+Jansen                      Standards Track                     [Page 5]
+
+RFC 5702                    DNSSEC RSA/SHA-2                October 2009
+
+
+6.  Examples
+
+6.1.  RSA/SHA-256 Key and Signature
+
+   Given a private key with the following values (in Base64):
+
+   Private-key-format: v1.2
+   Algorithm:       8 (RSASHA256)
+   Modulus:         wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm
+                    idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q==
+   PublicExponent:  AQAB
+   PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/
+                    HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ==
+   Prime1:          4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk=
+   Prime2:          2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE=
+   Exponent1:       G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk=
+   Exponent2:       GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE=
+   Coefficient:     icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q=
+
+   The DNSKEY record for this key would be:
+
+   example.net.     3600  IN  DNSKEY  (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI
+                    my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P
+                    kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b}
+
+   With this key, sign the following RRSet, consisting of 1 A record:
+
+   www.example.net. 3600  IN  A  192.0.2.91
+
+   If the inception date is set at 00:00 hours on January 1st, 2000, and
+   the expiration date at 00:00 hours on January 1st, 2030, the
+   following signature should be created:
+
+ www.example.net. 3600  IN  RRSIG  (A 8 3 3600 20300101000000
+                     20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9
+                     l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa
+                     cFYK/lPtPiVYP4bwg==);{id = 9033}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen                      Standards Track                     [Page 6]
+
+RFC 5702                    DNSSEC RSA/SHA-2                October 2009
+
+
+6.2.  RSA/SHA-512 Key and Signature
+
+   Given a private key with the following values (in Base64):
+
+   Private-key-format: v1.2
+   Algorithm:       10 (RSASHA512)
+   Modulus:         0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf
+                    Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk
+                    8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V
+                    jXZlNKdyit99waaE4s=
+   PublicExponent:  AQAB
+   PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6
+                    AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj
+                    yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3
+                    SEIAsrB043XzGrKIVE=
+   Prime1:          8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x
+                    nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ==
+   Prime2:          3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK
+                    Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw==
+   Exponent1:       v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM
+                    MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q==
+   Exponent2:       m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J
+                    PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w==
+   Coefficient:     Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q
+                    /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ==
+
+   The DNSKEY record for this key would be:
+
+   example.net.    3600  IN  DNSKEY  (256 3 10 AwEAAdHoNTOW+et86KuJOWRD
+                   p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD
+                   xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g
+                   pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL
+                   );{id = 3740 (zsk), size = 1024b}
+
+   With this key, sign the following RRSet, consisting of 1 A record:
+
+   www.example.net. 3600  IN  A  192.0.2.91
+
+   If the inception date is set at 00:00 hours on January 1st, 2000, and
+   the expiration date at 00:00 hours on January 1st, 2030, the
+   following signature should be created:
+
+   www.example.net. 3600  IN  RRSIG  (A 10 3 3600 20300101000000
+                    20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t
+                    6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa
+                    eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL
+                    DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw
+                    =);{id = 3740}
+
+
+
+Jansen                      Standards Track                     [Page 7]
+
+RFC 5702                    DNSSEC RSA/SHA-2                October 2009
+
+
+7.  IANA Considerations
+
+   This document updates the IANA registry "DNS SECURITY ALGORITHM
+   NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols).  The
+   following entries are added to the registry:
+
+                                             Zone  Trans.
+   Value   Description       Mnemonic    Signing    Sec.   References
+     8     RSA/SHA-256      RSASHA256          Y      *    RFC 5702
+    10     RSA/SHA-512      RSASHA512          Y      *    RFC 5702
+
+   * There has been no determination of standardization of the use of
+     this algorithm with Transaction Security.
+
+8.  Security Considerations
+
+8.1.  SHA-1 versus SHA-2 Considerations for RRSIG Resource Records
+
+   Users of DNSSEC are encouraged to deploy SHA-2 as soon as software
+   implementations allow for it.  SHA-2 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-2 is the better choice for use in
+   DNSSEC records.
+
+   SHA-2 is considered sufficiently strong for the immediate future, but
+   predictions about future development in cryptography and
+   cryptanalysis are beyond the scope of this document.
+
+   The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one
+   used for RSA/SHA-1 signatures.  This should ease implementation of
+   the new hashing algorithms in DNSSEC software.
+
+8.2.  Signature Type Downgrade Attacks
+
+   Since each RRSet MUST be signed with each algorithm present in the
+   DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a
+   malicious party cannot filter out the RSA/SHA-2 RRSIG and force the
+   validator to use the RSA/SHA-1 signature if both are present in the
+   zone.  This should provide resilience against algorithm downgrade
+   attacks, if the validator supports RSA/SHA-2.
+
+
+
+
+
+
+
+
+
+Jansen                      Standards Track                     [Page 8]
+
+RFC 5702                    DNSSEC RSA/SHA-2                October 2009
+
+
+9.  Acknowledgments
+
+   This document is a minor extension to [RFC4034].  Also, we try to
+   follow the documents [RFC3110] and [RFC4509] for consistency.  The
+   authors of and contributors to these documents are gratefully
+   acknowledged for their hard work.
+
+   The following people provided additional feedback and text: Jaap
+   Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont,
+   Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose,
+   Michael St. Johns, and Wouter Wijngaards.
+
+10.  References
+
+10.1.  Normative References
+
+   [FIPS.180-3.2008]
+              National Institute of Standards and Technology, "Secure
+              Hash Standard", FIPS PUB 180-3, October 2008.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+              Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for 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.
+
+10.2.  Informative References
+
+   [NIST800-57]
+              Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
+              "Recommendations for Key Management", NIST SP 800-57,
+              March 2007.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+
+
+Jansen                      Standards Track                     [Page 9]
+
+RFC 5702                    DNSSEC RSA/SHA-2                October 2009
+
+
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+Author's Address
+
+   Jelte Jansen
+   NLnet Labs
+   Science Park 140
+   1098 XG Amsterdam
+   NL
+
+   EMail: jelte@NLnetLabs.nl
+   URI:   http://www.nlnetlabs.nl/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen                      Standards Track                    [Page 10]
+
diff --git a/lib/bind/configure.in b/lib/bind/configure.in
index 9b9b53b81cb4..89fd4ced1e57 100644
--- a/lib/bind/configure.in
+++ b/lib/bind/configure.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001, 2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-AC_REVISION($Revision: 1.90.18.43 $)
+AC_REVISION($Revision: 1.90.18.45 $)
 
 AC_INIT(resolv/herror.c)
 AC_PREREQ(2.13)
@@ -23,7 +23,7 @@ AC_CONFIG_HEADER(config.h)
 AC_CANONICAL_HOST
 
 AC_PROG_MAKE_SET
-AC_PROG_RANLIB
+AC_PROG_LIBTOOL
 AC_PROG_INSTALL
 
 AC_SUBST(STD_CINCLUDES)
diff --git a/lib/bind9/api b/lib/bind9/api
index 3a74aee14444..d76c156aa7b0 100644
--- a/lib/bind9/api
+++ b/lib/bind9/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 31
-LIBREVISION = 1
+LIBREVISION = 2
 LIBAGE = 1
diff --git a/lib/bind9/check.c b/lib/bind9/check.c
index 2967650ef055..721f186c3256 100644
--- a/lib/bind9/check.c
+++ b/lib/bind9/check.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: check.c,v 1.44.18.41 2008/03/29 23:46:10 tbox Exp $ */
+/* $Id: check.c,v 1.44.18.45 2009/06/03 00:08:52 marka Exp $ */
 
 /*! \file */
 
@@ -784,8 +784,11 @@ validate_masters(const cfg_obj_t *obj, const cfg_obj_t *config,
 			if (new == NULL)
 				goto cleanup;
 			if (stackcount != 0) {
+				void *ptr;
+
+				DE_CONST(stack, ptr);
 				memcpy(new, stack, oldsize);
-				isc_mem_put(mctx, stack, oldsize);
+				isc_mem_put(mctx, ptr, oldsize);
 			}
 			stack = new;
 			stackcount = newlen;
@@ -798,8 +801,12 @@ validate_masters(const cfg_obj_t *obj, const cfg_obj_t *config,
 		goto resume;
 	}
  cleanup:
-	if (stack != NULL)
-		isc_mem_put(mctx, stack, stackcount * sizeof(*stack));
+	if (stack != NULL) {
+		void *ptr;
+
+		DE_CONST(stack, ptr);
+		isc_mem_put(mctx, ptr, stackcount * sizeof(*stack));
+	}
 	isc_symtab_destroy(&symtab);
 	*countp = count;
 	return (result);
@@ -918,9 +925,9 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions,
 	{ "notify", MASTERZONE | SLAVEZONE },
 	{ "also-notify", MASTERZONE | SLAVEZONE },
 	{ "dialup", MASTERZONE | SLAVEZONE | STUBZONE },
-	{ "delegation-only", HINTZONE | STUBZONE },
-	{ "forward", MASTERZONE | SLAVEZONE | STUBZONE | FORWARDZONE},
-	{ "forwarders", MASTERZONE | SLAVEZONE | STUBZONE | FORWARDZONE},
+	{ "delegation-only", HINTZONE | STUBZONE | DELEGATIONZONE },
+	{ "forward", MASTERZONE | SLAVEZONE | STUBZONE | FORWARDZONE },
+	{ "forwarders", MASTERZONE | SLAVEZONE | STUBZONE | FORWARDZONE },
 	{ "maintain-ixfr-base", MASTERZONE | SLAVEZONE },
 	{ "max-ixfr-log-size", MASTERZONE | SLAVEZONE },
 	{ "notify-source", MASTERZONE | SLAVEZONE },
@@ -1020,7 +1027,7 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions,
 
 	/*
 	 * Look for an already existing zone.
-	 * We need to make this cannonical as isc_symtab_define()
+	 * We need to make this canonical as isc_symtab_define()
 	 * deals with strings.
 	 */
 	dns_fixedname_init(&fixedname);
diff --git a/lib/bind9/include/bind9/getaddresses.h b/lib/bind9/include/bind9/getaddresses.h
index e6d030d76189..1385ad9e9bd7 100644
--- a/lib/bind9/include/bind9/getaddresses.h
+++ b/lib/bind9/include/bind9/getaddresses.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getaddresses.h,v 1.3.18.2 2005/04/29 00:15:48 marka Exp $ */
+/* $Id: getaddresses.h,v 1.3.18.4 2009/01/19 23:46:14 tbox Exp $ */
 
 #ifndef BIND9_GETADDRESSES_H
 #define BIND9_GETADDRESSES_H 1
@@ -40,7 +40,7 @@ bind9_getaddresses(const char *hostname, in_port_t port,
  * first 'addrsize' are returned and the remainder silently truncated.
  *
  * This routine may block.  If called by a program using the isc_app
- * framework, it should be surounded by isc_app_block()/isc_app_unblock().
+ * framework, it should be surrounded by isc_app_block()/isc_app_unblock().
  *
  *  Requires:
  *\li	'hostname' is not NULL.
@@ -48,7 +48,7 @@ bind9_getaddresses(const char *hostname, in_port_t port,
  *\li	'addrsize' > 0
  *\li	'addrcount' is not NULL.
  *
- * 
+ *
  * Returns:
  *\li	#ISC_R_SUCCESS
  *\li	#ISC_R_NOTFOUND
diff --git a/lib/dns/adb.c b/lib/dns/adb.c
index ae5dec85ec33..b9653910b804 100644
--- a/lib/dns/adb.c
+++ b/lib/dns/adb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: adb.c,v 1.215.18.24 2008/10/17 03:35:14 marka Exp $ */
+/* $Id: adb.c,v 1.215.18.26 2009/02/03 23:46:04 tbox Exp $ */
 
 /*! \file
  *
@@ -202,8 +202,6 @@ struct dns_adbname {
 /*% The adbfetch structure */
 struct dns_adbfetch {
 	unsigned int			magic;
-	dns_adbnamehook_t	       *namehook;
-	dns_adbentry_t		       *entry;
 	dns_fetch_t		       *fetch;
 	dns_rdataset_t			rdataset;
 };
@@ -1463,31 +1461,13 @@ new_adbfetch(dns_adb_t *adb) {
 		return (NULL);
 
 	f->magic = 0;
-	f->namehook = NULL;
-	f->entry = NULL;
 	f->fetch = NULL;
 
-	f->namehook = new_adbnamehook(adb, NULL);
-	if (f->namehook == NULL)
-		goto err;
-
-	f->entry = new_adbentry(adb);
-	if (f->entry == NULL)
-		goto err;
-
 	dns_rdataset_init(&f->rdataset);
 
 	f->magic = DNS_ADBFETCH_MAGIC;
 
 	return (f);
-
- err:
-	if (f->namehook != NULL)
-		free_adbnamehook(adb, &f->namehook);
-	if (f->entry != NULL)
-		free_adbentry(adb, &f->entry);
-	isc_mempool_put(adb->afmp, f);
-	return (NULL);
 }
 
 static inline void
@@ -1500,11 +1480,6 @@ free_adbfetch(dns_adb_t *adb, dns_adbfetch_t **fetch) {
 
 	f->magic = 0;
 
-	if (f->namehook != NULL)
-		free_adbnamehook(adb, &f->namehook);
-	if (f->entry != NULL)
-		free_adbentry(adb, &f->entry);
-
 	if (dns_rdataset_isassociated(&f->rdataset))
 		dns_rdataset_disassociate(&f->rdataset);
 
@@ -2953,8 +2928,8 @@ print_namehook_list(FILE *f, const char *legend, dns_adbnamehooklist_t *list,
 
 static inline void
 print_fetch(FILE *f, dns_adbfetch_t *ft, const char *type) {
-	fprintf(f, "\t\tFetch(%s): %p -> { nh %p, entry %p, fetch %p }\n",
-		type, ft, ft->namehook, ft->entry, ft->fetch);
+	fprintf(f, "\t\tFetch(%s): %p -> { fetch %p }\n",
+		type, ft, ft->fetch);
 }
 
 static void
diff --git a/lib/dns/cache.c b/lib/dns/cache.c
index c9b4a9588558..5de4225c8f25 100644
--- a/lib/dns/cache.c
+++ b/lib/dns/cache.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cache.c,v 1.57.18.18 2008/02/07 23:45:56 tbox Exp $ */
+/* $Id: cache.c,v 1.57.18.20 2009/01/19 23:46:14 tbox Exp $ */
 
 /*! \file */
 
@@ -60,7 +60,7 @@
  ***/
 
 /*
- * A cache_cleaner_t encapsulsates the state of the periodic
+ * A cache_cleaner_t encapsulates the state of the periodic
  * cache cleaning.
  */
 
@@ -1002,7 +1002,7 @@ dns_cache_setcachesize(dns_cache_t *cache, isc_uint32_t size) {
 	REQUIRE(VALID_CACHE(cache));
 
 	/*
-	 * Impose a minumum cache size; pathological things happen if there
+	 * Impose a minimum cache size; pathological things happen if there
 	 * is too little room.
 	 */
 	if (size != 0 && size < DNS_CACHE_MINSIZE)
diff --git a/lib/dns/db.c b/lib/dns/db.c
index 32ff6aebb7bd..e2391e88092b 100644
--- a/lib/dns/db.c
+++ b/lib/dns/db.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: db.c,v 1.74.18.6 2005/10/13 02:12:24 marka Exp $ */
+/* $Id: db.c,v 1.74.18.8 2009/04/29 23:46:04 tbox Exp $ */
 
 /*! \file */
 
@@ -95,7 +95,7 @@ static inline dns_dbimplementation_t *
 impfind(const char *name) {
 	dns_dbimplementation_t *imp;
 
-	for (imp = ISC_LIST_HEAD(implementations); 
+	for (imp = ISC_LIST_HEAD(implementations);
 	     imp != NULL;
 	     imp = ISC_LIST_NEXT(imp, link))
 		if (strcasecmp(name, imp->name) == 0)
@@ -687,7 +687,7 @@ dns_db_deleterdataset(dns_db_t *db, dns_dbnode_t *node,
 					      type, covers));
 }
 
-void 
+void
 dns_db_overmem(dns_db_t *db, isc_boolean_t overmem) {
 
 	REQUIRE(DNS_DB_VALID(db));
@@ -713,11 +713,11 @@ dns_db_getsoaserial(dns_db_t *db, dns_dbversion_t *ver, isc_uint32_t *serialp)
 	dns_rdataset_init(&rdataset);
 	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_soa, 0,
 				     (isc_stdtime_t)0, &rdataset, NULL);
- 	if (result != ISC_R_SUCCESS)
+	if (result != ISC_R_SUCCESS)
 		goto freenode;
 
 	result = dns_rdataset_first(&rdataset);
- 	if (result != ISC_R_SUCCESS)
+	if (result != ISC_R_SUCCESS)
 		goto freerdataset;
 	dns_rdataset_current(&rdataset, &rdata);
 	result = dns_rdataset_next(&rdataset);
@@ -770,7 +770,7 @@ dns_db_register(const char *name, dns_dbcreatefunc_t create, void *driverarg,
 		RWUNLOCK(&implock, isc_rwlocktype_write);
 		return (ISC_R_EXISTS);
 	}
-	
+
 	imp = isc_mem_get(mctx, sizeof(dns_dbimplementation_t));
 	if (imp == NULL) {
 		RWUNLOCK(&implock, isc_rwlocktype_write);
@@ -800,12 +800,14 @@ dns_db_unregister(dns_dbimplementation_t **dbimp) {
 	RUNTIME_CHECK(isc_once_do(&once, initialize) == ISC_R_SUCCESS);
 
 	imp = *dbimp;
+	*dbimp = NULL;
 	RWLOCK(&implock, isc_rwlocktype_write);
 	ISC_LIST_UNLINK(implementations, imp, link);
 	mctx = imp->mctx;
 	isc_mem_put(mctx, imp, sizeof(dns_dbimplementation_t));
 	isc_mem_detach(&mctx);
 	RWUNLOCK(&implock, isc_rwlocktype_write);
+	ENSURE(*dbimp == NULL);
 }
 
 isc_result_t
diff --git a/lib/dns/diff.c b/lib/dns/diff.c
index 22a3938790e2..60a1708ad8ad 100644
--- a/lib/dns/diff.c
+++ b/lib/dns/diff.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: diff.c,v 1.9.18.3 2005/04/27 05:01:15 sra Exp $ */
+/* $Id: diff.c,v 1.9.18.6 2009/01/06 23:45:56 tbox Exp $ */
 
 /*! \file */
 
@@ -269,7 +269,7 @@ diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver,
 						      sizeof(classbuf));
 				if (t->ttl != rdl.ttl && warn)
 					isc_log_write(DIFF_COMMON_LOGARGS,
-					      	ISC_LOG_WARNING,
+						ISC_LOG_WARNING,
 						"'%s/%s/%s': TTL differs in "
 						"rdataset, adjusting "
 						"%lu -> %lu",
@@ -306,7 +306,7 @@ diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver,
 				INSIST(0);
 			}
 			if (result == DNS_R_UNCHANGED) {
-			  	/*
+				/*
 				 * This will not happen when executing a
 				 * dynamic update, because that code will
 				 * generate strictly minimal diffs.
@@ -455,7 +455,7 @@ dns_diff_sort(dns_diff_t *diff, dns_diff_compare_func *compare) {
 
 /*
  * Create an rdataset containing the single RR of the given
- * tuple.  The caller must allocate the the rdata, rdataset and
+ * tuple.  The caller must allocate the rdata, rdataset and
  * an rdatalist structure for it to refer to.
  */
 
diff --git a/lib/dns/dispatch.c b/lib/dns/dispatch.c
index 794cdb5e5aac..b07b1dd90e94 100644
--- a/lib/dns/dispatch.c
+++ b/lib/dns/dispatch.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dispatch.c,v 1.116.18.37 2008/09/04 00:24:41 jinmei Exp $ */
+/* $Id: dispatch.c,v 1.116.18.42 2009/12/02 23:36:35 marka Exp $ */
 
 /*! \file */
 
@@ -1932,8 +1932,18 @@ dns_dispatchmgr_setudp(dns_dispatchmgr_t *mgr,
 
 	/* Create or adjust buffer pool */
 	if (mgr->bpool != NULL) {
-		isc_mempool_setmaxalloc(mgr->bpool, maxbuffers);
-		mgr->maxbuffers = maxbuffers;
+		/*
+		 * We only increase the maxbuffers to avoid accidental buffer
+		 * shortage.  Ideally we'd separate the manager-wide maximum
+		 * from per-dispatch limits and respect the latter within the
+		 * global limit.  But at this moment that's deemed to be
+		 * overkilling and isn't worth additional implementation
+		 * complexity.
+		 */
+		if (maxbuffers > mgr->maxbuffers) {
+			isc_mempool_setmaxalloc(mgr->bpool, maxbuffers);
+			mgr->maxbuffers = maxbuffers;
+		}
 	} else {
 		result = isc_mempool_create(mgr->mctx, buffersize, &mgr->bpool);
 		if (result != ISC_R_SUCCESS) {
@@ -2298,7 +2308,7 @@ dispatch_allocate(dns_dispatchmgr_t *mgr, unsigned int maxrequests,
 
 
 /*
- * MUST be unlocked, and not used by anthing.
+ * MUST be unlocked, and not used by anything.
  */
 static void
 dispatch_free(dns_dispatch_t **dispp)
@@ -2569,6 +2579,15 @@ get_udpsocket(dns_dispatchmgr_t *mgr, dns_dispatch_t *disp,
 		 * If this fails 1024 times, we then ask the kernel for
 		 * choosing one.
 		 */
+	} else {
+		/* Allow to reuse address for non-random ports. */
+		result = open_socket(sockmgr, localaddr,
+				     ISC_SOCKET_REUSEADDRESS, &sock);
+
+		if (result == ISC_R_SUCCESS)
+			*sockp = sock;
+
+		return (result);
 	}
 
 	memset(held, 0, sizeof(held));
diff --git a/lib/dns/dlz.c b/lib/dns/dlz.c
index ee6c03b08121..fa8996850ae1 100644
--- a/lib/dns/dlz.c
+++ b/lib/dns/dlz.c
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -50,7 +50,7 @@
  * USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dlz.c,v 1.2.2.2 2005/09/06 03:47:17 marka Exp $ */
+/* $Id: dlz.c,v 1.2.2.4 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file */
 
@@ -126,7 +126,7 @@ dns_dlzallowzonexfr(dns_view_t *view, dns_name_t *name,
 	dlzdatabase = view->dlzdatabase;
 	allowzonexfr = dlzdatabase->implementation->methods->allowzonexfr;
 	result = (*allowzonexfr)(dlzdatabase->implementation->driverarg,
-			         dlzdatabase->dbdata, dlzdatabase->mctx,
+				 dlzdatabase->dbdata, dlzdatabase->mctx,
 				 view->rdclass, name, clientaddr, dbp);
 
 	if (result == ISC_R_NOTIMPLEMENTED)
@@ -275,7 +275,7 @@ dns_dlzfindzone(dns_view_t *view, dns_name_t *name, unsigned int minlabels,
 	 * trying shorter names portions of the name until we find a
 	 * match, have an error, or are below the 'minlabels'
 	 * threshold.  minlabels is 0, if the standard database didn't
-	 * have a zone name match.  Otherwise minlables is the number
+	 * have a zone name match.  Otherwise minlabels is the number
 	 * of labels in that name.  We need to beat that for a
 	 * "better" match for the DLZ database to be authoritative
 	 * instead of the standard database.
diff --git a/lib/dns/dnssec.c b/lib/dns/dnssec.c
index 75ca44045359..0487907137d7 100644
--- a/lib/dns/dnssec.c
+++ b/lib/dns/dnssec.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -16,7 +16,7 @@
  */
 
 /*
- * $Id: dnssec.c,v 1.81.18.10 2007/09/14 04:35:42 marka Exp $
+ * $Id: dnssec.c,v 1.81.18.12 2008/11/20 23:46:03 tbox Exp $
  */
 
 /*! \file */
@@ -366,6 +366,9 @@ dns_dnssec_verify2(dns_name_t *name, dns_rdataset_t *set, dst_key_t *key,
 	if (ret != ISC_R_SUCCESS)
 		return (ret);
 
+	if (set->type != sig.covered)
+		return (DNS_R_SIGINVALID);
+
 	if (isc_serial_lt(sig.timeexpire, sig.timesigned))
 		return (DNS_R_SIGINVALID);
 
@@ -381,6 +384,27 @@ dns_dnssec_verify2(dns_name_t *name, dns_rdataset_t *set, dst_key_t *key,
 			return (DNS_R_SIGEXPIRED);
 	}
 
+	/*
+	 * NS, SOA and DNSSKEY records are signed by their owner.
+	 * DS records are signed by the parent.
+	 */
+	switch (set->type) {
+	case dns_rdatatype_ns:
+	case dns_rdatatype_soa:
+	case dns_rdatatype_dnskey:
+		if (!dns_name_equal(name, &sig.signer))
+			return (DNS_R_SIGINVALID);
+		break;
+	case dns_rdatatype_ds:
+		if (dns_name_equal(name, &sig.signer))
+			return (DNS_R_SIGINVALID);
+		/* FALLTHROUGH */
+	default:
+		if (!dns_name_issubdomain(name, &sig.signer))
+			return (DNS_R_SIGINVALID);
+		break;
+	}
+
 	/*
 	 * Is the key allowed to sign data?
 	 */
@@ -407,7 +431,7 @@ dns_dnssec_verify2(dns_name_t *name, dns_rdataset_t *set, dst_key_t *key,
 	dns_fixedname_init(&fnewname);
 	labels = dns_name_countlabels(name) - 1;
 	RUNTIME_CHECK(dns_name_downcase(name, dns_fixedname_name(&fnewname),
-				        NULL) == ISC_R_SUCCESS);
+					NULL) == ISC_R_SUCCESS);
 	if (labels - sig.labels > 0)
 		dns_name_split(dns_fixedname_name(&fnewname), sig.labels + 1,
 			       NULL, dns_fixedname_name(&fnewname));
@@ -487,9 +511,9 @@ cleanup_struct:
 	dns_rdata_freestruct(&sig);
 
 	if (ret == ISC_R_SUCCESS && labels - sig.labels > 0) {
-		if (wild != NULL) 
+		if (wild != NULL)
 			RUNTIME_CHECK(dns_name_concatenate(dns_wildcardname,
-					         dns_fixedname_name(&fnewname),
+						 dns_fixedname_name(&fnewname),
 						 wild, NULL) == ISC_R_SUCCESS);
 		ret = DNS_R_FROMWILDCARD;
 	}
@@ -541,6 +565,9 @@ dns_dnssec_findzonekeys2(dns_db_t *db, dns_dbversion_t *ver,
 		if (!is_zone_key(pubkey) ||
 		    (dst_key_flags(pubkey) & DNS_KEYTYPE_NOAUTH) != 0)
 			goto next;
+		/* Corrupted .key file? */
+		if (!dns_name_equal(name, dst_key_name(pubkey)))
+			goto next;
 		keys[count] = NULL;
 		result = dst_key_fromfile(dst_key_name(pubkey),
 					  dst_key_id(pubkey),
@@ -802,7 +829,7 @@ dns_dnssec_verifymessage(isc_buffer_t *source, dns_message_t *msg,
 	RETERR(dst_context_create(key, mctx, &ctx));
 
 	/*
- 	 * Digest the SIG(0) record, except for the signature.
+	 * Digest the SIG(0) record, except for the signature.
 	 */
 	dns_rdata_toregion(&rdata, &r);
 	r.length -= sig.siglen;
diff --git a/lib/dns/dst_api.c b/lib/dns/dst_api.c
index 7d98e10a7f3a..b8a23f6ec0a4 100644
--- a/lib/dns/dst_api.c
+++ b/lib/dns/dst_api.c
@@ -1,9 +1,9 @@
 /*
- * Portions Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2006, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2003  Internet Software Consortium.
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -18,7 +18,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: dst_api.c,v 1.1.6.7 2006/01/27 23:57:44 marka Exp $
+ * $Id: dst_api.c,v 1.1.6.15 2009/09/25 01:48:28 marka Exp $
  */
 
 /*! \file */
@@ -110,19 +110,21 @@ static isc_result_t	addsuffix(char *filename, unsigned int len,
 			return (_r);		\
 	} while (0);				\
 
+#ifdef OPENSSL
 static void *
 default_memalloc(void *arg, size_t size) {
-        UNUSED(arg);
-        if (size == 0U)
-                size = 1;
-        return (malloc(size));
+	UNUSED(arg);
+	if (size == 0U)
+		size = 1;
+	return (malloc(size));
 }
 
 static void
 default_memfree(void *arg, void *ptr) {
-        UNUSED(arg);
-        free(ptr);
+	UNUSED(arg);
+	free(ptr);
 }
+#endif
 
 isc_result_t
 dst_lib_init(isc_mem_t *mctx, isc_entropy_t *ectx, unsigned int eflags) {
@@ -925,6 +927,13 @@ dst_key_read_public(const char *filename, int type,
 	NEXTTOKEN(lex, opt, &token);
 	if (token.type != isc_tokentype_string)
 		BADTOKEN();
+
+	/*
+	 * We don't support "@" in .key files.
+	 */
+	if (!strcmp(DST_AS_STR(token), "@"))
+		BADTOKEN();
+
 	dns_fixedname_init(&name);
 	isc_buffer_init(&b, DST_AS_STR(token), strlen(DST_AS_STR(token)));
 	isc_buffer_add(&b, strlen(DST_AS_STR(token)));
@@ -936,6 +945,9 @@ dst_key_read_public(const char *filename, int type,
 	/* Read the next word: either TTL, class, or 'KEY' */
 	NEXTTOKEN(lex, opt, &token);
 
+	if (token.type != isc_tokentype_string)
+		BADTOKEN();
+
 	/* If it's a TTL, read the next one */
 	result = dns_ttl_fromtext(&token.value.as_textregion, &ttl);
 	if (result == ISC_R_SUCCESS)
@@ -1080,9 +1092,12 @@ write_public_key(const dst_key_t *key, int type, const char *directory) {
 	fwrite(r.base, 1, r.length, fp);
 
 	fputc('\n', fp);
+	fflush(fp);
+	if (ferror(fp))
+		ret = DST_R_WRITEERROR;
 	fclose(fp);
 
-	return (ISC_R_SUCCESS);
+	return (ret);
 }
 
 static isc_result_t
@@ -1208,6 +1223,8 @@ addsuffix(char *filename, unsigned int len, const char *ofilename,
 
 	n = snprintf(filename, len, "%.*s%s", olen, ofilename, suffix);
 	if (n < 0)
+		return (ISC_R_FAILURE);
+	if ((unsigned int)n >= len)
 		return (ISC_R_NOSPACE);
 	return (ISC_R_SUCCESS);
 }
diff --git a/lib/dns/dst_parse.c b/lib/dns/dst_parse.c
index ce361ef2d128..f3732cab3a0b 100644
--- a/lib/dns/dst_parse.c
+++ b/lib/dns/dst_parse.c
@@ -1,5 +1,5 @@
 /*
- * Portions Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2006, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2002  Internet Software Consortium.
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
@@ -18,7 +18,7 @@
 
 /*%
  * Principal Author: Brian Wellington
- * $Id: dst_parse.c,v 1.1.6.9 2008/01/22 23:27:05 tbox Exp $
+ * $Id: dst_parse.c,v 1.1.6.11 2009/03/02 23:45:58 tbox Exp $
  */
 
 #include 
@@ -486,8 +486,10 @@ dst__privstruct_writefile(const dst_key_t *key, const dst_private_t *priv,
 		fprintf(fp, "\n");
 	}
 
+	fflush(fp);
+	iret = ferror(fp) ? DST_R_WRITEERROR : ISC_R_SUCCESS;
 	fclose(fp);
-	return (ISC_R_SUCCESS);
+	return (iret);
 }
 
 /*! \file */
diff --git a/lib/dns/gen-unix.h b/lib/dns/gen-unix.h
index fc2dbf27920b..a5e95dcc9688 100644
--- a/lib/dns/gen-unix.h
+++ b/lib/dns/gen-unix.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: gen-unix.h,v 1.14.18.3 2005/06/08 02:07:54 marka Exp $ */
+/* $Id: gen-unix.h,v 1.14.18.5 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file
  * \brief
@@ -23,7 +23,7 @@
  * directly portable between Unix-like systems and Windows NT, option
  * parsing and directory scanning.  It is here because it was decided
  * that the "gen" build utility was not to depend on libisc.a, so
- * the functions delcared in isc/commandline.h and isc/dir.h could not
+ * the functions declared in isc/commandline.h and isc/dir.h could not
  * be used.
  *
  * The commandline stuff is really just a wrapper around getopt().
diff --git a/lib/dns/include/dns/Makefile.in b/lib/dns/include/dns/Makefile.in
index 3f367bc79204..cc9654b4ddcf 100644
--- a/lib/dns/include/dns/Makefile.in
+++ b/lib/dns/include/dns/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2003  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
 # copyright notice and this permission notice appear in all copies.
 #
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.50 2004/03/05 05:09:40 marka Exp $
+# $Id: Makefile.in,v 1.50.18.2 2008/11/20 23:46:03 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -23,14 +23,14 @@ top_srcdir =	@top_srcdir@
 
 HEADERS =	acl.h adb.h byaddr.h cache.h callbacks.h \
 		cert.h compress.h \
-		db.h dbiterator.h dbtable.h diff.h dispatch.h \
+		db.h dbiterator.h dbtable.h diff.h dispatch.h dlz.h \
 		dnssec.h ds.h events.h fixedname.h journal.h keyflags.h \
 		keytable.h keyvalues.h lib.h log.h master.h masterdump.h \
 		message.h name.h ncache.h \
 		nsec.h peer.h portlist.h rbt.h rcode.h \
 		rdata.h rdataclass.h rdatalist.h rdataset.h rdatasetiter.h \
 		rdataslab.h rdatatype.h request.h resolver.h result.h \
-		rootns.h sdb.h secalg.h secproto.h soa.h ssu.h \
+		rootns.h sdb.h sdlz.h secalg.h secproto.h soa.h ssu.h \
 		tcpmsg.h time.h tkey.h \
 		tsig.h ttl.h types.h validator.h version.h view.h xfrin.h \
 		zone.h zonekey.h zt.h
diff --git a/lib/dns/include/dns/acl.h b/lib/dns/include/dns/acl.h
index 34e394f36b0d..8268d30f0df6 100644
--- a/lib/dns/include/dns/acl.h
+++ b/lib/dns/include/dns/acl.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: acl.h,v 1.22.18.4 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: acl.h,v 1.22.18.6 2009/01/19 23:46:15 tbox Exp $ */
 
 #ifndef DNS_ACL_H
 #define DNS_ACL_H 1
@@ -139,7 +139,7 @@ dns_acl_isinsecure(const dns_acl_t *a);
 /*%<
  * Return #ISC_TRUE iff the acl 'a' is considered insecure, that is,
  * if it contains IP addresses other than those of the local host.
- * This is intended for applications such as printing warning 
+ * This is intended for applications such as printing warning
  * messages for suspect ACLs; it is not intended for making access
  * control decisions.  We make no guarantee that an ACL for which
  * this function returns #ISC_FALSE is safe.
@@ -189,12 +189,13 @@ isc_boolean_t
 dns_aclelement_match(const isc_netaddr_t *reqaddr,
 		     const dns_name_t *reqsigner,
 		     const dns_aclelement_t *e,
-		     const dns_aclenv_t *env,		     
+		     const dns_aclenv_t *env,
 		     const dns_aclelement_t **matchelt);
 /*%<
  * Like dns_acl_match, but matches against the single ACL element 'e'
  * rather than a complete list and returns ISC_TRUE iff it matched.
- * To determine whether the match was prositive or negative, the 
+ *
+ * To determine whether the match was positive or negative, the
  * caller should examine e->negative.  Since the element 'e' may be
  * a reference to a named ACL or a nested ACL, the matching element
  * returned through 'matchelt' is not necessarily 'e' itself.
diff --git a/lib/dns/include/dns/compress.h b/lib/dns/include/dns/compress.h
index 4d9c0119cc2c..a4580d3cc66b 100644
--- a/lib/dns/include/dns/compress.h
+++ b/lib/dns/include/dns/compress.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: compress.h,v 1.32.18.6 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: compress.h,v 1.32.18.8 2009/01/19 23:46:15 tbox Exp $ */
 
 #ifndef DNS_COMPRESS_H
 #define DNS_COMPRESS_H 1
@@ -77,7 +77,7 @@ struct dns_decompress {
 isc_result_t
 dns_compress_init(dns_compress_t *cctx, int edns, isc_mem_t *mctx);
 /*%<
- *	Inialise the compression context structure pointed to by 'cctx'.
+ *	Initialise the compression context structure pointed to by 'cctx'.
  *
  *	Requires:
  *	\li	'cctx' is a valid dns_compress_t structure.
@@ -136,7 +136,7 @@ dns_compress_setsensitive(dns_compress_t *cctx, isc_boolean_t sensitive);
 isc_boolean_t
 dns_compress_getsensitive(dns_compress_t *cctx);
 /*
- *	Return whether case is to be preservered when compressing
+ *	Return whether case is to be preserved when compressing
  *	domain names.
  *
  *	Requires:
diff --git a/lib/dns/include/dns/db.h b/lib/dns/include/dns/db.h
index b03ae5748a2e..6086bff5f703 100644
--- a/lib/dns/include/dns/db.h
+++ b/lib/dns/include/dns/db.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: db.h,v 1.76.18.10 2007/08/28 07:20:05 tbox Exp $ */
+/* $Id: db.h,v 1.76.18.14 2009/01/19 00:36:28 marka Exp $ */
 
 #ifndef DNS_DB_H
 #define DNS_DB_H 1
@@ -153,7 +153,7 @@ typedef isc_result_t
 		      dns_dbtype_t type, dns_rdataclass_t rdclass,
 		      unsigned int argc, char *argv[], void *driverarg,
 		      dns_db_t **dbp);
-					
+
 #define DNS_DB_MAGIC		ISC_MAGIC('D','N','S','D')
 #define DNS_DB_VALID(db)	ISC_MAGIC_VALID(db, DNS_DB_MAGIC)
 
@@ -786,7 +786,7 @@ dns_db_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
  *						the negative caching proof.
  *
  *	\li	#DNS_R_EMPTYNAME			The name exists but there is
- *						no data at the name. 
+ *						no data at the name.
  *
  *	\li	#DNS_R_COVERINGNSEC		The returned data is a NSEC
  *						that potentially covers 'name'.
@@ -1005,7 +1005,7 @@ isc_result_t
 dns_db_allrdatasets(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 		    isc_stdtime_t now, dns_rdatasetiter_t **iteratorp);
 /*%<
- * Make '*iteratorp' an rdataset iteratator for all rdatasets at 'node' in
+ * Make '*iteratorp' an rdataset iterator for all rdatasets at 'node' in
  * version 'version' of 'db'.
  *
  * Notes:
@@ -1192,7 +1192,7 @@ dns_db_getsoaserial(dns_db_t *db, dns_dbversion_t *ver, isc_uint32_t *serialp);
 void
 dns_db_overmem(dns_db_t *db, isc_boolean_t overmem);
 /*%<
- * Enable / disable agressive cache cleaning.
+ * Enable / disable aggressive cache cleaning.
  */
 
 unsigned int
@@ -1262,7 +1262,7 @@ dns_db_register(const char *name, dns_dbcreatefunc_t create, void *driverarg,
 void
 dns_db_unregister(dns_dbimplementation_t **dbimp);
 /*%<
- * Remove a database implementation from the the list of supported
+ * Remove a database implementation from the list of supported
  * implementations.  No databases of this type can be active when this
  * is called.
  *
diff --git a/lib/dns/include/dns/diff.h b/lib/dns/include/dns/diff.h
index cd96a0b088b5..0bced9821139 100644
--- a/lib/dns/include/dns/diff.h
+++ b/lib/dns/include/dns/diff.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: diff.h,v 1.6.18.2 2005/04/29 00:16:12 marka Exp $ */
+/* $Id: diff.h,v 1.6.18.4 2009/01/19 23:46:15 tbox Exp $ */
 
 #ifndef DNS_DIFF_H
 #define DNS_DIFF_H 1
@@ -73,7 +73,7 @@ typedef struct dns_difftuple dns_difftuple_t;
 #define DNS_DIFFTUPLE_VALID(t)	ISC_MAGIC_VALID(t, DNS_DIFFTUPLE_MAGIC)
 
 struct dns_difftuple {
-        unsigned int			magic;
+	unsigned int			magic;
 	isc_mem_t			*mctx;
 	dns_diffop_t			op;
 	dns_name_t			name;
@@ -99,7 +99,7 @@ struct dns_diff {
 	ISC_LIST(dns_difftuple_t)	tuples;
 };
 
-/* Type of comparision function for sorting diffs. */
+/* Type of comparison function for sorting diffs. */
 typedef int dns_diff_compare_func(const void *, const void *);
 
 /***
@@ -110,7 +110,7 @@ ISC_LANG_BEGINDECLS
 
 /**************************************************************************/
 /*
- * Maniuplation of diffs and tuples.
+ * Manipulation of diffs and tuples.
  */
 
 isc_result_t
diff --git a/lib/dns/include/dns/dlz.h b/lib/dns/include/dns/dlz.h
index 4c61c91cf296..6cb82611cdcd 100644
--- a/lib/dns/include/dns/dlz.h
+++ b/lib/dns/include/dns/dlz.h
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -50,7 +50,7 @@
  * USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dlz.h,v 1.2.2.2 2005/09/06 03:47:18 marka Exp $ */
+/* $Id: dlz.h,v 1.2.2.4 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file */
 
@@ -133,7 +133,7 @@ typedef void
 /*%<
  * Method prototype.  Drivers implementing the DLZ interface MUST
  * supply a destroy method.  This method is called when the DNS server
- * is shuting down and no longer needs the driver.
+ * is shutting down and no longer needs the driver.
  */
 
 typedef isc_result_t
@@ -157,7 +157,7 @@ typedef isc_result_t
  * \li	3) we run out of domain name labels. I.E. we have tried the
  *	   shortest domain name
  * \li	4) the number of labels in the domain name is less than
- *	   min_lables for dns_dlzfindzone
+ *	   min_labels for dns_dlzfindzone
  *
  * The driver's find zone method should return ISC_R_SUCCESS and a
  * database pointer to the name server if the zone is supported by the
@@ -202,7 +202,7 @@ dns_dlzallowzonexfr(dns_view_t *view, dns_name_t *name,
 
 /*%<
  * This method is called when the DNS server is performing a zone
- * transfer query.  It will call the DLZ driver's allow zone tranfer
+ * transfer query.  It will call the DLZ driver's allow zone transfer
  * method.
  */
 
@@ -223,7 +223,7 @@ void
 dns_dlzdestroy(dns_dlzdb_t **dbp);
 
 /*%<
- * This method is called when the DNS server is shuting down and no
+ * This method is called when the DNS server is shutting down and no
  * longer needs the driver.  If the DLZ driver supplies a destroy
  * methods, this function will call it.
  */
diff --git a/lib/dns/include/dns/journal.h b/lib/dns/include/dns/journal.h
index b776a30a58f9..2f62ba271a8f 100644
--- a/lib/dns/include/dns/journal.h
+++ b/lib/dns/include/dns/journal.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: journal.h,v 1.25.18.2 2005/04/29 00:16:13 marka Exp $ */
+/* $Id: journal.h,v 1.25.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_JOURNAL_H
 #define DNS_JOURNAL_H 1
@@ -26,7 +26,7 @@
 
 /*! \file
  * \brief
- * Database journalling.
+ * Database journaling.
  */
 
 /***
@@ -188,7 +188,7 @@ dns_journal_iter_init(dns_journal_t *j,
  * Returns:
  *\li	ISC_R_SUCCESS
  *\li	ISC_R_RANGE	begin_serial is outside the addressable range.
- *\li	ISC_R_NOTFOUND	begin_serial is within the range of adressable
+ *\li	ISC_R_NOTFOUND	begin_serial is within the range of addressable
  *			serial numbers covered by the journal, but
  *			this particular serial number does not exist.
  */
@@ -264,7 +264,7 @@ dns_db_diff(isc_mem_t *mctx,
 
 isc_result_t
 dns_journal_compact(isc_mem_t *mctx, char *filename, isc_uint32_t serial,
-                    isc_uint32_t target_size);
+		    isc_uint32_t target_size);
 /*%<
  * Attempt to compact the journal if it is greater that 'target_size'.
  * Changes from 'serial' onwards will be preserved.  If the journal
diff --git a/lib/dns/include/dns/log.h b/lib/dns/include/dns/log.h
index 7bee1745a642..5f93e0c230c5 100644
--- a/lib/dns/include/dns/log.h
+++ b/lib/dns/include/dns/log.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.h,v 1.33.18.4 2005/09/05 00:18:27 marka Exp $ */
+/* $Id: log.h,v 1.33.18.6 2009/01/19 23:46:16 tbox Exp $ */
 
 /*! \file
  * \author  Principal Authors: DCL */
@@ -87,7 +87,7 @@ dns_log_init(isc_log_t *lctx);
  *\li	dns_log_init() is called only once.
  *
  * Ensures:
- * \li	The catgories and modules defined above are available for
+ * \li	The categories and modules defined above are available for
  * 	use by isc_log_usechannnel() and isc_log_write().
  */
 
diff --git a/lib/dns/include/dns/lookup.h b/lib/dns/include/dns/lookup.h
index aea6f844e1be..8a2f1c47c5d4 100644
--- a/lib/dns/include/dns/lookup.h
+++ b/lib/dns/include/dns/lookup.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lookup.h,v 1.6.18.2 2005/04/29 00:16:15 marka Exp $ */
+/* $Id: lookup.h,v 1.6.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_LOOKUP_H
 #define DNS_LOOKUP_H 1
@@ -27,8 +27,8 @@
 /*! \file
  * \brief
  * The lookup module performs simple DNS lookups.  It implements
- * the full resolver algorithm, both looking for local data and 
- * resoving external names as necessary.
+ * the full resolver algorithm, both looking for local data and
+ * resolving external names as necessary.
  *
  * MP:
  *\li	The module ensures appropriate synchronization of data structures it
diff --git a/lib/dns/include/dns/message.h b/lib/dns/include/dns/message.h
index 9002b83f710b..29feecfc21bb 100644
--- a/lib/dns/include/dns/message.h
+++ b/lib/dns/include/dns/message.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: message.h,v 1.114.18.6 2006/03/02 23:19:20 marka Exp $ */
+/* $Id: message.h,v 1.114.18.8 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_MESSAGE_H
 #define DNS_MESSAGE_H 1
@@ -33,7 +33,7 @@
 
 #include 
 
-/*! \file 
+/*! \file
  * \brief Message Handling Module
  *
  * How this beast works:
@@ -157,7 +157,7 @@ typedef int dns_messagetextflag_t;
 						   occurs */
 #define DNS_MESSAGEPARSE_CLONEBUFFER	0x0004	/*%< save a copy of the
 						   source buffer */
-#define DNS_MESSAGEPARSE_IGNORETRUNCATION 0x0008 /*%< trucation errors are
+#define DNS_MESSAGEPARSE_IGNORETRUNCATION 0x0008 /*%< truncation errors are
 						  * not fatal. */
 
 /*
@@ -771,7 +771,7 @@ dns_message_addname(dns_message_t *msg, dns_name_t *name,
 
 void
 dns_message_removename(dns_message_t *msg, dns_name_t *name,
-                       dns_section_t section);
+		       dns_section_t section);
 /*%<
  * Remove a existing name from a given section.
  *
@@ -1031,7 +1031,7 @@ dns_message_setopt(dns_message_t *msg, dns_rdataset_t *opt);
  *\li	The OPT record has either been freed or ownership of it has
  *	been transferred to the message.
  *
- *\li	If ISC_R_SUCCESS was returned, the OPT record will be rendered 
+ *\li	If ISC_R_SUCCESS was returned, the OPT record will be rendered
  *	when dns_message_renderend() is called.
  *
  * Returns:
@@ -1195,7 +1195,7 @@ dns_message_takebuffer(dns_message_t *msg, isc_buffer_t **buffer);
  *\li	msg be a valid message.
  *
  *\li	buffer != NULL && *buffer is a valid isc_buffer_t, which was
- *	dynamincally allocated via isc_buffer_allocate().
+ *	dynamically allocated via isc_buffer_allocate().
  */
 
 isc_result_t
@@ -1315,7 +1315,7 @@ dns_message_setsortorder(dns_message_t *msg, dns_rdatasetorderfunc_t order,
  *\li	order_arg is NULL if and only if order is NULL.
  */
 
-void 
+void
 dns_message_settimeadjust(dns_message_t *msg, int timeadjust);
 /*%<
  * Adjust the time used to sign/verify a message by timeadjust.
@@ -1325,7 +1325,7 @@ dns_message_settimeadjust(dns_message_t *msg, int timeadjust);
  *\li	msg be a valid message.
  */
 
-int 
+int
 dns_message_gettimeadjust(dns_message_t *msg);
 /*%<
  * Return the current time adjustment.
diff --git a/lib/dns/include/dns/name.h b/lib/dns/include/dns/name.h
index 038ae05e6ab5..f53852ceaf6c 100644
--- a/lib/dns/include/dns/name.h
+++ b/lib/dns/include/dns/name.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: name.h,v 1.107.18.15 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: name.h,v 1.107.18.17 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_NAME_H
 #define DNS_NAME_H 1
@@ -242,7 +242,7 @@ dns_name_setbuffer(dns_name_t *name, isc_buffer_t *buffer);
  *
  * Notes:
  * \li	Specification of a target buffer in dns_name_fromwire(),
- *	dns_name_fromtext(), and dns_name_concatentate() is optional if
+ *	dns_name_fromtext(), and dns_name_concatenate() is optional if
  *	'name' has a dedicated buffer.
  *
  * \li	The caller must not write to buffer until the name has been
@@ -721,7 +721,7 @@ dns_name_fromwire(dns_name_t *name, isc_buffer_t *source,
 
 isc_result_t
 dns_name_towire(const dns_name_t *name, dns_compress_t *cctx,
-	        isc_buffer_t *target);
+		isc_buffer_t *target);
 /*%<
  * Convert 'name' into wire format, compressing it as specified by the
  * compression context 'cctx', and storing the result in 'target'.
@@ -840,7 +840,7 @@ dns_name_totext(dns_name_t *name, isc_boolean_t omit_final_dot,
  * name as generated by dns_name_totext().  This does not
  * include space for a terminating NULL.
  *
- * This definition is conservative - the actual maximum 
+ * This definition is conservative - the actual maximum
  * is 1004, derived as follows:
  *
  *   A backslash-decimal escaped character takes 4 bytes.
@@ -952,7 +952,7 @@ dns_name_split(dns_name_t *name, unsigned int suffixlabels,
  *
  * Notes:
  * \li     'name' is split such that 'suffix' holds the most significant
- *      'suffixlabels' labels.  All other labels are stored in 'prefix'. 
+ *      'suffixlabels' labels.  All other labels are stored in 'prefix'.
  *
  *\li	Copying name data is avoided as much as possible, so 'prefix'
  *	and 'suffix' will end up pointing at the data for 'name'.
@@ -1082,7 +1082,7 @@ dns_name_dynamic(dns_name_t *name);
  *
  * Returns:
  *
- *\li	'ISC_TRUE' if the name is dynamic othewise 'ISC_FALSE'.
+ *\li	'ISC_TRUE' if the name is dynamic otherwise 'ISC_FALSE'.
  */
 
 isc_result_t
@@ -1185,7 +1185,7 @@ dns_name_ishostname(const dns_name_t *name, isc_boolean_t wildcard);
  * Requires:
  *	'name' to be valid.
  */
- 
+
 
 isc_boolean_t
 dns_name_ismailbox(const dns_name_t *name);
@@ -1220,7 +1220,7 @@ dns_name_destroy(void);
 ISC_LANG_ENDDECLS
 
 /*
- *** High Peformance Macros
+ *** High Performance Macros
  ***/
 
 /*
diff --git a/lib/dns/include/dns/peer.h b/lib/dns/include/dns/peer.h
index be5a8c3a2230..2c5619fcc990 100644
--- a/lib/dns/include/dns/peer.h
+++ b/lib/dns/include/dns/peer.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: peer.h,v 1.20.18.8 2006/02/28 03:10:48 marka Exp $ */
+/* $Id: peer.h,v 1.20.18.10 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_PEER_H
 #define DNS_PEER_H 1
@@ -75,9 +75,9 @@ struct dns_peer {
 	isc_boolean_t		support_edns;
 	dns_name_t	       *key;
 	isc_sockaddr_t	       *transfer_source;
-	isc_sockaddr_t	       *notify_source;  
-	isc_sockaddr_t	       *query_source;  
-	isc_uint16_t		udpsize;		/* recieve size */
+	isc_sockaddr_t	       *notify_source;
+	isc_sockaddr_t	       *query_source;
+	isc_uint16_t		udpsize;		/* receive size */
 	isc_uint16_t		maxudp;			/* transmit size */
 
 	isc_uint32_t		bitflags;
diff --git a/lib/dns/include/dns/rbt.h b/lib/dns/include/dns/rbt.h
index a1edf0c7912d..e891660b1f1a 100644
--- a/lib/dns/include/dns/rbt.h
+++ b/lib/dns/include/dns/rbt.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbt.h,v 1.59.18.5 2005/10/13 01:26:07 marka Exp $ */
+/* $Id: rbt.h,v 1.59.18.7 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_RBT_H
 #define DNS_RBT_H 1
@@ -84,7 +84,7 @@ typedef struct dns_rbtnode {
 	/*!
 	 * The following bitfields add up to a total bitwidth of 32.
 	 * The range of values necessary for each item is indicated,
-	 * but in the case of "attributes" the field is wider to accomodate
+	 * but in the case of "attributes" the field is wider to accommodate
 	 * possible future expansion.  "offsetlen" could be one bit
 	 * narrower by always adjusting its value by 1 to find the real
 	 * offsetlen, but doing so does not gain anything (except perhaps
@@ -145,7 +145,7 @@ typedef isc_result_t (*dns_rbtfindcallback_t)(dns_rbtnode_t *node,
  * tree when a node is added).  The obvious implication of this is that for a
  * chain to remain valid, the tree has to be locked down against writes for the
  * duration of the useful life of the chain, because additions or removals can
- * change the path from the root to the node the chain has targetted.
+ * change the path from the root to the node the chain has targeted.
  *
  * The dns_rbtnodechain_ functions _first, _last, _prev and _next all take
  * dns_name_t parameters for the name and the origin, which can be NULL.  If
@@ -397,7 +397,7 @@ dns_rbt_findnode(dns_rbt_t *rbt, dns_name_t *name, dns_name_t *foundname,
  *\li	The 'level_count' of the chain indicates how deep the chain to the
  *	predecessor name is, as an index into the 'levels[]' array.  It does
  *	not count name elements, per se, but only levels of the tree of trees,
- *	the distinction arrising because multiple labels from a name can be
+ *      the distinction arising because multiple labels from a name can be
  *	stored on only one level.  It is also does not include the level
  *	that has the node, since that level is not stored in levels[].
  *
@@ -425,7 +425,7 @@ dns_rbt_findnode(dns_rbt_t *rbt, dns_name_t *name, dns_name_t *foundname,
  *\li	rbt is a valid rbt manager.
  *\li	dns_name_isabsolute(name) == TRUE.
  *\li	node != NULL && *node == NULL.
- *\li	#DNS_RBTFIND_NOEXACT and DNS_RBTFIND_NOPREDECESSOR are mutally
+ *\li   #DNS_RBTFIND_NOEXACT and DNS_RBTFIND_NOPREDECESSOR are mutually
  *		exclusive.
  *
  * Ensures:
@@ -534,7 +534,7 @@ dns_rbt_deletenode(dns_rbt_t *rbt, dns_rbtnode_t *node, isc_boolean_t recurse);
  *		'node' does not appear in the tree with data; however,
  *		the node might still exist if it serves as a pointer to
  *		a lower tree level as long as 'recurse' was false, hence
- *		the node could can be found with dns_rbt_findnode whem
+ *              the node could can be found with dns_rbt_findnode when
  *		that function's empty_data_ok parameter is true.
  *
  *\li	If result is ISC_R_NOMEMORY or ISC_R_NOSPACE:
@@ -624,14 +624,14 @@ dns_rbt_destroy(dns_rbt_t **rbtp);
 isc_result_t
 dns_rbt_destroy2(dns_rbt_t **rbtp, unsigned int quantum);
 /*%<
- * Stop working with a red-black tree of trees. 
+ * Stop working with a red-black tree of trees.
  * If 'quantum' is zero then the entire tree will be destroyed.
  * If 'quantum' is non zero then up to 'quantum' nodes will be destroyed
  * allowing the rbt to be incrementally destroyed by repeated calls to
  * dns_rbt_destroy2().  Once dns_rbt_destroy2() has been called no other
  * operations than dns_rbt_destroy()/dns_rbt_destroy2() should be
  * performed on the tree of trees.
- * 
+ *
  * Requires:
  * \li	*rbt is a valid rbt manager.
  *
@@ -864,26 +864,26 @@ dns_rbtnodechain_next(dns_rbtnodechain_t *chain, dns_name_t *name,
 #ifdef DNS_RBT_USEISCREFCOUNT
 #define dns_rbtnode_refinit(node, n)				\
 	do {							\
- 		isc_refcount_init(&(node)->references, (n));	\
-	} while (0) 
+		isc_refcount_init(&(node)->references, (n));	\
+	} while (0)
 #define dns_rbtnode_refdestroy(node)				\
 	do {							\
 		isc_refcount_destroy(&(node)->references);	\
-	} while (0) 
+	} while (0)
 #define dns_rbtnode_refcurrent(node)				\
 	isc_refcount_current(&(node)->references)
 #define dns_rbtnode_refincrement0(node, refs)			\
 	do {							\
 		isc_refcount_increment0(&(node)->references, (refs)); \
-	} while (0) 
+	} while (0)
 #define dns_rbtnode_refincrement(node, refs)			\
 	do {							\
 		isc_refcount_increment(&(node)->references, (refs)); \
-	} while (0) 
+	} while (0)
 #define dns_rbtnode_refdecrement(node, refs)			\
 	do {							\
 		isc_refcount_decrement(&(node)->references, (refs)); \
-	} while (0) 
+	} while (0)
 #else  /* DNS_RBT_USEISCREFCOUNT */
 #define dns_rbtnode_refinit(node, n)	((node)->references = (n))
 #define dns_rbtnode_refdestroy(node)	(REQUIRE((node)->references == 0))
@@ -894,21 +894,21 @@ dns_rbtnodechain_next(dns_rbtnodechain_t *chain, dns_name_t *name,
 		(node)->references++;				\
 		if ((_tmp) != NULL)				\
 			(*_tmp) = (node)->references;		\
-	} while (0) 
+	} while (0)
 #define dns_rbtnode_refincrement(node, refs)			\
 	do {							\
 		REQUIRE((node)->references > 0);		\
 		(node)->references++;				\
 		if ((refs) != NULL)				\
 			(*refs) = (node)->references;		\
-	} while (0) 
+	} while (0)
 #define dns_rbtnode_refdecrement(node, refs)			\
 	do {							\
 		REQUIRE((node)->references > 0);		\
 		(node)->references--;				\
 		if ((refs) != NULL)				\
 			(*refs) = (node)->references;		\
-	} while (0) 
+	} while (0)
 #endif /* DNS_RBT_USEISCREFCOUNT */
 
 ISC_LANG_ENDDECLS
diff --git a/lib/dns/include/dns/rdata.h b/lib/dns/include/dns/rdata.h
index a14bde788815..15d0ba4498ab 100644
--- a/lib/dns/include/dns/rdata.h
+++ b/lib/dns/include/dns/rdata.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdata.h,v 1.60.18.3 2005/05/19 04:59:56 marka Exp $ */
+/* $Id: rdata.h,v 1.60.18.7 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_RDATA_H
 #define DNS_RDATA_H 1
@@ -49,7 +49,7 @@
  *	build process from a set of source files, one per rdata type.  For
  *	portability, it's probably best that the building be done by a C
  *	program.  Adding a new rdata type will be a simple matter of adding
- *	a file to a directory and rebuilding the server.  *All* knowlege of
+ *	a file to a directory and rebuilding the server.  *All* knowledge of
  *	the format of a particular rdata type is in this file.
  *
  * MP:
@@ -327,11 +327,11 @@ dns_rdata_fromtext(dns_rdata_t *rdata, dns_rdataclass_t rdclass,
  *\li	'target' is a valid region.
  *
  *\li	'origin' if non NULL it must be absolute.
- *	
+ *
  *\li	'callbacks' to be NULL or callbacks->warn and callbacks->error be
  *	initialized.
  *
- * Ensures, 
+ * Ensures,
  *	if result is success:
  *\li	 	If 'rdata' is not NULL, it is attached to the target.
 
@@ -384,7 +384,8 @@ dns_rdata_totext(dns_rdata_t *rdata, dns_name_t *origin, isc_buffer_t *target);
 
 isc_result_t
 dns_rdata_tofmttext(dns_rdata_t *rdata, dns_name_t *origin, unsigned int flags,
-		    unsigned int width, char *linebreak, isc_buffer_t *target);
+		    unsigned int width, const char *linebreak,
+		    isc_buffer_t *target);
 /*%<
  * Like dns_rdata_totext, but do formatted output suitable for
  * database dumps.  This is intended for use by dns_db_dump();
diff --git a/lib/dns/include/dns/rdataset.h b/lib/dns/include/dns/rdataset.h
index 559759120f79..2749f8a80eb9 100644
--- a/lib/dns/include/dns/rdataset.h
+++ b/lib/dns/include/dns/rdataset.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.h,v 1.51.18.7 2006/03/03 00:56:53 marka Exp $ */
+/* $Id: rdataset.h,v 1.51.18.9 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_RDATASET_H
 #define DNS_RDATASET_H 1
@@ -348,8 +348,8 @@ dns_rdataset_totext(dns_rdataset_t *rdataset,
  * Notes:
  *\li	The rdata cursor position will be changed.
  *
- *\li	The 'question' flag should normally be #ISC_FALSE.  If it is 
- *	#ISC_TRUE, the TTL and rdata fields are not printed.  This is 
+ *\li	The 'question' flag should normally be #ISC_FALSE.  If it is
+ *	#ISC_TRUE, the TTL and rdata fields are not printed.  This is
  *	for use when printing an rdata representing a question section.
  *
  *\li	This interface is deprecated; use dns_master_rdatasettottext()
@@ -411,7 +411,7 @@ dns_rdataset_towiresorted(dns_rdataset_t *rdataset,
 			  unsigned int *countp);
 /*%<
  * Like dns_rdataset_towire(), but sorting the rdatasets according to
- * the integer value returned by 'order' when called witih the rdataset
+ * the integer value returned by 'order' when called with the rdataset
  * and 'order_arg' as arguments.
  *
  * Requires:
diff --git a/lib/dns/include/dns/request.h b/lib/dns/include/dns/request.h
index b858a9e52d06..a2a7528e9299 100644
--- a/lib/dns/include/dns/request.h
+++ b/lib/dns/include/dns/request.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: request.h,v 1.21.18.2 2005/04/29 00:16:20 marka Exp $ */
+/* $Id: request.h,v 1.21.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_REQUEST_H
 #define DNS_REQUEST_H 1
@@ -49,7 +49,7 @@
 #define DNS_REQUESTOPT_TCP 0x00000001U
 
 typedef struct dns_requestevent {
-        ISC_EVENT_COMMON(struct dns_requestevent);
+	ISC_EVENT_COMMON(struct dns_requestevent);
 	isc_result_t result;
 	dns_request_t *request;
 } dns_requestevent_t;
@@ -217,7 +217,7 @@ dns_request_createvia3(dns_requestmgr_t *requestmgr, dns_message_t *message,
 		       unsigned int udpretries, isc_task_t *task,
 		       isc_taskaction_t action, void *arg,
 		       dns_request_t **requestp);
-/*%< 
+/*%<
  * Create and send a request.
  *
  * Notes:
@@ -271,7 +271,7 @@ dns_request_createraw3(dns_requestmgr_t *requestmgr, isc_buffer_t *msgbuf,
 		       unsigned int udptimeout, unsigned int udpretries,
 		       isc_task_t *task, isc_taskaction_t action, void *arg,
 		       dns_request_t **requestp);
-/*!< 
+/*!<
  * \brief Create and send a request.
  *
  * Notes:
@@ -280,7 +280,7 @@ dns_request_createraw3(dns_requestmgr_t *requestmgr, isc_buffer_t *msgbuf,
  *	#DNS_REQUESTOPT_TCP option is set, TCP will be used.  The request
  *	will timeout after 'timeout' seconds.   UDP requests will be resent
  *	at 'udptimeout' intervals if non-zero or if 'udpretries' is not zero.
- *	
+ *
  *\li	When the request completes, successfully, due to a timeout, or
  *	because it was canceled, a completion event will be sent to 'task'.
  *
@@ -344,7 +344,7 @@ dns_request_usedtcp(dns_request_t *request);
 /*%<
  * Return whether this query used TCP or not.  Setting #DNS_REQUESTOPT_TCP
  * in the call to dns_request_create() will cause the function to return
- * #ISC_TRUE, othewise the result is based on the query message size.
+ * #ISC_TRUE, otherwise the result is based on the query message size.
  *
  * Requires:
  *\li	'request' is a valid request.
diff --git a/lib/dns/include/dns/resolver.h b/lib/dns/include/dns/resolver.h
index 4e0e6a01b774..3fce33665c48 100644
--- a/lib/dns/include/dns/resolver.h
+++ b/lib/dns/include/dns/resolver.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.h,v 1.40.18.11 2006/02/01 22:39:17 marka Exp $ */
+/* $Id: resolver.h,v 1.40.18.13 2009/09/24 23:46:07 tbox Exp $ */
 
 #ifndef DNS_RESOLVER_H
 #define DNS_RESOLVER_H 1
@@ -93,7 +93,7 @@ typedef struct dns_fetchevent {
 #define DNS_FETCHOPT_FORWARDONLY	0x10	     /*%< Only use forwarders. */
 #define DNS_FETCHOPT_NOVALIDATE		0x20	     /*%< Disable validation. */
 #define DNS_FETCHOPT_EDNS512		0x40	     /*%< Advertise a 512 byte
-						          UDP buffer. */
+							  UDP buffer. */
 
 #define	DNS_FETCHOPT_EDNSVERSIONSET	0x00800000
 #define	DNS_FETCHOPT_EDNSVERSIONMASK	0xff000000
@@ -348,6 +348,23 @@ dns_resolver_destroyfetch(dns_fetch_t **fetchp);
  *\li	*fetchp == NULL.
  */
 
+void
+dns_resolver_logfetch(dns_fetch_t *fetch, isc_log_t *lctx,
+		      isc_logcategory_t *category, isc_logmodule_t *module,
+		      int level, isc_boolean_t duplicateok);
+/*%<
+ * Dump a log message on internal state at the completion of given 'fetch'.
+ * 'lctx', 'category', 'module', and 'level' are used to write the log message.
+ * By default, only one log message is written even if the corresponding fetch
+ * context serves multiple clients; if 'duplicateok' is true the suppression
+ * is disabled and the message can be written every time this function is
+ * called.
+ *
+ * Requires:
+ *
+ *\li	'fetch' is a valid fetch, and has completed.
+ */
+
 dns_dispatchmgr_t *
 dns_resolver_dispatchmgr(dns_resolver_t *resolver);
 
@@ -470,7 +487,7 @@ dns_resolver_getclientsperquery(dns_resolver_t *resolver, isc_uint32_t *cur,
 
 isc_boolean_t
 dns_resolver_getzeronosoattl(dns_resolver_t *resolver);
- 
+
 void
 dns_resolver_setzeronosoattl(dns_resolver_t *resolver, isc_boolean_t state);
 
diff --git a/lib/dns/include/dns/sdb.h b/lib/dns/include/dns/sdb.h
index de849f928dd3..35bf883a43db 100644
--- a/lib/dns/include/dns/sdb.h
+++ b/lib/dns/include/dns/sdb.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdb.h,v 1.15.18.2 2005/04/29 00:16:21 marka Exp $ */
+/* $Id: sdb.h,v 1.15.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_SDB_H
 #define DNS_SDB_H 1
@@ -127,12 +127,12 @@ dns_sdb_register(const char *drivername, const dns_sdbmethods_t *methods,
  * The allnodes function, if non-NULL, fills in an opaque structure to be
  * used by a database iterator.  This allows the zone to be transferred.
  * This may use a considerable amount of memory for large zones, and the
- * zone transfer may not be fully RFC1035 compliant if the zone is 
+ * zone transfer may not be fully RFC1035 compliant if the zone is
  * frequently changed.
  *
  * The create function will be called for each zone configured
  * into the name server using this database type.  It can be used
- * to create a "database object" containg zone specific data,
+ * to create a "database object" containing zone specific data,
  * which can make use of the database arguments specified in the
  * name server configuration.
  *
diff --git a/lib/dns/include/dns/sdlz.h b/lib/dns/include/dns/sdlz.h
index 13ba14a1297b..aa418a3846c4 100644
--- a/lib/dns/include/dns/sdlz.h
+++ b/lib/dns/include/dns/sdlz.h
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -50,7 +50,7 @@
  * USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdlz.h,v 1.2.2.2 2005/09/06 03:47:19 marka Exp $ */
+/* $Id: sdlz.h,v 1.2.2.4 2009/01/19 23:46:16 tbox Exp $ */
 
 /*! \file */
 
@@ -148,7 +148,7 @@ typedef void
 /*%<
  * Method prototype.  Drivers implementing the SDLZ interface may
  * supply a destroy method.  This method is called when the DNS server
- * is shuting down and no longer needs the driver.  A SDLZ driver does
+ * is shutting down and no longer needs the driver.  A SDLZ driver does
  * not have to implement a destroy method.
  */
 
@@ -173,7 +173,7 @@ typedef isc_result_t
  * \li	3) we run out of domain name labels. I.E. we have tried the
  *	   shortest domain name
  *
- * \li	4) the number of labels in the domain name is less than min_lables
+ * \li	4) the number of labels in the domain name is less than min_labels
  *	   for dns_dlzfindzone
  *
  * The driver's find zone method should return ISC_R_SUCCESS if the
diff --git a/lib/dns/include/dns/tkey.h b/lib/dns/include/dns/tkey.h
index 4e3e80a0f570..a82fe50bcdcb 100644
--- a/lib/dns/include/dns/tkey.h
+++ b/lib/dns/include/dns/tkey.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tkey.h,v 1.19.18.2 2005/04/29 00:16:23 marka Exp $ */
+/* $Id: tkey.h,v 1.19.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_TKEY_H
 #define DNS_TKEY_H 1
@@ -144,7 +144,7 @@ dns_tkey_builddeletequery(dns_message_t *msg, dns_tsigkey_t *key);
 
 isc_result_t
 dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg,
-                           dst_key_t *key, isc_buffer_t *nonce,
+			   dst_key_t *key, isc_buffer_t *nonce,
 			   dns_tsigkey_t **outkey, dns_tsig_keyring_t *ring);
 /*%<
  *	Processes a response to a query containing a TKEY that was
diff --git a/lib/dns/include/dns/types.h b/lib/dns/include/dns/types.h
index fb061a3f46aa..94c2d86f8233 100644
--- a/lib/dns/include/dns/types.h
+++ b/lib/dns/include/dns/types.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: types.h,v 1.109.18.12.68.1 2009/11/19 00:25:18 marka Exp $ */
+/* $Id: types.h,v 1.109.18.15 2009/11/25 04:50:25 marka Exp $ */
 
 #ifndef DNS_TYPES_H
 #define DNS_TYPES_H 1
@@ -247,23 +247,23 @@ enum {
 	 */
 	dns_trust_pending_additional = 1,
 #define dns_trust_pending_additional \
-		((dns_trust_t)dns_trust_pending_additional)
- 
+		 ((dns_trust_t)dns_trust_pending_additional)
+
 	dns_trust_pending_answer = 2,
 #define dns_trust_pending_answer	((dns_trust_t)dns_trust_pending_answer)
- 
+
 	/*% Received in the additional section of a response. */
 	dns_trust_additional = 3,
 #define dns_trust_additional		((dns_trust_t)dns_trust_additional)
- 
+
 	/* Received in a referral response. */
 	dns_trust_glue = 4,
 #define dns_trust_glue			((dns_trust_t)dns_trust_glue)
- 
+
 	/* Answer from a non-authoritative server */
 	dns_trust_answer = 5,
 #define dns_trust_answer		((dns_trust_t)dns_trust_answer)
- 
+
 	/*  Received in the authority section as part of an
 	    authoritative response */
 	dns_trust_authauthority = 6,
@@ -272,7 +272,7 @@ enum {
 	/* Answer from an authoritative server */
 	dns_trust_authanswer = 7,
 #define dns_trust_authanswer		((dns_trust_t)dns_trust_authanswer)
- 
+
 	/* Successfully DNSSEC validated */
 	dns_trust_secure = 8,
 #define dns_trust_secure		((dns_trust_t)dns_trust_secure)
@@ -285,10 +285,10 @@ enum {
 #define DNS_TRUST_PENDING(x)		((x) == dns_trust_pending_answer || \
 					 (x) == dns_trust_pending_additional)
 #define DNS_TRUST_GLUE(x)		((x) == dns_trust_glue)
- 
- 
+
+
 /*%
- * Name checking severites.
+ * Name checking severities.
  */
 typedef enum {
 	dns_severity_ignore,
@@ -320,7 +320,7 @@ typedef void
 typedef void
 (*dns_updatecallback_t)(void *, isc_result_t, dns_message_t *);
 
-typedef int 
+typedef int
 (*dns_rdatasetorderfunc_t)(const dns_rdata_t *, const void *);
 
 typedef isc_boolean_t
diff --git a/lib/dns/include/dns/validator.h b/lib/dns/include/dns/validator.h
index c94fc3af5ee9..9708cc4ce7eb 100644
--- a/lib/dns/include/dns/validator.h
+++ b/lib/dns/include/dns/validator.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.h,v 1.27.18.10 2007/09/26 04:39:45 each Exp $ */
+/* $Id: validator.h,v 1.27.18.13 2009/01/19 00:36:28 marka Exp $ */
 
 #ifndef DNS_VALIDATOR_H
 #define DNS_VALIDATOR_H 1
@@ -74,7 +74,7 @@
  * caller so that they may be freed.
  *
  * If the RESULT is ISC_R_SUCCESS and the answer is secure then
- * proofs[] will contain the the names of the NSEC records that hold the
+ * proofs[] will contain the names of the NSEC records that hold the
  * various proofs.  Note the same name may appear multiple times.
  */
 typedef struct dns_validatorevent {
@@ -202,7 +202,7 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
  * options:
  * If DNS_VALIDATOR_DLV is set the caller knows there is not a
  * trusted key and the validator should immediately attempt to validate
- * the answer by looking for a appopriate DLV RRset.
+ * the answer by looking for an appropriate DLV RRset.
  */
 
 void
diff --git a/lib/dns/include/dns/view.h b/lib/dns/include/dns/view.h
index ea3d4c773e4d..f6099de3f945 100644
--- a/lib/dns/include/dns/view.h
+++ b/lib/dns/include/dns/view.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: view.h,v 1.91.18.9 2006/03/09 23:38:21 marka Exp $ */
+/* $Id: view.h,v 1.91.18.13 2009/01/19 00:36:28 marka Exp $ */
 
 #ifndef DNS_VIEW_H
 #define DNS_VIEW_H 1
@@ -224,7 +224,7 @@ void
 dns_view_flushanddetach(dns_view_t **viewp);
 /*%<
  * Detach '*viewp' from its view.  If this was the last reference
- * uncommited changed in zones will be flushed to disk.
+ * uncommitted changed in zones will be flushed to disk.
  *
  * Requires:
  *
@@ -363,7 +363,7 @@ dns_view_setdstport(dns_view_t *view, in_port_t dstport);
  *\li      'dstport' is a valid TCP/UDP port number.
  *
  * Ensures:
- *\li	External name servers will be assumed to be listning
+ *\li	External name servers will be assumed to be listening
  *	on 'dstport'.  For servers whose address has already
  *	obtained obtained at the time of the call, the view may
  *	continue to use the previously set port until the address
@@ -615,7 +615,7 @@ dns_view_loadnew(dns_view_t *view, isc_boolean_t stop);
 /*%<
  * Load zones attached to this view.  dns_view_load() loads
  * all zones whose master file has changed since the last
- * load; dns_view_loadnew() loads only zones that have never 
+ * load; dns_view_loadnew() loads only zones that have never
  * been loaded.
  *
  * If 'stop' is ISC_TRUE, stop on the first error and return it.
@@ -633,7 +633,7 @@ dns_view_gettsig(dns_view_t *view, dns_name_t *keyname,
  * Find the TSIG key configured in 'view' with name 'keyname',
  * if any.
  *
- * Reqires:
+ * Requires:
  *\li	keyp points to a NULL dns_tsigkey_t *.
  *
  * Returns:
@@ -649,7 +649,7 @@ dns_view_getpeertsig(dns_view_t *view, isc_netaddr_t *peeraddr,
  * Find the TSIG key configured in 'view' for the server whose
  * address is 'peeraddr', if any.
  *
- * Reqires:
+ * Requires:
  *	keyp points to a NULL dns_tsigkey_t *.
  *
  * Returns:
@@ -691,7 +691,7 @@ dns_view_dumpdbtostream(dns_view_t *view, FILE *fp);
  * easily obtainable by other means.
  *
  * Requires:
- * 	
+ *
  *\li	'view' is valid.
  *
  *\li	'fp' refers to a file open for writing.
@@ -734,7 +734,7 @@ isc_result_t
 dns_view_adddelegationonly(dns_view_t *view, dns_name_t *name);
 /*%<
  * Add the given name to the delegation only table.
- * 
+ *
  *
  * Requires:
  *\li	'view' is valid.
@@ -749,7 +749,7 @@ isc_result_t
 dns_view_excludedelegationonly(dns_view_t *view, dns_name_t *name);
 /*%<
  * Add the given name to be excluded from the root-delegation-only.
- * 
+ *
  *
  * Requires:
  *\li	'view' is valid.
@@ -771,8 +771,8 @@ dns_view_isdelegationonly(dns_view_t *view, dns_name_t *name);
  *\li	'name' is valid.
  *
  * Returns:
- *\li	#ISC_TRUE if the name is is the table.
- *\li	#ISC_FALSE othewise.
+ *\li	#ISC_TRUE if the name is the table.
+ *\li	#ISC_FALSE otherwise.
  */
 
 void
diff --git a/lib/dns/include/dns/xfrin.h b/lib/dns/include/dns/xfrin.h
index fcd482e2719c..7abf684e2517 100644
--- a/lib/dns/include/dns/xfrin.h
+++ b/lib/dns/include/dns/xfrin.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: xfrin.h,v 1.20.18.5 2006/07/20 01:10:30 marka Exp $ */
+/* $Id: xfrin.h,v 1.20.18.7 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef DNS_XFRIN_H
 #define DNS_XFRIN_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file 
+/*! \file
  * \brief
  * Incoming zone transfers (AXFR + IXFR).
  */
@@ -90,7 +90,7 @@ dns_xfrin_shutdown(dns_xfrin_ctx_t *xfr);
 /*%<
  * If the zone transfer 'xfr' has already finished,
  * do nothing.  Otherwise, abort it and cause it to call
- * its done callback with a status of ISC_R_CANCELLED.
+ * its done callback with a status of ISC_R_CANCELED.
  */
 
 void
diff --git a/lib/dns/include/dns/zone.h b/lib/dns/include/dns/zone.h
index 7cb827216b4d..96f5d1266862 100644
--- a/lib/dns/include/dns/zone.h
+++ b/lib/dns/include/dns/zone.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zone.h,v 1.126.18.19 2006/08/01 03:45:21 marka Exp $ */
+/* $Id: zone.h,v 1.126.18.24 2009/07/11 04:30:50 marka Exp $ */
 
 #ifndef DNS_ZONE_H
 #define DNS_ZONE_H 1
@@ -243,6 +243,9 @@ dns_zone_load(dns_zone_t *zone);
 
 isc_result_t
 dns_zone_loadnew(dns_zone_t *zone);
+
+isc_result_t
+dns_zone_loadandthaw(dns_zone_t *zone);
 /*%<
  *	Cause the database to be loaded from its backing store.
  *	Confirm that the minimum requirements for the zone type are
@@ -251,6 +254,8 @@ dns_zone_loadnew(dns_zone_t *zone);
  *	dns_zone_loadnew() only loads zones that are not yet loaded.
  *	dns_zone_load() also loads zones that are already loaded and
  *	and whose master file has changed since the last load.
+ *	dns_zone_loadandthaw() is similar to dns_zone_load() but will
+ *	also re-enable DNS UPDATEs when the load completes.
  *
  * Require:
  *\li	'zone' to be a valid zone.
@@ -406,7 +411,7 @@ dns_zone_refresh(dns_zone_t *zone);
 isc_result_t
 dns_zone_flush(dns_zone_t *zone);
 /*%<
- *	Write the zone to database if there are uncommited changes.
+ *	Write the zone to database if there are uncommitted changes.
  *
  * Require:
  *\li	'zone' to be a valid zone.
@@ -458,7 +463,7 @@ dns_zone_fulldumptostream(dns_zone_t *zone, FILE *fd);
 void
 dns_zone_maintenance(dns_zone_t *zone);
 /*%<
- *	Perform regular maintenace on the zone.  This is called as a
+ *	Perform regular maintenance on the zone.  This is called as a
  *	result of a zone being managed.
  *
  * Require
@@ -503,7 +508,7 @@ dns_zone_setalsonotify(dns_zone_t *zone, const isc_sockaddr_t *notify,
  * Require:
  *\li	'zone' to be a valid zone.
  *\li	'notify' to be non-NULL if count != 0.
- *\li	'count' to be the number of notifyees.
+ *\li	'count' to be the number of notifiees.
  *
  * Returns:
  *\li	#ISC_R_SUCCESS
@@ -905,13 +910,13 @@ isc_result_t
 dns_zone_notifyreceive(dns_zone_t *zone, isc_sockaddr_t *from,
 		       dns_message_t *msg);
 /*%<
- *	Tell the zone that it has recieved a NOTIFY message from another
- *	server.  This may cause some zone maintainence activity to occur.
+ *	Tell the zone that it has received a NOTIFY message from another
+ *	server.  This may cause some zone maintenance activity to occur.
  *
  * Requires:
  *\li	'zone' to be a valid zone.
  *\li	'*from' to contain the address of the server from which 'msg'
- *		was recieved.
+ *		was received.
  *\li	'msg' a message with opcode NOTIFY and qr clear.
  *
  * Returns:
@@ -1036,7 +1041,7 @@ dns_zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump);
  * If "dump" is ISC_TRUE, then the new zone contents are dumped
  * into to the zone's master file for persistence.  When replacing
  * a zone database by one just loaded from a master file, set
- * "dump" to ISC_FALSE to avoid a redunant redump of the data just
+ * "dump" to ISC_FALSE to avoid a redundant redump of the data just
  * loaded.  Otherwise, it should be set to ISC_TRUE.
  *
  * If the "diff-on-reload" option is enabled in the configuration file,
@@ -1048,7 +1053,7 @@ dns_zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump);
  *
  * Returns:
  * \li	DNS_R_SUCCESS
- * \li	DNS_R_BADZONE	zone failed basic consistancy checks:
+ * \li	DNS_R_BADZONE	zone failed basic consistency checks:
  *			* a single SOA must exist
  *			* some NS records must exist.
  *	Others
@@ -1159,10 +1164,10 @@ dns_zone_setnotifytype(dns_zone_t *zone, dns_notifytype_t notifytype);
 
 isc_result_t
 dns_zone_forwardupdate(dns_zone_t *zone, dns_message_t *msg,
-                       dns_updatecallback_t callback, void *callback_arg);
+		       dns_updatecallback_t callback, void *callback_arg);
 /*%<
  * Forward 'msg' to each master in turn until we get an answer or we
- * have exausted the list of masters. 'callback' will be called with
+ * have exhausted the list of masters. 'callback' will be called with
  * ISC_R_SUCCESS if we get an answer and the returned message will be
  * passed as 'answer_message', otherwise a non ISC_R_SUCCESS result code
  * will be passed and answer_message will be NULL.  The callback function
@@ -1267,7 +1272,7 @@ isc_result_t
 dns_zonemgr_forcemaint(dns_zonemgr_t *zmgr);
 /*%<
  * Force zone maintenance of all zones managed by 'zmgr' at its
- * earliest conveniene.
+ * earliest convenience.
  */
 
 void
@@ -1336,7 +1341,7 @@ dns_zonemgr_settransfersin(dns_zonemgr_t *zmgr, isc_uint32_t value);
 isc_uint32_t
 dns_zonemgr_getttransfersin(dns_zonemgr_t *zmgr);
 /*%<
- *	Return the the maximum number of simultaneous transfers in allowed.
+ *	Return the maximum number of simultaneous transfers in allowed.
  *
  * Requires:
  *\li	'zmgr' to be a valid zone manager.
@@ -1363,7 +1368,7 @@ dns_zonemgr_getttransfersperns(dns_zonemgr_t *zmgr);
 void
 dns_zonemgr_setiolimit(dns_zonemgr_t *zmgr, isc_uint32_t iolimit);
 /*%<
- *	Set the number of simultaneous file descriptors available for 
+ *	Set the number of simultaneous file descriptors available for
  *	reading and writing masterfiles.
  *
  * Requires:
@@ -1374,7 +1379,7 @@ dns_zonemgr_setiolimit(dns_zonemgr_t *zmgr, isc_uint32_t iolimit);
 isc_uint32_t
 dns_zonemgr_getiolimit(dns_zonemgr_t *zmgr);
 /*%<
- *	Get the number of simultaneous file descriptors available for 
+ *	Get the number of simultaneous file descriptors available for
  *	reading and writing masterfiles.
  *
  * Requires:
@@ -1484,7 +1489,7 @@ void
 dns_zone_name(dns_zone_t *zone, char *buf, size_t len);
 /*%<
  * Return the name of the zone with class and view.
- * 
+ *
  * Requires:
  *\li	'zone' to be valid.
  *\li	'buf' to be non NULL.
diff --git a/lib/dns/journal.c b/lib/dns/journal.c
index 4e4010fcb6f9..878ccdab0098 100644
--- a/lib/dns/journal.c
+++ b/lib/dns/journal.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: journal.c,v 1.86.18.14 2008/09/25 04:01:36 tbox Exp $ */
+/* $Id: journal.c,v 1.86.18.16 2009/01/19 23:46:15 tbox Exp $ */
 
 #include 
 
@@ -42,7 +42,7 @@
 #include 
 
 /*! \file
- * \brief Journalling.
+ * \brief Journaling.
  *
  * A journal file consists of
  *
@@ -172,7 +172,7 @@ dns_db_createsoatuple(dns_db_t *db, dns_dbversion_t *ver, isc_mem_t *mctx,
 	return (result);
 }
 
-/* Journalling */
+/* Journaling */
 
 /*%
  * On-disk representation of a "pointer" to a journal entry.
@@ -641,7 +641,7 @@ journal_open(isc_mem_t *mctx, const char *filename, isc_boolean_t write,
 	dns_rdata_init(&j->it.rdata);
 
 	/*
-	 * Set up empty initial buffers for uncheched and checked
+	 * Set up empty initial buffers for unchecked and checked
 	 * wire format RR data.  They will be reallocated
 	 * later.
 	 */
@@ -1209,7 +1209,7 @@ roll_forward(dns_journal_t *j, dns_db_t *db) {
 	dns_diff_init(j->mctx, &diff);
 
 	/*
-	 * Set up empty initial buffers for uncheched and checked
+	 * Set up empty initial buffers for unchecked and checked
 	 * wire format transaction data.  They will be reallocated
 	 * later.
 	 */
@@ -1374,7 +1374,7 @@ dns_journal_print(isc_mem_t *mctx, const char *filename, FILE *file) {
 	dns_diff_init(j->mctx, &diff);
 
 	/*
-	 * Set up empty initial buffers for uncheched and checked
+	 * Set up empty initial buffers for unchecked and checked
 	 * wire format transaction data.  They will be reallocated
 	 * later.
 	 */
diff --git a/lib/dns/master.c b/lib/dns/master.c
index b04f2eb63623..3a63aa90cd4e 100644
--- a/lib/dns/master.c
+++ b/lib/dns/master.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: master.c,v 1.148.18.21 2008/01/17 23:45:58 tbox Exp $ */
+/* $Id: master.c,v 1.148.18.23 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file */
 
@@ -1834,7 +1834,7 @@ load_text(dns_loadctx_t *lctx) {
 		/*
 		 * Find type in rdatalist.
 		 * If it does not exist create new one and prepend to list
-		 * as this will mimimise list traversal.
+		 * as this will minimise list traversal.
 		 */
 		if (ictx->glue != NULL)
 			this = ISC_LIST_HEAD(glue_list);
diff --git a/lib/dns/masterdump.c b/lib/dns/masterdump.c
index aa210e463d4c..bfa638105d3c 100644
--- a/lib/dns/masterdump.c
+++ b/lib/dns/masterdump.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: masterdump.c,v 1.73.18.16.2.1 2009/11/19 00:25:17 marka Exp $ */
+/* $Id: masterdump.c,v 1.73.18.19 2009/11/25 04:50:24 marka Exp $ */
 
 /*! \file */
 
@@ -283,7 +283,7 @@ totext_ctx_init(const dns_master_style_t *style, dns_totext_ctx_t *ctx) {
 		/*
 		 * Do not return ISC_R_NOSPACE if the line break string
 		 * buffer is too small, because that would just make
-		 * dump_rdataset() retry indenfinitely with ever
+		 * dump_rdataset() retry indefinitely with ever
 		 * bigger target buffers.  That's a different buffer,
 		 * so it won't help.  Use DNS_R_TEXTTOOLONG as a substitute.
 		 */
diff --git a/lib/dns/message.c b/lib/dns/message.c
index 8c56377d879e..4073a0d28371 100644
--- a/lib/dns/message.c
+++ b/lib/dns/message.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: message.c,v 1.222.18.16 2008/07/28 23:46:20 tbox Exp $ */
+/* $Id: message.c,v 1.222.18.18 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file */
 
@@ -138,7 +138,7 @@ static const char *rcodetext[] = {
 /*%
  * "helper" type, which consists of a block of some type, and is linkable.
  * For it to work, sizeof(dns_msgblock_t) must be a multiple of the pointer
- * size, or the allocated elements will not be alligned correctly.
+ * size, or the allocated elements will not be aligned correctly.
  */
 struct dns_msgblock {
 	unsigned int			count;
@@ -1934,7 +1934,7 @@ dns_message_rendersection(dns_message_t *msg, dns_section_t sectionid,
 				 *
 				 * XXXMLG Need to change this when
 				 * dns_rdataset_towire() can render partial
-				 * sets starting at some arbitary point in the
+				 * sets starting at some arbitrary point in the
 				 * set.  This will include setting a bit in the
 				 * rdataset to indicate that a partial
 				 * rendering was done, and some state saved
diff --git a/lib/dns/nsec.c b/lib/dns/nsec.c
index c1de67ed28eb..e301d71bd1ab 100644
--- a/lib/dns/nsec.c
+++ b/lib/dns/nsec.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nsec.c,v 1.5.20.2 2005/04/29 00:15:59 marka Exp $ */
+/* $Id: nsec.c,v 1.5.20.4 2009/01/06 23:45:57 tbox Exp $ */
 
 /*! \file */
 
@@ -197,7 +197,7 @@ dns_nsec_typepresent(dns_rdata_t *nsec, dns_rdatatype_t type) {
 	/* This should never fail */
 	result = dns_rdata_tostruct(nsec, &nsecstruct, NULL);
 	INSIST(result == ISC_R_SUCCESS);
-	
+
 	present = ISC_FALSE;
 	for (i = 0; i < nsecstruct.len; i += len) {
 		INSIST(i + 2 <= nsecstruct.len);
@@ -215,6 +215,6 @@ dns_nsec_typepresent(dns_rdata_t *nsec, dns_rdatatype_t type) {
 						   type % 256));
 		break;
 	}
-	dns_rdata_freestruct(&nsec);
+	dns_rdata_freestruct(&nsecstruct);
 	return (present);
 }
diff --git a/lib/dns/openssl_link.c b/lib/dns/openssl_link.c
index bb76e0e38eea..659b9eb99b28 100644
--- a/lib/dns/openssl_link.c
+++ b/lib/dns/openssl_link.c
@@ -1,5 +1,5 @@
 /*
- * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2003  Internet Software Consortium.
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
@@ -18,7 +18,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: openssl_link.c,v 1.1.6.12 2007/08/28 07:20:04 tbox Exp $
+ * $Id: openssl_link.c,v 1.1.6.14 2009/02/11 23:46:05 tbox Exp $
  */
 #ifdef OPENSSL
 
@@ -116,18 +116,8 @@ mem_free(void *ptr) {
 
 static void *
 mem_realloc(void *ptr, size_t size) {
-	void *p;
-
 	INSIST(dst__memory_pool != NULL);
-	p = NULL;
-	if (size > 0U) {
-		p = mem_alloc(size);
-		if (p != NULL && ptr != NULL)
-			memcpy(p, ptr, size);
-	}
-	if (ptr != NULL)
-		mem_free(ptr);
-	return (p);
+	return (isc_mem_reallocate(dst__memory_pool, ptr, size));
 }
 
 isc_result_t
diff --git a/lib/dns/openssldsa_link.c b/lib/dns/openssldsa_link.c
index 2ff33f3206c2..29f829c56cb2 100644
--- a/lib/dns/openssldsa_link.c
+++ b/lib/dns/openssldsa_link.c
@@ -1,5 +1,5 @@
 /*
- * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2002  Internet Software Consortium.
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
@@ -16,7 +16,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: openssldsa_link.c,v 1.1.6.9.28.1 2008/12/24 00:21:22 marka Exp $ */
+/* $Id: openssldsa_link.c,v 1.1.6.11 2009/01/14 23:46:03 tbox Exp $ */
 
 #ifdef OPENSSL
 
@@ -172,7 +172,7 @@ openssldsa_compare(const dst_key_t *key1, const dst_key_t *key2) {
 static isc_result_t
 openssldsa_generate(dst_key_t *key, int unused) {
 #if OPENSSL_VERSION_NUMBER > 0x00908000L
-        BN_GENCB cb;
+	BN_GENCB cb;
 #endif
 	DSA *dsa;
 	unsigned char rand_array[ISC_SHA1_DIGESTLENGTH];
@@ -186,12 +186,12 @@ openssldsa_generate(dst_key_t *key, int unused) {
 		return (result);
 
 #if OPENSSL_VERSION_NUMBER > 0x00908000L
-        dsa = DSA_new();
+	dsa = DSA_new();
 	if (dsa == NULL)
 		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
 
 	BN_GENCB_set_old(&cb, NULL, NULL);
-  
+
 	if (!DSA_generate_parameters_ex(dsa, key->key_size, rand_array,
 					ISC_SHA1_DIGESTLENGTH,  NULL, NULL,
 					&cb))
diff --git a/lib/dns/opensslrsa_link.c b/lib/dns/opensslrsa_link.c
index aacba455ce2e..2377297d9980 100644
--- a/lib/dns/opensslrsa_link.c
+++ b/lib/dns/opensslrsa_link.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -17,7 +17,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: opensslrsa_link.c,v 1.1.6.11.58.1 2008/12/24 00:21:22 marka Exp $
+ * $Id: opensslrsa_link.c,v 1.1.6.14 2009/01/19 00:36:27 marka Exp $
  */
 #ifdef OPENSSL
 
@@ -57,8 +57,8 @@
 
 
 	/*
-	 * XXXMPA  Temporarially disable RSA_BLINDING as it requires
-	 * good quality random data that cannot currently be guarenteed.
+	 * XXXMPA  Temporarily disable RSA_BLINDING as it requires
+	 * good quality random data that cannot currently be guaranteed.
 	 * XXXMPA  Find which versions of openssl use pseudo random data
 	 * and set RSA_FLAG_BLINDING for those.
 	 */
diff --git a/lib/dns/rbt.c b/lib/dns/rbt.c
index 4d3ca3aa449e..fecf96a0c35a 100644
--- a/lib/dns/rbt.c
+++ b/lib/dns/rbt.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbt.c,v 1.128.18.10 2008/03/31 13:32:59 fdupont Exp $ */
+/* $Id: rbt.c,v 1.128.18.12 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file */
 
@@ -119,7 +119,7 @@ struct dns_rbt {
  * Chain management.
  *
  * The "ancestors" member of chains were removed, with their job now
- * being wholy handled by parent pointers (which didn't exist, because
+ * being wholly handled by parent pointers (which didn't exist, because
  * of memory concerns, when chains were first implemented).
  */
 #define ADD_LEVEL(chain, node) \
@@ -1934,7 +1934,7 @@ dns_rbt_deletefromlevel(dns_rbtnode_t *delete, dns_rbtnode_t **rootp) {
 			} else {
 				/*
 				 * Child is parent's right child.
-				 * Everything is doen the same as above,
+				 * Everything is done the same as above,
 				 * except mirrored.
 				 */
 				sibling = LEFT(parent);
@@ -2398,7 +2398,7 @@ dns_rbtnodechain_next(dns_rbtnodechain_t *chain, dns_name_t *name,
 		 * reached without having traversed any left links, ascend one
 		 * level and look for either a right link off the point of
 		 * ascent, or search for a left link upward again, repeating
-		 * ascents until either case is true.
+		 * ascends until either case is true.
 		 */
 		do {
 			while (! IS_ROOT(current)) {
diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
index 940d78b65127..bd168080e76d 100644
--- a/lib/dns/rbtdb.c
+++ b/lib/dns/rbtdb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbtdb.c,v 1.196.18.53.4.1 2009/11/19 00:25:17 marka Exp $ */
+/* $Id: rbtdb.c,v 1.196.18.59 2009/11/26 23:46:11 tbox Exp $ */
 
 /*! \file */
 
@@ -502,7 +502,7 @@ static void free_rbtdb(dns_rbtdb_t *rbtdb, isc_boolean_t log,
 /*%
  * 'init_count' is used to initialize 'newheader->count' which inturn
  * is used to determine where in the cycle rrset-order cyclic starts.
- * We don't lock this as we don't care about simultanious updates.
+ * We don't lock this as we don't care about simultaneous updates.
  *
  * Note:
  *	Both init_count and header->count can be ISC_UINT32_MAX.
@@ -2609,11 +2609,17 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 		/*
 		 * The node may be a zone cut itself.  If it might be one,
 		 * make sure we check for it later.
+		 *
+		 * DS records live above the zone cut in ordinary zone so
+		 * we want to ignore any referral.
+		 *
+		 * Stub zones don't have anything "above" the delgation so
+		 * we always return a referral.
 		 */
 		if (node->find_callback &&
-		    (node != search.rbtdb->origin_node ||
-		     IS_STUB(search.rbtdb)) &&
-		    !dns_rdatatype_atparent(type))
+		    ((node != search.rbtdb->origin_node &&
+		      !dns_rdatatype_atparent(type)) ||
+		     IS_STUB(search.rbtdb)))
 			maybe_zonecut = ISC_TRUE;
 	}
 
@@ -3938,8 +3944,8 @@ expirenode(dns_db_t *db, dns_dbnode_t *node, isc_stdtime_t now) {
 
 		/*
 		 * Note that 'log' can be true IFF rbtdb->overmem is also true.
-		 * rbtdb->ovemem can currently only be true for cache databases
-		 * -- hence all of the "overmem cache" log strings.
+		 * rbtdb->overmem can currently only be true for cache
+		 * databases -- hence all of the "overmem cache" log strings.
 		 */
 		log = ISC_TF(isc_log_wouldlog(dns_lctx, level));
 		if (log)
@@ -4355,19 +4361,15 @@ cname_and_other_data(dns_rbtnode_t *node, rbtdb_serial_t serial) {
 			 * Look for active extant "other data".
 			 *
 			 * "Other data" is any rdataset whose type is not
-			 * KEY, RRSIG KEY, NSEC, RRSIG NSEC or RRSIG CNAME.
+			 * KEY, NSEC, SIG or RRSIG.
 			 */
 			rdtype = RBTDB_RDATATYPE_BASE(header->type);
-			if (rdtype == dns_rdatatype_rrsig ||
-			    rdtype == dns_rdatatype_sig)
-				rdtype = RBTDB_RDATATYPE_EXT(header->type);
-			if (rdtype != dns_rdatatype_nsec &&
-			    rdtype != dns_rdatatype_key &&
-			    rdtype != dns_rdatatype_cname) {
+			if (rdtype != dns_rdatatype_key &&
+			    rdtype != dns_rdatatype_sig &&
+			    rdtype != dns_rdatatype_nsec &&
+			    rdtype != dns_rdatatype_rrsig) {
 				/*
-				 * We've found a type that isn't
-				 * NSEC, KEY, CNAME, or one of their
-				 * signatures.  Is it active and extant?
+				 * Is it active and extant?
 				 */
 				do {
 					if (header->serial <= serial &&
@@ -4901,7 +4903,7 @@ addrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 
 	/*
 	 * Update the zone's secure status.  If version is non-NULL
-	 * this is defered until closeversion() is called.
+	 * this is deferred until closeversion() is called.
 	 */
 	if (result == ISC_R_SUCCESS && version == NULL && !IS_CACHE(rbtdb))
 		rbtdb->secure = iszonesecure(db, rbtdb->origin_node);
@@ -5064,7 +5066,7 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 
 	/*
 	 * Update the zone's secure status.  If version is non-NULL
-	 * this is defered until closeversion() is called.
+	 * this is deferred until closeversion() is called.
 	 */
 	if (result == ISC_R_SUCCESS && version == NULL && !IS_CACHE(rbtdb))
 		rbtdb->secure = iszonesecure(db, rbtdb->origin_node);
@@ -5116,7 +5118,7 @@ deleterdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 
 	/*
 	 * Update the zone's secure status.  If version is non-NULL
-	 * this is defered until closeversion() is called.
+	 * this is deferred until closeversion() is called.
 	 */
 	if (result == ISC_R_SUCCESS && version == NULL && !IS_CACHE(rbtdb))
 		rbtdb->secure = iszonesecure(db, rbtdb->origin_node);
@@ -5525,7 +5527,7 @@ dns_rbtdb_create
 	isc_mem_attach(mctx, &rbtdb->common.mctx);
 
 	/*
-	 * Must be initalized before free_rbtdb() is called.
+	 * Must be initialized before free_rbtdb() is called.
 	 */
 	isc_ondestroy_init(&rbtdb->common.ondest);
 
diff --git a/lib/dns/rdata.c b/lib/dns/rdata.c
index 564177790900..13409bc14394 100644
--- a/lib/dns/rdata.c
+++ b/lib/dns/rdata.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdata.c,v 1.184.18.9 2006/07/21 02:05:57 marka Exp $ */
+/* $Id: rdata.c,v 1.184.18.11 2008/12/12 23:46:04 tbox Exp $ */
 
 /*! \file */
 
@@ -111,7 +111,7 @@ typedef struct dns_rdata_textctx {
 	dns_name_t *origin;	/*%< Current origin, or NULL. */
 	unsigned int flags;	/*%< DNS_STYLEFLAG_*  */
 	unsigned int width;	/*%< Width of rdata column. */
-  	const char *linebreak;	/*%< Line break string. */
+	const char *linebreak;	/*%< Line break string. */
 } dns_rdata_textctx_t;
 
 static isc_result_t
@@ -532,7 +532,7 @@ unknown_fromtext(dns_rdataclass_t rdclass, dns_rdatatype_t type,
 	result = isc_buffer_allocate(mctx, &buf, token.value.as_ulong);
 	if (result != ISC_R_SUCCESS)
 		return (result);
-	
+
 	result = isc_hex_tobuffer(lexer, buf,
 				  (unsigned int)token.value.as_ulong);
 	if (result != ISC_R_SUCCESS)
@@ -728,7 +728,7 @@ dns_rdata_totext(dns_rdata_t *rdata, dns_name_t *origin, isc_buffer_t *target)
 isc_result_t
 dns_rdata_tofmttext(dns_rdata_t *rdata, dns_name_t *origin,
 		    unsigned int flags, unsigned int width,
-		    char *linebreak, isc_buffer_t *target)
+		    const char *linebreak, isc_buffer_t *target)
 {
 	dns_rdata_textctx_t tctx;
 
@@ -1504,16 +1504,16 @@ byte_btoa(int c, isc_buffer_t *target, struct state *state) {
 			   /*
 			    * Because some don't support u_long.
 			    */
-		    	tmp = 32;
-		    	tmpword -= (isc_int32_t)(85 * 85 * 85 * 85 * 32);
+			tmp = 32;
+			tmpword -= (isc_int32_t)(85 * 85 * 85 * 85 * 32);
 		    }
 		    if (tmpword < 0) {
-		    	tmp = 64;
-		    	tmpword -= (isc_int32_t)(85 * 85 * 85 * 85 * 32);
+			tmp = 64;
+			tmpword -= (isc_int32_t)(85 * 85 * 85 * 85 * 32);
 		    }
 			if (tr.length < 5)
 				return (ISC_R_NOSPACE);
-		    	tr.base[0] = atob_digits[(tmpword /
+			tr.base[0] = atob_digits[(tmpword /
 					      (isc_int32_t)(85 * 85 * 85 * 85))
 						+ tmp];
 			tmpword %= (isc_int32_t)(85 * 85 * 85 * 85);
@@ -1596,7 +1596,7 @@ warn_badmx(isc_token_t *token, isc_lex_t *lexer,
 	if (lexer != NULL) {
 		file = isc_lex_getsourcename(lexer);
 		line = isc_lex_getsourceline(lexer);
-		(*callbacks->warn)(callbacks, "%s:%u: warning: '%s': %s", 
+		(*callbacks->warn)(callbacks, "%s:%u: warning: '%s': %s",
 				   file, line, DNS_AS_STR(*token),
 				   dns_result_totext(DNS_R_MXISADDRESS));
 	}
@@ -1609,12 +1609,12 @@ warn_badname(dns_name_t *name, isc_lex_t *lexer,
 	const char *file;
 	unsigned long line;
 	char namebuf[DNS_NAME_FORMATSIZE];
-	
+
 	if (lexer != NULL) {
 		file = isc_lex_getsourcename(lexer);
 		line = isc_lex_getsourceline(lexer);
 		dns_name_format(name, namebuf, sizeof(namebuf));
-		(*callbacks->warn)(callbacks, "%s:%u: warning: %s: %s", 
+		(*callbacks->warn)(callbacks, "%s:%u: warning: %s: %s",
 				   file, line, namebuf,
 				   dns_result_totext(DNS_R_BADNAME));
 	}
diff --git a/lib/dns/rdata/generic/ipseckey_45.c b/lib/dns/rdata/generic/ipseckey_45.c
index 3c3736e76867..e3ff045bff4f 100644
--- a/lib/dns/rdata/generic/ipseckey_45.c
+++ b/lib/dns/rdata/generic/ipseckey_45.c
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ipseckey_45.c,v 1.2.2.1 2005/07/07 03:17:36 marka Exp $ */
+/* $Id: ipseckey_45.c,v 1.2.2.4 2009/09/18 21:57:08 jinmei Exp $ */
 
 #ifndef RDATA_GENERIC_IPSECKEY_45_C
 #define RDATA_GENERIC_IPSECKEY_45_C
@@ -131,15 +131,15 @@ totext_ipseckey(ARGS_TOTEXT) {
 
 	dns_name_init(&name, NULL);
 	dns_name_init(&prefix, NULL);
-	
+
 	if (rdata->data[1] > 3U)
 		return (ISC_R_NOTIMPLEMENTED);
 
-        if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
-                RETERR(str_totext("( ", target));
+	if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
+		RETERR(str_totext("( ", target));
 
 	/*
-	 * Precendence.
+	 * Precedence.
 	 */
 	dns_rdata_toregion(rdata, ®ion);
 	num = uint8_fromregion(®ion);
@@ -198,14 +198,14 @@ totext_ipseckey(ARGS_TOTEXT) {
 					 tctx->linebreak, target));
 	}
 
-        if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
-                RETERR(str_totext(" )", target));
+	if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
+		RETERR(str_totext(" )", target));
 	return (ISC_R_SUCCESS);
 }
 
 static inline isc_result_t
 fromwire_ipseckey(ARGS_FROMWIRE) {
-        dns_name_t name;
+	dns_name_t name;
 	isc_region_t region;
 
 	REQUIRE(type == 45);
@@ -215,7 +215,7 @@ fromwire_ipseckey(ARGS_FROMWIRE) {
 
 	dns_decompress_setmethods(dctx, DNS_COMPRESS_NONE);
 
-        dns_name_init(&name, NULL);
+	dns_name_init(&name, NULL);
 
 	isc_buffer_activeregion(source, ®ion);
 	if (region.length < 3)
@@ -243,6 +243,7 @@ fromwire_ipseckey(ARGS_FROMWIRE) {
 		isc_buffer_forward(source, 3);
 		RETERR(dns_name_fromwire(&name, source, dctx, options, target));
 		isc_buffer_activeregion(source, ®ion);
+		isc_buffer_forward(source, region.length);
 		return(mem_tobuffer(target, region.base, region.length));
 
 	default:
diff --git a/lib/dns/rdata/generic/loc_29.c b/lib/dns/rdata/generic/loc_29.c
index c93ac90005ef..aa3e02ae2fc6 100644
--- a/lib/dns/rdata/generic/loc_29.c
+++ b/lib/dns/rdata/generic/loc_29.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: loc_29.c,v 1.41.18.2 2005/04/29 00:16:34 marka Exp $ */
+/* $Id: loc_29.c,v 1.41.18.6 2009/02/17 05:55:19 marka Exp $ */
 
 /* Reviewed: Wed Mar 15 18:13:09 PST 2000 by explorer */
 
@@ -482,16 +482,19 @@ totext_loc(ARGS_TOTEXT) {
 
 	/* version = sr.base[0]; */
 	size = sr.base[1];
+	INSIST((size&0x0f) < 10 && (size>>4) < 10);
 	if ((size&0x0f)> 1)
 		sprintf(sbuf, "%lum", (size>>4) * poweroften[(size&0x0f)-2]);
 	else
 		sprintf(sbuf, "0.%02lum", (size>>4) * poweroften[(size&0x0f)]);
 	hp = sr.base[2];
+	INSIST((hp&0x0f) < 10 && (hp>>4) < 10);
 	if ((hp&0x0f)> 1)
 		sprintf(hbuf, "%lum", (hp>>4) * poweroften[(hp&0x0f)-2]);
 	else
 		sprintf(hbuf, "0.%02lum", (hp>>4) * poweroften[(hp&0x0f)]);
 	vp = sr.base[3];
+	INSIST((vp&0x0f) < 10 && (vp>>4) < 10);
 	if ((vp&0x0f)> 1)
 		sprintf(vbuf, "%lum", (vp>>4) * poweroften[(vp&0x0f)-2]);
 	else
@@ -514,6 +517,7 @@ totext_loc(ARGS_TOTEXT) {
 	m1 = (int)(latitude % 60);
 	latitude /= 60;
 	d1 = (int)latitude;
+	INSIST(latitude <= 90U);
 
 	longitude = uint32_fromregion(&sr);
 	isc_region_consume(&sr, 4);
@@ -531,6 +535,7 @@ totext_loc(ARGS_TOTEXT) {
 	m2 = (int)(longitude % 60);
 	longitude /= 60;
 	d2 = (int)longitude;
+	INSIST(longitude <= 180U);
 
 	altitude = uint32_fromregion(&sr);
 	isc_region_consume(&sr, 4);
@@ -616,7 +621,7 @@ fromwire_loc(ARGS_FROMWIRE) {
 		return (ISC_R_RANGE);
 
 	/*
-	 * Altitiude.
+	 * Altitude.
 	 * All values possible.
 	 */
 
diff --git a/lib/dns/rdata/generic/soa_6.c b/lib/dns/rdata/generic/soa_6.c
index 8de678c581ba..788510054332 100644
--- a/lib/dns/rdata/generic/soa_6.c
+++ b/lib/dns/rdata/generic/soa_6.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: soa_6.c,v 1.59 2004/03/05 05:10:18 marka Exp $ */
+/* $Id: soa_6.c,v 1.59.18.2 2009/02/16 23:46:03 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 15:18:32 PST 2000 by explorer */
 
@@ -101,7 +101,11 @@ totext_soa(ARGS_TOTEXT) {
 	REQUIRE(rdata->length != 0);
 
 	multiline = ISC_TF((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0);
-	comment = ISC_TF((tctx->flags & DNS_STYLEFLAG_COMMENT) != 0);
+	if (multiline)
+		comment = ISC_TF((tctx->flags & DNS_STYLEFLAG_COMMENT) != 0);
+	else
+		comment = ISC_FALSE;
+
 
 	dns_name_init(&mname, NULL);
 	dns_name_init(&rname, NULL);
@@ -128,16 +132,13 @@ totext_soa(ARGS_TOTEXT) {
 	RETERR(str_totext(tctx->linebreak, target));
 
 	for (i = 0; i < 5; i++) {
-		char buf[sizeof("2147483647")];
+		char buf[sizeof("0123456789 ; ")];
 		unsigned long num;
-		unsigned int numlen;
 		num = uint32_fromregion(&dregion);
 		isc_region_consume(&dregion, 4);
-		numlen = sprintf(buf, "%lu", num);
-		INSIST(numlen > 0 && numlen < sizeof("2147483647"));
+		sprintf(buf, comment ? "%-10lu ; " : "%lu", num);
 		RETERR(str_totext(buf, target));
-		if (multiline && comment) {
-			RETERR(str_totext("           ; " + numlen, target));
+		if (comment) {
 			RETERR(str_totext(soa_fieldnames[i], target));
 			/* Print times in week/day/hour/minute/second form */
 			if (i >= 1) {
@@ -147,7 +148,7 @@ totext_soa(ARGS_TOTEXT) {
 			}
 			RETERR(str_totext(tctx->linebreak, target));
 		} else if (i < 4) {
-			RETERR(str_totext(tctx->linebreak, target));			
+			RETERR(str_totext(tctx->linebreak, target));
 		}
 	}
 
@@ -159,8 +160,8 @@ totext_soa(ARGS_TOTEXT) {
 
 static inline isc_result_t
 fromwire_soa(ARGS_FROMWIRE) {
-        dns_name_t mname;
-        dns_name_t rname;
+	dns_name_t mname;
+	dns_name_t rname;
 	isc_region_t sregion;
 	isc_region_t tregion;
 
@@ -171,11 +172,11 @@ fromwire_soa(ARGS_FROMWIRE) {
 
 	dns_decompress_setmethods(dctx, DNS_COMPRESS_GLOBAL14);
 
-        dns_name_init(&mname, NULL);
-        dns_name_init(&rname, NULL);
+	dns_name_init(&mname, NULL);
+	dns_name_init(&rname, NULL);
 
-        RETERR(dns_name_fromwire(&mname, source, dctx, options, target));
-        RETERR(dns_name_fromwire(&rname, source, dctx, options, target));
+	RETERR(dns_name_fromwire(&mname, source, dctx, options, target));
+	RETERR(dns_name_fromwire(&rname, source, dctx, options, target));
 
 	isc_buffer_activeregion(source, &sregion);
 	isc_buffer_availableregion(target, &tregion);
diff --git a/lib/dns/rdata/in_1/wks_11.c b/lib/dns/rdata/in_1/wks_11.c
index 749b8fd7fcfe..12caf4f4f9e9 100644
--- a/lib/dns/rdata/in_1/wks_11.c
+++ b/lib/dns/rdata/in_1/wks_11.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: wks_11.c,v 1.51.18.1 2004/09/16 01:02:19 marka Exp $ */
+/* $Id: wks_11.c,v 1.51.18.3 2009/02/16 23:46:03 tbox Exp $ */
 
 /* Reviewed: Fri Mar 17 15:01:49 PST 2000 by explorer */
 
@@ -158,6 +158,7 @@ totext_in_wks(ARGS_TOTEXT) {
 	RETERR(str_totext(buf, target));
 	isc_region_consume(&sr, 1);
 
+	INSIST(sr.length <= 8*1024);
 	for (i = 0; i < sr.length; i++) {
 		if (sr.base[i] != 0)
 			for (j = 0; j < 8; j++)
@@ -242,7 +243,8 @@ fromstruct_in_wks(ARGS_FROMSTRUCT) {
 	REQUIRE(source != NULL);
 	REQUIRE(wks->common.rdtype == type);
 	REQUIRE(wks->common.rdclass == rdclass);
-	REQUIRE(wks->map != NULL || wks->map_len == 0);
+	REQUIRE((wks->map != NULL && wks->map_len <= 8*1024) ||
+		 wks->map_len == 0);
 
 	UNUSED(type);
 	UNUSED(rdclass);
diff --git a/lib/dns/rdataset.c b/lib/dns/rdataset.c
index c86b3c5f76fd..f3c062da2f5c 100644
--- a/lib/dns/rdataset.c
+++ b/lib/dns/rdataset.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.c,v 1.72.18.5 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: rdataset.c,v 1.72.18.7 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file */
 
@@ -137,7 +137,7 @@ question_disassociate(dns_rdataset_t *rdataset) {
 static isc_result_t
 question_cursor(dns_rdataset_t *rdataset) {
 	UNUSED(rdataset);
-	
+
 	return (ISC_R_NOMORE);
 }
 
@@ -148,7 +148,7 @@ question_current(dns_rdataset_t *rdataset, dns_rdata_t *rdata) {
 	 */
 	UNUSED(rdataset);
 	UNUSED(rdata);
-	
+
 	REQUIRE(0);
 }
 
@@ -339,7 +339,7 @@ towiresorted(dns_rdataset_t *rdataset, const dns_name_t *owner_name,
 	}
 
 	/*
-	 * Do we want to shuffle this anwer?
+	 * Do we want to shuffle this answer?
 	 */
 	if (!question && count > 1 &&
 	    (!WANT_FIXED(rdataset) || order != NULL) &&
@@ -445,7 +445,7 @@ towiresorted(dns_rdataset_t *rdataset, const dns_name_t *owner_name,
 		/*
 		 * Copy out the name, type, class, ttl.
 		 */
-		
+
 		rrbuffer = *target;
 		dns_compress_setmethods(cctx, DNS_COMPRESS_GLOBAL14);
 		result = dns_name_towire(owner_name, cctx, target);
@@ -620,7 +620,7 @@ dns_rdataset_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name) {
 
 isc_result_t
 dns_rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
-		        dns_rdataset_t *nsec, dns_rdataset_t *nsecsig)
+			dns_rdataset_t *nsec, dns_rdataset_t *nsecsig)
 {
 	REQUIRE(DNS_RDATASET_VALID(rdataset));
 	REQUIRE(rdataset->methods != NULL);
diff --git a/lib/dns/rdataslab.c b/lib/dns/rdataslab.c
index 5d89d0123bd6..4255b1d0002c 100644
--- a/lib/dns/rdataslab.c
+++ b/lib/dns/rdataslab.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataslab.c,v 1.35.18.8 2007/08/28 07:20:05 tbox Exp $ */
+/* $Id: rdataslab.c,v 1.35.18.10 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file */
 
@@ -65,7 +65,7 @@
  *
  * DNSSEC order traversal is performed by walking the data records.
  *
- * The order is stored with record to allow for efficient reconstuction of
+ * The order is stored with record to allow for efficient reconstruction
  * of the offset table following a merge or subtraction.
  *
  * The iterator methods here currently only support DNSSEC order iteration.
@@ -246,7 +246,7 @@ dns_rdataslab_fromrdataset(dns_rdataset_t *rdataset, isc_mem_t *mctx,
 		result = ISC_R_NOMEMORY;
 		goto free_rdatas;
 	}
-	
+
 #if DNS_RDATASET_FIXED
 	/* Allocate temporary offset table. */
 	offsettable = isc_mem_get(mctx, nalloc * sizeof(unsigned int));
@@ -288,7 +288,7 @@ dns_rdataslab_fromrdataset(dns_rdataset_t *rdataset, isc_mem_t *mctx,
 		memcpy(rawbuf, x[i].rdata.data, x[i].rdata.length);
 		rawbuf += x[i].rdata.length;
 	}
-	
+
 #if DNS_RDATASET_FIXED
 	fillin_offsets(offsetbase, offsettable, nalloc);
 	isc_mem_put(mctx, offsettable, nalloc * sizeof(unsigned int));
@@ -368,7 +368,7 @@ rdataset_current(dns_rdataset_t *rdataset, dns_rdata_t *rdata) {
 	raw += 4;
 #else
 	raw += 2;
-#endif 
+#endif
 	r.base = raw;
 	dns_rdata_fromregion(rdata, rdataset->rdclass, rdataset->type, &r);
 }
@@ -511,7 +511,7 @@ rdata_in_slab(unsigned char *slab, unsigned int reservelen,
 
 	for (i = 0; i < count; i++) {
 		rdata_from_slab(¤t, rdclass, type, &trdata);
-		
+
 		n = dns_rdata_compare(&trdata, rdata);
 		if (n == 0)
 			return (ISC_TRUE);
diff --git a/lib/dns/request.c b/lib/dns/request.c
index 64a3a4e31cfa..9b712816fdc5 100644
--- a/lib/dns/request.c
+++ b/lib/dns/request.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: request.c,v 1.72.18.8 2008/07/22 03:51:44 marka Exp $ */
+/* $Id: request.c,v 1.72.18.10 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file */
 
@@ -95,7 +95,7 @@ struct dns_request {
 #define DNS_REQUEST_F_SENDING 0x0002
 #define DNS_REQUEST_F_CANCELED 0x0004	/*%< ctlevent received, or otherwise
 					   synchronously canceled */
-#define DNS_REQUEST_F_TIMEDOUT 0x0008	/*%< cancelled due to a timeout */
+#define DNS_REQUEST_F_TIMEDOUT 0x0008	/*%< canceled due to a timeout */
 #define DNS_REQUEST_F_TCP 0x0010	/*%< This request used TCP */
 #define DNS_REQUEST_CANCELED(r) \
 	(((r)->flags & DNS_REQUEST_F_CANCELED) != 0)
@@ -197,7 +197,7 @@ dns_requestmgr_create(isc_mem_t *mctx,
 		dns_dispatch_attach(dispatchv6, &requestmgr->dispatchv6);
 	requestmgr->mctx = NULL;
 	isc_mem_attach(mctx, &requestmgr->mctx);
-	requestmgr->eref = 1;	/* implict attach */
+	requestmgr->eref = 1;	/* implicit attach */
 	requestmgr->iref = 0;
 	ISC_LIST_INIT(requestmgr->whenshutdown);
 	ISC_LIST_INIT(requestmgr->requests);
diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c
index 66e79c53e0d1..7b41e72da729 100644
--- a/lib/dns/resolver.c
+++ b/lib/dns/resolver.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.c,v 1.284.18.79.2.1 2009/11/19 00:25:17 marka Exp $ */
+/* $Id: resolver.c,v 1.284.18.99 2010/01/07 23:46:07 tbox Exp $ */
 
 /*! \file */
 
@@ -154,6 +154,12 @@ typedef enum {
 	fetchstate_done			/*%< FETCHDONE events posted. */
 } fetchstate;
 
+typedef enum {
+	badns_unreachable = 0,
+	badns_response,
+	badns_validation
+} badnstype_t;
+
 struct fetchctx {
 	/*% Not locked. */
 	unsigned int			magic;
@@ -219,6 +225,7 @@ struct fetchctx {
 	 * is used for EDNS0 black hole detection.
 	 */
 	unsigned int			timeouts;
+
 	/*%
 	 * Look aside state for DS lookups.
 	 */
@@ -230,6 +237,25 @@ struct fetchctx {
 	 * Number of queries that reference this context.
 	 */
 	unsigned int			nqueries;
+
+	/*%
+	 * Fetch-local statistics for detailed logging.
+	 */
+	isc_result_t			result; /*%< fetch result  */
+	isc_result_t			vresult; /*%< validation result  */
+	int				exitline;
+	isc_time_t			start;
+	isc_uint64_t			duration;
+	isc_boolean_t			logged;
+	unsigned int			querysent;
+	unsigned int			referrals;
+	unsigned int			lamecount;
+	unsigned int			neterr;
+	unsigned int			badresp;
+	unsigned int			adberr;
+	unsigned int			findfail;
+	unsigned int			valfail;
+	isc_boolean_t			timeout;
 };
 
 #define FCTX_MAGIC			ISC_MAGIC('F', '!', '!', '!')
@@ -375,7 +401,7 @@ static isc_result_t ncache_adderesult(dns_message_t *message,
 static void validated(isc_task_t *task, isc_event_t *event);
 static void maybe_destroy(fetchctx_t *fctx);
 static void add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
-		    isc_result_t reason);
+		    isc_result_t reason, badnstype_t badtype);
 
 static isc_result_t
 valcreate(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, dns_name_t *name,
@@ -414,6 +440,30 @@ valcreate(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, dns_name_t *name,
 	return (result);
 }
 
+static isc_boolean_t
+rrsig_fromchildzone(fetchctx_t *fctx, dns_rdataset_t *rdataset) {
+	dns_namereln_t namereln;
+	dns_rdata_rrsig_t rrsig;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	int order;
+	isc_result_t result;
+	unsigned int labels;
+
+	for (result = dns_rdataset_first(rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(rdataset)) {
+		dns_rdataset_current(rdataset, &rdata);
+		result = dns_rdata_tostruct(&rdata, &rrsig, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		namereln = dns_name_fullcompare(&rrsig.signer, &fctx->domain,
+						&order, &labels);
+		if (namereln == dns_namereln_subdomain)
+			return (ISC_TRUE);
+		dns_rdata_reset(&rdata);
+	}
+	return (ISC_FALSE);
+}
+
 static isc_boolean_t
 fix_mustbedelegationornxdomain(dns_message_t *message, fetchctx_t *fctx) {
 	dns_name_t *name;
@@ -427,13 +477,43 @@ fix_mustbedelegationornxdomain(dns_message_t *message, fetchctx_t *fctx) {
 		return (ISC_FALSE);
 
 	/*
-	 * Look for BIND 8 style delegations.
-	 * Also look for answers to ANY queries where the duplicate NS RRset
-	 * may have been stripped from the authority section.
+	 * A DS RRset can appear anywhere in a zone, even for a delegation-only
+	 * zone.  So a response to an explicit query for this type should be
+	 * excluded from delegation-only fixup.
+	 *
+	 * SOA, NS, and DNSKEY can only exist at a zone apex, so a postive
+	 * response to a query for these types can never violate the
+	 * delegation-only assumption: if the query name is below a
+	 * zone cut, the response should normally be a referral, which should
+	 * be accepted; if the query name is below a zone cut but the server
+	 * happens to have authority for the zone of the query name, the
+	 * response is a (non-referral) answer.  But this does not violate
+	 * delegation-only because the query name must be in a different zone
+	 * due to the "apex-only" nature of these types.  Note that if the
+	 * remote server happens to have authority for a child zone of a
+	 * delegation-only zone, we may still incorrectly "fix" the response
+	 * with NXDOMAIN for queries for other types.  Unfortunately it's
+	 * generally impossible to differentiate this case from violation of
+	 * the delegation-only assumption.  Once the resolver learns the
+	 * correct zone cut, possibly via a separate query for an "apex-only"
+	 * type, queries for other types will be resolved correctly.
+	 *
+	 * A query for type ANY will be accepted if it hits an exceptional
+	 * type above in the answer section as it should be from a child
+	 * zone.
+	 *
+	 * Also accept answers with RRSIG records from the child zone.
+	 * Direct queries for RRSIG records should not be answered from
+	 * the parent zone.
 	 */
+
 	if (message->counts[DNS_SECTION_ANSWER] != 0 &&
 	    (fctx->type == dns_rdatatype_ns ||
-	     fctx->type == dns_rdatatype_any)) {
+	     fctx->type == dns_rdatatype_ds ||
+	     fctx->type == dns_rdatatype_soa ||
+	     fctx->type == dns_rdatatype_any ||
+	     fctx->type == dns_rdatatype_rrsig ||
+	     fctx->type == dns_rdatatype_dnskey)) {
 		result = dns_message_firstname(message, DNS_SECTION_ANSWER);
 		while (result == ISC_R_SUCCESS) {
 			name = NULL;
@@ -442,10 +522,32 @@ fix_mustbedelegationornxdomain(dns_message_t *message, fetchctx_t *fctx) {
 			for (rdataset = ISC_LIST_HEAD(name->list);
 			     rdataset != NULL;
 			     rdataset = ISC_LIST_NEXT(rdataset, link)) {
-				type = rdataset->type;
-				if (type != dns_rdatatype_ns)
+				if (!dns_name_equal(name, &fctx->name))
 					continue;
-				if (dns_name_issubdomain(name, domain))
+				type = rdataset->type;
+				/*
+				 * RRsig from child?
+				 */
+				if (type == dns_rdatatype_rrsig &&
+				    rrsig_fromchildzone(fctx, rdataset))
+					return (ISC_FALSE);
+				/*
+				 * Direct query for apex records or DS.
+				 */
+				if (fctx->type == type &&
+				    (type == dns_rdatatype_ds ||
+				     type == dns_rdatatype_ns ||
+				     type == dns_rdatatype_soa ||
+				     type == dns_rdatatype_dnskey))
+					return (ISC_FALSE);
+				/*
+				 * Indirect query for apex records or DS.
+				 */
+				if (fctx->type == dns_rdatatype_any &&
+				    (type == dns_rdatatype_ns ||
+				     type == dns_rdatatype_ds ||
+				     type == dns_rdatatype_soa ||
+				     type == dns_rdatatype_dnskey))
 					return (ISC_FALSE);
 			}
 			result = dns_message_nextname(message,
@@ -453,7 +555,14 @@ fix_mustbedelegationornxdomain(dns_message_t *message, fetchctx_t *fctx) {
 		}
 	}
 
-	/* Look for referral. */
+	/*
+	 * A NODATA response to a DS query?
+	 */
+	if (fctx->type == dns_rdatatype_ds &&
+	    message->counts[DNS_SECTION_ANSWER] == 0)
+		return (ISC_FALSE);
+
+	/* Look for referral or indication of answer from child zone? */
 	if (message->counts[DNS_SECTION_AUTHORITY] == 0)
 		goto munge;
 
@@ -468,13 +577,37 @@ fix_mustbedelegationornxdomain(dns_message_t *message, fetchctx_t *fctx) {
 			if (type == dns_rdatatype_soa &&
 			    dns_name_equal(name, domain))
 				keep_auth = ISC_TRUE;
+
 			if (type != dns_rdatatype_ns &&
-			    type != dns_rdatatype_soa)
+			    type != dns_rdatatype_soa &&
+			    type != dns_rdatatype_rrsig)
 				continue;
-			if (dns_name_equal(name, domain))
-				goto munge;
-			if (dns_name_issubdomain(name, domain))
+
+			if (type == dns_rdatatype_rrsig) {
+				if (rrsig_fromchildzone(fctx, rdataset))
+					return (ISC_FALSE);
+				else
+					continue;
+			}
+
+			/* NS or SOA records. */
+			if (dns_name_equal(name, domain)) {
+				/*
+				 * If a query for ANY causes a negative
+				 * response, we can be sure that this is
+				 * an empty node.  For other type of queries
+				 * we cannot differentiate an empty node
+				 * from a node that just doesn't have that
+				 * type of record.  We only accept the former
+				 * case.
+				 */
+				if (message->counts[DNS_SECTION_ANSWER] == 0 &&
+				    fctx->type == dns_rdatatype_any)
+					return (ISC_FALSE);
+			} else if (dns_name_issubdomain(name, domain)) {
+				/* Referral or answer from child zone. */
 				return (ISC_FALSE);
+			}
 		}
 		result = dns_message_nextname(message, DNS_SECTION_AUTHORITY);
 	}
@@ -522,14 +655,13 @@ fctx_stoptimer(fetchctx_t *fctx) {
 
 
 static inline isc_result_t
-fctx_startidletimer(fetchctx_t *fctx) {
+fctx_startidletimer(fetchctx_t *fctx, isc_interval_t *interval) {
 	/*
 	 * Start the idle timer for fctx.  The lifetime timer continues
 	 * to be in effect.
 	 */
 	return (isc_timer_reset(fctx->timer, isc_timertype_once,
-				&fctx->expires, &fctx->interval,
-				ISC_FALSE));
+				&fctx->expires, interval, ISC_FALSE));
 }
 
 /*
@@ -790,12 +922,13 @@ fctx_stopeverything(fetchctx_t *fctx, isc_boolean_t no_response) {
 }
 
 static inline void
-fctx_sendevents(fetchctx_t *fctx, isc_result_t result) {
+fctx_sendevents(fetchctx_t *fctx, isc_result_t result, int line) {
 	dns_fetchevent_t *event, *next_event;
 	isc_task_t *task;
 	unsigned int count = 0;
 	isc_interval_t i;
 	isc_boolean_t logit = ISC_FALSE;
+	isc_time_t now;
 	unsigned int old_spillat;
 	unsigned int new_spillat = 0;	/* initialized to silence compiler warnings */
 
@@ -806,6 +939,14 @@ fctx_sendevents(fetchctx_t *fctx, isc_result_t result) {
 
 	FCTXTRACE("sendevents");
 
+	/*
+	 * Keep some record of fetch result for logging later (if required).
+	 */
+	fctx->result = result;
+	fctx->exitline = line;
+	TIME_NOW(&now);
+	fctx->duration = isc_time_microdiff(&now, &fctx->start);
+
 	for (event = ISC_LIST_HEAD(fctx->events);
 	     event != NULL;
 	     event = next_event) {
@@ -865,10 +1006,12 @@ fctx_sendevents(fetchctx_t *fctx, isc_result_t result) {
 }
 
 static void
-fctx_done(fetchctx_t *fctx, isc_result_t result) {
+fctx_done(fetchctx_t *fctx, isc_result_t result, int line) {
 	dns_resolver_t *res;
 	isc_boolean_t no_response;
 
+	REQUIRE(line >= 0);
+
 	FCTXTRACE("done");
 
 	res = fctx->res;
@@ -883,7 +1026,7 @@ fctx_done(fetchctx_t *fctx, isc_result_t result) {
 
 	fctx->state = fetchstate_done;
 	fctx->attributes &= ~FCTX_ATTR_ADDRWAIT;
-	fctx_sendevents(fctx, result);
+	fctx_sendevents(fctx, result, line);
 
 	UNLOCK(&res->buckets[fctx->bucketnum].lock);
 }
@@ -921,7 +1064,8 @@ process_sendevent(resquery_t *query, isc_event_t *event) {
 			/*
 			 * No route to remote.
 			 */
-			add_bad(fctx, query->addrinfo, sevent->result);
+			add_bad(fctx, query->addrinfo, sevent->result,
+				badns_unreachable);
 			fctx_cancelquery(&query, NULL, NULL, ISC_TRUE);
 			retry = ISC_TRUE;
 			break;
@@ -942,7 +1086,7 @@ process_sendevent(resquery_t *query, isc_event_t *event) {
 		fctx->attributes &= ~FCTX_ATTR_ADDRWAIT;
 		result = fctx_stopidletimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else
 			fctx_try(fctx);
 	}
@@ -1048,7 +1192,7 @@ fctx_setretryinterval(fetchctx_t *fctx, unsigned int rtt) {
 	unsigned int us;
 
 	/*
-	 * We retry every .5 seconds the first two times through the address
+	 * We retry every .8 seconds the first two times through the address
 	 * list, and then we do exponential back-off.
 	 */
 	if (fctx->restarts < 3)
@@ -1095,7 +1239,7 @@ fctx_query(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
 	task = res->buckets[fctx->bucketnum].task;
 
 	fctx_setretryinterval(fctx, addrinfo->srtt);
-	result = fctx_startidletimer(fctx);
+	result = fctx_startidletimer(fctx, &fctx->interval);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
@@ -1262,6 +1406,7 @@ fctx_query(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
 		if (result != ISC_R_SUCCESS)
 			goto cleanup_dispatch;
 	}
+	fctx->querysent++;
 
 	ISC_LIST_APPEND(fctx->queries, query, link);
 	query->fctx->nqueries++;
@@ -1493,20 +1638,32 @@ resquery_send(resquery_t *query) {
 	}
 
 	/*
-	 * Use EDNS0, unless the caller doesn't want it, or we know that
-	 * the remote server doesn't like it.
-	 */
-
-	if ((triededns512(fctx, &query->addrinfo->sockaddr) ||
-	     fctx->timeouts >= (MAX_EDNS0_TIMEOUTS * 2)) &&
-	    (query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
-		query->options |= DNS_FETCHOPT_NOEDNS0;
-		FCTXTRACE("too many timeouts, disabling EDNS0");
-	} else if ((triededns(fctx, &query->addrinfo->sockaddr) ||
-		    fctx->timeouts >= MAX_EDNS0_TIMEOUTS) &&
-		   (query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
-		query->options |= DNS_FETCHOPT_EDNS512;
-		FCTXTRACE("too many timeouts, setting EDNS size to 512");
+	 * Handle timeouts by reducing the UDP response size to 512 bytes
+	 * then if that doesn't work disabling EDNS (includes DO) and CD.
+	 *
+	 * These timeout can be due to:
+	 *	* broken nameservers that don't respond to EDNS queries.
+	 *	* broken/misconfigured firewalls and NAT implementations
+	 *	  that don't handle IP fragmentation.
+	 *	* broken/misconfigured firewalls that don't handle responses
+	 *	  greater than 512 bytes.
+	 *	* broken/misconfigured firewalls that don't handle EDNS, DO
+	 *	  or CD.
+	 *	* packet loss / link outage.
+	 */
+	if (fctx->timeout) {
+		if ((triededns512(fctx, &query->addrinfo->sockaddr) ||
+		     fctx->timeouts >= (MAX_EDNS0_TIMEOUTS * 2)) &&
+		    (query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
+			query->options |= DNS_FETCHOPT_NOEDNS0;
+			FCTXTRACE("too many timeouts, disabling EDNS0");
+		} else if ((triededns(fctx, &query->addrinfo->sockaddr) ||
+			    fctx->timeouts >= MAX_EDNS0_TIMEOUTS) &&
+			   (query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
+			query->options |= DNS_FETCHOPT_EDNS512;
+			FCTXTRACE("too many timeouts, setting EDNS size to 512");
+		}
+		fctx->timeout = ISC_FALSE;
 	}
 
 	if ((query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
@@ -1672,6 +1829,7 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 	isc_socketevent_t *sevent = (isc_socketevent_t *)event;
 	resquery_t *query = event->ev_arg;
 	isc_boolean_t retry = ISC_FALSE;
+	isc_interval_t interval;
 	isc_result_t result;
 	unsigned int attrs;
 	fetchctx_t *fctx;
@@ -1704,6 +1862,20 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 	} else {
 		switch (sevent->result) {
 		case ISC_R_SUCCESS:
+
+			/*
+			 * Extend the idle timer for TCP.  20 seconds
+			 * should be long enough for a TCP connection to be
+			 * established, a single DNS request to be sent,
+			 * and the response received.
+			 */
+			isc_interval_set(&interval, 20, 0);
+			result = fctx_startidletimer(query->fctx, &interval);
+			if (result != ISC_R_SUCCESS) {
+				fctx_cancelquery(&query, NULL, NULL, ISC_FALSE);
+				fctx_done(fctx, result, __LINE__);
+				break;
+			}
 			/*
 			 * We are connected.  Create a dispatcher and
 			 * send the query.
@@ -1736,9 +1908,8 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 				result = resquery_send(query);
 
 			if (result != ISC_R_SUCCESS) {
-				fctx_cancelquery(&query, NULL, NULL,
-						 ISC_FALSE);
-				fctx_done(fctx, result);
+				fctx_cancelquery(&query, NULL, NULL, ISC_FALSE);
+				fctx_done(fctx, result, __LINE__);
 			}
 			break;
 
@@ -1773,7 +1944,7 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 		fctx->attributes &= ~FCTX_ATTR_ADDRWAIT;
 		result = fctx_stopidletimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else
 			fctx_try(fctx);
 	}
@@ -1809,13 +1980,16 @@ fctx_finddone(isc_task_t *task, isc_event_t *event) {
 		fctx->attributes &= ~FCTX_ATTR_ADDRWAIT;
 		if (event->ev_type == DNS_EVENT_ADBMOREADDRESSES)
 			want_try = ISC_TRUE;
-		else if (fctx->pending == 0) {
-			/*
-			 * We've got nothing else to wait for and don't
-			 * know the answer.  There's nothing to do but
-			 * fail the fctx.
-			 */
-			want_done = ISC_TRUE;
+		else {
+			fctx->findfail++;
+			if (fctx->pending == 0) {
+				/*
+				 * We've got nothing else to wait for and don't
+				 * know the answer.  There's nothing to do but
+				 * fail the fctx.
+				 */
+				want_done = ISC_TRUE;
+			}
 		}
 	} else if (SHUTTINGDOWN(fctx) && fctx->pending == 0 &&
 		   fctx->nqueries == 0 && ISC_LIST_EMPTY(fctx->validators)) {
@@ -1836,7 +2010,7 @@ fctx_finddone(isc_task_t *task, isc_event_t *event) {
 	if (want_try)
 		fctx_try(fctx);
 	else if (want_done)
-		fctx_done(fctx, ISC_R_FAILURE);
+		fctx_done(fctx, ISC_R_FAILURE, __LINE__);
 	else if (bucket_empty)
 		empty_bucket(res);
 }
@@ -1924,7 +2098,9 @@ mark_bad(fetchctx_t *fctx) {
 }
 
 static void
-add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_result_t reason) {
+add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_result_t reason,
+	badnstype_t badtype)
+{
 	char namebuf[DNS_NAME_FORMATSIZE];
 	char addrbuf[ISC_SOCKADDR_FORMATSIZE];
 	char classbuf[64];
@@ -1935,6 +2111,21 @@ add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_result_t reason) {
 	const char *sep1, *sep2;
 	isc_sockaddr_t *address = &addrinfo->sockaddr;
 
+	if (reason == DNS_R_LAME)
+		fctx->lamecount++;
+	else {
+		switch (badtype) {
+		case badns_unreachable:
+			fctx->neterr++;
+			break;
+		case badns_response:
+			fctx->badresp++;
+			break;
+		case badns_validation:
+			break;	/* counted as 'valfail' */
+		}
+	}
+
 	if (bad_server(fctx, address)) {
 		/*
 		 * We already know this server is bad.
@@ -2103,6 +2294,7 @@ findname(fetchctx_t *fctx, dns_name_t *name, in_port_t port,
 			 * XXXRTH  Follow the CNAME/DNAME chain?
 			 */
 			dns_adb_destroyfind(&find);
+			fctx->adberr++;
 		}
 	} else if (!ISC_LIST_EMPTY(find->list)) {
 		/*
@@ -2147,6 +2339,11 @@ findname(fetchctx_t *fctx, dns_name_t *name, in_port_t port,
 			      find->result_v4 != DNS_R_NXDOMAIN)))
 				*need_alternate = ISC_TRUE;
 		} else {
+			if ((find->options & DNS_ADBFIND_LAMEPRUNED) != 0)
+				fctx->lamecount++; /* cached lame server */
+			else
+				fctx->adberr++; /* unreachable server, etc. */
+
 			/*
 			 * If we know there are no addresses for
 			 * the family we are using then try to add
@@ -2163,6 +2360,16 @@ findname(fetchctx_t *fctx, dns_name_t *name, in_port_t port,
 	}
 }
 
+static isc_boolean_t
+isstrictsubdomain(dns_name_t *name1, dns_name_t *name2) {
+	int order;
+	unsigned int nlabels;
+	dns_namereln_t namereln;
+
+	namereln = dns_name_fullcompare(name1, name2, &order, &nlabels);
+	return (ISC_TF(namereln == dns_namereln_subdomain));
+}
+
 static isc_result_t
 fctx_getaddresses(fetchctx_t *fctx) {
 	dns_rdata_t rdata = DNS_RDATA_INIT;
@@ -2208,23 +2415,40 @@ fctx_getaddresses(fetchctx_t *fctx) {
 		dns_name_t *name = &fctx->name;
 		dns_name_t suffix;
 		unsigned int labels;
+		dns_fixedname_t fixed;
+		dns_name_t *domain;
 
 		/*
 		 * DS records are found in the parent server.
 		 * Strip label to get the correct forwarder (if any).
 		 */
-		if (fctx->type == dns_rdatatype_ds &&
+		if (dns_rdatatype_atparent(fctx->type) &&
 		    dns_name_countlabels(name) > 1) {
 			dns_name_init(&suffix, NULL);
 			labels = dns_name_countlabels(name);
 			dns_name_getlabelsequence(name, 1, labels - 1, &suffix);
 			name = &suffix;
 		}
-		result = dns_fwdtable_find(fctx->res->view->fwdtable, name,
-					   &forwarders);
+
+		dns_fixedname_init(&fixed);
+		domain = dns_fixedname_name(&fixed);
+		result = dns_fwdtable_find2(fctx->res->view->fwdtable, name,
+					    domain, &forwarders);
 		if (result == ISC_R_SUCCESS) {
 			sa = ISC_LIST_HEAD(forwarders->addrs);
 			fctx->fwdpolicy = forwarders->fwdpolicy;
+			if (fctx->fwdpolicy == dns_fwdpolicy_only &&
+			    isstrictsubdomain(domain, &fctx->domain)) {
+				isc_mem_t *mctx;
+
+				mctx = res->buckets[fctx->bucketnum].mctx;
+				dns_name_free(&fctx->domain, mctx);
+				dns_name_init(&fctx->domain, NULL);
+				result = dns_name_dup(domain, mctx,
+						      &fctx->domain);
+				if (result != ISC_R_SUCCESS)
+					return (result);
+			}
 		}
 	}
 
@@ -2623,7 +2847,7 @@ fctx_try(fetchctx_t *fctx) {
 			/*
 			 * Something bad happened.
 			 */
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 			return;
 		}
 
@@ -2633,14 +2857,14 @@ fctx_try(fetchctx_t *fctx) {
 		 * might be bad ones.  In this case, return SERVFAIL.
 		 */
 		if (addrinfo == NULL) {
-			fctx_done(fctx, DNS_R_SERVFAIL);
+			fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 			return;
 		}
 	}
 
 	result = fctx_query(fctx, addrinfo, fctx->options);
 	if (result != ISC_R_SUCCESS)
-		fctx_done(fctx, result);
+		fctx_done(fctx, result, __LINE__);
 }
 
 static isc_boolean_t
@@ -2739,11 +2963,12 @@ fctx_timeout(isc_task_t *task, isc_event_t *event) {
 	FCTXTRACE("timeout");
 
 	if (event->ev_type == ISC_TIMEREVENT_LIFE) {
-		fctx_done(fctx, ISC_R_TIMEDOUT);
+		fctx_done(fctx, ISC_R_TIMEDOUT, __LINE__);
 	} else {
 		isc_result_t result;
 
 		fctx->timeouts++;
+		fctx->timeout = ISC_TRUE;
 		/*
 		 * We could cancel the running queries here, or we could let
 		 * them keep going.  Since we normally use separate sockets for
@@ -2765,7 +2990,7 @@ fctx_timeout(isc_task_t *task, isc_event_t *event) {
 		 */
 		result = fctx_starttimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else
 			/*
 			 * Keep trying.
@@ -2860,7 +3085,7 @@ fctx_doshutdown(isc_task_t *task, isc_event_t *event) {
 
 	if (fctx->state != fetchstate_done) {
 		fctx->state = fetchstate_done;
-		fctx_sendevents(fctx, ISC_R_CANCELED);
+		fctx_sendevents(fctx, ISC_R_CANCELED, __LINE__);
 	}
 
 	if (fctx->references == 0 && fctx->pending == 0 &&
@@ -2899,7 +3124,7 @@ fctx_start(isc_task_t *task, isc_event_t *event) {
 		 */
 		fctx->attributes |= FCTX_ATTR_SHUTTINGDOWN;
 		fctx->state = fetchstate_done;
-		fctx_sendevents(fctx, ISC_R_CANCELED);
+		fctx_sendevents(fctx, ISC_R_CANCELED, __LINE__);
 		/*
 		 * Since we haven't started, we INSIST that we have no
 		 * pending ADB finds and no pending validations.
@@ -2938,7 +3163,7 @@ fctx_start(isc_task_t *task, isc_event_t *event) {
 		 */
 		result = fctx_starttimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else
 			fctx_try(fctx);
 	} else if (bucket_empty)
@@ -3070,10 +3295,24 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type,
 	fctx->altfind = NULL;
 	fctx->pending = 0;
 	fctx->restarts = 0;
+	fctx->querysent = 0;
+	fctx->referrals = 0;
+	TIME_NOW(&fctx->start);
 	fctx->timeouts = 0;
+	fctx->lamecount = 0;
+	fctx->adberr = 0;
+	fctx->neterr = 0;
+	fctx->badresp = 0;
+	fctx->findfail = 0;
+	fctx->valfail = 0;
+	fctx->result = ISC_R_FAILURE;
+	fctx->vresult = ISC_R_SUCCESS;
+	fctx->exitline = -1;	/* sentinel */
+	fctx->logged = ISC_FALSE;
 	fctx->attributes = 0;
 	fctx->spilled = ISC_FALSE;
 	fctx->nqueries = 0;
+	fctx->timeout = ISC_FALSE;
 
 	dns_name_init(&fctx->nsname, NULL);
 	fctx->nsfetch = NULL;
@@ -3082,21 +3321,22 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type,
 	if (domain == NULL) {
 		dns_forwarders_t *forwarders = NULL;
 		unsigned int labels;
+		dns_name_t *fwdname = name;
 
 		/*
 		 * DS records are found in the parent server.
 		 * Strip label to get the correct forwarder (if any).
 		 */
-		if (fctx->type == dns_rdatatype_ds &&
+		if (dns_rdatatype_atparent(fctx->type) &&
 		    dns_name_countlabels(name) > 1) {
 			dns_name_init(&suffix, NULL);
 			labels = dns_name_countlabels(name);
 			dns_name_getlabelsequence(name, 1, labels - 1, &suffix);
-			name = &suffix;
+			fwdname = &suffix;
 		}
 		dns_fixedname_init(&fixed);
 		domain = dns_fixedname_name(&fixed);
-		result = dns_fwdtable_find2(fctx->res->view->fwdtable, name,
+		result = dns_fwdtable_find2(fctx->res->view->fwdtable, fwdname,
 					    domain, &forwarders);
 		if (result == ISC_R_SUCCESS)
 			fctx->fwdpolicy = forwarders->fwdpolicy;
@@ -3107,7 +3347,7 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type,
 			 * nameservers, and we're not in forward-only mode,
 			 * so find the best nameservers to use.
 			 */
-			if (dns_rdatatype_atparent(type))
+			if (dns_rdatatype_atparent(fctx->type))
 				findoptions |= DNS_DBFIND_NOEXACT;
 			result = dns_view_findzonecut(res->view, name, domain,
 						      0, findoptions, ISC_TRUE,
@@ -3543,6 +3783,8 @@ validated(isc_task_t *task, isc_event_t *event) {
 
 	if (vevent->result != ISC_R_SUCCESS) {
 		FCTXTRACE("validation failed");
+		fctx->valfail++;
+		fctx->vresult = vevent->result;
 		result = ISC_R_NOTFOUND;
 		if (vevent->rdataset != NULL)
 			result = dns_db_findnode(fctx->cache, vevent->name,
@@ -3557,7 +3799,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 		if (result == ISC_R_SUCCESS)
 			dns_db_detachnode(fctx->cache, &node);
 		result = vevent->result;
-		add_bad(fctx, addrinfo, result);
+		add_bad(fctx, addrinfo, result, badns_validation);
 		isc_event_free(&event);
 		UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 		INSIST(fctx->validator == NULL);
@@ -3565,7 +3807,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 		if (fctx->validator != NULL) {
 			dns_validator_send(fctx->validator);
 		} else if (sentresponse)
-			fctx_done(fctx, result);	/* Locks bucket. */
+			fctx_done(fctx, result, __LINE__); /* Locks bucket. */
 		else
 			fctx_try(fctx);			/* Locks bucket. */
 		return;
@@ -3590,7 +3832,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 		/*
 		 * If we are asking for a SOA record set the cache time
 		 * to zero to facilitate locating the containing zone of
-		 * a arbitary zone.
+		 * a arbitrary zone.
 		 */
 		ttl = fctx->res->view->maxncachettl;
 		if (fctx->type == dns_rdatatype_soa &&
@@ -3744,7 +3986,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 
 	UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 
-	fctx_done(fctx, result);	/* Locks bucket. */
+	fctx_done(fctx, result, __LINE__); /* Locks bucket. */
 
  cleanup_event:
 	INSIST(node == NULL);
@@ -3883,11 +4125,19 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
 			rdataset->ttl = res->view->maxcachettl;
 
 		/*
-		 * If this rrset is in a secure domain, do DNSSEC validation
-		 * for it, unless it is glue.
+		 * If this RRset is in a secure domain, is in bailiwick,
+		 * and is not glue, attempt DNSSEC validation.	(We do not
+		 * attempt to validate glue or out-of-bailiwick data--even
+		 * though there might be some performance benefit to doing
+		 * so--because it makes it simpler and safer to ensure that
+		 * records from a secure domain are only cached if validated
+		 * within the context of a query to the domain that owns
+		 * them.)
 		 */
-		if (secure_domain && rdataset->trust != dns_trust_glue) {
+		if (secure_domain && rdataset->trust != dns_trust_glue &&
+		    !EXTERNAL(rdataset)) {
 			dns_trust_t trust;
+
 			/*
 			 * RRSIGs are validated as part of validating the
 			 * type they cover.
@@ -3924,22 +4174,6 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
 			}
 
 			/*
-			 * Reject out of bailiwick additional records
-			 * without RRSIGs as they can't possibly validate
-			 * as "secure" and as we will never never want to
-			 * store these as "answers" after validation.
-			 */
-			if (rdataset->trust == dns_trust_additional &&
-			    sigrdataset == NULL && EXTERNAL(rdataset))
-				continue;
- 
-			/*
-			 * XXXMPA: If we store as "answer" after validating
-			 * then we need to do bailiwick processing and
-			 * also need to track whether RRsets are in or
-			 * out of bailiwick.  This will require a another
-			 * pending trust level.
-			 *
 			 * Cache this rdataset/sigrdataset pair as
 			 * pending data.  Track whether it was additional
 			 * or not.
@@ -3948,57 +4182,57 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
 				trust = dns_trust_pending_additional;
 			else
 				trust = dns_trust_pending_answer;
- 
+
 			rdataset->trust = trust;
 			if (sigrdataset != NULL)
 				sigrdataset->trust = trust;
-			if (!need_validation)
+			if (!need_validation || !ANSWER(rdataset)) {
 				addedrdataset = ardataset;
-			else
-				addedrdataset = NULL;
-			result = dns_db_addrdataset(fctx->cache, node, NULL,
-						    now, rdataset, 0,
-						    addedrdataset);
-			if (result == DNS_R_UNCHANGED) {
-				result = ISC_R_SUCCESS;
-				if (!need_validation &&
-				    ardataset != NULL &&
-				    ardataset->type == 0) {
-					/*
-					 * The answer in the cache is better
-					 * than the answer we found, and is
-					 * a negative cache entry, so we
-					 * must set eresult appropriately.
-					 */
-					if (NXDOMAIN(ardataset))
-						eresult = DNS_R_NCACHENXDOMAIN;
-					else
-						eresult = DNS_R_NCACHENXRRSET;
-					/*
-					 * We have a negative response from
-					 * the cache so don't attempt to
-					 * add the RRSIG rrset.
-					 */
-					continue;
-				}
-			}
-			if (result != ISC_R_SUCCESS)
-				break;
-			if (sigrdataset != NULL) {
-				if (!need_validation)
-					addedrdataset = asigrdataset;
-				else
-					addedrdataset = NULL;
-				result = dns_db_addrdataset(fctx->cache,
-							    node, NULL, now,
-							    sigrdataset, 0,
-							    addedrdataset);
-				if (result == DNS_R_UNCHANGED)
+				result = dns_db_addrdataset(fctx->cache, node,
+							    NULL, now, rdataset,
+							    0, addedrdataset);
+				if (result == DNS_R_UNCHANGED) {
 					result = ISC_R_SUCCESS;
+					if (!need_validation &&
+					    ardataset != NULL &&
+					    ardataset->type == 0) {
+						/*
+						 * The answer in the cache is
+						 * better than the answer we
+						 * found, and is a negative
+						 * cache entry, so we must set
+						 * eresult appropriately.
+						 */
+						if (NXDOMAIN(ardataset))
+							eresult =
+							   DNS_R_NCACHENXDOMAIN;
+						else
+							eresult =
+							   DNS_R_NCACHENXRRSET;
+						/*
+						 * We have a negative response
+						 * from the cache so don't
+						 * attempt to add the RRSIG
+						 * rrset.
+						 */
+						continue;
+					}
+				}
 				if (result != ISC_R_SUCCESS)
 					break;
-			} else if (!ANSWER(rdataset))
-				continue;
+				if (sigrdataset != NULL) {
+					addedrdataset = asigrdataset;
+					result = dns_db_addrdataset(fctx->cache,
+								node, NULL, now,
+								sigrdataset, 0,
+								addedrdataset);
+					if (result == DNS_R_UNCHANGED)
+						result = ISC_R_SUCCESS;
+					if (result != ISC_R_SUCCESS)
+						break;
+				} else if (!ANSWER(rdataset))
+					continue;
+			}
 
 			if (ANSWER(rdataset) && need_validation) {
 				if (fctx->type != dns_rdatatype_any &&
@@ -4034,7 +4268,7 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
 					 * Defer any further validations.
 					 * This prevents multiple validators
 					 * from manipulating fctx->rmessage
-					 * simultaniously.
+					 * simultaneously.
 					 */
 					valoptions |= DNS_VALIDATOR_DEFER;
 				}
@@ -4350,11 +4584,12 @@ ncache_message(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
 	/*
 	 * If we are asking for a SOA record set the cache time
 	 * to zero to facilitate locating the containing zone of
-	 * a arbitary zone.
+	 * a arbitrary zone.
 	 */
 	ttl = fctx->res->view->maxncachettl;
 	if (fctx->type == dns_rdatatype_soa &&
-	    covers == dns_rdatatype_any)
+	    covers == dns_rdatatype_any &&
+	    fctx->res->zero_no_soa_ttl)
 		ttl = 0;
 
 	result = ncache_adderesult(fctx->rmessage, fctx->cache, node,
@@ -5047,9 +5282,7 @@ answer_response(fetchctx_t *fctx) {
 						/*
 						 * This data is outside of
 						 * our query domain, and
-						 * may only be cached if it
-						 * comes from a secure zone
-						 * and validates.
+						 * may not be cached.
 						 */
 						rdataset->attributes |=
 						    DNS_RDATASETATTR_EXTERNAL;
@@ -5180,7 +5413,7 @@ answer_response(fetchctx_t *fctx) {
 					 */
 					if (found_dname) {
 						/*
-						 * Copy the the dname into the
+						 * Copy the dname into the
 						 * qname fixed name.
 						 *
 						 * Although we check for
@@ -5334,7 +5567,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 	bucketnum = fctx->bucketnum;
 	if (fevent->result == ISC_R_CANCELED) {
 		dns_resolver_destroyfetch(&fctx->nsfetch);
-		fctx_done(fctx, ISC_R_CANCELED);
+		fctx_done(fctx, ISC_R_CANCELED, __LINE__);
 	} else if (fevent->result == ISC_R_SUCCESS) {
 
 		FCTXTRACE("resuming DS lookup");
@@ -5350,7 +5583,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 				      fctx->res->buckets[bucketnum].mctx,
 				      &fctx->domain);
 		if (result != ISC_R_SUCCESS) {
-			fctx_done(fctx, DNS_R_SERVFAIL);
+			fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 			goto cleanup;
 		}
 		/*
@@ -5368,7 +5601,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 		domain = dns_fixedname_name(&fixed);
 		dns_name_copy(&fctx->nsfetch->private->domain, domain, NULL);
 		if (dns_name_equal(&fctx->nsname, domain)) {
-			fctx_done(fctx, DNS_R_SERVFAIL);
+			fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 			dns_resolver_destroyfetch(&fctx->nsfetch);
 			goto cleanup;
 		}
@@ -5395,7 +5628,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 						  &fctx->nsrrset, NULL,
 						  &fctx->nsfetch);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else {
 			LOCK(&res->buckets[bucketnum].lock);
 			locked = ISC_TRUE;
@@ -5516,6 +5749,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 	unsigned int options;
 	unsigned int findoptions;
 	isc_result_t broken_server;
+	badnstype_t broken_type = badns_response;
 
 	REQUIRE(VALID_QUERY(query));
 	fctx = query->fctx;
@@ -5540,6 +5774,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 	}
 
 	fctx->timeouts = 0;
+	fctx->timeout = ISC_FALSE;
 
 	/*
 	 * XXXRTH  We should really get the current time just once.  We
@@ -5587,6 +5822,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			     devent->result == ISC_R_CONNREFUSED ||
 			     devent->result == ISC_R_CANCELED)) {
 				    broken_server = devent->result;
+				    broken_type = badns_unreachable;
 			}
 		}
 		goto done;
@@ -5951,6 +6187,18 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			 * has not experienced any restarts yet.
 			 */
 			fctx->restarts = 0;
+
+			/*
+			 * Update local statistics counters collected for each
+			 * new zone.
+			 */
+			fctx->referrals++;
+			fctx->querysent = 0;
+			fctx->lamecount = 0;
+			fctx->neterr = 0;
+			fctx->badresp = 0;
+			fctx->adberr = 0;
+
 			result = ISC_R_SUCCESS;
 		} else if (result != ISC_R_SUCCESS) {
 			/*
@@ -6024,7 +6272,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			 * Add this server to the list of bad servers for
 			 * this fctx.
 			 */
-			add_bad(fctx, addrinfo, broken_server);
+			add_bad(fctx, addrinfo, broken_server, broken_type);
 		}
 
 		if (get_nameservers) {
@@ -6032,7 +6280,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			dns_fixedname_init(&foundname);
 			fname = dns_fixedname_name(&foundname);
 			if (result != ISC_R_SUCCESS) {
-				fctx_done(fctx, DNS_R_SERVFAIL);
+				fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 				return;
 			}
 			findoptions = 0;
@@ -6050,7 +6298,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 						      NULL);
 			if (result != ISC_R_SUCCESS) {
 				FCTXTRACE("couldn't find a zonecut");
-				fctx_done(fctx, DNS_R_SERVFAIL);
+				fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 				return;
 			}
 			if (!dns_name_issubdomain(fname, &fctx->domain)) {
@@ -6059,7 +6307,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 				 * QDOMAIN.
 				 */
 				FCTXTRACE("nameservers now above QDOMAIN");
-				fctx_done(fctx, DNS_R_SERVFAIL);
+				fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 				return;
 			}
 			dns_name_free(&fctx->domain,
@@ -6069,7 +6317,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 					      fctx->res->buckets[fctx->bucketnum].mctx,
 					      &fctx->domain);
 			if (result != ISC_R_SUCCESS) {
-				fctx_done(fctx, DNS_R_SERVFAIL);
+				fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 				return;
 			}
 			fctx_cancelqueries(fctx, ISC_TRUE);
@@ -6089,7 +6337,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 		FCTXTRACE("resend");
 		result = fctx_query(fctx, addrinfo, options);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 	} else if (result == ISC_R_SUCCESS && !HAVE_ANSWER(fctx)) {
 		/*
 		 * All has gone well so far, but we are waiting for the
@@ -6103,10 +6351,10 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 		 */
 		result = fctx_stopidletimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 	} else if (result == DNS_R_CHASEDSSERVERS) {
 		unsigned int n;
-		add_bad(fctx, addrinfo, result);
+		add_bad(fctx, addrinfo, result, broken_type);
 		fctx_cancelqueries(fctx, ISC_TRUE);
 		fctx_cleanupfinds(fctx);
 		fctx_cleanupforwaddrs(fctx);
@@ -6123,18 +6371,18 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 						  &fctx->nsrrset, NULL,
 						  &fctx->nsfetch);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		LOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 		fctx->references++;
 		UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 		result = fctx_stopidletimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 	} else {
 		/*
 		 * We're done.
 		 */
-		fctx_done(fctx, result);
+		fctx_done(fctx, result, __LINE__);
 	}
 }
 
@@ -6996,6 +7244,47 @@ dns_resolver_destroyfetch(dns_fetch_t **fetchp) {
 		empty_bucket(res);
 }
 
+void
+dns_resolver_logfetch(dns_fetch_t *fetch, isc_log_t *lctx,
+		      isc_logcategory_t *category, isc_logmodule_t *module,
+		      int level, isc_boolean_t duplicateok)
+{
+	fetchctx_t *fctx;
+	dns_resolver_t *res;
+	char domainbuf[DNS_NAME_FORMATSIZE];
+
+	REQUIRE(DNS_FETCH_VALID(fetch));
+	fctx = fetch->private;
+	REQUIRE(VALID_FCTX(fctx));
+	res = fctx->res;
+
+	LOCK(&res->buckets[fctx->bucketnum].lock);
+
+	INSIST(fctx->exitline >= 0);
+	if (!fctx->logged || duplicateok) {
+		dns_name_format(&fctx->domain, domainbuf, sizeof(domainbuf));
+		isc_log_write(lctx, category, module, level,
+			      "fetch completed at %s:%d for %s in "
+			      "%" ISC_PRINT_QUADFORMAT "u."
+			      "%06" ISC_PRINT_QUADFORMAT "u: %s/%s "
+			      "[domain:%s,referral:%u,restart:%u,qrysent:%u,"
+			      "timeout:%u,lame:%u,neterr:%u,badresp:%u,"
+			      "adberr:%u,findfail:%u,valfail:%u]",
+			      __FILE__, fctx->exitline, fctx->info,
+			      fctx->duration / 1000000,
+			      fctx->duration % 1000000,
+			      isc_result_totext(fctx->result),
+			      isc_result_totext(fctx->vresult), domainbuf,
+			      fctx->referrals, fctx->restarts,
+			      fctx->querysent, fctx->timeouts, fctx->lamecount,
+			      fctx->neterr, fctx->badresp, fctx->adberr,
+			      fctx->findfail, fctx->valfail);
+		fctx->logged = ISC_TRUE;
+	}
+
+	UNLOCK(&res->buckets[fctx->bucketnum].lock);
+}
+
 dns_dispatchmgr_t *
 dns_resolver_dispatchmgr(dns_resolver_t *resolver) {
 	REQUIRE(VALID_RESOLVER(resolver));
diff --git a/lib/dns/sdb.c b/lib/dns/sdb.c
index effb2bf0c293..972b72a985f8 100644
--- a/lib/dns/sdb.c
+++ b/lib/dns/sdb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdb.c,v 1.45.18.16 2008/01/17 23:45:58 tbox Exp $ */
+/* $Id: sdb.c,v 1.45.18.19 2009/06/26 06:25:20 marka Exp $ */
 
 /*! \file */
 
@@ -880,9 +880,12 @@ find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 				{
 					result = DNS_R_ZONECUT;
 					dns_rdataset_disassociate(rdataset);
-					if (sigrdataset != NULL)
+					if (sigrdataset != NULL &&
+					    dns_rdataset_isassociated
+							(sigrdataset)) {
 						dns_rdataset_disassociate
 								(sigrdataset);
+					}
 				} else
 					result = DNS_R_DELEGATION;
 				break;
@@ -1442,9 +1445,11 @@ dbiterator_seek(dns_dbiterator_t *iterator, dns_name_t *name) {
 	sdb_dbiterator_t *sdbiter = (sdb_dbiterator_t *)iterator;
 
 	sdbiter->current = ISC_LIST_HEAD(sdbiter->nodelist);
-	while (sdbiter->current != NULL)
+	while (sdbiter->current != NULL) {
 		if (dns_name_equal(sdbiter->current->name, name))
 			return (ISC_R_SUCCESS);
+		sdbiter->current = ISC_LIST_NEXT(sdbiter->current, link);
+	}
 	return (ISC_R_NOTFOUND);
 }
 
diff --git a/lib/dns/sdlz.c b/lib/dns/sdlz.c
index b91f8259e7bd..6c9a521b05f2 100644
--- a/lib/dns/sdlz.c
+++ b/lib/dns/sdlz.c
@@ -1,5 +1,5 @@
 /*
- * Portions Copyright (C) 2005-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -50,7 +50,7 @@
  * USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdlz.c,v 1.2.2.11 2007/08/28 07:20:05 tbox Exp $ */
+/* $Id: sdlz.c,v 1.2.2.14 2009/06/26 06:25:20 marka Exp $ */
 
 /*! \file */
 
@@ -841,9 +841,12 @@ find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 				{
 					result = DNS_R_ZONECUT;
 					dns_rdataset_disassociate(rdataset);
-					if (sigrdataset != NULL)
+					if (sigrdataset != NULL &&
+					    dns_rdataset_isassociated
+							(sigrdataset)) {
 						dns_rdataset_disassociate
 							(sigrdataset);
+					}
 				} else
 					result = DNS_R_DELEGATION;
 				break;
@@ -1103,9 +1106,11 @@ dbiterator_seek(dns_dbiterator_t *iterator, dns_name_t *name) {
 	sdlz_dbiterator_t *sdlziter = (sdlz_dbiterator_t *)iterator;
 
 	sdlziter->current = ISC_LIST_HEAD(sdlziter->nodelist);
-	while (sdlziter->current != NULL)
+	while (sdlziter->current != NULL) {
 		if (dns_name_equal(sdlziter->current->name, name))
 			return (ISC_R_SUCCESS);
+		sdlziter->current = ISC_LIST_NEXT(sdlziter->current, link);
+	}
 	return (ISC_R_NOTFOUND);
 }
 
@@ -1327,7 +1332,7 @@ dns_sdlzallowzonexfr(void *driverarg, void *dbdata, isc_mem_t *mctx,
 		return (result);
 	isc_buffer_putuint8(&b2, 0);
 
-        /* make sure strings are always lowercase */
+	/* make sure strings are always lowercase */
 	dns_sdlz_tolower(namestr);
 	dns_sdlz_tolower(clientstr);
 
@@ -1440,7 +1445,7 @@ dns_sdlzfindzone(void *driverarg, void *dbdata, isc_mem_t *mctx,
 		return (result);
 	isc_buffer_putuint8(&b, 0);
 
-        /* make sure strings are always lowercase */
+	/* make sure strings are always lowercase */
 	dns_sdlz_tolower(namestr);
 
 	/* Call SDLZ driver's find zone method */
@@ -1571,7 +1576,7 @@ dns_sdlz_putrr(dns_sdlzlookup_t *lookup, const char *type, dns_ttl_t ttl,
 	return (ISC_R_SUCCESS);
 
  failure:
- 	if (rdatabuf != NULL)
+	if (rdatabuf != NULL)
 		isc_buffer_free(&rdatabuf);
 	if (lex != NULL)
 		isc_lex_destroy(&lex);
diff --git a/lib/dns/time.c b/lib/dns/time.c
index b4e7bee78651..618ea69fa71c 100644
--- a/lib/dns/time.c
+++ b/lib/dns/time.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: time.c,v 1.26.18.3 2005/04/29 00:16:06 marka Exp $ */
+/* $Id: time.c,v 1.26.18.5 2009/01/19 23:46:15 tbox Exp $ */
 
 /*! \file */
 
@@ -145,7 +145,7 @@ dns_time64_fromtext(const char *source, isc_int64_t *target) {
 	RANGE(0, 60, second);		/* 60 == leap second. */
 
 	/*
-	 * Calulate seconds since epoch.
+	 * Calculate seconds since epoch.
 	 */
 	value = second + (60 * minute) + (3600 * hour) + ((day - 1) * 86400);
 	for (i = 0; i < (month - 1); i++)
diff --git a/lib/dns/validator.c b/lib/dns/validator.c
index 31098910bd6d..387c433f5450 100644
--- a/lib/dns/validator.c
+++ b/lib/dns/validator.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.c,v 1.119.18.41.2.2 2009/11/19 00:25:18 marka Exp $ */
+/* $Id: validator.c,v 1.119.18.51 2009/12/30 06:44:05 each Exp $ */
 
 /*! \file */
 
@@ -89,7 +89,7 @@
 #define VALID_VALIDATOR(v)		ISC_MAGIC_VALID(v, VALIDATOR_MAGIC)
 
 #define VALATTR_SHUTDOWN		0x0001	/*%< Shutting down. */
-#define VALATTR_CANCELED		0x0002	/*%< Cancelled. */
+#define VALATTR_CANCELED		0x0002	/*%< Canceled. */
 #define VALATTR_TRIEDVERIFY		0x0004  /*%< We have found a key and
 						 * have attempted a verify. */
 #define VALATTR_INSECURITY		0x0010	/*%< Attempting proveunsecure. */
@@ -1128,7 +1128,7 @@ get_dst_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo,
 }
 
 /*%
- * Get the key that genertated this signature.
+ * Get the key that generated this signature.
  */
 static isc_result_t
 get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
@@ -1141,7 +1141,7 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 	 * Is the signer name appropriate for this signature?
 	 *
 	 * The signer name must be at the same level as the owner name
-	 * or closer to the the DNS root.
+	 * or closer to the DNS root.
 	 */
 	namereln = dns_name_fullcompare(val->event->name, &siginfo->signer,
 					&order, &nlabels);
@@ -1163,6 +1163,23 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 		 */
 		if (dns_rdatatype_atparent(val->event->rdataset->type))
 			return (DNS_R_CONTINUE);
+	} else {
+		/*
+		 * SOA and NS RRsets can only be signed by a key with
+		 * the same name.
+		 */
+		if (val->event->rdataset->type == dns_rdatatype_soa ||
+		    val->event->rdataset->type == dns_rdatatype_ns) {
+			const char *typename;
+
+			if (val->event->rdataset->type == dns_rdatatype_soa)
+				typename = "SOA";
+			else
+				typename = "NS";
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "%s signer mismatch", typename);
+			return (DNS_R_CONTINUE);
+		}
 	}
 
 	/*
@@ -1620,6 +1637,7 @@ dlv_validatezonekey(dns_validator_t *val) {
 				break;
 		}
 		if (result != ISC_R_SUCCESS) {
+			dns_rdataset_disassociate(&trdataset);
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "no DNSKEY matching DLV");
 			continue;
@@ -1734,6 +1752,10 @@ validatezonekey(dns_validator_t *val) {
 					     &sigrdata);
 			result = dns_rdata_tostruct(&sigrdata, &sig, NULL);
 			RUNTIME_CHECK(result == ISC_R_SUCCESS);
+
+			if (!dns_name_equal(val->event->name, &sig.signer))
+				continue;
+
 			result = dns_keytable_findkeynode(val->keytable,
 							  val->event->name,
 							  sig.algorithm,
@@ -1957,6 +1979,7 @@ validatezonekey(dns_validator_t *val) {
 				break;
 		}
 		if (result != ISC_R_SUCCESS) {
+			dns_rdataset_disassociate(&trdataset);
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "no DNSKEY matching DS");
 			continue;
@@ -1974,7 +1997,11 @@ validatezonekey(dns_validator_t *val) {
 			if (ds.key_tag != sig.keyid ||
 			    ds.algorithm != sig.algorithm)
 				continue;
-
+			if (!dns_name_equal(val->event->name, &sig.signer)) {
+				validator_log(val, ISC_LOG_DEBUG(3),
+					      "DNSKEY signer mismatch");
+				continue;
+			}
 			dstkey = NULL;
 			result = dns_dnssec_keyfromrdata(val->event->name,
 							 &keyrdata,
@@ -2380,7 +2407,7 @@ dlvfetched(isc_task_t *task, isc_event_t *event) {
 }
 
 /*%
- * Start the DLV lookup proccess.
+ * Start the DLV lookup process.
  *
  * Returns
  * \li	ISC_R_SUCCESS
@@ -2424,7 +2451,7 @@ startfinddlvsep(dns_validator_t *val, dns_name_t *unsecure) {
 		validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", namebuf);
 		dlv_validator_start(val);
 		return (DNS_R_WAIT);
-	} 
+	}
 	validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found with no supported "
 		      "algorithms", namebuf);
 	markanswer(val);
@@ -2572,20 +2599,20 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 	if (val->havedlvsep)
 		dns_name_copy(dns_fixedname_name(&val->dlvsep), secroot, NULL);
 	else {
+		unsigned int labels;
 		dns_name_copy(val->event->name, secroot, NULL);
 		/*
 		 * If this is a response to a DS query, we need to look in
 		 * the parent zone for the trust anchor.
 		 */
-		if (val->event->type == dns_rdatatype_ds &&
-		    dns_name_countlabels(secroot) > 1U)
-			dns_name_split(secroot, 1, NULL, secroot);
+
+		labels = dns_name_countlabels(secroot);
+		if (val->event->type == dns_rdatatype_ds && labels > 1U)
+			dns_name_getlabelsequence(secroot, 1, labels - 1,
+						  secroot);
 		result = dns_keytable_finddeepestmatch(val->keytable,
 						       secroot, secroot);
-
 		if (result == ISC_R_NOTFOUND) {
-			validator_log(val, ISC_LOG_DEBUG(3),
-				      "not beneath secure root");
 			if (val->mustbesecure) {
 				validator_log(val, ISC_LOG_WARNING,
 					      "must be secure failure");
@@ -2808,7 +2835,7 @@ dlv_validator_start(dns_validator_t *val) {
 /*%
  * Start the validation process.
  *
- * Attempt to valididate the answer based on the category it appears to
+ * Attempt to validate the answer based on the category it appears to
  * fall in.
  * \li	1. secure positive answer.
  * \li	2. unsecure positive answer.
@@ -2829,7 +2856,7 @@ validator_start(isc_task_t *task, isc_event_t *event) {
 	vevent = (dns_validatorevent_t *)event;
 	val = vevent->validator;
 
-	/* If the validator has been cancelled, val->event == NULL */
+	/* If the validator has been canceled, val->event == NULL */
 	if (val->event == NULL)
 		return;
 
diff --git a/lib/dns/zone.c b/lib/dns/zone.c
index 36f303c375f8..62ad0fb5ac03 100644
--- a/lib/dns/zone.c
+++ b/lib/dns/zone.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,11 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zone.c,v 1.410.18.55 2008/10/24 01:43:17 tbox Exp $ */
+/* $Id: zone.c,v 1.410.18.61 2009/09/24 21:38:52 jinmei Exp $ */
 
 /*! \file */
 
 #include 
+#include 
 
 #include 
 #include 
@@ -29,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -287,7 +289,7 @@ struct dns_zone {
 						 * reload */
 #define DNS_ZONEFLG_NOMASTERS	0x00001000U	/*%< an attempt to refresh a
 						 * zone with no masters
-						 * occured */
+						 * occurred */
 #define DNS_ZONEFLG_LOADING	0x00002000U	/*%< load from disk in progress*/
 #define DNS_ZONEFLG_HAVETIMERS	0x00004000U	/*%< timer values have been set
 						 * from SOA (if not set, we
@@ -304,11 +306,15 @@ struct dns_zone {
 #define DNS_ZONEFLG_USEALTXFRSRC 0x00800000U
 #define DNS_ZONEFLG_SOABEFOREAXFR 0x01000000U
 #define DNS_ZONEFLG_NEEDCOMPACT 0x02000000U
+#define DNS_ZONEFLG_REFRESHING	0x04000000U	/*%< Refreshing keydata */
+#define DNS_ZONEFLG_THAW	0x08000000U
 
 #define DNS_ZONE_OPTION(z,o) (((z)->options & (o)) != 0)
 
 /* Flags for zone_load() */
 #define DNS_ZONELOADFLAG_NOSTAT	0x00000001U	/* Do not stat() master files */
+#define DNS_ZONELOADFLAG_THAW	0x00000002U	/* Thaw the zone on successful
+						   load. */
 
 struct dns_zonemgr {
 	unsigned int		magic;
@@ -1087,7 +1093,9 @@ zone_load(dns_zone_t *zone, unsigned int flags) {
 	INSIST(zone->type != dns_zone_none);
 
 	if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_LOADING)) {
-		result = ISC_R_SUCCESS;
+		if ((flags & DNS_ZONELOADFLAG_THAW) != 0)
+			DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_THAW);
+		result = DNS_R_CONTINUE;
 		goto cleanup;
 	}
 
@@ -1221,6 +1229,8 @@ zone_load(dns_zone_t *zone, unsigned int flags) {
 
 	if (result == DNS_R_CONTINUE) {
 		DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_LOADING);
+		if ((flags & DNS_ZONELOADFLAG_THAW) != 0)
+			DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_THAW);
 		goto cleanup;
 	}
 
@@ -1243,6 +1253,30 @@ dns_zone_loadnew(dns_zone_t *zone) {
 	return (zone_load(zone, DNS_ZONELOADFLAG_NOSTAT));
 }
 
+isc_result_t
+dns_zone_loadandthaw(dns_zone_t *zone) {
+	isc_result_t result;
+
+	result = zone_load(zone, DNS_ZONELOADFLAG_THAW);
+	switch (result) {
+	case DNS_R_CONTINUE:
+		/* Deferred thaw. */
+		break;
+	case ISC_R_SUCCESS:
+	case DNS_R_UPTODATE:
+	case DNS_R_SEENINCLUDE:
+		zone->update_disabled = ISC_FALSE;
+		break;
+	case DNS_R_NOMASTERFILE:
+		zone->update_disabled = ISC_FALSE;
+		break;
+	default:
+		/* Error, remain in disabled state. */
+		break;
+	}
+	return (result);
+}
+
 static void
 zone_gotreadhandle(isc_task_t *task, isc_event_t *event) {
 	dns_load_t *load = event->ev_arg;
@@ -2809,7 +2843,7 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone,
 		goto unlock;
 
 	/*
-	 * masters must countain count elements!
+	 * masters must contain count elements!
 	 */
 	new = isc_mem_get(zone->mctx, count * sizeof(*new));
 	if (new == NULL) {
@@ -4479,7 +4513,7 @@ refresh_callback(isc_task_t *task, isc_event_t *event) {
 			     "master %s (source %s)", (int)rb.used, rcode,
 			     master, source);
 		/*
-		 * Perhaps AXFR/IXFR is allowed even if SOA queries arn't.
+		 * Perhaps AXFR/IXFR is allowed even if SOA queries aren't.
 		 */
 		if (msg->rcode == dns_rcode_refused &&
 		    zone->type == dns_zone_slave)
@@ -6318,7 +6352,7 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) {
 
 	/*
 	 * The initial version of a slave zone is always dumped;
-	 * subsequent versions may be journalled instead if this
+	 * subsequent versions may be journaled instead if this
 	 * is enabled in the configuration.
 	 */
 	if (zone->db != NULL && zone->journal != NULL &&
@@ -6401,7 +6435,7 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) {
 			 * The in-memory database just changed, and
 			 * because 'dump' is set, it didn't change by
 			 * being loaded from disk.  Also, we have not
-			 * journalled diffs for this change.
+			 * journaled diffs for this change.
 			 * Therefore, the on-disk journal is missing
 			 * the deltas for this change.  Since it can
 			 * no longer be used to bring the zone
@@ -6411,7 +6445,17 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) {
 			isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL,
 				      DNS_LOGMODULE_ZONE, ISC_LOG_DEBUG(3),
 				      "removing journal file");
-			(void)remove(zone->journal);
+			if (remove(zone->journal) < 0 && errno != ENOENT) {
+				char strbuf[ISC_STRERRORSIZE];
+				isc__strerror(errno, strbuf, sizeof(strbuf));
+				isc_log_write(dns_lctx,
+					      DNS_LOGCATEGORY_GENERAL,
+					      DNS_LOGMODULE_ZONE,
+					      ISC_LOG_WARNING,
+					      "unable to remove journal "
+					      "'%s': '%s'",
+					      zone->journal, strbuf);
+			}
 		}
 	}
 
@@ -6526,7 +6570,6 @@ zone_xfrdone(dns_zone_t *zone, isc_result_t result) {
 				zone_unload(zone);
 				goto next_master;
 			}
-			zone->serial = serial;
 			zone->refresh = RANGE(refresh, zone->minrefresh,
 					      zone->maxrefresh);
 			zone->retry = RANGE(retry, zone->minretry,
@@ -6564,11 +6607,11 @@ zone_xfrdone(dns_zone_t *zone, isc_result_t result) {
 				buf[0] = '\0';
 			dns_zone_log(zone, ISC_LOG_INFO,
 				     "transferred serial %u%s",
-				     zone->serial, buf);
+				     serial, buf);
 		}
 
 		/*
-		 * This is not neccessary if we just performed a AXFR
+		 * This is not necessary if we just performed a AXFR
 		 * however it is necessary for an IXFR / UPTODATE and
 		 * won't hurt with an AXFR.
 		 */
@@ -6712,6 +6755,13 @@ zone_loaddone(void *arg, isc_result_t result) {
 	(void)zone_postload(load->zone, load->db, load->loadtime, result);
 	zonemgr_putio(&load->zone->readio);
 	DNS_ZONE_CLRFLAG(load->zone, DNS_ZONEFLG_LOADING);
+	/*
+	 * Leave the zone frozen if the reload fails.
+	 */
+	if ((result == ISC_R_SUCCESS || result == DNS_R_SEENINCLUDE) &&
+	     DNS_ZONE_FLAG(load->zone, DNS_ZONEFLG_THAW))
+		zone->update_disabled = ISC_FALSE;
+	DNS_ZONE_CLRFLAG(load->zone, DNS_ZONEFLG_THAW);
 	UNLOCK_ZONE(load->zone);
 
 	load->magic = 0;
@@ -7735,7 +7785,7 @@ zone_saveunique(dns_zone_t *zone, const char *path, const char *templat) {
 }
 
 #if 0
-/* Hook for ondestroy notifcation from a database. */
+/* Hook for ondestroy notification from a database. */
 
 static void
 dns_zonemgr_dbdestroyed(isc_task_t *task, isc_event_t *event) {
diff --git a/lib/isc/Makefile.in b/lib/isc/Makefile.in
index 82afe5fc6b97..39e260434401 100644
--- a/lib/isc/Makefile.in
+++ b/lib/isc/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.81.18.10 2008/06/24 23:45:55 tbox Exp $
+# $Id: Makefile.in,v 1.81.18.11 2008/12/01 04:02:15 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -54,7 +54,7 @@ OBJS =		@ISC_EXTRA_OBJS@ \
 		assertions.@O@ base64.@O@ bitstring.@O@ buffer.@O@ \
 		bufferlist.@O@ commandline.@O@ error.@O@ event.@O@ \
 		hash.@O@ heap.@O@ hex.@O@ hmacmd5.@O@ hmacsha.@O@\
-		lex.@O@ lfsr.@O@ lib.@O@ log.@O@ md5.@O@ \
+		inet_aton.@O@ lex.@O@ lfsr.@O@ lib.@O@ log.@O@ md5.@O@ \
 		mem.@O@ mutexblock.@O@ netaddr.@O@ netscope.@O@ ondestroy.@O@ \
 		parseint.@O@ portset.@O@ quota.@O@ random.@O@ \
 		ratelimiter.@O@ refcount.@O@ region.@O@ result.@O@ rwlock.@O@ \
@@ -67,7 +67,7 @@ SRCS =		@ISC_EXTRA_SRCS@ \
 		assertions.c base64.c bitstring.c buffer.c \
 		bufferlist.c commandline.c error.c event.c \
 		heap.c hex.c hmacmd5.c hmacsha.c \
-		lex.c lfsr.c lib.c log.c \
+		inet_aton.c lex.c lfsr.c lib.c log.c \
 		md5.c mem.c mutexblock.c netaddr.c netscope.c ondestroy.c \
 		parseint.c portset.c quota.c random.c \
 		ratelimiter.c refcount.c region.c result.c rwlock.c \
diff --git a/lib/isc/alpha/include/isc/atomic.h b/lib/isc/alpha/include/isc/atomic.h
index a4b9b15a02ea..380a49fa0586 100644
--- a/lib/isc/alpha/include/isc/atomic.h
+++ b/lib/isc/alpha/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.2.2.2 2005/06/16 22:01:01 jinmei Exp $ */
+/* $Id: atomic.h,v 1.2.2.4 2009/04/08 06:46:30 tbox Exp $ */
 
 /*
  * This code was written based on FreeBSD's kernel source whose copyright
@@ -62,16 +62,20 @@
 
 /*
  * This routine atomically increments the value stored in 'p' by 'val', and
- * returns the previous value.
+ * returns the previous value.  Memory access ordering around this function
+ * can be critical, so we add explicit memory block instructions at the
+ * beginning and the end of it (same for other functions).
  */
-static inline isc_int32_t 
+static inline isc_int32_t
 isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
-	return (asm("1:"
+	return (asm("mb;"
+		    "1:"
 		    "ldl_l %t0, 0(%a0);"	/* load old value */
 		    "mov %t0, %v0;"		/* copy the old value */
 		    "addl %t0, %a1, %t0;"	/* calculate new value */
 		    "stl_c %t0, 0(%a0);"	/* attempt to store */
-		    "beq %t0, 1b;",		/* spin if failed */
+		    "beq %t0, 1b;"		/* spin if failed */
+		    "mb;",
 		    p, val));
 }
 
@@ -80,11 +84,13 @@ isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
  */
 static inline void
 isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
-	(void)asm("1:"
+	(void)asm("mb;"
+		  "1:"
 		  "ldl_l %t0, 0(%a0);"		/* load old value */
 		  "mov %a1, %t0;"		/* value to store */
 		  "stl_c %t0, 0(%a0);"		/* attempt to store */
-		  "beq %t0, 1b;",		/* spin if failed */
+		  "beq %t0, 1b;"		/* spin if failed */
+		  "mb;",
 		  p, val);
 }
 
@@ -96,7 +102,8 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
 static inline isc_int32_t
 isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 
-	return(asm("1:"
+	return(asm("mb;"
+		   "1:"
 		   "ldl_l %t0, 0(%a0);"		/* load old value */
 		   "mov %t0, %v0;"		/* copy the old value */
 		   "cmpeq %t0, %a1, %t0;"	/* compare */
@@ -104,22 +111,25 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 		   "mov %a2, %t0;"		/* value to store */
 		   "stl_c %t0, 0(%a0);"		/* attempt to store */
 		   "beq %t0, 1b;"		/* if it failed, spin */
-		   "2:",
+		   "2:"
+		   "mb;",
 		   p, cmpval, val));
 }
 #elif defined (ISC_PLATFORM_USEGCCASM)
-static inline isc_int32_t 
+static inline isc_int32_t
 isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
 	isc_int32_t temp, prev;
 
 	__asm__ volatile(
+		"mb;"
 		"1:"
 		"ldl_l %0, %1;"			/* load old value */
 		"mov %0, %2;"			/* copy the old value */
 		"addl %0, %3, %0;"		/* calculate new value */
 		"stl_c %0, %1;"			/* attempt to store */
 		"beq %0, 1b;"			/* spin if failed */
-		: "=&r"(temp), "+m"(*p), "=r"(prev)
+		"mb;"
+		: "=&r"(temp), "+m"(*p), "=&r"(prev)
 		: "r"(val)
 		: "memory");
 
@@ -131,11 +141,13 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
 	isc_int32_t temp;
 
 	__asm__ volatile(
+		"mb;"
 		"1:"
 		"ldl_l %0, %1;"			/* load old value */
 		"mov %2, %0;"			/* value to store */
 		"stl_c %0, %1;"			/* attempt to store */
 		"beq %0, 1b;"			/* if it failed, spin */
+		"mb;"
 		: "=&r"(temp), "+m"(*p)
 		: "r"(val)
 		: "memory");
@@ -146,6 +158,7 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 	isc_int32_t temp, prev;
 
 	__asm__ volatile(
+		"mb;"
 		"1:"
 		"ldl_l %0, %1;"			/* load old value */
 		"mov %0, %2;"			/* copy the old value */
@@ -155,7 +168,8 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 		"stl_c %0, %1;"			/* attempt to store */
 		"beq %0, 1b;"			/* if it failed, spin */
 		"2:"
-		: "=&r"(temp), "+m"(*p), "=r"(prev)
+		"mb;"
+		: "=&r"(temp), "+m"(*p), "=&r"(prev)
 		: "r"(cmpval), "r"(val)
 		: "memory");
 
diff --git a/lib/isc/api b/lib/isc/api
index 0b8a3bc5beea..8216a30f0a2c 100644
--- a/lib/isc/api
+++ b/lib/isc/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 36
-LIBREVISION = 2
-LIBAGE = 0
+LIBINTERFACE = 37
+LIBREVISION = 0
+LIBAGE = 1
diff --git a/lib/isc/entropy.c b/lib/isc/entropy.c
index 3e87d87e515c..c5de1e785e72 100644
--- a/lib/isc/entropy.c
+++ b/lib/isc/entropy.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: entropy.c,v 1.11.18.3 2005/07/12 01:22:28 marka Exp $ */
+/* $Id: entropy.c,v 1.11.18.5 2009/01/19 23:46:16 tbox Exp $ */
 
 /*! \file
  * \brief
@@ -290,7 +290,7 @@ entropypool_add_word(isc_entropypool_t *rp, isc_uint32_t val) {
 	 * If we have looped around the pool, increment the rotate
 	 * variable so the next value will get xored in rotated to
 	 * a different position.
-	 * Increment by a value that is relativly prime to the word size
+	 * Increment by a value that is relatively prime to the word size
 	 * to try to spread the bits throughout the pool quickly when the
 	 * pool is empty.
 	 */
@@ -1251,7 +1251,7 @@ isc_entropy_usebestsource(isc_entropy_t *ectx, isc_entropysource_t **source,
 
 		if (final_result != ISC_R_SUCCESS)
 			final_result = result;
-	}	
+	}
 
 	/*
 	 * final_result is ISC_R_SUCCESS if at least one source of entropy
diff --git a/lib/isc/ia64/include/isc/atomic.h b/lib/isc/ia64/include/isc/atomic.h
index 20cbabdae394..f834c25da6f6 100644
--- a/lib/isc/ia64/include/isc/atomic.h
+++ b/lib/isc/ia64/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.2.2.1 2006/06/21 03:38:32 marka Exp $ */
+/* $Id: atomic.h,v 1.2.2.4 2009/06/24 02:24:13 marka Exp $ */
 
 #ifndef ISC_ATOMIC_H
 #define ISC_ATOMIC_H 1
@@ -31,7 +31,11 @@
  * (e.g., 1 and -1)?
  */
 static inline isc_int32_t
-isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
+#ifdef __GNUC__
+__attribute__ ((unused))
+#endif
+isc_atomic_xadd(isc_int32_t *p, isc_int32_t val)
+{
 	isc_int32_t prev, swapped;
 
 	for (prev = *(volatile isc_int32_t *)p; ; prev = swapped) {
@@ -53,7 +57,11 @@ isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
  * This routine atomically stores the value 'val' in 'p'.
  */
 static inline void
-isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
+#ifdef __GNUC__
+__attribute__ ((unused))
+#endif
+isc_atomic_store(isc_int32_t *p, isc_int32_t val)
+{
 	__asm__ volatile(
 		"st4.rel %0=%1"
 		: "=m" (*p)
@@ -68,7 +76,11 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
  * case.
  */
 static inline isc_int32_t
-isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
+#ifdef __GNUC__
+__attribute__ ((unused))
+#endif
+isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val)
+{
 	isc_int32_t ret;
 
 	__asm__ volatile(
diff --git a/lib/isc/include/isc/entropy.h b/lib/isc/include/isc/entropy.h
index 2890f6c5c270..d5b5b59122a5 100644
--- a/lib/isc/include/isc/entropy.h
+++ b/lib/isc/include/isc/entropy.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: entropy.h,v 1.25.18.2 2005/04/29 00:16:54 marka Exp $ */
+/* $Id: entropy.h,v 1.25.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_ENTROPY_H
 #define ISC_ENTROPY_H 1
@@ -74,7 +74,7 @@ typedef void (*isc_entropystop_t)(isc_entropysource_t *source, void *arg);
  ***/
 
 /*!
- * \brief 
+ * \brief
  *	Extract only "good" data; return failure if there is not enough
  *	data available and there are no sources which we can poll to get
  *	data, or those sources are empty.
@@ -103,7 +103,7 @@ typedef void (*isc_entropystop_t)(isc_entropysource_t *source, void *arg);
 /*!
  * \brief
  *	Estimate the amount of entropy contained in the sample pool.
- *	If this is not set, the source will be gathered and perodically
+ *	If this is not set, the source will be gathered and periodically
  *	mixed into the entropy pool, but no increment in contained entropy
  *	will be assumed.  This flag only makes sense on sample sources.
  */
@@ -113,12 +113,12 @@ typedef void (*isc_entropystop_t)(isc_entropysource_t *source, void *arg);
  * For use with isc_entropy_usebestsource().
  */
 /*!
- * \brief 
+ * \brief
  *	Use the keyboard as the only entropy source.
  */
 #define ISC_ENTROPY_KEYBOARDYES		1
 /*!
- * \brief 
+ * \brief
  *	Never use the keyboard as an entropy source.
  */
 #define ISC_ENTROPY_KEYBOARDNO		2
@@ -194,7 +194,7 @@ isc_entropy_createcallbacksource(isc_entropy_t *ent,
 				 void *arg,
 				 isc_entropysource_t **sourcep);
 /*!<
- * \brief Create an entropy source that is polled via a callback.  
+ * \brief Create an entropy source that is polled via a callback.
  *
  * This would
  * be used when keyboard input is used, or a GUI input method.  It can
@@ -220,7 +220,7 @@ isc_result_t
 isc_entropy_addsample(isc_entropysource_t *source, isc_uint32_t sample,
 		      isc_uint32_t extra);
 /*!<
- * \brief Add a sample to the sample source.  
+ * \brief Add a sample to the sample source.
  *
  * The sample MUST be a timestamp
  * that increases over time, with the exception of wrap-around for
@@ -275,11 +275,11 @@ isc_entropy_usebestsource(isc_entropy_t *ectx, isc_entropysource_t **source,
  *
  * Notes:
  *\li	If "randomfile" is not NULL, open it with
- *	isc_entropy_createfilesource(). 
+ *	isc_entropy_createfilesource().
  *
  *\li	If "randomfile" is NULL and the system's random device was detected
  *	when the program was configured and built, open that device with
- *	isc_entropy_createfilesource(). 
+ *	isc_entropy_createfilesource().
  *
  *\li	If "use_keyboard" is #ISC_ENTROPY_KEYBOARDYES, then always open
  *	the keyboard as an entropy source (possibly in addition to
diff --git a/lib/isc/include/isc/file.h b/lib/isc/include/isc/file.h
index 16b007572581..b984f666907e 100644
--- a/lib/isc/include/isc/file.h
+++ b/lib/isc/include/isc/file.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: file.h,v 1.27.18.2 2005/04/29 00:16:54 marka Exp $ */
+/* $Id: file.h,v 1.27.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_FILE_H
 #define ISC_FILE_H 1
@@ -35,7 +35,7 @@ isc_file_settime(const char *file, isc_time_t *time);
 isc_result_t
 isc_file_getmodtime(const char *file, isc_time_t *time);
 /*!<
- * \brief Get the time of last modication of a file.
+ * \brief Get the time of last modification of a file.
  *
  * Notes:
  *\li	The time that is set is relative to the (OS-specific) epoch, as are
@@ -204,7 +204,7 @@ isc_result_t
 isc_file_progname(const char *filename, char *buf, size_t buflen);
 /*!<
  * \brief Given an operating system specific file name "filename"
- * referring to a program, return the canonical program name. 
+ * referring to a program, return the canonical program name.
  *
  *
  * Any directory prefix or executable file name extension (if
diff --git a/lib/isc/include/isc/fsaccess.h b/lib/isc/include/isc/fsaccess.h
index 70c4d7c4db78..8203f4ef93b4 100644
--- a/lib/isc/include/isc/fsaccess.h
+++ b/lib/isc/include/isc/fsaccess.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: fsaccess.h,v 1.8.18.2 2005/04/29 00:16:55 marka Exp $ */
+/* $Id: fsaccess.h,v 1.8.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_FSACCESS_H
 #define ISC_FSACCESS_H 1
@@ -25,8 +25,8 @@
  * and directory access permissions into one API that is meant to be
  * portable to multiple operating systems.
  *
- * The two primary operating system flavors that are initially accomodated are
- * POSIX and Windows NT 4.0 and later.  The Windows NT access model is
+ * The two primary operating system flavors that are initially accommodated
+ * are POSIX and Windows NT 4.0 and later.  The Windows NT access model is
  * considerable more flexible than POSIX's model (as much as I am loathe to
  * admit it), and so the ISC API has a higher degree of complexity than would
  * be needed to simply address POSIX's needs.
@@ -88,7 +88,7 @@
  *
  * The rest of this comment discusses a few of the incompatibilities
  * between the two systems that need more thought if this API is to
- * be extended to accomodate them.
+ * be extended to accommodate them.
  *
  * The Windows standard access right "DELETE" doesn't have a direct
  * equivalent in the Unix world, so it isn't clear what should be done
@@ -98,7 +98,7 @@
  * of allowing users to create files in a directory but not delete or
  * rename them, it does not have a concept of allowing them to be deleted
  * if they are owned by the user trying to delete/rename.  While it is
- * probable that something could be cobbled together in NT 5 with inheritence,
+ * probable that something could be cobbled together in NT 5 with inheritance,
  * it can't really be done in NT 4 as a single property that you could
  * set on a directory.  You'd need to coordinate something with file creation
  * so that every file created had DELETE set for the owner but noone else.
@@ -155,7 +155,7 @@
  * Adding any permission bits beyond 0x200 would mean typedef'ing
  * isc_fsaccess_t as isc_uint64_t, and redefining this value to
  * reflect the new range of permission types, Probably to 21 for
- * maximum flexibility.  The number of bits has to accomodate all of
+ * maximum flexibility.  The number of bits has to accommodate all of
  * the permission types, and three full sets of them have to fit
  * within an isc_fsaccess_t.
  */
diff --git a/lib/isc/include/isc/hash.h b/lib/isc/include/isc/hash.h
index cd29cdf865e3..4908fc87cb93 100644
--- a/lib/isc/include/isc/hash.h
+++ b/lib/isc/include/isc/hash.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hash.h,v 1.4.18.2 2005/04/29 00:16:55 marka Exp $ */
+/* $Id: hash.h,v 1.4.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_HASH_H
 #define ISC_HASH_H 1
@@ -36,7 +36,7 @@
  *	in the random vector are unpredictable, the probability of hash
  *	collision between arbitrary two different values is at most 1/2^16.
  *
- *	Altough the API is generic about the hash keys, it mainly expects
+ *	Although the API is generic about the hash keys, it mainly expects
  *	DNS names (and sometimes IPv4/v6 addresses) as inputs.  It has an
  *	upper limit of the input length, and may run slow to calculate the
  *	hash values for large inputs.
@@ -135,7 +135,7 @@ isc_hash_ctxinit(isc_hash_t *hctx);
 void
 isc_hash_init(void);
 /*!<
- * \brief Initialize a hash object.  
+ * \brief Initialize a hash object.
  *
  * It fills in the random vector with a proper
  * source of entropy, which is typically from the entropy object specified
diff --git a/lib/isc/include/isc/heap.h b/lib/isc/include/isc/heap.h
index d54a8d5b76cc..fbb5f9c5c89b 100644
--- a/lib/isc/include/isc/heap.h
+++ b/lib/isc/include/isc/heap.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: heap.h,v 1.17.18.3 2006/04/17 18:27:33 explorer Exp $ */
+/* $Id: heap.h,v 1.17.18.5 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_HEAP_H
 #define ISC_HEAP_H 1
@@ -28,7 +28,7 @@
 ISC_LANG_BEGINDECLS
 
 /*%
- * The comparision function returns ISC_TRUE if the first argument has
+ * The comparison function returns ISC_TRUE if the first argument has
  * higher priority than the second argument, and ISC_FALSE otherwise.
  */
 typedef isc_boolean_t (*isc_heapcompare_t)(void *, void *);
diff --git a/lib/isc/include/isc/log.h b/lib/isc/include/isc/log.h
index c3817758faee..7ac5bfe9bf4c 100644
--- a/lib/isc/include/isc/log.h
+++ b/lib/isc/include/isc/log.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.h,v 1.47.18.3 2005/04/29 00:16:58 marka Exp $ */
+/* $Id: log.h,v 1.47.18.8 2009/02/16 02:12:58 marka Exp $ */
 
 #ifndef ISC_LOG_H
 #define ISC_LOG_H 1
@@ -86,7 +86,7 @@
 /*@}*/
 
 /*!
- * \brief Used to name the categories used by a library.  
+ * \brief Used to name the categories used by a library.
  *
  * An array of isc_logcategory
  * structures names each category, and the id value is initialized by calling
@@ -107,13 +107,13 @@ struct isc_logmodule {
 
 /*%
  * The isc_logfile structure is initialized as part of an isc_logdestination
- * before calling isc_log_createchannel().  
+ * before calling isc_log_createchannel().
  *
  * When defining an #ISC_LOG_TOFILE
  * channel the name, versions and maximum_size should be set before calling
  * isc_log_createchannel().  To define an #ISC_LOG_TOFILEDESC channel set only
  * the stream before the call.
- * 
+ *
  * Setting maximum_size to zero implies no maximum.
  */
 typedef struct isc_logfile {
@@ -166,6 +166,7 @@ LIBISC_EXTERNAL_DATA extern isc_logmodule_t isc_modules[];
 #define ISC_LOGMODULE_TIME (&isc_modules[1])
 #define ISC_LOGMODULE_INTERFACE (&isc_modules[2])
 #define ISC_LOGMODULE_TIMER (&isc_modules[3])
+#define ISC_LOGMODULE_FILE (&isc_modules[4])
 
 ISC_LANG_BEGINDECLS
 
@@ -477,7 +478,7 @@ isc_log_usechannel(isc_logconfig_t *lcfg, const char *name,
  *	number of named channels.)  When multiple channels of the same
  *	name are defined, the most recent definition is found.
  *
- *\li	Specifing a very large number of channels for a category will have
+ *\li	Specifying a very large number of channels for a category will have
  *	a moderate impact on performance in isc_log_write(), as each
  *	call looks up the category for the start of a linked list, which
  *	it follows all the way to the end to find matching modules.  The
@@ -527,7 +528,7 @@ isc_log_usechannel(isc_logconfig_t *lcfg, const char *name,
  */
 
 /* Attention: next four comments PRECEED code */
-/*! 
+/*!
  *   \brief
  * Write a message to the log channels.
  *
@@ -546,7 +547,7 @@ isc_log_usechannel(isc_logconfig_t *lcfg, const char *name,
  *\li	lctx is a valid logging context.
  *
  *\li	The category and module arguments must have ids that are in the
- *	range of known ids, as estabished by isc_log_registercategories()
+ *	range of known ids, as established by isc_log_registercategories()
  *	and isc_log_registermodules().
  *
  *\li	level != #ISC_LOG_DYNAMIC.  ISC_LOG_DYNAMIC is used only to define
@@ -585,7 +586,7 @@ ISC_FORMAT_PRINTF(5, 6);
  *\li	lctx is a valid logging context.
  *
  *\li	The category and module arguments must have ids that are in the
- *	range of known ids, as estabished by isc_log_registercategories()
+ *	range of known ids, as established by isc_log_registercategories()
  *	and isc_log_registermodules().
  *
  *\li	level != #ISC_LOG_DYNAMIC.  ISC_LOG_DYNAMIC is used only to define
@@ -633,8 +634,8 @@ isc_log_vwrite1(isc_log_t *lctx, isc_logcategory_t *category,
 ISC_FORMAT_PRINTF(5, 0);
 
 /*%
- * These are four internationalized versions of the the isc_log_[v]write[1]
- * functions.  
+ * These are four internationalized versions of the isc_log_[v]write[1]
+ * functions.
  *
  * The only difference is that they take arguments for a message
  * catalog, message set, and message number, all immediately preceding the
@@ -824,7 +825,7 @@ isc_log_opensyslog(const char *tag, int options, int facility);
  *			declared facility.
  * \endcode
  *
- *\li	Zero effort has been made (yet) to accomodate systems with openlog()
+ *\li	Zero effort has been made (yet) to accommodate systems with openlog()
  *	that only takes two arguments, or to identify valid syslog
  *	facilities or options for any given architecture.
  *
diff --git a/lib/isc/include/isc/mem.h b/lib/isc/include/isc/mem.h
index 2c3c54e4f4d7..d3a77ac149d9 100644
--- a/lib/isc/include/isc/mem.h
+++ b/lib/isc/include/isc/mem.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mem.h,v 1.59.18.11 2008/02/07 23:45:56 tbox Exp $ */
+/* $Id: mem.h,v 1.59.18.14 2009/02/11 03:11:39 jinmei Exp $ */
 
 #ifndef ISC_MEM_H
 #define ISC_MEM_H 1
@@ -93,7 +93,7 @@ LIBISC_EXTERNAL_DATA extern unsigned int isc_mem_debugging;
 /*!<
  * The variable isc_mem_debugging holds a set of flags for
  * turning certain memory debugging options on or off at
- * runtime.  Its is intialized to the value ISC_MEM_DEGBUGGING,
+ * runtime.  It is initialized to the value ISC_MEM_DEGBUGGING,
  * which is 0 by default but may be overridden at compile time.
  * The following flags can be specified:
  *
@@ -105,7 +105,7 @@ LIBISC_EXTERNAL_DATA extern unsigned int isc_mem_debugging;
  *	Crash if a free doesn't match an allocation.
  *
  * \li #ISC_MEM_DEBUGUSAGE
- *	If a hi_water mark is set, print the maximium inuse memory
+ *	If a hi_water mark is set, print the maximum inuse memory
  *	every time it is raised once it exceeds the hi_water mark.
  *
  * \li #ISC_MEM_DEBUGSIZE
@@ -153,11 +153,12 @@ LIBISC_EXTERNAL_DATA extern unsigned int isc_mem_debugging;
 
 #define isc_mem_get(c, s)	isc__mem_get((c), (s) _ISC_MEM_FILELINE)
 #define isc_mem_allocate(c, s)	isc__mem_allocate((c), (s) _ISC_MEM_FILELINE)
+#define isc_mem_reallocate(c, p, s) isc__mem_reallocate((c), (p), (s) _ISC_MEM_FILELINE)
 #define isc_mem_strdup(c, p)	isc__mem_strdup((c), (p) _ISC_MEM_FILELINE)
 #define isc_mempool_get(c)	isc__mempool_get((c) _ISC_MEM_FILELINE)
 
 /*%
- * isc_mem_putanddetach() is a convienence function for use where you
+ * isc_mem_putanddetach() is a convenience function for use where you
  * have a structure with an attached memory context.
  *
  * Given:
@@ -340,12 +341,12 @@ isc_mem_setwater(isc_mem_t *mctx, isc_mem_water_t water, void *water_arg,
  *
  * When the memory usage of 'mctx' exceeds 'hiwater',
  * '(water)(water_arg, #ISC_MEM_HIWATER)' will be called.  'water' needs to
- * call isc_mem_waterack() with #ISC_MEM_HIWATER to acknowlege the state
+ * call isc_mem_waterack() with #ISC_MEM_HIWATER to acknowledge the state
  * change.  'water' may be called multiple times.
  *
  * When the usage drops below 'lowater', 'water' will again be called, this
  * time with #ISC_MEM_LOWATER.  'water' need to calls isc_mem_waterack() with
- * #ISC_MEM_LOWATER to acknowlege the change.
+ * #ISC_MEM_LOWATER to acknowledge the change.
  *
  *	static void
  *	water(void *arg, int mark) {
@@ -371,7 +372,7 @@ isc_mem_setwater(isc_mem_t *mctx, isc_mem_water_t water, void *water_arg,
 void
 isc_mem_waterack(isc_mem_t *ctx, int mark);
 /*%<
- * Called to acknowledge changes in signalled by calls to 'water'.
+ * Called to acknowledge changes in signaled by calls to 'water'.
  */
 
 void
@@ -451,7 +452,7 @@ isc_mempool_associatelock(isc_mempool_t *mpctx, isc_mutex_t *lock);
  * and it is also used to set or get internal state via the isc_mempool_get*()
  * and isc_mempool_set*() set of functions.
  *
- * Mutiple pools can each share a single lock.  For instance, if "manager"
+ * Multiple pools can each share a single lock.  For instance, if "manager"
  * type object contained pools for various sizes of events, and each of
  * these pools used a common lock.  Note that this lock must NEVER be used
  * by other than mempool routines once it is given to a pool, since that can
@@ -551,6 +552,8 @@ void
 isc__mem_put(isc_mem_t *, void *, size_t _ISC_MEM_FLARG);
 void *
 isc__mem_allocate(isc_mem_t *, size_t _ISC_MEM_FLARG);
+void *
+isc__mem_reallocate(isc_mem_t *, void *, size_t _ISC_MEM_FLARG);
 void
 isc__mem_free(isc_mem_t *, void * _ISC_MEM_FLARG);
 char *
diff --git a/lib/isc/include/isc/netaddr.h b/lib/isc/include/isc/netaddr.h
index 06d063e70bad..a74c8ee2959b 100644
--- a/lib/isc/include/isc/netaddr.h
+++ b/lib/isc/include/isc/netaddr.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: netaddr.h,v 1.25.18.5 2005/07/28 04:58:47 marka Exp $ */
+/* $Id: netaddr.h,v 1.25.18.7 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_NETADDR_H
 #define ISC_NETADDR_H 1
@@ -36,7 +36,7 @@ ISC_LANG_BEGINDECLS
 struct isc_netaddr {
 	unsigned int family;
 	union {
-    		struct in_addr in;
+		struct in_addr in;
 		struct in6_addr in6;
 #ifdef ISC_PLATFORM_HAVESYSUNH
 		char un[sizeof(((struct sockaddr_un *)0)->sun_path)];
@@ -166,7 +166,7 @@ isc_netaddr_prefixok(const isc_netaddr_t *na, unsigned int prefixlen);
  * Returns:
  *	ISC_R_SUCCESS
  *	ISC_R_RANGE		prefixlen out of range
- *	ISC_R_NOTIMPLENTED	unsupported family
+ *	ISC_R_NOTIMPLEMENTED	unsupported family
  *	ISC_R_FAILURE		extra bits.
  */
 
diff --git a/lib/isc/include/isc/netscope.h b/lib/isc/include/isc/netscope.h
index d9bea54fbd7c..170eb0a0995b 100644
--- a/lib/isc/include/isc/netscope.h
+++ b/lib/isc/include/isc/netscope.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: netscope.h,v 1.5.18.2 2005/04/29 00:17:00 marka Exp $ */
+/* $Id: netscope.h,v 1.5.18.4 2009/06/25 23:46:08 tbox Exp $ */
 
 #ifndef ISC_NETSCOPE_H
 #define ISC_NETSCOPE_H 1
@@ -40,4 +40,4 @@ isc_netscope_pton(int af, char *scopename, void *addr, isc_uint32_t *zoneid);
 
 ISC_LANG_ENDDECLS
 
-#endif /* ISC_NETADDR_H */
+#endif /* ISC_NETSCOPE_H */
diff --git a/lib/isc/include/isc/platform.h.in b/lib/isc/include/isc/platform.h.in
index afcd4df01ccb..fbf4360bea80 100644
--- a/lib/isc/include/isc/platform.h.in
+++ b/lib/isc/include/isc/platform.h.in
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: platform.h.in,v 1.34.18.11 2008/06/24 23:45:55 tbox Exp $ */
+/* $Id: platform.h.in,v 1.34.18.12 2008/12/01 04:02:15 marka Exp $ */
 
 #ifndef ISC_PLATFORM_H
 #define ISC_PLATFORM_H 1
@@ -98,11 +98,6 @@
  */
 @ISC_PLATFORM_NEEDPTON@
 
-/*! \brief
- * If this system needs inet_aton(), ISC_PLATFORM_NEEDATON will be defined.
- */
-@ISC_PLATFORM_NEEDATON@
-
 /*! \brief
  * If this system needs in_port_t, ISC_PLATFORM_NEEDPORTT will be defined.
  */
diff --git a/lib/isc/include/isc/portset.h b/lib/isc/include/isc/portset.h
index 6396e5ced3d5..7cd4a278a227 100644
--- a/lib/isc/include/isc/portset.h
+++ b/lib/isc/include/isc/portset.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -14,10 +14,10 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: portset.h,v 1.3.4.1 2008/06/24 03:42:10 marka Exp $ */
+/* $Id: portset.h,v 1.3.4.4 2009/06/25 05:33:47 marka Exp $ */
 
 /*! \file isc/portset.h
- * \brief Transport Protocol Port Manipuration Module
+ * \brief Transport Protocol Port Manipulation Module
  *
  * This module provides simple utilities to handle a set of transport protocol
  * (UDP or TCP) port numbers, e.g., for creating an ACL list.  An isc_portset_t
@@ -138,4 +138,4 @@ isc_portset_removerange(isc_portset_t *portset, in_port_t port_lo,
 
 ISC_LANG_ENDDECLS
 
-#endif	/* ISC_NETADDR_H */
+#endif	/* ISC_PORTSET_H */
diff --git a/lib/isc/include/isc/random.h b/lib/isc/include/isc/random.h
index c5cef8bdbfc5..f3478ea0e9ca 100644
--- a/lib/isc/include/isc/random.h
+++ b/lib/isc/include/isc/random.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: random.h,v 1.12.18.2 2005/04/29 00:17:01 marka Exp $ */
+/* $Id: random.h,v 1.12.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_RANDOM_H
 #define ISC_RANDOM_H 1
@@ -25,7 +25,7 @@
 
 /*! \file
  * \brief Implements a random state pool which will let the caller return a
- * series of possibly non-reproducable random values.  
+ * series of possibly non-reproducible random values.
  *
  * Note that the
  * strength of these numbers is not all that high, and should not be
diff --git a/lib/isc/include/isc/ratelimiter.h b/lib/isc/include/isc/ratelimiter.h
index 1944754b05e0..2528b1508c13 100644
--- a/lib/isc/include/isc/ratelimiter.h
+++ b/lib/isc/include/isc/ratelimiter.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ratelimiter.h,v 1.15.18.2 2005/04/29 00:17:01 marka Exp $ */
+/* $Id: ratelimiter.h,v 1.15.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_RATELIMITER_H
 #define ISC_RATELIMITER_H 1
@@ -53,7 +53,7 @@ isc_ratelimiter_create(isc_mem_t *mctx, isc_timermgr_t *timermgr,
 isc_result_t
 isc_ratelimiter_setinterval(isc_ratelimiter_t *rl, isc_interval_t *interval);
 /*!<
- * Set the mininum interval between event executions.
+ * Set the minimum interval between event executions.
  * The interval value is copied, so the caller need not preserve it.
  *
  * Requires:
@@ -71,7 +71,7 @@ isc_result_t
 isc_ratelimiter_enqueue(isc_ratelimiter_t *rl, isc_task_t *task,
 			isc_event_t **eventp);
 /*%<
- * Queue an event for rate-limited execution.  
+ * Queue an event for rate-limited execution.
  *
  * This is similar
  * to doing an isc_task_send() to the 'task', except that the
@@ -102,7 +102,7 @@ isc_ratelimiter_shutdown(isc_ratelimiter_t *ratelimiter);
  *\li	Further attempts to enqueue events will fail with
  * 	#ISC_R_SHUTTINGDOWN.
  *
- *\li	The reatelimiter is no longer attached to its task.
+ *\li	The rate limiter is no longer attached to its task.
  */
 
 void
diff --git a/lib/isc/include/isc/serial.h b/lib/isc/include/isc/serial.h
index 86d9b2f14d25..05c450545b6e 100644
--- a/lib/isc/include/isc/serial.h
+++ b/lib/isc/include/isc/serial.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: serial.h,v 1.10.18.2 2005/04/29 00:17:02 marka Exp $ */
+/* $Id: serial.h,v 1.10.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_SERIAL_H
 #define ISC_SERIAL_H 1
@@ -23,8 +23,8 @@
 #include 
 #include 
 
-/*! \file
- *	\brief Implement 32 bit serial space arithmetic comparision functions.
+/*! \file isc/serial.h
+ *	\brief Implement 32 bit serial space arithmetic comparison functions.
  *	Note: Undefined results are returned as ISC_FALSE.
  */
 
diff --git a/lib/isc/include/isc/sockaddr.h b/lib/isc/include/isc/sockaddr.h
index 83412d2db4b1..39743b761204 100644
--- a/lib/isc/include/isc/sockaddr.h
+++ b/lib/isc/include/isc/sockaddr.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sockaddr.h,v 1.42.18.8 2006/03/02 00:37:22 marka Exp $ */
+/* $Id: sockaddr.h,v 1.42.18.10 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_SOCKADDR_H
 #define ISC_SOCKADDR_H 1
@@ -209,7 +209,7 @@ isc_sockaddr_isexperimental(const isc_sockaddr_t *sa);
 isc_boolean_t
 isc_sockaddr_islinklocal(const isc_sockaddr_t *sa);
 /*%<
- * Returns ISC_TRUE if the address is a link local addresss.
+ * Returns ISC_TRUE if the address is a link local address.
  */
 
 isc_boolean_t
diff --git a/lib/isc/include/isc/socket.h b/lib/isc/include/isc/socket.h
index a9a22c87c57c..11083d15cb01 100644
--- a/lib/isc/include/isc/socket.h
+++ b/lib/isc/include/isc/socket.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket.h,v 1.57.18.15 2008/09/04 08:03:08 marka Exp $ */
+/* $Id: socket.h,v 1.57.18.17 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_SOCKET_H
 #define ISC_SOCKET_H 1
@@ -812,7 +812,7 @@ isc_socket_permunix(isc_sockaddr_t *sockaddr, isc_uint32_t perm,
  * Set ownership and file permissions on the UNIX domain socket.
  *
  * Note: On Solaris and SunOS this secures the directory containing
- *       the socket as Solaris and SunOS do not honour the filesytem
+ *       the socket as Solaris and SunOS do not honour the filesystem
  *	 permissions on the socket.
  *
  * Requires:
diff --git a/lib/isc/include/isc/symtab.h b/lib/isc/include/isc/symtab.h
index 94ea173c18ac..141ebffe3d72 100644
--- a/lib/isc/include/isc/symtab.h
+++ b/lib/isc/include/isc/symtab.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: symtab.h,v 1.17.18.4 2006/03/02 00:37:22 marka Exp $ */
+/* $Id: symtab.h,v 1.17.18.6 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_SYMTAB_H
 #define ISC_SYMTAB_H 1
@@ -27,7 +27,7 @@
 /*! \file
  * \brief Provides a simple memory-based symbol table.
  *
- * Keys are C strings, and key comparisons are case-insenstive.  A type may
+ * Keys are C strings, and key comparisons are case-insensitive.  A type may
  * be specified when looking up, defining, or undefining.  A type value of
  * 0 means "match any type"; any other value will only match the given
  * type.
diff --git a/lib/isc/include/isc/task.h b/lib/isc/include/isc/task.h
index f7d237c29ef3..e89321dd35e0 100644
--- a/lib/isc/include/isc/task.h
+++ b/lib/isc/include/isc/task.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: task.h,v 1.51.18.2 2005/04/29 00:17:03 marka Exp $ */
+/* $Id: task.h,v 1.51.18.4 2009/01/19 23:46:16 tbox Exp $ */
 
 #ifndef ISC_TASK_H
 #define ISC_TASK_H 1
@@ -26,7 +26,7 @@
 
 /*! \file
  * \brief The task system provides a lightweight execution context, which is
- * basically an event queue.  
+ * basically an event queue.
 
  * When a task's event queue is non-empty, the
  * task is runnable.  A small work crew of threads, typically one per CPU,
@@ -67,7 +67,7 @@
  * Consumers of events should purge, not unsend.
  *
  * Producers of events often want to remove events when the caller indicates
- * it is no longer interested in the object, e.g. by cancelling a timer.
+ * it is no longer interested in the object, e.g. by canceling a timer.
  * Sometimes this can be done by purging, but for some event types, the
  * calls to isc_event_free() cause deadlock because the event free routine
  * wants to acquire a lock the caller is already holding.  Unsending instead
@@ -497,7 +497,7 @@ isc_task_beginexclusive(isc_task_t *task);
  * current event, and prevents any new events from executing in any of the
  * tasks sharing a task manager with 'task'.
  *
- * The exclusive access must be relinquished by calling 
+ * The exclusive access must be relinquished by calling
  * isc_task_endexclusive() before returning from the current event handler.
  *
  * Requires:
@@ -512,7 +512,7 @@ isc_task_beginexclusive(isc_task_t *task);
 void
 isc_task_endexclusive(isc_task_t *task);
 /*%<
- * Relinquish the exclusive access obtained by isc_task_beginexclusive(), 
+ * Relinquish the exclusive access obtained by isc_task_beginexclusive(),
  * allowing other tasks to execute.
  *
  * Requires:
@@ -592,7 +592,7 @@ isc_taskmgr_destroy(isc_taskmgr_t **managerp);
  *	because it would block forever waiting for the event action to
  *	complete.  An event action that wants to cause task manager shutdown
  *	should request some non-event action thread of execution to do the
- *	shutdown, e.g. by signalling a condition variable or using
+ *	shutdown, e.g. by signaling a condition variable or using
  *	isc_app_shutdown().
  *
  *\li	Task manager references are not reference counted, so the caller
diff --git a/lib/isc/inet_aton.c b/lib/isc/inet_aton.c
index 160252109c52..c47fa3c4fe77 100644
--- a/lib/isc/inet_aton.c
+++ b/lib/isc/inet_aton.c
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1996-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -71,7 +71,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static char sccsid[] = "@(#)inet_addr.c	8.1 (Berkeley) 6/17/93";
-static char rcsid[] = "$Id: inet_aton.c,v 1.17.18.2 2005/04/29 00:16:46 marka Exp $";
+static char rcsid[] = "$Id: inet_aton.c,v 1.17.18.4 2008/12/01 23:45:57 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include 
@@ -145,7 +145,7 @@ isc_net_aton(const char *cp, struct in_addr *addr) {
 			 *	a.b.c	(with c treated as 16 bits)
 			 *	a.b	(with b treated as 24 bits)
 			 */
-			if (pp >= parts + 3 || val > 0xff)
+			if (pp >= parts + 3 || val > 0xffU)
 				return (0);
 			*pp++ = (isc_uint8_t)val;
 			c = *++cp;
@@ -172,19 +172,19 @@ isc_net_aton(const char *cp, struct in_addr *addr) {
 		break;
 
 	case 2:				/* a.b -- 8.24 bits */
-		if (val > 0xffffff)
+		if (val > 0xffffffU)
 			return (0);
 		val |= parts[0] << 24;
 		break;
 
 	case 3:				/* a.b.c -- 8.8.16 bits */
-		if (val > 0xffff)
+		if (val > 0xffffU)
 			return (0);
 		val |= (parts[0] << 24) | (parts[1] << 16);
 		break;
 
 	case 4:				/* a.b.c.d -- 8.8.8.8 bits */
-		if (val > 0xff)
+		if (val > 0xffU)
 			return (0);
 		val |= (parts[0] << 24) | (parts[1] << 16) | (parts[2] << 8);
 		break;
diff --git a/lib/isc/inet_ntop.c b/lib/isc/inet_ntop.c
index c0d1161d663b..c963f55922c8 100644
--- a/lib/isc/inet_ntop.c
+++ b/lib/isc/inet_ntop.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -19,7 +19,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static char rcsid[] =
-	"$Id: inet_ntop.c,v 1.14.18.3 2005/04/29 00:16:46 marka Exp $";
+	"$Id: inet_ntop.c,v 1.14.18.5 2009/07/18 23:46:03 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include 
@@ -52,7 +52,7 @@ static const char *inet_ntop6(const unsigned char *src, char *dst,
  *	convert a network format address to presentation format.
  * \return
  *	pointer to presentation format address (`dst'), or NULL (see errno).
- * \author 
+ * \author
  *	Paul Vixie, 1996.
  */
 const char *
@@ -169,8 +169,9 @@ inet_ntop6(const unsigned char *src, char *dst, size_t size)
 		if (i != 0)
 			*tp++ = ':';
 		/* Is this address an encapsulated IPv4? */
-		if (i == 6 && best.base == 0 &&
-		    (best.len == 6 || (best.len == 5 && words[5] == 0xffff))) {
+		if (i == 6 && best.base == 0 && (best.len == 6 ||
+		    (best.len == 7 && words[7] != 0x0001) ||
+		    (best.len == 5 && words[5] == 0xffff))) {
 			if (!inet_ntop4(src+12, tp,
 					sizeof(tmp) - (tp - tmp)))
 				return (NULL);
diff --git a/lib/isc/log.c b/lib/isc/log.c
index 27c01d12baf0..9b180b90705f 100644
--- a/lib/isc/log.c
+++ b/lib/isc/log.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.c,v 1.84.18.8 2006/03/02 00:37:22 marka Exp $ */
+/* $Id: log.c,v 1.84.18.13 2009/02/16 02:12:58 marka Exp $ */
 
 /*! \file
  * \author  Principal Authors: DCL */
@@ -61,7 +61,7 @@
  * This is the structure that holds each named channel.  A simple linked
  * list chains all of the channels together, so an individual channel is
  * found by doing strcmp()s with the names down the list.  Their should
- * be no peformance penalty from this as it is expected that the number
+ * be no performance penalty from this as it is expected that the number
  * of named channels will be no more than a dozen or so, and name lookups
  * from the head of the list are only done when isc_log_usechannel() is
  * called, which should also be very infrequent.
@@ -128,7 +128,7 @@ struct isc_logconfig {
  * This isc_log structure provides the context for the isc_log functions.
  * The log context locks itself in isc_log_doit, the internal backend to
  * isc_log_write.  The locking is necessary both to provide exclusive access
- * to the the buffer into which the message is formatted and to guard against
+ * to the buffer into which the message is formatted and to guard against
  * competing threads trying to write to the same syslog resource.  (On
  * some systems, such as BSD/OS, stdio is thread safe but syslog is not.)
  * Unfortunately, the lock cannot guard against a _different_ logging
@@ -204,6 +204,7 @@ LIBISC_EXTERNAL_DATA isc_logmodule_t isc_modules[] = {
 	{ "time", 0 },
 	{ "interface", 0 },
 	{ "timer", 0 },
+	{ "file", 0 },
 	{ NULL, 0 }
 };
 
@@ -1448,7 +1449,7 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 	LOCK(&lctx->lock);
 
 	lctx->buffer[0] = '\0';
-	
+
 	lcfg = lctx->logconfig;
 
 	category_channels = ISC_LIST_HEAD(lcfg->channellists[category->id]);
@@ -1507,7 +1508,7 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 		if ((channel->flags & ISC_LOG_PRINTTIME) != 0 &&
 		    time_string[0] == '\0') {
 			isc_time_t isctime;
-			
+
 			TIME_NOW(&isctime);
 			isc_time_formattimestamp(&isctime, time_string,
 						 sizeof(time_string));
@@ -1518,9 +1519,9 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 			if (level < ISC_LOG_CRITICAL)
 				snprintf(level_string, sizeof(level_string),
 					 isc_msgcat_get(isc_msgcat,
-						        ISC_MSGSET_LOG,
-						        ISC_MSG_LEVEL,
-						        "level %d: "),
+							ISC_MSGSET_LOG,
+							ISC_MSG_LEVEL,
+							"level %d: "),
 					 level);
 			else if (level > ISC_LOG_DYNAMIC)
 				snprintf(level_string, sizeof(level_string),
@@ -1700,8 +1701,8 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 				printcategory ? category->name	: "",
 				printcategory ? ": "		: "",
 				printmodule   ? (module != NULL ? module->name
-						 		: "no_module")
-					      			: "",
+								: "no_module")
+								: "",
 				printmodule   ? ": "		: "",
 				printlevel    ? level_string	: "",
 				lctx->buffer);
@@ -1743,8 +1744,8 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 			       printcategory ? category->name	: "",
 			       printcategory ? ": "		: "",
 			       printmodule   ? (module != NULL	? module->name
-						 		: "no_module")
-					      			: "",
+								: "no_module")
+								: "",
 			       printmodule   ? ": "		: "",
 			       printlevel    ? level_string	: "",
 			       lctx->buffer);
diff --git a/lib/isc/mem.c b/lib/isc/mem.c
index 408770d82c4c..7d237329b21d 100644
--- a/lib/isc/mem.c
+++ b/lib/isc/mem.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mem.c,v 1.116.18.21 2008/02/07 23:45:56 tbox Exp $ */
+/* $Id: mem.c,v 1.116.18.25 2009/02/16 03:17:57 marka Exp $ */
 
 /*! \file */
 
@@ -51,7 +51,7 @@ LIBISC_EXTERNAL_DATA unsigned int isc_mem_debugging = ISC_MEM_DEBUGGING;
 
 #define DEF_MAX_SIZE		1100
 #define DEF_MEM_TARGET		4096
-#define ALIGNMENT_SIZE		8		/*%< must be a power of 2 */
+#define ALIGNMENT_SIZE		8U		/*%< must be a power of 2 */
 #define NUM_BASIC_BLOCKS	64		/*%< must be > 1 */
 #define TABLE_INCREMENT		1024
 #define DEBUGLIST_COUNT		1024
@@ -1173,7 +1173,7 @@ print_active(isc_mem_t *mctx, FILE *out) {
 		const char *format;
 		isc_boolean_t found;
 
-		fprintf(out, isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
+		fprintf(out, "%s", isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
 					    ISC_MSG_DUMPALLOC,
 					    "Dump of all outstanding "
 					    "memory allocations:\n"));
@@ -1199,7 +1199,7 @@ print_active(isc_mem_t *mctx, FILE *out) {
 			}
 		}
 		if (!found)
-			fprintf(out, isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
+			fprintf(out, "%s", isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
 						    ISC_MSG_NONE, "\tNone.\n"));
 	}
 }
@@ -1241,7 +1241,7 @@ isc_mem_stats(isc_mem_t *ctx, FILE *out) {
 	 */
 	pool = ISC_LIST_HEAD(ctx->pools);
 	if (pool != NULL) {
-		fprintf(out, isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
+		fprintf(out, "%s", isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
 					    ISC_MSG_POOLSTATS,
 					    "[Pool statistics]\n"));
 		fprintf(out, "%15s %10s %10s %10s %10s %10s %10s %10s %1s\n",
@@ -1347,6 +1347,40 @@ isc__mem_allocate(isc_mem_t *ctx, size_t size FLARG) {
 	return (si);
 }
 
+void *
+isc__mem_reallocate(isc_mem_t *ctx, void *ptr, size_t size FLARG) {
+	void *new_ptr = NULL;
+	size_t oldsize, copysize;
+
+	REQUIRE(VALID_CONTEXT(ctx));
+
+	/*
+	 * This function emulates the realloc(3) standard library function:
+	 * - if size > 0, allocate new memory; and if ptr is non NULL, copy
+	 *   as much of the old contents to the new buffer and free the old one.
+	 *   Note that when allocation fails the original pointer is intact;
+	 *   the caller must free it.
+	 * - if size is 0 and ptr is non NULL, simply free the given ptr.
+	 * - this function returns:
+	 *     pointer to the newly allocated memory, or
+	 *     NULL if allocation fails or doesn't happen.
+	 */
+	if (size > 0U) {
+		new_ptr = isc__mem_allocate(ctx, size FLARG_PASS);
+		if (new_ptr != NULL && ptr != NULL) {
+			oldsize = (((size_info *)ptr)[-1]).u.size;
+			INSIST(oldsize >= ALIGNMENT_SIZE);
+			oldsize -= ALIGNMENT_SIZE;
+			copysize = oldsize > size ? size : oldsize;
+			memcpy(new_ptr, ptr, copysize);
+			isc__mem_free(ctx, ptr FLARG_PASS);
+		}
+	} else if (ptr != NULL)
+		isc__mem_free(ctx, ptr FLARG_PASS);
+
+	return (new_ptr);
+}
+
 void
 isc__mem_free(isc_mem_t *ctx, void *ptr FLARG) {
 	size_info *si;
diff --git a/lib/isc/random.c b/lib/isc/random.c
index f6c7d6e1266e..4486e505dec7 100644
--- a/lib/isc/random.c
+++ b/lib/isc/random.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: random.c,v 1.21.18.2 2005/04/29 00:16:48 marka Exp $ */
+/* $Id: random.c,v 1.21.18.4 2009/07/16 23:46:08 tbox Exp $ */
 
 /*! \file */
 
@@ -43,7 +43,7 @@ initialize_rand(void)
 {
 #ifndef HAVE_ARC4RANDOM
 	unsigned int pid = getpid();
-	
+
 	/*
 	 * The low bits of pid generally change faster.
 	 * Xor them with the high bits of time which change slowly.
@@ -84,7 +84,16 @@ isc_random_get(isc_uint32_t *val)
 	 * rand()'s lower bits are not random.
 	 * rand()'s upper bit is zero.
 	 */
+#if RAND_MAX >= 0xfffff
+	/* We have at least 20 bits.  Use lower 16 excluding lower most 4 */
 	*val = ((rand() >> 4) & 0xffff) | ((rand() << 12) & 0xffff0000);
+#elif RAND_MAX >= 0x7fff
+	/* We have at least 15 bits.  Use lower 10/11 excluding lower most 4 */
+	*val = ((rand() >> 4) & 0x000007ff) | ((rand() << 7) & 0x003ff800) |
+		((rand() << 18) & 0xffc00000);
+#else
+#error RAND_MAX is too small
+#endif
 #else
 	*val = arc4random();
 #endif
@@ -92,13 +101,13 @@ isc_random_get(isc_uint32_t *val)
 
 isc_uint32_t
 isc_random_jitter(isc_uint32_t max, isc_uint32_t jitter) {
+	isc_uint32_t rnd;
+
 	REQUIRE(jitter < max);
+
 	if (jitter == 0)
 		return (max);
-	else
-#ifndef HAVE_ARC4RANDOM
-		return (max - rand() % jitter);
-#else
-		return (max - arc4random() % jitter);
-#endif
+
+	isc_random_get(&rnd);
+	return (max - rnd % jitter);
 }
diff --git a/lib/isc/rwlock.c b/lib/isc/rwlock.c
index 69b8f56d94c5..4bb0edf1efb2 100644
--- a/lib/isc/rwlock.c
+++ b/lib/isc/rwlock.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rwlock.c,v 1.37.18.5 2005/07/12 01:22:30 marka Exp $ */
+/* $Id: rwlock.c,v 1.37.18.7 2009/01/19 23:46:16 tbox Exp $ */
 
 /*! \file */
 
@@ -45,7 +45,7 @@
 
 #ifdef ISC_RWLOCK_TRACE
 #include 		/* Required for fprintf/stderr. */
-#include 		/* Requried for isc_thread_self(). */
+#include 		/* Required for isc_thread_self(). */
 
 static void
 print_lock(const char *operation, isc_rwlock_t *rwl, isc_rwlocktype_t type) {
@@ -55,17 +55,17 @@ print_lock(const char *operation, isc_rwlock_t *rwl, isc_rwlocktype_t type) {
 			       "rwlock %p thread %lu %s(%s): %s, %u active, "
 			       "%u granted, %u rwaiting, %u wwaiting\n"),
 		rwl, isc_thread_self(), operation,
-		(type == isc_rwlocktype_read ? 
+		(type == isc_rwlocktype_read ?
 		 isc_msgcat_get(isc_msgcat, ISC_MSGSET_RWLOCK,
 				ISC_MSG_READ, "read") :
 		 isc_msgcat_get(isc_msgcat, ISC_MSGSET_RWLOCK,
 				ISC_MSG_WRITE, "write")),
-	        (rwl->type == isc_rwlocktype_read ?
+		(rwl->type == isc_rwlocktype_read ?
 		 isc_msgcat_get(isc_msgcat, ISC_MSGSET_RWLOCK,
-				ISC_MSG_READING, "reading") : 
+				ISC_MSG_READING, "reading") :
 		 isc_msgcat_get(isc_msgcat, ISC_MSGSET_RWLOCK,
 				ISC_MSG_WRITING, "writing")),
-	        rwl->active, rwl->granted, rwl->readers_waiting,
+		rwl->active, rwl->granted, rwl->readers_waiting,
 		rwl->writers_waiting);
 }
 #endif
@@ -381,7 +381,7 @@ isc_rwlock_trylock(isc_rwlock_t *rwl, isc_rwlocktype_t type) {
 				BROADCAST(&rwl->writeable);
 				UNLOCK(&rwl->lock);
 			}
-			
+
 			return (ISC_R_LOCKBUSY);
 		}
 	} else {
@@ -434,7 +434,7 @@ isc_rwlock_tryupgrade(isc_rwlock_t *rwl) {
 		return (ISC_R_LOCKBUSY);
 
 	return (ISC_R_SUCCESS);
-	
+
 }
 
 void
@@ -555,7 +555,7 @@ doit(isc_rwlock_t *rwl, isc_rwlocktype_t type, isc_boolean_t nonblock) {
 			    ((rwl->active == 0 ||
 			      (rwl->type == isc_rwlocktype_read &&
 			       (rwl->writers_waiting == 0 ||
-			        rwl->granted < rwl->read_quota)))))
+				rwl->granted < rwl->read_quota)))))
 			{
 				rwl->type = isc_rwlocktype_read;
 				rwl->active++;
@@ -751,7 +751,7 @@ isc_rwlock_lock(isc_rwlock_t *rwl, isc_rwlocktype_t type) {
 		rwl->type = isc_rwlocktype_write;
 		rwl->active = 1;
 	}
-        return (ISC_R_SUCCESS);
+	return (ISC_R_SUCCESS);
 }
 
 isc_result_t
@@ -766,7 +766,7 @@ isc_rwlock_tryupgrade(isc_rwlock_t *rwl) {
 	REQUIRE(VALID_RWLOCK(rwl));
 	REQUIRE(rwl->type == isc_rwlocktype_read);
 	REQUIRE(rwl->active != 0);
-	
+
 	/* If we are the only reader then succeed. */
 	if (rwl->active == 1)
 		rwl->type = isc_rwlocktype_write;
diff --git a/lib/isc/sha2.c b/lib/isc/sha2.c
index 7b41a28918a9..045d4bd366bd 100644
--- a/lib/isc/sha2.c
+++ b/lib/isc/sha2.c
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2006, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sha2.c,v 1.2.2.12 2006/08/16 03:18:14 marka Exp $ */
+/* $Id: sha2.c,v 1.2.2.14 2009/01/19 23:46:16 tbox Exp $ */
 
 /*	$FreeBSD$	*/
 /*	$KAME: sha2.c,v 1.8 2001/11/08 01:07:52 itojun Exp $	*/
@@ -39,7 +39,7 @@
  * 3. Neither the name of the copyright holder nor the names of contributors
  *    may be used to endorse or promote products derived from this software
  *    without specific prior written permission.
- * 
+ *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) AND CONTRIBUTOR(S) ``AS IS'' AND
  * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
@@ -83,7 +83,7 @@
  * Please make sure that your system defines BYTE_ORDER.  If your
  * architecture is little-endian, make sure it also defines
  * LITTLE_ENDIAN and that the two (BYTE_ORDER and LITTLE_ENDIAN) are
- * equivilent.
+ * equivalent.
  *
  * If your system does not define the above, then you can do so by
  * hand like this:
@@ -93,7 +93,7 @@
  *
  * And for little-endian machines, add:
  *
- *   #define BYTE_ORDER LITTLE_ENDIAN 
+ *   #define BYTE_ORDER LITTLE_ENDIAN
  *
  * Or for big-endian machines:
  *
@@ -414,12 +414,12 @@ isc_sha224_init(isc_sha224_t *context) {
 	context->bitcount = 0;
 }
 
-void 
+void
 isc_sha224_update(isc_sha224_t *context, const isc_uint8_t* data, size_t len) {
 	isc_sha256_update((isc_sha256_t *)context, data, len);
 }
 
-void 
+void
 isc_sha224_final(isc_uint8_t digest[], isc_sha224_t *context) {
 	isc_uint8_t sha256_digest[ISC_SHA256_DIGESTLENGTH];
 	isc_sha256_final(sha256_digest, (isc_sha256_t *)context);
@@ -453,7 +453,7 @@ isc_sha224_end(isc_sha224_t *context, char buffer[]) {
 
 char*
 isc_sha224_data(const isc_uint8_t *data, size_t len,
-	        char digest[ISC_SHA224_DIGESTSTRINGLENGTH])
+		char digest[ISC_SHA224_DIGESTSTRINGLENGTH])
 {
 	isc_sha224_t context;
 
@@ -483,7 +483,7 @@ isc_sha256_init(isc_sha256_t *context) {
 #define ROUND256_0_TO_15(a,b,c,d,e,f,g,h)	\
 	REVERSE32(*data++, W256[j]); \
 	T1 = (h) + Sigma1_256(e) + Ch((e), (f), (g)) + \
-             K256[j] + W256[j]; \
+	     K256[j] + W256[j]; \
 	(d) += T1; \
 	(h) = T1 + Sigma0_256(a) + Maj((a), (b), (c)); \
 	j++
@@ -615,11 +615,11 @@ isc_sha256_transform(isc_sha256_t *context, const isc_uint32_t* data) {
 		/* Part of the message block expansion: */
 		s0 = W256[(j+1)&0x0f];
 		s0 = sigma0_256(s0);
-		s1 = W256[(j+14)&0x0f];	
+		s1 = W256[(j+14)&0x0f];
 		s1 = sigma1_256(s1);
 
 		/* Apply the SHA-256 compression function to update a..h */
-		T1 = h + Sigma1_256(e) + Ch(e, f, g) + K256[j] + 
+		T1 = h + Sigma1_256(e) + Ch(e, f, g) + K256[j] +
 		     (W256[j&0x0f] += s1 + W256[(j+9)&0x0f] + s0);
 		T2 = Sigma0_256(a) + Maj(a, b, c);
 		h = g;
@@ -828,7 +828,7 @@ isc_sha512_init(isc_sha512_t *context) {
 #define ROUND512_0_TO_15(a,b,c,d,e,f,g,h)	\
 	REVERSE64(*data++, W512[j]); \
 	T1 = (h) + Sigma1_512(e) + Ch((e), (f), (g)) + \
-             K512[j] + W512[j]; \
+	     K512[j] + W512[j]; \
 	(d) += T1, \
 	(h) = T1 + Sigma0_512(a) + Maj((a), (b), (c)), \
 	j++
@@ -838,7 +838,7 @@ isc_sha512_init(isc_sha512_t *context) {
 
 #define ROUND512_0_TO_15(a,b,c,d,e,f,g,h)	\
 	T1 = (h) + Sigma1_512(e) + Ch((e), (f), (g)) + \
-             K512[j] + (W512[j] = *data++); \
+	     K512[j] + (W512[j] = *data++); \
 	(d) += T1; \
 	(h) = T1 + Sigma0_512(a) + Maj((a), (b), (c)); \
 	j++
@@ -851,7 +851,7 @@ isc_sha512_init(isc_sha512_t *context) {
 	s1 = W512[(j+14)&0x0f]; \
 	s1 = sigma1_512(s1); \
 	T1 = (h) + Sigma1_512(e) + Ch((e), (f), (g)) + K512[j] + \
-             (W512[j&0x0f] += s1 + W512[(j+9)&0x0f] + s0); \
+	     (W512[j&0x0f] += s1 + W512[(j+9)&0x0f] + s0); \
 	(d) += T1; \
 	(h) = T1 + Sigma0_512(a) + Maj((a), (b), (c)); \
 	j++
@@ -1163,12 +1163,12 @@ isc_sha384_init(isc_sha384_t *context) {
 	context->bitcount[0] = context->bitcount[1] = 0;
 }
 
-void 
+void
 isc_sha384_update(isc_sha384_t *context, const isc_uint8_t* data, size_t len) {
 	isc_sha512_update((isc_sha512_t *)context, data, len);
 }
 
-void 
+void
 isc_sha384_final(isc_uint8_t digest[], isc_sha384_t *context) {
 	isc_uint64_t	*d = (isc_uint64_t*)digest;
 
@@ -1224,7 +1224,7 @@ isc_sha384_end(isc_sha384_t *context, char buffer[]) {
 
 char*
 isc_sha384_data(const isc_uint8_t *data, size_t len,
-	        char digest[ISC_SHA384_DIGESTSTRINGLENGTH])
+		char digest[ISC_SHA384_DIGESTSTRINGLENGTH])
 {
 	isc_sha384_t context;
 
diff --git a/lib/isc/timer.c b/lib/isc/timer.c
index c27281de1264..03ec40a9ceef 100644
--- a/lib/isc/timer.c
+++ b/lib/isc/timer.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: timer.c,v 1.73.18.10 2008/08/22 05:59:04 marka Exp $ */
+/* $Id: timer.c,v 1.73.18.14 2009/01/23 23:46:08 tbox Exp $ */
 
 /*! \file */
 
@@ -662,7 +662,7 @@ dispatch(isc_timermgr_t *manager, isc_time_t *now) {
 					isc_task_send(timer->task,
 						      ISC_EVENT_PTR(&event));
 				} else
-					UNEXPECTED_ERROR(__FILE__, __LINE__,
+					UNEXPECTED_ERROR(__FILE__, __LINE__, "%s",
 						 isc_msgcat_get(isc_msgcat,
 							 ISC_MSGSET_TIMER,
 							 ISC_MSG_EVENTNOTALLOC,
@@ -678,11 +678,12 @@ dispatch(isc_timermgr_t *manager, isc_time_t *now) {
 				result = schedule(timer, now, ISC_FALSE);
 				if (result != ISC_R_SUCCESS)
 					UNEXPECTED_ERROR(__FILE__, __LINE__,
+							 "%s: %u",
 						isc_msgcat_get(isc_msgcat,
 							ISC_MSGSET_TIMER,
 							ISC_MSG_SCHEDFAIL,
-							"couldn't "
-							"schedule timer: %u"),
+							"couldn't schedule "
+							"timer"),
 							 result);
 			}
 		} else {
diff --git a/lib/isc/unix/dir.c b/lib/isc/unix/dir.c
index b627c884256c..5c921cd03ec8 100644
--- a/lib/isc/unix/dir.c
+++ b/lib/isc/unix/dir.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dir.c,v 1.20.18.3 2005/09/05 00:18:30 marka Exp $ */
+/* $Id: dir.c,v 1.20.18.7 2009/02/16 23:46:03 tbox Exp $ */
 
 /*! \file
  * \author  Principal Authors: DCL */
@@ -93,7 +93,7 @@ isc_dir_open(isc_dir_t *dir, const char *dirname) {
 }
 
 /*!
- * \brief Return previously retrieved file or get next one.  
+ * \brief Return previously retrieved file or get next one.
 
  * Unix's dirent has
  * separate open and read functions, but the Win32 and DOS interfaces open
@@ -171,10 +171,14 @@ isc_dir_chroot(const char *dirname) {
 
 	REQUIRE(dirname != NULL);
 
-	if (chroot(dirname) < 0)
+#ifdef HAVE_CHROOT
+	if (chroot(dirname) < 0 || chdir("/") < 0)
 		return (isc__errno2result(errno));
 
 	return (ISC_R_SUCCESS);
+#else
+	return (ISC_R_NOTIMPLEMENTED);
+#endif
 }
 
 isc_result_t
diff --git a/lib/isc/unix/entropy.c b/lib/isc/unix/entropy.c
index 4c0d0d0cb9ff..0192ac1e2611 100644
--- a/lib/isc/unix/entropy.c
+++ b/lib/isc/unix/entropy.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: entropy.c,v 1.71.18.7 2006/12/07 04:53:03 marka Exp $ */
+/* $Id: entropy.c,v 1.71.18.9 2008/12/01 23:45:57 tbox Exp $ */
 
 /* \file unix/entropy.c
  * \brief
@@ -31,6 +31,9 @@
 #include 
 #include 
 
+#ifdef HAVE_NANOSLEEP
+#include 
+#endif
 #include 
 
 #include 
@@ -153,12 +156,12 @@ get_from_usocketsource(isc_entropysource_t *source, isc_uint32_t desired) {
 				source->sources.usocket.status =
 					isc_usocketsource_ndesired;
 				goto eagain_loop;
-			}	
+			}
 			INSIST(n == 2);
 			source->sources.usocket.status =
 						isc_usocketsource_wrote;
 			/*FALLTHROUGH*/
-		
+
 		case isc_usocketsource_wrote:
 			if (recvfrom(fd, buf, 1, 0, NULL, NULL) != 1) {
 				if (errno == EAGAIN) {
@@ -166,15 +169,23 @@ get_from_usocketsource(isc_entropysource_t *source, isc_uint32_t desired) {
 					 * The problem of EAGAIN (try again
 					 * later) is a major issue on HP-UX.
 					 * Solaris actually tries the recvfrom
-					 * call again, while HP-UX just dies. 
+					 * call again, while HP-UX just dies.
 					 * This code is an attempt to let the
 					 * entropy pool fill back up (at least
 					 * that's what I think the problem is.)
-					 * We go to eagain_loop because if we 
+					 * We go to eagain_loop because if we
 					 * just "break", then the "desired"
 					 * amount gets borked.
 					 */
+#ifdef HAVE_NANOSLEEP
+					struct timespec ts;
+
+					ts.tv_sec = 0;
+					ts.tv_nsec = 1000000;
+					nanosleep(&ts, NULL);
+#else
 					usleep(1000);
+#endif
 					goto eagain_loop;
 				}
 				if (errno == EWOULDBLOCK || errno == EINTR)
@@ -201,7 +212,7 @@ get_from_usocketsource(isc_entropysource_t *source, isc_uint32_t desired) {
 			} else
 				n = 0;
 			break;
-		
+
 		default:
 			goto err;
 		}
@@ -491,7 +502,7 @@ isc_entropy_createfilesource(isc_entropy_t *ent, const char *fname) {
 		ret = isc__errno2result(errno);
 		goto errout;
 	}
-	/* 
+	/*
 	 * Solaris 2.5.1 does not have support for sockets (S_IFSOCK),
 	 * but it does return type S_IFIFO (the OS believes that
 	 * the socket is a fifo).  This may be an issue if we tell
diff --git a/lib/isc/unix/file.c b/lib/isc/unix/file.c
index e45e0fe68b6c..700edb147433 100644
--- a/lib/isc/unix/file.c
+++ b/lib/isc/unix/file.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -48,7 +48,7 @@
  * SUCH DAMAGE.
  */
 
-/* $Id: file.c,v 1.47.18.2 2005/04/29 00:17:07 marka Exp $ */
+/* $Id: file.c,v 1.47.18.4 2009/02/16 23:46:03 tbox Exp $ */
 
 /*! \file */
 
@@ -67,6 +67,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -235,7 +236,9 @@ isc_file_renameunique(const char *file, char *templet) {
 			}
 		}
 	}
-	(void)unlink(file);
+	if (unlink(file) < 0)
+		if (errno != ENOENT)
+			return (isc__errno2result(errno));
 	return (ISC_R_SUCCESS);
 }
 
@@ -287,7 +290,11 @@ isc_file_openunique(char *templet, FILE **fp) {
 	f = fdopen(fd, "w+");
 	if (f == NULL) {
 		result = isc__errno2result(errno);
-		(void)remove(templet);
+		if (remove(templet) < 0) {
+			isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL,
+				      ISC_LOGMODULE_FILE, ISC_LOG_ERROR,
+				      "remove '%s': failed", templet);
+		}
 		(void)close(fd);
 	} else
 		*fp = f;
@@ -386,7 +393,7 @@ isc_file_progname(const char *filename, char *buf, size_t buflen) {
 
 /*
  * Put the absolute name of the current directory into 'dirname', which is
- * a buffer of at least 'length' characters.  End the string with the 
+ * a buffer of at least 'length' characters.  End the string with the
  * appropriate path separator, such that the final product could be
  * concatenated with a relative pathname to make a valid pathname string.
  */
@@ -431,7 +438,7 @@ isc_result_t
 isc_file_truncate(const char *filename, isc_offset_t size) {
 	isc_result_t result = ISC_R_SUCCESS;
 
-	if (truncate(filename, size) < 0) 
+	if (truncate(filename, size) < 0)
 		result = isc__errno2result(errno);
 	return (result);
 }
diff --git a/lib/isc/unix/ifiter_getifaddrs.c b/lib/isc/unix/ifiter_getifaddrs.c
index 3599a89355dd..57e90ed00fe9 100644
--- a/lib/isc/unix/ifiter_getifaddrs.c
+++ b/lib/isc/unix/ifiter_getifaddrs.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ifiter_getifaddrs.c,v 1.4.18.5 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: ifiter_getifaddrs.c,v 1.4.18.7 2009/09/24 23:46:07 tbox Exp $ */
 
 /*! \file
  * \brief
@@ -148,7 +148,7 @@ internal_current(isc_interfaceiter_t *iter) {
 			 ifa->ifa_name);
 
 	if (ifa->ifa_dstaddr != NULL &&
-	    (iter->current.flags & IFF_POINTOPOINT) != 0)
+	    (iter->current.flags & INTERFACE_F_POINTTOPOINT) != 0)
 		get_addr(family, &iter->current.dstaddress, ifa->ifa_dstaddr,
 			 ifa->ifa_name);
 
diff --git a/lib/isc/unix/ifiter_ioctl.c b/lib/isc/unix/ifiter_ioctl.c
index ce63de7ec79b..5d50ea5465d0 100644
--- a/lib/isc/unix/ifiter_ioctl.c
+++ b/lib/isc/unix/ifiter_ioctl.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ifiter_ioctl.c,v 1.44.18.13 2007/08/31 23:46:25 tbox Exp $ */
+/* $Id: ifiter_ioctl.c,v 1.44.18.17 2009/01/19 23:46:16 tbox Exp $ */
 
 /*! \file
  * \brief
@@ -104,7 +104,7 @@ struct isc_interfaceiter {
 #ifdef __linux
 #ifndef IF_NAMESIZE
 # ifdef IFNAMSIZ
-#  define IF_NAMESIZE  IFNAMSIZ  
+#  define IF_NAMESIZE  IFNAMSIZ
 # else
 #  define IF_NAMESIZE 16
 # endif
@@ -126,7 +126,7 @@ getbuf4(isc_interfaceiter_t *iter) {
 		iter->ifc.ifc_len = iter->bufsize;
 		iter->ifc.ifc_buf = iter->buf;
 		/*
-		 * Ignore the HP/UX warning about "interger overflow during
+		 * Ignore the HP/UX warning about "integer overflow during
 		 * conversion".  It comes from its own macro definition,
 		 * and is really hard to shut up.
 		 */
@@ -206,7 +206,7 @@ getbuf6(isc_interfaceiter_t *iter) {
 		iter->lifc.lifc_len = iter->bufsize6;
 		iter->lifc.lifc_buf = iter->buf6;
 		/*
-		 * Ignore the HP/UX warning about "interger overflow during
+		 * Ignore the HP/UX warning about "integer overflow during
 		 * conversion".  It comes from its own macro definition,
 		 * and is really hard to shut up.
 		 */
@@ -394,7 +394,7 @@ isc_interfaceiter_create(isc_mem_t *mctx, isc_interfaceiter_t **iterp) {
 		(void) close(iter->socket6);
   socket6_failure:
 #endif
- 
+
 	isc_mem_put(mctx, iter, sizeof(*iter));
 	return (result);
 }
@@ -479,8 +479,8 @@ linux_if_inet6_current(isc_interfaceiter_t *iter) {
 	for (i = 0; i < 16; i++) {
 		unsigned char byte;
 		static const char hex[] = "0123456789abcdef";
-		byte = ((index(hex, address[i * 2]) - hex) << 4) |
-		       (index(hex, address[i * 2 + 1]) - hex);
+		byte = ((strchr(hex, address[i * 2]) - hex) << 4) |
+		       (strchr(hex, address[i * 2 + 1]) - hex);
 		addr6.s6_addr[i] = byte;
 	}
 	iter->current.af = AF_INET6;
@@ -588,7 +588,7 @@ internal_current4(isc_interfaceiter_t *iter) {
 	iter->current.flags = 0;
 
 	/*
-	 * Ignore the HP/UX warning about "interger overflow during
+	 * Ignore the HP/UX warning about "integer overflow during
 	 * conversion.  It comes from its own macro definition,
 	 * and is really hard to shut up.
 	 */
@@ -666,7 +666,7 @@ internal_current4(isc_interfaceiter_t *iter) {
 	 */
 	if ((iter->current.flags & INTERFACE_F_POINTTOPOINT) != 0) {
 		/*
-		 * Ignore the HP/UX warning about "interger overflow during
+		 * Ignore the HP/UX warning about "integer overflow during
 		 * conversion.  It comes from its own macro definition,
 		 * and is really hard to shut up.
 		 */
@@ -693,7 +693,7 @@ internal_current4(isc_interfaceiter_t *iter) {
 	memset(&ifreq, 0, sizeof(ifreq));
 	memcpy(&ifreq, ifrp, sizeof(ifreq));
 	/*
-	 * Ignore the HP/UX warning about "interger overflow during
+	 * Ignore the HP/UX warning about "integer overflow during
 	 * conversion.  It comes from its own macro definition,
 	 * and is really hard to shut up.
 	 */
@@ -776,7 +776,7 @@ internal_current6(isc_interfaceiter_t *iter) {
 		fd = iter->socket;
 
 	/*
-	 * Ignore the HP/UX warning about "interger overflow during
+	 * Ignore the HP/UX warning about "integer overflow during
 	 * conversion.  It comes from its own macro definition,
 	 * and is really hard to shut up.
 	 */
@@ -805,7 +805,7 @@ internal_current6(isc_interfaceiter_t *iter) {
 	 */
 	if ((iter->current.flags & INTERFACE_F_POINTTOPOINT) != 0) {
 		/*
-		 * Ignore the HP/UX warning about "interger overflow during
+		 * Ignore the HP/UX warning about "integer overflow during
 		 * conversion.  It comes from its own macro definition,
 		 * and is really hard to shut up.
 		 */
@@ -855,7 +855,7 @@ internal_current6(isc_interfaceiter_t *iter) {
 #endif
 
 	/*
-	 * Ignore the HP/UX warning about "interger overflow during
+	 * Ignore the HP/UX warning about "integer overflow during
 	 * conversion.  It comes from its own macro definition,
 	 * and is really hard to shut up.
 	 */
@@ -906,7 +906,7 @@ internal_next4(isc_interfaceiter_t *iter) {
 #endif
 
 	REQUIRE(iter->ifc.ifc_len == 0 ||
-	        iter->pos < (unsigned int) iter->ifc.ifc_len);
+		iter->pos < (unsigned int) iter->ifc.ifc_len);
 
 #ifdef __linux
 	if (linux_if_inet6_next(iter) == ISC_R_SUCCESS)
@@ -939,7 +939,7 @@ internal_next6(isc_interfaceiter_t *iter) {
 #ifdef ISC_PLATFORM_HAVESALEN
 	struct LIFREQ *ifrp;
 #endif
-	
+
 	if (iter->result6 != ISC_R_SUCCESS && iter->result6 != ISC_R_IGNORE)
 		return (iter->result6);
 
diff --git a/lib/isc/unix/include/isc/net.h b/lib/isc/unix/include/isc/net.h
index 948e7b19d3d4..87c04eb99b7b 100644
--- a/lib/isc/unix/include/isc/net.h
+++ b/lib/isc/unix/include/isc/net.h
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: net.h,v 1.39.18.6 2008/06/24 23:45:55 tbox Exp $ */
+/* $Id: net.h,v 1.39.18.8 2008/12/01 04:13:20 marka Exp $ */
 
 #ifndef ISC_NET_H
 #define ISC_NET_H 1
@@ -354,11 +354,10 @@ isc_net_pton(int af, const char *src, void *dst);
 #define inet_pton isc_net_pton
 #endif
 
-#ifdef ISC_PLATFORM_NEEDATON
 int
 isc_net_aton(const char *cp, struct in_addr *addr);
+#undef inet_aton
 #define inet_aton isc_net_aton
-#endif
 
 ISC_LANG_ENDDECLS
 
diff --git a/lib/isc/unix/include/isc/offset.h b/lib/isc/unix/include/isc/offset.h
index 15fbad4fdb21..eedf23b60e9e 100644
--- a/lib/isc/unix/include/isc/offset.h
+++ b/lib/isc/unix/include/isc/offset.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: offset.h,v 1.11.18.2 2005/04/29 00:17:10 marka Exp $ */
+/* $Id: offset.h,v 1.11.18.4 2008/12/01 23:45:57 tbox Exp $ */
 
 #ifndef ISC_OFFSET_H
 #define ISC_OFFSET_H 1
@@ -26,6 +26,7 @@
  */
 #include              /* Required for CHAR_BIT. */
 #include 
+#include 		/* For Linux Standard Base. */
 
 typedef off_t isc_offset_t;
 
diff --git a/lib/isc/unix/include/isc/strerror.h b/lib/isc/unix/include/isc/strerror.h
index fb2e8a48a965..5913b05b0564 100644
--- a/lib/isc/unix/include/isc/strerror.h
+++ b/lib/isc/unix/include/isc/strerror.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: strerror.h,v 1.4.18.2 2005/04/29 00:17:10 marka Exp $ */
+/* $Id: strerror.h,v 1.4.18.4 2008/12/01 23:45:57 tbox Exp $ */
 
 #ifndef ISC_STRERROR_H
 #define ISC_STRERROR_H
@@ -32,7 +32,7 @@ ISC_LANG_BEGINDECLS
 #define ISC_STRERRORSIZE 128
 
 /*%
- * Provide a thread safe wrapper to strerrror().
+ * Provide a thread safe wrapper to strerror().
  *
  * Requires:
  * 	'buf' to be non NULL.
diff --git a/lib/isc/unix/include/isc/time.h b/lib/isc/unix/include/isc/time.h
index 65794392a7ea..739b69204a57 100644
--- a/lib/isc/unix/include/isc/time.h
+++ b/lib/isc/unix/include/isc/time.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: time.h,v 1.30.18.2 2005/04/29 00:17:10 marka Exp $ */
+/* $Id: time.h,v 1.30.18.5 2009/01/06 23:45:57 tbox Exp $ */
 
 #ifndef ISC_TIME_H
 #define ISC_TIME_H 1
@@ -29,7 +29,7 @@
  *** Intervals
  ***/
 
-/*! 
+/*!
  *  \brief
  * The contents of this structure are private, and MUST NOT be accessed
  * directly by callers.
@@ -274,7 +274,7 @@ isc_time_nanoseconds(const isc_time_t *t);
  * Return the number of nanoseconds stored in a time structure.
  *
  * Notes:
- *\li	This is the number of nanoseconds in excess of the the number
+ *\li	This is the number of nanoseconds in excess of the number
  *	of seconds since the epoch; it will always be less than one
  *	full second.
  *
diff --git a/lib/isc/unix/resource.c b/lib/isc/unix/resource.c
index e9bc5fd6bd17..0a51e4fcaf6c 100644
--- a/lib/isc/unix/resource.c
+++ b/lib/isc/unix/resource.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resource.c,v 1.12.18.6 2008/08/05 07:17:05 marka Exp $ */
+/* $Id: resource.c,v 1.12.18.8 2009/02/13 23:46:06 tbox Exp $ */
 
 #include 
 
@@ -159,7 +159,11 @@ isc_resource_setlimit(isc_resource_t resource, isc_resourcevalue_t value) {
 		if (unixresult == 0)
 			return (ISC_R_SUCCESS);
 	}
-#elif defined(NR_OPEN) && defined(__linux__)
+#elif defined(__linux__)
+#ifndef NR_OPEN
+#define NR_OPEN (1024*1024)
+#endif
+
 	/*
 	 * Some Linux kernels don't accept RLIM_INFINIT; the maximum
 	 * possible value is the NR_OPEN defined in linux/fs.h.
diff --git a/lib/isc/unix/socket.c b/lib/isc/unix/socket.c
index 8b006e46b6fa..023f71a86fcf 100644
--- a/lib/isc/unix/socket.c
+++ b/lib/isc/unix/socket.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket.c,v 1.237.18.56.2.1 2008/12/23 00:14:34 marka Exp $ */
+/* $Id: socket.c,v 1.237.18.68 2009/09/07 02:17:09 marka Exp $ */
 
 /*! \file */
 
@@ -268,7 +268,7 @@ typedef isc_event_t intev_t;
 #endif
 
 /*%
- * The size to raise the recieve buffer to (from BIND 8).
+ * The size to raise the receive buffer to (from BIND 8).
  */
 #define RCVBUFSIZE (32*1024)
 
@@ -1119,7 +1119,7 @@ build_msghdr_send(isc_socket_t *sock, isc_socketevent_t *dev,
 
 /*
  * Construct an iov array and attach it to the msghdr passed in.  This is
- * the RECV constructor, which will use the avialable region of the buffer
+ * the RECV constructor, which will use the available region of the buffer
  * (if using a buffer list) or will use the internal region (if a single
  * buffer I/O is requested).
  *
@@ -2257,17 +2257,14 @@ isc_socket_detach(isc_socket_t **socketp) {
 isc_result_t
 isc_socket_close(isc_socket_t *sock) {
 	int fd;
+	isc_socketmgr_t *manager;
+	isc_sockettype_t type;
 
 	REQUIRE(VALID_SOCKET(sock));
 
 	LOCK(&sock->lock);
-	REQUIRE(sock->references == 1);
-	UNLOCK(&sock->lock);
-	/*
-	 * We don't need to retain the lock hereafter, since no one else has
-	 * this socket.
-	 */
 
+	REQUIRE(sock->references == 1);
 	REQUIRE(sock->fd >= 0 && sock->fd < (int)sock->manager->maxsocks);
 
 	INSIST(!sock->connecting);
@@ -2279,6 +2276,8 @@ isc_socket_close(isc_socket_t *sock) {
 	INSIST(ISC_LIST_EMPTY(sock->accept_list));
 	INSIST(sock->connect_ev == NULL);
 
+	manager = sock->manager;
+	type = sock->type;
 	fd = sock->fd;
 	sock->fd = -1;
 	sock->listener = 0;
@@ -2286,8 +2285,9 @@ isc_socket_close(isc_socket_t *sock) {
 	sock->connecting = 0;
 	sock->bound = 0;
 	isc_sockaddr_any(&sock->address);
+	UNLOCK(&sock->lock);
 
-	closesocket(sock->manager, sock->type, fd);
+	closesocket(manager, type, fd);
 
 	return (ISC_R_SUCCESS);
 }
@@ -2517,7 +2517,7 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 	 * a documented error for accept().  ECONNABORTED has been
 	 * reported for Solaris 8.  The rest are thrown in not because
 	 * we have seen them but because they are ignored by other
-	 * deamons such as BIND 8 and Apache.
+	 * daemons such as BIND 8 and Apache.
 	 */
 
 	addrlen = sizeof(dev->newsocket->address.type);
@@ -2826,6 +2826,7 @@ process_fd(isc_socketmgr_t *manager, int fd, isc_boolean_t readable,
 {
 	isc_socket_t *sock;
 	isc_boolean_t unlock_sock;
+	isc_boolean_t unwatch_read = ISC_FALSE, unwatch_write = ISC_FALSE;
 	int lockid = FDLOCK_ID(fd);
 
 	/*
@@ -2841,11 +2842,10 @@ process_fd(isc_socketmgr_t *manager, int fd, isc_boolean_t readable,
 	}
 
 	sock = manager->fds[fd];
-	UNLOCK(&manager->fdlock[lockid]);
 	unlock_sock = ISC_FALSE;
 	if (readable) {
 		if (sock == NULL) {
-			(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+			unwatch_read = ISC_TRUE;
 			goto check_write;
 		}
 		unlock_sock = ISC_TRUE;
@@ -2856,13 +2856,13 @@ process_fd(isc_socketmgr_t *manager, int fd, isc_boolean_t readable,
 			else
 				dispatch_recv(sock);
 		}
-		(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+		unwatch_read = ISC_TRUE;
 	}
 check_write:
 	if (writeable) {
 		if (sock == NULL) {
-			(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
-			return;
+			unwatch_write = ISC_TRUE;
+			goto unlock_fd;
 		}
 		if (!unlock_sock) {
 			unlock_sock = ISC_TRUE;
@@ -2874,10 +2874,18 @@ check_write:
 			else
 				dispatch_send(sock);
 		}
-		(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
+		unwatch_write = ISC_TRUE;
 	}
 	if (unlock_sock)
 		UNLOCK(&sock->lock);
+
+ unlock_fd:
+	UNLOCK(&manager->fdlock[lockid]);
+	if (unwatch_read)
+		(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+	if (unwatch_write)
+		(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
+
 }
 
 #ifdef USE_KQUEUE
@@ -3184,7 +3192,7 @@ watcher(void *uap) {
 #endif
 	}
 
-	manager_log(manager, TRACE,
+	manager_log(manager, TRACE, "%s",
 		    isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
 				   ISC_MSG_EXITING, "watcher exiting"));
 
@@ -3207,6 +3215,9 @@ isc__socketmgr_setreserved(isc_socketmgr_t *manager, isc_uint32_t reserved) {
 static isc_result_t
 setup_watcher(isc_mem_t *mctx, isc_socketmgr_t *manager) {
 	isc_result_t result;
+#if defined(USE_KQUEUE) || defined(USE_EPOLL) || defined(USE_DEVPOLL)
+	char strbuf[ISC_STRERRORSIZE];
+#endif
 
 #ifdef USE_KQUEUE
 	manager->nevents = ISC_SOCKET_MAXEVENTS;
@@ -3217,6 +3228,12 @@ setup_watcher(isc_mem_t *mctx, isc_socketmgr_t *manager) {
 	manager->kqueue_fd = kqueue();
 	if (manager->kqueue_fd == -1) {
 		result = isc__errno2result(errno);
+		isc__strerror(errno, strbuf, sizeof(strbuf));
+		UNEXPECTED_ERROR(__FILE__, __LINE__,
+				 "kqueue %s: %s",
+				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
+						ISC_MSG_FAILED, "failed"),
+				 strbuf);
 		isc_mem_put(mctx, manager->events,
 			    sizeof(struct kevent) * manager->nevents);
 		return (result);
@@ -3240,6 +3257,12 @@ setup_watcher(isc_mem_t *mctx, isc_socketmgr_t *manager) {
 	manager->epoll_fd = epoll_create(manager->nevents);
 	if (manager->epoll_fd == -1) {
 		result = isc__errno2result(errno);
+		isc__strerror(errno, strbuf, sizeof(strbuf));
+		UNEXPECTED_ERROR(__FILE__, __LINE__,
+				 "epoll_create %s: %s",
+				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
+						ISC_MSG_FAILED, "failed"),
+				 strbuf);
 		isc_mem_put(mctx, manager->events,
 			    sizeof(struct epoll_event) * manager->nevents);
 		return (result);
@@ -3271,13 +3294,19 @@ setup_watcher(isc_mem_t *mctx, isc_socketmgr_t *manager) {
 					  manager->maxsocks);
 	if (manager->fdpollinfo == NULL) {
 		isc_mem_put(mctx, manager->events,
-			    sizeof(pollinfo_t) * manager->maxsocks);
+			    sizeof(struct pollfd) * manager->nevents);
 		return (ISC_R_NOMEMORY);
 	}
 	memset(manager->fdpollinfo, 0, sizeof(pollinfo_t) * manager->maxsocks);
 	manager->devpoll_fd = open("/dev/poll", O_RDWR);
 	if (manager->devpoll_fd == -1) {
 		result = isc__errno2result(errno);
+		isc__strerror(errno, strbuf, sizeof(strbuf));
+		UNEXPECTED_ERROR(__FILE__, __LINE__,
+				 "open(/dev/poll) %s: %s",
+				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
+						ISC_MSG_FAILED, "failed"),
+				 strbuf);
 		isc_mem_put(mctx, manager->events,
 			    sizeof(struct pollfd) * manager->nevents);
 		isc_mem_put(mctx, manager->fdpollinfo,
@@ -3441,7 +3470,7 @@ isc_socketmgr_create2(isc_mem_t *mctx, isc_socketmgr_t **managerp,
 		goto free_manager;
 	}
 	manager->fdstate = isc_mem_get(mctx, manager->maxsocks * sizeof(int));
-	if (manager->fds == NULL) {
+	if (manager->fdstate == NULL) {
 		result = ISC_R_NOMEMORY;
 		goto free_manager;
 	}
@@ -3610,7 +3639,7 @@ isc_socketmgr_destroy(isc_socketmgr_t **managerp) {
 	 * Wait for all sockets to be destroyed.
 	 */
 	while (!ISC_LIST_EMPTY(manager->socklist)) {
-		manager_log(manager, CREATION,
+		manager_log(manager, CREATION, "%s",
 			    isc_msgcat_get(isc_msgcat, ISC_MSGSET_SOCKET,
 					   ISC_MSG_SOCKETSREMAIN,
 					   "sockets exist"));
@@ -3621,7 +3650,7 @@ isc_socketmgr_destroy(isc_socketmgr_t **managerp) {
 	 * Hope all sockets have been destroyed.
 	 */
 	if (!ISC_LIST_EMPTY(manager->socklist)) {
-		manager_log(manager, CREATION,
+		manager_log(manager, CREATION, "%s",
 			    isc_msgcat_get(isc_msgcat, ISC_MSGSET_SOCKET,
 					   ISC_MSG_SOCKETSREMAIN,
 					   "sockets exist"));
@@ -4453,6 +4482,7 @@ isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr,
 	isc_socketmgr_t *manager;
 	int cc;
 	char strbuf[ISC_STRERRORSIZE];
+	char addrbuf[ISC_SOCKADDR_FORMATSIZE];
 
 	REQUIRE(VALID_SOCKET(sock));
 	REQUIRE(addr != NULL);
@@ -4521,7 +4551,9 @@ isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr,
 		sock->connected = 0;
 
 		isc__strerror(errno, strbuf, sizeof(strbuf));
-		UNEXPECTED_ERROR(__FILE__, __LINE__, "%d/%s", errno, strbuf);
+		isc_sockaddr_format(addr, addrbuf, sizeof(addrbuf));
+		UNEXPECTED_ERROR(__FILE__, __LINE__, "connect(%s) %d/%s",
+				 addrbuf, errno, strbuf);
 
 		UNLOCK(&sock->lock);
 		isc_event_free(ISC_EVENT_PTR(&dev));
diff --git a/lib/isc/unix/strerror.c b/lib/isc/unix/strerror.c
index 18cc367e21d6..96cfb4e65069 100644
--- a/lib/isc/unix/strerror.c
+++ b/lib/isc/unix/strerror.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: strerror.c,v 1.4.18.2 2005/04/29 00:17:08 marka Exp $ */
+/* $Id: strerror.c,v 1.4.18.4 2009/02/16 23:46:03 tbox Exp $ */
 
 /*! \file */
 
@@ -47,7 +47,7 @@ void
 isc__strerror(int num, char *buf, size_t size) {
 #ifdef HAVE_STRERROR
 	char *msg;
-	unsigned int unum = num;
+	unsigned int unum = (unsigned int)num;
 	static isc_once_t once = ISC_ONCE_INIT;
 
 	REQUIRE(buf != NULL);
@@ -62,7 +62,7 @@ isc__strerror(int num, char *buf, size_t size) {
 		snprintf(buf, size, "Unknown error: %u", unum);
 	UNLOCK(&isc_strerror_lock);
 #else
-	unsigned int unum = num;
+	unsigned int unum = (unsigned int)num;
 
 	REQUIRE(buf != NULL);
 
diff --git a/lib/isc/x86_32/include/isc/atomic.h b/lib/isc/x86_32/include/isc/atomic.h
index f3136d9eaff2..c196300bc16f 100644
--- a/lib/isc/x86_32/include/isc/atomic.h
+++ b/lib/isc/x86_32/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.2.2.3 2005/07/27 04:23:33 marka Exp $ */
+/* $Id: atomic.h,v 1.2.2.5 2009/07/13 23:46:05 tbox Exp $ */
 
 #ifndef ISC_ATOMIC_H
 #define ISC_ATOMIC_H 1
@@ -28,6 +28,9 @@
  * returns the previous value.
  */
 static inline isc_int32_t
+#ifdef __GNUC__
+__attribute__ ((unused))
+#endif
 isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
 	isc_int32_t prev = val;
 
@@ -47,6 +50,9 @@ isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
  * This routine atomically stores the value 'val' in 'p'.
  */
 static inline void
+#ifdef __GNUC__
+__attribute__ ((unused))
+#endif
 isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
 	__asm__ volatile(
 #ifdef ISC_PLATFORM_USETHREADS
@@ -54,7 +60,7 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
 		 * xchg should automatically lock memory, but we add it
 		 * explicitly just in case (it at least doesn't harm)
 		 */
-		"lock;"		
+		"lock;"
 #endif
 
 		"xchgl %1, %0"
@@ -69,6 +75,9 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
  * case.
  */
 static inline isc_int32_t
+#ifdef __GNUC__
+__attribute__ ((unused))
+#endif
 isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 	__asm__ volatile(
 #ifdef ISC_PLATFORM_USETHREADS
diff --git a/lib/isccfg/include/isccfg/log.h b/lib/isccfg/include/isccfg/log.h
index f66c37ff7d05..1f627617b11d 100644
--- a/lib/isccfg/include/isccfg/log.h
+++ b/lib/isccfg/include/isccfg/log.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.h,v 1.6.18.2 2005/04/29 00:17:16 marka Exp $ */
+/* $Id: log.h,v 1.6.18.4 2009/01/19 23:46:17 tbox Exp $ */
 
 #ifndef ISCCFG_LOG_H
 #define ISCCFG_LOG_H 1
@@ -46,7 +46,7 @@ cfg_log_init(isc_log_t *lctx);
  *\li	cfg_log_init() is called only once.
  *
  * Ensures:
- * \li	The catgories and modules defined above are available for
+ * \li	The categories and modules defined above are available for
  * 	use by isc_log_usechannnel() and isc_log_write().
  */
 
diff --git a/lib/isccfg/include/isccfg/namedconf.h b/lib/isccfg/include/isccfg/namedconf.h
index 6125b26d54c2..89811ef241f3 100644
--- a/lib/isccfg/include/isccfg/namedconf.h
+++ b/lib/isccfg/include/isccfg/namedconf.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: namedconf.h,v 1.3.18.2 2005/04/29 00:17:16 marka Exp $ */
+/* $Id: namedconf.h,v 1.3.18.4 2009/06/25 23:46:08 tbox Exp $ */
 
 #ifndef ISCCFG_NAMEDCONF_H
 #define ISCCFG_NAMEDCONF_H 1
@@ -42,4 +42,4 @@ LIBISCCFG_EXTERNAL_DATA extern cfg_type_t cfg_type_rndckey;
 LIBISCCFG_EXTERNAL_DATA extern cfg_type_t cfg_type_keyref;
 /*%< A key reference, used as an ACL element */
 
-#endif /* ISCCFG_CFG_H */
+#endif /* ISCCFG_NAMEDCONF_H */
diff --git a/lib/lwres/api b/lib/lwres/api
index 0be3ae77fc2e..3d42fccad650 100644
--- a/lib/lwres/api
+++ b/lib/lwres/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 30
-LIBREVISION = 6
+LIBREVISION = 7
 LIBAGE = 0
diff --git a/lib/lwres/context.c b/lib/lwres/context.c
index c731bb746e46..ecab51c7d738 100644
--- a/lib/lwres/context.c
+++ b/lib/lwres/context.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: context.c,v 1.45.18.7 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: context.c,v 1.45.18.12 2009/09/01 23:46:02 tbox Exp $ */
 
-/*! \file context.c 
+/*! \file context.c
    lwres_context_create() creates a #lwres_context_t structure for use in
    lightweight resolver operations. It holds a socket and other data
    needed for communicating with a resolver daemon. The new
@@ -156,7 +156,6 @@ lwres_context_create(lwres_context_t **contextp, void *arg,
 	lwres_context_t *ctx;
 
 	REQUIRE(contextp != NULL && *contextp == NULL);
-	UNUSED(flags);
 
 	/*
 	 * If we were not given anything special to use, use our own
@@ -184,6 +183,17 @@ lwres_context_create(lwres_context_t **contextp, void *arg,
 	ctx->timeout = LWRES_DEFAULT_TIMEOUT;
 	ctx->serial = time(NULL); /* XXXMLG or BEW */
 
+	ctx->use_ipv4 = 1;
+	ctx->use_ipv6 = 1;
+	if ((flags & (LWRES_CONTEXT_USEIPV4 | LWRES_CONTEXT_USEIPV6)) ==
+	    LWRES_CONTEXT_USEIPV6) {
+		ctx->use_ipv4 = 0;
+	}
+	if ((flags & (LWRES_CONTEXT_USEIPV4 | LWRES_CONTEXT_USEIPV6)) ==
+	    LWRES_CONTEXT_USEIPV4) {
+		ctx->use_ipv6 = 0;
+	}
+
 	/*
 	 * Init resolv.conf bits.
 	 */
@@ -194,9 +204,9 @@ lwres_context_create(lwres_context_t **contextp, void *arg,
 }
 
 /*%
-Destroys a #lwres_context_t, closing its socket. 
-contextp is a pointer to a pointer to the context that is 
-to be destroyed. The pointer will be set to NULL 
+Destroys a #lwres_context_t, closing its socket.
+contextp is a pointer to a pointer to the context that is
+to be destroyed. The pointer will be set to NULL
 when the context has been destroyed.
  */
 void
@@ -449,7 +459,7 @@ lwres_context_sendrecv(lwres_context_t *ctx,
 	struct timeval timeout;
 
 	/*
-	 * Type of tv_sec is 32 bits long. 
+	 * Type of tv_sec is 32 bits long.
 	 */
 	if (ctx->timeout <= 0x7FFFFFFFU)
 		timeout.tv_sec = (int)ctx->timeout;
@@ -465,7 +475,7 @@ lwres_context_sendrecv(lwres_context_t *ctx,
 	FD_ZERO(&readfds);
 	FD_SET(ctx->sock, &readfds);
 	ret2 = select(ctx->sock + 1, &readfds, NULL, NULL, &timeout);
-	
+
 	/*
 	 * What happened with select?
 	 */
@@ -477,6 +487,6 @@ lwres_context_sendrecv(lwres_context_t *ctx,
 	result = lwres_context_recv(ctx, recvbase, recvlen, recvd_len);
 	if (result == LWRES_R_RETRY)
 		goto again;
-	
+
 	return (result);
 }
diff --git a/lib/lwres/context_p.h b/lib/lwres/context_p.h
index d255ef6d72be..ee83124710db 100644
--- a/lib/lwres/context_p.h
+++ b/lib/lwres/context_p.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: context_p.h,v 1.13.18.2 2005/04/29 00:17:17 marka Exp $ */
+/* $Id: context_p.h,v 1.13.18.4 2008/12/17 23:46:01 tbox Exp $ */
 
 #ifndef LWRES_CONTEXT_P_H
 #define LWRES_CONTEXT_P_H 1
@@ -46,6 +46,8 @@ struct lwres_context {
 	 */
 	int			sock;		/*%< socket to send on */
 	lwres_addr_t		address;	/*%< address to send to */
+	int			use_ipv4;	/*%< use IPv4 transaction */
+	int			use_ipv6;	/*%< use IPv6 transaction */
 
 	/*@{*/
 	/*
diff --git a/lib/lwres/getaddrinfo.c b/lib/lwres/getaddrinfo.c
index 6056f24c6e65..75fbb482e0cd 100644
--- a/lib/lwres/getaddrinfo.c
+++ b/lib/lwres/getaddrinfo.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * This code is derived from software contributed to ISC by
@@ -18,7 +18,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getaddrinfo.c,v 1.43.18.8 2007/09/13 23:46:26 tbox Exp $ */
+/* $Id: getaddrinfo.c,v 1.43.18.10 2008/11/25 23:46:01 tbox Exp $ */
 
 /*! \file */
 
@@ -31,10 +31,10 @@
  *    string: a dotted decimal IPv4 address or an IPv6 address. servname is
  *    either a decimal port number or a service name as listed in
  *    /etc/services.
- * 
+ *
  *    If the operating system does not provide a struct addrinfo, the
  *    following structure is used:
- * 
+ *
  * \code
  * struct  addrinfo {
  *         int             ai_flags;       // AI_PASSIVE, AI_CANONNAME
@@ -47,29 +47,29 @@
  *         struct addrinfo *ai_next;       // next structure in linked list
  * };
  * \endcode
- * 
- * 
+ *
+ *
  *    hints is an optional pointer to a struct addrinfo. This structure can
  *    be used to provide hints concerning the type of socket that the caller
  *    supports or wishes to use. The caller can supply the following
  *    structure elements in *hints:
- * 
+ *
  * 
    
  *    
  • ai_family:
  *           The protocol family that should be used. When ai_family is set
  *           to PF_UNSPEC, it means the caller will accept any protocol
  *           family supported by the operating system.
    • 
- * 
+ *
  *    
  • ai_socktype:
  *           denotes the type of socket -- SOCK_STREAM, SOCK_DGRAM or
  *           SOCK_RAW -- that is wanted. When ai_socktype is zero the caller
  *           will accept any socket type.
    • 
- * 
+ *
  *    
  • ai_protocol:
  *           indicates which transport protocol is wanted: IPPROTO_UDP or
  *           IPPROTO_TCP. If ai_protocol is zero the caller will accept any
  *           protocol.
    • 
- * 
+ *
  *    
  • ai_flags:
  *           Flag bits. If the AI_CANONNAME bit is set, a successful call to
  *           lwres_getaddrinfo() will return a null-terminated string
@@ -81,7 +81,7 @@
  *           address portion of the socket address structure will be set to
  *           INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6
  *           address.

    
- * 
+ *
  *           When ai_flags does not set the AI_PASSIVE bit, the returned
  *           socket address structure will be ready for use in a call to
  *           connect(2) for a connection-oriented protocol or connect(2),
@@ -89,18 +89,18 @@
  *           chosen. The IP address portion of the socket address structure
  *           will be set to the loopback address if hostname is a NULL
  *           pointer and AI_PASSIVE is not set in ai_flags.

    
- * 
+ *
  *           If ai_flags is set to AI_NUMERICHOST it indicates that hostname
  *           should be treated as a numeric string defining an IPv4 or IPv6
  *           address and no name resolution should be attempted.
  * 

- * 
+ *
  *    All other elements of the struct addrinfo passed via hints must be
  *    zero.
- * 
+ *
  *    A hints of NULL is treated as if the caller provided a struct addrinfo
  *    initialized to zero with ai_familyset to PF_UNSPEC.
- * 
+ *
  *    After a successful call to lwres_getaddrinfo(), *res is a pointer to a
  *    linked list of one or more addrinfo structures. Each struct addrinfo
  *    in this list cn be processed by following the ai_next pointer, until a
@@ -109,7 +109,7 @@
  *    corresponding arguments for a call to socket(2). For each addrinfo
  *    structure in the list, the ai_addr member points to a filled-in socket
  *    address structure of length ai_addrlen.
- * 
+ *
  *    All of the information returned by lwres_getaddrinfo() is dynamically
  *    allocated: the addrinfo structures, and the socket address structures
  *    and canonical host name strings pointed to by the addrinfostructures.
@@ -117,15 +117,15 @@
  *    successful call to lwres_getaddrinfo() is released by
  *    lwres_freeaddrinfo(). ai is a pointer to a struct addrinfo created by
  *    a call to lwres_getaddrinfo().
- * 
+ *
  * \section lwresreturn RETURN VALUES
- * 
+ *
  *    lwres_getaddrinfo() returns zero on success or one of the error codes
  *    listed in gai_strerror() if an error occurs. If both hostname and
  *    servname are NULL lwres_getaddrinfo() returns #EAI_NONAME.
- * 
+ *
  * \section lwressee SEE ALSO
- * 
+ *
  *    lwres(3), lwres_getaddrinfo(), lwres_freeaddrinfo(),
  *    lwres_gai_strerror(), RFC2133, getservbyname(3), connect(2),
  *    sendto(2), sendmsg(2), socket(2).
@@ -145,7 +145,7 @@
 #define SA(addr)	((struct sockaddr *)(addr))
 #define SIN(addr)	((struct sockaddr_in *)(addr))
 #define SIN6(addr)	((struct sockaddr_in6 *)(addr))
-#define SUN(addr)	((struct sockaddr_un *)(addr))
+#define SLOCAL(addr)	((struct sockaddr_un *)(addr))
 
 /*! \struct addrinfo
  */
@@ -162,7 +162,7 @@ static int add_ipv4(const char *hostname, int flags, struct addrinfo **aip,
 static int add_ipv6(const char *hostname, int flags, struct addrinfo **aip,
     int socktype, int port);
 static void set_order(int, int (**)(const char *, int, struct addrinfo **,
-         int, int));
+	 int, int));
 
 #define FOUND_IPV4	0x1
 #define FOUND_IPV6	0x2
@@ -384,7 +384,7 @@ lwres_getaddrinfo(const char *hostname, const char *servname,
 			scopeid = 0;
 #endif
 
-               if (lwres_net_pton(AF_INET, hostname, (struct in_addr *)abuf)
+	       if (lwres_net_pton(AF_INET, hostname, (struct in_addr *)abuf)
 		   == 1)
 	       {
 			if (family == AF_INET6) {
@@ -709,17 +709,17 @@ lwres_freeaddrinfo(struct addrinfo *ai) {
 static int
 get_local(const char *name, int socktype, struct addrinfo **res) {
 	struct addrinfo *ai;
-	struct sockaddr_un *sun;
+	struct sockaddr_un *slocal;
 
 	if (socktype == 0)
 		return (EAI_SOCKTYPE);
 
-	ai = ai_alloc(AF_LOCAL, sizeof(*sun));
+	ai = ai_alloc(AF_LOCAL, sizeof(*slocal));
 	if (ai == NULL)
 		return (EAI_MEMORY);
 
-	sun = SUN(ai->ai_addr);
-	strncpy(sun->sun_path, name, sizeof(sun->sun_path));
+	slocal = SLOCAL(ai->ai_addr);
+	strncpy(slocal->sun_path, name, sizeof(slocal->sun_path));
 
 	ai->ai_socktype = socktype;
 	/*
diff --git a/lib/lwres/getipnode.c b/lib/lwres/getipnode.c
index ab4981481a6d..e13f9cd32598 100644
--- a/lib/lwres/getipnode.c
+++ b/lib/lwres/getipnode.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getipnode.c,v 1.37.18.7 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: getipnode.c,v 1.37.18.10 2009/09/01 23:46:02 tbox Exp $ */
 
 /*! \file */
 
@@ -23,7 +23,7 @@
  *    These functions perform thread safe, protocol independent
  *    nodename-to-address and address-to-nodename translation as defined in
  *    RFC2553.  This use a struct hostent which is defined in namedb.h:
- * 
+ *
  * \code
  * struct  hostent {
  *         char    *h_name;        // official name of host
@@ -34,90 +34,90 @@
  * };
  * #define h_addr  h_addr_list[0]  // address, for backward compatibility
  * \endcode
- * 
+ *
  *    The members of this structure are:
- * 
+ *
  * \li   h_name:
  *           The official (canonical) name of the host.
- * 
+ *
  * \li   h_aliases:
  *           A NULL-terminated array of alternate names (nicknames) for the
  *           host.
- * 
+ *
  * \li   h_addrtype:
  *           The type of address being returned - usually PF_INET or
  *           PF_INET6.
- * 
+ *
  * \li   h_length:
  *           The length of the address in bytes.
- * 
+ *
  * \li   h_addr_list:
  *           A NULL terminated array of network addresses for the host. Host
  *           addresses are returned in network byte order.
- * 
+ *
  *    lwres_getipnodebyname() looks up addresses of protocol family af for
  *    the hostname name. The flags parameter contains ORed flag bits to
  *    specify the types of addresses that are searched for, and the types of
  *    addresses that are returned. The flag bits are:
- * 
+ *
  * \li   #AI_V4MAPPED:
  *           This is used with an af of #AF_INET6, and causes IPv4 addresses
  *           to be returned as IPv4-mapped IPv6 addresses.
- * 
+ *
  * \li   #AI_ALL:
  *           This is used with an af of #AF_INET6, and causes all known
  *           addresses (IPv6 and IPv4) to be returned. If #AI_V4MAPPED is
  *           also set, the IPv4 addresses are return as mapped IPv6
  *           addresses.
- * 
+ *
  * \li   #AI_ADDRCONFIG:
  *           Only return an IPv6 or IPv4 address if here is an active
  *           network interface of that type. This is not currently
  *           implemented in the BIND 9 lightweight resolver, and the flag is
  *           ignored.
- * 
+ *
  * \li   #AI_DEFAULT:
  *           This default sets the #AI_V4MAPPED and #AI_ADDRCONFIG flag bits.
- * 
+ *
  *    lwres_getipnodebyaddr() performs a reverse lookup of address src which
  *    is len bytes long. af denotes the protocol family, typically PF_INET
  *    or PF_INET6.
- * 
+ *
  *    lwres_freehostent() releases all the memory associated with the struct
  *    hostent pointer. Any memory allocated for the h_name, h_addr_list
  *    and h_aliases is freed, as is the memory for the hostent structure
  *    itself.
- * 
+ *
  * \section getipnode_return Return Values
- * 
+ *
  *    If an error occurs, lwres_getipnodebyname() and
  *    lwres_getipnodebyaddr() set *error_num to an appropriate error code
  *    and the function returns a NULL pointer. The error codes and their
  *    meanings are defined in \link netdb.h \endlink:
- * 
+ *
  * \li   #HOST_NOT_FOUND:
  *           No such host is known.
- * 
+ *
  * \li   #NO_ADDRESS:
  *           The server recognised the request and the name but no address
  *           is available. Another type of request to the name server for
  *           the domain might return an answer.
- * 
+ *
  * \li   #TRY_AGAIN:
  *           A temporary and possibly transient error occurred, such as a
  *           failure of a server to respond. The request may succeed if
  *           retried.
- * 
+ *
  * \li   #NO_RECOVERY:
  *           An unexpected failure occurred, and retrying the request is
  *           pointless.
- * 
+ *
  *    lwres_hstrerror() translates these error codes to suitable error
  *    messages.
- * 
+ *
  * \section getipnode_see See Also
- * 
- * getaddrinfo.c, gethost.c, getnameinfo.c, herror.c, RFC2553  
+ *
+ * getaddrinfo.c, gethost.c, getnameinfo.c, herror.c, RFC2553
  */
 
 #include 
@@ -146,21 +146,21 @@ LIBLWRES_EXTERNAL_DATA const struct in6_addr in6addr_any = IN6ADDR_ANY_INIT;
 
 #ifndef IN6_IS_ADDR_V4COMPAT
 static const unsigned char in6addr_compat[12] = {
-        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
 };
 #define IN6_IS_ADDR_V4COMPAT(x) (!memcmp((x)->s6_addr, in6addr_compat, 12) && \
-                                 ((x)->s6_addr[12] != 0 || \
-                                  (x)->s6_addr[13] != 0 || \
-                                  (x)->s6_addr[14] != 0 || \
-                                   ((x)->s6_addr[15] != 0 && \
-                                    (x)->s6_addr[15] != 1)))
+				 ((x)->s6_addr[12] != 0 || \
+				  (x)->s6_addr[13] != 0 || \
+				  (x)->s6_addr[14] != 0 || \
+				   ((x)->s6_addr[15] != 0 && \
+				    (x)->s6_addr[15] != 1)))
 #endif
 #ifndef IN6_IS_ADDR_V4MAPPED
 #define IN6_IS_ADDR_V4MAPPED(x) (!memcmp((x)->s6_addr, in6addr_mapped, 12))
 #endif
 
 static const unsigned char in6addr_mapped[12] = {
-        0, 0, 0, 0,  0, 0, 0, 0,  0, 0, 0xff, 0xff
+	0, 0, 0, 0,  0, 0, 0, 0,  0, 0, 0xff, 0xff
 };
 
 /***
@@ -492,7 +492,7 @@ lwres_freehostent(struct hostent *he) {
  */
 
 #if defined(SIOCGLIFCONF) && defined(SIOCGLIFADDR) && \
-    !defined(IRIX_EMUL_IOCTL_SIOCGIFCONF) 
+    !defined(IRIX_EMUL_IOCTL_SIOCGIFCONF)
 
 #ifdef __hpux
 #define lifc_len iflc_len
@@ -504,7 +504,7 @@ lwres_freehostent(struct hostent *he) {
 #define ISC_HAVE_LIFC_FLAGS 1
 #define LIFCONF lifconf
 #endif
- 
+
 #ifdef __hpux
 #define lifr_addr iflr_addr
 #define lifr_name iflr_name
@@ -557,7 +557,7 @@ scan_interfaces6(int *have_v4, int *have_v6) {
 			/*
 			 * Some OS's just return what will fit rather
 			 * than set EINVAL if the buffer is too small
-			 * to fit all the interfaces in.  If 
+			 * to fit all the interfaces in.  If
 			 * lifc.lifc_len is too near to the end of the
 			 * buffer we will grow it just in case and
 			 * retry.
@@ -619,13 +619,13 @@ scan_interfaces6(int *have_v4, int *have_v6) {
 				if ((lifreq.lifr_flags & IFF_UP) == 0)
 					break;
 				*have_v4 = 1;
-			} 
+			}
 			break;
 		case AF_INET6:
 			if (*have_v6 == 0) {
 				memcpy(&in6,
 				       &((struct sockaddr_in6 *)
-				       &lifreq.lifr_addr)->sin6_addr, 
+				       &lifreq.lifr_addr)->sin6_addr,
 				       sizeof(in6));
 				if (memcmp(&in6, &in6addr_any,
 					   sizeof(in6)) == 0)
@@ -675,7 +675,7 @@ scan_interfaces(int *have_v4, int *have_v6) {
 	InitSockets();
 #endif
 #if defined(SIOCGLIFCONF) && defined(SIOCGLIFADDR) && \
-    !defined(IRIX_EMUL_IOCTL_SIOCGIFCONF) 
+    !defined(IRIX_EMUL_IOCTL_SIOCGIFCONF)
 	/*
 	 * Try to scan the interfaces using IPv6 ioctls().
 	 */
@@ -721,7 +721,7 @@ scan_interfaces(int *have_v4, int *have_v6) {
 			/*
 			 * Some OS's just return what will fit rather
 			 * than set EINVAL if the buffer is too small
-			 * to fit all the interfaces in.  If 
+			 * to fit all the interfaces in.  If
 			 * ifc.ifc_len is too near to the end of the
 			 * buffer we will grow it just in case and
 			 * retry.
@@ -786,7 +786,7 @@ scan_interfaces(int *have_v4, int *have_v6) {
 				if ((u.ifreq.ifr_flags & IFF_UP) == 0)
 					break;
 				*have_v4 = 1;
-			} 
+			}
 			break;
 		case AF_INET6:
 			if (*have_v6 == 0) {
diff --git a/lib/lwres/include/lwres/context.h b/lib/lwres/include/lwres/context.h
index bd2444638b9c..2ce16ea25501 100644
--- a/lib/lwres/include/lwres/context.h
+++ b/lib/lwres/include/lwres/context.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: context.h,v 1.15.18.2 2005/04/29 00:17:21 marka Exp $ */
+/* $Id: context.h,v 1.15.18.4 2008/12/17 23:46:01 tbox Exp $ */
 
 #ifndef LWRES_CONTEXT_H
 #define LWRES_CONTEXT_H 1
@@ -57,8 +57,15 @@ typedef void (*lwres_free_t)(void *arg, void *mem, size_t length);
  * _SERVERMODE
  *	Don't allocate and connect a socket to the server, since the
  *	caller _is_ a server.
+ *
+ * _USEIPV4, _USEIPV6
+ *	Use IPv4 and IPv6 transactions with remote servers, respectively.
+ *	For backward compatibility, regard both flags as being set when both
+ *	are cleared.
  */
 #define LWRES_CONTEXT_SERVERMODE	0x00000001U
+#define LWRES_CONTEXT_USEIPV4		0x00000002U
+#define LWRES_CONTEXT_USEIPV6		0x00000004U
 
 lwres_result_t
 lwres_context_create(lwres_context_t **contextp, void *arg,
diff --git a/lib/lwres/include/lwres/netdb.h.in b/lib/lwres/include/lwres/netdb.h.in
index eaef63b9066d..9a792fb72ef1 100644
--- a/lib/lwres/include/lwres/netdb.h.in
+++ b/lib/lwres/include/lwres/netdb.h.in
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: netdb.h.in,v 1.35.18.2 2005/04/29 00:17:22 marka Exp $ */
+/* $Id: netdb.h.in,v 1.35.18.4 2009/01/19 23:46:17 tbox Exp $ */
 
 /*! \file */
 
@@ -66,7 +66,7 @@ struct addrinfo {
 #define	NETDB_INTERNAL	-1	/* see errno */
 #define	NETDB_SUCCESS	0	/* no problem */
 #define	HOST_NOT_FOUND	1 /* Authoritative Answer Host not found */
-#define	TRY_AGAIN	2 /* Non-Authoritive Host not found, or SERVERFAIL */
+#define	TRY_AGAIN	2 /* Non-Authoritative Host not found, or SERVERFAIL */
 #define	NO_RECOVERY	3 /* Non recoverable errors, FORMERR, REFUSED, NOTIMP */
 #define	NO_DATA		4 /* Valid name, no data record of requested type */
 #define	NO_ADDRESS	NO_DATA		/* no address, look for MX record */
diff --git a/lib/lwres/lwconfig.c b/lib/lwres/lwconfig.c
index cf4f6a7f0549..37e347950e5a 100644
--- a/lib/lwres/lwconfig.c
+++ b/lib/lwres/lwconfig.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwconfig.c,v 1.38.18.5 2006/10/03 23:50:51 marka Exp $ */
+/* $Id: lwconfig.c,v 1.38.18.7 2008/12/17 23:46:01 tbox Exp $ */
 
 /*! \file */
 
@@ -24,32 +24,32 @@
  *
  *    lwres_conf_init() creates an empty lwres_conf_t structure for
  *    lightweight resolver context ctx.
- * 
+ *
  *    lwres_conf_clear() frees up all the internal memory used by that
  *    lwres_conf_t structure in resolver context ctx.
- * 
+ *
  *    lwres_conf_parse() opens the file filename and parses it to initialise
  *    the resolver context ctx's lwres_conf_t structure.
- * 
+ *
  *    lwres_conf_print() prints the lwres_conf_t structure for resolver
  *    context ctx to the FILE fp.
- * 
+ *
  * \section lwconfig_return Return Values
- * 
+ *
  *    lwres_conf_parse() returns #LWRES_R_SUCCESS if it successfully read and
  *    parsed filename. It returns #LWRES_R_FAILURE if filename could not be
  *    opened or contained incorrect resolver statements.
- * 
+ *
  *    lwres_conf_print() returns #LWRES_R_SUCCESS unless an error occurred
  *    when converting the network addresses to a numeric host address
  *    string. If this happens, the function returns #LWRES_R_FAILURE.
- * 
+ *
  * \section lwconfig_see See Also
- * 
+ *
  *    stdio(3), \link resolver resolver \endlink
- * 
+ *
  * \section files Files
- * 
+ *
  *    /etc/resolv.conf
  */
 
@@ -313,8 +313,11 @@ lwres_conf_parsenameserver(lwres_context_t *ctx,  FILE *fp) {
 		return (LWRES_R_FAILURE); /* Extra junk on line. */
 
 	res = lwres_create_addr(word, &address, 1);
-	if (res == LWRES_R_SUCCESS)
+	if (res == LWRES_R_SUCCESS &&
+	    ((address.family == LWRES_ADDRTYPE_V4 && ctx->use_ipv4 == 1) ||
+	     (address.family == LWRES_ADDRTYPE_V6 && ctx->use_ipv6 == 1))) {
 		confdata->nameservers[confdata->nsnext++] = address;
+	}
 
 	return (LWRES_R_SUCCESS);
 }
diff --git a/lib/lwres/man/lwres.3 b/lib/lwres/man/lwres.3
index 968e8f857af2..dbbc88595df1 100644
--- a/lib/lwres/man/lwres.3
+++ b/lib/lwres/man/lwres.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres.3,v 1.17.18.11 2007/01/30 00:23:44 marka Exp $
+.\" $Id: lwres.3,v 1.17.18.12 2009/07/11 01:31:47 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres.html b/lib/lwres/man/lwres.html
index e4bbc098fa16..273d10240c55 100644
--- a/lib/lwres/man/lwres.html
+++ b/lib/lwres/man/lwres.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_buffer.3 b/lib/lwres/man/lwres_buffer.3
index 4bebafa960aa..7f4919d73d63 100644
--- a/lib/lwres/man/lwres_buffer.3
+++ b/lib/lwres/man/lwres_buffer.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_buffer.3,v 1.15.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_buffer.3,v 1.15.18.12 2009/07/11 01:31:47 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_buffer.html b/lib/lwres/man/lwres_buffer.html
index ed3e427be4ff..54a7334e921f 100644
--- a/lib/lwres/man/lwres_buffer.html
+++ b/lib/lwres/man/lwres_buffer.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_config.3 b/lib/lwres/man/lwres_config.3
index 5a4123d10dab..c80918f51067 100644
--- a/lib/lwres/man/lwres_config.3
+++ b/lib/lwres/man/lwres_config.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_config.3,v 1.15.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_config.3,v 1.15.18.12 2009/07/11 01:31:47 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_config.html b/lib/lwres/man/lwres_config.html
index efa33d85424c..d2e42299167c 100644
--- a/lib/lwres/man/lwres_config.html
+++ b/lib/lwres/man/lwres_config.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_context.3 b/lib/lwres/man/lwres_context.3
index 8883a01a22ee..b6347938ffba 100644
--- a/lib/lwres/man/lwres_context.3
+++ b/lib/lwres/man/lwres_context.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_context.3,v 1.17.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_context.3,v 1.17.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_context.html b/lib/lwres/man/lwres_context.html
index f2aa7e1711f6..95b450505ac0 100644
--- a/lib/lwres/man/lwres_context.html
+++ b/lib/lwres/man/lwres_context.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_gabn.3 b/lib/lwres/man/lwres_gabn.3
index 69d311f28627..c639628466ba 100644
--- a/lib/lwres/man/lwres_gabn.3
+++ b/lib/lwres/man/lwres_gabn.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gabn.3,v 1.16.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_gabn.3,v 1.16.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_gabn.html b/lib/lwres/man/lwres_gabn.html
index e27954b1676e..b6f2cad9ee5b 100644
--- a/lib/lwres/man/lwres_gabn.html
+++ b/lib/lwres/man/lwres_gabn.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_gai_strerror.3 b/lib/lwres/man/lwres_gai_strerror.3
index 4fd03e2a8f4e..d4f115f6ece7 100644
--- a/lib/lwres/man/lwres_gai_strerror.3
+++ b/lib/lwres/man/lwres_gai_strerror.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gai_strerror.3,v 1.16.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_gai_strerror.3,v 1.16.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_gai_strerror.html b/lib/lwres/man/lwres_gai_strerror.html
index 967325309509..bdbdacc8615d 100644
--- a/lib/lwres/man/lwres_gai_strerror.html
+++ b/lib/lwres/man/lwres_gai_strerror.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_getaddrinfo.3 b/lib/lwres/man/lwres_getaddrinfo.3
index 9d198d62db09..2d499ee13dd5 100644
--- a/lib/lwres/man/lwres_getaddrinfo.3
+++ b/lib/lwres/man/lwres_getaddrinfo.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getaddrinfo.3,v 1.20.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_getaddrinfo.3,v 1.20.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_getaddrinfo.html b/lib/lwres/man/lwres_getaddrinfo.html
index d2dcdd95a609..8844bdd2ce1f 100644
--- a/lib/lwres/man/lwres_getaddrinfo.html
+++ b/lib/lwres/man/lwres_getaddrinfo.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_gethostent.3 b/lib/lwres/man/lwres_gethostent.3
index e6fbcd7c04cb..607e1993c114 100644
--- a/lib/lwres/man/lwres_gethostent.3
+++ b/lib/lwres/man/lwres_gethostent.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gethostent.3,v 1.19.18.10 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_gethostent.3,v 1.19.18.11 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_gethostent.html b/lib/lwres/man/lwres_gethostent.html
index 0b7ba4423e32..ee295c2104eb 100644
--- a/lib/lwres/man/lwres_gethostent.html
+++ b/lib/lwres/man/lwres_gethostent.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_getipnode.3 b/lib/lwres/man/lwres_getipnode.3
index 9c9f374b8f13..80cdf1411c09 100644
--- a/lib/lwres/man/lwres_getipnode.3
+++ b/lib/lwres/man/lwres_getipnode.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getipnode.3,v 1.17.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_getipnode.3,v 1.17.18.12 2009/07/11 01:31:47 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_getipnode.html b/lib/lwres/man/lwres_getipnode.html
index a585f1d09dc7..008fa11fda77 100644
--- a/lib/lwres/man/lwres_getipnode.html
+++ b/lib/lwres/man/lwres_getipnode.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_getnameinfo.3 b/lib/lwres/man/lwres_getnameinfo.3
index 449f59130fdf..8c8fe476544f 100644
--- a/lib/lwres/man/lwres_getnameinfo.3
+++ b/lib/lwres/man/lwres_getnameinfo.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getnameinfo.3,v 1.18.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_getnameinfo.3,v 1.18.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_getnameinfo.html b/lib/lwres/man/lwres_getnameinfo.html
index 312cfe53e213..8a67a2b5d59a 100644
--- a/lib/lwres/man/lwres_getnameinfo.html
+++ b/lib/lwres/man/lwres_getnameinfo.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_getrrsetbyname.3 b/lib/lwres/man/lwres_getrrsetbyname.3
index 548b8e7e1711..afb918f79e0b 100644
--- a/lib/lwres/man/lwres_getrrsetbyname.3
+++ b/lib/lwres/man/lwres_getrrsetbyname.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getrrsetbyname.3,v 1.14.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_getrrsetbyname.3,v 1.14.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_getrrsetbyname.html b/lib/lwres/man/lwres_getrrsetbyname.html
index 092536735673..13c9624a8287 100644
--- a/lib/lwres/man/lwres_getrrsetbyname.html
+++ b/lib/lwres/man/lwres_getrrsetbyname.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_gnba.3 b/lib/lwres/man/lwres_gnba.3
index 1c6574f08e82..1d340e560270 100644
--- a/lib/lwres/man/lwres_gnba.3
+++ b/lib/lwres/man/lwres_gnba.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gnba.3,v 1.16.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_gnba.3,v 1.16.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_gnba.html b/lib/lwres/man/lwres_gnba.html
index aac60c648e61..97dd432dc96c 100644
--- a/lib/lwres/man/lwres_gnba.html
+++ b/lib/lwres/man/lwres_gnba.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_hstrerror.3 b/lib/lwres/man/lwres_hstrerror.3
index 6fa744ea0c43..78e0ea85b3a9 100644
--- a/lib/lwres/man/lwres_hstrerror.3
+++ b/lib/lwres/man/lwres_hstrerror.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_hstrerror.3,v 1.16.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_hstrerror.3,v 1.16.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_hstrerror.html b/lib/lwres/man/lwres_hstrerror.html
index b52ff069decb..1866d4a2a55d 100644
--- a/lib/lwres/man/lwres_hstrerror.html
+++ b/lib/lwres/man/lwres_hstrerror.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_inetntop.3 b/lib/lwres/man/lwres_inetntop.3
index 4cb09f807610..519a920d9b31 100644
--- a/lib/lwres/man/lwres_inetntop.3
+++ b/lib/lwres/man/lwres_inetntop.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_inetntop.3,v 1.15.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_inetntop.3,v 1.15.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_inetntop.html b/lib/lwres/man/lwres_inetntop.html
index 532d500ef1af..b54f38acc53f 100644
--- a/lib/lwres/man/lwres_inetntop.html
+++ b/lib/lwres/man/lwres_inetntop.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_noop.3 b/lib/lwres/man/lwres_noop.3
index 78841096fb1b..5414f064264a 100644
--- a/lib/lwres/man/lwres_noop.3
+++ b/lib/lwres/man/lwres_noop.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_noop.3,v 1.17.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_noop.3,v 1.17.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_noop.html b/lib/lwres/man/lwres_noop.html
index 4705ecbf0eed..c8bcafef9bef 100644
--- a/lib/lwres/man/lwres_noop.html
+++ b/lib/lwres/man/lwres_noop.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_packet.3 b/lib/lwres/man/lwres_packet.3
index 141090852f50..f1720316fb2d 100644
--- a/lib/lwres/man/lwres_packet.3
+++ b/lib/lwres/man/lwres_packet.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_packet.3,v 1.18.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_packet.3,v 1.18.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_packet.html b/lib/lwres/man/lwres_packet.html
index eeb7ebd84074..f918f85b23ba 100644
--- a/lib/lwres/man/lwres_packet.html
+++ b/lib/lwres/man/lwres_packet.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/lib/lwres/man/lwres_resutil.3 b/lib/lwres/man/lwres_resutil.3
index 9aebc9f86a00..f36a87bdde21 100644
--- a/lib/lwres/man/lwres_resutil.3
+++ b/lib/lwres/man/lwres_resutil.3
@@ -1,7 +1,7 @@
 .\" Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000, 2001 Internet Software Consortium.
 .\" 
-.\" Permission to use, copy, modify, and distribute this software for any
+.\" Permission to use, copy, modify, and/or distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
 .\" 
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_resutil.3,v 1.17.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_resutil.3,v 1.17.18.12 2009/07/11 01:31:46 tbox Exp $
 .\"
 .hy 0
 .ad l
diff --git a/lib/lwres/man/lwres_resutil.html b/lib/lwres/man/lwres_resutil.html
index dfa2e1c88dc1..8c26abd0c940 100644
--- a/lib/lwres/man/lwres_resutil.html
+++ b/lib/lwres/man/lwres_resutil.html
@@ -2,7 +2,7 @@
  - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
- - Permission to use, copy, modify, and distribute this software for any
+ - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
  - 
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
+
 
 
 
diff --git a/libtool.m4 b/libtool.m4
index 551ffd0d83ea..a352a6543da4 100644
--- a/libtool.m4
+++ b/libtool.m4
@@ -1,28 +1,13 @@
 # libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
-## Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004
-## Free Software Foundation, Inc.
+## Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007,
+## 2008  Free Software Foundation, Inc.
 ## Originally by Gordon Matzigkeit , 1996
 ##
-## This program is free software; you can redistribute it and/or modify
-## it under the terms of the GNU General Public License as published by
-## the Free Software Foundation; either version 2 of the License, or
-## (at your option) any later version.
-##
-## This program is distributed in the hope that it will be useful, but
-## WITHOUT ANY WARRANTY; without even the implied warranty of
-## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-## General Public License for more details.
-##
-## You should have received a copy of the GNU General Public License
-## along with this program; if not, write to the Free Software
-## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-##
-## As a special exception to the GNU General Public License, if you
-## distribute this file as part of a program that contains a
-## configuration script generated by Autoconf, you may include it under
-## the same distribution terms that you use for the rest of that program.
+## This file is free software; the Free Software Foundation gives
+## unlimited permission to copy and/or distribute it, with or without
+## modifications, as long as this notice is preserved.
 
-# serial 47 AC_PROG_LIBTOOL
+# serial 52 AC_PROG_LIBTOOL
 
 
 # AC_PROVIDE_IFELSE(MACRO-NAME, IF-PROVIDED, IF-NOT-PROVIDED)
@@ -110,7 +95,6 @@ AC_REQUIRE([AC_DEPLIBS_CHECK_METHOD])dnl
 AC_REQUIRE([AC_OBJEXT])dnl
 AC_REQUIRE([AC_EXEEXT])dnl
 dnl
-
 AC_LIBTOOL_SYS_MAX_CMD_LEN
 AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE
 AC_LIBTOOL_OBJDIR
@@ -132,7 +116,7 @@ esac
 
 # Sed substitution that helps us do robust quoting.  It backslashifies
 # metacharacters that are still active within double-quoted strings.
-Xsed='sed -e s/^X//'
+Xsed='sed -e 1s/^X//'
 [sed_quote_subst='s/\([\\"\\`$\\\\]\)/\\\1/g']
 
 # Same as above, but do not quote variable references.
@@ -152,7 +136,7 @@ rm="rm -f"
 default_ofile=libtool
 can_build_shared=yes
 
-# All known linkers require a `.a' archive for static linking (except M$VC,
+# All known linkers require a `.a' archive for static linking (except MSVC,
 # which needs '.lib').
 libext=a
 ltmain="$ac_aux_dir/ltmain.sh"
@@ -172,6 +156,7 @@ test -z "$AR_FLAGS" && AR_FLAGS=cru
 test -z "$AS" && AS=as
 test -z "$CC" && CC=cc
 test -z "$LTCC" && LTCC=$CC
+test -z "$LTCFLAGS" && LTCFLAGS=$CFLAGS
 test -z "$DLLTOOL" && DLLTOOL=dlltool
 test -z "$LD" && LD=ld
 test -z "$LN_S" && LN_S="ln -s"
@@ -184,23 +169,23 @@ test -z "$STRIP" && STRIP=:
 test -z "$ac_objext" && ac_objext=o
 
 # Determine commands to create old-style static archives.
-old_archive_cmds='$AR $AR_FLAGS $oldlib$oldobjs$old_deplibs'
+old_archive_cmds='$AR $AR_FLAGS $oldlib$oldobjs'
 old_postinstall_cmds='chmod 644 $oldlib'
 old_postuninstall_cmds=
 
 if test -n "$RANLIB"; then
   case $host_os in
   openbsd*)
-    old_postinstall_cmds="\$RANLIB -t \$oldlib~$old_postinstall_cmds"
+    old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib"
     ;;
   *)
-    old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
+    old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
     ;;
   esac
   old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
 fi
 
-cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
+_LT_CC_BASENAME([$compiler])
 
 # Only perform the check for file, if the check method requires it
 case $deplibs_check_method in
@@ -211,6 +196,8 @@ file_magic*)
   ;;
 esac
 
+_LT_REQUIRED_DARWIN_CHECKS
+
 AC_PROVIDE_IFELSE([AC_LIBTOOL_DLOPEN], enable_dlopen=yes, enable_dlopen=no)
 AC_PROVIDE_IFELSE([AC_LIBTOOL_WIN32_DLL],
 enable_win32_dll=yes, enable_win32_dll=no)
@@ -242,11 +229,129 @@ AC_DEFUN([_LT_AC_SYS_COMPILER],
 # If no C compiler was specified, use CC.
 LTCC=${LTCC-"$CC"}
 
+# If no C compiler flags were specified, use CFLAGS.
+LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
+
 # Allow CC to be a program name with arguments.
 compiler=$CC
 ])# _LT_AC_SYS_COMPILER
 
 
+# _LT_CC_BASENAME(CC)
+# -------------------
+# Calculate cc_basename.  Skip known compiler wrappers and cross-prefix.
+AC_DEFUN([_LT_CC_BASENAME],
+[for cc_temp in $1""; do
+  case $cc_temp in
+    compile | *[[\\/]]compile | ccache | *[[\\/]]ccache ) ;;
+    distcc | *[[\\/]]distcc | purify | *[[\\/]]purify ) ;;
+    \-*) ;;
+    *) break;;
+  esac
+done
+cc_basename=`$echo "X$cc_temp" | $Xsed -e 's%.*/%%' -e "s%^$host_alias-%%"`
+])
+
+
+# _LT_COMPILER_BOILERPLATE
+# ------------------------
+# Check for compiler boilerplate output or warnings with
+# the simple compiler test code.
+AC_DEFUN([_LT_COMPILER_BOILERPLATE],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+ac_outfile=conftest.$ac_objext
+echo "$lt_simple_compile_test_code" >conftest.$ac_ext
+eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
+_lt_compiler_boilerplate=`cat conftest.err`
+$rm conftest*
+])# _LT_COMPILER_BOILERPLATE
+
+
+# _LT_LINKER_BOILERPLATE
+# ----------------------
+# Check for linker boilerplate output or warnings with
+# the simple link test code.
+AC_DEFUN([_LT_LINKER_BOILERPLATE],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+ac_outfile=conftest.$ac_objext
+echo "$lt_simple_link_test_code" >conftest.$ac_ext
+eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
+_lt_linker_boilerplate=`cat conftest.err`
+$rm -r conftest*
+])# _LT_LINKER_BOILERPLATE
+
+# _LT_REQUIRED_DARWIN_CHECKS
+# --------------------------
+# Check for some things on darwin
+AC_DEFUN([_LT_REQUIRED_DARWIN_CHECKS],[
+  case $host_os in
+    rhapsody* | darwin*)
+    AC_CHECK_TOOL([DSYMUTIL], [dsymutil], [:])
+    AC_CHECK_TOOL([NMEDIT], [nmedit], [:])
+
+    AC_CACHE_CHECK([for -single_module linker flag],[lt_cv_apple_cc_single_mod],
+      [lt_cv_apple_cc_single_mod=no
+      if test -z "${LT_MULTI_MODULE}"; then
+   # By default we will add the -single_module flag. You can override
+   # by either setting the environment variable LT_MULTI_MODULE
+   # non-empty at configure time, or by adding -multi_module to the
+   # link flags.
+   echo "int foo(void){return 1;}" > conftest.c
+   $LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \
+     -dynamiclib ${wl}-single_module conftest.c
+   if test -f libconftest.dylib; then
+     lt_cv_apple_cc_single_mod=yes
+     rm -rf libconftest.dylib*
+   fi
+   rm conftest.c
+      fi])
+    AC_CACHE_CHECK([for -exported_symbols_list linker flag],
+      [lt_cv_ld_exported_symbols_list],
+      [lt_cv_ld_exported_symbols_list=no
+      save_LDFLAGS=$LDFLAGS
+      echo "_main" > conftest.sym
+      LDFLAGS="$LDFLAGS -Wl,-exported_symbols_list,conftest.sym"
+      AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
+   [lt_cv_ld_exported_symbols_list=yes],
+   [lt_cv_ld_exported_symbols_list=no])
+   LDFLAGS="$save_LDFLAGS"
+    ])
+    case $host_os in
+    rhapsody* | darwin1.[[0123]])
+      _lt_dar_allow_undefined='${wl}-undefined ${wl}suppress' ;;
+    darwin1.*)
+     _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
+    darwin*)
+      # if running on 10.5 or later, the deployment target defaults
+      # to the OS version, if on x86, and 10.4, the deployment
+      # target defaults to 10.4. Don't you love it?
+      case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
+   10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
+     _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
+   10.[[012]]*)
+     _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
+   10.*)
+     _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
+      esac
+    ;;
+  esac
+    if test "$lt_cv_apple_cc_single_mod" = "yes"; then
+      _lt_dar_single_mod='$single_module'
+    fi
+    if test "$lt_cv_ld_exported_symbols_list" = "yes"; then
+      _lt_dar_export_syms=' ${wl}-exported_symbols_list,$output_objdir/${libname}-symbols.expsym'
+    else
+      _lt_dar_export_syms="~$NMEDIT -s \$output_objdir/\${libname}-symbols.expsym \${lib}"
+    fi
+    if test "$DSYMUTIL" != ":"; then
+      _lt_dsymutil="~$DSYMUTIL \$lib || :"
+    else
+      _lt_dsymutil=
+    fi
+    ;;
+  esac
+])
+
 # _LT_AC_SYS_LIBPATH_AIX
 # ----------------------
 # Links a minimal program and checks the executable
@@ -256,12 +361,20 @@ compiler=$CC
 # If we don't find anything, use the default library path according
 # to the aix ld manual.
 AC_DEFUN([_LT_AC_SYS_LIBPATH_AIX],
-[AC_LINK_IFELSE(AC_LANG_PROGRAM,[
-aix_libpath=`dump -H conftest$ac_exeext 2>/dev/null | $SED -n -e '/Import File Strings/,/^$/ { /^0/ { s/^0  *\(.*\)$/\1/; p; }
-}'`
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_LINK_IFELSE(AC_LANG_PROGRAM,[
+lt_aix_libpath_sed='
+    /Import File Strings/,/^$/ {
+	/^0/ {
+	    s/^0  *\(.*\)$/\1/
+	    p
+	}
+    }'
+aix_libpath=`dump -H conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
 # Check for a 64-bit object if we didn't find anything.
-if test -z "$aix_libpath"; then aix_libpath=`dump -HX64 conftest$ac_exeext 2>/dev/null | $SED -n -e '/Import File Strings/,/^$/ { /^0/ { s/^0  *\(.*\)$/\1/; p; }
-}'`; fi],[])
+if test -z "$aix_libpath"; then
+  aix_libpath=`dump -HX64 conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
+fi],[])
 if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
 ])# _LT_AC_SYS_LIBPATH_AIX
 
@@ -326,8 +439,8 @@ if test "X${echo_test_string+set}" != Xset; then
 # find a string as large as possible, as long as the shell can cope with it
   for cmd in 'sed 50q "[$]0"' 'sed 20q "[$]0"' 'sed 10q "[$]0"' 'sed 2q "[$]0"' 'echo test'; do
     # expected sizes: less than 2Kb, 1Kb, 512 bytes, 16 bytes, ...
-    if (echo_test_string="`eval $cmd`") 2>/dev/null &&
-       echo_test_string="`eval $cmd`" &&
+    if (echo_test_string=`eval $cmd`) 2>/dev/null &&
+       echo_test_string=`eval $cmd` &&
        (test "X$echo_test_string" = "X$echo_test_string") 2>/dev/null
     then
       break
@@ -492,13 +605,17 @@ ia64-*-hpux*)
   rm -rf conftest*
   ;;
 
-x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
+x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
+s390*-*linux*|sparc*-*linux*)
   # Find out which ABI we are using.
   echo 'int i;' > conftest.$ac_ext
   if AC_TRY_EVAL(ac_compile); then
-    case "`/usr/bin/file conftest.o`" in
+    case `/usr/bin/file conftest.o` in
     *32-bit*)
       case $host in
+        x86_64-*kfreebsd*-gnu)
+          LD="${LD-ld} -m elf_i386_fbsd"
+          ;;
         x86_64-*linux*)
           LD="${LD-ld} -m elf_i386"
           ;;
@@ -515,6 +632,9 @@ x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
       ;;
     *64-bit*)
       case $host in
+        x86_64-*kfreebsd*-gnu)
+          LD="${LD-ld} -m elf_x86_64_fbsd"
+          ;;
         x86_64-*linux*)
           LD="${LD-ld} -m elf_x86_64"
           ;;
@@ -547,6 +667,26 @@ x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
     CFLAGS="$SAVE_CFLAGS"
   fi
   ;;
+sparc*-*solaris*)
+  # Find out which ABI we are using.
+  echo 'int i;' > conftest.$ac_ext
+  if AC_TRY_EVAL(ac_compile); then
+    case `/usr/bin/file conftest.o` in
+    *64-bit*)
+      case $lt_cv_prog_gnu_ld in
+      yes*) LD="${LD-ld} -m elf64_sparc" ;;
+      *)
+        if ${LD-ld} -64 -r -o conftest2.o conftest.o >/dev/null 2>&1; then
+	  LD="${LD-ld} -64"
+	fi
+	;;
+      esac
+      ;;
+    esac
+  fi
+  rm -rf conftest*
+  ;;
+
 AC_PROVIDE_IFELSE([AC_LIBTOOL_WIN32_DLL],
 [*-*-cygwin* | *-*-mingw* | *-*-pw32*)
   AC_CHECK_TOOL(DLLTOOL, dlltool, false)
@@ -570,7 +710,7 @@ AC_DEFUN([AC_LIBTOOL_COMPILER_OPTION],
 AC_CACHE_CHECK([$1], [$2],
   [$2=no
   ifelse([$4], , [ac_outfile=conftest.$ac_objext], [ac_outfile=$4])
-   printf "$lt_simple_compile_test_code" > conftest.$ac_ext
+   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
    lt_compiler_flag="$3"
    # Insert the option either (1) after the last *FLAGS variable, or
    # (2) before a word containing "conftest.", or (3) at the end.
@@ -578,7 +718,7 @@ AC_CACHE_CHECK([$1], [$2],
    # with a dollar sign (not a hyphen), so the echo should work correctly.
    # The option is referenced via a variable to avoid confusing sed.
    lt_compile=`echo "$ac_compile" | $SED \
-   -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [[^ ]]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
    (eval echo "\"\$as_me:__oline__: $lt_compile\"" >&AS_MESSAGE_LOG_FD)
@@ -588,8 +728,10 @@ AC_CACHE_CHECK([$1], [$2],
    echo "$as_me:__oline__: \$? = $ac_status" >&AS_MESSAGE_LOG_FD
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
-     # So say no if there are warnings
-     if test ! -s conftest.err; then
+     # So say no if there are warnings other than the usual output.
+     $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
+     $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+     if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
        $2=yes
      fi
    fi
@@ -609,22 +751,28 @@ fi
 # ------------------------------------------------------------
 # Check whether the given compiler option works
 AC_DEFUN([AC_LIBTOOL_LINKER_OPTION],
-[AC_CACHE_CHECK([$1], [$2],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_CACHE_CHECK([$1], [$2],
   [$2=no
    save_LDFLAGS="$LDFLAGS"
    LDFLAGS="$LDFLAGS $3"
-   printf "$lt_simple_link_test_code" > conftest.$ac_ext
+   echo "$lt_simple_link_test_code" > conftest.$ac_ext
    if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
-     # The compiler can only warn and ignore the option if not recognized
+     # The linker can only warn and ignore the option if not recognized
      # So say no if there are warnings
      if test -s conftest.err; then
        # Append any errors to the config.log.
        cat conftest.err 1>&AS_MESSAGE_LOG_FD
+       $echo "X$_lt_linker_boilerplate" | $Xsed -e '/^$/d' > conftest.exp
+       $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+       if diff conftest.exp conftest.er2 >/dev/null; then
+         $2=yes
+       fi
      else
        $2=yes
      fi
    fi
-   $rm conftest*
+   $rm -r conftest*
    LDFLAGS="$save_LDFLAGS"
 ])
 
@@ -678,38 +826,71 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl
     lt_cv_sys_max_cmd_len=8192;
     ;;
 
-  netbsd* | freebsd* | openbsd* | darwin* )
+  netbsd* | freebsd* | openbsd* | darwin* | dragonfly*)
     # This has been around since 386BSD, at least.  Likely further.
     if test -x /sbin/sysctl; then
       lt_cv_sys_max_cmd_len=`/sbin/sysctl -n kern.argmax`
     elif test -x /usr/sbin/sysctl; then
       lt_cv_sys_max_cmd_len=`/usr/sbin/sysctl -n kern.argmax`
     else
-      lt_cv_sys_max_cmd_len=65536 # usable default for *BSD
+      lt_cv_sys_max_cmd_len=65536	# usable default for all BSDs
     fi
     # And add a safety zone
     lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
+    lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
+    ;;
+
+  interix*)
+    # We know the value 262144 and hardcode it with a safety zone (like BSD)
+    lt_cv_sys_max_cmd_len=196608
     ;;
 
- *)
-    # If test is not a shell built-in, we'll probably end up computing a
-    # maximum length that is only half of the actual maximum length, but
-    # we can't tell.
-    SHELL=${SHELL-${CONFIG_SHELL-/bin/sh}}
-    while (test "X"`$SHELL [$]0 --fallback-echo "X$teststring" 2>/dev/null` \
+  osf*)
+    # Dr. Hans Ekkehard Plesser reports seeing a kernel panic running configure
+    # due to this test when exec_disable_arg_limit is 1 on Tru64. It is not
+    # nice to cause kernel panics so lets avoid the loop below.
+    # First set a reasonable default.
+    lt_cv_sys_max_cmd_len=16384
+    #
+    if test -x /sbin/sysconfig; then
+      case `/sbin/sysconfig -q proc exec_disable_arg_limit` in
+        *1*) lt_cv_sys_max_cmd_len=-1 ;;
+      esac
+    fi
+    ;;
+  sco3.2v5*)
+    lt_cv_sys_max_cmd_len=102400
+    ;;
+  sysv5* | sco5v6* | sysv4.2uw2*)
+    kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null`
+    if test -n "$kargmax"; then
+      lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[ 	]]//'`
+    else
+      lt_cv_sys_max_cmd_len=32768
+    fi
+    ;;
+  *)
+    lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2> /dev/null`
+    if test -n "$lt_cv_sys_max_cmd_len"; then
+      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
+      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
+    else
+      SHELL=${SHELL-${CONFIG_SHELL-/bin/sh}}
+      while (test "X"`$SHELL [$]0 --fallback-echo "X$teststring" 2>/dev/null` \
 	       = "XX$teststring") >/dev/null 2>&1 &&
-	    new_result=`expr "X$teststring" : ".*" 2>&1` &&
-	    lt_cv_sys_max_cmd_len=$new_result &&
-	    test $i != 17 # 1/2 MB should be enough
-    do
-      i=`expr $i + 1`
-      teststring=$teststring$teststring
-    done
-    teststring=
-    # Add a significant safety factor because C++ compilers can tack on massive
-    # amounts of additional arguments before passing them to the linker.
-    # It appears as though 1/2 is a usable value.
-    lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 2`
+	      new_result=`expr "X$teststring" : ".*" 2>&1` &&
+	      lt_cv_sys_max_cmd_len=$new_result &&
+	      test $i != 17 # 1/2 MB should be enough
+      do
+        i=`expr $i + 1`
+        teststring=$teststring$teststring
+      done
+      teststring=
+      # Add a significant safety factor because C++ compilers can tack on massive
+      # amounts of additional arguments before passing them to the linker.
+      # It appears as though 1/2 is a usable value.
+      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 2`
+    fi
     ;;
   esac
 ])
@@ -722,7 +903,7 @@ fi
 
 
 # _LT_AC_CHECK_DLFCN
-# --------------------
+# ------------------
 AC_DEFUN([_LT_AC_CHECK_DLFCN],
 [AC_CHECK_HEADERS(dlfcn.h)dnl
 ])# _LT_AC_CHECK_DLFCN
@@ -730,7 +911,7 @@ AC_DEFUN([_LT_AC_CHECK_DLFCN],
 
 # _LT_AC_TRY_DLOPEN_SELF (ACTION-IF-TRUE, ACTION-IF-TRUE-W-USCORE,
 #                           ACTION-IF-FALSE, ACTION-IF-CROSS-COMPILING)
-# ------------------------------------------------------------------
+# ---------------------------------------------------------------------
 AC_DEFUN([_LT_AC_TRY_DLOPEN_SELF],
 [AC_REQUIRE([_LT_AC_CHECK_DLFCN])dnl
 if test "$cross_compiling" = yes; then :
@@ -796,17 +977,19 @@ int main ()
       else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
       /* dlclose (self); */
     }
+  else
+    puts (dlerror ());
 
     exit (status);
 }]
 EOF
   if AC_TRY_EVAL(ac_link) && test -s conftest${ac_exeext} 2>/dev/null; then
-    (./conftest; exit; ) 2>/dev/null
+    (./conftest; exit; ) >&AS_MESSAGE_LOG_FD 2>/dev/null
     lt_status=$?
     case x$lt_status in
       x$lt_dlno_uscore) $1 ;;
       x$lt_dlneed_uscore) $2 ;;
-      x$lt_unknown|x*) $3 ;;
+      x$lt_dlunknown|x*) $3 ;;
     esac
   else :
     # compilation failed
@@ -818,7 +1001,7 @@ rm -fr conftest*
 
 
 # AC_LIBTOOL_DLOPEN_SELF
-# -------------------
+# ----------------------
 AC_DEFUN([AC_LIBTOOL_DLOPEN_SELF],
 [AC_REQUIRE([_LT_AC_CHECK_DLFCN])dnl
 if test "x$enable_dlopen" != xyes; then
@@ -860,7 +1043,7 @@ else
     AC_CHECK_FUNC([shl_load],
 	  [lt_cv_dlopen="shl_load"],
       [AC_CHECK_LIB([dld], [shl_load],
-	    [lt_cv_dlopen="shl_load" lt_cv_dlopen_libs="-dld"],
+	    [lt_cv_dlopen="shl_load" lt_cv_dlopen_libs="-ldld"],
 	[AC_CHECK_FUNC([dlopen],
 	      [lt_cv_dlopen="dlopen"],
 	  [AC_CHECK_LIB([dl], [dlopen],
@@ -868,7 +1051,7 @@ else
 	    [AC_CHECK_LIB([svld], [dlopen],
 		  [lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-lsvld"],
 	      [AC_CHECK_LIB([dld], [dld_link],
-		    [lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-dld"])
+		    [lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-ldld"])
 	      ])
 	    ])
 	  ])
@@ -889,7 +1072,7 @@ else
     test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
 
     save_LDFLAGS="$LDFLAGS"
-    eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
+    wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
 
     save_LIBS="$LIBS"
     LIBS="$lt_cv_dlopen_libs $LIBS"
@@ -902,7 +1085,7 @@ else
     ])
 
     if test "x$lt_cv_dlopen_self" = xyes; then
-      LDFLAGS="$LDFLAGS $link_static_flag"
+      wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $lt_prog_compiler_static\"
       AC_CACHE_CHECK([whether a statically linked program can dlopen itself],
     	  lt_cv_dlopen_self_static, [dnl
 	  _LT_AC_TRY_DLOPEN_SELF(
@@ -934,7 +1117,8 @@ fi
 # ---------------------------------
 # Check to see if options -c and -o are simultaneously supported by compiler
 AC_DEFUN([AC_LIBTOOL_PROG_CC_C_O],
-[AC_REQUIRE([_LT_AC_SYS_COMPILER])dnl
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_REQUIRE([_LT_AC_SYS_COMPILER])dnl
 AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
   [_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)],
   [_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)=no
@@ -942,7 +1126,7 @@ AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
    mkdir conftest
    cd conftest
    mkdir out
-   printf "$lt_simple_compile_test_code" > conftest.$ac_ext
+   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
 
    lt_compiler_flag="-o out/conftest2.$ac_objext"
    # Insert the option either (1) after the last *FLAGS variable, or
@@ -950,7 +1134,7 @@ AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
    # Note that $ac_compile itself does not contain backslashes and begins
    # with a dollar sign (not a hyphen), so the echo should work correctly.
    lt_compile=`echo "$ac_compile" | $SED \
-   -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [[^ ]]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
    (eval echo "\"\$as_me:__oline__: $lt_compile\"" >&AS_MESSAGE_LOG_FD)
@@ -962,11 +1146,13 @@ AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
    then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
-     if test ! -s out/conftest.err; then
+     $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
+     $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
+     if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
        _LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)=yes
      fi
    fi
-   chmod u+w .
+   chmod u+w . 2>&AS_MESSAGE_LOG_FD
    $rm conftest*
    # SGI C++ compiler will create directory out/ii_files/ for
    # template instantiation
@@ -1080,6 +1266,7 @@ else
    darwin*)
        if test -n "$STRIP" ; then
          striplib="$STRIP -x"
+         old_striplib="$STRIP -S"
          AC_MSG_RESULT([yes])
        else
   AC_MSG_RESULT([no])
@@ -1097,7 +1284,8 @@ fi
 # -----------------------------
 # PORTME Fill in your ld.so characteristics
 AC_DEFUN([AC_LIBTOOL_SYS_DYNAMIC_LINKER],
-[AC_MSG_CHECKING([dynamic linker characteristics])
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_MSG_CHECKING([dynamic linker characteristics])
 library_names_spec=
 libname_spec='lib$name'
 soname_spec=
@@ -1111,20 +1299,58 @@ shlibpath_overrides_runpath=unknown
 version_type=none
 dynamic_linker="$host_os ld.so"
 sys_lib_dlsearch_path_spec="/lib /usr/lib"
+m4_if($1,[],[
 if test "$GCC" = yes; then
-  sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
-  if echo "$sys_lib_search_path_spec" | grep ';' >/dev/null ; then
+  case $host_os in
+    darwin*) lt_awk_arg="/^libraries:/,/LR/" ;;
+    *) lt_awk_arg="/^libraries:/" ;;
+  esac
+  lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg | $SED -e "s/^libraries://" -e "s,=/,/,g"`
+  if echo "$lt_search_path_spec" | grep ';' >/dev/null ; then
     # if the path contains ";" then we assume it to be the separator
     # otherwise default to the standard path separator (i.e. ":") - it is
     # assumed that no part of a normal pathname contains ";" but that should
     # okay in the real world where ";" in dirpaths is itself problematic.
-    sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
+    lt_search_path_spec=`echo "$lt_search_path_spec" | $SED -e 's/;/ /g'`
   else
-    sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED  -e "s/$PATH_SEPARATOR/ /g"`
+    lt_search_path_spec=`echo "$lt_search_path_spec" | $SED  -e "s/$PATH_SEPARATOR/ /g"`
   fi
+  # Ok, now we have the path, separated by spaces, we can step through it
+  # and add multilib dir if necessary.
+  lt_tmp_lt_search_path_spec=
+  lt_multi_os_dir=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
+  for lt_sys_path in $lt_search_path_spec; do
+    if test -d "$lt_sys_path/$lt_multi_os_dir"; then
+      lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/$lt_multi_os_dir"
+    else
+      test -d "$lt_sys_path" && \
+	lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path"
+    fi
+  done
+  lt_search_path_spec=`echo $lt_tmp_lt_search_path_spec | awk '
+BEGIN {RS=" "; FS="/|\n";} {
+  lt_foo="";
+  lt_count=0;
+  for (lt_i = NF; lt_i > 0; lt_i--) {
+    if ($lt_i != "" && $lt_i != ".") {
+      if ($lt_i == "..") {
+        lt_count++;
+      } else {
+        if (lt_count == 0) {
+          lt_foo="/" $lt_i lt_foo;
+        } else {
+          lt_count--;
+        }
+      }
+    }
+  }
+  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
+  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
+}'`
+  sys_lib_search_path_spec=`echo $lt_search_path_spec`
 else
   sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
-fi
+fi])
 need_lib_prefix=unknown
 hardcode_into_libs=no
 
@@ -1142,7 +1368,7 @@ aix3*)
   soname_spec='${libname}${release}${shared_ext}$major'
   ;;
 
-aix4* | aix5*)
+aix[[4-9]]*)
   version_type=linux
   need_lib_prefix=no
   need_version=no
@@ -1226,7 +1452,8 @@ cygwin* | mingw* | pw32*)
       dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo \$dlname'\''`~
       dldir=$destdir/`dirname \$dlpath`~
       test -d \$dldir || mkdir -p \$dldir~
-      $install_prog $dir/$dlname \$dldir/$dlname'
+      $install_prog $dir/$dlname \$dldir/$dlname~
+      chmod a+x \$dldir/$dlname'
     postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
       dlpath=$dir/\$dldll~
        $rm \$dlpath'
@@ -1256,7 +1483,7 @@ cygwin* | mingw* | pw32*)
       ;;
     pw32*)
       # pw32 DLLs use 'pw' prefix rather than 'lib'
-      library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
+      library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
       ;;
     esac
     ;;
@@ -1279,13 +1506,9 @@ darwin* | rhapsody*)
   soname_spec='${libname}${release}${major}$shared_ext'
   shlibpath_overrides_runpath=yes
   shlibpath_var=DYLD_LIBRARY_PATH
-  shrext_cmds='$(test .$module = .yes && echo .so || echo .dylib)'
-  # Apple's gcc prints 'gcc -print-search-dirs' doesn't operate the same.
-  if test "$GCC" = yes; then
-    sys_lib_search_path_spec=`$CC -print-search-dirs | tr "\n" "$PATH_SEPARATOR" | sed -e 's/libraries:/@libraries:/' | tr "@" "\n" | grep "^libraries:" | sed -e "s/^libraries://" -e "s,=/,/,g" -e "s,$PATH_SEPARATOR, ,g" -e "s,.*,& /lib /usr/lib /usr/local/lib,g"`
-  else
-    sys_lib_search_path_spec='/lib /usr/lib /usr/local/lib'
-  fi
+  shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
+  m4_if([$1], [],[
+  sys_lib_search_path_spec="$sys_lib_search_path_spec /usr/local/lib"]) 
   sys_lib_dlsearch_path_spec='/usr/local/lib /lib /usr/lib'
   ;;
 
@@ -1302,20 +1525,17 @@ freebsd1*)
   dynamic_linker=no
   ;;
 
-kfreebsd*-gnu)
-  version_type=linux
-  need_lib_prefix=no
-  need_version=no
-  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
-  soname_spec='${libname}${release}${shared_ext}$major'
-  shlibpath_var=LD_LIBRARY_PATH
-  shlibpath_overrides_runpath=no
-  hardcode_into_libs=yes
-  dynamic_linker='GNU ld.so'
-  ;;
-
-freebsd*)
-  objformat=`test -x /usr/bin/objformat && /usr/bin/objformat || echo aout`
+freebsd* | dragonfly*)
+  # DragonFly does not have aout.  When/if they implement a new
+  # versioning mechanism, adjust this.
+  if test -x /usr/bin/objformat; then
+    objformat=`/usr/bin/objformat`
+  else
+    case $host_os in
+    freebsd[[123]]*) objformat=aout ;;
+    *) objformat=elf ;;
+    esac
+  fi
   version_type=freebsd-$objformat
   case $version_type in
     freebsd-elf*)
@@ -1333,14 +1553,19 @@ freebsd*)
   freebsd2*)
     shlibpath_overrides_runpath=yes
     ;;
-  freebsd3.[01]* | freebsdelf3.[01]*)
+  freebsd3.[[01]]* | freebsdelf3.[[01]]*)
     shlibpath_overrides_runpath=yes
     hardcode_into_libs=yes
     ;;
-  *) # from 3.2 on
+  freebsd3.[[2-9]]* | freebsdelf3.[[2-9]]* | \
+  freebsd4.[[0-5]] | freebsdelf4.[[0-5]] | freebsd4.1.1 | freebsdelf4.1.1)
     shlibpath_overrides_runpath=no
     hardcode_into_libs=yes
     ;;
+  *) # from 4.6 on, and DragonFly
+    shlibpath_overrides_runpath=yes
+    hardcode_into_libs=yes
+    ;;
   esac
   ;;
 
@@ -1360,7 +1585,7 @@ hpux9* | hpux10* | hpux11*)
   version_type=sunos
   need_lib_prefix=no
   need_version=no
-  case "$host_cpu" in
+  case $host_cpu in
   ia64*)
     shrext_cmds='.so'
     hardcode_into_libs=yes
@@ -1400,6 +1625,18 @@ hpux9* | hpux10* | hpux11*)
   postinstall_cmds='chmod 555 $lib'
   ;;
 
+interix[[3-9]]*)
+  version_type=linux
+  need_lib_prefix=no
+  need_version=no
+  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+  soname_spec='${libname}${release}${shared_ext}$major'
+  dynamic_linker='Interix 3.x ld.so.1 (PE, like ELF)'
+  shlibpath_var=LD_LIBRARY_PATH
+  shlibpath_overrides_runpath=no
+  hardcode_into_libs=yes
+  ;;
+
 irix5* | irix6* | nonstopux*)
   case $host_os in
     nonstopux*) version_type=nonstopux ;;
@@ -1443,7 +1680,7 @@ linux*oldld* | linux*aout* | linux*coff*)
   ;;
 
 # This must be Linux ELF.
-linux*)
+linux* | k*bsd*-gnu)
   version_type=linux
   need_lib_prefix=no
   need_version=no
@@ -1459,7 +1696,7 @@ linux*)
 
   # Append ld.so.conf contents to the search path
   if test -f /etc/ld.so.conf; then
-    lt_ld_extra=`$SED -e 's/[:,\t]/ /g;s/=[^=]*$//;s/=[^= ]* / /g' /etc/ld.so.conf | tr '\n' ' '`
+    lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;/^[ 	]*hwcap[ 	]/d;s/[:,	]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
     sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
   fi
 
@@ -1472,18 +1709,6 @@ linux*)
   dynamic_linker='GNU/Linux ld.so'
   ;;
 
-knetbsd*-gnu)
-  version_type=linux
-  need_lib_prefix=no
-  need_version=no
-  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
-  soname_spec='${libname}${release}${shared_ext}$major'
-  shlibpath_var=LD_LIBRARY_PATH
-  shlibpath_overrides_runpath=no
-  hardcode_into_libs=yes
-  dynamic_linker='GNU ld.so'
-  ;;
-
 netbsd*)
   version_type=sunos
   need_lib_prefix=no
@@ -1521,8 +1746,13 @@ nto-qnx*)
 
 openbsd*)
   version_type=sunos
+  sys_lib_dlsearch_path_spec="/usr/lib"
   need_lib_prefix=no
-  need_version=no
+  # Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
+  case $host_os in
+    openbsd3.3 | openbsd3.3.*) need_version=yes ;;
+    *)                         need_version=no  ;;
+  esac
   library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
   finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
   shlibpath_var=LD_LIBRARY_PATH
@@ -1560,11 +1790,8 @@ osf3* | osf4* | osf5*)
   sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
   ;;
 
-sco3.2v5*)
-  version_type=osf
-  soname_spec='${libname}${release}${shared_ext}$major'
-  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
-  shlibpath_var=LD_LIBRARY_PATH
+rdos*)
+  dynamic_linker=no
   ;;
 
 solaris*)
@@ -1592,7 +1819,7 @@ sunos4*)
   need_version=yes
   ;;
 
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
   version_type=linux
   library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
   soname_spec='${libname}${release}${shared_ext}$major'
@@ -1625,6 +1852,29 @@ sysv4*MP*)
   fi
   ;;
 
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+  version_type=freebsd-elf
+  need_lib_prefix=no
+  need_version=no
+  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
+  soname_spec='${libname}${release}${shared_ext}$major'
+  shlibpath_var=LD_LIBRARY_PATH
+  hardcode_into_libs=yes
+  if test "$with_gnu_ld" = yes; then
+    sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib /usr/lib /lib'
+    shlibpath_overrides_runpath=no
+  else
+    sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+    shlibpath_overrides_runpath=yes
+    case $host_os in
+      sco3.2v5*)
+        sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+	;;
+    esac
+  fi
+  sys_lib_dlsearch_path_spec='/usr/lib'
+  ;;
+
 uts4*)
   version_type=linux
   library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
@@ -1638,13 +1888,26 @@ uts4*)
 esac
 AC_MSG_RESULT([$dynamic_linker])
 test "$dynamic_linker" = no && can_build_shared=no
+
+AC_CACHE_VAL([lt_cv_sys_lib_search_path_spec],
+[lt_cv_sys_lib_search_path_spec="$sys_lib_search_path_spec"])
+sys_lib_search_path_spec="$lt_cv_sys_lib_search_path_spec"
+AC_CACHE_VAL([lt_cv_sys_lib_dlsearch_path_spec],
+[lt_cv_sys_lib_dlsearch_path_spec="$sys_lib_dlsearch_path_spec"])
+sys_lib_dlsearch_path_spec="$lt_cv_sys_lib_dlsearch_path_spec"
+
+variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
+if test "$GCC" = yes; then
+  variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
+fi
 ])# AC_LIBTOOL_SYS_DYNAMIC_LINKER
 
 
 # _LT_AC_TAGCONFIG
 # ----------------
 AC_DEFUN([_LT_AC_TAGCONFIG],
-[AC_ARG_WITH([tags],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_ARG_WITH([tags],
     [AC_HELP_STRING([--with-tags@<:@=TAGS@:>@],
         [include additional configurations @<:@automatic@:>@])],
     [tagnames="$withval"])
@@ -1662,6 +1925,9 @@ if test -f "$ltmain" && test -n "$tagnames"; then
       AC_MSG_WARN([using `LTCC=$LTCC', extracted from `$ofile'])
     fi
   fi
+  if test -z "$LTCFLAGS"; then
+    eval "`$SHELL ${ofile} --config | grep '^LTCFLAGS='`"
+  fi
 
   # Extract list of available tagged configurations in $ofile.
   # Note that this assumes the entire list is on one line.
@@ -1689,7 +1955,7 @@ if test -f "$ltmain" && test -n "$tagnames"; then
       case $tagname in
       CXX)
 	if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
-	    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) || 
+	    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
 	    (test "X$CXX" != "Xg++"))) ; then
 	  AC_LIBTOOL_LANG_CXX_CONFIG
 	else
@@ -1752,7 +2018,7 @@ AC_DEFUN([AC_LIBTOOL_DLOPEN],
 
 # AC_LIBTOOL_WIN32_DLL
 # --------------------
-# declare package support for building win32 dll's
+# declare package support for building win32 DLLs
 AC_DEFUN([AC_LIBTOOL_WIN32_DLL],
 [AC_BEFORE([$0], [AC_LIBTOOL_SETUP])
 ])# AC_LIBTOOL_WIN32_DLL
@@ -1790,7 +2056,7 @@ AC_ARG_ENABLE([shared],
 
 # AC_DISABLE_SHARED
 # -----------------
-#- set the default shared flag to --disable-shared
+# set the default shared flag to --disable-shared
 AC_DEFUN([AC_DISABLE_SHARED],
 [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
 AC_ENABLE_SHARED(no)
@@ -1902,7 +2168,7 @@ m4_ifndef([AC_PROG_EGREP], [AC_DEFUN([AC_PROG_EGREP],
 
 # AC_PATH_TOOL_PREFIX
 # -------------------
-# find a file program which can recognise shared library
+# find a file program which can recognize shared library
 AC_DEFUN([AC_PATH_TOOL_PREFIX],
 [AC_REQUIRE([AC_PROG_EGREP])dnl
 AC_MSG_CHECKING([for $1])
@@ -1926,7 +2192,7 @@ dnl not every word.  This closes a longstanding sh security hole.
       if test -n "$file_magic_test_file"; then
 	case $deplibs_check_method in
 	"file_magic "*)
-	  file_magic_regex="`expr \"$deplibs_check_method\" : \"file_magic \(.*\)\"`"
+	  file_magic_regex=`expr "$deplibs_check_method" : "file_magic \(.*\)"`
 	  MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
 	  if eval $file_magic_cmd \$file_magic_test_file 2> /dev/null |
 	    $EGREP "$file_magic_regex" > /dev/null; then
@@ -1965,7 +2231,7 @@ fi
 
 # AC_PATH_MAGIC
 # -------------
-# find a file program which can recognise a shared library
+# find a file program which can recognize a shared library
 AC_DEFUN([AC_PATH_MAGIC],
 [AC_PATH_TOOL_PREFIX(${ac_tool_prefix}file, /usr/bin$PATH_SEPARATOR$PATH)
 if test -z "$lt_cv_path_MAGIC_CMD"; then
@@ -2036,7 +2302,7 @@ AC_CACHE_VAL(lt_cv_path_LD,
     if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then
       lt_cv_path_LD="$ac_dir/$ac_prog"
       # Check to see if the program is GNU ld.  I'd rather use --version,
-      # but apparently some GNU ld's only accept -v.
+      # but apparently some variants of GNU ld only accept -v.
       # Break only if it was the GNU/non-GNU ld that we prefer.
       case `"$lt_cv_path_LD" -v 2>&1 &1 /dev/null 2>&1; then
+    lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
+    lt_cv_file_magic_cmd='func_win32_libid'
+  else
+    lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?'
+    lt_cv_file_magic_cmd='$OBJDUMP -f'
+  fi
   ;;
 
 darwin* | rhapsody*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
-freebsd* | kfreebsd*-gnu)
+freebsd* | dragonfly*)
   if echo __ELF__ | $CC -E - | grep __ELF__ > /dev/null; then
     case $host_cpu in
     i*86 )
       # Not sure whether the presence of OpenBSD here was a mistake.
       # Let's accept both of them until this is cleared up.
-      lt_cv_deplibs_check_method='file_magic (FreeBSD|OpenBSD)/i[[3-9]]86 (compact )?demand paged shared library'
+      lt_cv_deplibs_check_method='file_magic (FreeBSD|OpenBSD|DragonFly)/i[[3-9]]86 (compact )?demand paged shared library'
       lt_cv_file_magic_cmd=/usr/bin/file
       lt_cv_file_magic_test_file=`echo /usr/lib/libc.so.*`
       ;;
@@ -2182,7 +2454,7 @@ gnu*)
 
 hpux10.20* | hpux11*)
   lt_cv_file_magic_cmd=/usr/bin/file
-  case "$host_cpu" in
+  case $host_cpu in
   ia64*)
     lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]|ELF-[[0-9]][[0-9]]) shared object file - IA64'
     lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
@@ -2198,6 +2470,11 @@ hpux10.20* | hpux11*)
   esac
   ;;
 
+interix[[3-9]]*)
+  # PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a here
+  lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
+  ;;
+
 irix5* | irix6* | nonstopux*)
   case $LD in
   *-32|*"-32 ") libmagic=32-bit;;
@@ -2209,7 +2486,7 @@ irix5* | irix6* | nonstopux*)
   ;;
 
 # This must be Linux ELF.
-linux*)
+linux* | k*bsd*-gnu)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
@@ -2243,7 +2520,7 @@ osf3* | osf4* | osf5*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
-sco3.2v5*)
+rdos*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
@@ -2251,7 +2528,7 @@ solaris*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
   case $host_vendor in
   motorola)
     lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB (shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
@@ -2272,10 +2549,13 @@ sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
   siemens)
     lt_cv_deplibs_check_method=pass_all
     ;;
+  pc)
+    lt_cv_deplibs_check_method=pass_all
+    ;;
   esac
   ;;
 
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7* | sysv4*uw2*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 esac
@@ -2295,36 +2575,43 @@ AC_DEFUN([AC_PROG_NM],
   # Let the user override the test.
   lt_cv_path_NM="$NM"
 else
-  lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
-  for ac_dir in $PATH /usr/ccs/bin /usr/ucb /bin; do
-    IFS="$lt_save_ifs"
-    test -z "$ac_dir" && ac_dir=.
-    tmp_nm="$ac_dir/${ac_tool_prefix}nm"
-    if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
-      # Check to see if the nm accepts a BSD-compat flag.
-      # Adding the `sed 1q' prevents false positives on HP-UX, which says:
-      #   nm: unknown option "B" ignored
-      # Tru64's nm complains that /dev/null is an invalid object file
-      case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
-      */dev/null* | *'Invalid file or object type'*)
-	lt_cv_path_NM="$tmp_nm -B"
-	break
-        ;;
-      *)
-	case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
-	*/dev/null*)
-	  lt_cv_path_NM="$tmp_nm -p"
+  lt_nm_to_check="${ac_tool_prefix}nm"
+  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
+    lt_nm_to_check="$lt_nm_to_check nm"
+  fi
+  for lt_tmp_nm in $lt_nm_to_check; do
+    lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
+    for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
+      IFS="$lt_save_ifs"
+      test -z "$ac_dir" && ac_dir=.
+      tmp_nm="$ac_dir/$lt_tmp_nm"
+      if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
+	# Check to see if the nm accepts a BSD-compat flag.
+	# Adding the `sed 1q' prevents false positives on HP-UX, which says:
+	#   nm: unknown option "B" ignored
+	# Tru64's nm complains that /dev/null is an invalid object file
+	case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
+	*/dev/null* | *'Invalid file or object type'*)
+	  lt_cv_path_NM="$tmp_nm -B"
 	  break
 	  ;;
 	*)
-	  lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
-	  continue # so that we can try to find one that supports BSD flags
+	  case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
+	  */dev/null*)
+	    lt_cv_path_NM="$tmp_nm -p"
+	    break
+	    ;;
+	  *)
+	    lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
+	    continue # so that we can try to find one that supports BSD flags
+	    ;;
+	  esac
 	  ;;
 	esac
-      esac
-    fi
+      fi
+    done
+    IFS="$lt_save_ifs"
   done
-  IFS="$lt_save_ifs"
   test -z "$lt_cv_path_NM" && lt_cv_path_NM=nm
 fi])
 NM="$lt_cv_path_NM"
@@ -2356,13 +2643,13 @@ esac
 # -----------------------------------
 # sets LIBLTDL to the link flags for the libltdl convenience library and
 # LTDLINCL to the include flags for the libltdl header and adds
-# --enable-ltdl-convenience to the configure arguments.  Note that LIBLTDL
-# and LTDLINCL are not AC_SUBSTed, nor is AC_CONFIG_SUBDIRS called.  If
-# DIRECTORY is not provided, it is assumed to be `libltdl'.  LIBLTDL will
-# be prefixed with '${top_builddir}/' and LTDLINCL will be prefixed with
-# '${top_srcdir}/' (note the single quotes!).  If your package is not
-# flat and you're not using automake, define top_builddir and
-# top_srcdir appropriately in the Makefiles.
+# --enable-ltdl-convenience to the configure arguments.  Note that
+# AC_CONFIG_SUBDIRS is not called here.  If DIRECTORY is not provided,
+# it is assumed to be `libltdl'.  LIBLTDL will be prefixed with
+# '${top_builddir}/' and LTDLINCL will be prefixed with '${top_srcdir}/'
+# (note the single quotes!).  If your package is not flat and you're not
+# using automake, define top_builddir and top_srcdir appropriately in
+# the Makefiles.
 AC_DEFUN([AC_LIBLTDL_CONVENIENCE],
 [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
   case $enable_ltdl_convenience in
@@ -2381,13 +2668,13 @@ AC_DEFUN([AC_LIBLTDL_CONVENIENCE],
 # -----------------------------------
 # sets LIBLTDL to the link flags for the libltdl installable library and
 # LTDLINCL to the include flags for the libltdl header and adds
-# --enable-ltdl-install to the configure arguments.  Note that LIBLTDL
-# and LTDLINCL are not AC_SUBSTed, nor is AC_CONFIG_SUBDIRS called.  If
-# DIRECTORY is not provided and an installed libltdl is not found, it is
-# assumed to be `libltdl'.  LIBLTDL will be prefixed with '${top_builddir}/'
-# and LTDLINCL will be prefixed with '${top_srcdir}/' (note the single
-# quotes!).  If your package is not flat and you're not using automake,
-# define top_builddir and top_srcdir appropriately in the Makefiles.
+# --enable-ltdl-install to the configure arguments.  Note that
+# AC_CONFIG_SUBDIRS is not called here.  If DIRECTORY is not provided,
+# and an installed libltdl is not found, it is assumed to be `libltdl'.
+# LIBLTDL will be prefixed with '${top_builddir}/'# and LTDLINCL with
+# '${top_srcdir}/' (note the single quotes!).  If your package is not
+# flat and you're not using automake, define top_builddir and top_srcdir
+# appropriately in the Makefiles.
 # In the future, this macro may have to be called after AC_PROG_LIBTOOL.
 AC_DEFUN([AC_LIBLTDL_INSTALLABLE],
 [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
@@ -2430,12 +2717,12 @@ _LT_AC_SHELL_INIT([tagnames=${tagnames+${tagnames},}CXX])
 ])# _LT_AC_LANG_CXX
 
 # _LT_AC_PROG_CXXCPP
-# ---------------
+# ------------------
 AC_DEFUN([_LT_AC_PROG_CXXCPP],
 [
 AC_REQUIRE([AC_PROG_CXX])
 if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
-    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) || 
+    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
     (test "X$CXX" != "Xg++"))) ; then
   AC_PROG_CXXCPP
 fi
@@ -2479,7 +2766,7 @@ _LT_AC_SHELL_INIT([tagnames=${tagnames+${tagnames},}GCJ])
 
 
 # AC_LIBTOOL_RC
-# --------------
+# -------------
 # enable support for Windows resource files
 AC_DEFUN([AC_LIBTOOL_RC],
 [AC_REQUIRE([LT_AC_PROG_RC])
@@ -2505,43 +2792,16 @@ objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code="int some_variable = 0;\n"
+lt_simple_compile_test_code="int some_variable = 0;"
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='int main(){return(0);}\n'
+lt_simple_link_test_code='int main(){return(0);}'
 
 _LT_AC_SYS_COMPILER
 
-#
-# Check for any special shared library compilation flags.
-#
-_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)=
-if test "$GCC" = no; then
-  case $host_os in
-  sco3.2v5*)
-    _LT_AC_TAGVAR(lt_prog_cc_shlib, $1)='-belf'
-    ;;
-  esac
-fi
-if test -n "$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)"; then
-  AC_MSG_WARN([`$CC' requires `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to build shared libraries])
-  if echo "$old_CC $old_CFLAGS " | grep "[[ 	]]$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)[[ 	]]" >/dev/null; then :
-  else
-    AC_MSG_WARN([add `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to the CC or CFLAGS env variable and reconfigure])
-    _LT_AC_TAGVAR(lt_cv_prog_cc_can_build_shared, $1)=no
-  fi
-fi
-
-
-#
-# Check to make sure the static flag actually works.
-#
-AC_LIBTOOL_LINKER_OPTION([if $compiler static flag $_LT_AC_TAGVAR(lt_prog_compiler_static, $1) works],
-  _LT_AC_TAGVAR(lt_prog_compiler_static_works, $1),
-  $_LT_AC_TAGVAR(lt_prog_compiler_static, $1),
-  [],
-  [_LT_AC_TAGVAR(lt_prog_compiler_static, $1)=])
-
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
 
 ## CAVEAT EMPTOR:
 ## There is no encapsulation within the following macros, do not change
@@ -2555,9 +2815,9 @@ AC_LIBTOOL_PROG_LD_SHLIBS($1)
 AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
 AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
 AC_LIBTOOL_SYS_LIB_STRIP
-AC_LIBTOOL_DLOPEN_SELF($1)
+AC_LIBTOOL_DLOPEN_SELF
 
-# Report which libraries types will actually be built
+# Report which library types will actually be built
 AC_MSG_CHECKING([if libtool supports shared libraries])
 AC_MSG_RESULT([$can_build_shared])
 
@@ -2566,7 +2826,7 @@ test "$can_build_shared" = "no" && enable_shared=no
 
 # On AIX, shared libraries and static libraries use the same namespace, and
 # are all built from PIC.
-case "$host_os" in
+case $host_os in
 aix3*)
   test "$enable_shared" = yes && enable_static=no
   if test -n "$RANLIB"; then
@@ -2575,7 +2835,7 @@ aix3*)
   fi
   ;;
 
-aix4* | aix5*)
+aix[[4-9]]*)
   if test "$host_cpu" != ia64 && test "$aix_use_runtimelinking" = no ; then
     test "$enable_shared" = yes && enable_static=no
   fi
@@ -2616,6 +2876,7 @@ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
 _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
 _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=
 _LT_AC_TAGVAR(hardcode_minus_L, $1)=no
+_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
 _LT_AC_TAGVAR(hardcode_automatic, $1)=no
 _LT_AC_TAGVAR(module_cmds, $1)=
 _LT_AC_TAGVAR(module_expsym_cmds, $1)=
@@ -2631,23 +2892,28 @@ _LT_AC_TAGVAR(postdep_objects, $1)=
 _LT_AC_TAGVAR(predeps, $1)=
 _LT_AC_TAGVAR(postdeps, $1)=
 _LT_AC_TAGVAR(compiler_lib_search_path, $1)=
+_LT_AC_TAGVAR(compiler_lib_search_dirs, $1)=
 
 # Source file extension for C++ test sources.
-ac_ext=cc
+ac_ext=cpp
 
 # Object file extension for compiled C++ test sources.
 objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code="int some_variable = 0;\n"
+lt_simple_compile_test_code="int some_variable = 0;"
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='int main(int, char *[]) { return(0); }\n'
+lt_simple_link_test_code='int main(int, char *[[]]) { return(0); }'
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_AC_SYS_COMPILER
 
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
 # Allow CC to be a program name with arguments.
 lt_save_CC=$CC
 lt_save_LD=$LD
@@ -2658,18 +2924,18 @@ lt_save_path_LD=$lt_cv_path_LD
 if test -n "${lt_cv_prog_gnu_ldcxx+set}"; then
   lt_cv_prog_gnu_ld=$lt_cv_prog_gnu_ldcxx
 else
-  unset lt_cv_prog_gnu_ld
+  $as_unset lt_cv_prog_gnu_ld
 fi
 if test -n "${lt_cv_path_LDCXX+set}"; then
   lt_cv_path_LD=$lt_cv_path_LDCXX
 else
-  unset lt_cv_path_LD
+  $as_unset lt_cv_path_LD
 fi
 test -z "${LDCXX+set}" || LD=$LDCXX
 CC=${CXX-"c++"}
 compiler=$CC
 _LT_AC_TAGVAR(compiler, $1)=$CC
-cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
+_LT_CC_BASENAME([$compiler])
 
 # We don't want -fno-exception wen compiling C++ code, so set the
 # no_builtin_flag separately
@@ -2736,7 +3002,7 @@ case $host_os in
     # FIXME: insert proper C++ library support
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
     ;;
-  aix4* | aix5*)
+  aix[[4-9]]*)
     if test "$host_cpu" = ia64; then
       # On IA64, the linker does run time linking by default, so we don't
       # have to do anything special.
@@ -2749,7 +3015,7 @@ case $host_os in
       # Test if we are trying to use run time linking or normal
       # AIX style linking. If -brtl is somewhere in LDFLAGS, we
       # need to do runtime linking.
-      case $host_os in aix4.[[23]]|aix4.[[23]].*|aix5*)
+      case $host_os in aix4.[[23]]|aix4.[[23]].*|aix[[5-9]]*)
 	for ld_flag in $LDFLAGS; do
 	  case $ld_flag in
 	  *-brtl*)
@@ -2758,6 +3024,7 @@ case $host_os in
 	    ;;
 	  esac
 	done
+	;;
       esac
 
       exp_sym_flag='-bexport'
@@ -2776,7 +3043,7 @@ case $host_os in
     _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
 
     if test "$GXX" = yes; then
-      case $host_os in aix4.[012]|aix4.[012].*)
+      case $host_os in aix4.[[012]]|aix4.[[012]].*)
       # We only want to do this on AIX 4.2 and lower, the check
       # below for broken collect2 doesn't work under 4.3+
 	collect2name=`${CC} -print-prog-name=collect2`
@@ -2784,7 +3051,7 @@ case $host_os in
 	   strings "$collect2name" | grep resolve_lib_name >/dev/null
 	then
 	  # We have reworked collect2
-	  _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+	  :
 	else
 	  # We have old collect2
 	  _LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
@@ -2795,8 +3062,12 @@ case $host_os in
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
 	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=
 	fi
+	;;
       esac
       shared_flag='-shared'
+      if test "$aix_use_runtimelinking" = yes; then
+	shared_flag="$shared_flag "'${wl}-G'
+      fi
     else
       # not using gcc
       if test "$host_cpu" = ia64; then
@@ -2823,12 +3094,12 @@ case $host_os in
       _LT_AC_SYS_LIBPATH_AIX
       _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
 
-      _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+      _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
      else
       if test "$host_cpu" = ia64; then
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $libdir:/usr/lib:/lib'
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)="-z nodefs"
-	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
       else
 	# Determine the default libpath from the value encoded in an empty executable.
 	_LT_AC_SYS_LIBPATH_AIX
@@ -2837,16 +3108,26 @@ case $host_os in
 	# -berok will link without error, but may produce a broken library.
 	_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
-	# -bexpall does not export symbols beginning with underscore (_)
-	_LT_AC_TAGVAR(always_export_symbols, $1)=yes
 	# Exported symbols can be pulled into shared objects from archives
-	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
+	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
 	_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
-	# This is similar to how AIX traditionally builds it's shared libraries.
-	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+	# This is similar to how AIX traditionally builds its shared libraries.
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
       fi
     fi
     ;;
+
+  beos*)
+    if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+      _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
+      # Joseph Beckenbach  says some releases of gcc
+      # support --undefined.  This deserves some investigation.  FIXME
+      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -nostart $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
+    else
+      _LT_AC_TAGVAR(ld_shlibs, $1)=no
+    fi
+    ;;
+
   chorus*)
     case $cc_basename in
       *)
@@ -2856,7 +3137,6 @@ case $host_os in
     esac
     ;;
 
-
   cygwin* | mingw* | pw32*)
     # _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
     # as there is no search path for DLLs.
@@ -2866,7 +3146,7 @@ case $host_os in
     _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
 
     if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
-      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
       # If the export-symbols file already is a .def file (1st line
       # is EXPORTS), use it as is; otherwise, prepend...
       _LT_AC_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -2875,65 +3155,37 @@ case $host_os in
 	echo EXPORTS > $output_objdir/$soname.def;
 	cat $export_symbols >> $output_objdir/$soname.def;
       fi~
-      $CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+      $CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
     else
       _LT_AC_TAGVAR(ld_shlibs, $1)=no
     fi
   ;;
       darwin* | rhapsody*)
-        case "$host_os" in
-        rhapsody* | darwin1.[[012]])
-         _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}suppress'
-         ;;
-       *) # Darwin 1.3 on
-         if test -z ${MACOSX_DEPLOYMENT_TARGET} ; then
-           _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-flat_namespace ${wl}-undefined ${wl}suppress'
-         else
-           case ${MACOSX_DEPLOYMENT_TARGET} in
-             10.[[012]])
-               _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-flat_namespace ${wl}-undefined ${wl}suppress'
-               ;;
-             10.*)
-               _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}dynamic_lookup'
-               ;;
-           esac
-         fi
-         ;;
-        esac
       _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
       _LT_AC_TAGVAR(hardcode_direct, $1)=no
       _LT_AC_TAGVAR(hardcode_automatic, $1)=yes
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
       _LT_AC_TAGVAR(whole_archive_flag_spec, $1)=''
       _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
-
-    if test "$GXX" = yes ; then
-      lt_int_apple_cc_single_mod=no
+      _LT_AC_TAGVAR(allow_undefined_flag, $1)="$_lt_dar_allow_undefined"
+      if test "$GXX" = yes ; then
       output_verbose_link_cmd='echo'
-      if $CC -dumpspecs 2>&1 | $EGREP 'single_module' >/dev/null ; then
-       lt_int_apple_cc_single_mod=yes
+      _LT_AC_TAGVAR(archive_cmds, $1)="\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring $_lt_dar_single_mod${_lt_dsymutil}"
+      _LT_AC_TAGVAR(module_cmds, $1)="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dsymutil}"
+      _LT_AC_TAGVAR(archive_expsym_cmds, $1)="sed 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring ${_lt_dar_single_mod}${_lt_dar_export_syms}${_lt_dsymutil}"
+      _LT_AC_TAGVAR(module_expsym_cmds, $1)="sed -e 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dar_export_syms}${_lt_dsymutil}"
+      if test "$lt_cv_apple_cc_single_mod" != "yes"; then
+        _LT_AC_TAGVAR(archive_cmds, $1)="\$CC -r -keep_private_externs -nostdlib -o \${lib}-master.o \$libobjs~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \${lib}-master.o \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring${_lt_dsymutil}"
+        _LT_AC_TAGVAR(archive_expsym_cmds, $1)="sed 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -r -keep_private_externs -nostdlib -o \${lib}-master.o \$libobjs~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \${lib}-master.o \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring${_lt_dar_export_syms}${_lt_dsymutil}"
       fi
-      if test "X$lt_int_apple_cc_single_mod" = Xyes ; then
-       _LT_AC_TAGVAR(archive_cmds, $1)='$CC -dynamiclib -single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
-      else
-          _LT_AC_TAGVAR(archive_cmds, $1)='$CC -r -keep_private_externs -nostdlib -o ${lib}-master.o $libobjs~$CC -dynamiclib $allow_undefined_flag -o $lib ${lib}-master.o $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
-        fi
-        _LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
-        # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
-          if test "X$lt_int_apple_cc_single_mod" = Xyes ; then
-            _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib -single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
-          else
-            _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -r -keep_private_externs -nostdlib -o ${lib}-master.o $libobjs~$CC -dynamiclib $allow_undefined_flag -o $lib ${lib}-master.o $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
-          fi
-            _LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag  -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
       else
-      case "$cc_basename" in
+      case $cc_basename in
         xlc*)
          output_verbose_link_cmd='echo'
-          _LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
+          _LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $xlcverstring'
           _LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
-          # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
-          _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
+          # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
+          _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $xlcverstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
           _LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag  -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
           ;;
        *)
@@ -2945,11 +3197,11 @@ case $host_os in
 
   dgux*)
     case $cc_basename in
-      ec++)
+      ec++*)
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      ghcx)
+      ghcx*)
 	# Green Hills C++ Compiler
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
@@ -2960,14 +3212,14 @@ case $host_os in
 	;;
     esac
     ;;
-  freebsd[12]*)
+  freebsd[[12]]*)
     # C++ shared libraries reported to be fairly broken before switch to ELF
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
     ;;
   freebsd-elf*)
     _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
     ;;
-  freebsd* | kfreebsd*-gnu)
+  freebsd* | dragonfly*)
     # FreeBSD 3 and later use GNU C++ and GNU ld with standard ELF
     # conventions
     _LT_AC_TAGVAR(ld_shlibs, $1)=yes
@@ -2984,11 +3236,11 @@ case $host_os in
 				# location of the library.
 
     case $cc_basename in
-    CC)
+    CC*)
       # FIXME: insert proper C++ library support
       _LT_AC_TAGVAR(ld_shlibs, $1)=no
       ;;
-    aCC)
+    aCC*)
       _LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC -b ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
       # Commands to make compiler produce verbose output that lists
       # what "hidden" libraries, object files and flags are used when
@@ -2998,7 +3250,7 @@ case $host_os in
       # explicitly linking system object files so we need to strip them
       # from the output so that they don't get included in the library
       # dependencies.
-      output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | grep "[-]L"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
+      output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | grep "[[-]]L"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
       ;;
     *)
       if test "$GXX" = yes; then
@@ -3012,34 +3264,21 @@ case $host_os in
     ;;
   hpux10*|hpux11*)
     if test $with_gnu_ld = no; then
-      case "$host_cpu" in
-      hppa*64*)
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
-	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
-        ;;
-      ia64*)
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
-        ;;
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+      _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+      case $host_cpu in
+      hppa*64*|ia64*) ;;
       *)
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
 	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
         ;;
       esac
     fi
-    case "$host_cpu" in
-    hppa*64*)
+    case $host_cpu in
+    hppa*64*|ia64*)
       _LT_AC_TAGVAR(hardcode_direct, $1)=no
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
       ;;
-    ia64*)
-      _LT_AC_TAGVAR(hardcode_direct, $1)=no
-      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-      _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
-					      # but as the default
-					      # location of the library.
-      ;;
     *)
       _LT_AC_TAGVAR(hardcode_direct, $1)=yes
       _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
@@ -3049,14 +3288,17 @@ case $host_os in
     esac
 
     case $cc_basename in
-      CC)
+      CC*)
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      aCC)
-	case "$host_cpu" in
-	hppa*64*|ia64*)
-	  _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
+      aCC*)
+	case $host_cpu in
+	hppa*64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+	  ;;
+	ia64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
 	  ;;
 	*)
 	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
@@ -3075,9 +3317,12 @@ case $host_os in
       *)
 	if test "$GXX" = yes; then
 	  if test $with_gnu_ld = no; then
-	    case "$host_cpu" in
-	    ia64*|hppa*64*)
-	      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
+	    case $host_cpu in
+	    hppa*64*)
+	      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+	      ;;
+	    ia64*)
+	      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
 	      ;;
 	    *)
 	      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
@@ -3091,11 +3336,25 @@ case $host_os in
 	;;
     esac
     ;;
+  interix[[3-9]]*)
+    _LT_AC_TAGVAR(hardcode_direct, $1)=no
+    _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+    _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+    # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+    # Instead, shared libraries are loaded at an image base (0x10000000 by
+    # default) and relocated if they conflict, which is a slow very memory
+    # consuming and fragmenting process.  To avoid this, we pick a random,
+    # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+    # time.  Moving up from 0x10000000 also allows more sbrk(2) space.
+    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+    _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+    ;;
   irix5* | irix6*)
     case $cc_basename in
-      CC)
+      CC*)
 	# SGI C++
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -all -multigot $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations -o $lib'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -all -multigot $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib'
 
 	# Archives containing C++ object files must be created using
 	# "CC -ar", where "CC" is the IRIX C++ compiler.  This is
@@ -3106,7 +3365,7 @@ case $host_os in
       *)
 	if test "$GXX" = yes; then
 	  if test "$with_gnu_ld" = no; then
-	    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+	    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
 	  else
 	    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` -o $lib'
 	  fi
@@ -3117,9 +3376,9 @@ case $host_os in
     _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
     _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
     ;;
-  linux*)
+  linux* | k*bsd*-gnu)
     case $cc_basename in
-      KCC)
+      KCC*)
 	# Kuck and Associates, Inc. (KAI) C++ Compiler
 
 	# KCC will only create a shared library if the output file
@@ -3144,7 +3403,7 @@ case $host_os in
 	# "CC -Bstatic", where "CC" is the KAI C++ compiler.
 	_LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -Bstatic -o $oldlib $oldobjs'
 	;;
-      icpc)
+      icpc*)
 	# Intel C++
 	with_gnu_ld=yes
 	# version 8.0 and above of icpc choke on multiply defined symbols
@@ -3156,8 +3415,12 @@ case $host_os in
   	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
 	  ;;
 	*)  # Version 8.0 or newer
-  	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
-  	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+	  tmp_idyn=
+	  case $host_cpu in
+	    ia64*) tmp_idyn=' -i_dynamic';;
+	  esac
+  	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared'"$tmp_idyn"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared'"$tmp_idyn"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
 	  ;;
 	esac
 	_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
@@ -3165,7 +3428,16 @@ case $host_os in
 	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
 	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive$convenience ${wl}--no-whole-archive'
 	;;
-      cxx)
+      pgCC* | pgcpp*)
+        # Portland Group C++ compiler
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname -o $lib'
+  	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname ${wl}-retain-symbols-file ${wl}$export_symbols -o $lib'
+
+	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'
+	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
+	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+        ;;
+      cxx*)
 	# Compaq C++
 	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname  -o $lib ${wl}-retain-symbols-file $wl$export_symbols'
@@ -3184,6 +3456,29 @@ case $host_os in
 	# dependencies.
 	output_verbose_link_cmd='templist=`$CC -shared $CFLAGS -v conftest.$objext 2>&1 | grep "ld"`; templist=`echo $templist | $SED "s/\(^.*ld.*\)\( .*ld .*$\)/\1/"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
 	;;
+      *)
+	case `$CC -V 2>&1 | sed 5q` in
+	*Sun\ C*)
+	  # Sun C++ 5.9
+	  _LT_AC_TAGVAR(no_undefined_flag, $1)=' -zdefs'
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G${allow_undefined_flag} -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-retain-symbols-file ${wl}$export_symbols'
+	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\"\"; do test -z \"$conv\" || new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+
+	  # Not sure whether something based on
+	  # $CC $CFLAGS -v conftest.$objext -o libconftest$shared_ext 2>&1
+	  # would be better.
+	  output_verbose_link_cmd='echo'
+
+	  # Archives containing C++ object files must be created using
+	  # "CC -xar", where "CC" is the Sun C++ compiler.  This is
+	  # necessary to make sure instantiated templates are included
+	  # in the archive.
+	  _LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -xar -o $oldlib $oldobjs'
+	  ;;
+	esac
+	;;
     esac
     ;;
   lynxos*)
@@ -3196,7 +3491,7 @@ case $host_os in
     ;;
   mvs*)
     case $cc_basename in
-      cxx)
+      cxx*)
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
@@ -3222,20 +3517,24 @@ case $host_os in
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
     ;;
   openbsd*)
-    _LT_AC_TAGVAR(hardcode_direct, $1)=yes
-    _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
-    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
-    if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
-      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-retain-symbols-file,$export_symbols -o $lib'
-      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
-      _LT_AC_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
+    if test -f /usr/libexec/ld.so; then
+      _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+      if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-retain-symbols-file,$export_symbols -o $lib'
+	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
+      fi
+      output_verbose_link_cmd='echo'
+    else
+      _LT_AC_TAGVAR(ld_shlibs, $1)=no
     fi
-    output_verbose_link_cmd='echo'
     ;;
   osf3*)
     case $cc_basename in
-      KCC)
+      KCC*)
 	# Kuck and Associates, Inc. (KAI) C++ Compiler
 
 	# KCC will only create a shared library if the output file
@@ -3251,14 +3550,14 @@ case $host_os in
 	_LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -Bstatic -o $oldlib $oldobjs'
 
 	;;
-      RCC)
+      RCC*)
 	# Rational C++ 2.4.1
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      cxx)
+      cxx*)
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $soname `test -n "$verstring" && echo ${wl}-set_version $verstring` -update_registry ${objdir}/so_locations -o $lib'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $soname `test -n "$verstring" && echo ${wl}-set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib'
 
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
 	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -3276,7 +3575,7 @@ case $host_os in
       *)
 	if test "$GXX" = yes && test "$with_gnu_ld" = no; then
 	  _LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
-	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
 
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
 	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -3295,7 +3594,7 @@ case $host_os in
     ;;
   osf4* | osf5*)
     case $cc_basename in
-      KCC)
+      KCC*)
 	# Kuck and Associates, Inc. (KAI) C++ Compiler
 
 	# KCC will only create a shared library if the output file
@@ -3310,17 +3609,17 @@ case $host_os in
 	# the KAI C++ compiler.
 	_LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -o $oldlib $oldobjs'
 	;;
-      RCC)
+      RCC*)
 	# Rational C++ 2.4.1
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      cxx)
+      cxx*)
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations -o $lib'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done~
 	  echo "-hidden">> $lib.exp~
-	  $CC -shared$allow_undefined_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname -Wl,-input -Wl,$lib.exp  `test -n "$verstring" && echo -set_version	$verstring` -update_registry $objdir/so_locations -o $lib~
+	  $CC -shared$allow_undefined_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname -Wl,-input -Wl,$lib.exp  `test -n "$verstring" && echo -set_version	$verstring` -update_registry ${output_objdir}/so_locations -o $lib~
 	  $rm $lib.exp'
 
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-rpath $libdir'
@@ -3339,7 +3638,7 @@ case $host_os in
       *)
 	if test "$GXX" = yes && test "$with_gnu_ld" = no; then
 	  _LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
-	 _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-msym ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+	 _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-msym ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
 
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
 	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -3360,27 +3659,14 @@ case $host_os in
     # FIXME: insert proper C++ library support
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
     ;;
-  sco*)
-    _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
-    case $cc_basename in
-      CC)
-	# FIXME: insert proper C++ library support
-	_LT_AC_TAGVAR(ld_shlibs, $1)=no
-	;;
-      *)
-	# FIXME: insert proper C++ library support
-	_LT_AC_TAGVAR(ld_shlibs, $1)=no
-	;;
-    esac
-    ;;
   sunos4*)
     case $cc_basename in
-      CC)
+      CC*)
 	# Sun C++ 4.x
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      lcc)
+      lcc*)
 	# Lucid
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
@@ -3393,36 +3679,28 @@ case $host_os in
     ;;
   solaris*)
     case $cc_basename in
-      CC)
+      CC*)
 	# Sun C++ 4.2, 5.x and Centerline C++
+        _LT_AC_TAGVAR(archive_cmds_need_lc,$1)=yes
 	_LT_AC_TAGVAR(no_undefined_flag, $1)=' -zdefs'
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -nolib -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag}  -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
-	$CC -G${allow_undefined_flag} -nolib ${wl}-M ${wl}$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm $lib.exp'
+	$CC -G${allow_undefined_flag}  ${wl}-M ${wl}$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm $lib.exp'
 
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
 	_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
 	case $host_os in
-	  solaris2.[0-5] | solaris2.[0-5].*) ;;
+	  solaris2.[[0-5]] | solaris2.[[0-5]].*) ;;
 	  *)
-	    # The C++ compiler is used as linker so we must use $wl
-	    # flag to pass the commands to the underlying system
-	    # linker.
+	    # The compiler driver will combine and reorder linker options,
+	    # but understands `-z linker_flag'.
 	    # Supported since Solaris 2.6 (maybe 2.5.1?)
-	    _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract$convenience ${wl}-z ${wl}defaultextract'
+	    _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='-z allextract$convenience -z defaultextract'
 	    ;;
 	esac
 	_LT_AC_TAGVAR(link_all_deplibs, $1)=yes
 
-	# Commands to make compiler produce verbose output that lists
-	# what "hidden" libraries, object files and flags are used when
-	# linking a shared library.
-	#
-	# There doesn't appear to be a way to prevent this compiler from
-	# explicitly linking system object files so we need to strip them
-	# from the output so that they don't get included in the library
-	# dependencies.
-	output_verbose_link_cmd='templist=`$CC -G $CFLAGS -v conftest.$objext 2>&1 | grep "\-[[LR]]"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
+	output_verbose_link_cmd='echo'
 
 	# Archives containing C++ object files must be created using
 	# "CC -xar", where "CC" is the Sun C++ compiler.  This is
@@ -3430,7 +3708,7 @@ case $host_os in
 	# in the archive.
 	_LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -xar -o $oldlib $oldobjs'
 	;;
-      gcx)
+      gcx*)
 	# Green Hills C++ Compiler
 	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-h $wl$soname -o $lib'
 
@@ -3464,16 +3742,73 @@ case $host_os in
 	  fi
 
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $wl$libdir'
+	  case $host_os in
+	  solaris2.[[0-5]] | solaris2.[[0-5]].*) ;;
+	  *)
+	    _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract$convenience ${wl}-z ${wl}defaultextract'
+	    ;;
+	  esac
 	fi
 	;;
     esac
     ;;
-  sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7*)
+  sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* | sco3.2v5.0.[[024]]*)
+    _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+    _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+    _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+    runpath_var='LD_RUN_PATH'
+
+    case $cc_basename in
+      CC*)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	;;
+      *)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	;;
+    esac
+    ;;
+  sysv5* | sco3.2v5* | sco5v6*)
+    # Note: We can NOT use -z defs as we might desire, because we do not
+    # link with -lc, and that would cause any symbols used from libc to
+    # always be unresolved, which means just about no library would
+    # ever link correctly.  If we're not using GNU ld we use -z text
+    # though, which does catch some bad symbols but isn't as heavy-handed
+    # as -z defs.
+    # For security reasons, it is highly recommended that you always
+    # use absolute paths for naming shared libraries, and exclude the
+    # DT_RUNPATH tag from executables and libraries.  But doing so
+    # requires that you compile everything twice, which is a pain.
+    # So that behaviour is only enabled if SCOABSPATH is set to a
+    # non-empty value in the environment.  Most likely only useful for
+    # creating official distributions of packages.
+    # This is a hack until libtool officially supports absolute path
+    # names for shared libraries.
+    _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+    _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-z,nodefs'
     _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+    _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+    _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=':'
+    _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
+    _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
+    runpath_var='LD_RUN_PATH'
+
+    case $cc_basename in
+      CC*)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	;;
+      *)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	;;
+    esac
     ;;
   tandem*)
     case $cc_basename in
-      NCC)
+      NCC*)
 	# NonStop-UX NCC 3.20
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
@@ -3510,8 +3845,6 @@ AC_LIBTOOL_SYS_HARD_LINK_LOCKS($1)
 AC_LIBTOOL_PROG_LD_SHLIBS($1)
 AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
 AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
-AC_LIBTOOL_SYS_LIB_STRIP
-AC_LIBTOOL_DLOPEN_SELF($1)
 
 AC_LIBTOOL_CONFIG($1)
 
@@ -3529,12 +3862,13 @@ lt_cv_prog_gnu_ld=$lt_save_with_gnu_ld
 ])# AC_LIBTOOL_LANG_CXX_CONFIG
 
 # AC_LIBTOOL_POSTDEP_PREDEP([TAGNAME])
-# ------------------------
+# ------------------------------------
 # Figure out "hidden" library dependencies from verbose
 # compiler output when linking a shared library.
 # Parse the compiler output and extract the necessary
 # objects, libraries and library flags.
-AC_DEFUN([AC_LIBTOOL_POSTDEP_PREDEP],[
+AC_DEFUN([AC_LIBTOOL_POSTDEP_PREDEP],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
 dnl we can't use the lt_simple_compile_test_code here,
 dnl because it contains code intended for an executable,
 dnl not a library.  It's possible we should let each
@@ -3583,7 +3917,7 @@ if AC_TRY_EVAL(ac_compile); then
   # The `*' in the case matches for architectures that use `case' in
   # $output_verbose_cmd can trigger glob expansion during the loop
   # eval without this substitution.
-  output_verbose_link_cmd="`$echo \"X$output_verbose_link_cmd\" | $Xsed -e \"$no_glob_subst\"`"
+  output_verbose_link_cmd=`$echo "X$output_verbose_link_cmd" | $Xsed -e "$no_glob_subst"`
 
   for p in `eval $output_verbose_link_cmd`; do
     case $p in
@@ -3659,13 +3993,74 @@ fi
 
 $rm -f confest.$objext
 
+_LT_AC_TAGVAR(compiler_lib_search_dirs, $1)=
+if test -n "$_LT_AC_TAGVAR(compiler_lib_search_path, $1)"; then
+  _LT_AC_TAGVAR(compiler_lib_search_dirs, $1)=`echo " ${_LT_AC_TAGVAR(compiler_lib_search_path, $1)}" | ${SED} -e 's! -L! !g' -e 's!^ !!'`
+fi
+
+# PORTME: override above test on systems where it is broken
+ifelse([$1],[CXX],
+[case $host_os in
+interix[[3-9]]*)
+  # Interix 3.5 installs completely hosed .la files for C++, so rather than
+  # hack all around it, let's just trust "g++" to DTRT.
+  _LT_AC_TAGVAR(predep_objects,$1)=
+  _LT_AC_TAGVAR(postdep_objects,$1)=
+  _LT_AC_TAGVAR(postdeps,$1)=
+  ;;
+
+linux*)
+  case `$CC -V 2>&1 | sed 5q` in
+  *Sun\ C*)
+    # Sun C++ 5.9
+    #
+    # The more standards-conforming stlport4 library is
+    # incompatible with the Cstd library. Avoid specifying
+    # it if it's in CXXFLAGS. Ignore libCrun as
+    # -library=stlport4 depends on it.
+    case " $CXX $CXXFLAGS " in
+    *" -library=stlport4 "*)
+      solaris_use_stlport4=yes
+      ;;
+    esac
+    if test "$solaris_use_stlport4" != yes; then
+      _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun'
+    fi
+    ;;
+  esac
+  ;;
+
+solaris*)
+  case $cc_basename in
+  CC*)
+    # The more standards-conforming stlport4 library is
+    # incompatible with the Cstd library. Avoid specifying
+    # it if it's in CXXFLAGS. Ignore libCrun as
+    # -library=stlport4 depends on it.
+    case " $CXX $CXXFLAGS " in
+    *" -library=stlport4 "*)
+      solaris_use_stlport4=yes
+      ;;
+    esac
+
+    # Adding this requires a known-good setup of shared libraries for
+    # Sun compiler versions before 5.6, else PIC objects from an old
+    # archive will be linked into the output, leading to subtle bugs.
+    if test "$solaris_use_stlport4" != yes; then
+      _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun'
+    fi
+    ;;
+  esac
+  ;;
+esac
+])
 case " $_LT_AC_TAGVAR(postdeps, $1) " in
 *" -lc "*) _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no ;;
 esac
 ])# AC_LIBTOOL_POSTDEP_PREDEP
 
 # AC_LIBTOOL_LANG_F77_CONFIG
-# ------------------------
+# --------------------------
 # Ensure that the configuration vars for the C compiler are
 # suitably defined.  Those variables are subsequently used by
 # AC_LIBTOOL_CONFIG to write the compiler configuration to `libtool'.
@@ -3701,20 +4096,31 @@ objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code="      subroutine t\n      return\n      end\n"
+lt_simple_compile_test_code="\
+      subroutine t
+      return
+      end
+"
 
 # Code to be used in simple link tests
-lt_simple_link_test_code="      program t\n      end\n"
+lt_simple_link_test_code="\
+      program t
+      end
+"
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_AC_SYS_COMPILER
 
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
 # Allow CC to be a program name with arguments.
 lt_save_CC="$CC"
 CC=${F77-"f77"}
 compiler=$CC
 _LT_AC_TAGVAR(compiler, $1)=$CC
-cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
+_LT_CC_BASENAME([$compiler])
 
 AC_MSG_CHECKING([if libtool supports shared libraries])
 AC_MSG_RESULT([$can_build_shared])
@@ -3724,7 +4130,7 @@ test "$can_build_shared" = "no" && enable_shared=no
 
 # On AIX, shared libraries and static libraries use the same namespace, and
 # are all built from PIC.
-case "$host_os" in
+case $host_os in
 aix3*)
   test "$enable_shared" = yes && enable_static=no
   if test -n "$RANLIB"; then
@@ -3732,8 +4138,10 @@ aix3*)
     postinstall_cmds='$RANLIB $lib'
   fi
   ;;
-aix4* | aix5*)
-  test "$enable_shared" = yes && enable_static=no
+aix[[4-9]]*)
+  if test "$host_cpu" != ia64 && test "$aix_use_runtimelinking" = no ; then
+    test "$enable_shared" = yes && enable_static=no
+  fi
   ;;
 esac
 AC_MSG_RESULT([$enable_shared])
@@ -3743,8 +4151,6 @@ AC_MSG_CHECKING([whether to build static libraries])
 test "$enable_shared" = yes || enable_static=yes
 AC_MSG_RESULT([$enable_static])
 
-test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = no && can_build_shared=no
-
 _LT_AC_TAGVAR(GCC, $1)="$G77"
 _LT_AC_TAGVAR(LD, $1)="$LD"
 
@@ -3754,8 +4160,6 @@ AC_LIBTOOL_SYS_HARD_LINK_LOCKS($1)
 AC_LIBTOOL_PROG_LD_SHLIBS($1)
 AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
 AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
-AC_LIBTOOL_SYS_LIB_STRIP
-
 
 AC_LIBTOOL_CONFIG($1)
 
@@ -3781,23 +4185,30 @@ objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code="class foo {}\n"
+lt_simple_compile_test_code="class foo {}"
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='public class conftest { public static void main(String[] argv) {}; }\n'
+lt_simple_link_test_code='public class conftest { public static void main(String[[]] argv) {}; }'
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_AC_SYS_COMPILER
 
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
 # Allow CC to be a program name with arguments.
 lt_save_CC="$CC"
 CC=${GCJ-"gcj"}
 compiler=$CC
 _LT_AC_TAGVAR(compiler, $1)=$CC
+_LT_CC_BASENAME([$compiler])
 
 # GCJ did not exist at the time GCC didn't implicitly link libc in.
 _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
 
+_LT_AC_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
+
 ## CAVEAT EMPTOR:
 ## There is no encapsulation within the following macros, do not change
 ## the running order or otherwise move them around unless you know exactly
@@ -3809,8 +4220,6 @@ AC_LIBTOOL_SYS_HARD_LINK_LOCKS($1)
 AC_LIBTOOL_PROG_LD_SHLIBS($1)
 AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
 AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
-AC_LIBTOOL_SYS_LIB_STRIP
-AC_LIBTOOL_DLOPEN_SELF($1)
 
 AC_LIBTOOL_CONFIG($1)
 
@@ -3820,7 +4229,7 @@ CC="$lt_save_CC"
 
 
 # AC_LIBTOOL_LANG_RC_CONFIG
-# --------------------------
+# -------------------------
 # Ensure that the configuration vars for the Windows resource compiler are
 # suitably defined.  Those variables are subsequently used by
 # AC_LIBTOOL_CONFIG to write the compiler configuration to `libtool'.
@@ -3836,7 +4245,7 @@ objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code='sample MENU { MENUITEM "&Soup", 100, CHECKED }\n'
+lt_simple_compile_test_code='sample MENU { MENUITEM "&Soup", 100, CHECKED }'
 
 # Code to be used in simple link tests
 lt_simple_link_test_code="$lt_simple_compile_test_code"
@@ -3844,11 +4253,16 @@ lt_simple_link_test_code="$lt_simple_compile_test_code"
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_AC_SYS_COMPILER
 
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
 # Allow CC to be a program name with arguments.
 lt_save_CC="$CC"
 CC=${RC-"windres"}
 compiler=$CC
 _LT_AC_TAGVAR(compiler, $1)=$CC
+_LT_CC_BASENAME([$compiler])
 _LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)=yes
 
 AC_LIBTOOL_CONFIG($1)
@@ -3878,7 +4292,7 @@ if test -f "$ltmain"; then
   # Now quote all the things that may contain metacharacters while being
   # careful not to overquote the AC_SUBSTed values.  We take copies of the
   # variables and quote the copies for generation of the libtool script.
-  for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC NM \
+  for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC LTCFLAGS NM \
     SED SHELL STRIP \
     libname_spec library_names_spec soname_spec extract_expsyms_cmds \
     old_striplib striplib file_magic_cmd finish_cmds finish_eval \
@@ -3905,6 +4319,7 @@ if test -f "$ltmain"; then
     _LT_AC_TAGVAR(predeps, $1) \
     _LT_AC_TAGVAR(postdeps, $1) \
     _LT_AC_TAGVAR(compiler_lib_search_path, $1) \
+    _LT_AC_TAGVAR(compiler_lib_search_dirs, $1) \
     _LT_AC_TAGVAR(archive_cmds, $1) \
     _LT_AC_TAGVAR(archive_expsym_cmds, $1) \
     _LT_AC_TAGVAR(postinstall_cmds, $1) \
@@ -3920,6 +4335,7 @@ if test -f "$ltmain"; then
     _LT_AC_TAGVAR(module_cmds, $1) \
     _LT_AC_TAGVAR(module_expsym_cmds, $1) \
     _LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1) \
+    _LT_AC_TAGVAR(fix_srcfile_path, $1) \
     _LT_AC_TAGVAR(exclude_expsyms, $1) \
     _LT_AC_TAGVAR(include_expsyms, $1); do
 
@@ -3966,7 +4382,7 @@ ifelse([$1], [],
 # Generated automatically by $PROGRAM (GNU $PACKAGE $VERSION$TIMESTAMP)
 # NOTE: Changes made to this file will be lost: look at ltmain.sh.
 #
-# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001
+# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
 # Free Software Foundation, Inc.
 #
 # This file is part of GNU Libtool:
@@ -3984,7 +4400,7 @@ ifelse([$1], [],
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -3995,7 +4411,7 @@ ifelse([$1], [],
 SED=$lt_SED
 
 # Sed that helps us avoid accidentally triggering echo(1) options like -n.
-Xsed="$SED -e s/^X//"
+Xsed="$SED -e 1s/^X//"
 
 # The HP-UX ksh and POSIX shell print the target directory to stdout
 # if CDPATH is set.
@@ -4030,6 +4446,12 @@ fast_install=$enable_fast_install
 # The host system.
 host_alias=$host_alias
 host=$host
+host_os=$host_os
+
+# The build system.
+build_alias=$build_alias
+build=$build
+build_os=$build_os
 
 # An echo program that does not interpret backslashes.
 echo=$lt_echo
@@ -4041,6 +4463,9 @@ AR_FLAGS=$lt_AR_FLAGS
 # A C compiler.
 LTCC=$lt_LTCC
 
+# LTCC compiler flags.
+LTCFLAGS=$lt_LTCFLAGS
+
 # A language-specific compiler.
 CC=$lt_[]_LT_AC_TAGVAR(compiler, $1)
 
@@ -4106,7 +4531,7 @@ max_cmd_len=$lt_cv_sys_max_cmd_len
 # Does compiler simultaneously support -c and -o options?
 compiler_c_o=$lt_[]_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)
 
-# Must we lock files when doing compilation ?
+# Must we lock files when doing compilation?
 need_locks=$lt_need_locks
 
 # Do we need the lib prefix for modules?
@@ -4194,6 +4619,10 @@ predeps=$lt_[]_LT_AC_TAGVAR(predeps, $1)
 # shared library.
 postdeps=$lt_[]_LT_AC_TAGVAR(postdeps, $1)
 
+# The directories searched by this compiler when creating a shared
+# library
+compiler_lib_search_dirs=$lt_[]_LT_AC_TAGVAR(compiler_lib_search_dirs, $1)
+
 # The library search path used internally by the compiler when linking
 # a shared library.
 compiler_lib_search_path=$lt_[]_LT_AC_TAGVAR(compiler_lib_search_path, $1)
@@ -4282,7 +4711,7 @@ sys_lib_search_path_spec=$lt_sys_lib_search_path_spec
 sys_lib_dlsearch_path_spec=$lt_sys_lib_dlsearch_path_spec
 
 # Fix the shell variable \$srcfile for the compiler.
-fix_srcfile_path="$_LT_AC_TAGVAR(fix_srcfile_path, $1)"
+fix_srcfile_path=$lt_fix_srcfile_path
 
 # Set to yes if exported symbols are required.
 always_export_symbols=$_LT_AC_TAGVAR(always_export_symbols, $1)
@@ -4365,6 +4794,7 @@ fi
 # ---------------------------------
 AC_DEFUN([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE],
 [AC_REQUIRE([AC_CANONICAL_HOST])
+AC_REQUIRE([LT_AC_PROG_SED])
 AC_REQUIRE([AC_PROG_NM])
 AC_REQUIRE([AC_OBJEXT])
 # Check for command to grab the raw symbol name followed by C symbol from nm.
@@ -4380,9 +4810,6 @@ symcode='[[BCDEGRST]]'
 # Regexp to match symbols that can be accessed directly from C.
 sympat='\([[_A-Za-z]][[_A-Za-z0-9]]*\)'
 
-# Transform the above into a raw symbol and a C symbol.
-symxfrm='\1 \2\3 \3'
-
 # Transform an extracted symbol line into a proper C declaration
 lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^. .* \(.*\)$/extern int \1;/p'"
 
@@ -4404,7 +4831,7 @@ hpux*) # Its linker distinguishes data from code symbols
   lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
   lt_cv_sys_global_symbol_to_c_name_address="sed -n -e 's/^: \([[^ ]]*\) $/  {\\\"\1\\\", (lt_ptr) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  {\"\2\", (lt_ptr) \&\2},/p'"
   ;;
-linux*)
+linux* | k*bsd*-gnu)
   if test "$host_cpu" = ia64; then
     symcode='[[ABCDGIRSTW]]'
     lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
@@ -4417,9 +4844,18 @@ irix* | nonstopux*)
 osf*)
   symcode='[[BCDEGQRST]]'
   ;;
-solaris* | sysv5*)
+solaris*)
   symcode='[[BDRT]]'
   ;;
+sco3.2v5*)
+  symcode='[[DT]]'
+  ;;
+sysv4.2uw2*)
+  symcode='[[DT]]'
+  ;;
+sysv5* | sco5v6* | unixware* | OpenUNIX*)
+  symcode='[[ABDT]]'
+  ;;
 sysv4)
   symcode='[[DFNSTU]]'
   ;;
@@ -4442,8 +4878,11 @@ esac
 # Try without a prefix undercore, then with it.
 for ac_symprfx in "" "_"; do
 
+  # Transform symcode, sympat, and symprfx into a raw symbol and a C symbol.
+  symxfrm="\\1 $ac_symprfx\\2 \\2"
+
   # Write the raw and C identifiers.
-  lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[ 	]]\($symcode$symcode*\)[[ 	]][[ 	]]*\($ac_symprfx\)$sympat$opt_cr$/$symxfrm/p'"
+  lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[ 	]]\($symcode$symcode*\)[[ 	]][[ 	]]*$ac_symprfx$sympat$opt_cr$/$symxfrm/p'"
 
   # Check to see that the pipe works correctly.
   pipe_works=no
@@ -4533,7 +4972,7 @@ EOF
     echo "$progname: failed program was:" >&AS_MESSAGE_LOG_FD
     cat conftest.$ac_ext >&5
   fi
-  rm -f conftest* conftst*
+  rm -rf conftest* conftst*
 
   # Do not use the global_symbol_pipe unless it works.
   if test "$pipe_works" = yes; then
@@ -4582,13 +5021,16 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       # like `-m68040'.
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 -malways-restore-a4'
       ;;
-    beos* | cygwin* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
+    beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
       # PIC is the default for these OSes.
       ;;
-    mingw* | os2* | pw32*)
+    mingw* | cygwin* | os2* | pw32*)
       # This hack is so that the source file can tell whether it is being
       # built for inclusion in a dll (and should export symbols for example).
-      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'
+      # Although the cygwin gcc ignores -fPIC, still need this for old-style
+      # (--disable-auto-import) libraries
+      m4_if([$1], [GCJ], [],
+	[_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
       ;;
     darwin* | rhapsody*)
       # PIC is the default on this platform
@@ -4599,6 +5041,10 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       # DJGPP does not support shared libraries at all
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
       ;;
+    interix[[3-9]]*)
+      # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+      # Instead, we relocate shared libraries at runtime.
+      ;;
     sysv4*MP*)
       if test -d /usr/nec; then
 	_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=-Kconform_pic
@@ -4607,7 +5053,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
     hpux*)
       # PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
       # not for PA HP-UX.
-      case "$host_cpu" in
+      case $host_cpu in
       hppa*64*|ia64*)
 	;;
       *)
@@ -4621,7 +5067,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
     esac
   else
     case $host_os in
-      aix4* | aix5*)
+      aix[[4-9]]*)
 	# All AIX code is PIC.
 	if test "$host_cpu" = ia64; then
 	  # AIX 5 now supports IA64 processor
@@ -4632,7 +5078,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       chorus*)
 	case $cc_basename in
-	cxch68)
+	cxch68*)
 	  # Green Hills C++ Compiler
 	  # _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="--no_auto_instantiation -u __main -u __premain -u _abort -r $COOL_DIR/lib/libOrb.a $MVME_DIR/lib/CC/libC.a $MVME_DIR/lib/classix/libcx.s.a"
 	  ;;
@@ -4641,7 +5087,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
        darwin*)
          # PIC is the default on this platform
          # Common symbols not allowed in MH_DYLIB files
-         case "$cc_basename" in
+         case $cc_basename in
            xlc*)
            _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-qnocommon'
            _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
@@ -4650,10 +5096,10 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
        ;;
       dgux*)
 	case $cc_basename in
-	  ec++)
+	  ec++*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	    ;;
-	  ghcx)
+	  ghcx*)
 	    # Green Hills C++ Compiler
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
 	    ;;
@@ -4661,22 +5107,22 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    ;;
 	esac
 	;;
-      freebsd* | kfreebsd*-gnu)
+      freebsd* | dragonfly*)
 	# FreeBSD uses GNU C++
 	;;
       hpux9* | hpux10* | hpux11*)
 	case $cc_basename in
-	  CC)
+	  CC*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
-	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
+	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
 	    if test "$host_cpu" != ia64; then
 	      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
 	    fi
 	    ;;
-	  aCC)
+	  aCC*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
-	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
-	    case "$host_cpu" in
+	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
+	    case $host_cpu in
 	    hppa*64*|ia64*)
 	      # +Z the default
 	      ;;
@@ -4689,9 +5135,13 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    ;;
 	esac
 	;;
+      interix*)
+	# This is c89, which is MS Visual C++ (no shared libs)
+	# Anyone wants to do a port?
+	;;
       irix5* | irix6* | nonstopux*)
 	case $cc_basename in
-	  CC)
+	  CC*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
 	    # CC pic flag -KPIC is the default.
@@ -4700,20 +5150,26 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    ;;
 	esac
 	;;
-      linux*)
+      linux* | k*bsd*-gnu)
 	case $cc_basename in
-	  KCC)
+	  KCC*)
 	    # KAI C++ Compiler
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='--backend -Wl,'
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
 	    ;;
-	  icpc)
+	  icpc* | ecpc*)
 	    # Intel C++
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
 	    ;;
-	  cxx)
+	  pgCC* | pgcpp*)
+	    # Portland Group C++ compiler.
+	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
+	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	    ;;
+	  cxx*)
 	    # Compaq C++
 	    # Make sure the PIC flag is empty.  It appears that all Alpha
 	    # Linux and Compaq Tru64 Unix objects are PIC.
@@ -4721,6 +5177,14 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
 	    ;;
 	  *)
+	    case `$CC -V 2>&1 | sed 5q` in
+	    *Sun\ C*)
+	      # Sun C++ 5.9
+	      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+	      _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	      _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
+	      ;;
+	    esac
 	    ;;
 	esac
 	;;
@@ -4730,7 +5194,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       mvs*)
 	case $cc_basename in
-	  cxx)
+	  cxx*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-W c,exportall'
 	    ;;
 	  *)
@@ -4741,14 +5205,14 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       osf3* | osf4* | osf5*)
 	case $cc_basename in
-	  KCC)
+	  KCC*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='--backend -Wl,'
 	    ;;
-	  RCC)
+	  RCC*)
 	    # Rational C++ 2.4.1
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
 	    ;;
-	  cxx)
+	  cxx*)
 	    # Digital/Compaq C++
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	    # Make sure the PIC flag is empty.  It appears that all Alpha
@@ -4762,24 +5226,15 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       psos*)
 	;;
-      sco*)
-	case $cc_basename in
-	  CC)
-	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
-	    ;;
-	  *)
-	    ;;
-	esac
-	;;
       solaris*)
 	case $cc_basename in
-	  CC)
+	  CC*)
 	    # Sun C++ 4.2, 5.x and Centerline C++
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
 	    ;;
-	  gcx)
+	  gcx*)
 	    # Green Hills C++ Compiler
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-PIC'
 	    ;;
@@ -4789,12 +5244,12 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       sunos4*)
 	case $cc_basename in
-	  CC)
+	  CC*)
 	    # Sun C++ 4.x
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
 	    ;;
-	  lcc)
+	  lcc*)
 	    # Lucid
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
 	    ;;
@@ -4804,7 +5259,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       tandem*)
 	case $cc_basename in
-	  NCC)
+	  NCC*)
 	    # NonStop-UX NCC 3.20
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	    ;;
@@ -4812,7 +5267,14 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    ;;
 	esac
 	;;
-      unixware*)
+      sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+	case $cc_basename in
+	  CC*)
+	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	    ;;
+	esac
 	;;
       vxworks*)
 	;;
@@ -4843,14 +5305,17 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 -malways-restore-a4'
       ;;
 
-    beos* | cygwin* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
+    beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
       # PIC is the default for these OSes.
       ;;
 
-    mingw* | pw32* | os2*)
+    mingw* | cygwin* | pw32* | os2*)
       # This hack is so that the source file can tell whether it is being
       # built for inclusion in a dll (and should export symbols for example).
-      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'
+      # Although the cygwin gcc ignores -fPIC, still need this for old-style
+      # (--disable-auto-import) libraries
+      m4_if([$1], [GCJ], [],
+	[_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
       ;;
 
     darwin* | rhapsody*)
@@ -4859,6 +5324,11 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fno-common'
       ;;
 
+    interix[[3-9]]*)
+      # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+      # Instead, we relocate shared libraries at runtime.
+      ;;
+
     msdosdjgpp*)
       # Just because we use GCC doesn't mean we suddenly get shared libraries
       # on systems that don't support them.
@@ -4875,7 +5345,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
     hpux*)
       # PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
       # not for PA HP-UX.
-      case "$host_cpu" in
+      case $host_cpu in
       hppa*64*|ia64*)
 	# +Z the default
 	;;
@@ -4904,7 +5374,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       darwin*)
         # PIC is the default on this platform
         # Common symbols not allowed in MH_DYLIB files
-       case "$cc_basename" in
+       case $cc_basename in
          xlc*)
          _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-qnocommon'
          _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
@@ -4912,17 +5382,18 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
        esac
        ;;
 
-    mingw* | pw32* | os2*)
+    mingw* | cygwin* | pw32* | os2*)
       # This hack is so that the source file can tell whether it is being
       # built for inclusion in a dll (and should export symbols for example).
-      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'
+      m4_if([$1], [GCJ], [],
+	[_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
       ;;
 
     hpux9* | hpux10* | hpux11*)
       _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
       # PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
       # not for PA HP-UX.
-      case "$host_cpu" in
+      case $host_cpu in
       hppa*64*|ia64*)
 	# +Z the default
 	;;
@@ -4945,18 +5416,41 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
       ;;
 
-    linux*)
-      case $CC in
+    linux* | k*bsd*-gnu)
+      case $cc_basename in
       icc* | ecc*)
 	_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
         ;;
+      pgcc* | pgf77* | pgf90* | pgf95*)
+        # Portland Group compilers (*not* the Pentium gcc compiler,
+	# which looks to be a dead project)
+	_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+	_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
+	_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+        ;;
       ccc*)
         _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
         # All Alpha code is PIC.
         _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
         ;;
+      *)
+        case `$CC -V 2>&1 | sed 5q` in
+	*Sun\ C*)
+	  # Sun C 5.9
+	  _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+	  _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	  _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+	  ;;
+	*Sun\ F*)
+	  # Sun Fortran 8.3 passes all unrecognized flags to the linker
+	  _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+	  _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	  _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)=''
+	  ;;
+	esac
+	;;
       esac
       ;;
 
@@ -4966,15 +5460,19 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
       ;;
 
-    sco3.2v5*)
-      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-Kpic'
-      _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-dn'
+    rdos*)
+      _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
       ;;
 
     solaris*)
-      _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+      case $cc_basename in
+      f77* | f90* | f95*)
+	_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld ';;
+      *)
+	_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,';;
+      esac
       ;;
 
     sunos4*)
@@ -4983,7 +5481,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
       ;;
 
-    sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+    sysv4 | sysv4.2uw2* | sysv4.3*)
       _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -4996,6 +5494,17 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       fi
       ;;
 
+    sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+      _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+      _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+      ;;
+
+    unicos*)
+      _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+      _LT_AC_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
+      ;;
+
     uts4*)
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -5014,7 +5523,7 @@ AC_MSG_RESULT([$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)])
 #
 if test -n "$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)"; then
   AC_LIBTOOL_COMPILER_OPTION([if $compiler PIC flag $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) works],
-    _LT_AC_TAGVAR(lt_prog_compiler_pic_works, $1),
+    _LT_AC_TAGVAR(lt_cv_prog_compiler_pic_works, $1),
     [$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)ifelse([$1],[],[ -DPIC],[ifelse([$1],[CXX],[ -DPIC],[])])], [],
     [case $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) in
      "" | " "*) ;;
@@ -5023,7 +5532,7 @@ if test -n "$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)"; then
     [_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
      _LT_AC_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no])
 fi
-case "$host_os" in
+case $host_os in
   # For platforms which do not support PIC, -DPIC is meaningless:
   *djgpp*)
     _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
@@ -5032,6 +5541,16 @@ case "$host_os" in
     _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)ifelse([$1],[],[ -DPIC],[ifelse([$1],[CXX],[ -DPIC],[])])"
     ;;
 esac
+
+#
+# Check to make sure the static flag actually works.
+#
+wl=$_LT_AC_TAGVAR(lt_prog_compiler_wl, $1) eval lt_tmp_static_flag=\"$_LT_AC_TAGVAR(lt_prog_compiler_static, $1)\"
+AC_LIBTOOL_LINKER_OPTION([if $compiler static flag $lt_tmp_static_flag works],
+  _LT_AC_TAGVAR(lt_cv_prog_compiler_static_works, $1),
+  $lt_tmp_static_flag,
+  [],
+  [_LT_AC_TAGVAR(lt_prog_compiler_static, $1)=])
 ])
 
 
@@ -5039,11 +5558,12 @@ esac
 # ------------------------------------
 # See if the linker supports building shared libraries.
 AC_DEFUN([AC_LIBTOOL_PROG_LD_SHLIBS],
-[AC_MSG_CHECKING([whether the $compiler linker ($LD) supports shared libraries])
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_MSG_CHECKING([whether the $compiler linker ($LD) supports shared libraries])
 ifelse([$1],[CXX],[
   _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
   case $host_os in
-  aix4* | aix5*)
+  aix[[4-9]]*)
     # If we're using GNU nm, then we don't want the "-C" option.
     # -C means demangle to AIX nm, but means don't demangle with GNU nm
     if $NM -V 2>&1 | grep 'GNU' > /dev/null; then
@@ -5056,12 +5576,13 @@ ifelse([$1],[CXX],[
     _LT_AC_TAGVAR(export_symbols_cmds, $1)="$ltdll_cmds"
   ;;
   cygwin* | mingw*)
-    _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGS]] /s/.* \([[^ ]]*\)/\1 DATA/'\'' | $SED -e '\''/^[[AITW]] /s/.* //'\'' | sort | uniq > $export_symbols'
+    _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1 DATA/;/^.*[[ ]]__nm__/s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[ ]]/d;/^[[AITW]][[ ]]/s/.*[[ ]]//'\'' | sort | uniq > $export_symbols'
   ;;
   *)
     _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
   ;;
   esac
+  _LT_AC_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
 ],[
   runpath_var=
   _LT_AC_TAGVAR(allow_undefined_flag, $1)=
@@ -5092,14 +5613,17 @@ ifelse([$1],[CXX],[
   # it will be wrapped by ` (' and `)$', so one must not match beginning or
   # end of line.  Example: `a|bc|.*d.*' will exclude the symbols `a' and `bc',
   # as well as any symbol that contains `d'.
-  _LT_AC_TAGVAR(exclude_expsyms, $1)="_GLOBAL_OFFSET_TABLE_"
+  _LT_AC_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
   # Although _GLOBAL_OFFSET_TABLE_ is a valid symbol C name, most a.out
   # platforms (ab)use it in PIC code, but their linkers get confused if
   # the symbol is explicitly referenced.  Since portable code cannot
   # rely on this symbol name, it's probably fine to never include it in
   # preloaded symbol tables.
+  # Exclude shared library initialization/finalization symbols.
+dnl Note also adjust exclude_expsyms for C++ above.
   extract_expsyms_cmds=
-
+  # Just being paranoid about ensuring that cc_basename is set.
+  _LT_CC_BASENAME([$compiler])
   case $host_os in
   cygwin* | mingw* | pw32*)
     # FIXME: the MSVC++ port hasn't been tested in a loooong time
@@ -5109,6 +5633,10 @@ ifelse([$1],[CXX],[
       with_gnu_ld=no
     fi
     ;;
+  interix*)
+    # we just hope/assume this is gcc and not c89 (= MSVC++)
+    with_gnu_ld=yes
+    ;;
   openbsd*)
     with_gnu_ld=no
     ;;
@@ -5119,9 +5647,30 @@ ifelse([$1],[CXX],[
     # If archive_cmds runs LD, not CC, wlarc should be empty
     wlarc='${wl}'
 
+    # Set some defaults for GNU ld with shared library support. These
+    # are reset later if shared libraries are not supported. Putting them
+    # here allows them to be overridden if necessary.
+    runpath_var=LD_RUN_PATH
+    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'
+    _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
+    # ancient GNU ld didn't support --whole-archive et. al.
+    if $LD --help 2>&1 | grep 'no-whole-archive' > /dev/null; then
+	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
+      else
+  	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
+    fi
+    supports_anon_versioning=no
+    case `$LD -v 2>/dev/null` in
+      *\ [[01]].* | *\ 2.[[0-9]].* | *\ 2.10.*) ;; # catch versions < 2.11
+      *\ 2.11.93.0.2\ *) supports_anon_versioning=yes ;; # RH7.3 ...
+      *\ 2.11.92.0.12\ *) supports_anon_versioning=yes ;; # Mandrake 8.2 ...
+      *\ 2.11.*) ;; # other 2.11 versions
+      *) supports_anon_versioning=yes ;;
+    esac
+
     # See if GNU ld supports shared libraries.
     case $host_os in
-    aix3* | aix4* | aix5*)
+    aix[[3-9]]*)
       # On AIX/PPC, the GNU linker is very broken
       if test "$host_cpu" != ia64; then
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
@@ -5169,10 +5718,10 @@ EOF
       _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
       _LT_AC_TAGVAR(always_export_symbols, $1)=no
       _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
-      _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGS]] /s/.* \([[^ ]]*\)/\1 DATA/'\'' | $SED -e '\''/^[[AITW]] /s/.* //'\'' | sort | uniq > $export_symbols'
+      _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1 DATA/'\'' -e '\''/^[[AITW]][[ ]]/s/.*[[ ]]//'\'' | sort | uniq > $export_symbols'
 
       if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
-        _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+        _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
 	# If the export-symbols file already is a .def file (1st line
 	# is EXPORTS), use it as is; otherwise, prepend...
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -5181,9 +5730,64 @@ EOF
 	  echo EXPORTS > $output_objdir/$soname.def;
 	  cat $export_symbols >> $output_objdir/$soname.def;
 	fi~
-	$CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000  ${wl}--out-implib,$lib'
+	$CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
       else
-	ld_shlibs=no
+	_LT_AC_TAGVAR(ld_shlibs, $1)=no
+      fi
+      ;;
+
+    interix[[3-9]]*)
+      _LT_AC_TAGVAR(hardcode_direct, $1)=no
+      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+      # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+      # Instead, shared libraries are loaded at an image base (0x10000000 by
+      # default) and relocated if they conflict, which is a slow very memory
+      # consuming and fragmenting process.  To avoid this, we pick a random,
+      # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+      # time.  Moving up from 0x10000000 also allows more sbrk(2) space.
+      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+      ;;
+
+    gnu* | linux* | k*bsd*-gnu)
+      if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+	tmp_addflag=
+	case $cc_basename,$host_cpu in
+	pgcc*)				# Portland Group C compiler
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+	  tmp_addflag=' $pic_flag'
+	  ;;
+	pgf77* | pgf90* | pgf95*)	# Portland Group f77 and f90 compilers
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+	  tmp_addflag=' $pic_flag -Mnomain' ;;
+	ecc*,ia64* | icc*,ia64*)		# Intel C compiler on ia64
+	  tmp_addflag=' -i_dynamic' ;;
+	efc*,ia64* | ifort*,ia64*)	# Intel Fortran compiler on ia64
+	  tmp_addflag=' -i_dynamic -nofor_main' ;;
+	ifc* | ifort*)			# Intel Fortran compiler
+	  tmp_addflag=' -nofor_main' ;;
+	esac
+	case `$CC -V 2>&1 | sed 5q` in
+	*Sun\ C*)			# Sun C 5.9
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\"\"; do test -z \"$conv\" || new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+	  tmp_sharedflag='-G' ;;
+	*Sun\ F*)			# Sun Fortran 8.3
+	  tmp_sharedflag='-G' ;;
+	*)
+	  tmp_sharedflag='-shared' ;;
+	esac
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
+
+	if test $supports_anon_versioning = yes; then
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $output_objdir/$libname.ver~
+  cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
+  $echo "local: *; };" >> $output_objdir/$libname.ver~
+	  $CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver -o $lib'
+	fi
+      else
+	_LT_AC_TAGVAR(ld_shlibs, $1)=no
       fi
       ;;
 
@@ -5197,7 +5801,7 @@ EOF
       fi
       ;;
 
-    solaris* | sysv5*)
+    solaris*)
       if $LD -v 2>&1 | grep 'BFD 2\.8' > /dev/null; then
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	cat <&2
@@ -5218,6 +5822,33 @@ EOF
       fi
       ;;
 
+    sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX*)
+      case `$LD -v 2>&1` in
+        *\ [[01]].* | *\ 2.[[0-9]].* | *\ 2.1[[0-5]].*)
+	_LT_AC_TAGVAR(ld_shlibs, $1)=no
+	cat <<_LT_EOF 1>&2
+
+*** Warning: Releases of the GNU linker prior to 2.16.91.0.3 can not
+*** reliably create shared libraries on SCO systems.  Therefore, libtool
+*** is disabling shared libraries support.  We urge you to upgrade GNU
+*** binutils to release 2.16.91.0.3 or newer.  Another option is to modify
+*** your PATH or compiler configuration so that the native linker is
+*** used, and then restart.
+
+_LT_EOF
+	;;
+	*)
+	  if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+	    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`test -z "$SCOABSPATH" && echo ${wl}-rpath,$libdir`'
+	    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib'
+	    _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname,-retain-symbols-file,$export_symbols -o $lib'
+	  else
+	    _LT_AC_TAGVAR(ld_shlibs, $1)=no
+	  fi
+	;;
+      esac
+      ;;
+
     sunos4*)
       _LT_AC_TAGVAR(archive_cmds, $1)='$LD -assert pure-text -Bshareable -o $lib $libobjs $deplibs $linker_flags'
       wlarc=
@@ -5225,31 +5856,6 @@ EOF
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
       ;;
 
-  linux*)
-    if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
-        tmp_archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
-	_LT_AC_TAGVAR(archive_cmds, $1)="$tmp_archive_cmds"
-      supports_anon_versioning=no
-      case `$LD -v 2>/dev/null` in
-        *\ [01].* | *\ 2.[[0-9]].* | *\ 2.10.*) ;; # catch versions < 2.11
-        *\ 2.11.93.0.2\ *) supports_anon_versioning=yes ;; # RH7.3 ...
-        *\ 2.11.92.0.12\ *) supports_anon_versioning=yes ;; # Mandrake 8.2 ...
-        *\ 2.11.*) ;; # other 2.11 versions
-        *) supports_anon_versioning=yes ;;
-      esac
-      if test $supports_anon_versioning = yes; then
-        _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $output_objdir/$libname.ver~
-cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
-$echo "local: *; };" >> $output_objdir/$libname.ver~
-        $CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver -o $lib'
-      else
-        _LT_AC_TAGVAR(archive_expsym_cmds, $1)="$tmp_archive_cmds"
-      fi
-    else
-      _LT_AC_TAGVAR(ld_shlibs, $1)=no
-    fi
-    ;;
-
     *)
       if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
 	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
@@ -5260,16 +5866,11 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       ;;
     esac
 
-    if test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = yes; then
-      runpath_var=LD_RUN_PATH
-      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'
-      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
-      # ancient GNU ld didn't support --whole-archive et. al.
-      if $LD --help 2>&1 | grep 'no-whole-archive' > /dev/null; then
- 	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
-      else
-  	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
-      fi
+    if test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = no; then
+      runpath_var=
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
+      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
+      _LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
     fi
   else
     # PORTME fill in a description of your system's linker (not GNU ld)
@@ -5281,14 +5882,14 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       # Note: this linker hardcodes the directories in LIBPATH if there
       # are no directories specified by -L.
       _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
-      if test "$GCC" = yes && test -z "$link_static_flag"; then
+      if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
 	# Neither direct hardcoding nor static linking is supported with a
 	# broken collect2.
 	_LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
       fi
       ;;
 
-    aix4* | aix5*)
+    aix[[4-9]]*)
       if test "$host_cpu" = ia64; then
 	# On IA64, the linker does run time linking by default, so we don't
 	# have to do anything special.
@@ -5308,13 +5909,14 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
 	# Test if we are trying to use run time linking or normal
 	# AIX style linking. If -brtl is somewhere in LDFLAGS, we
 	# need to do runtime linking.
-	case $host_os in aix4.[[23]]|aix4.[[23]].*|aix5*)
+	case $host_os in aix4.[[23]]|aix4.[[23]].*|aix[[5-9]]*)
 	  for ld_flag in $LDFLAGS; do
   	  if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl"); then
   	    aix_use_runtimelinking=yes
   	    break
   	  fi
 	  done
+	  ;;
 	esac
 
 	exp_sym_flag='-bexport'
@@ -5333,7 +5935,7 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
 
       if test "$GCC" = yes; then
-	case $host_os in aix4.[012]|aix4.[012].*)
+	case $host_os in aix4.[[012]]|aix4.[[012]].*)
 	# We only want to do this on AIX 4.2 and lower, the check
 	# below for broken collect2 doesn't work under 4.3+
 	  collect2name=`${CC} -print-prog-name=collect2`
@@ -5341,7 +5943,7 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
   	   strings "$collect2name" | grep resolve_lib_name >/dev/null
 	  then
   	  # We have reworked collect2
-  	  _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+  	  :
 	  else
   	  # We have old collect2
   	  _LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
@@ -5352,8 +5954,12 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
   	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
   	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=
 	  fi
+	  ;;
 	esac
 	shared_flag='-shared'
+	if test "$aix_use_runtimelinking" = yes; then
+	  shared_flag="$shared_flag "'${wl}-G'
+	fi
       else
 	# not using gcc
 	if test "$host_cpu" = ia64; then
@@ -5361,11 +5967,11 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
   	# chokes on -Wl,-G. The following line is correct:
 	  shared_flag='-G'
 	else
-  	if test "$aix_use_runtimelinking" = yes; then
+	  if test "$aix_use_runtimelinking" = yes; then
 	    shared_flag='${wl}-G'
 	  else
 	    shared_flag='${wl}-bM:SRE'
-  	fi
+	  fi
 	fi
       fi
 
@@ -5379,12 +5985,12 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
        # Determine the default libpath from the value encoded in an empty executable.
        _LT_AC_SYS_LIBPATH_AIX
        _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
-	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
        else
 	if test "$host_cpu" = ia64; then
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $libdir:/usr/lib:/lib'
 	  _LT_AC_TAGVAR(allow_undefined_flag, $1)="-z nodefs"
-	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
 	else
 	 # Determine the default libpath from the value encoded in an empty executable.
 	 _LT_AC_SYS_LIBPATH_AIX
@@ -5393,13 +5999,11 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
 	  # -berok will link without error, but may produce a broken library.
 	  _LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
 	  _LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
-	  # -bexpall does not export symbols beginning with underscore (_)
-	  _LT_AC_TAGVAR(always_export_symbols, $1)=yes
 	  # Exported symbols can be pulled into shared objects from archives
-	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
 	  _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
-	  # This is similar to how AIX traditionally builds it's shared libraries.
-	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+	  # This is similar to how AIX traditionally builds its shared libraries.
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
 	fi
       fi
       ;;
@@ -5432,13 +6036,13 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       # The linker will automatically build a .lib file if we build a DLL.
       _LT_AC_TAGVAR(old_archive_From_new_cmds, $1)='true'
       # FIXME: Should let the user specify the lib program.
-      _LT_AC_TAGVAR(old_archive_cmds, $1)='lib /OUT:$oldlib$oldobjs$old_deplibs'
-      fix_srcfile_path='`cygpath -w "$srcfile"`'
+      _LT_AC_TAGVAR(old_archive_cmds, $1)='lib -OUT:$oldlib$oldobjs$old_deplibs'
+      _LT_AC_TAGVAR(fix_srcfile_path, $1)='`cygpath -w "$srcfile"`'
       _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
       ;;
 
     darwin* | rhapsody*)
-      case "$host_os" in
+      case $host_os in
         rhapsody* | darwin1.[[012]])
          _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}suppress'
          ;;
@@ -5465,19 +6069,18 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
     if test "$GCC" = yes ; then
     	output_verbose_link_cmd='echo'
-        _LT_AC_TAGVAR(archive_cmds, $1)='$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
-      _LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
-      # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
-      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
-      _LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag  -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
+        _LT_AC_TAGVAR(archive_cmds, $1)="\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring $_lt_dar_single_mod${_lt_dsymutil}"
+        _LT_AC_TAGVAR(module_cmds, $1)="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dsymutil}"
+        _LT_AC_TAGVAR(archive_expsym_cmds, $1)="sed 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring ${_lt_dar_single_mod}${_lt_dar_export_syms}${_lt_dsymutil}"
+        _LT_AC_TAGVAR(module_expsym_cmds, $1)="sed -e 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dar_export_syms}${_lt_dsymutil}"
     else
-      case "$cc_basename" in
+      case $cc_basename in
         xlc*)
          output_verbose_link_cmd='echo'
-         _LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
+         _LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $xlcverstring'
          _LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
-          # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
-         _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
+          # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
+         _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $xlcverstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
           _LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag  -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
           ;;
        *)
@@ -5517,7 +6120,7 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       ;;
 
     # FreeBSD 3 and greater uses gcc -shared to do shared libraries.
-    freebsd* | kfreebsd*-gnu)
+    freebsd* | dragonfly*)
       _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -o $lib $libobjs $deplibs $compiler_flags'
       _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
       _LT_AC_TAGVAR(hardcode_direct, $1)=yes
@@ -5540,47 +6143,62 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
       ;;
 
-    hpux10* | hpux11*)
+    hpux10*)
       if test "$GCC" = yes -a "$with_gnu_ld" = no; then
-	case "$host_cpu" in
-	hppa*64*|ia64*)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+      else
+	_LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+      fi
+      if test "$with_gnu_ld" = no; then
+	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+	_LT_AC_TAGVAR(hardcode_direct, $1)=yes
+	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+
+	# hardcode_minus_L: Not really in the search PATH,
+	# but as the default location of the library.
+	_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
+      fi
+      ;;
+
+    hpux11*)
+      if test "$GCC" = yes -a "$with_gnu_ld" = no; then
+	case $host_cpu in
+	hppa*64*)
 	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
 	  ;;
+	ia64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
+	  ;;
 	*)
 	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
 	  ;;
 	esac
       else
-	case "$host_cpu" in
-	hppa*64*|ia64*)
-	  _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+	case $host_cpu in
+	hppa*64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	  ;;
+	ia64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
 	  ;;
 	*)
-	  _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
 	  ;;
 	esac
       fi
       if test "$with_gnu_ld" = no; then
-	case "$host_cpu" in
-	hppa*64*)
-	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+	case $host_cpu in
+	hppa*64*|ia64*)
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
-	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
 	  _LT_AC_TAGVAR(hardcode_direct, $1)=no
 	  _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
 	  ;;
-	ia64*)
-	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
-	  _LT_AC_TAGVAR(hardcode_direct, $1)=no
-	  _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-
-	  # hardcode_minus_L: Not really in the search PATH,
-	  # but as the default location of the library.
-	  _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
-	  ;;
 	*)
-	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
 	  _LT_AC_TAGVAR(hardcode_direct, $1)=yes
 	  _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
 
@@ -5624,24 +6242,28 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       ;;
 
     openbsd*)
-      _LT_AC_TAGVAR(hardcode_direct, $1)=yes
-      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-      if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
-	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-retain-symbols-file,$export_symbols'
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
-	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+      if test -f /usr/libexec/ld.so; then
+	_LT_AC_TAGVAR(hardcode_direct, $1)=yes
+	_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+	if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-retain-symbols-file,$export_symbols'
+	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+	  _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+	else
+	  case $host_os in
+	   openbsd[[01]].* | openbsd2.[[0-7]] | openbsd2.[[0-7]].*)
+	     _LT_AC_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
+	     _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+	     ;;
+	   *)
+	     _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
+	     _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+	     ;;
+	  esac
+        fi
       else
-       case $host_os in
-	 openbsd[[01]].* | openbsd2.[[0-7]] | openbsd2.[[0-7]].*)
-	   _LT_AC_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
-	   _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
-	   ;;
-	 *)
-	   _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
-	   _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
-	   ;;
-       esac
+	_LT_AC_TAGVAR(ld_shlibs, $1)=no
       fi
       ;;
 
@@ -5674,7 +6296,7 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
 	_LT_AC_TAGVAR(archive_cmds, $1)='$LD -shared${allow_undefined_flag} $libobjs $deplibs $linker_flags -msym -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done; echo "-hidden">> $lib.exp~
-	$LD -shared${allow_undefined_flag} -input $lib.exp $linker_flags $libobjs $deplibs -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations -o $lib~$rm $lib.exp'
+	$LD -shared${allow_undefined_flag} -input $lib.exp $linker_flags $libobjs $deplibs -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib~$rm $lib.exp'
 
 	# Both c and cxx compiler support -rpath directly
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-rpath $libdir'
@@ -5682,21 +6304,15 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
       ;;
 
-    sco3.2v5*)
-      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
-      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
-      runpath_var=LD_RUN_PATH
-      hardcode_runpath_var=yes
-      ;;
-
     solaris*)
       _LT_AC_TAGVAR(no_undefined_flag, $1)=' -z text'
       if test "$GCC" = yes; then
+	wlarc='${wl}'
 	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
 	  $CC -shared ${wl}-M ${wl}$lib.exp ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags~$rm $lib.exp'
       else
+	wlarc=''
 	_LT_AC_TAGVAR(archive_cmds, $1)='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
   	$LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$rm $lib.exp'
@@ -5705,8 +6321,17 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
       case $host_os in
       solaris2.[[0-5]] | solaris2.[[0-5]].*) ;;
-      *) # Supported since Solaris 2.6 (maybe 2.5.1?)
-	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)='-z allextract$convenience -z defaultextract' ;;
+      *)
+	# The compiler driver will combine and reorder linker options,
+	# but understands `-z linker_flag'.  GCC discards it without `$wl',
+	# but is careful enough not to reorder.
+ 	# Supported since Solaris 2.6 (maybe 2.5.1?)
+	if test "$GCC" = yes; then
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract$convenience ${wl}-z ${wl}defaultextract'
+	else
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='-z allextract$convenience -z defaultextract'
+	fi
+	;;
       esac
       _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
       ;;
@@ -5763,36 +6388,45 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       fi
       ;;
 
-    sysv4.2uw2*)
-      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G -o $lib $libobjs $deplibs $linker_flags'
-      _LT_AC_TAGVAR(hardcode_direct, $1)=yes
-      _LT_AC_TAGVAR(hardcode_minus_L, $1)=no
+    sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* | sco3.2v5.0.[[024]]*)
+      _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+      _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-      hardcode_runpath_var=yes
-      runpath_var=LD_RUN_PATH
-      ;;
+      runpath_var='LD_RUN_PATH'
 
-   sysv5OpenUNIX8* | sysv5UnixWare7* |  sysv5uw[[78]]* | unixware7*)
-      _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
       if test "$GCC" = yes; then
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
       else
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
       fi
-      runpath_var='LD_RUN_PATH'
-      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
       ;;
 
-    sysv5*)
-      _LT_AC_TAGVAR(no_undefined_flag, $1)=' -z text'
-      # $CC -shared without GNU ld will not create a library from C++
-      # object files and a static libstdc++, better avoid it by now
-      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
-      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
-  		$LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$rm $lib.exp'
-      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
+    sysv5* | sco3.2v5* | sco5v6*)
+      # Note: We can NOT use -z defs as we might desire, because we do not
+      # link with -lc, and that would cause any symbols used from libc to
+      # always be unresolved, which means just about no library would
+      # ever link correctly.  If we're not using GNU ld we use -z text
+      # though, which does catch some bad symbols but isn't as heavy-handed
+      # as -z defs.
+      _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+      _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-z,nodefs'
+      _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+      _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=':'
+      _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
+      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
       runpath_var='LD_RUN_PATH'
+
+      if test "$GCC" = yes; then
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+      else
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+      fi
       ;;
 
     uts4*)
@@ -5810,11 +6444,6 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
 AC_MSG_RESULT([$_LT_AC_TAGVAR(ld_shlibs, $1)])
 test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = no && can_build_shared=no
 
-variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
-if test "$GCC" = yes; then
-  variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
-fi
-
 #
 # Do we need to explicitly link libc?
 #
@@ -5834,7 +6463,7 @@ x|xyes)
       # to ld, don't add -lc before -lgcc.
       AC_MSG_CHECKING([whether -lc should be explicitly linked in])
       $rm conftest*
-      printf "$lt_simple_compile_test_code" > conftest.$ac_ext
+      echo "$lt_simple_compile_test_code" > conftest.$ac_ext
 
       if AC_TRY_EVAL(ac_compile) 2>conftest.err; then
         soname=conftest
@@ -5842,6 +6471,7 @@ x|xyes)
         libobjs=conftest.$ac_objext
         deplibs=
         wl=$_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)
+	pic_flag=$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)
         compiler_flags=-v
         linker_flags=-v
         verstring=
@@ -5936,6 +6566,30 @@ AC_DEFUN([LT_AC_PROG_RC],
 [AC_CHECK_TOOL(RC, windres, no)
 ])
 
+
+# Cheap backport of AS_EXECUTABLE_P and required macros
+# from Autoconf 2.59; we should not use $as_executable_p directly.
+
+# _AS_TEST_PREPARE
+# ----------------
+m4_ifndef([_AS_TEST_PREPARE],
+[m4_defun([_AS_TEST_PREPARE],
+[if test -x / >/dev/null 2>&1; then
+  as_executable_p='test -x'
+else
+  as_executable_p='test -f'
+fi
+])])# _AS_TEST_PREPARE
+
+# AS_EXECUTABLE_P
+# ---------------
+# Check whether a file is executable.
+m4_ifndef([AS_EXECUTABLE_P],
+[m4_defun([AS_EXECUTABLE_P],
+[AS_REQUIRE([_AS_TEST_PREPARE])dnl
+$as_executable_p $1[]dnl
+])])# AS_EXECUTABLE_P
+
 ############################################################
 # NOTE: This macro has been submitted for inclusion into   #
 #  GNU Autoconf as AC_PROG_SED.  When it is available in   #
@@ -5958,18 +6612,19 @@ do
   test -z "$as_dir" && as_dir=.
   for lt_ac_prog in sed gsed; do
     for ac_exec_ext in '' $ac_executable_extensions; do
-      if $as_executable_p "$as_dir/$lt_ac_prog$ac_exec_ext"; then
+      if AS_EXECUTABLE_P(["$as_dir/$lt_ac_prog$ac_exec_ext"]); then
         lt_ac_sed_list="$lt_ac_sed_list $as_dir/$lt_ac_prog$ac_exec_ext"
       fi
     done
   done
 done
+IFS=$as_save_IFS
 lt_ac_max=0
 lt_ac_count=0
 # Add /usr/xpg4/bin/sed as it is typically found on Solaris
 # along with /bin/sed that truncates output.
 for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do
-  test ! -f $lt_ac_sed && break
+  test ! -f $lt_ac_sed && continue
   cat /dev/null > conftest.in
   lt_ac_count=0
   echo $ECHO_N "0123456789$ECHO_C" >conftest.in
@@ -5996,5 +6651,6 @@ for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do
 done
 ])
 SED=$lt_cv_path_SED
+AC_SUBST([SED])
 AC_MSG_RESULT([$SED])
 ])
diff --git a/ltmain.sh b/ltmain.sh
index e032aff9675d..ce02bc6ffaa2 100644
--- a/ltmain.sh
+++ b/ltmain.sh
@@ -1,8 +1,8 @@
 # ltmain.sh - Provide generalized library-building support services.
 # NOTE: Changing this file will not affect anything until you rerun configure.
 #
-# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004
-# Free Software Foundation, Inc.
+# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006,
+# 2007, 2008  Free Software Foundation, Inc.
 # Originally by Gordon Matzigkeit , 1996
 #
 # This program is free software; you can redistribute it and/or modify
@@ -17,7 +17,7 @@
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -43,14 +43,22 @@ EXIT_FAILURE=1
 
 PROGRAM=ltmain.sh
 PACKAGE=libtool
-VERSION=1.5.10
-TIMESTAMP=" (1.1220.2.131 2004/09/19 12:46:56)"
-
-# See if we are running on zsh, and set the options which allow our
-# commands through without removal of \ escapes.
-if test -n "${ZSH_VERSION+set}" ; then
+VERSION=1.5.26
+TIMESTAMP=" (1.1220.2.492 2008/01/30 06:40:56)"
+
+# Be Bourne compatible (taken from Autoconf:_AS_BOURNE_COMPATIBLE).
+if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
+  emulate sh
+  NULLCMD=:
+  # Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
+  # is contrary to our usage.  Disable this feature.
+  alias -g '${1+"$@"}'='"$@"'
   setopt NO_GLOB_SUBST
+else
+  case `(set -o) 2>/dev/null` in *posix*) set -o posix;; esac
 fi
+BIN_SH=xpg4; export BIN_SH # for Tru64
+DUALCASE=1; export DUALCASE # for MKS sh
 
 # Check that we have a working $echo.
 if test "X$1" = X--no-reexec; then
@@ -88,14 +96,15 @@ rm="rm -f"
 Xsed="${SED}"' -e 1s/^X//'
 sed_quote_subst='s/\([\\`\\"$\\\\]\)/\\\1/g'
 # test EBCDIC or ASCII
-case `echo A|tr A '\301'` in
- A) # EBCDIC based system
-  SP2NL="tr '\100' '\n'"
-  NL2SP="tr '\r\n' '\100\100'"
+case `echo X|tr X '\101'` in
+ A) # ASCII based system
+    # \n is not interpreted correctly by Solaris 8 /usr/ucb/tr
+  SP2NL='tr \040 \012'
+  NL2SP='tr \015\012 \040\040'
   ;;
- *) # Assume ASCII based system
-  SP2NL="tr '\040' '\012'"
-  NL2SP="tr '\015\012' '\040\040'"
+ *) # EBCDIC based system
+  SP2NL='tr \100 \n'
+  NL2SP='tr \r\n \100\100'
   ;;
 esac
 
@@ -104,16 +113,25 @@ esac
 # These must not be set unconditionally because not all systems understand
 # e.g. LANG=C (notably SCO).
 # We save the old values to restore during execute mode.
-if test "${LC_ALL+set}" = set; then
-  save_LC_ALL="$LC_ALL"; LC_ALL=C; export LC_ALL
-fi
-if test "${LANG+set}" = set; then
-  save_LANG="$LANG"; LANG=C; export LANG
+lt_env=
+for lt_var in LANG LANGUAGE LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES
+do
+  eval "if test \"\${$lt_var+set}\" = set; then
+	  save_$lt_var=\$$lt_var
+	  lt_env=\"$lt_var=\$$lt_var \$lt_env\"
+	  $lt_var=C
+	  export $lt_var
+	fi"
+done
+
+if test -n "$lt_env"; then
+  lt_env="env $lt_env"
 fi
 
 # Make sure IFS has a sensible default
-: ${IFS=" 	
-"}
+lt_nl='
+'
+IFS=" 	$lt_nl"
 
 if test "$build_libtool_libs" != yes && test "$build_old_libs" != yes; then
   $echo "$modename: not configured to build any kind of library" 1>&2
@@ -130,20 +148,62 @@ run=
 show="$echo"
 show_help=
 execute_dlfiles=
+duplicate_deps=no
+preserve_args=
 lo2o="s/\\.lo\$/.${objext}/"
 o2lo="s/\\.${objext}\$/.lo/"
+extracted_archives=
+extracted_serial=0
 
 #####################################
 # Shell function definitions:
 # This seems to be the best place for them
 
+# func_mktempdir [string]
+# Make a temporary directory that won't clash with other running
+# libtool processes, and avoids race conditions if possible.  If
+# given, STRING is the basename for that directory.
+func_mktempdir ()
+{
+    my_template="${TMPDIR-/tmp}/${1-$progname}"
+
+    if test "$run" = ":"; then
+      # Return a directory name, but don't create it in dry-run mode
+      my_tmpdir="${my_template}-$$"
+    else
+
+      # If mktemp works, use that first and foremost
+      my_tmpdir=`mktemp -d "${my_template}-XXXXXXXX" 2>/dev/null`
+
+      if test ! -d "$my_tmpdir"; then
+	# Failing that, at least try and use $RANDOM to avoid a race
+	my_tmpdir="${my_template}-${RANDOM-0}$$"
+
+	save_mktempdir_umask=`umask`
+	umask 0077
+	$mkdir "$my_tmpdir"
+	umask $save_mktempdir_umask
+      fi
+
+      # If we're not in dry-run mode, bomb out on failure
+      test -d "$my_tmpdir" || {
+        $echo "cannot create temporary directory \`$my_tmpdir'" 1>&2
+	exit $EXIT_FAILURE
+      }
+    fi
+
+    $echo "X$my_tmpdir" | $Xsed
+}
+
+
 # func_win32_libid arg
 # return the library type of file 'arg'
 #
 # Need a lot of goo to handle *both* DLLs and import libs
 # Has to be a shell function in order to 'eat' the argument
 # that is supplied when $file_magic_command is called.
-func_win32_libid () {
+func_win32_libid ()
+{
   win32_libid_type="unknown"
   win32_fileres=`file -L $1 2>/dev/null`
   case $win32_fileres in
@@ -154,12 +214,17 @@ func_win32_libid () {
     if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev/null | \
       $EGREP -e 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then
       win32_nmres=`eval $NM -f posix -A $1 | \
-	sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;};}'`
-      if test "X$win32_nmres" = "Ximport" ; then
-        win32_libid_type="x86 archive import"
-      else
-        win32_libid_type="x86 archive static"
-      fi
+	$SED -n -e '1,100{
+		/ I /{
+			s,.*,import,
+			p
+			q
+			}
+		}'`
+      case $win32_nmres in
+      import*)  win32_libid_type="x86 archive import";;
+      *)        win32_libid_type="x86 archive static";;
+      esac
     fi
     ;;
   *DLL*)
@@ -183,7 +248,22 @@ func_win32_libid () {
 # Only attempt this if the compiler in the base compile
 # command doesn't match the default compiler.
 # arg is usually of the form 'gcc ...'
-func_infer_tag () {
+func_infer_tag ()
+{
+    # FreeBSD-specific: where we install compilers with non-standard names
+    tag_compilers_CC="*cc cc* *gcc gcc*"
+    tag_compilers_CXX="*c++ c++* *g++ g++*"
+    base_compiler=`set -- "$@"; echo $1`
+
+    # If $tagname isn't set, then try to infer if the default "CC" tag applies
+    if test -z "$tagname"; then
+      for zp in $tag_compilers_CC; do
+        case $base_compiler in
+	 $zp) tagname="CC"; break;;
+	esac
+      done
+    fi
+
     if test -n "$available_tags" && test -z "$tagname"; then
       CC_quoted=
       for arg in $CC; do
@@ -224,7 +304,22 @@ func_infer_tag () {
 	      break
 	      ;;
 	    esac
-	  fi
+
+	    # FreeBSD-specific: try compilers based on inferred tag
+	    if test -z "$tagname"; then
+	      eval "tag_compilers=\$tag_compilers_${z}"
+	      if test -n "$tag_compilers"; then
+		for zp in $tag_compilers; do
+		  case $base_compiler in   
+		    $zp) tagname=$z; break;;
+		  esac
+		done
+		if test -n "$tagname"; then
+		  break
+		fi
+	      fi
+            fi
+          fi
 	done
 	# If $tagname still isn't set, then no tagged configuration
 	# was found and let the user know that the "--tag" command
@@ -242,8 +337,25 @@ func_infer_tag () {
 }
 
 
+# func_extract_an_archive dir oldlib
+func_extract_an_archive ()
+{
+    f_ex_an_ar_dir="$1"; shift
+    f_ex_an_ar_oldlib="$1"
+
+    $show "(cd $f_ex_an_ar_dir && $AR x $f_ex_an_ar_oldlib)"
+    $run eval "(cd \$f_ex_an_ar_dir && $AR x \$f_ex_an_ar_oldlib)" || exit $?
+    if ($AR t "$f_ex_an_ar_oldlib" | sort | sort -uc >/dev/null 2>&1); then
+     :
+    else
+      $echo "$modename: ERROR: object name conflicts: $f_ex_an_ar_dir/$f_ex_an_ar_oldlib" 1>&2
+      exit $EXIT_FAILURE
+    fi
+}
+
 # func_extract_archives gentop oldlib ...
-func_extract_archives () {
+func_extract_archives ()
+{
     my_gentop="$1"; shift
     my_oldlibs=${1+"$@"}
     my_oldobjs=""
@@ -268,15 +380,25 @@ func_extract_archives () {
 	*) my_xabs=`pwd`"/$my_xlib" ;;
       esac
       my_xlib=`$echo "X$my_xlib" | $Xsed -e 's%^.*/%%'`
-      my_xdir="$my_gentop/$my_xlib"
+      my_xlib_u=$my_xlib
+      while :; do
+        case " $extracted_archives " in
+	*" $my_xlib_u "*)
+	  extracted_serial=`expr $extracted_serial + 1`
+	  my_xlib_u=lt$extracted_serial-$my_xlib ;;
+	*) break ;;
+	esac
+      done
+      extracted_archives="$extracted_archives $my_xlib_u"
+      my_xdir="$my_gentop/$my_xlib_u"
 
       $show "${rm}r $my_xdir"
       $run ${rm}r "$my_xdir"
       $show "$mkdir $my_xdir"
       $run $mkdir "$my_xdir"
-      status=$?
-      if test "$status" -ne 0 && test ! -d "$my_xdir"; then
-	exit $status
+      exit_status=$?
+      if test "$exit_status" -ne 0 && test ! -d "$my_xdir"; then
+	exit $exit_status
       fi
       case $host in
       *-darwin*)
@@ -287,7 +409,7 @@ func_extract_archives () {
 	  cd $my_xdir || exit $?
 	  darwin_archive=$my_xabs
 	  darwin_curdir=`pwd`
-	  darwin_base_archive=`basename $darwin_archive`
+	  darwin_base_archive=`$echo "X$darwin_archive" | $Xsed -e 's%^.*/%%'`
 	  darwin_arches=`lipo -info "$darwin_archive" 2>/dev/null | $EGREP Architectures 2>/dev/null`
 	  if test -n "$darwin_arches"; then 
 	    darwin_arches=`echo "$darwin_arches" | $SED -e 's/.*are://'`
@@ -296,64 +418,33 @@ func_extract_archives () {
 	    for darwin_arch in  $darwin_arches ; do
 	      mkdir -p "unfat-$$/${darwin_base_archive}-${darwin_arch}"
 	      lipo -thin $darwin_arch -output "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}" "${darwin_archive}"
-	      # Remove the table of contents from the thin files.
-	      $AR -d "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}" __.SYMDEF 2>/dev/null || true
-	      $AR -d "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}" __.SYMDEF\ SORTED 2>/dev/null || true
 	      cd "unfat-$$/${darwin_base_archive}-${darwin_arch}"
-	      $AR -xo "${darwin_base_archive}"
-	      rm "${darwin_base_archive}"
+	      func_extract_an_archive "`pwd`" "${darwin_base_archive}"
 	      cd "$darwin_curdir"
+	      $rm "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}"
 	    done # $darwin_arches
       ## Okay now we have a bunch of thin objects, gotta fatten them up :)
-	    darwin_filelist=`find unfat-$$ -type f | xargs basename | sort -u | $NL2SP`
+	    darwin_filelist=`find unfat-$$ -type f -name \*.o -print -o -name \*.lo -print| xargs basename | sort -u | $NL2SP`
 	    darwin_file=
 	    darwin_files=
 	    for darwin_file in $darwin_filelist; do
 	      darwin_files=`find unfat-$$ -name $darwin_file -print | $NL2SP`
 	      lipo -create -output "$darwin_file" $darwin_files
 	    done # $darwin_filelist
-	    rm -rf unfat-$$
+	    ${rm}r unfat-$$
 	    cd "$darwin_orig_dir"
 	  else
-	    cd $darwin_orig_dir
-	    (cd $my_xdir && $AR x $my_xabs) || exit $?
+	    cd "$darwin_orig_dir"
+ 	    func_extract_an_archive "$my_xdir" "$my_xabs"
 	  fi # $darwin_arches
 	fi # $run
-      ;;
-      *)
-	# We will extract separately just the conflicting names and we will
-	# no longer touch any unique names. It is faster to leave these
-	# extract automatically by $AR in one run.
-	$show "(cd $my_xdir && $AR x $my_xabs)"
-	$run eval "(cd \$my_xdir && $AR x \$my_xabs)" || exit $?
-	if ($AR t "$my_xabs" | sort | sort -uc >/dev/null 2>&1); then
-	  :
-	else
-	  $echo "$modename: warning: object name conflicts; renaming object files" 1>&2
-	  $echo "$modename: warning: to ensure that they will not overwrite" 1>&2
-	  $AR t "$my_xabs" | sort | uniq -cd | while read -r count name
-	  do
-	    i=1
-	    while test "$i" -le "$count"
-	    do
-	      # Put our $i before any first dot (extension)
-	      # Never overwrite any file
-	      name_to="$name"
-	      while test "X$name_to" = "X$name" || test -f "$my_xdir/$name_to"
-	      do
-		name_to=`$echo "X$name_to" | $Xsed -e "s/\([^.]*\)/\1-$i/"`
-	      done
-	      $show "(cd $my_xdir && $AR xN $i $my_xabs '$name' && $mv '$name' '$name_to')"
-	      $run eval "(cd \$my_xdir && $AR xN $i \$my_xabs '$name' && $mv '$name' '$name_to')" || exit $?
-	      i=`expr $i + 1`
-	    done
-	  done
-	fi
 	;;
+      *)
+        func_extract_an_archive "$my_xdir" "$my_xabs"
+        ;;
       esac
       my_oldobjs="$my_oldobjs "`find $my_xdir -name \*.$objext -print -o -name \*.lo -print | $NL2SP`
     done
-
     func_extract_archives_result="$my_oldobjs"
 }
 # End of Shell function definitions
@@ -362,6 +453,8 @@ func_extract_archives () {
 # Darwin sucks
 eval std_shrext=\"$shrext_cmds\"
 
+disable_libs=no
+
 # Parse our command line options once, thoroughly.
 while test "$#" -gt 0
 do
@@ -424,12 +517,13 @@ do
     ;;
 
   --version)
-    $echo "$PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP"
-    $echo
-    $echo "Copyright (C) 2003  Free Software Foundation, Inc."
-    $echo "This is free software; see the source for copying conditions.  There is NO"
-    $echo "warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
-    exit $EXIT_SUCCESS
+    echo "\
+$PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP
+
+Copyright (C) 2008  Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
+    exit $?
     ;;
 
   --config)
@@ -438,7 +532,7 @@ do
     for tagname in $taglist; do
       ${SED} -n -e "/^# ### BEGIN LIBTOOL TAG CONFIG: $tagname$/,/^# ### END LIBTOOL TAG CONFIG: $tagname$/p" < "$progpath"
     done
-    exit $EXIT_SUCCESS
+    exit $?
     ;;
 
   --debug)
@@ -463,7 +557,7 @@ do
     else
       $echo "disable static libraries"
     fi
-    exit $EXIT_SUCCESS
+    exit $?
     ;;
 
   --finish) mode="finish" ;;
@@ -478,7 +572,11 @@ do
     preserve_args="$preserve_args $arg"
     ;;
 
-  --tag) prevopt="--tag" prev=tag ;;
+  --tag)
+    prevopt="--tag"
+    prev=tag
+    preserve_args="$preserve_args --tag"
+    ;;
   --tag=*)
     set tag "$optarg" ${1+"$@"}
     shift
@@ -510,6 +608,18 @@ if test -n "$prevopt"; then
   exit $EXIT_FAILURE
 fi
 
+case $disable_libs in
+no) 
+  ;;
+shared)
+  build_libtool_libs=no
+  build_old_libs=yes
+  ;;
+static)
+  build_old_libs=`case $build_libtool_libs in yes) echo no;; *) echo yes;; esac`
+  ;;
+esac
+
 # If this variable is set in any of the actions, the command in it
 # will be execed at the end.  This prevents here-documents from being
 # left over by shells.
@@ -520,7 +630,7 @@ if test -z "$show_help"; then
   # Infer the operation mode.
   if test -z "$mode"; then
     $echo "*** Warning: inferring the mode of operation is deprecated." 1>&2
-    $echo "*** Future versions of Libtool will require -mode=MODE be specified." 1>&2
+    $echo "*** Future versions of Libtool will require --mode=MODE be specified." 1>&2
     case $nonopt in
     *cc | cc* | *++ | gcc* | *-gcc* | g++* | xlc*)
       mode=link
@@ -586,7 +696,7 @@ if test -z "$show_help"; then
 
     for arg
     do
-      case "$arg_mode" in
+      case $arg_mode in
       arg  )
 	# do not "continue".  Instead, add this to base_compile
 	lastarg="$arg"
@@ -668,7 +778,10 @@ if test -z "$show_help"; then
       case $lastarg in
       # Double-quote args containing other shell metacharacters.
       # Many Bourne shells cannot handle close brackets correctly
-      # in scan sets, so we specify it separately.
+      # in scan sets, and some SunOS ksh mistreat backslash-escaping
+      # in scan sets (worked around with variable expansion),
+      # and furthermore cannot handle '|' '&' '(' ')' in scan sets 
+      # at all, so we specify them separately.
       *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
 	lastarg="\"$lastarg\""
 	;;
@@ -706,9 +819,11 @@ if test -z "$show_help"; then
     *.class) xform=class ;;
     *.cpp) xform=cpp ;;
     *.cxx) xform=cxx ;;
-    *.f90) xform=f90 ;;
+    *.[fF][09]?) xform=[fF][09]. ;;
     *.for) xform=for ;;
     *.java) xform=java ;;
+    *.obj) xform=obj ;;
+    *.sx) xform=sx ;;
     esac
 
     libobj=`$echo "X$libobj" | $Xsed -e "s/\.$xform$/.lo/"`
@@ -742,6 +857,14 @@ if test -z "$show_help"; then
       esac
     done
 
+    qlibobj=`$echo "X$libobj" | $Xsed -e "$sed_quote_subst"`
+    case $qlibobj in
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
+	qlibobj="\"$qlibobj\"" ;;
+    esac
+    test "X$libobj" != "X$qlibobj" \
+	&& $echo "X$libobj" | grep '[]~#^*{};<>?"'"'"' 	&()|`$[]' \
+	&& $echo "$modename: libobj name \`$libobj' may not contain shell special characters."
     objname=`$echo "X$obj" | $Xsed -e 's%^.*/%%'`
     xdir=`$echo "X$obj" | $Xsed -e 's%/[^/]*$%%'`
     if test "X$xdir" = "X$obj"; then
@@ -814,12 +937,17 @@ compiler."
 	$run $rm $removelist
 	exit $EXIT_FAILURE
       fi
-      $echo $srcfile > "$lockfile"
+      $echo "$srcfile" > "$lockfile"
     fi
 
     if test -n "$fix_srcfile_path"; then
       eval srcfile=\"$fix_srcfile_path\"
     fi
+    qsrcfile=`$echo "X$srcfile" | $Xsed -e "$sed_quote_subst"`
+    case $qsrcfile in
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
+      qsrcfile="\"$qsrcfile\"" ;;
+    esac
 
     $run $rm "$libobj" "${libobj}T"
 
@@ -841,18 +969,18 @@ EOF
       fbsd_hideous_sh_bug=$base_compile
 
       if test "$pic_mode" != no; then
-	command="$base_compile $srcfile $pic_flag"
+	command="$base_compile $qsrcfile $pic_flag"
       else
 	# Don't build PIC code
-	command="$base_compile $srcfile"
+	command="$base_compile $qsrcfile"
       fi
 
       if test ! -d "${xdir}$objdir"; then
 	$show "$mkdir ${xdir}$objdir"
 	$run $mkdir ${xdir}$objdir
-	status=$?
-	if test "$status" -ne 0 && test ! -d "${xdir}$objdir"; then
-	  exit $status
+	exit_status=$?
+	if test "$exit_status" -ne 0 && test ! -d "${xdir}$objdir"; then
+	  exit $exit_status
 	fi
       fi
 
@@ -864,7 +992,7 @@ EOF
       $run $rm "$lobj" "$output_obj"
 
       $show "$command"
-      if $run eval "$command"; then :
+      if $run eval $lt_env "$command"; then :
       else
 	test -n "$output_obj" && $run $rm $removelist
 	exit $EXIT_FAILURE
@@ -924,9 +1052,9 @@ EOF
     if test "$build_old_libs" = yes; then
       if test "$pic_mode" != yes; then
 	# Don't build PIC code
-	command="$base_compile $srcfile"
+	command="$base_compile $qsrcfile"
       else
-	command="$base_compile $srcfile $pic_flag"
+	command="$base_compile $qsrcfile $pic_flag"
       fi
       if test "$compiler_c_o" = yes; then
 	command="$command -o $obj"
@@ -936,7 +1064,7 @@ EOF
       command="$command$suppress_output"
       $run $rm "$obj" "$output_obj"
       $show "$command"
-      if $run eval "$command"; then :
+      if $run eval $lt_env "$command"; then :
       else
 	$run $rm $removelist
 	exit $EXIT_FAILURE
@@ -1055,6 +1183,7 @@ EOF
     no_install=no
     objs=
     non_pic_objects=
+    notinst_path= # paths that contain not-installed libtool libraries
     precious_files_regex=
     prefer_static_libs=no
     preload=no
@@ -1068,6 +1197,7 @@ EOF
     thread_safe=no
     vinfo=
     vinfo_number=no
+    single_module="${wl}-single_module"
 
     func_infer_tag $base_compile
 
@@ -1075,22 +1205,32 @@ EOF
     for arg
     do
       case $arg in
-      -all-static | -static)
-	if test "X$arg" = "X-all-static"; then
+      -all-static | -static | -static-libtool-libs)
+	case $arg in
+	-all-static)
 	  if test "$build_libtool_libs" = yes && test -z "$link_static_flag"; then
 	    $echo "$modename: warning: complete static linking is impossible in this configuration" 1>&2
 	  fi
 	  if test -n "$link_static_flag"; then
 	    dlopen_self=$dlopen_self_static
 	  fi
-	else
+	  prefer_static_libs=yes
+	  ;;
+	-static)
 	  if test -z "$pic_flag" && test -n "$link_static_flag"; then
 	    dlopen_self=$dlopen_self_static
 	  fi
-	fi
+	  prefer_static_libs=built
+	  ;;
+	-static-libtool-libs)
+	  if test -z "$pic_flag" && test -n "$link_static_flag"; then
+	    dlopen_self=$dlopen_self_static
+	  fi
+	  prefer_static_libs=yes
+	  ;;
+	esac
 	build_libtool_libs=no
 	build_old_libs=yes
-	prefer_static_libs=yes
 	break
 	;;
       esac
@@ -1265,6 +1405,11 @@ EOF
 		  if test -z "$pic_object" || test "$pic_object" = none ; then
 		    arg="$non_pic_object"
 		  fi
+		else
+		  # If the PIC object exists, use it instead.
+		  # $xdir was prepended to $pic_object above.
+		  non_pic_object="$pic_object"
+		  non_pic_objects="$non_pic_objects $non_pic_object"
 		fi
 	      else
 		# Only an error if not doing a dry-run.
@@ -1348,6 +1493,13 @@ EOF
 	  prev=
 	  continue
 	  ;;
+	darwin_framework|darwin_framework_skip)
+	  test "$prev" = "darwin_framework" && compiler_flags="$compiler_flags $arg"
+	  compile_command="$compile_command $arg"
+	  finalize_command="$finalize_command $arg"
+	  prev=
+	  continue
+	  ;;
 	*)
 	  eval "$prev=\"\$arg\""
 	  prev=
@@ -1406,6 +1558,18 @@ EOF
 	continue
 	;;
 
+      -framework|-arch|-isysroot)
+	case " $CC " in
+	  *" ${arg} ${1} "* | *" ${arg}	${1} "*) 
+		prev=darwin_framework_skip ;;
+	  *) compiler_flags="$compiler_flags $arg"
+	     prev=darwin_framework ;;
+	esac
+	compile_command="$compile_command $arg"
+	finalize_command="$finalize_command $arg"
+	continue
+	;;
+
       -inst-prefix-dir)
 	prev=inst_prefix
 	continue
@@ -1432,7 +1596,8 @@ EOF
 	  absdir=`cd "$dir" && pwd`
 	  if test -z "$absdir"; then
 	    $echo "$modename: cannot determine absolute directory name of \`$dir'" 1>&2
-	    exit $EXIT_FAILURE
+	    absdir="$dir"
+	    notinst_path="$notinst_path $dir"
 	  fi
 	  dir="$absdir"
 	  ;;
@@ -1446,10 +1611,15 @@ EOF
 	esac
 	case $host in
 	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+	  testbindir=`$echo "X$dir" | $Xsed -e 's*/lib$*/bin*'`
 	  case :$dllsearchpath: in
 	  *":$dir:"*) ;;
 	  *) dllsearchpath="$dllsearchpath:$dir";;
 	  esac
+	  case :$dllsearchpath: in
+	  *":$testbindir:"*) ;;
+	  *) dllsearchpath="$dllsearchpath:$testbindir";;
+	  esac
 	  ;;
 	esac
 	continue
@@ -1458,15 +1628,15 @@ EOF
       -l*)
 	if test "X$arg" = "X-lc" || test "X$arg" = "X-lm"; then
 	  case $host in
-	  *-*-cygwin* | *-*-pw32* | *-*-beos*)
+	  *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-beos*)
 	    # These systems don't actually have a C or math library (as such)
 	    continue
 	    ;;
-	  *-*-mingw* | *-*-os2*)
+	  *-*-os2*)
 	    # These systems don't actually have a C library (as such)
 	    test "X$arg" = "X-lc" && continue
 	    ;;
-	  *-*-openbsd* | *-*-freebsd*)
+	  *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
 	    # Do not include libc due to us having libc/libc_r.
 	    test "X$arg" = "X-lc" && continue
 	    ;;
@@ -1474,10 +1644,19 @@ EOF
 	    # Rhapsody C and math libraries are in the System framework
 	    deplibs="$deplibs -framework System"
 	    continue
+	    ;;
+	  *-*-sco3.2v5* | *-*-sco5v6*)
+	    # Causes problems with __ctype
+	    test "X$arg" = "X-lc" && continue
+	    ;;
+	  *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*)
+	    # Compiler inserts libc in the correct place for threads to work
+	    test "X$arg" = "X-lc" && continue
+	    ;;
 	  esac
 	elif test "X$arg" = "X-lc_r"; then
 	 case $host in
-	 *-*-openbsd* | *-*-freebsd*)
+	 *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
 	   # Do not include libc_r directly, use -pthread flag.
 	   continue
 	   ;;
@@ -1487,19 +1666,26 @@ EOF
 	continue
 	;;
 
-     -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe)
-	case $host in
-	*-*-freebsd*)
-	   compile_command="$compile_command $arg"
-	   finalize_command="$finalize_command $arg"
-	   ;;
-	*)
-	   case "$archive_cmds" in
-	     *"\$LD"*) ;;
-	     *) deplibs="$deplibs $arg";;
-	   esac
-	   ;;
-	esac
+      # Tru64 UNIX uses -model [arg] to determine the layout of C++
+      # classes, name mangling, and exception handling.
+      -model)
+	compile_command="$compile_command $arg"
+	compiler_flags="$compiler_flags $arg"
+	finalize_command="$finalize_command $arg"
+	prev=xcompiler
+	continue
+	;;
+
+     -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads)
+	compiler_flags="$compiler_flags $arg"
+	compile_command="$compile_command $arg"
+	finalize_command="$finalize_command $arg"
+	deplibs="$deplibs $arg"
+	continue
+	;;
+
+      -multi_module)
+	single_module="${wl}-multi_module"
 	continue
 	;;
 
@@ -1508,13 +1694,20 @@ EOF
 	continue
 	;;
 
-      # gcc -m* arguments should be passed to the linker via $compiler_flags
-      # in order to pass architecture information to the linker
-      # (e.g. 32 vs 64-bit).  This may also be accomplished via -Wl,-mfoo
-      # but this is not reliable with gcc because gcc may use -mfoo to
-      # select a different linker, different libraries, etc, while
-      # -Wl,-mfoo simply passes -mfoo to the linker.
-      -m*)
+      # -64, -mips[0-9] enable 64-bit mode on the SGI compiler
+      # -r[0-9][0-9]* specifies the processor on the SGI compiler
+      # -xarch=*, -xtarget=* enable 64-bit mode on the Sun compiler
+      # +DA*, +DD* enable 64-bit mode on the HP compiler
+      # -q* pass through compiler args for the IBM compiler
+      # -m* pass through architecture-specific compiler args for GCC
+      # -m*, -t[45]*, -txscale* pass through architecture-specific
+      # compiler args for GCC
+      # -p, -pg, --coverage, -fprofile-* pass through profiling flag for GCC
+      # -F/path gives path to uninstalled frameworks, gcc on darwin
+      # @file GCC response files
+      -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
+      -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*)
+
 	# Unknown arguments in both finalize_command and compile_command need
 	# to be aesthetically quoted because they are evaled later.
 	arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
@@ -1525,9 +1718,7 @@ EOF
 	esac
         compile_command="$compile_command $arg"
         finalize_command="$finalize_command $arg"
-        if test "$with_gcc" = "yes" ; then
-          compiler_flags="$compiler_flags $arg"
-        fi
+        compiler_flags="$compiler_flags $arg"
         continue
         ;;
 
@@ -1543,9 +1734,9 @@ EOF
 
       -no-install)
 	case $host in
-	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-darwin*)
 	  # The PATH hackery in wrapper scripts is required on Windows
-	  # in order for the loader to find any dlls it needs.
+	  # and Darwin in order for the loader to find any dlls it needs.
 	  $echo "$modename: warning: \`-no-install' is ignored for $host" 1>&2
 	  $echo "$modename: warning: assuming \`-no-fast-install' instead" 1>&2
 	  fast_install=no
@@ -1604,7 +1795,7 @@ EOF
 	continue
 	;;
 
-      -static)
+      -static | -static-libtool-libs)
 	# The effects of -static are defined in a previous loop.
 	# We used to do the same as -all-static on platforms that
 	# didn't have a PIC flag, but the assumption that the effects
@@ -1765,6 +1956,11 @@ EOF
 	    if test -z "$pic_object" || test "$pic_object" = none ; then
 	      arg="$non_pic_object"
 	    fi
+	  else
+	    # If the PIC object exists, use it instead.
+	    # $xdir was prepended to $pic_object above.
+	    non_pic_object="$pic_object"
+	    non_pic_objects="$non_pic_objects $non_pic_object"
 	  fi
 	else
 	  # Only an error if not doing a dry-run.
@@ -1870,9 +2066,9 @@ EOF
     if test ! -d "$output_objdir"; then
       $show "$mkdir $output_objdir"
       $run $mkdir $output_objdir
-      status=$?
-      if test "$status" -ne 0 && test ! -d "$output_objdir"; then
-	exit $status
+      exit_status=$?
+      if test "$exit_status" -ne 0 && test ! -d "$output_objdir"; then
+	exit $exit_status
       fi
     fi
 
@@ -1935,7 +2131,6 @@ EOF
     newlib_search_path=
     need_relink=no # whether we're linking any uninstalled libtool libraries
     notinst_deplibs= # not-installed libtool libraries
-    notinst_path= # paths that contain not-installed libtool libraries
     case $linkmode in
     lib)
 	passes="conv link"
@@ -1982,16 +2177,36 @@ EOF
 	lib=
 	found=no
 	case $deplib in
-	-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe)
+	-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads)
 	  if test "$linkmode,$pass" = "prog,link"; then
 	    compile_deplibs="$deplib $compile_deplibs"
 	    finalize_deplibs="$deplib $finalize_deplibs"
 	  else
-	    case "$archive_cmds" in
-	      *"\$LD"*) ;;
-	      *) deplibs="$deplibs $arg";;
-	    esac
+	    compiler_flags="$compiler_flags $deplib"
 	  fi
+
+	  case $linkmode in
+	  lib)
+	    deplibs="$deplib $deplibs"
+	    test "$pass" = conv && continue
+	    newdependency_libs="$deplib $newdependency_libs"
+	    ;;
+	  prog)
+	    if test "$pass" = conv; then
+	      deplibs="$deplib $deplibs"
+	      continue
+	    fi
+	    if test "$pass" = scan; then
+	      deplibs="$deplib $deplibs"
+	    else
+	      compile_deplibs="$deplib $compile_deplibs"
+	      finalize_deplibs="$deplib $finalize_deplibs"
+	    fi
+	    ;;
+	  *)
+	    ;;
+	  esac # linkmode
+
 	  continue
 	  ;;
 	-l*)
@@ -1999,12 +2214,13 @@ EOF
 	    $echo "$modename: warning: \`-l' is ignored for archives/objects" 1>&2
 	    continue
 	  fi
-	  if test "$pass" = conv; then
-	    deplibs="$deplib $deplibs"
-	    continue
-	  fi
 	  name=`$echo "X$deplib" | $Xsed -e 's/^-l//'`
-	  for searchdir in $newlib_search_path $lib_search_path $sys_lib_search_path $shlib_search_path; do
+	  if test "$linkmode" = lib; then
+	    searchdirs="$newlib_search_path $lib_search_path $compiler_lib_search_dirs $sys_lib_search_path $shlib_search_path"
+	  else
+	    searchdirs="$newlib_search_path $lib_search_path $sys_lib_search_path $shlib_search_path"
+	  fi
+	  for searchdir in $searchdirs; do
 	    for search_ext in .la $std_shrext .so .a; do
 	      # Search the libtool library
 	      lib="$searchdir/lib${name}${search_ext}"
@@ -2178,7 +2394,7 @@ EOF
 	esac # case $deplib
 	if test "$found" = yes || test -f "$lib"; then :
 	else
-	  $echo "$modename: cannot find the library \`$lib'" 1>&2
+	  $echo "$modename: cannot find the library \`$lib' or unhandled argument \`$deplib'" 1>&2
 	  exit $EXIT_FAILURE
 	fi
 
@@ -2202,6 +2418,8 @@ EOF
 	# it will not redefine variables installed, or shouldnotlink
 	installed=yes
 	shouldnotlink=no
+	avoidtemprpath=
+
 
 	# Read the .la file
 	case $lib in
@@ -2300,6 +2518,7 @@ EOF
 	    dir="$libdir"
 	    absdir="$libdir"
 	  fi
+	  test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes
 	else
 	  if test ! -f "$ladir/$objdir/$linklib" && test -f "$abs_ladir/$linklib"; then
 	    dir="$ladir"
@@ -2382,14 +2601,16 @@ EOF
 
 	if test "$linkmode,$pass" = "prog,link"; then
 	  if test -n "$library_names" &&
-	     { test "$prefer_static_libs" = no || test -z "$old_library"; }; then
+	     { { test "$prefer_static_libs" = no ||
+		 test "$prefer_static_libs,$installed" = "built,yes"; } ||
+	       test -z "$old_library"; }; then
 	    # We need to hardcode the library path
-	    if test -n "$shlibpath_var"; then
+	    if test -n "$shlibpath_var" && test -z "$avoidtemprpath" ; then
 	      # Make sure the rpath contains only unique directories.
 	      case "$temp_rpath " in
 	      *" $dir "*) ;;
 	      *" $absdir "*) ;;
-	      *) temp_rpath="$temp_rpath $dir" ;;
+	      *) temp_rpath="$temp_rpath $absdir" ;;
 	      esac
 	    fi
 
@@ -2426,8 +2647,12 @@ EOF
 	fi
 
 	link_static=no # Whether the deplib will be linked statically
+	use_static_libs=$prefer_static_libs
+	if test "$use_static_libs" = built && test "$installed" = yes ; then
+	  use_static_libs=no
+	fi
 	if test -n "$library_names" &&
-	   { test "$prefer_static_libs" = no || test -z "$old_library"; }; then
+	   { test "$use_static_libs" = no || test -z "$old_library"; }; then
 	  if test "$installed" = no; then
 	    notinst_deplibs="$notinst_deplibs $lib"
 	    need_relink=yes
@@ -2540,11 +2765,15 @@ EOF
 	      if test "$hardcode_direct" = no; then
 		add="$dir/$linklib"
 		case $host in
-		  *-*-sco3.2v5* ) add_dir="-L$dir" ;;
+		  *-*-sco3.2v5.0.[024]*) add_dir="-L$dir" ;;
+		  *-*-sysv4*uw2*) add_dir="-L$dir" ;;
+		  *-*-sysv5OpenUNIX* | *-*-sysv5UnixWare7.[01].[10]* | \
+		    *-*-unixware7*) add_dir="-L$dir" ;;
 		  *-*-darwin* )
 		    # if the lib is a module then we can not link against
 		    # it, someone is ignoring the new warnings I added
-		    if /usr/bin/file -L $add 2> /dev/null | $EGREP "bundle" >/dev/null ; then
+		    if /usr/bin/file -L $add 2> /dev/null |
+                      $EGREP ": [^:]* bundle" >/dev/null ; then
 		      $echo "** Warning, lib $linklib is a module, not a shared library"
 		      if test -z "$old_library" ; then
 		        $echo
@@ -2575,7 +2804,7 @@ EOF
 		add_dir="-L$dir"
 		# Try looking first in the location we're being installed to.
 		if test -n "$inst_prefix_dir"; then
-		  case "$libdir" in
+		  case $libdir in
 		    [\\/]*)
 		      add_dir="$add_dir -L$inst_prefix_dir$libdir"
 		      ;;
@@ -2648,7 +2877,7 @@ EOF
 	      add_dir="-L$libdir"
 	      # Try looking first in the location we're being installed to.
 	      if test -n "$inst_prefix_dir"; then
-		case "$libdir" in
+		case $libdir in
 		  [\\/]*)
 		    add_dir="$add_dir -L$inst_prefix_dir$libdir"
 		    ;;
@@ -2709,8 +2938,6 @@ EOF
 	      fi
 	    fi
 	  else
-	    convenience="$convenience $dir/$old_library"
-	    old_convenience="$old_convenience $dir/$old_library"
 	    deplibs="$dir/$old_library $deplibs"
 	    link_static=yes
 	  fi
@@ -2789,12 +3016,18 @@ EOF
 		  # we do not want to link against static libs,
 		  # but need to link against shared
 		  eval deplibrary_names=`${SED} -n -e 's/^library_names=\(.*\)$/\1/p' $deplib`
+		  eval deplibdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $deplib`
 		  if test -n "$deplibrary_names" ; then
 		    for tmp in $deplibrary_names ; do
 		      depdepl=$tmp
 		    done
-		    if test -f "$path/$depdepl" ; then
+		    if test -f "$deplibdir/$depdepl" ; then
+		      depdepl="$deplibdir/$depdepl"
+	      	    elif test -f "$path/$depdepl" ; then
 		      depdepl="$path/$depdepl"
+		    else
+		      # Can't find it, oh well...
+		      depdepl=
 		    fi
 		    # do not add paths which are already there
 		    case " $newlib_search_path " in
@@ -2828,12 +3061,12 @@ EOF
 	      *) continue ;;
 	      esac
 	      case " $deplibs " in
-	      *" $depdepl "*) ;;
-	      *) deplibs="$depdepl $deplibs" ;;
+	      *" $path "*) ;;
+	      *) deplibs="$path $deplibs" ;;
 	      esac
 	      case " $deplibs " in
-	      *" $path "*) ;;
-	      *) deplibs="$deplibs $path" ;;
+	      *" $depdepl "*) ;;
+	      *) deplibs="$depdepl $deplibs" ;;
 	      esac
 	    done
 	  fi # link_all_deplibs != no
@@ -2942,9 +3175,10 @@ EOF
 
     case $linkmode in
     oldlib)
-      if test -n "$deplibs"; then
-	$echo "$modename: warning: \`-l' and \`-L' are ignored for archives" 1>&2
-      fi
+      case " $deplibs" in
+      *\ -l* | *\ -L*)
+	$echo "$modename: warning: \`-l' and \`-L' are ignored for archives" 1>&2 ;;
+      esac
 
       if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
 	$echo "$modename: warning: \`-dlopen' is ignored for archives" 1>&2
@@ -3072,7 +3306,7 @@ EOF
 	  # which has an extra 1 added just for fun
 	  #
 	  case $version_type in
-	  darwin|linux|osf|windows)
+	  darwin|linux|osf|windows|none)
 	    current=`expr $number_major + $number_minor`
 	    age="$number_minor"
 	    revision="$number_revision"
@@ -3083,9 +3317,10 @@ EOF
 	    age="0"
 	    ;;
 	  irix|nonstopux)
-	    current=`expr $number_major + $number_minor - 1`
+	    current=`expr $number_major + $number_minor`
 	    age="$number_minor"
 	    revision="$number_minor"
+	    lt_irix_increment=no
 	    ;;
 	  esac
 	  ;;
@@ -3098,27 +3333,27 @@ EOF
 
 	# Check that each of the things are valid numbers.
 	case $current in
-	0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;;
+	0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
 	*)
-	  $echo "$modename: CURRENT \`$current' is not a nonnegative integer" 1>&2
+	  $echo "$modename: CURRENT \`$current' must be a nonnegative integer" 1>&2
 	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
 	  exit $EXIT_FAILURE
 	  ;;
 	esac
 
 	case $revision in
-	0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;;
+	0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
 	*)
-	  $echo "$modename: REVISION \`$revision' is not a nonnegative integer" 1>&2
+	  $echo "$modename: REVISION \`$revision' must be a nonnegative integer" 1>&2
 	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
 	  exit $EXIT_FAILURE
 	  ;;
 	esac
 
 	case $age in
-	0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;;
+	0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
 	*)
-	  $echo "$modename: AGE \`$age' is not a nonnegative integer" 1>&2
+	  $echo "$modename: AGE \`$age' must be a nonnegative integer" 1>&2
 	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
 	  exit $EXIT_FAILURE
 	  ;;
@@ -3144,7 +3379,8 @@ EOF
 	  versuffix="$major.$age.$revision"
 	  # Darwin ld doesn't like 0 for these options...
 	  minor_current=`expr $current + 1`
-	  verstring="${wl}-compatibility_version ${wl}$minor_current ${wl}-current_version ${wl}$minor_current.$revision"
+	  xlcverstring="${wl}-compatibility_version ${wl}$minor_current ${wl}-current_version ${wl}$minor_current.$revision"
+	  verstring="-compatibility_version $minor_current -current_version $minor_current.$revision"
 	  ;;
 
 	freebsd-aout)
@@ -3158,8 +3394,11 @@ EOF
 	  ;;
 
 	irix | nonstopux)
-	  major=`expr $current - $age + 1`
-
+	  if test "X$lt_irix_increment" = "Xno"; then
+	    major=`expr $current - $age`
+	  else
+	    major=`expr $current - $age + 1`
+	  fi
 	  case $version_type in
 	    nonstopux) verstring_prefix=nonstopux ;;
 	    *)         verstring_prefix=sgi ;;
@@ -3296,11 +3535,11 @@ EOF
       fi
 
       # Eliminate all temporary directories.
-      for path in $notinst_path; do
-	lib_search_path=`$echo "$lib_search_path " | ${SED} -e 's% $path % %g'`
-	deplibs=`$echo "$deplibs " | ${SED} -e 's% -L$path % %g'`
-	dependency_libs=`$echo "$dependency_libs " | ${SED} -e 's% -L$path % %g'`
-      done
+      #for path in $notinst_path; do
+      #	lib_search_path=`$echo "$lib_search_path " | ${SED} -e "s% $path % %g"`
+      #	deplibs=`$echo "$deplibs " | ${SED} -e "s% -L$path % %g"`
+      #	dependency_libs=`$echo "$dependency_libs " | ${SED} -e "s% -L$path % %g"`
+      #done
 
       if test -n "$xrpath"; then
 	# If the user specified any rpath flags, then add them.
@@ -3350,9 +3589,14 @@ EOF
 	  *-*-netbsd*)
 	    # Don't link with libc until the a.out ld.so is fixed.
 	    ;;
-	  *-*-openbsd* | *-*-freebsd*)
+	  *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
 	    # Do not include libc due to us having libc/libc_r.
-	    test "X$arg" = "X-lc" && continue
+	    ;;
+	  *-*-sco3.2v5* | *-*-sco5v6*)
+	    # Causes problems with __ctype
+	    ;;
+	  *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*)
+	    # Compiler inserts libc in the correct place for threads to work
 	    ;;
  	  *)
 	    # Add libc to deplibs on all other systems if necessary.
@@ -3396,13 +3640,12 @@ EOF
 	  int main() { return 0; }
 EOF
 	  $rm conftest
-	  $LTCC -o conftest conftest.c $deplibs
-	  if test "$?" -eq 0 ; then
+	  if $LTCC $LTCFLAGS -o conftest conftest.c $deplibs; then
 	    ldd_output=`ldd conftest`
 	    for i in $deplibs; do
-	      name="`expr $i : '-l\(.*\)'`"
+	      name=`expr $i : '-l\(.*\)'`
 	      # If $name is empty we are operating on a -L argument.
-              if test "$name" != "" && test "$name" -ne "0"; then
+              if test "$name" != "" && test "$name" != "0"; then
 		if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
 		  case " $predeps $postdeps " in
 		  *" $i "*)
@@ -3437,13 +3680,11 @@ EOF
 	    # Error occurred in the first compile.  Let's try to salvage
 	    # the situation: Compile a separate program for each library.
 	    for i in $deplibs; do
-	      name="`expr $i : '-l\(.*\)'`"
+	      name=`expr $i : '-l\(.*\)'`
 	      # If $name is empty we are operating on a -L argument.
               if test "$name" != "" && test "$name" != "0"; then
 		$rm conftest
-		$LTCC -o conftest conftest.c $i
-		# Did it work?
-		if test "$?" -eq 0 ; then
+		if $LTCC $LTCFLAGS -o conftest conftest.c $i; then
 		  ldd_output=`ldd conftest`
 		  if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
 		    case " $predeps $postdeps " in
@@ -3475,7 +3716,7 @@ EOF
 		  droppeddeps=yes
 		  $echo
 		  $echo "*** Warning!  Library $i is needed by this library but I was not able to"
-		  $echo "***  make it link in!  You will probably need to install it or some"
+		  $echo "*** make it link in!  You will probably need to install it or some"
 		  $echo "*** library that it depends on before this library will be fully"
 		  $echo "*** functional.  Installing it before continuing would be even better."
 		fi
@@ -3489,7 +3730,7 @@ EOF
 	  set dummy $deplibs_check_method
 	  file_magic_regex=`expr "$deplibs_check_method" : "$2 \(.*\)"`
 	  for a_deplib in $deplibs; do
-	    name="`expr $a_deplib : '-l\(.*\)'`"
+	    name=`expr $a_deplib : '-l\(.*\)'`
 	    # If $name is empty we are operating on a -L argument.
             if test "$name" != "" && test  "$name" != "0"; then
 	      if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
@@ -3558,7 +3799,7 @@ EOF
 	  set dummy $deplibs_check_method
 	  match_pattern_regex=`expr "$deplibs_check_method" : "$2 \(.*\)"`
 	  for a_deplib in $deplibs; do
-	    name="`expr $a_deplib : '-l\(.*\)'`"
+	    name=`expr $a_deplib : '-l\(.*\)'`
 	    # If $name is empty we are operating on a -L argument.
 	    if test -n "$name" && test "$name" != "0"; then
 	      if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
@@ -3688,6 +3929,35 @@ EOF
 	deplibs=$newdeplibs
       fi
 
+
+      # move library search paths that coincide with paths to not yet
+      # installed libraries to the beginning of the library search list
+      new_libs=
+      for path in $notinst_path; do
+	case " $new_libs " in
+	*" -L$path/$objdir "*) ;;
+	*)
+	  case " $deplibs " in
+	  *" -L$path/$objdir "*)
+	    new_libs="$new_libs -L$path/$objdir" ;;
+	  esac
+	  ;;
+	esac
+      done
+      for deplib in $deplibs; do
+	case $deplib in
+	-L*)
+	  case " $new_libs " in
+	  *" $deplib "*) ;;
+	  *) new_libs="$new_libs $deplib" ;;
+	  esac
+	  ;;
+	*) new_libs="$new_libs $deplib" ;;
+	esac
+      done
+      deplibs="$new_libs"
+
+
       # All the library-specific variables (install_libdir is set above).
       library_names=
       old_library=
@@ -3732,7 +4002,10 @@ EOF
 	     test -n "$hardcode_libdirs"; then
 	    libdir="$hardcode_libdirs"
 	    if test -n "$hardcode_libdir_flag_spec_ld"; then
-	      eval dep_rpath=\"$hardcode_libdir_flag_spec_ld\"
+	      case $archive_cmds in
+	      *\$LD*) eval dep_rpath=\"$hardcode_libdir_flag_spec_ld\" ;;
+	      *)      eval dep_rpath=\"$hardcode_libdir_flag_spec\" ;;
+	      esac
 	    else
 	      eval dep_rpath=\"$hardcode_libdir_flag_spec\"
 	    fi
@@ -3771,6 +4044,7 @@ EOF
 	fi
 
 	lib="$output_objdir/$realname"
+	linknames=
 	for link
 	do
 	  linknames="$linknames $link"
@@ -3799,6 +4073,9 @@ EOF
 	        # The command line is too long to execute in one step.
 	        $show "using reloadable object file for export list..."
 	        skipped_export=:
+		# Break out early, otherwise skipped_export may be
+		# set to false by a later but shorter cmd.
+		break
 	      fi
 	    done
 	    IFS="$save_ifs"
@@ -3868,7 +4145,8 @@ EOF
 	  fi
 	fi
 
-	if test "X$skipped_export" != "X:" && len=`expr "X$test_cmds" : ".*"` &&
+	if test "X$skipped_export" != "X:" &&
+	   len=`expr "X$test_cmds" : ".*" 2>/dev/null` &&
 	   test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then
 	  :
 	else
@@ -3887,6 +4165,7 @@ EOF
 	    save_libobjs=$libobjs
 	  fi
 	  save_output=$output
+	  output_la=`$echo "X$output" | $Xsed -e "$basename"`
 
 	  # Clear the reloadable object creation command queue and
 	  # initialize k to one.
@@ -3896,13 +4175,13 @@ EOF
 	  delfiles=
 	  last_robj=
 	  k=1
-	  output=$output_objdir/$save_output-${k}.$objext
+	  output=$output_objdir/$output_la-${k}.$objext
 	  # Loop over the list of objects to be linked.
 	  for obj in $save_libobjs
 	  do
 	    eval test_cmds=\"$reload_cmds $objlist $last_robj\"
 	    if test "X$objlist" = X ||
-	       { len=`expr "X$test_cmds" : ".*"` &&
+	       { len=`expr "X$test_cmds" : ".*" 2>/dev/null` &&
 		 test "$len" -le "$max_cmd_len"; }; then
 	      objlist="$objlist $obj"
 	    else
@@ -3916,9 +4195,9 @@ EOF
 		# the last one created.
 		eval concat_cmds=\"\$concat_cmds~$reload_cmds $objlist $last_robj\"
 	      fi
-	      last_robj=$output_objdir/$save_output-${k}.$objext
+	      last_robj=$output_objdir/$output_la-${k}.$objext
 	      k=`expr $k + 1`
-	      output=$output_objdir/$save_output-${k}.$objext
+	      output=$output_objdir/$output_la-${k}.$objext
 	      objlist=$obj
 	      len=1
 	    fi
@@ -3938,13 +4217,13 @@ EOF
 	    eval concat_cmds=\"\$concat_cmds~$export_symbols_cmds\"
           fi
 
-	  # Set up a command to remove the reloadale object files
+	  # Set up a command to remove the reloadable object files
 	  # after they are used.
 	  i=0
 	  while test "$i" -lt "$k"
 	  do
 	    i=`expr $i + 1`
-	    delfiles="$delfiles $output_objdir/$save_output-${i}.$objext"
+	    delfiles="$delfiles $output_objdir/$output_la-${i}.$objext"
 	  done
 
 	  $echo "creating a temporary reloadable object file: $output"
@@ -3992,13 +4271,30 @@ EOF
 	  IFS="$save_ifs"
 	  eval cmd=\"$cmd\"
 	  $show "$cmd"
-	  $run eval "$cmd" || exit $?
+	  $run eval "$cmd" || {
+	    lt_exit=$?
+
+	    # Restore the uninstalled library and exit
+	    if test "$mode" = relink; then
+	      $run eval '(cd $output_objdir && $rm ${realname}T && $mv ${realname}U $realname)'
+	    fi
+
+	    exit $lt_exit
+	  }
 	done
 	IFS="$save_ifs"
 
 	# Restore the uninstalled library and exit
 	if test "$mode" = relink; then
 	  $run eval '(cd $output_objdir && $rm ${realname}T && $mv $realname ${realname}T && $mv "$realname"U $realname)' || exit $?
+
+	  if test -n "$convenience"; then
+	    if test -z "$whole_archive_flag_spec"; then
+	      $show "${rm}r $gentop"
+	      $run ${rm}r "$gentop"
+	    fi
+	  fi
+
 	  exit $EXIT_SUCCESS
 	fi
 
@@ -4019,9 +4315,10 @@ EOF
       ;;
 
     obj)
-      if test -n "$deplibs"; then
-	$echo "$modename: warning: \`-l' and \`-L' are ignored for objects" 1>&2
-      fi
+      case " $deplibs" in
+      *\ -l* | *\ -L*)
+	$echo "$modename: warning: \`-l' and \`-L' are ignored for objects" 1>&2 ;;
+      esac
 
       if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
 	$echo "$modename: warning: \`-dlopen' is ignored for objects" 1>&2
@@ -4068,12 +4365,14 @@ EOF
       reload_conv_objs=
       gentop=
       # reload_cmds runs $LD directly, so let us get rid of
-      # -Wl from whole_archive_flag_spec
+      # -Wl from whole_archive_flag_spec and hope we can get by with
+      # turning comma into space..
       wl=
 
       if test -n "$convenience"; then
 	if test -n "$whole_archive_flag_spec"; then
-	  eval reload_conv_objs=\"\$reload_objs $whole_archive_flag_spec\"
+	  eval tmp_whole_archive_flags=\"$whole_archive_flag_spec\"
+	  reload_conv_objs=$reload_objs\ `$echo "X$tmp_whole_archive_flags" | $Xsed -e 's|,| |g'`
 	else
 	  gentop="$output_objdir/${obj}x"
 	  generated="$generated $gentop"
@@ -4180,6 +4479,35 @@ EOF
         ;;
       esac
 
+
+      # move library search paths that coincide with paths to not yet
+      # installed libraries to the beginning of the library search list
+      new_libs=
+      for path in $notinst_path; do
+	case " $new_libs " in
+	*" -L$path/$objdir "*) ;;
+	*)
+	  case " $compile_deplibs " in
+	  *" -L$path/$objdir "*)
+	    new_libs="$new_libs -L$path/$objdir" ;;
+	  esac
+	  ;;
+	esac
+      done
+      for deplib in $compile_deplibs; do
+	case $deplib in
+	-L*)
+	  case " $new_libs " in
+	  *" $deplib "*) ;;
+	  *) new_libs="$new_libs $deplib" ;;
+	  esac
+	  ;;
+	*) new_libs="$new_libs $deplib" ;;
+	esac
+      done
+      compile_deplibs="$new_libs"
+
+
       compile_command="$compile_command $compile_deplibs"
       finalize_command="$finalize_command $finalize_deplibs"
 
@@ -4224,10 +4552,15 @@ EOF
 	fi
 	case $host in
 	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+	  testbindir=`$echo "X$libdir" | $Xsed -e 's*/lib$*/bin*'`
 	  case :$dllsearchpath: in
 	  *":$libdir:"*) ;;
 	  *) dllsearchpath="$dllsearchpath:$libdir";;
 	  esac
+	  case :$dllsearchpath: in
+	  *":$testbindir:"*) ;;
+	  *) dllsearchpath="$dllsearchpath:$testbindir";;
+	  esac
 	  ;;
 	esac
       done
@@ -4341,13 +4674,25 @@ extern \"C\" {
 
 	    # Prepare the list of exported symbols
 	    if test -z "$export_symbols"; then
-	      export_symbols="$output_objdir/$output.exp"
+	      export_symbols="$output_objdir/$outputname.exp"
 	      $run $rm $export_symbols
-	      $run eval "${SED} -n -e '/^: @PROGRAM@$/d' -e 's/^.* \(.*\)$/\1/p' "'< "$nlist" > "$export_symbols"'
+	      $run eval "${SED} -n -e '/^: @PROGRAM@ $/d' -e 's/^.* \(.*\)$/\1/p' "'< "$nlist" > "$export_symbols"'
+              case $host in
+              *cygwin* | *mingw* )
+	        $run eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
+		$run eval 'cat "$export_symbols" >> "$output_objdir/$outputname.def"'
+                ;;
+              esac
 	    else
-	      $run eval "${SED} -e 's/\([][.*^$]\)/\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$output.exp"'
-	      $run eval 'grep -f "$output_objdir/$output.exp" < "$nlist" > "$nlist"T'
+	      $run eval "${SED} -e 's/\([].[*^$]\)/\\\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$outputname.exp"'
+	      $run eval 'grep -f "$output_objdir/$outputname.exp" < "$nlist" > "$nlist"T'
 	      $run eval 'mv "$nlist"T "$nlist"'
+              case $host in
+              *cygwin* | *mingw* )
+	        $run eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
+		$run eval 'cat "$nlist" >> "$output_objdir/$outputname.def"'
+                ;;
+              esac
 	    fi
 	  fi
 
@@ -4398,7 +4743,26 @@ extern \"C\" {
 #endif
 
 /* The mapping between symbol names and symbols. */
+"
+
+	    case $host in
+	    *cygwin* | *mingw* )
+	  $echo >> "$output_objdir/$dlsyms" "\
+/* DATA imports from DLLs on WIN32 can't be const, because
+   runtime relocations are performed -- see ld's documentation
+   on pseudo-relocs */
+struct {
+"
+	      ;;
+	    * )
+	  $echo >> "$output_objdir/$dlsyms" "\
 const struct {
+"
+	      ;;
+	    esac
+
+
+	  $echo >> "$output_objdir/$dlsyms" "\
   const char *name;
   lt_ptr address;
 }
@@ -4445,16 +4809,32 @@ static const void *lt_preloaded_setup() {
 	  esac
 
 	  # Now compile the dynamic symbol file.
-	  $show "(cd $output_objdir && $LTCC -c$no_builtin_flag$pic_flag_for_symtable \"$dlsyms\")"
-	  $run eval '(cd $output_objdir && $LTCC -c$no_builtin_flag$pic_flag_for_symtable "$dlsyms")' || exit $?
+	  $show "(cd $output_objdir && $LTCC  $LTCFLAGS -c$no_builtin_flag$pic_flag_for_symtable \"$dlsyms\")"
+	  $run eval '(cd $output_objdir && $LTCC  $LTCFLAGS -c$no_builtin_flag$pic_flag_for_symtable "$dlsyms")' || exit $?
 
 	  # Clean up the generated files.
 	  $show "$rm $output_objdir/$dlsyms $nlist ${nlist}S ${nlist}T"
 	  $run $rm "$output_objdir/$dlsyms" "$nlist" "${nlist}S" "${nlist}T"
 
 	  # Transform the symbol file into the correct name.
-	  compile_command=`$echo "X$compile_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
-	  finalize_command=`$echo "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
+          case $host in
+          *cygwin* | *mingw* )
+            if test -f "$output_objdir/${outputname}.def" ; then
+              compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}.def $output_objdir/${outputname}S.${objext}%" | $NL2SP`
+              finalize_command=`$echo "X$finalize_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}.def $output_objdir/${outputname}S.${objext}%" | $NL2SP`
+            else
+              compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%" | $NL2SP`
+              finalize_command=`$echo "X$finalize_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%" | $NL2SP`
+             fi
+            ;;
+          * )
+            compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%" | $NL2SP`
+            finalize_command=`$echo "X$finalize_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%" | $NL2SP`
+            ;;
+          esac
+	  ;;
+	*-*-freebsd*)
+	  # FreeBSD doesn't need this...
 	  ;;
 	*)
 	  $echo "$modename: unknown suffix for \`$dlsyms'" 1>&2
@@ -4467,19 +4847,19 @@ static const void *lt_preloaded_setup() {
 	# really was required.
 
 	# Nullify the symbol file.
-	compile_command=`$echo "X$compile_command" | $Xsed -e "s% @SYMFILE@%%"`
-	finalize_command=`$echo "X$finalize_command" | $Xsed -e "s% @SYMFILE@%%"`
+	compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e "s% @SYMFILE@%%" | $NL2SP`
+	finalize_command=`$echo "X$finalize_command" | $SP2NL | $Xsed -e "s% @SYMFILE@%%" | $NL2SP`
       fi
 
       if test "$need_relink" = no || test "$build_libtool_libs" != yes; then
 	# Replace the output file specification.
-	compile_command=`$echo "X$compile_command" | $Xsed -e 's%@OUTPUT@%'"$output"'%g'`
+	compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e 's%@OUTPUT@%'"$output"'%g' | $NL2SP`
 	link_command="$compile_command$compile_rpath"
 
 	# We have no uninstalled library dependencies, so finalize right now.
 	$show "$link_command"
 	$run eval "$link_command"
-	status=$?
+	exit_status=$?
 
 	# Delete the generated files.
 	if test -n "$dlsyms"; then
@@ -4487,7 +4867,7 @@ static const void *lt_preloaded_setup() {
 	  $run $rm "$output_objdir/${outputname}S.${objext}"
 	fi
 
-	exit $status
+	exit $exit_status
       fi
 
       if test -n "$shlibpath_var"; then
@@ -4560,7 +4940,7 @@ static const void *lt_preloaded_setup() {
 	if test "$fast_install" != no; then
 	  link_command="$finalize_var$compile_command$finalize_rpath"
 	  if test "$fast_install" = yes; then
-	    relink_command=`$echo "X$compile_var$compile_command$compile_rpath" | $Xsed -e 's%@OUTPUT@%\$progdir/\$file%g'`
+	    relink_command=`$echo "X$compile_var$compile_command$compile_rpath" | $SP2NL | $Xsed -e 's%@OUTPUT@%\$progdir/\$file%g' | $NL2SP`
 	  else
 	    # fast_install is set to needless
 	    relink_command=
@@ -4597,7 +4977,7 @@ static const void *lt_preloaded_setup() {
 	  fi
 	done
 	relink_command="(cd `pwd`; $relink_command)"
-	relink_command=`$echo "X$relink_command" | $Xsed -e "$sed_quote_subst"`
+	relink_command=`$echo "X$relink_command" | $SP2NL | $Xsed -e "$sed_quote_subst" | $NL2SP`
       fi
 
       # Quote $echo for shipping.
@@ -4627,10 +5007,12 @@ static const void *lt_preloaded_setup() {
 	esac
 	case $host in
 	  *cygwin* | *mingw* )
-	    cwrappersource=`$echo ${objdir}/lt-${output}.c`
-	    cwrapper=`$echo ${output}.exe`
-	    $rm $cwrappersource $cwrapper
-	    trap "$rm $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2 15
+            output_name=`basename $output`
+            output_path=`dirname $output`
+            cwrappersource="$output_path/$objdir/lt-$output_name.c"
+            cwrapper="$output_path/$output_name.exe"
+            $rm $cwrappersource $cwrapper
+            trap "$rm $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2 15
 
 	    cat > $cwrappersource <
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #if defined(PATH_MAX)
 # define LT_PATHMAX PATH_MAX
@@ -4665,15 +5050,19 @@ EOF
 #endif
 
 #ifndef DIR_SEPARATOR
-#define DIR_SEPARATOR '/'
+# define DIR_SEPARATOR '/'
+# define PATH_SEPARATOR ':'
 #endif
 
 #if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
   defined (__OS2__)
-#define HAVE_DOS_BASED_FILE_SYSTEM
-#ifndef DIR_SEPARATOR_2
-#define DIR_SEPARATOR_2 '\\'
-#endif
+# define HAVE_DOS_BASED_FILE_SYSTEM
+# ifndef DIR_SEPARATOR_2
+#  define DIR_SEPARATOR_2 '\\'
+# endif
+# ifndef PATH_SEPARATOR_2
+#  define PATH_SEPARATOR_2 ';'
+# endif
 #endif
 
 #ifndef DIR_SEPARATOR_2
@@ -4683,17 +5072,32 @@ EOF
         (((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
 #endif /* DIR_SEPARATOR_2 */
 
+#ifndef PATH_SEPARATOR_2
+# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR)
+#else /* PATH_SEPARATOR_2 */
+# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2)
+#endif /* PATH_SEPARATOR_2 */
+
 #define XMALLOC(type, num)      ((type *) xmalloc ((num) * sizeof(type)))
 #define XFREE(stale) do { \
   if (stale) { free ((void *) stale); stale = 0; } \
 } while (0)
 
+/* -DDEBUG is fairly common in CFLAGS.  */
+#undef DEBUG
+#if defined DEBUGWRAPPER
+# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__)
+#else
+# define DEBUG(format, ...)
+#endif
+
 const char *program_name = NULL;
 
 void * xmalloc (size_t num);
 char * xstrdup (const char *string);
-char * basename (const char *name);
-char * fnqualify(const char *path);
+const char * base_name (const char *name);
+char * find_executable(const char *wrapper);
+int    check_executable(const char *path);
 char * strendzap(char *str, const char *pat);
 void lt_fatal (const char *message, ...);
 
@@ -4703,29 +5107,51 @@ main (int argc, char *argv[])
   char **newargz;
   int i;
 
-  program_name = (char *) xstrdup ((char *) basename (argv[0]));
+  program_name = (char *) xstrdup (base_name (argv[0]));
+  DEBUG("(main) argv[0]      : %s\n",argv[0]);
+  DEBUG("(main) program_name : %s\n",program_name);
   newargz = XMALLOC(char *, argc+2);
 EOF
 
-	    cat >> $cwrappersource <> $cwrappersource <> $cwrappersource <<"EOF"
-  newargz[1] = fnqualify(argv[0]);
+            cat >> $cwrappersource <<"EOF"
+  newargz[1] = find_executable(argv[0]);
+  if (newargz[1] == NULL)
+    lt_fatal("Couldn't find %s", argv[0]);
+  DEBUG("(main) found exe at : %s\n",newargz[1]);
   /* we know the script has the same name, without the .exe */
   /* so make sure newargz[1] doesn't end in .exe */
   strendzap(newargz[1],".exe");
   for (i = 1; i < argc; i++)
     newargz[i+1] = xstrdup(argv[i]);
   newargz[argc+1] = NULL;
+
+  for (i=0; i> $cwrappersource <> $cwrappersource <> $cwrappersource <> $cwrappersource <<"EOF"
+            cat >> $cwrappersource <<"EOF"
+  return 127;
 }
 
 void *
@@ -4745,48 +5171,148 @@ xstrdup (const char *string)
 ;
 }
 
-char *
-basename (const char *name)
+const char *
+base_name (const char *name)
 {
   const char *base;
 
 #if defined (HAVE_DOS_BASED_FILE_SYSTEM)
   /* Skip over the disk name in MSDOS pathnames. */
-  if (isalpha (name[0]) && name[1] == ':')
+  if (isalpha ((unsigned char)name[0]) && name[1] == ':')
     name += 2;
 #endif
 
   for (base = name; *name; name++)
     if (IS_DIR_SEPARATOR (*name))
       base = name + 1;
-  return (char *) base;
+  return base;
+}
+
+int
+check_executable(const char * path)
+{
+  struct stat st;
+
+  DEBUG("(check_executable)  : %s\n", path ? (*path ? path : "EMPTY!") : "NULL!");
+  if ((!path) || (!*path))
+    return 0;
+
+  if ((stat (path, &st) >= 0) &&
+      (
+        /* MinGW & native WIN32 do not support S_IXOTH or S_IXGRP */
+#if defined (S_IXOTH)
+       ((st.st_mode & S_IXOTH) == S_IXOTH) ||
+#endif
+#if defined (S_IXGRP)
+       ((st.st_mode & S_IXGRP) == S_IXGRP) ||
+#endif
+       ((st.st_mode & S_IXUSR) == S_IXUSR))
+      )
+    return 1;
+  else
+    return 0;
 }
 
+/* Searches for the full path of the wrapper.  Returns
+   newly allocated full path name if found, NULL otherwise */
 char *
-fnqualify(const char *path)
+find_executable (const char* wrapper)
 {
-  size_t size;
-  char *p;
+  int has_slash = 0;
+  const char* p;
+  const char* p_next;
+  /* static buffer for getcwd */
   char tmp[LT_PATHMAX + 1];
+  int tmp_len;
+  char* concat_name;
+
+  DEBUG("(find_executable)  : %s\n", wrapper ? (*wrapper ? wrapper : "EMPTY!") : "NULL!");
 
-  assert(path != NULL);
+  if ((wrapper == NULL) || (*wrapper == '\0'))
+    return NULL;
 
-  /* Is it qualified already? */
+  /* Absolute path? */
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+  if (isalpha ((unsigned char)wrapper[0]) && wrapper[1] == ':')
+  {
+    concat_name = xstrdup (wrapper);
+    if (check_executable(concat_name))
+      return concat_name;
+    XFREE(concat_name);
+  }
+  else
+  {
+#endif
+    if (IS_DIR_SEPARATOR (wrapper[0]))
+    {
+      concat_name = xstrdup (wrapper);
+      if (check_executable(concat_name))
+        return concat_name;
+      XFREE(concat_name);
+    }
 #if defined (HAVE_DOS_BASED_FILE_SYSTEM)
-  if (isalpha (path[0]) && path[1] == ':')
-    return xstrdup (path);
+  }
 #endif
-  if (IS_DIR_SEPARATOR (path[0]))
-    return xstrdup (path);
 
-  /* prepend the current directory */
-  /* doesn't handle '~' */
+  for (p = wrapper; *p; p++)
+    if (*p == '/')
+    {
+      has_slash = 1;
+      break;
+    }
+  if (!has_slash)
+  {
+    /* no slashes; search PATH */
+    const char* path = getenv ("PATH");
+    if (path != NULL)
+    {
+      for (p = path; *p; p = p_next)
+      {
+        const char* q;
+        size_t p_len;
+        for (q = p; *q; q++)
+          if (IS_PATH_SEPARATOR(*q))
+            break;
+        p_len = q - p;
+        p_next = (*q == '\0' ? q : q + 1);
+        if (p_len == 0)
+        {
+          /* empty path: current directory */
+          if (getcwd (tmp, LT_PATHMAX) == NULL)
+            lt_fatal ("getcwd failed");
+          tmp_len = strlen(tmp);
+          concat_name = XMALLOC(char, tmp_len + 1 + strlen(wrapper) + 1);
+          memcpy (concat_name, tmp, tmp_len);
+          concat_name[tmp_len] = '/';
+          strcpy (concat_name + tmp_len + 1, wrapper);
+        }
+        else
+        {
+          concat_name = XMALLOC(char, p_len + 1 + strlen(wrapper) + 1);
+          memcpy (concat_name, p, p_len);
+          concat_name[p_len] = '/';
+          strcpy (concat_name + p_len + 1, wrapper);
+        }
+        if (check_executable(concat_name))
+          return concat_name;
+        XFREE(concat_name);
+      }
+    }
+    /* not found in PATH; assume curdir */
+  }
+  /* Relative path | not found in path: prepend cwd */
   if (getcwd (tmp, LT_PATHMAX) == NULL)
     lt_fatal ("getcwd failed");
-  size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
-  p = XMALLOC(char, size);
-  sprintf(p, "%s%c%s", tmp, DIR_SEPARATOR, path);
-  return p;
+  tmp_len = strlen(tmp);
+  concat_name = XMALLOC(char, tmp_len + 1 + strlen(wrapper) + 1);
+  memcpy (concat_name, tmp, tmp_len);
+  concat_name[tmp_len] = '/';
+  strcpy (concat_name + tmp_len + 1, wrapper);
+
+  if (check_executable(concat_name))
+    return concat_name;
+  XFREE(concat_name);
+  return NULL;
 }
 
 char *
@@ -4830,16 +5356,16 @@ lt_fatal (const char *message, ...)
   va_end (ap);
 }
 EOF
-	  # we should really use a build-platform specific compiler
-	  # here, but OTOH, the wrappers (shell script and this C one)
-	  # are only useful if you want to execute the "real" binary.
-	  # Since the "real" binary is built for $host, then this
-	  # wrapper might as well be built for $host, too.
-	  $run $LTCC -s -o $cwrapper $cwrappersource
-	  ;;
-	esac
-	$rm $output
-	trap "$rm $output; exit $EXIT_FAILURE" 1 2 15
+          # we should really use a build-platform specific compiler
+          # here, but OTOH, the wrappers (shell script and this C one)
+          # are only useful if you want to execute the "real" binary.
+          # Since the "real" binary is built for $host, then this
+          # wrapper might as well be built for $host, too.
+          $run $LTCC $LTCFLAGS -s -o $cwrapper $cwrappersource
+          ;;
+        esac
+        $rm $output
+        trap "$rm $output; exit $EXIT_FAILURE" 1 2 15
 
 	$echo > $output "\
 #! $SHELL
@@ -4858,6 +5384,20 @@ EOF
 Xsed='${SED} -e 1s/^X//'
 sed_quote_subst='$sed_quote_subst'
 
+# Be Bourne compatible (taken from Autoconf:_AS_BOURNE_COMPATIBLE).
+if test -n \"\${ZSH_VERSION+set}\" && (emulate sh) >/dev/null 2>&1; then
+  emulate sh
+  NULLCMD=:
+  # Zsh 3.x and 4.x performs word splitting on \${1+\"\$@\"}, which
+  # is contrary to our usage.  Disable this feature.
+  alias -g '\${1+\"\$@\"}'='\"\$@\"'
+  setopt NO_GLOB_SUBST
+else
+  case \`(set -o) 2>/dev/null\` in *posix*) set -o posix;; esac
+fi
+BIN_SH=xpg4; export BIN_SH # for Tru64
+DUALCASE=1; export DUALCASE # for MKS sh
+
 # The HP-UX ksh and POSIX shell print the target directory to stdout
 # if CDPATH is set.
 (unset CDPATH) >/dev/null 2>&1 && unset CDPATH
@@ -4989,23 +5529,23 @@ else
 	# Backslashes separate directories on plain windows
 	*-*-mingw | *-*-os2*)
 	  $echo >> $output "\
-      exec \$progdir\\\\\$program \${1+\"\$@\"}
+      exec \"\$progdir\\\\\$program\" \${1+\"\$@\"}
 "
 	  ;;
 
 	*)
 	  $echo >> $output "\
-      exec \$progdir/\$program \${1+\"\$@\"}
+      exec \"\$progdir/\$program\" \${1+\"\$@\"}
 "
 	  ;;
 	esac
 	$echo >> $output "\
-      \$echo \"\$0: cannot exec \$program \${1+\"\$@\"}\"
+      \$echo \"\$0: cannot exec \$program \$*\"
       exit $EXIT_FAILURE
     fi
   else
     # The program doesn't exist.
-    \$echo \"\$0: error: \$progdir/\$program does not exist\" 1>&2
+    \$echo \"\$0: error: \\\`\$progdir/\$program' does not exist\" 1>&2
     \$echo \"This script is just a wrapper for \$program.\" 1>&2
     $echo \"See the $PACKAGE documentation for more information.\" 1>&2
     exit $EXIT_FAILURE
@@ -5047,6 +5587,63 @@ fi\
       if test -n "$old_archive_from_new_cmds" && test "$build_libtool_libs" = yes; then
        cmds=$old_archive_from_new_cmds
       else
+	# POSIX demands no paths to be encoded in archives.  We have
+	# to avoid creating archives with duplicate basenames if we
+	# might have to extract them afterwards, e.g., when creating a
+	# static archive out of a convenience library, or when linking
+	# the entirety of a libtool archive into another (currently
+	# not supported by libtool).
+	if (for obj in $oldobjs
+	    do
+	      $echo "X$obj" | $Xsed -e 's%^.*/%%'
+	    done | sort | sort -uc >/dev/null 2>&1); then
+	  :
+	else
+	  $echo "copying selected object files to avoid basename conflicts..."
+
+	  if test -z "$gentop"; then
+	    gentop="$output_objdir/${outputname}x"
+	    generated="$generated $gentop"
+
+	    $show "${rm}r $gentop"
+	    $run ${rm}r "$gentop"
+	    $show "$mkdir $gentop"
+	    $run $mkdir "$gentop"
+	    exit_status=$?
+	    if test "$exit_status" -ne 0 && test ! -d "$gentop"; then
+	      exit $exit_status
+	    fi
+	  fi
+
+	  save_oldobjs=$oldobjs
+	  oldobjs=
+	  counter=1
+	  for obj in $save_oldobjs
+	  do
+	    objbase=`$echo "X$obj" | $Xsed -e 's%^.*/%%'`
+	    case " $oldobjs " in
+	    " ") oldobjs=$obj ;;
+	    *[\ /]"$objbase "*)
+	      while :; do
+		# Make sure we don't pick an alternate name that also
+		# overlaps.
+		newobj=lt$counter-$objbase
+		counter=`expr $counter + 1`
+		case " $oldobjs " in
+		*[\ /]"$newobj "*) ;;
+		*) if test ! -f "$gentop/$newobj"; then break; fi ;;
+		esac
+	      done
+	      $show "ln $obj $gentop/$newobj || cp $obj $gentop/$newobj"
+	      $run ln "$obj" "$gentop/$newobj" ||
+	      $run cp "$obj" "$gentop/$newobj"
+	      oldobjs="$oldobjs $gentop/$newobj"
+	      ;;
+	    *) oldobjs="$oldobjs $obj" ;;
+	    esac
+	  done
+	fi
+
 	eval cmds=\"$old_archive_cmds\"
 
 	if len=`expr "X$cmds" : ".*"` &&
@@ -5060,20 +5657,7 @@ fi\
 	  objlist=
 	  concat_cmds=
 	  save_oldobjs=$oldobjs
-	  # GNU ar 2.10+ was changed to match POSIX; thus no paths are
-	  # encoded into archives.  This makes 'ar r' malfunction in
-	  # this piecewise linking case whenever conflicting object
-	  # names appear in distinct ar calls; check, warn and compensate.
-	    if (for obj in $save_oldobjs
-	    do
-	      $echo "X$obj" | $Xsed -e 's%^.*/%%'
-	    done | sort | sort -uc >/dev/null 2>&1); then
-	    :
-	  else
-	    $echo "$modename: warning: object name conflicts; overriding AR_FLAGS to 'cq'" 1>&2
-	    $echo "$modename: warning: to ensure that POSIX-compatible ar will work" 1>&2
-	    AR_FLAGS=cq
-	  fi
+
 	  # Is there a better way of finding the last object in the list?
 	  for obj in $save_oldobjs
 	  do
@@ -5084,7 +5668,7 @@ fi\
 	    oldobjs="$objlist $obj"
 	    objlist="$objlist $obj"
 	    eval test_cmds=\"$old_archive_cmds\"
-	    if len=`expr "X$test_cmds" : ".*"` &&
+	    if len=`expr "X$test_cmds" : ".*" 2>/dev/null` &&
 	       test "$len" -le "$max_cmd_len"; then
 	      :
 	    else
@@ -5142,7 +5726,7 @@ fi\
       done
       # Quote the link command for shipping.
       relink_command="(cd `pwd`; $SHELL $progpath $preserve_args --mode=relink $libtool_args @inst_prefix_dir@)"
-      relink_command=`$echo "X$relink_command" | $Xsed -e "$sed_quote_subst"`
+      relink_command=`$echo "X$relink_command" | $SP2NL | $Xsed -e "$sed_quote_subst" | $NL2SP`
       if test "$hardcode_automatic" = yes ; then
 	relink_command=
       fi
@@ -5281,11 +5865,11 @@ relink_command=\"$relink_command\""
     # install_prog (especially on Windows NT).
     if test "$nonopt" = "$SHELL" || test "$nonopt" = /bin/sh ||
        # Allow the use of GNU shtool's install command.
-       $echo "X$nonopt" | $Xsed | grep shtool > /dev/null; then
+       $echo "X$nonopt" | grep shtool > /dev/null; then
       # Aesthetically quote it.
       arg=`$echo "X$nonopt" | $Xsed -e "$sed_quote_subst"`
       case $arg in
-      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
 	arg="\"$arg\""
 	;;
       esac
@@ -5294,14 +5878,14 @@ relink_command=\"$relink_command\""
       shift
     else
       install_prog=
-      arg="$nonopt"
+      arg=$nonopt
     fi
 
     # The real first argument should be the name of the installation program.
     # Aesthetically quote it.
     arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
     case $arg in
-    *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+    *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
       arg="\"$arg\""
       ;;
     esac
@@ -5319,28 +5903,31 @@ relink_command=\"$relink_command\""
     do
       if test -n "$dest"; then
 	files="$files $dest"
-	dest="$arg"
+	dest=$arg
 	continue
       fi
 
       case $arg in
       -d) isdir=yes ;;
-      -f) prev="-f" ;;
-      -g) prev="-g" ;;
-      -m) prev="-m" ;;
-      -o) prev="-o" ;;
+      -f) 
+      	case " $install_prog " in
+	*[\\\ /]cp\ *) ;;
+	*) prev=$arg ;;
+	esac
+	;;
+      -g | -m | -o) prev=$arg ;;
       -s)
 	stripme=" -s"
 	continue
 	;;
-      -*) ;;
-
+      -*)
+	;;
       *)
 	# If the previous option needed an argument, then skip it.
 	if test -n "$prev"; then
 	  prev=
 	else
-	  dest="$arg"
+	  dest=$arg
 	  continue
 	fi
 	;;
@@ -5349,7 +5936,7 @@ relink_command=\"$relink_command\""
       # Aesthetically quote the argument.
       arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
       case $arg in
-      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
 	arg="\"$arg\""
 	;;
       esac
@@ -5484,9 +6071,9 @@ relink_command=\"$relink_command\""
 
 	  if test -n "$inst_prefix_dir"; then
 	    # Stick the inst_prefix_dir data into the link command.
-	    relink_command=`$echo "$relink_command" | $SED "s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%"`
+	    relink_command=`$echo "$relink_command" | $SP2NL | $SED "s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%" | $NL2SP`
 	  else
-	    relink_command=`$echo "$relink_command" | $SED "s%@inst_prefix_dir@%%"`
+	    relink_command=`$echo "$relink_command" | $SP2NL | $SED "s%@inst_prefix_dir@%%" | $NL2SP`
 	  fi
 
 	  $echo "$modename: warning: relinking \`$file'" 1>&2
@@ -5518,11 +6105,14 @@ relink_command=\"$relink_command\""
 
 	  if test "$#" -gt 0; then
 	    # Delete the old symlinks, and create new ones.
+	    # Try `ln -sf' first, because the `ln' binary might depend on
+	    # the symlink we replace!  Solaris /bin/ln does not understand -f,
+	    # so we also need to try rm && ln -s.
 	    for linkname
 	    do
 	      if test "$linkname" != "$realname"; then
-		$show "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)"
-		$run eval "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)"
+                $show "(cd $destdir && { $LN_S -f $realname $linkname || { $rm $linkname && $LN_S $realname $linkname; }; })"
+                $run eval "(cd $destdir && { $LN_S -f $realname $linkname || { $rm $linkname && $LN_S $realname $linkname; }; })"
 	      fi
 	    done
 	  fi
@@ -5535,7 +6125,16 @@ relink_command=\"$relink_command\""
 	    IFS="$save_ifs"
 	    eval cmd=\"$cmd\"
 	    $show "$cmd"
-	    $run eval "$cmd" || exit $?
+	    $run eval "$cmd" || {
+	      lt_exit=$?
+
+	      # Restore the uninstalled library and exit
+	      if test "$mode" = relink; then
+		$run eval '(cd $output_objdir && $rm ${realname}T && $mv ${realname}U $realname)'
+	      fi
+
+	      exit $lt_exit
+	    }
 	  done
 	  IFS="$save_ifs"
 	fi
@@ -5629,17 +6228,15 @@ relink_command=\"$relink_command\""
 	  notinst_deplibs=
 	  relink_command=
 
-	  # To insure that "foo" is sourced, and not "foo.exe",
-	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
-	  # which disallows the automatic-append-.exe behavior.
-	  case $build in
-	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
-	  *) wrapperdot=${wrapper} ;;
-	  esac
+	  # Note that it is not necessary on cygwin/mingw to append a dot to
+	  # foo even if both foo and FILE.exe exist: automatic-append-.exe
+	  # behavior happens only for exec(3), not for open(2)!  Also, sourcing
+	  # `FILE.' does not work on cygwin managed mounts.
+	  #
 	  # If there is no directory component, then add one.
-	  case $file in
-	  */* | *\\*) . ${wrapperdot} ;;
-	  *) . ./${wrapperdot} ;;
+	  case $wrapper in
+	  */* | *\\*) . ${wrapper} ;;
+	  *) . ./${wrapper} ;;
 	  esac
 
 	  # Check the variables that should have been set.
@@ -5667,38 +6264,25 @@ relink_command=\"$relink_command\""
 	  done
 
 	  relink_command=
-	  # To insure that "foo" is sourced, and not "foo.exe",
-	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
-	  # which disallows the automatic-append-.exe behavior.
-	  case $build in
-	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
-	  *) wrapperdot=${wrapper} ;;
-	  esac
+	  # Note that it is not necessary on cygwin/mingw to append a dot to
+	  # foo even if both foo and FILE.exe exist: automatic-append-.exe
+	  # behavior happens only for exec(3), not for open(2)!  Also, sourcing
+	  # `FILE.' does not work on cygwin managed mounts.
+	  #
 	  # If there is no directory component, then add one.
-	  case $file in
-	  */* | *\\*) . ${wrapperdot} ;;
-	  *) . ./${wrapperdot} ;;
+	  case $wrapper in
+	  */* | *\\*) . ${wrapper} ;;
+	  *) . ./${wrapper} ;;
 	  esac
 
 	  outputname=
 	  if test "$fast_install" = no && test -n "$relink_command"; then
 	    if test "$finalize" = yes && test -z "$run"; then
-	      tmpdir="/tmp"
-	      test -n "$TMPDIR" && tmpdir="$TMPDIR"
-	      tmpdir="$tmpdir/libtool-$$"
-	      save_umask=`umask`
-	      umask 0077
-	      if $mkdir "$tmpdir"; then
-	        umask $save_umask
-	      else
-	        umask $save_umask
-		$echo "$modename: error: cannot create temporary directory \`$tmpdir'" 1>&2
-		continue
-	      fi
+	      tmpdir=`func_mktempdir`
 	      file=`$echo "X$file$stripped_ext" | $Xsed -e 's%^.*/%%'`
 	      outputname="$tmpdir/$file"
 	      # Replace the output file specification.
-	      relink_command=`$echo "X$relink_command" | $Xsed -e 's%@OUTPUT@%'"$outputname"'%g'`
+	      relink_command=`$echo "X$relink_command" | $SP2NL | $Xsed -e 's%@OUTPUT@%'"$outputname"'%g' | $NL2SP`
 
 	      $show "$relink_command"
 	      if $run eval "$relink_command"; then :
@@ -5718,7 +6302,7 @@ relink_command=\"$relink_command\""
 	fi
 
 	# remove .exe since cygwin /usr/bin/install will append another
-	# one anyways
+	# one anyway 
 	case $install_prog,$host in
 	*/usr/bin/install*,*cygwin*)
 	  case $file:$destfile in
@@ -5818,7 +6402,7 @@ relink_command=\"$relink_command\""
     # Exit here if they wanted silent mode.
     test "$show" = : && exit $EXIT_SUCCESS
 
-    $echo "----------------------------------------------------------------------"
+    $echo "X----------------------------------------------------------------------" | $Xsed
     $echo "Libraries have been installed in:"
     for libdir in $libdirs; do
       $echo "   $libdir"
@@ -5851,7 +6435,7 @@ relink_command=\"$relink_command\""
     $echo
     $echo "See any operating system documentation about shared libraries for"
     $echo "more information, such as the ld(1) and ld.so(8) manual pages."
-    $echo "----------------------------------------------------------------------"
+    $echo "X----------------------------------------------------------------------" | $Xsed
     exit $EXIT_SUCCESS
     ;;
 
@@ -5909,8 +6493,10 @@ relink_command=\"$relink_command\""
 	if test -f "$dir/$objdir/$dlname"; then
 	  dir="$dir/$objdir"
 	else
-	  $echo "$modename: cannot find \`$dlname' in \`$dir' or \`$dir/$objdir'" 1>&2
-	  exit $EXIT_FAILURE
+	  if test ! -f "$dir/$dlname"; then
+	    $echo "$modename: cannot find \`$dlname' in \`$dir' or \`$dir/$objdir'" 1>&2
+	    exit $EXIT_FAILURE
+	  fi
 	fi
 	;;
 
@@ -5974,12 +6560,12 @@ relink_command=\"$relink_command\""
       fi
 
       # Restore saved environment variables
-      if test "${save_LC_ALL+set}" = set; then
-	LC_ALL="$save_LC_ALL"; export LC_ALL
-      fi
-      if test "${save_LANG+set}" = set; then
-	LANG="$save_LANG"; export LANG
-      fi
+      for lt_var in LANG LANGUAGE LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES
+      do
+	eval "if test \"\${save_$lt_var+set}\" = set; then
+		$lt_var=\$save_$lt_var; export $lt_var
+	      fi"
+      done
 
       # Now prepare to actually exec the command.
       exec_cmd="\$cmd$args"
@@ -6068,9 +6654,17 @@ relink_command=\"$relink_command\""
 	    rmfiles="$rmfiles $objdir/$n"
 	  done
 	  test -n "$old_library" && rmfiles="$rmfiles $objdir/$old_library"
-	  test "$mode" = clean && rmfiles="$rmfiles $objdir/$name $objdir/${name}i"
 
-	  if test "$mode" = uninstall; then
+	  case "$mode" in
+	  clean)
+	    case "  $library_names " in
+	    # "  " in the beginning catches empty $dlname
+	    *" $dlname "*) ;;
+	    *) rmfiles="$rmfiles $objdir/$dlname" ;;
+	    esac
+	     test -n "$libdir" && rmfiles="$rmfiles $objdir/$name $objdir/${name}i"
+	    ;;
+	  uninstall)
 	    if test -n "$library_names"; then
 	      # Do each command in the postuninstall commands.
 	      cmds=$postuninstall_cmds
@@ -6103,7 +6697,8 @@ relink_command=\"$relink_command\""
 	      IFS="$save_ifs"
 	    fi
 	    # FIXME: should reinstall the best remaining shared library.
-	  fi
+	    ;;
+	  esac
 	fi
 	;;
 
@@ -6327,9 +6922,9 @@ The following components of LINK-COMMAND are treated specially:
   -dlpreopen FILE   link in FILE and add its symbols to lt_preloaded_symbols
   -export-dynamic   allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
   -export-symbols SYMFILE
-		    try to export only the symbols listed in SYMFILE
+                    try to export only the symbols listed in SYMFILE
   -export-symbols-regex REGEX
-		    try to export only the symbols matching REGEX
+                    try to export only the symbols matching REGEX
   -LLIBDIR          search LIBDIR for required installed libraries
   -lNAME            OUTPUT-FILE requires the installed library libNAME
   -module           build a library that can dlopened
@@ -6343,9 +6938,11 @@ The following components of LINK-COMMAND are treated specially:
   -release RELEASE  specify package release information
   -rpath LIBDIR     the created library will eventually be installed in LIBDIR
   -R[ ]LIBDIR       add LIBDIR to the runtime path of programs and libraries
-  -static           do not do any dynamic linking of libtool libraries
+  -static           do not do any dynamic linking of uninstalled libtool libraries
+  -static-libtool-libs
+                    do not do any dynamic linking of libtool libraries
   -version-info CURRENT[:REVISION[:AGE]]
-		    specify library version info [each variable defaults to 0]
+                    specify library version info [each variable defaults to 0]
 
 All other options (arguments beginning with \`-') are ignored.
 
@@ -6388,7 +6985,7 @@ esac
 $echo
 $echo "Try \`$modename --help' for more information about other modes."
 
-exit $EXIT_SUCCESS
+exit $?
 
 # The TAGs below are defined such that we never get into a situation
 # in which we disable both kinds of libraries.  Given conflicting
@@ -6402,12 +6999,11 @@ exit $EXIT_SUCCESS
 # configuration.  But we'll never go from static-only to shared-only.
 
 # ### BEGIN LIBTOOL TAG CONFIG: disable-shared
-build_libtool_libs=no
-build_old_libs=yes
+disable_libs=shared
 # ### END LIBTOOL TAG CONFIG: disable-shared
 
 # ### BEGIN LIBTOOL TAG CONFIG: disable-static
-build_old_libs=`case $build_libtool_libs in yes) $echo no;; *) $echo yes;; esac`
+disable_libs=static
 # ### END LIBTOOL TAG CONFIG: disable-static
 
 # Local Variables:
diff --git a/make/rules.in b/make/rules.in
index e1488e9c1c96..f9464679567d 100644
--- a/make/rules.in
+++ b/make/rules.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: rules.in,v 1.47.18.15 2008/02/18 23:46:01 tbox Exp $
+# $Id: rules.in,v 1.47.18.17 2009/01/10 23:45:59 tbox Exp $
 
 ###
 ### Common Makefile rules for BIND 9.
@@ -34,6 +34,7 @@ libdir =	@libdir@
 sysconfdir =	@sysconfdir@
 localstatedir =	@localstatedir@
 mandir =	@mandir@
+datarootdir =   @datarootdir@
 
 DESTDIR =
 
diff --git a/version b/version
index d15763c1a8ba..7d97c13f850f 100644
--- a/version
+++ b/version
@@ -1,10 +1,10 @@
-# $Id: version,v 1.29.134.23.2.4 2009/11/19 00:25:17 marka Exp $
+# $Id: version,v 1.29.134.28 2010/01/21 01:10:54 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
 #
 MAJORVER=9
 MINORVER=4
-PATCHVER=3
-RELEASETYPE=-P
-RELEASEVER=4
+PATCHVER=
+RELEASETYPE=-ESV
+RELEASEVER=
-- 
cgit v1.2.3